Per-model Combo Support

[vinz-bambico]

Given multiple agents with specialized skillsets, is it possible to make the combos be configurable on a per-model basis?

If I were to use Oh-My-Opencode for example, an ideal and more token-efficient scenario would be something like:

Sissyphus (main orchestrator agent): Claude Opus 4.6 -> Gemini 3.1 Pro -> Kimi K2.5 -> etc..
Hephaestus (code researcher): Claude Sonnet 4.5 -> GPT 5.3 Codex -> Gemini 3 Flash -> Kimi K2.5 -> etc.
Prometheus (planning agent): Claude Opus 4.6 -> Gemini 3.1 Pro GPT 5.3 Codex -> Kimi K2.5 -> etc..

You get the idea. Basically cascade providers to the next available as currently used one hit limits.

Since there is currently only one endpoint, I am thinking if it would be possible to create multiple endpoints for each specialized agent combo although I would leave it to your best judgement should you consider this idea.

[diegosouzapw]

Hey @vinz-bambico! Great idea - per-model combo routing is something I've been thinking about too

Currently, combos are global (one active combo = one failover chain for all requests). But your use case - assigning different fallback chains per model/agent - is a strong one, especially for multi-agent setups like Oh-My-Opencode.

Here's how you can achieve something similar today:

1. Multiple API Keys - Create separate API keys in /dashboard/api-manager, each pointing to a different combo. Your orchestrator agent uses one key (-> Opus combo), your code researcher uses another (-> Sonnet combo), etc.
2. 2. Header-based combo switching - Use X-OmniRoute-Combo: header per-request to dynamically select which combo to use without switching the global default.
      For a native per-model combo mapping (where the combo is automatically selected based on the requested model name), I'll open a feature issue to track it properly. It would fit well as a routing policy layer.

Thanks for the suggestion!

[dail45]

How do this?

[diegosouzapw]

@dail45 -- here's the concrete how-to for the multi-key combo workaround today (before the per-model combo feature lands):

1. Create one combo per agent role. Dashboard -> Combos -> New Combo. Name them after the role: orchestrator-combo, code-research-combo, planning-combo, etc.
2. Add models in priority order inside each combo. For code-research-combo you'd add claude-sonnet-4-6 first, then gpt-5.3-codex, then gemini-3-flash, then kimi-k2.5. Strategy: priority (fixed order) or lkgp (last-known-good-priority -- sticks to the head until it fails).
3. Map each combo to a unique model alias via Dashboard -> Combos -> Model-Combo Mappings. For example, expose code-research-combo as model name omniroute-research. Same for the other combos.
4. Point each agent in your client (Oh-My-Opencode, Claude Code, Continue, etc.) to the matching alias. The orchestrator agent calls model omniroute-orchestrator, the researcher calls omniroute-research, etc. Each lands in its own fallback chain.

This is per-model-name routing, which is what OmniRoute supports today. The "true" per-model-combo feature (one global combo definition that re-dispatches based on the inner requested model) is tracked separately -- I'll link the new issue here when I open it. But for practical multi-agent setups, the alias-per-role approach above is what production users are doing and it works cleanly.

[diegosouzapw]

Update @vinz-bambico -- per-model combo routing is available now (it shipped via #563), so the manual one-combo-per-role workaround posted earlier is no longer required.

Dashboard -> Settings -> Model Routing (/dashboard/settings/routing) lets you map model-name glob patterns to specific combos. The resolver matches the incoming model string against your patterns (glob, case-insensitive) and routes to the first matching combo:

• *orchestrator* -> orchestrator-combo
• *research* -> code-research-combo
• *plan* -> planning-combo

Backed by src/lib/db/modelComboMappings.ts + API /api/model-combo-mappings. So your Oh-My-Opencode setup works by naming each agent role to match a pattern. Closing as resolved -- ping me if a pattern does not route as expected.