Et c'est ce que font la plupart des devs. Ils changent le model ID, ils gardent les mêmes paramètres par défaut, et ils se demandent pourquoi la facture monte alors que les résultats ressemblent à ce qu'ils avaient avant.
Décryptage.
Ce qui a changé sous le capot
Le taux d'erreur d'outils a été divisé par 3 par rapport à Opus 4.6 (confirmé par Box et Replit). La résolution image passe à 2 576 px. La cohérence sur contexte long est revenue. C'est pas juste "un meilleur modèle". C'est un modèle qui se comporte différemment.
La dérive qui faisait oublier les instructions de la première heure après deux heures de session, celle que j'avais documentée dans l'article sur la dégradation d'Opus 4.6, ne se reproduit plus. Du coup, un comportement différent demande une configuration différente.
Réglage 1 : le niveau d'effort
Opus 4.7 a introduit le cran xhigh, avec environ 20 000 tokens de raisonnement interne par requête. C'est le mode où le modèle réfléchit vraiment avant de répondre, au lieu de sortir la première solution plausible. Le laisser en xhigh en permanence, c'est du gaspillage. Ne pas l'activer sur les problèmes durs, c'est se priver du seul truc qui justifie le prix d'Opus.
Le piège : sur un refactoring trivial ou une génération de tests unitaires, tu paies 20 000 tokens de réflexion pour un résultat identique à celui d'auto. À l'inverse, demander un arbitrage d'architecture en auto, c'est vraiment passer à côté.
Niveau
Quand l'utiliser
low
Subagents simples, tâches mécaniques, formatage
medium
Refactoring, tests, réponses factuelles, tout ce qui est balisé
high
Débogage complexe, migration de code, feature non triviale
xhigh
Problème ouvert sans piste, décision d'archi critique, tâche longue
max
Opus 4.6 uniquement, raisonnement sans contrainte de tokens
Dans Claude Code, tu peux changer à la volée avec /effort xhigh ou /effort high. Pour fixer un niveau par défaut sur un projet, tu le mets dans .claude/settings.json :
{
"preferences": {
"effort": "xhigh"
}
}
Sur l'API (SDK Python/TypeScript ou appels directs), le paramètre passe dans le body de la requête. Attention : l'ancien format thinking: {type: "enabled", budget_tokens: N} est déprécié depuis Opus 4.6 et renvoie une erreur 400 sur 4.7+. Il faut utiliser l'adaptive thinking :
Les valeurs possibles : "low", "medium", "high" (défaut API), "xhigh" (nouveau sur Opus 4.7), "max" (Opus 4.6 uniquement). Anthropic recommande de démarrer à xhigh pour le coding et l'agentique, et de monter à max uniquement si les évals montrent un gain mesurable.
La latence monte, c'est le prix. Mais quand tu envoies un problème qui mérite vraiment 20 secondes de réflexion, la qualité de la première réponse change. Moins de va-et-vient, moins de corrections, au final moins de tokens consommés. J'utilise ce setup tous les jours sur Waku et ça se sent vraiment sur les sessions de plus d'une heure.
Réglage 2 : le cache prompt
Le cache prompt, c'est le réglage le plus rentable et le moins configuré que je vois chez les devs qui utilisent l'API. Sur les blocs qui ne changent pas d'un appel à l'autre (system prompt, docs de référence, historique figé), tu passes de 5 $ à 0,50 $ par million de tokens. Une réduction de 90%.
Ce réglage concerne uniquement les appels API directs (SDK Python/TypeScript, fetch, ou les plateformes comme Amazon Bedrock et Vertex AI). Dans Claude Code et sur claude.ai, le cache est géré automatiquement.
En pratique : si ton system prompt fait 4 000 tokens et que tu fais 100 appels dans la journée, sans cache tu paies 400 000 tokens d'entrée à plein tarif. Avec cache_control: ephemeral, tu paies le premier appel plein pot et les 99 suivants à 90 % de réduction. La différence se voit sur la facture du premier jour.
Deux contraintes : le cache expire au bout de 5 minutes sans accès (option 1 heure disponible moyennant surcoût), et il faut un minimum de 4 096 tokens pour qu'il s'active. En dessous, la requête passe mais sans mise en cache, et aucune erreur n'est renvoyée. Genre tu crois que ça cache, mais en fait non.
J'avais détaillé ma méthode complète de réduction de tokens dans cet article. Le cache en fait partie, mais à l'époque c'était sur Opus 4.6 et l'impact était déjà gros. Sur 4.7, avec des sessions plus longues et plus stables, le gain est encore plus net.
Réglage 3 : réécrire ses prompts pour l'instruction following
Opus 4.6 interprétait. Si ton prompt était vague, il comblait les trous, il devinait ce que tu voulais. Parfois juste, souvent approximatif. Opus 4.7 exécute. Si tu lui dis "génère des tests pour ce composant" sans préciser quoi couvrir, il va tester uniquement ce qui est explicitement visible dans le code. Pas d'inférence sur les edge cases, pas de supposition.
Au début, ça ressemble à une régression. Mais sur les sessions longues et les workflows agentiques, c'est exactement ce qui manquait. Un modèle qui suit les instructions à la lettre sur l'étape 5 d'un plan en 6 étapes, au lieu de prendre un raccourci parce qu'il "pense savoir" ce que tu veux.
Trois ajustements dans la façon de rédiger :
Avant (4.6)
Après (4.7)
"Teste le composant"
"Teste le composant : cas nominal, cas d'erreur réseau, cas de props manquantes"
"Refactorise ce fichier"
"Refactorise ce fichier : extraire la logique métier dans un service, garder le controller mince, conserver l'interface publique"
"Corrige le bug"
"Corrige le bug : le state ne se reset pas après submit, vérifier le useEffect cleanup"
Ça prend 2 minutes de plus par prompt. Mais ces 2 minutes remplacent les 15 minutes de corrections qu'on passait après coup sur 4.6. Sur Waku, j'ai vraiment senti la différence : les sessions sont plus propres parce que le modèle fait exactement ce que tu lui demandes, pas ce qu'il pense que tu veux.
Réglage 4 : la vision haute résolution
La résolution native d'Opus 4.7 est passée à 2 576 pixels, contre environ 685 sur 4.6. CharXiv Reasoning monte à 91 % avec les outils (84,7 % avant). Envoyer un screenshot au lieu de décrire un bug en prose, ça prend 2 secondes et ça donne un résultat hyper précis.
Avant 4.7, passer un screenshot de code ou d'interface à Claude, c'était un pari. La compression dégradait les détails, le modèle ratait des caractères, les petits textes dans les diagrammes passaient à la trappe.
Dans Claude Code, tu glisses un fichier image directement dans le terminal, ou tu utilises @chemin/vers/screenshot.png dans ton prompt. Le modèle reçoit l'image en haute résolution sans manipulation.
Sur l'API, tu passes l'image en base64 dans le champ content d'un message :
Opus 4.7 coûte 5x plus cher que Sonnet en entrée. Sur un résumé, une reformulation ou une génération de tests standards, Sonnet donne le même résultat. C'est payer le prix d'un chirurgien pour poser un pansement.
Tâche
Sonnet
Opus 4.7
Latence critique (temps réel, UI)
Oui
Non
Tâche bien définie, peu d'ambiguïté
Oui
Non
Raisonnement multi-étapes complexe
Non
Oui
Session longue (>50k tokens, cohérence requise)
Non
Oui
Agent autonome sur plusieurs heures
Non
Oui
Tests unitaires, formatage, résumé
Oui
Non
Bug subtil sans piste claire
Non
Oui
La règle que je me donne : si je peux écrire la spec complète de la tâche en moins de 500 tokens et que je sais à quoi doit ressembler la sortie, c'est Sonnet. Si la tâche demande du jugement, de la nuance ou plusieurs tours de raisonnement, c'est Opus.
Box a mesuré 30 % de réduction de coûts en passant de 4.6 à 4.7 à qualité égale. Une partie vient du modèle lui-même (moins d'appels, moins d'erreurs). L'autre partie vient du routing. J'ai détaillé cette logique dans mon article sur l'architecture des agents de code IA, et le setup complet de mon workflow dans mon retour sur Claude Code.
Mon setup depuis le 16 avril
Réglage
Ce que je fais
Gain
Effort
xhigh pour l'archi et les bugs sans piste, high pour le reste
Meilleure qualité première réponse, moins de va-et-vient
Cache
Activé sur tous les system prompts API
Visible dès le premier jour, ~90% sur les blocs cachés
Instruction following
Prompts réécrits avec contraintes explicites
2 min de plus à la rédaction, 15 de moins en corrections
Vision
Screenshots directs pour UI, métriques, diagrammes
Plus de descriptions en prose inutiles
Routing
Sonnet pour les tâches balisées, Opus pour le jugement
Facture divisée sans perte de qualité
La dérive de contexte long d'Opus 4.6 avait cassé ma confiance dans les sessions de plus d'une heure. Ce problème-là est réglé. Tout le reste, c'est de la configuration.
Et toi, tu as trouvé un setup différent qui marche mieux sur tes projets ? Commentaires en dessous ou sur X.
Alex
À retenir
Le niveau d'effort xhigh est le bon défaut pour le coding complexe et l'agentique. Le laisser sur auto pour un problème d'archi, c'est se priver du seul truc qui justifie le prix d'Opus.
Le cache prompt réduit de 90% les coûts d'entrée sur les blocs répétés (system prompts, docs). Minimum 4 096 tokens pour qu'il s'active. Le gain est visible dès le premier jour.
Opus 4.7 exécute au lieu d'interpréter. Des prompts explicites avec contraintes nommées remplacent les 15 minutes de corrections qu'on passait sur 4.6.
La vision haute résolution (2 576 px) rend les screenshots plus utiles que les descriptions en texte pour les bugs visuels, les diagrammes et les dashboards.
Le routing Sonnet/Opus divise la facture sans perte de qualité : Sonnet pour les tâches balisées, Opus pour le jugement et les sessions longues.
