Votre agent de code paie le prix fort des modèles frontier pour répondre à des questions à choix multiples.
Quelles notes dois-je charger ? Cette étape doit-elle aller au gros modèle ou à un petit ? L'outil vient d'échouer : je réessaie, je corrige ou j'abandonne ? Quels tests lancer en premier ?
Chacune de ces questions n'a que quatre ou cinq réponses possibles. Pourtant, dans la plupart des configurations d'agents actuelles, c'est votre modèle le plus cher qui y répond à chaque fois, avec le mode réflexion activé, en lisant tout le contexte et en rédigeant un paragraphe avant de se décider.
C'est là que l'argent fuit.
Cet article vous montre comment colmater la brèche. Opus 5.5 garde le raisonnement complexe : planification, écriture de code, débogage. Jev prend en charge les quatre décisions qui surviennent à presque chaque étape. Votre harness (votre boucle de contrôle) prépare les options, vérifie les réponses et tranche en dernier ressort.
Dans l'exemple détaillé ci-dessous, une session de développement passe de 6,42 $ à 2,00 $. Soit 69 % d'économie, avec chaque ligne de calcul expliquée dans cet article pour que vous puissiez vérifier avec vos propres chiffres.
Ce guide s'adresse à quiconque fait tourner un agent de code sur de vrais projets : Claude Code, votre propre harness via l'API, ou n'importe quelle solution intermédiaire. Pas besoin de réécrire votre agent. Chaque élément de cet article s'intègre dans une boucle existante sous forme d'appel de fonction, avec un flag pour le désactiver. Si vous avez lu mon article sur Jev + Claude Code, voici la version mise à jour : même concept, un modèle de raisonnement plus récent, et quatre décisions précises au lieu d'un principe général.
Il vous faudra une clé API Jev, une clé API Anthropic, et environ une semaine de logs de votre propre agent comme base de comparaison.
C'est parti.
opus réfléchit, jev décide.
Le problème : un seul modèle pour deux métiers
Observez un agent de code travailler pendant dix minutes et vous le verrez accomplir deux tâches radicalement différentes.
La première est le raisonnement. Planifier une fonctionnalité. Écrire une fonction. Lire une stack trace et comprendre pourquoi le parseur de dates plante les années bissextiles. Ce travail est ouvert. La réponse ne figure pas dans une liste. C'est ici qu'il faut le modèle le plus intelligent que vous pouvez vous offrir, et Opus 5.5 excelle dans ce domaine.
La seconde est la décision. Choisir les trois notes de projet pertinentes parmi quarante. Décider qu'un renommage peut être confié à un modèle bon marché. Choisir quoi faire après un timeout de npm test. Sélectionner les 12 fichiers de test à exécuter avant la suite complète de 1 400. Ces réponses sont dans une liste. Une liste courte. Et votre code peut exploiter la réponse directement.
La plupart des agents font passer ces deux métiers par le même modèle, car c'est le comportement par défaut. La boucle appelle Opus, Opus réfléchit, Opus répond, la boucle continue.
Ça fonctionne. Mais c'est aussi lent et coûteux d'une manière difficile à percevoir, car pris isolément, aucun appel de décision ne semble cher. Un simple appel « quelles notes me faut-il » coûte peut-être un centime. Mais il se produit à chaque étape, en embarquant systématiquement tout le contexte.
Et il y a un second coût, encore plus discret : quand l'agent n'arrive pas à choisir quoi charger, il charge tout. Chaque note de projet, chaque document de conventions, chaque décision passée, entassés dans chaque appel. Opus 5.5 a rendu les lectures de cache abordables à 0,20 $ le million de tokens, mais « pas cher × soixante étapes × tout votre dossier de notes », ça finit par chiffrer.
La solution : Opus raisonne, Jev décide, votre harness commande
Jev est le modèle de TypeSafe conçu précisément pour cette seconde tâche. Il ne génère pas de texte. Vous lui donnez du contexte et des questions typées avec un ensemble fixe d'options, et il renvoie une probabilité pour chaque option. Il répond en quelques millisecondes, l'input coûte 0,042 $ le million de tokens, et l'output est gratuit.
L'architecture devient alors simple à décrire :
Opus 5.5 gère le raisonnement. Planification, code, débogage, tout ce dont la réponse ne figure pas dans une liste.
Jev prend les petites décisions. Il choisit parmi les options préparées par votre harness.
Votre harness garde le contrôle. Il construit les listes d'options, lit les probabilités, applique les seuils et se rabat sur Opus quand Jev hésite.
C'est cette troisième ligne que tout le monde saute, alors que c'est elle qui garantit la sécurité de l'ensemble. Jev n'invente jamais d'option. Jev n'a jamais le dernier mot sur une action irréversible. C'est votre code qui définit ce que signifie « assez sûr ».
Voici la fonction utilitaire sur laquelle repose tout le reste de cet article :
from dataclasses import dataclass
class Decision:
answer: str
prob: float
probs: dict
confident: bool
def jev_choice(context: str, question: str, options: list[str]):
Connectez ceci à votre client Jev : le SDK TypeSafe, Vercel AI Gateway,
ou le package LangChain. Il doit renvoyer {option: probabilité}
pour chaque option transmise.
raise NotImplementedError
def decide(context: str, question: str, options: list[str], threshold: float):
probs = jev_choice(context, question, options)
answer = max(probs, key=probs.get)
return Decision(answer, probs[answer], probs, probs[answer] >= threshold)
Remarquez ce qui manque : aucune question demandant à Jev son niveau de confiance. Vous lisez simplement la probabilité qu'il renvoie. Demander à un modèle « es-tu sûr ? » vous vaudra un « oui » presque à chaque fois. La probabilité est le seul signal honnête.
Passons maintenant aux quatre décisions.
Les quatre décisions au sein d'une étape de l'agent
Décision 1 : sélectionner les notes de projet pertinentes avant de charger le contexte
C'est le levier le plus puissant, et presque personne ne l'a encore implémenté.
Votre agent possède un dossier de notes. Un fichier AGENTS.md, des documents d'architecture, des conventions, des décisions passées, des avertissements du type « ne jamais toucher au module de facturation sans migration ». Peut-être 30 000 tokens au total. La plupart des agents chargent l'intégralité à chaque appel, parce que personne ne veut être celui qui a oublié la note cruciale.
Au lieu de tout charger, posez donc à Jev une question simple sur chaque note, en parallèle : l'agent a-t-il besoin de cette note pour cette tâche ?
Commencez par découper vos notes en blocs selon les titres. Chaque section d'AGENTS.md devient un bloc. Chaque document d'architecture devient un ou plusieurs blocs.
import re
def chunk_notes(markdown: str, source: str):
parts = re.split(r"
(?=## )", markdown)
return [{"source": source, "text": p.strip()} for p in parts if p.strip()]
Évaluez ensuite chaque bloc par rapport à la tâche en cours :
from concurrent.futures import ThreadPoolExecutor
def pick_notes(task: str, notes: list[dict], keep: int = 6, floor: float = 0.55):
def score(note):
probs = jev_choice(
context=f"TASK:
{task}
NOTE ({note['source']}):
{note['text']}",
question="Would an engineer need this note to do the task correctly?",
options=["needed", "not_needed"],
)
return probs["needed"], note
with ThreadPoolExecutor(max_workers=16) as pool:
scored = sorted(pool.map(score, notes), key=lambda s: s[0], reverse=True)
picked = [n for p, n in scored[:keep] if p >= floor]
return picked or [n for _, n in scored[:2]]
Trois détails ont leur importance ici.
Chargez toujours les éléments non négociables. Certaines notes doivent figurer dans chaque appel, quoi qu'il arrive : les règles de sécurité, l'interdiction de force push, la ligne unique qui indique quelle base de données est en production. Taguez-les comme obligatoires et ne les évaluez pas.
Fixez un seuil plancher et un repli. Si rien ne dépasse 0,55, chargez quand même les deux premiers blocs. Un agent sans aucun contexte est pire qu'un agent avec un peu trop de contexte.
Loguez ce qui est écarté. Quand l'agent commet une erreur, la première chose à vérifier est si la note qui l'aurait empêchée a été filtrée. C'est grâce à ces logs que vous ajusterez les paramètres keep et floor.
Dans notre exemple, cette seule modification fait passer la partie « notes » de chaque appel de 30 000 à 6 000 tokens. À elle seule, elle réduit le coût de la session d'environ 24 %.
Décision 2 : router les tâches adaptées vers un worker plus rapide
Toutes les étapes n'ont pas besoin d'Opus.
Renommer une fonction dans huit fichiers, non plus. Ajouter un champ à un formulaire qui en compte déjà neuf identiques, non plus. Mettre à jour un chemin d'import, non plus. Ce sont des modifications qui suivent un motif déjà présent dans le code.
Ainsi, avant chaque étape, Jev classe la tâche, et votre harness associe cette classe à un worker :
ROUTES = {
"rename_or_move": "fast",
"small_edit_following_existing_pattern": "fast",
"new_logic": "opus",
"debugging": "opus",
"design_decision": "opus",
}
def route(step: str, recent_diff: str):
d = decide(
context=f"STEP:
{step}
RECENT CHANGES:
{recent_diff}",
question="What kind of work is this step?",
options=list(ROUTES),
threshold=0.8,
)
if not d.confident:
return "opus"
return ROUTES[d.answer]
Observez la formulation des options. Ce ne sont pas « facile » et « difficile », et encore moins « un petit modèle peut-il gérer ça ? ». Ce sont des types de travaux concrets que votre code peut traduire en action. C'est la règle d'or pour chaque question posée à Jev : chaque option doit correspondre à une action que votre harness sait exécuter.
Notez également le comportement par défaut. Sous 0,8, l'étape part chez Opus. Les erreurs de routage ne vont que dans un sens : confier une tâche complexe au worker rapide vous coûte une étape ratée et une nouvelle tentative, tandis qu'envoyer une tâche simple à Opus ne coûte qu'un léger supplément. Dans le doute, déléguez vers le haut.
Pour le worker rapide, j'utilise Haiku 4.5 à 1 $ le million de tokens en input et 5 $ en output. Dans l'exemple détaillé, 12 des 36 véritables étapes de travail lui sont confiées.
Décision 3 : choisir une stratégie de récupération quand un outil échoue
Les outils plantent constamment. Les tests dépassent le délai imparti. Un chemin de fichier est faux. Un paquet n'est pas installé. Une commande shell se heurte à une erreur de permissions. Un linter râle sur un détail sans rapport.
La plupart des agents gèrent cela de la façon la plus coûteuse possible : ils renvoient toute l'erreur au gros modèle et le laissent réfléchir à la marche à suivre. Parfois, c'est justifié. Mais souvent, la solution est évidente, et Opus dépense 1 500 tokens pour redécouvrir que ENOENT signifie que le fichier n'existe pas.
Pire, les agents s'enferment dans des boucles. Réessayer, échouer, réessayer, échouer, en payant à chaque fois une étape complète de raisonnement.
Confiez plutôt l'échec à Jev avec un ensemble fixe de stratégies de récupération :
from collections import deque
def tail(text: str, n: int = 4000):
return "".join(deque(text, maxlen=n)) # derniers n caractères de l'erreur
def recover(tool: str, command: str, error: str, attempt: int):
if attempt >= 3:
return "stop_and_report"
d = decide(
context=f"TOOL: {tool}
COMMAND: {command}
ATTEMPT: {attempt}
ERROR:
{tail(error)}",
question="What is the best next move after this failure?",
options=RECOVERY,
threshold=0.8,
)
return d.answer if d.confident else "escalate_to_opus"
1RECOVERY = [2 "retry_unchanged", # réseau instable ou timeout3 "retry_after_install", # paquet ou outil manquant4 "fix_path_and_retry", # chemin de fichier ou cwd incorrect5 "switch_tool", # cet outil ne peut pas le faire, un autre si6 "escalate_to_opus", # nécessite un vrai débogage7 "stop_and_report", # intervention humaine requise8]
La limite stricte de tentatives vit dans le code, pas dans le modèle. Aucun modèle, aussi bon marché soit-il, ne devrait être autorisé à réessayer indéfiniment.
Chaque stratégie de récupération correspond à une petite fonction dans votre harness. retry_after_install extrait le paquet manquant de l'erreur via une regex et l'installe. fix_path_and_retry vérifie les chemins existants et suggère la correspondance la plus proche. Seul escalate_to_opus coûte vraiment de l'argent, et il ne se déclenche que lorsque l'échec exige une véritable réflexion.
Dans notre exemple, cela élimine 6 étapes de relance inutiles de la session.
Décision 4 : exécuter des vérifications ciblées avant la suite de tests complète
Celle-ci économise davantage de temps que d'argent, et c'est le temps qui donne l'impression qu'un agent est rapide.
Après chaque modification, la plupart des agents lancent toute la suite de tests. Si votre suite prend quatre minutes, votre agent passe quatre minutes à attendre après chaque édition, puis parcourt des centaines de lignes de logs pour trouver l'unique échec pertinent.
La solution reprend le même schéma que pour les notes : évaluez chaque fichier de test par rapport au diff, lancez les plus pertinents en premier, et n'exécutez la suite complète que si les vérifications ciblées passent.
1def pick_tests(diff: str, test_files: list[str], keep: int = 12):2 def score(path):3 probs = jev_choice(4 context=f"DIFF:\n{diff[:12000]}\n\nTEST FILE: {path}",5 question="Could this change break tests in this file?",6 options=["likely", "unlikely"],7 )8 return probs["likely"], path910 with ThreadPoolExecutor(max_workers=16) as pool:11 scored = sorted(pool.map(score, test_files), key=lambda s: s[0], reverse=True)12 return [p for _, p in scored[:keep]]1314def check(diff: str, test_files: list[str]):15 focused = pick_tests(diff, test_files)16 if not run_tests(focused):17 return False # échouer vite, corriger avant toute chose18 return run_tests(test_files) # la suite complète reste le garde-fou du commit
Relisez bien cette dernière ligne. La suite complète tourne toujours avant le moindre commit. Les vérifications ciblées sont une alerte précoce, pas un remplacement. Vous détectez la plupart des cassures en quelques secondes au lieu de minutes, sans jamais livrer un code que la suite complète aurait bloqué.
Ajoutez d'abord les vérifications bon marché : typage et linting uniquement sur les fichiers modifiés. Cela prend une seconde et intercepte une proportion surprenante d'erreurs avant même de lancer les tests.
L'assemblage : la boucle du harness
Voici comment les quatre décisions s'articulent au sein d'une étape de la boucle :
def run_step(task: str, step: str, state):
1. contexte : ne charger que les notes nécessaires à cette étape
notes = state.always_notes + pick_notes(step, state.notes)
2. routage : choisir le worker pour cette étape
worker = state.workers[route(step, state.recent_diff())]
result = worker.run(step, notes=notes, history=state.history)
3. récupération : gérer les échecs d'outils de cette étape
for failure in result.failures:
action = recover(failure.tool, failure.command, failure.error, failure.attempt)
state.apply_recovery(action, failure)
4. vérifications : tests ciblés d'abord, suite complète avant le commit
if result.diff:
state.log_check(check(result.diff, state.test_files))
Et voici le côté Opus : c'est simplement votre appel Opus 5.5 habituel. Placez votre contexte stable en premier (prompt système, définitions des outils, notes « always ») pour qu'il reste en cache d'une étape à l'autre, et mettez les éléments spécifiques à l'étape à la fin.
import os
import anthropic
client = anthropic.Anthropic()
OPUS = os.environ["OPUS_MODEL"] # l'id de votre modèle Opus 5.5
def opus_step(system: str, notes: list[dict], history: list, step: str):
notes_text = "
".join(n["text"] for n in notes)
return client.messages.create(
model=OPUS,
max_tokens=8000,
system=[{"type": "text", "text": system, "cache_control": {"type": "ephemeral"}}],
messages=history + [{"role": "user", "content": f"NOTES:
{notes_text}
STEP:
{step}"}],
)
Rien d'exotique. Les économies viennent de ce que vous cessez de lui envoyer, pas d'un prompt magique.
Une étape à la loupe
Voici à quoi ressemble une étape unique dans les logs une fois les quatre décisions activées. La tâche : ajouter une limitation de débit (rate limiting) sur l'endpoint public d'inscription. Cette trace est illustrative, mais c'est exactement la structure que vous retrouverez dans vos propres logs.
step 14 "add a per IP rate limit to POST /signup"
[notes] scored 41 chunks in parallel
kept: api/middleware.md (0.94), conventions/errors.md (0.88),
infra/redis.md (0.81), decisions/2025_auth.md (0.62)
dropped: 37 chunks, including billing, email templates, CI
[route] new_logic (0.91) → opus
[opus] plans the change, writes middleware + config + handler edit
[tool] npm test FAILED "Cannot find module 'bottleneck'"
[recover] retry_after_install (0.97) → npm install, rerun
[checks] typecheck changed files: pass
focused tests (12 of 1,388): pass
full suite: pass
Lisez-la de haut en bas et comptez combien de ces lignes nécessitaient auparavant un appel Opus complet. Le choix des notes : un gros appel, ou aucun tri et 30 000 tokens de notes chargés à l'aveugle. Le routage : rien, chaque étape allait à Opus. Le paquet manquant : une étape de raisonnement complète pour comprendre qu'un module absent signifie « installer le module ». Le choix des tests : rien, la suite complète à chaque édition.
Désormais, une seule ligne de cette trace concerne Opus, et c'est celle qui avait réellement besoin d'un modèle frontier : planifier et écrire le limiteur de débit.
C'est toute l'idée résumée en une image. Le modèle coûteux consacre son temps à la partie du travail que lui seul peut accomplir.
L'exemple détaillé : d'où viennent les 69 %
Voici le calcul complet pour une session de développement : 60 étapes d'agent plus les 6 relances inutiles qu'un agent classique accumule en chemin. Tous les prix correspondent aux tarifs publics actuels.
Avant : Opus 5.5 fait tout
Chaque étape charge 70 000 tokens de contexte : 15 000 pour le prompt système et les outils, 30 000 pour l'intégralité du dossier de notes, et 25 000 pour la conversation en cours. Je pars du principe que 80 % de cela correspond à un hit de cache. Chaque étape produit environ 1 500 tokens en output, car le mode réflexion est toujours actif sur Opus 5.5.
cache reads: 56,000 × $0.20/M = $0.0112
fresh input: 14,000 × $4.00/M = $0.0560
output: 1,500 × $20.00/M = $0.0300
per step = $0.0972
66 steps × $0.0972 = $6.42
Après : la couche de décision
Le contexte tombe à 46 000 tokens par étape, car Jev sélectionne 6 000 tokens de notes au lieu de charger les 30 000. Les 24 étapes purement décisionnelles passent chez Jev. Les 6 boucles de relance disparaissent. Et 12 des 36 étapes de travail restantes sont confiées à Haiku 4.5.
Opus 5.5: 24 steps × $0.0742 = $1.78
Haiku 4.5: 12 steps × $0.0169 = $0.20
Jev: 102 calls × 5,000 tokens
× $0.042/M, output free = $0.02
total = $2.00
De 6,42 $ à 2,00 $. Soit 68,8 % d'économie pour la même fonctionnalité.
définissez le seuil selon le coût d'une mauvaise réponse
Et voici la contribution de chaque levier, empilée dans l'ordre :
notes selection only $4.89 23.7% saved
- decisions moved to Jev $3.13 51.2% saved
- recovery paths $2.69 58.1% saved
- routing to a fast worker $2.00 68.8% saved
Deux remarques honnêtes concernant ces calculs.
Premièrement, ce sont des estimations basées sur des hypothèses explicites, pas une mesure de votre infrastructure. La taille de votre contexte, votre taux de hit de cache et votre nombre de décisions seront différents. L'intérêt de détailler chaque ligne est de vous permettre d'y substituer vos propres chiffres. Une fois votre avant/après réel mesuré, utilisez vos données, pas les miennes.
Deuxièmement, regardez où va réellement l'argent. Les 102 appels de Jev coûtent deux centimes au total. Les économies ne viennent pas du fait que Jev soit peu cher par appel. Elles proviennent de tout ce qui cesse de se produire une fois que Jev a tranché : le contexte gonflé, les étapes de raisonnement complètes pour des QCM, les boucles de relance et les appels au gros modèle pour des renommages.
Pourquoi ne pas simplement utiliser Haiku pour les décisions ?
Question légitime. Haiku 4.5 est bon marché et rapide. Pourquoi ajouter un nouveau modèle ?
Pour trois raisons.
Il génère toujours du texte. Haiku répond sous forme de texte. Vous devez le forcer via le prompt à répondre avec l'une de vos options, puis parser la réponse, puis gérer les cas où il ajoute une explication, choisit quelque chose hors de la liste ou noie la réponse dans une phrase. Jev renvoie une probabilité pour chaque option fournie. Rien à parser, rien hors de la liste.
Vous obtenez toute la distribution, pas juste une réponse. Quand Jev dit needed: 0.52, not_needed: 0.48, vous savez que c'est quitte ou double et votre harness peut escalader. Quand un modèle textuel répond « needed », vous ignorez totalement s'il en était certain. Les seuils ne fonctionnent que si vous voyez les probabilités.
Le calcul des coûts est différent. L'output de Jev est gratuit et son input coûte 0,042 $ le million de tokens. Évaluer 41 blocs de notes à chaque étape signifie 41 petits appels. Avec Jev, cela représente une fraction de centime. Avec n'importe quel modèle textuel, même bon marché, ce sont 41 générations avec leurs propres coûts d'output et leur latence.
Utilisez Haiku pour les petites modifications, là où il doit réellement écrire du code. Utilisez Jev pour choisir dans des listes. Utilisez Opus pour réfléchir. Chaque modèle fait le travail pour lequel il a été conçu.
Comment le déployer sans rien casser
N'activez pas les quatre décisions d'un coup. Voici l'ordre que je recommande.
Semaine 1 : le shadow mode. Gardez votre agent actuel tel quel. Pour chaque décision qu'il prend, posez aussi la même question à Jev et loguez les deux réponses ainsi que la probabilité de Jev. N'agissez jamais en fonction de la réponse de Jev.
1def shadow(decision_name, context, question, options, current_answer):2 probs = jev_choice(context, question, options)3 jev_answer = max(probs, key=probs.get)4 log_row(5 decision=decision_name,6 current=current_answer,7 jev=jev_answer,8 prob=probs[jev_answer],9 agree=(jev_answer == current_answer),10 )
Semaine 2 : analyser les désaccords. Concentrez-vous uniquement sur les lignes où Jev et votre agent actuel divergent. Triez-les par probabilité de Jev. Vous repérerez généralement une frontière nette : au-delà d'une certaine probabilité, Jev a raison aussi souvent qu'Opus. Cette frontière est votre seuil. Ces lignes de désaccord deviennent aussi votre jeu de test, constitué gratuitement à partir de votre trafic réel.
Semaine 3 : activer la sélection des notes. C'est le levier le plus puissant et le plus facile à annuler, puisqu'une note oubliée se repère très vite dans vos logs.
Semaine 4 : activer la récupération et les tests. Les deux ont des limites strictes et des replis codés en dur, le pire scénario étant donc de revenir à ce que vous faites aujourd'hui.
En dernier : le routage. Les erreurs de routage sont les plus visibles pour les utilisateurs, car une tâche complexe envoyée au worker rapide produit du mauvais code. Activez-le en dernier, avec un seuil prudent, et surveillez le taux d'échec des étapes du worker rapide.
Placez chaque décision derrière un flag on/off pour pouvoir l'annuler en une ligne.
Définir les seuils selon le risque
Appliquer un seuil unique à tout est une erreur. Définissez-les selon les conséquences d'une mauvaise réponse.
Une session de développement, même résultat : de 6,42 $ à 2,00 $
Faible enjeu, facile à annuler : 0,55 à 0,65. Sélectionner des notes. Ordonner des tests. Une mauvaise réponse coûte un peu de contexte ou quelques secondes.
Enjeu moyen : 0,8. Routage et récupération. Une mauvaise réponse coûte une étape ratée, que votre harness intercepte.
Fort enjeu, difficile à annuler : 0,9 ou jamais. Supprimer des fichiers. Faire un force push. Toucher à la configuration de production. Lancer une migration. Mon conseil sincère : ne laissez aucun modèle prendre ces décisions seul. Routez-les vers un humain, ou au minimum vers Opus avec une étape de confirmation.
Tout ce qui passe sous le seuil remonte la chaîne : vers Opus si cela demande du raisonnement, vers un humain si cela exige du jugement.
Les cas où cela n'aide pas
Cette architecture n'est pas un multiplicateur magique pour toutes les charges de travail.
Les tâches de pure génération changent peu. Si votre agent passe l'essentiel de son temps à écrire de grandes quantités de code inédit à partir d'un cahier des charges clair, il y a peu de décisions à déplacer. Vous bénéficierez des économies sur la sélection des notes, mais guère plus.
Les minuscules projets n'en ont pas besoin. Si votre dossier de notes entier pèse 2 000 tokens et que votre suite de tests tourne en huit secondes, le temps passé à construire ce système n'est pas encore rentable.
Jev n'est pas idéal pour trancher seul en dernier ressort. Il excelle pour repérer des détails et choisir dans une liste courte. Ce n'est pas le modèle à utiliser pour répondre d'un coup à « cette pull request est-elle prête à être mergée ? ». Découpez les grandes questions en petites, évaluez chacune, et combinez les résultats dans votre propre code avec vos propres pondérations.
Si vous disposez déjà de données étiquetées pour une question fixe, un petit modèle auto-hébergé peut battre Jev sur le prix. Jev brille lorsque les questions changent constamment et que vous n'avez pas de données d'entraînement, ce qui décrit la majorité des agents de code.
Les erreurs à éviter
Laisser le modèle écrire la liste d'options. Toute l'architecture repose sur des options exploitables par votre code. Si un modèle génère les options, vous retournez à la case départ : parser du texte libre.
Demander à Jev s'il est confiant. Lisez plutôt la probabilité. Une auto-évaluation sera presque toujours « oui ».
Aucun repli. Chaque décision de Jev nécessite une issue pour « pas sûr », et cette issue est Opus ou un humain, jamais une supposition.
Les limites de relance dans le prompt plutôt que dans le code. Un modèle à qui l'on dit « ne réessaie que 3 fois » réessaiera parfois 30 fois. Le code, non.
Supprimer la suite de tests complète. Les vérifications ciblées vous accélèrent. La suite complète vous maintient rigoureux. Gardez les deux.
Ne rien mesurer. Si tu ne notes pas le coût par session avant de commencer, tu ne sauras jamais si tu as économisé 20 % ou 70 %. Récupère d'abord tes données d'utilisation sur une semaine de travail normale. Ça prend dix minutes et c'est le seul chiffre qui compte vraiment.
Ce qu'il faut faire cette semaine
Voici la marche à suivre sous forme de checklist :
- Consigne une semaine de sessions d'agent : étapes, tokens, coûts, échecs.
- Repère les décisions cachées dans ta boucle : notes, routage, récupération, tests.
- Formule chacune d'elles sous forme de question avec une liste d'options fixe.
- Fais tourner Jev en mode shadow aux côtés de ton agent actuel pendant une semaine.
- Définis des seuils à partir du journal des désaccords, selon le niveau de risque.
- Active d'abord la sélection des notes, puis la récupération et les tests, et enfin le routage.
- Compare le coût par session avant et après. C'est ton indicateur clé.
Opus 5.5 est le meilleur modèle de raisonnement que j'aie utilisé pour le code. L'erreur, c'est de lui demander de tout faire.
Laisse-le réfléchir. Laisse Jev décider. Laisse ton code dicter les règles.
Si cet article t'a été utile, suis @cyrilXBT. Chaque semaine, je décortique comment construire avec les derniers modèles d'IA, chiffres réels à l'appui.
Ajoute cette page à tes favoris pour l'avoir sous la main quand tu te lanceras.
