Claude CLI, OpenCode & Gemini – router des modèles, choisir un harnais

Un malentendu d’abord – un qui m’a été clair dès le début : on ne route pas des CLI. Une CLI est un harnais, c’est-à-dire un outil, et le harnais utilise un modèle. Ce sont deux décisions distinctes. Au quotidien, deux questions tournent donc en parallèle :

1. Quel modèle résout le mieux cette tâche ? → contexte, confidentialité, coût, capacité.
2. Quel harnais fait tourner ce modèle le plus confortablement ? → boucle agentique, usage d’outils, ergonomie.

Trois harnais me sont restés : Claude Code, OpenCode et Gemini CLI. Mais le véritable axe de routage, ce sont les modèles derrière – et là, ça devient concret : Claude Opus 5 et Sonnet 5, Gemini 3.1 Pro (plus Gemini 3 Flash pour la vision), le DeepSeek-V4-Pro ouvert, et en local un Qwen3-32B quantisé. La CLI n’est que le frontal avec lequel je les pilote.

Deux axes, pas un

Les propriétés selon lesquelles je route sont presque toutes des propriétés du modèle, pas de la CLI :

• La fenêtre de 2 millions de tokens de Gemini 3.1 Pro est une propriété du modèle – tu obtiens la même fenêtre via API ou dans n’importe quel autre harnais. (Le reste de la gamme Gemini 3 est à 1 M ; les 2 M sont l’exception, et justement la raison d’aller vers Gemini.)
• La vision tient au modèle, pas au terminal : images et captures passent chez moi par le Gemini 3 Flash multimodal, moins cher – même CLI, modèle plus petit.
• « Reste sur la machine » veut dire : un modèle local (Qwen3-32B), pas « OpenCode ».
• « Poids ouverts, reproductible » veut dire : DeepSeek-V4-Pro, pas le harnais qui le fait tourner.
• Le coût et la profondeur de raisonnement tiennent au modèle – Opus 5 contre Sonnet 5 contre Haiku 4.5 –, pas au frontal du terminal.

Le harnais apporte tout de même une valeur réelle et propre – simplement d’un autre ordre : la qualité de la boucle agentique éditer-tester-corriger, la façon dont les outils sont branchés, dont le dépôt est lu. La force de Claude Code sur les refactors multi-fichiers, c’est exactement ça – du travail de harnais par-dessus un modèle solide.

Décomposé proprement, mon « routage » ressemble donc à ceci – l’axe d’abord, puis le modèle (et sa variante), puis le harnais :

★ paramètres actifs par token – DeepSeek-V4-Pro est un mixture-of-experts d’environ 1,6 Bio. de paramètres au total, mais seulement ~49 Md actifs, avec une fenêtre de 1M tokens.

Deux choses figurent volontairement dans ce tableau. D’abord les variantes : Opus 5 est mon ancre de qualité, mais Sonnet 5 s’en approche étonnamment sur les tâches de code, pour un coût nettement moindre – les petits diffs n’ont pas besoin de passer par le modèle le plus cher. Ensuite, un cas particulier honnête : OpenCode n’est pas un modèle à part entière. C’est une coquille agnostique au modèle – j’y fais tourner aussi bien le Qwen local que le DeepSeek ouvert, et je pourrais tout aussi bien y faire tourner Claude ou Gemini. Il figure sur deux lignes parce que je l’utilise pour ça, pas parce qu’« OpenCode » serait une capacité. C’est précisément là que s’effondre le couplage 1:1 « une CLI = un modèle » qui rend le reste du tableau si net.

L’heuristique de routage

Les questions décident d’abord du modèle ; le harnais en découle le plus souvent :

1. Les données sont-elles sensibles ? → un modèle local (Qwen3-32B, quant IQ3_M), aucun appel cloud – chez moi via OpenCode.
2. Le contexte est-il immense (dépôt entier, longs logs) ? → Gemini 3.1 Pro et sa fenêtre de 2 M, via la Gemini CLI. S’il s’agit plutôt d’images ou de captures, le Gemini 3 Flash multimodal, moins cher, suffit le plus souvent – même CLI, modèle plus petit. Et quand j’ai besoin de poids ouverts (reproductibilité, pas de vendor lock, self-hébergeable), la tâche lourde passe par DeepSeek-V4-Pro plutôt que par Claude – piloté via OpenCode.
3. Est-ce une tâche d’agent profonde et multi-étapes (refactor, migration, debug à travers de nombreux fichiers) ? → Claude, via Claude Code. Là, je route une seconde fois, à l’intérieur du fournisseur : petit changement bien délimité → Sonnet 5 ; travail multi-fichiers profond et risqué → Opus 5 à effort élevé (xhigh).

En version exécutable, cela tient dans une petite fonction shell. C’est un raccourci qui regroupe les deux décisions – modèle et harnais – en un mot :

