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 – 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:

• Geminis Riesenkontext ist eine Eigenschaft des Gemini-Modells – dasselbe Fenster bekommst du per API oder in jedem anderen Harness.
• „Bleibt auf dem Rechner“ heißt: ein lokales Modell (Qwen), nicht „OpenCode“.
• Kosten und Reasoning-Tiefe hängen am Modell, 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, dann der Harness:

Ein ehrlicher Sonderfall steht in der Tabelle: OpenCode ist kein eigenes Modell. Es ist eine modell-agnostische Hülle – ich könnte darüber genauso Claude oder Gemini fahren. Es steht hier neben lokalem Qwen, weil ich es dafür nutze, nicht weil „OpenCode“ eine Fähigkeit wäre. Genau an dieser Zeile 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 drei Fragen bestimmen zuerst das Modell; der Harness folgt meist daraus:

1. Sind die Daten sensibel? → lokales Modell (Qwen), kein Cloud-Call – bei mir über OpenCode.
2. Ist der Kontext riesig (ganzes Repo, lange Logs)? → Gemini, über die Gemini CLI.
3. Ist es ein tiefer, mehrstufiger Agenten-Task (refactor, migrate, debug quer durch viele Dateien)? → Claude, über Claude Code.

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 Modell, alles bleibt auf der Maschine
            opencode --model ollama/qwen3-32b-local $argv[2..]
        case big          # riesiger Kontext → Gemini-Modell
            gemini $argv[2..]
        case agent        # tiefe Multi-File-Änderung → Claude-Modell
            claude $argv[2..]
        case '*'          # Default: allgemeiner, tiefer Task → Claude-Modell
            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 steckt die eigentliche Wahl im --model-Flag – der Harness (OpenCode) wäre austauschbar.

Praxis: gleicher Prompt, andere Wahl

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

Sensibler Code (Kundenprojekt, nichts in die Cloud):

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

Ganzes Repo verstehen:

gemini "Lies src/ komplett und beschreibe die Modul-Grenzen als Mermaid-Diagramm"
# → das große Kontextfenster des Gemini-Modells trägt hier, wo andere abschneiden müssten

Tiefer Refactor mit Tool-Use:

claude "Migriere alle Klassen-Komponenten in src/components auf Hooks,
        führ nach jeder Datei die Tests aus und stopp bei Rotfärbung"
# → agentische Schleife (Harness) auf starkem Modell: editieren, testen, korrigieren

Der ehrliche Teil: die Trade-offs

• Kosten vs. Fähigkeit: Das Claude-Modell ist bei großen Aufgaben mein Qualitätsanker – aber auch der teuerste Pfad. Kleine, abgegrenzte Änderungen müssen nicht immer über das stärkste Modell laufen.
• Datenschutz vs. Bequemlichkeit: Der lokale Pfad (Qwen, egal über welchen Harness) ist langsamer als jede Cloud, aber bei Kundencode nicht verhandelbar. Wie ich Qwen dafür auf 16 GB gebracht habe, steht im Quantisierungs-Post.
• Kontext vs. Präzision: Geminis Riesenfenster 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 wählen – und dann den Harness, der dieses Modell am besten fährt. Die drei Fragen – sensibel? groß? 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]