Claude CLI, OpenCode & Gemini – Modelle routen, Harness wählen

Ein Missverständnis vorweg – eines, das mir von Anfang an klar war: Man routet nicht CLIs. Eine CLI ist ein Harness, also ein Werkzeug, und der Harness benutzt ein Modell. Das sind zwei getrennte Entscheidungen. Bei mir laufen im Alltag deshalb zwei Fragen parallel:

1. Welches Modell löst diese Aufgabe am besten? → Kontext, Datenschutz, Kosten, Fähigkeit.
2. Welcher Harness fährt dieses Modell am angenehmsten? → agentische Schleife, Tool-Use, Ergonomie.

Drei Harnesses hängen bei mir: Claude Code, OpenCode und Gemini CLI. Aber die eigentliche Routing-Achse sind die Modelle dahinter – und da wird es konkret: Claude Opus 5 und Sonnet 5, Gemini 3.1 Pro (plus Gemini 3 Flash für Vision), das offene DeepSeek-V4-Pro, lokal ein quantisiertes Qwen3-32B. Die CLI ist nur das Frontend, mit dem ich sie fahre.

Zwei Achsen, nicht eine

Die Eigenschaften, nach denen ich route, sind fast alle Modell-Eigenschaften, keine CLI-Eigenschaften:

• Das 2-Millionen-Token-Fenster von Gemini 3.1 Pro ist eine Eigenschaft des Modells – dasselbe Fenster bekommst du per API oder in jedem anderen Harness. (Der Rest der Gemini-3-Reihe liegt bei 1 Mio.; die 2 Mio. sind der Ausreißer, und genau deshalb der Grund, überhaupt zu Gemini zu greifen.)
• Vision hängt am Modell, nicht am Terminal: Bild und Screenshot versteht bei mir das günstigere, multimodale Gemini 3 Flash – dieselbe CLI, kleineres Modell.
• „Bleibt auf dem Rechner“ heißt: ein lokales Modell (Qwen3-32B), nicht „OpenCode“.
• „Offene Gewichte, reproduzierbar“ heißt: DeepSeek-V4-Pro, nicht der Harness, über den ich es fahre.
• Kosten und Reasoning-Tiefe hängen am Modell – Opus 5 gegen Sonnet 5 gegen Haiku 4.5 –, nicht am Terminal-Frontend.

Der Harness trägt trotzdem echten, eigenen Wert bei – nur einen anderen: wie gut die agentische Schleife editiert-testet-korrigiert, wie Tools eingebunden sind, wie das Repo gelesen wird. Claude Codes Stärke bei Multi-File-Refactors ist genau das – Harness-Arbeit oben auf einem starken Modell.

Sauber aufgeschlüsselt sieht mein „Routing“ also so aus – erst die Achse, dann das Modell (samt Variante), dann der Harness:

★ aktive Parameter pro Token – DeepSeek-V4-Pro ist ein Mixture-of-Experts mit ~1,6 Bio. Gesamt-, aber nur ~49 Mrd. aktiven Parametern und 1M-Kontext.

Zwei Dinge stecken absichtlich in dieser Tabelle. Erstens die Varianten: Opus 5 ist mein Qualitätsanker, aber Sonnet 5 liegt bei Coding-Aufgaben erstaunlich nah dran und kostet deutlich weniger – kleine Diffs müssen nicht über das teuerste Modell laufen. Zweitens ein ehrlicher Sonderfall: OpenCode ist kein eigenes Modell. Es ist eine modell-agnostische Hülle – ich fahre darüber sowohl lokales Qwen als auch das offene DeepSeek, und könnte genauso Claude oder Gemini fahren. Es steht in zwei Zeilen, weil ich es dafür nutze, nicht weil „OpenCode“ eine Fähigkeit wäre. Genau daran fällt die 1:1-Bündelung „eine CLI = ein Modell“ auf, die den Rest der Tabelle so ordentlich aussehen lässt.

Die Routing-Heuristik

Die Fragen bestimmen zuerst das Modell; der Harness folgt meist daraus:

1. Sind die Daten sensibel? → lokales Modell (Qwen3-32B, IQ3_M-Quant), kein Cloud-Call – bei mir über OpenCode.
2. Ist der Kontext riesig (ganzes Repo, lange Logs)? → Gemini 3.1 Pro mit seinem 2M-Fenster, über die Gemini CLI. Geht es dagegen um Bilder oder Screenshots, reicht meist das günstigere, multimodale Gemini 3 Flash – dieselbe CLI, kleineres Modell. Und wenn ich offene Gewichte brauche (Reproduzierbarkeit, kein Vendor-Lock, self-hostbar), läuft die schwere Aufgabe über DeepSeek-V4-Pro statt über Claude – gefahren via OpenCode.
3. Ist es ein tiefer, mehrstufiger Agenten-Task (refactor, migrate, debug quer durch viele Dateien)? → Claude, über Claude Code. Hier route ich noch ein zweites Mal, innerhalb des Anbieters: kleine, abgegrenzte Änderung → Sonnet 5; tiefe, riskante Multi-File-Arbeit → Opus 5 auf hoher Effort-Stufe (xhigh).

Als ausführbare Version passt das in eine kleine Shell-Funktion. Sie ist eine Abkürzung, die beide Entscheidungen – Modell und Harness – in einem Wort bündelt:

