Repository navigation
[FEATURE]: Task tool should support model parameter for cost-optimized multi-agent orchestration #26925
Description
Problem
When using OpenCode as an orchestrator that launches multiple sub-agents via the Task tool, there is no way to specify which model each sub-agent should use. The subagent_type parameter only accepts general or explore — there is no model parameter.
This means every sub-agent runs on the same (expensive) model as the orchestrator, even when the sub-agent's task is simple data gathering that a cheaper model could handle perfectly.
Real-world example (anonymized)
I asked OpenCode (using GitHub Copilot as a provider) to audit Kubernetes resource usage across multiple clusters. The orchestrator launched 5 sub-agents in parallel:
| Sub-agent Task | Complexity | Ideal Model | Actual Model |
|---|---|---|---|
| Call Datadog MCP tools, collect metrics | LOW — tool calls only | cheap (e.g. gpt-4o-mini, sonnet) | claude-opus-4.6 |
| Call Grafana MCP tools, collect metrics | LOW — tool calls only | cheap | claude-opus-4.6 |
| Run kubectl commands, parse JSON | LOW — shell + parse | cheap | claude-opus-4.6 |
| Search GitHub files, read YAML | LOW — file reads | cheap | claude-opus-4.6 |
| Cross-validate 3 datasets, write analysis report with 18 action specs | HIGH — reasoning + synthesis | expensive (opus) | claude-opus-4.6 |
4 out of 5 agents were doing simple tool-calling work that any cheap model handles well. Only the final analysis agent needed heavy reasoning. But all 5 burned premium tokens at the orchestrator's model tier.
Proposed Solution
Add an optional model parameter to the Task tool:
{
description: "Launch a new agent to handle complex, multistep tasks autonomously.",
parameters: {
// existing params...
subagent_type: { type: "string", enum: ["general", "explore"] },
model: {
type: "string",
description: "Optional model override for the sub-agent (e.g. 'github-copilot/gpt-4o-mini', 'anthropic/claude-sonnet-4'). If omitted, inherits the orchestrator's model."
}
}
}Model resolution priority
params.model(explicit per-invocation override)- Agent config model (from
opencode.json) - Parent session model (current behavior)
Why this matters
-
Cost optimization — Orchestrator patterns are becoming standard (plan → delegate → synthesize). Data-gathering agents don't need frontier models. A 5-agent workflow could cost 80% less by routing 4 agents to cheap models.
-
Enables "double-tap" validation — Users want to launch Agent A with Model X, then Agent B with Model Y on the same task to cross-validate. Currently impossible without separate agent configs.
-
The orchestrator knows best — The orchestrator agent understands each sub-task's complexity and should be able to make model routing decisions dynamically, not just at config time.
Prior art / related issues
- Subagent models are ignored when using GitHub Copilot provider — All Premium Requests billed to orchestrator model (Claude Opus 4.6) #20859 — Subagent models ignored when using GitHub Copilot provider (billing-level routing bug)
- feat(opencode): add model parameter to task tool for subagent model override #26536 — Same feature proposed, auto-closed after 2 hours with
needs:compliancelabel without discussion - [FEATURE]: Knowledge Harness of SOTA models as blueprint for cheap worker models #23382 — Knowledge harness of SOTA models as blueprint for cheap workers (related concept)
#26536 proposed exactly this but was closed without substantive review. This issue provides a concrete real-world use case demonstrating the cost impact.
Alternatives considered
| Alternative | Why insufficient |
|---|---|
Create separate agent configs per model in opencode.json |
Static — orchestrator can't choose model based on task complexity at runtime |
| Just use cheap model for everything | Analysis/synthesis tasks need frontier models for quality |
| Manual multi-session workflow | Defeats purpose of autonomous orchestration |
Impact
For users running multi-agent workflows (DevOps audits, codebase migrations, parallel code reviews), this could reduce costs by 50-80% while maintaining quality where it matters.
Activity
github-actions commentedon May 11, 2026
This issue might be a duplicate of existing issues. Please check:
Both issues are open and cover the same core request: allowing the orchestrating agent to specify a model when invoking a subagent via the Task tool. Please check if your use case is already covered or if you can contribute to one of those existing discussions instead of opening a new issue.
questionjie-max commentedon Jul 5, 2026
I would like to suggest a small harness-level workflow on top of the per-Task model override proposed here. Working title: Mix Code Mode.
The idea is not automatic routing for every prompt. It starts only after a plan has been produced and approved:
In Mix Code Mode, the current planning model remains the coordinator. It decomposes and dispatches the approved plan to one or more user-configured worker models, such as GLM, Qwen, Kimi, or DeepSeek. Workers perform the bounded implementation tasks, then return their results to the coordinator for review. The coordinator can accept the result, request a revision, assign another worker, or take over a difficult step.
This would turn the proposed
Task.modelfield into a coherent plan-to-execution harness rather than only a low-level override:{ "mixCode": { "coordinator": "current", "workers": [ "zai/glm", "alibaba/qwen", "moonshot/kimi" ] } }Suggested first version:
The key distinction is that this is not simply "switch to a cheaper model." It is heterogeneous execution: a strong model plans and verifies, while lower-cost or specialized models implement the plan.
Acceptance test: create a plan with model A, choose Mix Code Mode, execute a plan step with configured model B, return the result to model A for review, and preserve existing behavior when the mode is not selected.
I originally explored this as a standalone prototype, but it may be more useful as a native execution mode in an established harness such as OpenCode. If the direction is interesting, I would be glad to help refine the UX and test cases.
github-actions commentedon Sep 4, 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.