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

• Le contexte immense de Gemini est une propriété du modèle Gemini – tu obtiens la même fenêtre via API ou dans n’importe quel autre harnais.
• « Reste sur la machine » veut dire : un modèle local (Qwen), pas « OpenCode ».
• Le coût et la profondeur de raisonnement tiennent au modèle, 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, puis le harnais :

Un cas particulier honnête figure dans le tableau : OpenCode n’est pas un modèle à part entière. C’est une coquille agnostique au modèle – je pourrais y faire tourner Claude ou Gemini tout aussi bien. Il figure ici à côté de Qwen local parce que je l’utilise pour ça, pas parce qu’« OpenCode » serait une capacité. C’est précisément à cette ligne 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 trois 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 (Qwen), aucun appel cloud – chez moi via OpenCode.
2. Le contexte est-il immense (dépôt entier, longs logs) ? → Gemini, via la Gemini CLI.
3. Est-ce une tâche d’agent profonde et multi-étapes (refactor, migration, debug à travers de nombreux fichiers) ? → Claude, via Claude Code.

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 → modèle local, tout reste sur la machine
            opencode --model ollama/qwen3-32b-local $argv[2..]
        case big          # contexte immense → modèle Gemini
            gemini $argv[2..]
        case agent        # changement profond multi-fichiers → modèle Claude
            claude $argv[2..]
        case '*'          # défaut : tâche générale et profonde → modèle Claude
            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, le vrai choix est dans le flag --model – le harnais (OpenCode) est interchangeable.

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

Le prompt change à peine – le choix du modèle et du harnais, si. Trois 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 (exécuté via OpenCode), pas un octet ne quitte la machine

Comprendre un dépôt entier :

gemini "Lis tout src/ et décris les frontières de modules en diagramme Mermaid"
# → la grande fenêtre du modèle Gemini porte ici, là où d’autres devraient tronquer

Refactor profond avec usage d’outils :

claude "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"
# → boucle agentique (harnais) sur un modèle solide : éditer, tester, corriger

La partie honnête : les compromis

• Coût vs. capacité : le modèle Claude 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 n’ont pas toujours besoin du modèle le plus puissant.
• Confidentialité vs. confort : le chemin local (Qwen, 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 Qwen sur 16 Go pour cela est dans le billet sur la quantisation.
• Contexte vs. précision : la fenêtre géante de Gemini 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 ensuite le harnais qui fait tourner ce modèle au mieux. Les trois questions – sensible ? gros ? 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]