# ~/.config/fish/functions/ai.fish  (bash-Variante analog)
function ai --description "Route eine Coding-Aufgabe ans passende Modell (via Harness)"
    switch $argv[1]
        case local        # sensible Daten → lokales Qwen3-32B (IQ3_M), alles bleibt auf der Maschine
            opencode --model ollama/qwen3-32b-local $argv[2..]
        case big          # riesiger Kontext → Gemini 3.1 Pro (2M-Token-Fenster)
            gemini --model gemini-3.1-pro $argv[2..]
        case vision       # Bild/Screenshot → multimodales Gemini 3 Flash (günstig)
            gemini --model gemini-3-flash $argv[2..]
        case ds           # schwere Aufgabe, aber offenes Modell nötig → DeepSeek-V4-Pro
            opencode --model deepseek/deepseek-v4-pro $argv[2..]
        case quick        # kleine, abgegrenzte Änderung → Claude Sonnet 5 (günstiger)
            claude --model sonnet $argv[2..]
        case agent        # tiefer Multi-File-Task → Claude Opus 5, hohe Effort-Stufe
            claude --model opus $argv[2..]
        case '*'          # Default: allgemeiner, tiefer Task → Claude Opus 5
            claude $argv
    end
end

Aufruf dann z. B. ai local "erklär mir db/migrations" oder ai agent "zieh die Auth aus dem Controller in einen Service". Man sieht dem Alias die Doppelnatur an: bei local und ds steckt die eigentliche Wahl im --model-Flag – der Harness (OpenCode) wäre austauschbar; bei quick vs. agent route ich denselben Harness auf zwei verschiedene Claude-Varianten, bei big vs. vision dieselbe Gemini CLI auf zwei verschieden große Gemini-Modelle.

Praxis: gleicher Prompt, andere Wahl

Der Prompt ändert sich kaum – die Wahl von Modell und Harness schon. Sechs reale Muster:

Sensibler Code (Kundenprojekt, nichts in die Cloud):

ai local "Review diese Zahlungs-Logik auf Race-Conditions"
# → lokales Qwen3-32B, quantisiert auf IQ3_M (gefahren über OpenCode),
#   kein Byte verlässt den Rechner

Ganzes Repo verstehen:

gemini --model gemini-3.1-pro "Lies src/ komplett und beschreibe die Modul-Grenzen als Mermaid-Diagramm"
# → das 2M-Token-Fenster von Gemini 3.1 Pro trägt hier, wo andere abschneiden müssten

Screenshot deuten (Vision):

ai vision "Was zeigt dieser Fehler-Screenshot, und in welcher Komponente steckt er?" ./error.png
# → multimodales Gemini 3 Flash: reicht fürs Bildverständnis, ohne das teure Pro-Modell

Schwer, aber mit offenem Modell:

ai ds "Leite die Zeitkomplexität dieses Schedulers her und schlag eine bessere Datenstruktur vor"
# → DeepSeek-V4-Pro (offene Gewichte) über OpenCode – reproduzierbar, kein Vendor-Lock

Kleine, abgegrenzte Änderung:

ai quick "Benenn getUser in fetchUser um, inkl. Aufrufer in diesem Modul"
# → Claude Sonnet 5: nahe an Opus-Coding-Qualität, aber der günstigere Pfad

Tiefer Refactor mit Tool-Use:

ai agent "Migriere alle Klassen-Komponenten in src/components auf Hooks,
          führ nach jeder Datei die Tests aus und stopp bei Rotfärbung"
# → Claude Opus 5 auf `xhigh`: agentische Schleife auf dem stärksten Modell –
#   editieren, testen, korrigieren

Der ehrliche Teil: die Trade-offs

• Kosten vs. Fähigkeit: Opus 5 (grob ~5 $ / 25 $ pro Mio. Token Ein-/Ausgabe) ist bei großen Aufgaben mein Qualitätsanker – aber der teuerste Pfad. Kleine, abgegrenzte Änderungen laufen bei mir über Sonnet 5 (~3 $ / 15 $), das bei Coding nah an Opus liegt; wirklich triviales Zeug (Commit-Messages, kurze Erklärungen) geht an Haiku 4.5. Die Effort-Stufe ist dabei ein zweiter Hebel: xhigh nur, wenn die Aufgabe es rechtfertigt.
• Offen vs. proprietär: Wo Reproduzierbarkeit, Self-Hosting oder „kein Vendor-Lock“ zählt, ist DeepSeek-V4-Pro (offene Gewichte, 1M-Kontext) die Alternative zu Claude – dieselbe agentische Schleife über OpenCode, nur eben mit einem Modell, das ich notfalls selbst hosten kann.
• Datenschutz vs. Bequemlichkeit: Der lokale Pfad – Qwen3-32B auf IQ3_M, ~15 GB, egal über welchen Harness – ist langsamer als jede Cloud, aber bei Kundencode nicht verhandelbar. Wie ich das dense 32B auf eine 16-GB-Karte gebracht habe, steht im Quantisierungs-Post.
• Kontext vs. Präzision: Das 2M-Fenster von Gemini 3.1 Pro ist verführerisch – aber „alles reinkippen“ ist selten die beste Idee. Warum, steht im Context-Engineering-Post.

Fazit

Multi-Modell heißt nicht „viele Tools offen haben“ und auch nicht „CLIs routen“. Es heißt: die Aufgabe auf ihre Achse legen, danach das Modell samt Variante wählen – Opus 5 oder Sonnet 5, Gemini 3.1 Pro oder Gemini 3 Flash, das offene DeepSeek-V4-Pro oder ein lokales Qwen3-32B – und dann den Harness, der dieses Modell am besten fährt. Die Fragen – sensibel? groß? Bild? offen nötig? tief? – erledigen die Modellwahl; die CLI ist die Kür, nicht die Entscheidung. Das beste Modell ist selten das größte, sondern das passende für die Achse, auf der die Aufgabe gerade liegt.

[Top]