Managing models 

Adding a model manually 

1. Navigate to AI > Setup > Models.
2. Click Add Model.

3. Fill in the required fields:

   Identifier

   Unique slug (e.g., gpt-5, claude-sonnet).

   Name

   Display name (e.g., GPT-5 (128K)).

   Provider

   Select the parent provider.

   Model ID

   The API model identifier as the provider expects it (e.g., gpt-5.3-instant, claude-sonnet-4-6).

4. Optionally set capabilities (chat, completion, embeddings, vision, streaming, tools), context length, max output tokens, and pricing.
5. Click Save.

Fetching models from a provider 

Use Fetch Models beside the Model ID field in a model edit form to browse the selected provider's catalogue:

1. Save the provider and select it in the model form.
2. Click Fetch Models and choose an entry from the dropdown. The choice sets the API model identifier and applies capability, token-limit and pricing suggestions where available. Where discovery cannot say what a model lacks (an OpenAI or Gemini chat model the built-in catalogue does not list yet, every Groq model, an Ollama model whose capabilities the host did not report) and the record already ticks that kind of model, the other ticked capabilities are kept as they are. Check them against the provider's documentation.
3. Review the fields in the current form, then click Save to persist the model record.

If live discovery fails and a built-in catalogue is available, the dropdown shows that catalogue with a warning. Review those suggestions against the provider before relying on them.

Which capabilities the provider actually confirmed 

A capability badge in the model list says that the model has the capability, not who said so. Those are different claims, and the list separates them.

A grey badge means a live answer from the provider's own model endpoint declared that capability, and the row says when. A yellow badge with a question mark means nobody confirmed it: either an administrator ticked it by hand, or it came from the static model catalogue bundled with the extension. Hover the badge for the reason.

Expect the yellow badge for OpenAI, Anthropic, Groq and the Gemini models the extension knows by name, even against a reachable API. Those model endpoints list model ids and no capabilities, so the tokens come from the bundled catalogue on a live run exactly as on an unreachable one, and the badge says so rather than borrowing the provider's authority. Mistral, OpenRouter, Ollama and Gemini releases newer than this extension do report capabilities per model, and those confirm to grey.

Use the Confirm capabilities row action to ask the provider. It runs the same discovery the wizard uses, records what came back, and refreshes the confirmation date. A model the provider does not list is reported as such — that is not a confirmation, so nothing is stored.

Confirming never edits what you declared. A capability you ticked that the provider does not advertise stays on the model and simply stops borrowing the provider's authority for it. That matters most for a model created from the bundled catalogue: nothing about it was ever checked against the live API until you confirm it.

The three underlying fields — what was confirmed, when, and whether the answer was live or from the catalogue — are also visible read-only on the Capabilities tab of the model record.

Routing does not use this. Eligibility below still reads the declared capabilities, confirmed or not: making it depend on confirmation would silently drop every model an administrator declared by hand.

Reasoning models the extension does not know yet 

Whether a model is a reasoning model, which efforts it accepts and where its tool calls go are bundled with the extension for the OpenAI models it knows. A newer model works without a release once its record says so: set Reasoning model, Accepted reasoning efforts and Tool calls go through on the Capabilities tab. A value set there wins over every other source; see Reasoning profile for the order.

Confirm capabilities also records what discovery stated:

• For an OpenRouter provider, OpenRouter's model list states per model whether it reasons and which efforts it accepts. Both are stored with the source discovery.
• For an OpenAI provider, OpenAI's model list states nothing. With discovery.thirdPartyReasoningCatalog switched on, the reasoning flag is read from OpenRouter's public list for openai/<model id> and stored with the source third_party_catalog. The effort scale is never taken from it, because it was measured to differ from what OpenAI accepts. The flag alone does not move tool calls to Responses: for a model outside the families the extension knows, set Tool calls go through and the efforts yourself when the model needs them.

A run that states nothing for the model stores nothing, so an earlier answer stays and nothing turns into "no". Changing the record's model id or its provider forgets the discovered profile, because it was measured for the old one; the fields you set yourself stay.

A model you mark as a reasoning model gets an output budget of at least 16,000 tokens, never more than the record's Max Output Tokens when that is set.

The profile applies to models served by the OpenAI adapter: OpenAI, Azure OpenAI, Together, Fireworks, Perplexity and custom endpoints. That adapter sends by it, the configuration form offers no temperature for a reasoning model, and the model list shows below the capabilities whether the record resolves to a reasoning model and which source decided it.

OpenRouter and Groq have their own adapters, which send temperature whatever the profile says. For their models the profile is not applied: a discovered OpenRouter profile is shown on the record, read-only, and changes neither the form nor the request. OpenRouter's "reasoning" means the model can produce reasoning tokens, not that it refuses a temperature.

Which model a criteria-mode configuration picks 

A configuration set to Dynamic (Criteria) names no model. One is chosen per call from the models that are active, in two steps that never mix.

Eligibility is a hard yes or no. A model is considered only if it declares every capability the criteria require, uses a permitted adapter type, meets the minimum context length, stays within the cost ceiling, and — for the operation being run — does not declare capabilities that exclude it. A model refused here cannot come back: nothing about its speed, price or quality is even looked at.

Ranking orders what is left. The provider Priority you set decides first, always. Below it, the extension configuration option Routing policy (category routing) chooses what else counts:

Provider priority

The default. Nothing beyond your priority, the default-model flag and the sorting order, plus cost where the criteria set prefer lowest cost. This is what the extension has always done.

Balanced, Quality, Economy

Add measured signals — evaluation quality scores and recent provider health — weighted differently. Economy also weighs cost when the criteria did not ask for it.

With routing.callHistory switched on in the extension configuration, the measured modes also rank by each model's recent calls of the same operation: how long they took, and what they cost per call. See Why this model?.

The measured modes are opt-in on purpose: they change which model serves a call, so an upgrade never switches them on for you. Two rules make them safe to try. Your provider priority is never overruled by a measurement — a priority is an instruction, a score is evidence. And a model nobody has measured is not punished for it: an absent signal is skipped, not counted as zero.

If a criteria-mode configuration selects nothing, the cause is usually that every matching model declares it cannot serve that operation. The extension says so explicitly rather than letting the provider fail with an opaque error.