[FEATURE]: @agent:provider/model syntax to override subagent model on the fly #7988

Open
opened 2026-02-16 18:08:51 -05:00 by yindo · 2 comments
Owner

Originally created by @adambiggs on GitHub (Jan 29, 2026).

Originally assigned to: @thdxr on GitHub.

Feature hasn't been suggested before.

  • I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

I’d like OpenCode to support an explicit per-subtask model override when invoking subagents, via @agent:provider/model syntax (example: @explore:openai/gpt-5.2).

What I want to add:

  • Allow users to specify the model for a specific subagent invocation inline, without changing global defaults.
  • Ideally this is supported anywhere @agent invocations are supported (at least TUI first), with autocomplete for available providers/models.
  • The chosen model should be stored on the message/subtask metadata so it’s visible/auditable and can be surfaced in the UI.

Benefits:

  • Lets users pick a faster/cheaper model for simple subtasks and a stronger model for harder ones, per call.
  • Avoids needing multiple nearly-identical agents just to switch models.
  • Makes model selection explicit and reproducible when reviewing a session history.
Originally created by @adambiggs on GitHub (Jan 29, 2026). Originally assigned to: @thdxr on GitHub. ### Feature hasn't been suggested before. - [x] I have verified this feature I'm about to request hasn't been suggested before. ### Describe the enhancement you want to request I’d like OpenCode to support an explicit per-subtask model override when invoking subagents, via `@agent:provider/model` syntax (example: `@explore:openai/gpt-5.2`). **What I want to add:** - Allow users to specify the model for a specific subagent invocation inline, without changing global defaults. - Ideally this is supported anywhere `@agent` invocations are supported (at least TUI first), with autocomplete for available providers/models. - The chosen model should be stored on the message/subtask metadata so it’s visible/auditable and can be surfaced in the UI. **Benefits:** - Lets users pick a faster/cheaper model for simple subtasks and a stronger model for harder ones, per call. - Avoids needing multiple nearly-identical agents just to switch models. - Makes model selection explicit and reproducible when reviewing a session history.
yindo added the discussion label 2026-02-16 18:08:51 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 29, 2026):

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

  • #6651: Dynamic model selection for subagents via Task tool (proposes model_tier parameter with global/agent-level mappings)
  • #7713: Commands Model Variant Specification (adding variant field to commands for per-command model overrides)
  • #8278: Tool that lets the model switch models (automation of model picking with instructions)

These issues all address the core need for per-task/per-command model selection without changing global defaults. The proposed @agent:provider/model syntax in this issue provides an alternative approach to the tiered model system proposed in #6651.

Feel free to ignore if this specific syntax approach addresses a gap not covered by those issues.

@github-actions[bot] commented on GitHub (Jan 29, 2026): This issue might be a duplicate of existing issues. Please check: - #6651: Dynamic model selection for subagents via Task tool (proposes model_tier parameter with global/agent-level mappings) - #7713: Commands Model Variant Specification (adding variant field to commands for per-command model overrides) - #8278: Tool that lets the model switch models (automation of model picking with instructions) These issues all address the core need for per-task/per-command model selection without changing global defaults. The proposed @agent:provider/model syntax in this issue provides an alternative approach to the tiered model system proposed in #6651. Feel free to ignore if this specific syntax approach addresses a gap not covered by those issues.
Author
Owner

@farukg commented on GitHub (Feb 16, 2026):

Love this idea. Related use case that goes a step further: shell-specialist → summarizer pipeline.

I want to delegate shell command execution (fd, rg, eza pipelines) to a cheap code-specialist model (opencode/grok-code), then have the main expensive model (Opus/GPT-5) interpret and summarize the raw results. Today I achieve this with a custom shell-exec subagent pinned to a specific model, but the @agent:provider/model syntax would make ad-hoc overrides much more ergonomic — especially when I want to temporarily test whether a different model handles a specific subtask better, without editing agent config files.

@farukg commented on GitHub (Feb 16, 2026): Love this idea. Related use case that goes a step further: **shell-specialist → summarizer pipeline**. I want to delegate shell command execution (fd, rg, eza pipelines) to a cheap code-specialist model (`opencode/grok-code`), then have the main expensive model (Opus/GPT-5) interpret and summarize the raw results. Today I achieve this with a custom `shell-exec` subagent pinned to a specific model, but the `@agent:provider/model` syntax would make ad-hoc overrides much more ergonomic — especially when I want to temporarily test whether a different model handles a specific subtask better, without editing agent config files.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7988