Repository navigation
[FEATURE]: Native task routing over resolved models with reasoning-variant selection #51972
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
OpenCode could natively support task-aware routing across the models it has already resolved, followed by compatible reasoning-variant selection.
I maintain a plugin that demonstrates this workflow: it makes two decisions for each request:
- Select an eligible agent/model for the task.
- Select a reasoning variant supported by that model (
none,low,medium,high,xhigh, ormax, depending on the runtime catalog).
The plugin validates the choice against the runtime model catalog and falls back without sending an unsupported variant. See the example implementation and configuration:
https://github.com/Melivo/opencode-plugin-variantizer
This is related to #34370, #8456, #50729, and #49712, but the useful native primitive here is the two-stage, catalog-aware decision: resolve the available models first, then derive the valid thinking/variant choices for the selected model. That would avoid plugins having to recreate model/variant discovery and would make the behavior consistent across TUI, CLI, and other clients.
Suggested behavior
- Resolve the currently available and authorized model catalog.
- Choose a model/agent based on the task, unless the user explicitly pinned one.
- Choose a reasoning variant only from the selected model's resolved capabilities.
- Preserve explicit user model and variant selections over automatic routing.
- Validate the final model-plus-variant pair before the provider request; use a deterministic fallback when automatic classification is unavailable or invalid.
- Expose the effective model and variant in session metadata or logs so the decision is inspectable.
The classification mechanism could be built in or exposed as a stable native extension point. The core should own catalog resolution, precedence, validation, and safe fallback behavior.
Acceptance criteria
- No unsupported variant is sent to a provider because of automatic routing.
- A user-pinned model or variant is never silently replaced.
- Automatic routing works consistently for interactive and one-shot requests without requiring abort-and-resend.
- The effective model, variant, and fallback outcome are observable for debugging.
Activity
github-actions commentedon Sep 29, 2026
This issue might be a duplicate of existing issues. Please check:
Melivo commentedon Sep 29, 2026
It would also be great if this could support bring-your-own-key (BYOK) for the TypeSafe/Jev classifier. Users could provide their own TypeSafe API key (for example via an environment variable or OpenCode secret configuration), and the native routing flow would use it for model/variant decisions. This should remain opt-in, avoid logging or exposing the key, and preserve a deterministic fallback when no key is configured.
IRONICBo commentedon Sep 29, 2026
The native seam looks like it belongs before
SessionPrompt.promptpersists the user message. On currentdev,prompt.ts:654accepts an explicitinput.variant, while request prep assumes the model is resolved and silently gets no variant options when that key is invalid.I’d keep the catalog code-owned: Jev chooses an opaque model ID, code loads that model, then a second Choice contains only its resolved variants. Preserve explicit pins and record the requested/effective tuple plus fallback reason. Tests should cover pinned model+variant, pinned model only, invalid decisions, and a catalog change between decisions. Jev Social uses this same boundary for typed browser actions.
miguelenes commentedon Oct 11, 2026
Adding a concrete plugin requirement from an OpenCode v2 Jev router implementation.
Against v2.0.26,
session.promptruns at admission and exposes no model override,session.contextsees a readonlymodel, andsession.switchModelchanges the model for subsequent provider turns. The only plugin-level workaround we have verified is rewriting the model field in an OpenRouter HTTP request after Core has already selected the provider. That cannot safely route to a different provider: the request still carries the original provider's endpoint, credentials, and protocol.A provider-agnostic router needs a request-scoped choice before provider resolution. The choice should bind to the admitted user message, drive provider/model/auth resolution atomically, and be reapplied to that turn's tool continuations. Queued prompts must resolve independently, and automatic selection must not mutate the persistent session default or override an explicit user-pinned model/variant. The effective per-turn model should be visible in the TUI and desktop.
Could this issue include a stable pre-dispatch model-selection hook or request-local model override with those semantics? Suggested coverage: two queued prompts with a tool continuation, retry/compaction behavior, provider auth and protocol selection, explicit model/variant precedence, invalid-model rejection before dispatch, and effective-model display.
Related plugin API discussions: #50729 and #35408. Mutating model-visible context alone does not resolve the provider/auth selection problem.
Melivo commentedon Oct 11, 2026
I think this has become somewhat obsolete.
Changing models per prompt might not be cost-effective because you lose the token cache and therefore cheaper pricing.
For example:
We would probably need extensive usage stats to know whether this really makes sense. And I doubt Jev can properly account for these factors.
Additionally, OpenChamber already provides this feature.
Therefore: Issue closed. However, if others still want to continue this, feel free.