[FEATURE]: Task tool should support `model` parameter for cost-optimized multi-agent orchestration

[danielpsf-grover]

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

1. params.model (explicit per-invocation override)
2. Agent config model (from opencode.json)
3. Parent session model (current behavior)

Why this matters

1. 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.

2. 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.

3. 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:compliance label 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.

[github-actions]

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

• [FEATURE]: Dynamic model selection for subagents via Task tool #6651: Dynamic model selection for subagents via Task tool — same feature request with multiple proposed solutions
• [FEATURE]: Runtime model override for task tool subagents #17595: Runtime model override for task tool subagents — same feature (runtime model override via Task tool parameter)

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]

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:

Plan is ready.

Choose an execution mode:
1. Execute with the current model
2. Execute with Mix Code Mode

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.model field 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:

1. The mode is explicitly selected by the user after Plan mode. Existing execution remains the default.
2. The coordinator keeps responsibility for the goal, delegation, review, and final response.
3. Workers can only use configured providers/models and receive bounded tasks derived from the approved plan.
4. Every worker result returns to the coordinator before it is accepted.
5. Start with one worker at a time. Automatic classification, Best-of-N, and cost dashboards can come later.

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.