Tuning LIA's models without a restart, and without impossible configurations

The problem

On a LIA instance, dozens of tasks call on a language model: understanding your request, planning, answering, summarizing a meeting, writing your journal, preparing a notification. An administrator must be able to change the model for one of them, because a provider raises its prices, a newer model comes out or a task answers badly.

If that change goes through a configuration file and a restart, people hesitate to make it. If it goes through a form that accepts anything, you end up saving a combination the provider will refuse on every call. And if nothing caps spending, an instance open to several accounts can cost much more than expected.

What I wanted

I wanted a single place for these settings, an immediate effect, and a screen that only offers what will work. I also wanted spending to have two clear ceilings: one for each account and one for the whole instance.

How it works

Each task has default values, written in the code and proven in use. In Administration › LLM Configuration, the administrator can override them, task by task: provider, model, temperature, response budget, timeout, reasoning depth. This override is saved in the database and applies to the next operations, without a restart. The “Reset” button clears it and goes back to the code's default. There's no hidden third source: an old model setting left in an environment file is ignored.

The screen also acts as a safeguard:

It only offers the reasoning levels the chosen model accepts, and hides the settings that model can't receive.
A response budget is held to the model's known output cap. If you switch to a more limited model, LIA sends the smaller of the two numbers and says so.
Deep reasoning with too small a response budget is refused when you save: the reasoning would take up all the room and the answer would arrive empty.

What each model can do (tools, images, structured output, caps) comes from a catalogue maintained from public registries, and each row says where its values come from: a default nobody has checked, an imported value, or a value confirmed by a human. A model is only deactivated if the retirement date announced by its provider has passed and no task uses it anymore.

Cost, task by task

This breakdown allows fine-grained optimization. For example, sorting requests runs on a small, cheap model, the planner on a pricier but more reliable model, memory extraction on a free local model. Prices live in a tariff catalogue that also knows the off-peak hours of the providers that offer them: each call is counted at the rate of its moment. Each call keeps the model actually used and the parameters sent, and the dashboards let you compare tasks with one another.

Two ceilings for spending

Each account can have its own limits, in tokens, messages and cost, per monthly cycle or in total. But adding up accounts doesn't cap an instance. So the operator can set a daily instance budget, which the administrator can tighten from the interface but not widen: the smaller of the two values applies.

The two ceilings don't react the same way to an outage. If the database doesn't answer, an account limit lets one message too many through. An unknown instance spend, on the other hand, blocks, because the worst case on that side is the whole budget. The refusal says what's going on: an instance pause, with the time it lifts. So you don't think you've used up your own quota. In the background, a refused task is recorded as skipped, which saves you from hunting for a fault that doesn't exist.

The limits

A change applies to the next operations: an operation already under way may keep the configuration it started with.
A catalogue price is a reference. The real bill is still the provider's, which sometimes applies rules LIA can't express, like a higher rate beyond a certain request size.
Some small decisions, like classifying an email, can be handed to a specialized decision model. Each use has its own switch, off by default. When in doubt, LIA goes back to its usual path, and such a decision doesn't authorize any action on its own.