Le conseil circule : montez le niveau d'effort Claude Opus 5.5 avant de changer de modèle. Il est juste, mais incomplet. Chaque cran coûte plus cher pour un gain plus faible, et le défaut est medium. Voici les chiffres d'Anthropic et une méthode pour choisir.
Que règle exactement le niveau d'effort, et quels niveaux existent sur Opus 5.5 ?
L'effort règle la quantité de travail que Claude fournit sur toute la réponse : réflexion, appels d'outils, vérification et longueur. Opus 5.5 accepte cinq niveaux : low, medium, high, xhigh et max. Le paramètre thinking, lui, décide seulement si Claude réfléchit.
Nous ne revenons pas ici sur la notion elle-même : elle est détaillée dans notre article « Voilà à quoi sert la notion d'effort dans Claude ». Retenez que la documentation officielle sur l'effort indique qu'Opus 5.5 prend en charge les cinq niveaux. Le niveau xhigh, placé entre high et max, est apparu avec Opus 4.7.
Ce réglage s'utilise dans l'API et dans Claude Code. Nous n'affirmons pas qu'un curseur équivalent existe dans l'interface grand public : nous ne l'avons pas vérifié.
Quel est le niveau d'effort par défaut d'Opus 5.5 ?
C'est medium. La documentation Anthropic précise que ce défaut vaut pour Opus 5.5 et Haiku 5.5, alors que la plupart des autres modèles Claude tournent à high. Une requête sans réglage d'effort reçoit donc ce traitement, et fixer medium explicitement revient exactement au même.
Le piège se trouve dans la migration. Vous passez de Sonnet 5.5 à Opus 5.5 en changeant seulement l'identifiant du modèle ? Vous avez, sans le savoir, baissé l'effort d'un cran. La documentation le dit aussi pour Opus 5 : les modèles Opus précédents sont à high, donc une requête qui omet l'effort tourne un niveau plus bas sur Opus 5.5.
Résultat possible : des réponses plus courtes, moins de vérifications, et l'impression que « le nouveau modèle est moins bon ». Avant de conclure, vérifiez le paramètre.
Combien coûte chaque cran d'effort, chiffres à l'appui ?
Chaque cran coûte plus cher que le précédent pour un gain plus petit. Sur un sous-ensemble de SWE-bench Pro, Opus 5.5 passe de 87,4 % de tâches résolues en low à 96,7 % en xhigh, mais le coût par tâche est multiplié par près de sept, de 0,11 $ à 0,74 $.
Voici le tableau publié par Anthropic sur sa page d'optimisation coût/intelligence, complété de deux colonnes que nous avons calculées :
| Niveau | Tâches résolues | Coût par tâche | Coût par point gagné vs niveau précédent | Coût par tâche résolue |
|---|---|---|---|---|
| low | 87,4 % | 0,11 $ | n/a | ≈ 0,13 $ |
| medium (défaut) | 92,8 % | 0,21 $ | ≈ 0,02 $ | ≈ 0,23 $ |
| high | 95,3 % | 0,29 $ | ≈ 0,03 $ | ≈ 0,30 $ |
| xhigh (un seul passage) | 96,7 % | 0,74 $ | ≈ 0,32 $ | ≈ 0,77 $ |
Comment lire ces chiffres ?
De medium à high, vous gagnez 2,5 points pour environ 0,08 $ de plus : c'est souvent rentable. De high à xhigh, vous gagnez 1,4 point pour plus de 2,5 fois le prix. De medium à xhigh, la facture est environ 3,5 fois plus élevée pour 4 points de mieux.
Autrement dit, le point supplémentaire coûte environ dix fois plus cher entre high et xhigh qu'entre medium et high. Le tableau ne donne pas de ligne pour max : nous n'avons aucun chiffre à vous proposer, donc ne le déployez pas sans test.
Notre avis : à volume égal, c'est la ligne « medium → high » qui mérite le premier test. Elle est la plus facile à justifier, et c'est souvent là que se joue la différence entre un défaut subi et un réglage choisi.
Quel niveau d'effort choisir selon la tâche ?
Le bon niveau est le plus bas qui donne un résultat acceptable, relevé sur vos propres tâches. Plus l'erreur coûte cher, plus on monte : un brouillon d'e-mail se contente de low ou medium, une revue de code ou un agent qui tourne longtemps justifie high ou xhigh.
Une grille de décision simple :
- Une erreur se corrige en dix secondes (brouillon, reformulation, tri) : low ou medium.
- Une erreur passe inaperçue et coûte cher (revue de code, analyse chiffrée, extraction de données) : high, puis xhigh si les tests le justifient.
- Un agent enchaîne beaucoup d'étapes : une erreur au début se propage, donc high ou xhigh se défendent. Mesurez quand même le coût total d'une exécution complète.
- Volume important, tâche répétitive : testez low avant tout. Sur des milliers d'appels, quelques centimes par tâche deviennent un vrai poste de dépense.
Plutôt que « toujours xhigh », visez un réglage par type de tâche. Le niveau d'effort se règle à chaque requête, et rien n'oblige à garder la même valeur partout.
Ces chiffres valent-ils pour mes propres tâches ?
Non, pas tels quels. Ce sont des benchmarks publiés par Anthropic sur des tâches de code, pas sur de la rédaction, du support ou de l'analyse. Ils donnent un ordre de grandeur et la forme de la courbe, pas le réglage optimal pour votre usage.
Trois précautions :
- Le résultat xhigh vient d'un seul passage. Un écart de 1,4 point sur une seule exécution demande de la prudence.
- Plus d'effort ne garantit pas mieux. Dans le même document, Fable 5.1 obtient 66 % en low et 65 % en high sur DeepResearch Bench II, pour un coût 1,5 fois plus élevé en high (4,48 $ contre 6,89 $). Sur cette tâche, monter l'effort n'a rien apporté.
- Plus d'effort donne des réponses plus longues, d'après Anthropic. Cela pèse sur la facture et sur le temps de relecture, y compris quand la qualité ne bouge pas.
Anthropic indique aussi que régler l'effort est souvent un meilleur levier que changer de modèle. Elle conseille d'essayer le modèle supérieur, Fable 5.1, seulement si les tests à xhigh ou max restent insuffisants. Nous partageons cette logique, avec une réserve : « souvent » n'est pas « toujours », et seul votre test le dira.
Comment tester son niveau d'effort en cinq tâches ?
Prenez cinq tâches réelles, lancez-les à medium, high puis xhigh, notez qualité, temps et coût, puis retenez le niveau le plus bas acceptable. La méthode tient en cinq étapes et, côté API, dans un script d'une vingtaine de lignes.
- Choisissez 5 tâches représentatives, pas 5 cas faciles : au moins une où l'erreur coûte cher, une très répétitive.
- Figez le reste : même prompt, même modèle, même configuration
thinking. Seul l'effort varie. - Lancez chaque tâche à medium, high et xhigh, idéalement 2 ou 3 fois pour lisser la variabilité.
- Notez qualité, temps et coût avec la même grille pour tous les essais.
- Retenez le niveau le plus bas acceptable. Montez d'un cran seulement sur les tâches où l'erreur coûte cher.
Script de mesure côté API (Python). L'identifiant du modèle et les prix sont à reprendre dans la documentation et la page de tarifs d'Anthropic ; vérifiez aussi la syntaxe du paramètre effort selon votre version du SDK.
import time
import anthropic
client = anthropic.Anthropic()
MODEL = "ID_OPUS_5_5" # à copier depuis la documentation Anthropic
PRIX_ENTREE = 0.0 # $ par million de tokens, à remplir
PRIX_SORTIE = 0.0 # $ par million de tokens, à remplir
TACHES = ["tâche 1...", "tâche 2...", "tâche 3...", "tâche 4...", "tâche 5..."]
for effort in ["medium", "high", "xhigh"]:
for i, tache in enumerate(TACHES, 1):
debut = time.time()
rep = client.messages.create(
model=MODEL,
max_tokens=16000,
messages=[{"role": "user", "content": tache}],
extra_body={"output_config": {"effort": effort}},
)
duree = time.time() - debut
cout = (rep.usage.input_tokens * PRIX_ENTREE
+ rep.usage.output_tokens * PRIX_SORTIE) / 1_000_000
print(f"{effort} | tâche {i} | {duree:.1f}s | {cout:.4f}$ | "
f"{rep.usage.output_tokens} tokens")
# Enregistrez rep.content[-1].text pour la notation à l'aveuglePour noter, utilisez une grille identique sur chaque réponse, idéalement à l'aveugle (sans voir le niveau d'effort utilisé) :
Tâche : [description]
Réponse n° : [id, sans mention du niveau d'effort]
1. Exactitude (0 à 5) : les faits, le code ou les calculs sont-ils justes ?
2. Complétude (0 à 5) : a-t-elle traité tout ce qui était demandé ?
3. Correction nécessaire (aucune / légère / lourde) : combien de temps pour la rendre utilisable ?
4. Verdict : acceptable en l'état (oui / non)Un détail que les tutoriels oublient : mesurez le coût de correction humaine, pas seulement le coût API. Une réponse low à 0,11 $ qui demande dix minutes de reprise coûte plus cher qu'une réponse high à 0,29 $ utilisable directement.
Que faire dès demain ?
Dès demain, vérifiez d'abord que vos requêtes Opus 5.5 ne tournent pas à medium par simple omission. Puis lancez le test des cinq tâches. Changez de modèle seulement si xhigh ne suffit pas.
Concrètement, dans cet ordre :
- Repérez où l'effort n'est pas précisé dans vos appels API et vos configurations Claude Code.
- Choisissez vos 5 tâches et lancez-les à medium, high et xhigh.
- Fixez un niveau par type de tâche, au plus bas acceptable.
- Relancez le test à chaque changement de modèle : un réglage valable aujourd'hui ne l'est pas forcément sur la prochaine version.
Mesurer avant de choisir un outil, c'est la logique de l'étape « Calcul du ROI » de la formation IA pour entreprises, construite sur mesure à partir d'un audit de vos besoins. Pour monter en compétence à titre individuel sur Claude, regardez la formation pour particuliers.
Questions fréquentes
Quel est le niveau d'effort Claude Opus 5.5 par défaut ?
Le niveau d'effort Claude Opus 5.5 par défaut est medium, comme pour Haiku 5.5. La plupart des autres modèles Claude sont à high par défaut. Fixer medium explicitement équivaut à ne rien préciser dans la requête.
Faut-il régler le niveau d'effort Claude Opus 5.5 sur xhigh ou max par défaut ?
Non. Sur le sous-ensemble de SWE-bench Pro publié par Anthropic, xhigh coûte plus de 2,5 fois le prix de high pour 1,4 point de plus. Réservez-le aux tâches où une erreur coûte cher, après test sur vos propres cas.
L'effort remplace-t-il le paramètre thinking ?
Non. Selon la documentation Anthropic, thinking décide si Claude réfléchit ou non, tandis que l'effort règle la quantité de travail fournie sur toute la réponse : réflexion, appels d'outils, vérification et longueur.
Quand changer de modèle plutôt que monter l'effort ?
Anthropic conseille d'essayer le modèle supérieur, Fable 5.1, seulement si les tests à xhigh ou max restent insuffisants sur vos tâches. Avant cela, régler l'effort est souvent un meilleur levier.