Claude CLI, OpenCode & Gemini – route models, pick a harness

One misconception up front – one that was clear to me from the start: you don’t route CLIs. A CLI is a harness, i.e. a tool, and the harness uses a model. Those are two separate decisions. So day to day, two questions run in parallel:

1. Which model solves this task best? → context, privacy, cost, capability.
2. Which harness runs that model most comfortably? → agentic loop, tool use, ergonomics.

Three harnesses stuck with me: Claude Code, OpenCode and Gemini CLI. But the actual routing axis is the models behind them – and this is where it gets concrete: Claude Opus 5 and Sonnet 5, Gemini 3.1 Pro (plus Gemini 3 Flash for vision), the open DeepSeek-V4-Pro, and locally a quantised Qwen3-32B. The CLI is just the front end I drive them with.

Two axes, not one

The properties I route on are almost all model properties, not CLI properties:

• Gemini 3.1 Pro’s 2-million-token window is a property of the model – you get the same window via API or in any other harness. (The rest of the Gemini 3 line sits at 1M; the 2M is the outlier, and precisely the reason to reach for Gemini at all.)
• Vision hangs on the model, not the terminal: images and screenshots go to the cheaper, multimodal Gemini 3 Flash for me – same CLI, smaller model.
• “Stays on the machine” means: a local model (Qwen3-32B), not “OpenCode”.
• “Open weights, reproducible” means: DeepSeek-V4-Pro, not the harness I run it through.
• Cost and reasoning depth hang on the model – Opus 5 vs. Sonnet 5 vs. Haiku 4.5 –, not on the terminal front end.

The harness still contributes real, independent value – just a different kind: how well the agentic loop edits-tests-corrects, how tools are wired in, how the repo is read. Claude Code’s strength on multi-file refactors is exactly that – harness work on top of a strong model.

Broken out cleanly, my “routing” looks like this – axis first, then model (and variant), then harness:

★ active parameters per token – DeepSeek-V4-Pro is a mixture-of-experts with ~1.6T total but only ~49B active parameters and a 1M context window.

Two things sit in this table deliberately. First, the variants: Opus 5 is my quality anchor, but Sonnet 5 lands surprisingly close on coding tasks at a markedly lower cost – small diffs don’t need to run through the most expensive model. Second, an honest special case: OpenCode is not a model of its own. It’s a model-agnostic shell – I run both local Qwen and the open DeepSeek through it, and could just as well run Claude or Gemini. It appears in two rows because I use it for that, not because “OpenCode” is a capability. This is exactly where the 1:1 bundling “one CLI = one model” – which makes the rest of the table look so tidy – falls apart.

The routing heuristic

The questions decide the model first; the harness usually follows from it:

1. Is the data sensitive? → a local model (Qwen3-32B, IQ3_M quant), no cloud call – for me via OpenCode.
2. Is the context huge (whole repo, long logs)? → Gemini 3.1 Pro with its 2M window, via the Gemini CLI. If it’s about images or screenshots instead, the cheaper, multimodal Gemini 3 Flash usually does – same CLI, smaller model. And when I need open weights (reproducibility, no vendor lock, self-hostable), the heavy task runs through DeepSeek-V4-Pro instead of Claude – driven via OpenCode.
3. Is it a deep, multi-step agent task (refactor, migrate, debug across many files)? → Claude, via Claude Code. Here I route a second time, within the provider: small, well-scoped change → Sonnet 5; deep, risky multi-file work → Opus 5 at high effort (xhigh).

As an executable version this fits into a small shell function. It’s a shortcut that bundles both decisions – model and harness – into one word:

# ~/.config/fish/functions/ai.fish  (bash variant analogous)
function ai --description "Route a coding task to the right model (via a harness)"
    switch $argv[1]
        case local        # sensitive data → local Qwen3-32B (IQ3_M), everything stays on the machine
            opencode --model ollama/qwen3-32b-local $argv[2..]
        case big          # huge context → Gemini 3.1 Pro (2M-token window)
            gemini --model gemini-3.1-pro $argv[2..]
        case vision       # image/screenshot → multimodal Gemini 3 Flash (cheap)
            gemini --model gemini-3-flash $argv[2..]
        case ds           # hard task, but needs open weights → DeepSeek-V4-Pro
            opencode --model deepseek/deepseek-v4-pro $argv[2..]
        case quick        # small, well-scoped change → Claude Sonnet 5 (cheaper)
            claude --model sonnet $argv[2..]
        case agent        # deep multi-file task → Claude Opus 5, high effort
            claude --model opus $argv[2..]
        case '*'          # default: general, deep task → Claude Opus 5
            claude $argv
    end
end

Then you call e.g. ai local "explain db/migrations to me" or ai agent "pull the auth out of the controller into a service". You can see the dual nature in the alias: for local and ds, the actual choice lives in the --model flag – the harness (OpenCode) is interchangeable; for quick vs. agent I route the same harness to two different Claude variants, and for big vs. vision the same Gemini CLI to two differently sized Gemini models.

In practice: same prompt, different choice

The prompt barely changes – the choice of model and harness does. Six real patterns:

Sensitive code (client project, nothing to the cloud):

ai local "Review this payment logic for race conditions"
# → local Qwen3-32B, quantised to IQ3_M (run via OpenCode), not a byte leaves the machine

Understand a whole repo:

gemini --model gemini-3.1-pro "Read all of src/ and describe the module boundaries as a Mermaid diagram"
# → Gemini 3.1 Pro's 2M-token window carries here, where others would have to truncate

Read a screenshot (vision):

ai vision "What does this error screenshot show, and which component is it in?" ./error.png
# → multimodal Gemini 3 Flash: enough for image understanding without the pricey Pro model

Hard, but with an open model:

ai ds "Derive the time complexity of this scheduler and suggest a better data structure"
# → DeepSeek-V4-Pro (open weights) via OpenCode – reproducible, no vendor lock

Small, well-scoped change:

ai quick "Rename getUser to fetchUser, including its callers in this module"
# → Claude Sonnet 5: close to Opus coding quality, but the cheaper path

Deep refactor with tool use:

ai agent "Migrate all class components in src/components to hooks,
          run the tests after each file and stop if it goes red"
# → Claude Opus 5 at `xhigh`: agentic loop on the strongest model – edit, test, correct

The honest part: the trade-offs

• Cost vs. capability: Opus 5 (roughly $5 / $25 per million tokens in/out) is my quality anchor for big tasks – but also the most expensive path. Small, well-scoped changes run through Sonnet 5 ($3 / $15), which sits close to Opus on coding; genuinely trivial stuff (commit messages, short explanations) goes to Haiku 4.5. The effort level is a second lever here: xhigh only when the task justifies it.
• Open vs. proprietary: where reproducibility, self-hosting or “no vendor lock” matters, DeepSeek-V4-Pro (open weights, 1M context) is the alternative to Claude – the same agentic loop through OpenCode, just with a model I can host myself if I have to.
• Privacy vs. convenience: the local path – Qwen3-32B at IQ3_M, ~15 GB, whatever harness runs it – is slower than any cloud, but non-negotiable for client code. How I got the dense 32B onto a 16 GB card is in the quantisation post.
• Context vs. precision: Gemini 3.1 Pro’s 2M window is tempting – but “dump it all in” is rarely the best idea. Why, is in the context-engineering post.

Conclusion

Multi-model doesn’t mean “have many tools open”, and it doesn’t mean “route CLIs” either. It means: put the task on its axis, then pick the model and its variant – Opus 5 or Sonnet 5, Gemini 3.1 Pro or Gemini 3 Flash, the open DeepSeek-V4-Pro or a local Qwen3-32B – and then the harness that runs that model best. The questions – sensitive? big? image? open needed? deep? – settle the model choice; the CLI is the finish, not the decision. The best model is rarely the biggest, but the one that fits the axis the task currently sits on.

[Top]