Same-model agents do not preserve agent-local variant at runtime

[daifeiya]

Description

When multiple agents share the same model but configure different variant values, the effective runtime variant does not match the agent-local config.

In my setup, I configured:

• dubhe-orch → lumenmodel/gpt-5.4 + low
• build → lumenmodel/gpt-5.4 + medium

But exported sessions/messages and local runtime DB records show other values (especially high) instead. This suggests the problem is not only UI-related: the runtime effective variant itself appears wrong.

opencode agent list also does not expose model/variant, which makes this harder to detect.

Plugins

No response

OpenCode version

OpenCode Terminal 1.15.0

Steps to reproduce

Minimal repro config

{
  "agent": {
    "dubhe-orch": {
      "model": "lumenmodel/gpt-5.4",
      "variant": "low"
    },
    "build": {
      "model": "lumenmodel/gpt-5.4",
      "variant": "medium"
    },
    "dubhe-arc": {
      "model": "lumenmodel/gpt-5.4",
      "variant": "high"
    }
  }
}

These agents intentionally share the same model but use different variants.

Expected
The runtime should preserve the per-agent configured variant:

dubhe-orch → low
build → medium
dubhe-arc → high
Actual
Runtime records do not match config:

dubhe-orch (configured low) shows high, max, or default
build (configured medium) shows high or default
I did not observe the configured low / medium values for the tested agents in runtime data.

This suggests the effective variant may be bleeding across same-model agents, being cached at model level, or being overwritten during session/message creation.

Evidence
Config truth: my config defines different variants for same-model agents, e.g. dubhe-orch = lumenmodel/gpt-5.4 + low and build = lumenmodel/gpt-5.4 + medium.
Exported runtime truth: opencode export <session-id> shows those sessions/messages resolving to other values (especially high) instead of the configured low / medium.
Local runtime DB truth: records in C:\Users\daifeiya\.local\share\opencode\opencode.db also show mismatched runtime values, and I did not observe the configured low / medium values for the tested agents.
So this does not appear to be only a display/UI bug.

Observability gap
opencode agent list does not show model or variant, so the CLI does not provide an easy way to confirm the effective runtime model/variant per agent.

Repro note
The issue is easiest to reproduce with at least 3 agents that share the same model but use different variants, for example:

agent A → lumenmodel/gpt-5.4 + low
agent B → lumenmodel/gpt-5.4 + medium
agent C → lumenmodel/gpt-5.4 + high
The runtime should preserve the per-agent variant, but in my local runtime artifacts it does not.

### Screenshot and/or share link

_No response_

### Operating System

windows11 23h2

### Terminal

Codenomad '0.16.0'

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Same provider/model with different variants #25248: Same provider/model with different variants — reports the same scenario of multiple agents sharing one model but configured with different variants
• subagent model variants are parsed but not applied at runtime in v1.4.0 #21632: Subagent model variants are parsed but not applied at runtime — directly describes variants not being applied at runtime
• Non deterministic behaviour of variants passed into agents in the opencode.json config #16034: Non-deterministic behaviour of variants passed into agents in opencode.json config — reports the same variant bleeding/override behaviour in agent config

If your issue is distinct, please add a comment clarifying how it differs from the above.

[daifeiya]

Thanks — after checking the linked issues, I agree this is very likely part of the same bug family, especially #25248.

What I think this report adds is stronger runtime-level evidence that this is not only a UI/display problem:

• my config defines different agent-local variants for same-model agents
• opencode export <session-id> shows the effective runtime variant resolving to other values
• local SQLite runtime records also show the configured values are not the ones actually used

So if this issue is closed as a duplicate, I think the most relevant target is #25248, with #21632 and #16034 as related historical variants of the same underlying problem.

In particular, my local evidence suggests the effective runtime variant itself is wrong, not just the visible CLI state.