Opus 5 relit son propre code avant de te le rendre. C'est la meilleure nouvelle de cette version, et c'est aussi ce qui a fait grimper notre facture le premier jour. On a migré notre workflow Claude Code d'Opus 4.8 vers Opus 5 trois jours après la sortie du 24 juillet : changer l'identifiant claude-opus-4-8 en claude-opus-5 prend dix secondes, le reste a pris un après-midi. Deux choses ont cassé — nos instructions de vérification dans CLAUDE.md, devenues redondantes et coûteuses, et un appel API qui renvoyait une 400 parce qu'on coupait la réflexion tout en réclamant l'effort xhigh. Voici le détail, config à l'appui.
Le swap d'identifiant, puis les vrais problèmes
Opus 5 garde la grille tarifaire d'Opus 4.8 : 5 $ le million de tokens en entrée, 25 $ en sortie, réflexion active par défaut et effort réglé sur high. La fenêtre de contexte monte à 1M de tokens, valeur par défaut comme maximum — il n'existe pas de variante plus courte. Dans Claude Code, le basculement tient en une ligne :
/model claude-opus-5
Jusqu'ici, rien de piégeux. Les ennuis commencent quand le modèle se met à travailler comme il l'entend, pas comme ton ancien CLAUDE.md le lui dictait.
Piège 1 : Opus 5 se vérifie seul, tes instructions doublent le travail
Opus 5 se relit sans qu'on le lui demande : il repasse sur ses diffs, délègue davantage à des sous-agents, et produit des réponses plus longues que 4.8. Si ton CLAUDE.md transporte encore les rituels de vérification écrits pour l'ancien modèle, tu paies deux fois le même contrôle — une fois parce que tu l'as demandé, une fois parce que le modèle le fait de toute façon. Résultat : des sorties plus verbeuses, plus de tokens, une facture qui monte. Sans gain de qualité.
Ce qu'on trimballait, hérité de 4.8 :
## Avant de rendre du code
- Relis chaque fichier modifié, ligne par ligne.
- Relance la suite de tests deux fois pour confirmer.
- Rédige un résumé des risques après chaque changement.
Ce qu'on a gardé pour Opus 5 :
## Avant de rendre du code
- Lance la suite de tests une fois.
- Signale uniquement les tests rouges.
Sur une session de feature classique — un CRUD avec validation et tests —, retirer ces trois lignes a fait baisser nos tokens de sortie d'environ un quart. Le code rendu était de qualité identique. La leçon tient en une phrase : ne dis plus à Opus 5 de vérifier, il le fait mieux quand tu le laisses tranquille.
Piège 2 : l'erreur 400 sur xhigh et max
L'échelle d'effort va de low à max, en passant par medium, high et xhigh, avec la réflexion active par défaut. Le piège est logique une fois qu'on l'a vu : si tu désactives la réflexion et que tu réclames quand même xhigh ou max, l'API renvoie une 400, parce que les deux se contredisent. Un effort élevé, c'est précisément du raisonnement étendu — le couper puis en exiger le maximum n'a pas de sens.
Ce qui casse :
# 400 Bad Request — réflexion coupée mais effort maximal demandé
client.messages.create(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "disabled", "effort": "xhigh"},
messages=[...],
)
Ce qui passe :
client.messages.create(
model="claude-opus-5",
max_tokens=16000,
thinking={"type": "enabled", "effort": "xhigh"},
messages=[...],
)
Si tu veux vraiment couper le raisonnement, pour une tâche mécanique où il ne sert à rien, plafonne l'effort à medium. Au-delà, garde la réflexion active. C'est le genre d'erreur qui ne se voit pas en relisant le code, seulement en lisant le message d'erreur.
Quel effort pour quoi, dans notre usage
On a fini par calibrer l'effort par type de tâche, plutôt que de laisser high partout. Voici la grille qu'on applique après trois jours d'usage réel — elle vaut pour nos projets, pas comme vérité universelle :
| Tâche | Effort | Pourquoi |
|---|---|---|
| Renommage, refactor mécanique |
low / medium
|
rien à gagner côté raisonnement, on économise |
| Feature CRUD standard + tests |
high (défaut) |
le bon compromis coût/qualité |
| Bug de concurrence, choix d'archi | xhigh |
le raisonnement étendu paie vraiment |
| Presque rien | max |
rarement : le coût grimpe pour un gain marginal |
Le fast mode mérite un mot : deux fois et demie plus rapide, à 10 $/50 $ le million, mais disponible sur l'API Claude seulement — ni Bedrock, ni Vertex, ni Foundry. Pour une boucle d'itération serrée, le gain de latence vaut le surcoût. Pour un batch de nuit, non.
Le bilan, après trois jours
La migration technique se résume à un identifiant, deux pièges et une grille d'effort. Le vrai travail est ailleurs. Il faut désapprendre les réflexes de 4.8 : arrêter de sur-instruire un modèle qui en fait déjà plus tout seul. Détail utile au passage, le cache de prompt se déclenche désormais dès 512 tokens contre 1 024 avant — sur un CLAUDE.md volumineux, ça se sent sur la facture. On continue de mesurer, et on ajustera la grille quand on aura plus de recul sur les tâches longues.
Si tu montes une équipe sur Claude Code et que tu veux éviter de repayer ces trois jours de tâtonnement, on a condensé nos réglages dans notre formation Claude Code. Et si tu hésites encore entre Claude Code et Cursor pour ce genre de workflow, notre comparatif tranche.
Prochaine étape de notre côté : vérifier si xhigh tient ses promesses sur une refonte d'archi complète, pas seulement sur un bug isolé. On publiera les chiffres.
Top comments (0)