Repository navigation
[FEATURE]: Runtime model override for task tool subagents #17595
Description
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
Problem: Subagents always run on the model configured at startup. There's no way for an orchestrating agent to switch models at runtime based on context.
Use cases:
- Adaptive review loop — orchestrator runs code review on haiku. If the same errors repeat twice, it escalates to sonnet or opus for a more thorough review (fewer false positives, better understanding of context).
- Variable-complexity reports — same report-generating subagent, but the orchestrator picks the model based on report difficulty. Simple report → cheap model. Complex/long report → stronger model. The agent definition stays the same.
Proposed approach: Add a model parameter to the task tool ("provider/model-id" format). Gate it with a new model_override permission (default: deny) so users control which models agents can switch to. Supports wildcards ("anthropic/*": "allow") and specific models.
Why permission-gated: Without it, a prompt injection could escalate to an expensive model, or an agent could pick models randomly. The permission system lets users whitelist exactly what's allowed.
Not a duplicate of #17570: That issue is about static config — users assign models to subagents upfront in config/UI. This is about runtime decisions — the orchestrating agent picks the model dynamically based on what's happening during execution (errors, complexity, retries). They're complementary features.
Note: PR #17577 with an implementation already exists — apologies for the reversed order. Opening this issue retroactively for proper tracking and design discussion.
Activity
github-actions commentedon Mar 15, 2026
This issue might be a duplicate of existing issues. Please check:
@agent:provider/modelsyntax) — same goal of switching models at runtime without static configIf your request adds meaningfully different scope (e.g., the permission-gating mechanism or the specific runtime-escalation use cases), please clarify how it differs so maintainers can decide whether to merge or keep separate.
feat(opencode): add model parameter to task tool for subagent model o…
funkybooboo commentedon May 9, 2026
I've opened PR #26535 implementing this feature with a minimal, permission-gated approach:
modelparameter to the task tool (provider/modelformat)model_overridepermission denied by default -- users opt in via config (e.g."model_override": { "anthropic/*": "allow" })provider/modelformat with clear error messagesparams.model->agent.model-> parent session modelThis is similar to #18528 but uses Effect Schema instead of zod and inlines the parsing to avoid importing the heavy Provider module. Compared to #11217 (UI-driven
@agent:provider/model) and #11377 (tier abstraction), this takes the simplest direct approach with the security gate from the original issue.github-actions commentedon Jul 9, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.
Doble-K commentedon Aug 7, 2026
I ran into this issue while building an orchestration framework on top of OpenCode and wanted to share what I found after tracing the implementation.
Initially I assumed this was a bug because I was requesting a Medium model for a delegated Worker task, but the Worker was executing with MiMo.
After inspecting the framework, I realized the behavior was actually expected:
SubtaskPart.modelis supported.modelparameter, so there is no supported per-invocation override.The real problem in my framework turned out to be that the Director was still delegating to the generic
workeralias instead ofworker-medium. Sinceworkerwas configured with MiMo, the runtime was behaving correctly.Changing the delegation to explicit capability-based agents (
worker-small,worker-medium,worker-large) solved the problem without any changes to OpenCode.So I can confirm that this is not a runtime bug—the current implementation is internally consistent.
Although I still think a runtime model override could simplify orchestration frameworks by reducing duplicated agent definitions, the current capability-based approach works well once the routing is configured correctly.
Hopefully this investigation helps anyone who arrives here after assuming the model selection is being ignored, as I initially did.
RajatGarga commentedon Aug 22, 2026
I have hit a stone wall on this. I want to use opencode as my primary harness and hoped that this feature would ship but all I see is dead discussions closed automatically. Some with PRs as well