[FEATURE]: opencode could automatically use different models based on task type

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

What feature would you like to see?

Leading agentic coding tools enable configurable model selection for different task types executed by the agent; opencode would benefit from adopting a similar approach.

Enable configuration of defaults via environment variables:
- model_reasoning: the model for complex reasoning and architecture decisions (e.g. anthropic/claude-opus-4-20250514")
- model_execution: the model for code generation and implementation (e.g. anthropic/claude-sonnet-4-20250514)
- model_tool: the model for tool execution or background functionality (e.g. anthropic/claude-haiku-4-20250514)

By default, in plan mode, opencode would automatically use model_reasoning for complex reasoning and architecture decisions and use model_tool for efficient execution of tools (find, grep, etc.). By delegating tool execution to the more efficient model and reasoning to the stronger model, we get the best of all worlds for efficient, speed and cost.

Support hybrid settings (e.g., plan), which use a stronger model (model_reasoning) for planning (still using model_tool when appropriate), then switch to a more efficient model (model_execution) for execution (still using model_tool when appropriate).

So in ~/.config/opencode/config.json:

{
  "model": "anthropic/claude-opus-4-20250514",
  "model_reasoning": "anthropic/claude-opus-4-20250514",
  "model_execution": "anthropic/claude-sonnet-4-20250514",
  "model_tool": "anthropic/claude-haiku-4-20250514"
}

or for hybrid mode:

{
  "model": "codeplan",
  "model_reasoning": "anthropic/claude-opus-4-20250514",
  "model_execution": "anthropic/claude-sonnet-4-20250514",
  "model_tool": "anthropic/claude-haiku-4-20250514"
}

Similar issues:

Related issues:

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 - discusses model tier configuration approach
Subtask commands do not inherit model #6928: Subtask commands do not inherit model - related to model inheritance in subtasks
[FEATURE] Support default variant configuration per agent (#7156) #7138: Support default variant configuration per agent - agent-level model configuration

Feel free to ignore if none of these address your specific case.

Wouldn't that cause you to constantly be feeding different models your entire context over and over as it switches?

You can do something very similar already with sub-agents. Set up your primary agent as an orchestrator to assign tasks to the most appropriate sub-agent. Configure the sub-agent to use whatever model and settings you wish.

Add an actual scenario:
Using GLM-5.0 for everything feels like overkill — we’re basically paying “architect prices” to generate boilerplate, simple logic, and repetitive tests, which wastes tokens and hits rate limits fast. It probably makes more sense to split the workflow: let 5.0 handle the hard thinking (design, core logic, interfaces, overall structure) and push the bulk execution work to 4.7 (filling code, tests, repetitive stuff). In short, 5.0 thinks, 4.7 grinds — same architecture quality, but cheaper and faster overall.

I’ve recently been thinking about something very similar, and I wanted to implement it via a plugin with the following goals:

Scenario Example

When using OpenCode to build a full project, the workflow often includes multiple stages:

Discuss with AI, retrieve relevant documentation, and produce an implementation plan.
Build the project from 0 to 1 with only core functionality.
Run automated tests.
Make small code edits and debugging fixes.
Package/build the project for delivery.
Improve UI design and visual polish.
Add new features.
Write or update project documentation.

These stages are different in complexity and capability requirements, so the best model can vary by stage.
With auto-routing, each stage can be sent to its most suitable model. Simpler steps can be routed to cheaper/faster models, while harder steps can use stronger reasoning/coding models, reducing token cost and speeding up overall development.

What I Want to Build

A native-feeling automatic model switching workflow for OpenCode, where routing is decided by:

Current session mode (plan / build)
Current user instruction
A configurable meta model that classifies task type first, then routes to the best model

Proposed task types:

reasoning: requirement clarification, complex project planning, code/plan validation, documentation writing.
terminal_command: automated test execution, local project exploration, code/file reading, environment setup, package/build workflows.
agentic: large-scale web or repository search, heavy tool usage, MCP-driven workflows.
coding: core work is implementing or modifying code.
multimodal: image/video-based requests and visual tasks such as frontend UI design from screenshots or mockups.
hybrid: substantial combination of multiple capabilities above, such as end-to-end 0-to-1 full-stack delivery.

Important rule: classification should use the primary workload, not minor side actions.
For example, if a task is mostly code implementation but includes one small web lookup, it should still be classified as coding, not agentic.

I also hoped to provide:

/auto: enable auto-routing in current session
/auto-config: configure the meta model
auto-switcher.json: explicit user-editable routing table
/auto-init: let users pick candidate models in CLI, then use the meta model to compare benchmark/latency evidence and generate routing recommendations

Plugin Limitations I Hit

Due to current plugin constraints, this is hard to implement cleanly:

The SDK is better at request transformation than true built-in command short-circuiting, so command behavior cannot be fully equivalent to native commands.
It’s difficult to fully extend the native model-selection TUI (for example, making auto a first-class model option with seamless UX).

This leads to workaround-heavy implementations with compromises in reliability and user experience.

My Conclusion

I now think implementing this directly in OpenCode core may be a better path.
If auto-routing is built as a first-class core feature, it can be integrated properly across:

command system
model-selection UI
session state handling
configuration lifecycle

That would likely deliver a much cleaner and more stable result than plugin-only approaches.

Note: I am not deeply familiar with OpenCode internals or the TypeScript stack yet. This proposal was discussed with AI and drafted with AI assistance, so it is for reference only and may need further review/discussion by experienced contributors.

I am finding ways to achieve the same thing, by routing all my models through LiteLLM
https://docs.litellm.ai/docs/proxy/auto_routing

But I do agree, it would be great if OpenCode handles this natively.

That said, following the path of https://github.com/malhashemi/opencode-skills, perhaps it would be best to create a plugin for this, then if it has traction, it could get absorbed into the core?

I came across https://github.com/marco-jardim/opencode-model-router and so far it seems to work good.

I'd like to take this on. Here's my approach:

How it works:

User sets model: "auto" in config (or types auto interactively)
A small classifier model (default opencode/gpt-5-nano, free) looks at the prompt and returns a complexity + task type score
A local routing function picks the best model from the available catalog or from a user-defined model_pool if they want to constrain choices
The classifier model is configurable, so users can swap in Ollama or any provider for offline use

Config surface:

"auto_model": {
  "classifier_model": "opencode/gpt-5-nano",  // can be ollama/llama3.2:3b etc
  "model_pool": ["anthropic/claude-haiku-4-5", "openai/gpt-5.2-codex"],  // optional constraint
  "preferred_provider": "cheap"  // cheap | fast | capable
}

Happy to start small and iterate based on feedback. Would a PR along these lines be welcome?

I'd like to take this on. Here's my approach:

How it works:

User sets model: "auto" in config (or types auto interactively)

A small classifier model (default opencode/gpt-5-nano, free) looks at the prompt and returns a complexity + task type score

A local routing function picks the best model from the available catalog or from a user-defined model_pool if they want to constrain choices

The classifier model is configurable, so users can swap in Ollama or any provider for offline use

Config surface:

"auto_model": {
"classifier_model": "opencode/gpt-5-nano", // can be ollama/llama3.2:3b etc
"model_pool": ["anthropic/claude-haiku-4-5", "openai/gpt-5.2-codex"], // optional constraint
"preferred_provider": "cheap" // cheap | fast | capable
}
Happy to start small and iterate based on feedback. Would a PR along these lines be welcome?

That looks great for an initial version. How is the preferred_model used? Or impacting anything?

I'd like to take this on. Here's my approach:
How it works:

User sets model: "auto" in config (or types auto interactively)

A small classifier model (default opencode/gpt-5-nano, free) looks at the prompt and returns a complexity + task type score

A local routing function picks the best model from the available catalog or from a user-defined model_pool if they want to constrain choices

The classifier model is configurable, so users can swap in Ollama or any provider for offline use

Config surface:
"auto_model": {
"classifier_model": "opencode/gpt-5-nano", // can be ollama/llama3.2:3b etc
"model_pool": ["anthropic/claude-haiku-4-5", "openai/gpt-5.2-codex"], // optional constraint
"preferred_provider": "cheap" // cheap | fast | capable
}
Happy to start small and iterate based on feedback. Would a PR along these lines be welcome?

That looks great for an initial version. How is the preferred_model used? Or impacting anything?

Aiden Cline said they are not interested in the feature at this time when i checked interest on discord. so respectable im not doing it. However, the preferred model cheap/fast/capable etc would just add a bonus to the final scoring.

Aiden Cline said they are not interested in the feature at this time when i checked interest on discord. so respectable im not doing it.

Was there a reason why there is no interest? The proposal seems logical and I don't see it being hard to POC this. This issue has been mentioned several times there is clear interest for it.

I really miss this, combining with with go models i would love to use better models for complex tasks, so that i can use my credits more efficient.

While we wait for core to support something like this, I've created a plugin that allows the parent model to specify what model to use in subagents.

You should be able to create your custom commands on top of that if you want more elaborate "routing".
Hope someone finds it useful!

Closing as a duplicate of #6651, which is now done. In OpenCode v2 the subagent tool takes an optional model (#49194), so the main agent can choose a model for each task. Agents can also set their own model in config.

Navigation Menu

Repository navigation

[FEATURE]: opencode could automatically use different models based on task type #8456

Feature hasn't been suggested before.

Describe the enhancement you want to request

What feature would you like to see?

Scenario Example

What I Want to Build

Plugin Limitations I Hit

My Conclusion

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[FEATURE]: opencode could automatically use different models based on task type #8456

Description

Feature hasn't been suggested before.

Describe the enhancement you want to request

What feature would you like to see?

Activity

github-actions commented on Jan 14, 2026

jhov94 commented on Jan 15, 2026

novahe commented on Feb 12, 2026

DarkIceField commented on Feb 17, 2026

Scenario Example

What I Want to Build

Plugin Limitations I Hit

My Conclusion

shahrin014 commented on Mar 24, 2026

aayushrautela commented on May 12, 2026

nhlmg93 commented on Jun 17, 2026

saidelike commented on Jun 18, 2026

nhlmg93 commented on Jun 18, 2026

akuzni2 commented on Aug 5, 2026

JensvandeWiel commented on Sep 15, 2026

balboah commented on Sep 17, 2026

neriousy commented on Oct 1, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions