Layerer les modèles d'un agent CLI à budget plafonné

Choisir un modèle pour un agent de coding était simple tant qu’un seul dominait. En 2026, sous un abonnement à budget plafonné comme opencode Go — un pool de modèles ouverts accessibles pour une somme mensuelle fixe — la question devient : quel modèle sur quelle tâche, sachant que le quota est fini et que la moitié des modèles ont des défaillances documentées ? Voici la méthode que j’ai appliquée pour layerer mon setup pi, avec les chiffres relevés en juillet 2026.

Pourquoi le prix au token ne suffit plus à choisir un modèle ?

Parce qu’un budget plafonné ne se dépense pas en tokens, il se dépense en requêtes. opencode Go plafonne à 60 $/mois — soit, une fois lissé sur les fenêtres glissantes, environ 2,77 $ par jour ouvré effectif. Le tarif au token ne dit rien de ce que tu vas réellement brûler, parce qu’il ignore la verbosité du modèle.

Le chiffre décisif, opencode Go le publie lui-même : le nombre de requêtes par tranche de 5 h, qui intègre déjà prix et verbosité. Relevé en juillet 2026 :

Modèle	Req. / 5 h
Grok 4.5	120
GLM-5.2	880
DeepSeek V4 Pro	4 300
Hunyuan 3 (hy3)	30 100

Grok 4.5 consomme 36× plus de quota que DeepSeek V4 Pro, et 251× plus que Hy3. Un modèle « pas cher au token » mais bavard peut vider ton quota en une matinée. C’est le premier filtre : un modèle à 120 req/5 h ne peut pas être ton défaut, il est réservé à un usage parcimonieux.

Comment lire les benchmarks qui restent ?

Le piège de 2026 : les leaderboards indépendants et reproductibles ont gelé ou changé de cap, et ce qui reste à jour est majoritairement auto-déclaré. Je détaille cet effondrement — et pourquoi il faut s’en méfier plutôt que d’y renoncer — dans le dispatch Choisir un modèle quand les benchmarks ne suivent plus. Côté méthode, retiens deux garde-fous.

Une seule source reste vivante et indépendante : vals.ai (SWE-bench Verified, mis à jour en continu). Extrait de juillet 2026 :

Modèle	Score	Dispo
Claude Opus 5	97,0	quota Claude
Kimi K3	93,4	Go
Grok 4.5	86,6	Go
GLM-5.2	82,8	Go
Kimi K2.7 Code	78,2	Go
DeepSeek V4 Pro	77,4	Go

Premier garde-fou : elle sature. Les cinq premiers tiennent en quatre points, avec ~2 points d’erreur type. On s’en sert pour éliminer le bas, pas pour départager le haut. Second : aucun de ces chiffres ne parle de ta stack — aucune donnée publique n’existe sur les performances PHP/Symfony de ces modèles (SWE-bench est du Python, Terminal-Bench du shell). Tout classement appliqué à ton code est une extrapolation par proxy, d’où le test local en bout de course.

Quel est le vrai critère pour un agent CLI ?

La fiabilité du tool-calling — et aucun benchmark de qualité ne la mesure. Un agent CLI ne fait que ça : lire, éditer, lancer du bash, réécrire. Un modèle qui score haut en génération mais rate un appel d’outil sur cinq est inutilisable en agent.

Le seul dont le tool-calling soit vérifié indépendamment est Kimi K2.7 Code (MCPMark Verified : 81,89 %, devant Claude Opus 4.8 et DeepSeek V4 Pro). Rançon : c’est le plus lent du lot (~51 t/s). Pour un rôle qui doit enchaîner des outils sans dérailler, c’est le signal le plus solide du dossier.

À l’inverse, une issue opencode rapporte que DeepSeek V4 Pro/Flash et MiMo renverraient une erreur 500 dès que le paramètre tools est présent, sur les backends Go. Attention : ce constat est contesté — deux sources indépendantes (CI OpenHands, groupe de contrôle) ne le reproduisent pas, mais toutes deux passent par litellm, pas par le backend Go. À traiter comme un risque non tranché, à vérifier soi-même avant de confier du volume à ces modèles.

À quoi ressemble le layering une fois tranché ?

Un modèle par preset, chaque affectation portant sa justification. Voici le layering déployé en juillet 2026 sur pi via opencode Go :

Preset	Modèle	Outils	Raison
plan	glm-5.2	read, bash, grep, find, ls	Meilleur QI open, 191 t/s
implement	kimi-k2.7-code	read, bash, edit, write	Seul tool-calling vérifié indépendamment
review	grok-4.5	read, bash, grep, find, ls	Verbosité la plus basse ; une review consomme peu de requêtes, seul usage tenable sous 120 req/5 h
bulk	deepseek-v4-flash	read, write	Le moins cher, mais outils restreints par précaution
fast	glm-5.2	read, bash, edit, write	191 t/s, TTFT 1,35 s
vision	grok-4.5	read, bash, grep, find, ls	Image input, mais 120 req/5 h → parcimonie
hard	kimi-k2.7-code high	tous	Long-horizon : PR multi-fichiers, refactors profonds

La config réelle est publique : presets.json (ce tableau en JSON) et preset.ts (l’extension qui l’applique).

Le point qui n’est pas dans le tableau : le frontier ne passe pas par l’agent. Pour une tâche qui mérite le meilleur modèle avec tous les garde-fous, je ne bascule pas de modèle dans pi — je délègue à Claude Code interactif. La raison est mécanique : appeler un modèle premium depuis pi via un sous-processus casse les prompts interactifs et aveugle la supervision. Le layering ouvert couvre le quotidien ; le frontier vit ailleurs, en connaissance de cause.

Faut-il instruire le modèle ou le contraindre ?

Le contraindre. Le preset bulk réduit ses outils à ["read", "write"] au lieu de demander au modèle d’éviter les tool calls complexes : une contrainte appliquée tient là où une consigne de prompt se fait oublier sur un run long. C’est la leçon la plus transférable du layering — quand un comportement compte, applique-le, ne le demande pas. Le mécanisme et la config exacte sont dans ce TIL.