Map a plugin's models

For: tenant administrators and cost owners.

Preview the agents a mapping would reach before saving it. A mapping changes new jobs while preserving the installed plugin.

Map a plugin's models

A mapping rule sends what agents ask for to another model without changing the plugin: its signature, its pins and its updates stay as they are. A rule has a source, what an agent's definition asks for:

• an alias, such as default (an agent's model.use);
• a <provider>/<model>, such as anthropic/claude-sonnet-5-5 (an agent's model.primary);
• <provider>/*, every model of a provider an agent names.

and a target: an alias or a <provider>/<model>, or, for a <provider>/* source, another provider whose model names a naming preset translates. A rule is for the whole tenant, one plugin (--plugin) or one agent of a plugin (--plugin and --agent):

oz0 model map set default smart --plugin web                            # the web plugin's agents on smart
oz0 model map set 'anthropic/*' eu-gw --preset same-names                  # every agent on Anthropic's models, through your own gateway
oz0 model map set 'anthropic/*' foundry --preset anthropic-foundry --plugin pr-reviewer --agent oz0-pr-reviewer
oz0 model map set 'openai/*' azure-openai --preset openai-azure \
  --name gpt-6.1-sol=sol-prod --name gpt-6-luna=luna-prod                # Azure's deployment names are yours
oz0 model map list
oz0 model map delete mr-7k2q9v4c1mxw3bda

The most specific rule wins: an agent's over its plugin's over the tenant's, then an exact source over <provider>/*. A rule is applied once: its target is resolved as an alias or a model, and no other rule is applied to the result, so rules never chain or loop. A source matches what the agent's definition asks for, never the models an alias stands for: to move an alias's models, change the alias (oz0 model alias set).

A rule is checked when it is set, against every agent of the tenant's plugins it reaches: what each needs (needs, min_context), the model API its harness speaks, its data: setting and the tenant's data rules. A rule that reaches no agent, or does not fit one it reaches, is refused, and the refusal names the agent and why; nothing forces it.

--dry-run shows whom a rule would reach and what each would get, and stores nothing. A target that names its model in the call's path (Bedrock's InvokeModel, Vertex AI's rawPredict) fits only an agent on a harness that calls it that way; the runtime's own model clients name the model in the call's body.

Rules apply to jobs that start after the change. When a job starts, the edge resolves its agent's model through the rules, and the job keeps that model, and the rule's ID, in its history: a running job keeps its model, and a replay runs on the same one. The job's trace gets the finding model_override (info), which names the rule and the model it gave.

A rule that no longer fits when a job starts (a provider removed, a data rule tightened, the target alias deleted) fails the job before any model call, naming the rule; it never falls back to the agent's own model, which could send data where you chose not to. oz0 model map list and the Models page's Mapping rules tab show each rule's agents and whether it still fits.

A best-of's candidates, a comparison's arms and a cascade's later steps run on the models they name, without rules: that is what lets you compare the old model with the new one. A harness agent's session runs on the model a rule chose for its alias or its provider record's model, on JSON-lines and ACP harnesses alike; its built-in model.primary (anthropic/..., openai/...) is the harness's own and runs as written.

Naming presets

A <provider>/* rule to another provider needs the target's name for each model. A naming preset gives them where a vendor's naming is systematic; oz0 model map presets lists them:

A model the preset does not name is not guessed: an agent that names one does not fit the rule. --name <model>=<name> names it yourself, before the preset's names. Azure's deployment names are your own, so its preset only proposes them: the rule keeps the list. The presets' names are data that follows the vendors' naming, so check a new model's ID in your cloud's console when a preset does not have it yet. Where your data may go is still your data rules' decision: a target in another region passes only if they allow it.

Verified plugins keep their status

A mapping changes nothing in the plugin, so a verified plugin stays verified. Its evals ran on its author's model, though, so oz0 plugin show, the plugin's row on the plugins page and its agents' capability cards say verified; model changed by the tenant, and offer two ways to see how it does on the new model: its evals on your models, with an eval routine, and a paired comparison of the old and the new model:

oz0 plugin show web
oz0 compare-savings start oz0-web-research --baseline-model anthropic/claude-sonnet-5-5 --variant-model eu-gw/claude-sonnet-5-5 \
  --budget 2 --dry-run

Rules need the models.manage permission, as aliases do; each change is in the audit log as model.map.set or model.map.delete, with the agents it reached.

A judge and the agent it judges

A judge (an outcome check's, a best-of's, a sampled one) should not resolve to the model of the agent it judges: a model asked whether its own answer is good tends to say yes. Give a judge an alias of its own and map it to another model than the agents' aliases.

A mapping rule reaches agents, never judges, so a rule can move an agent onto its judge's model without anyone touching the judge: the job then refuses a judge that gates its answer before the judge is asked, and a sampled judge judges on with a judge_same_model finding (A judge on another model).

Two records are one model to this check when they name the same model behind the same endpoint, or one is a pool with that endpoint among its members.