# ~/.config/fish/functions/ai.fish  (variante bash analogue)
function ai --description "Router une tâche de code vers le bon modèle (via un harnais)"
    switch $argv[1]
        case local        # données sensibles → Qwen3-32B local (IQ3_M), tout reste sur la machine
            opencode --model ollama/qwen3-32b-local $argv[2..]
        case big          # contexte immense → Gemini 3.1 Pro (fenêtre 2M tokens)
            gemini --model gemini-3.1-pro $argv[2..]
        case vision       # image/capture → Gemini 3 Flash multimodal (bon marché)
            gemini --model gemini-3-flash $argv[2..]
        case ds           # tâche difficile, mais modèle ouvert requis → DeepSeek-V4-Pro
            opencode --model deepseek/deepseek-v4-pro $argv[2..]
        case quick        # petit changement bien délimité → Claude Sonnet 5 (moins cher)
            claude --model sonnet $argv[2..]
        case agent        # tâche multi-fichiers profonde → Claude Opus 5, effort élevé
            claude --model opus $argv[2..]
        case '*'          # défaut : tâche générale et profonde → Claude Opus 5
            claude $argv
    end
end

On appelle ensuite p. ex. ai local "explique-moi db/migrations" ou ai agent "sors l’auth du contrôleur vers un service". La double nature se voit dans l’alias : pour local et ds, le vrai choix est dans le flag --model – le harnais (OpenCode) est interchangeable ; pour quick vs. agent, je route le même harnais vers deux variantes de Claude, et pour big vs. vision la même Gemini CLI vers deux modèles Gemini de tailles différentes.

En pratique : même prompt, choix différent

Le prompt change à peine – le choix du modèle et du harnais, si. Six motifs réels :

Code sensible (projet client, rien vers le cloud) :

ai local "Passe en revue cette logique de paiement pour les race conditions"
# → Qwen3-32B local, quantisé en IQ3_M (exécuté via OpenCode), pas un octet ne quitte la machine

Comprendre un dépôt entier :

gemini --model gemini-3.1-pro "Lis tout src/ et décris les frontières de modules en diagramme Mermaid"
# → la fenêtre de 2M tokens de Gemini 3.1 Pro porte ici, là où d’autres devraient tronquer

Décrypter une capture (vision) :

ai vision "Que montre cette capture d’erreur, et dans quel composant se trouve-t-elle ?" ./error.png
# → Gemini 3 Flash multimodal : suffit à comprendre l’image, sans le coûteux modèle Pro

Difficile, mais avec un modèle ouvert :

ai ds "Dérive la complexité temporelle de ce scheduler et propose une meilleure structure de données"
# → DeepSeek-V4-Pro (poids ouverts) via OpenCode – reproductible, pas de vendor lock

Petit changement bien délimité :

ai quick "Renomme getUser en fetchUser, y compris ses appelants dans ce module"
# → Claude Sonnet 5 : proche de la qualité de code d’Opus, mais le chemin le moins cher

Refactor profond avec usage d’outils :

ai agent "Migre tous les composants classe de src/components vers des hooks,
          lance les tests après chaque fichier et arrête-toi si ça passe au rouge"
# → Claude Opus 5 en `xhigh` : boucle agentique sur le modèle le plus fort – éditer, tester, corriger

La partie honnête : les compromis

• Coût vs. capacité : Opus 5 (grosso modo ~5 $ / 25 $ par million de tokens en entrée/sortie) est mon ancre de qualité pour les grosses tâches – mais aussi le chemin le plus coûteux. Les petits changements bien délimités passent par Sonnet 5 (~3 $ / 15 $), proche d’Opus sur le code ; le vraiment trivial (messages de commit, courtes explications) va à Haiku 4.5. Le niveau d’effort est un second levier : xhigh seulement quand la tâche le justifie.
• Ouvert vs. propriétaire : là où comptent la reproductibilité, le self-hosting ou le « pas de vendor lock », DeepSeek-V4-Pro (poids ouverts, contexte 1M) est l’alternative à Claude – la même boucle agentique via OpenCode, mais avec un modèle que je peux héberger moi-même au besoin.
• Confidentialité vs. confort : le chemin local – Qwen3-32B en IQ3_M, ~15 Go, quel que soit le harnais qui l’exécute – est plus lent que n’importe quel cloud, mais non négociable pour du code client. Comment j’ai fait tenir le 32B dense sur une carte de 16 Go est dans le billet sur la quantisation.
• Contexte vs. précision : la fenêtre de 2 M de Gemini 3.1 Pro est tentante – mais « tout balancer » est rarement la meilleure idée. Pourquoi, c’est dans le billet sur le context engineering.

Conclusion

Le multi-modèle ne veut pas dire « avoir plein d’outils ouverts », et pas non plus « router des CLI ». Il veut dire : placer la tâche sur son axe, puis choisir le modèle et sa variante – Opus 5 ou Sonnet 5, Gemini 3.1 Pro ou Gemini 3 Flash, le DeepSeek-V4-Pro ouvert ou un Qwen3-32B local – et ensuite le harnais qui fait tourner ce modèle au mieux. Les questions – sensible ? gros ? image ? ouvert requis ? profond ? – règlent le choix du modèle ; la CLI est la finition, pas la décision. Le meilleur modèle est rarement le plus gros, mais celui qui convient à l’axe sur lequel la tâche se trouve.

[Top]