Add default variant config per agent

[opencode-agent]

All changes are in place. Let me create a summary of the implementation:

Summary

I've implemented the default variant configuration per agent feature as specified in the issue. Here are the changes made:

Files Modified

1. packages/opencode/src/config/config.ts (lines 481, 497):

   • Added variant field to Config.Agent schema with description
   • Added variant to knownKeys set for proper parsing

2. packages/opencode/src/agent/agent.ts (lines 37, 194):

   • Added variant field to Agent.Info type
   • Added parsing logic to read variant from config during agent state initialization

3. packages/opencode/src/session/llm.ts (lines 86-87):

   • Updated variant resolution to use input.user.variant ?? input.agent.variant as the variant key
   • This implements the priority order: explicit user selection > agent's configured default > none

4. packages/opencode/src/tool/task.ts (line 135):

   • Pass agent.variant to subagent sessions so they use their own configured variant

Usage

Users can now configure a default variant for each agent:

{
  "agent": {
    "build": {
      "model": "anthropic/claude-sonnet-4-5-thinking",
      "variant": "high"
    },
    "explore": {
      "model": "google/gemini-3-flash",
      "variant": "low"
    }
  }
}

Variant Priority Order

1. Explicit user selection (--variant flag or ctrl+t)
2. Agent's configured default variant (agent.variant)
3. None (model's base behavior)

Subagent Behavior

Subagents now use their own configured agent.variant rather than inheriting the parent's --variant override, respecting explicit per-agent configuration.

Closes #7138

opencode session  |  github run

[rekram1-node]

/oc I think this requires changes in tui too?

[opencode-agent]

Now I have a full picture. Here's my analysis:

Does this PR require TUI changes?

Short answer: No, the TUI doesn't need changes for the basic functionality to work, but there could be a UX enhancement.

Here's why:

1. Backend side works correctly: The llm.ts already uses input.user.variant ?? input.agent.variant, so if no user variant is selected, the agent's configured default variant will be used automatically.

2. Current TUI behavior:

   • local.model.variant.current() returns the user-selected variant (stored per model in model.json)
   • When displaying the variant in the prompt UI, it only shows if local.model.variant.current() returns a value
   • If the user hasn't selected a variant, it shows nothing (even if the agent has a default configured)

3. Potential UX enhancement (optional): The TUI could optionally show the agent's default variant in the UI when no user variant is selected. However, this is purely cosmetic since:

   • The backend already applies the agent's default variant correctly
   • The current behavior (showing nothing when user hasn't explicitly selected) is arguably correct since it represents what the user has chosen, not what will be applied

4. What the PR already handles correctly:

   • Subagents use their own configured agent.variant (in task.ts)
   • The user.variant ?? agent.variant priority order works correctly

Conclusion: The TUI doesn't strictly require changes. The agent's default variant will be used correctly by the backend even without TUI changes. However, if you wanted to show the agent's default variant in the UI (as a visual indicator), that would be an optional UX enhancement, not a requirement.

opencode session  |  github run

[CasualDeveloper]

Good implementation! I noticed one potential gap:

Missing prompt.ts Change

The PR modifies llm.ts to use input.agent.variant as fallback, but prompt.ts also needs to be updated to store the resolved variant on the user message info.

In packages/opencode/src/session/prompt.ts around line 808, the current code is:

variant: input.variant,

This should be:

variant: input.variant ?? agent.variant,

Without this change, when input.variant is undefined (no explicit user selection), the agent's default variant won't be stored on the message info. The llm.ts change handles the LLM call correctly, but the message metadata won't reflect the actual variant used.

---

Also, consider adding a clarifying comment in task.ts explaining the design choice for subagent variant handling:

// Use subagent's configured variant (respects explicit per-agent config).
// Parent's --variant override does NOT cascade to subagents intentionally:
// if user configured oracle with variant: "high", that intent should be honored
// even when parent session uses --variant low.
variant: agent.variant,

This documents why subagents don't inherit the parent's variant selection.

[CasualDeveloper]

I've also opened PR #7156 with an alternative implementation that includes:

• The prompt.ts change (stores resolved variant in message metadata)
• TUI support (same as this PR)
• Desktop/web app support (additional)

Both PRs are viable - this one is simpler (9 files), #7156 is more complete (14 files with desktop + message metadata). Happy to defer to maintainer preference on which to merge!

[terwey]

Quick chime in, if this is the wrong place for the discussion then direct me to where I should.

Does this also allow an Agent that calls a sub-agent via Task to pass a variant? One of the use cases I see is that the default model is not set (because I often switch between Providers) but you have e.g. Opus or Sonnet do the planning with maximum thinking but the Agent that will receive the sub-tasks should not have thinking enabled at all (or lower).

Currently my only work-around is duplicating agents and setting a fixed model there.