Claude Opus 5 : quel niveau d’effort choisir ?

Claude Opus 5 est le modèle premium d’Anthropic pour le développement complexe, les agents et les usages en entreprise. Lancé le 24 juillet 2026, il tient une promesse simple : offrir une grande partie des capacités de Fable 5 au tarif historique d’Opus.

Sur le prix, passer d’Opus 4.8 à ce modèle paraît évident. Son adoption en production demande toutefois plus de précautions. Le raisonnement fonctionne désormais par défaut, le niveau d’effort détermine la quantité de travail consacrée au texte comme aux outils, et une ancienne limite de sortie peut interrompre une tâche avant la fin du raisonnement.

Claude Opus 5, le modèle premium du quotidien plutôt que le plafond absolu

Opus 5 convient aux tâches difficiles qui reviennent chaque jour. Sonnet 5 reste préférable lorsque le volume et la latence priment. Fable 5 ne se justifie que si une tâche a déjà échoué lors d’une évaluation avec Opus et si cet échec coûte plus cher que le surcoût de 2x par token.

Cette hiérarchie correspond aussi à la manière dont Anthropic présente désormais sa gamme. Son guide actuel des modèles recommande aux développeurs indécis de commencer par Opus 5 pour le développement agentique complexe et les usages en entreprise, puis de passer à Fable 5 lorsque le niveau de capacité maximal devient nécessaire.

Opus 5 dispose d’une fenêtre de contexte de 1 million de tokens et d’une sortie synchrone maximale de 128,000 tokens. La fenêtre de contexte désigne les informations que le modèle peut garder à l’esprit pendant une requête ; elle ne garantit pas que chaque token bénéficiera de la même attention. La limite de sortie englobe à la fois le raisonnement masqué et la réponse visible, un point crucial lors de la migration.

L’identifiant du modèle est claude-opus-5. Il est disponible via l’API Claude, Amazon Bedrock, Google Cloud et Microsoft Foundry. Dans l’application Claude, Anthropic en a fait le modèle par défaut de l’offre Max et le modèle le plus puissant accessible avec l’offre Pro.

Il ne s’agit pas d’un classement définitif, mais d’une politique de routage capable de résister à la prochaine génération de modèles : chaque changement doit découler des résultats observés sur la charge de travail, et non d’une préférence pour une gamme.

Le vrai benchmark : le coût par tâche réussie

Le résultat le plus utile de Claude Opus 5 dans les benchmarks n’est pas sa capacité à tout dominer. C’est le fait qu’il atteint souvent le même résultat accepté avec une exécution moins chère.

Anthropic publie cinq résultats déterminants pour la décision :

• Sur Frontier-Bench v0.1, Opus 5 fait plus que doubler les performances d’Opus 4.8, avec un coût par tâche inférieur.
• Sur CursorBench 3.2, Opus 5 avec l’effort max termine à moins de 0.5% du meilleur résultat de Fable 5, pour un coût par tâche divisé par deux.
• Sur ARC-AGI 3, son score équivaut à trois fois celui du deuxième meilleur modèle de la comparaison d’Anthropic.
• Sur Zapier AutomationBench, son taux de réussite atteint environ 1.5 fois celui du deuxième meilleur modèle à coût par tâche identique. Même au niveau d’effort le plus bas, il réussit davantage de tâches que tout autre modèle de cette comparaison.
• Sur OSWorld 2.0, il dépasse le meilleur résultat de Fable 5 en utilisation d’ordinateur, pour un peu plus d’un tiers du coût.

Ces chiffres sont des résultats de lancement publiés par le fournisseur, et non un classement universel valable pour chaque dépôt, document de politique interne ou workflow dans un navigateur. Ils indiquent que des tokens supplémentaires peuvent, via le réglage d’effort, se transformer en travail accepté. Ils ne disent pas combien de tentatives votre propre agent nécessitera, à quelle fréquence une personne rejettera sa réponse, ni si un résultat plus rapide mais légèrement moins bon conviendra mieux à votre objectif de niveau de service.

Le coût par tâche réussie intègre ces dimensions manquantes. Additionnez le coût en tokens de toutes les tentatives, les frais liés aux appels d’outils, la latence qui a un impact sur le produit et la revue humaine. Divisez ensuite ce total par le nombre de résultats qui respectent vos critères d’acceptation.

Pour un agent de développement, réussir peut signifier que les tests passent, que le diff reste dans le périmètre demandé et qu’un reviewer l’accepte sans cycle de correction. Pour un agent opérationnel, il peut s’agir de mettre à jour le bon enregistrement, de demander l’approbation adéquate et de ne prendre aucune initiative non autorisée. Le barème doit décrire le résultat attendu avant toute comparaison des niveaux d’effort.

L’intelligence apparente du modèle n’est pas la bonne métrique. Ce qui compte, c’est un résultat accepté à un coût connu.

À charge fixe, le coût atteint $9, $22.50 ou $45

À volume de tokens identique, Opus 5 se place exactement entre le tarif temporaire de Sonnet 5 et celui de Fable 5.

Prenons 100 tâches. Chacune envoie 20,000 tokens en entrée et reçoit 5,000 tokens en sortie. Le lot consomme 2 millions de tokens en entrée et 500,000 tokens en sortie :

• Sonnet 5, à son tarif de lancement de $2 en entrée et $10 en sortie, coûte $9.
• Opus 5, à $5 en entrée et $25 en sortie, coûte $22.50.
• Fable 5, à $10 en entrée et $50 en sortie, coûte $45.

Le calcul repose sur les tarifs actuels de l’API Anthropic. Le tarif de $2/$10 de Sonnet 5 reste en vigueur jusqu’au 31 août 2026 ; il passera ensuite au prix standard de $3/$15. Ce calcul exclut la mise en cache des prompts, les remises sur les traitements par lots, la recherche web, l’exécution de code, les nouvelles tentatives ainsi que toute variation du nombre de tokens due au modèle ou au niveau d’effort.

À cette petite échelle, Opus coûte $13.50 de plus que Sonnet, tandis que Fable coûte $22.50 de plus qu’Opus. Sur tout le lot, il suffit qu’Opus évite une seule correction d’une valeur supérieure à $13.50 pour justifier son surcoût par rapport à Sonnet. De son côté, Fable doit éviter plus de $22.50 d’échec ou de revue pour rentabiliser le palier supplémentaire.

Avec 10,000 tâches de même profil, les totaux passent à $900, $2,250 et $4,500. Opus dépasse alors Sonnet de $1,350, et Fable ajoute encore $2,250. Un choix de routage anodin pendant le prototype devient une ligne budgétaire au passage en production.

Le mode Fast rend la différence encore plus nette. Il exécute Opus 5 environ 2.5 fois plus vite au tarif de $10/$50, soit deux fois le prix normal. Dans l’exemple des 100 tâches, le coût atteindrait $45, exactement le même total de base en tokens que Fable 5. Réservez-le aux cas où le temps de réponse crée assez de valeur pour justifier ce surcoût, pas comme accélérateur activé par défaut.

Le mode effort de Claude est une politique, pas un budget de tokens

Commencez par high. C’est le réglage par défaut de l’API Claude et de Claude Code, et Anthropic précise que définir explicitement high produit le même comportement que l’absence du paramètre d’effort.

Le niveau d’effort détermine le travail que Claude consacre à l’ensemble de la réponse : texte visible, raisonnement, appels d’outils et arguments de fonctions. Le réduire peut diminuer la consommation de tokens et l’activité des outils ; l’augmenter peut permettre une exploration plus approfondie. Il reste toutefois un signal comportemental, pas une limite stricte : une requête difficile soumise avec low peut malgré tout déclencher du raisonnement.

Les cinq niveaux répondent à des besoins distincts :

low convient aux tâches peu coûteuses et bien délimitées. Utilisez-le pour la classification, l’extraction, les transformations simples et les tâches étroites confiées à des sous-agents dont la sortie se vérifie facilement. Un agent de tri qui choisit la file d’un ticket s’y prête mieux qu’un agent chargé de résoudre ce ticket.

medium offre l’équilibre adapté à la production. Il convient aux tâches ordinaires assistées par des outils, lorsque le parcours est connu mais que les données changent : résumer le dossier d’un client, rédiger une réponse standard ou appliquer une procédure opérationnelle bien définie. C’est le premier cran à tester sous le réglage par défaut quand le coût en tokens ou la latence devient prioritaire.

high est le réglage par défaut des tâches quotidiennes difficiles. Choisissez-le pour les modifications de code, les analyses nuancées et les agents en plusieurs étapes, lorsque le coût des erreurs justifie un raisonnement attentif. C’est le meilleur point de mesure initial, car tous les niveaux supérieurs ou inférieurs peuvent ensuite lui être comparés.

xhigh vise les travaux de longue durée. Anthropic le destine aux tâches agentiques ou de développement susceptibles de durer plus de 30 minutes avec des budgets de tokens qui se comptent en millions. Il devient pertinent lorsque le modèle doit explorer plusieurs pistes, appeler de nombreux outils ou conserver un plan pendant une longue exécution.

max constitue une voie d’exception. Il lève les contraintes sur la dépense de tokens afin de rechercher le niveau de capacité maximal. Une tâche ne devrait y accéder qu’après un échec avec xhigh, ou lorsque sa valeur rend l’efficacité en tokens secondaire.

Deux erreurs sont faciles à commettre.

Premièrement, n’utilisez pas le réglage d’effort pour contrôler la longueur du texte. D’après la documentation d’Anthropic, le modifier ne raccourcit pas de manière fiable la réponse visible d’Opus 5. Indiquez plutôt la longueur attendue dans le prompt.

Deuxièmement, ne lancez pas toutes les tâches qui semblent difficiles avec max. Vous ne sauriez jamais si high aurait suffi, et toute discussion ultérieure sur les coûts resterait hypothétique. La comparaison utile porte sur le réglage le plus bas qui atteint le résultat de manière fiable, pas sur le meilleur score qu’il est possible d’acheter.

Qui devrait choisir Opus 5, Sonnet 5 ou Fable 5 ?

La plupart des acheteurs ne devraient pas imposer un modèle unique à toutes les requêtes. Mieux vaut définir un choix par défaut et une voie d’escalade étroite.

Pour le fondateur d’une start-up financée qui développe un produit agentique

Utilisez Sonnet 5 pour les interactions à fort volume faciles à valider, et Opus 5 pour les étapes qui planifient, réconcilient des informations contradictoires ou reprennent le contrôle après l’échec d’un outil.

Le principal risque consiste à utiliser Opus à chaque tour sous prétexte qu’il semble plus sûr. Si la majorité des requêtes suit un parcours prévisible, ce surcoût finance des tâches qui n’en avaient jamais besoin. Gardez la voie économique aussi large que possible et réservez Opus aux étapes lourdes de conséquences.

Pour une orchestration complexe, commencez avec Opus et l’effort high. Ne faites passer une catégorie difficile connue à xhigh que si la progression du taux d’acceptation couvre la consommation de tokens supplémentaire. N’envoyez une tâche à Fable qu’après l’échec d’Opus sur un cas représentatif et si l’impact métier justifie un prix unitaire de 2x.

Pour le CTO d’une ETI qui standardise la couche de modèles

Faites d’Opus 5 le choix premium par défaut et rendez le routage des modèles explicite dans la politique interne. Le responsable d’une charge de travail doit pouvoir expliquer pourquoi une tâche utilise Sonnet, Opus ou Fable, et quelle évaluation ferait évoluer cette décision.

Ne migrez pas toutes les requêtes Opus 4.8 en changeant simplement une chaîne de modèle. Le raisonnement par défaut modifie à la fois la sortie et la consommation de tokens. Les réglages max_tokens existants, la conception des conversations mises en cache et les prompts de vérification doivent tous être réexaminés.

L’analyse de Claude Sonnet 5 fournit la borne basse utile : Sonnet l’emporte tant que ses résultats acceptés se maintiennent à son prix actuel. Fable représente la borne haute. Opus occupe l’espace entre les deux, jusqu’à ce qu’une charge de travail donnée démontre la supériorité de l’une de ces bornes.

Pour le responsable opérationnel expérimenté qui automatise les processus métier

Opus est indiqué lorsqu’une tâche traverse plusieurs systèmes ou limites de politique interne. Lire une demande, vérifier un compte, appliquer une règle et décider si une personne doit approuver l’action s’avère plus difficile que rédiger un résumé, car chaque étape modifie les conséquences de la suivante.

Utilisez medium pour une procédure stable avec des outils bien délimités. Passez à high si les exceptions, les dossiers ambigus ou les règles contradictoires sont fréquents. Conservez une approbation humaine pour les actions irréversibles, même si les benchmarks sont solides. Un meilleur modèle réduit les revues ordinaires ; il ne supprime pas la responsabilité.

Fable ne devient raisonnable que pour une tâche à la fois exceptionnellement difficile et exceptionnellement précieuse. Si une personne contrôle systématiquement chaque résultat, investir davantage dans le modèle peut être moins rentable que d’améliorer l’interface de revue.

Pour le développeur indépendant

Commencez avec Sonnet 5 tant que la forme du produit évolue. Confiez à Opus 5 le débogage difficile, la revue d’architecture et les implémentations qui traversent plusieurs fichiers. L’écart compte surtout lorsqu’un échec oblige à reconstruire un contexte coûteux, beaucoup moins pour une petite modification.

Le choix plus large entre fournisseurs reste une décision distincte. GPT-5.6 et Claude Sonnet 5 diffèrent par leurs systèmes d’exécution autant que par la qualité des modèles. Opus 5 renforce la voie premium d’Anthropic, sans rendre pour autant interchangeables l’orchestration, les autorisations d’outils ou l’observabilité.

Pour ces quatre profils, le point de bascule est identique : montez en gamme lorsque le coût mesuré des échecs et de la revue dépasse le surcoût du modèle. Si personne n’a chiffré ce coût, la décision métier prudente consiste à évaluer avant d’augmenter le niveau.

Migrer depuis Opus 4.8 : deux changements incompatibles

Remplacer claude-opus-4-8 par claude-opus-5 conserve le même prix unitaire de $5/$25, mais pas le même comportement à l’exécution.

Le premier changement concerne le raisonnement par défaut. Opus 4.8 pouvait fonctionner sans raisonnement, sauf activation explicite dans la requête. Opus 5 décide désormais par défaut quand raisonner et jusqu’où. Comme max_tokens plafonne à la fois le raisonnement et la réponse visible, une limite qui suffisait largement à Opus 4.8 peut interrompre un agent Opus 5 avant qu’il ait terminé.

Le second changement touche l’interaction entre raisonnement et effort. Si une requête désactive le raisonnement tout en définissant xhigh ou max, l’API renvoie une erreur HTTP 400. Lorsque le raisonnement doit rester désactivé, limitez l’effort à high ou moins ; au-delà, retirez le champ qui désactive le raisonnement.

Anthropic prévient aussi que la désactivation du raisonnement peut parfois conduire Opus 5 à écrire un appel d’outil comme du texte ordinaire ou à exposer des balises XML internes au lieu d’émettre le bloc tool_use attendu. Laissez le raisonnement activé dans la mesure du possible et maîtrisez les dépenses avec le niveau d’effort.

Voici une requête Python valide pour une tâche agentique ou de développement prolongée :

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

La limite de 64,000 tokens est le point de départ recommandé par Anthropic pour xhigh ou max, pas une obligation pour chaque requête. Réduisez-la après avoir observé la consommation réelle et la capacité du modèle à terminer.

Attendez-vous aussi à des différences qualitatives. Selon Anthropic, Opus 5 tend à produire des livrables plus longs, à commenter davantage sa progression pendant les sessions agentiques, à déléguer plus volontiers à des sous-agents et à vérifier son travail sans instruction distincte. Ces comportements peuvent être utiles, mais une interface agentique, un pipeline de logs ou une couche d’orchestration conçus autour du comportement plus discret d’Opus 4.8 peuvent nécessiter des ajustements.

Trois paramètres de production qui déterminent la facture

Effort, mise en cache et vitesse interagissent. Optimiser l’un séparément peut dégrader les deux autres.

Conserver le même effort dans une conversation mise en cache

Modifier output_config.effort entre deux requêtes change le prompt rendu par Anthropic. La requête suivante ne conserve donc pas le préfixe mis en cache. Un système qui augmente et réduit l’effort au sein d’une longue conversation risque de perdre les économies de cache qu’il espérait réaliser.

Choisissez un niveau d’effort au début d’une session dépendante du cache, puis conservez-le. Si le travail ultérieur exige un autre niveau, routez-le vers une nouvelle conversation ou intégrez la perte du cache au coût de l’escalade.

Opus 5 abaisse la taille minimale d’un prompt pouvant être mis en cache de 1,024 tokens avec Opus 4.8 à 512 tokens. La mise en cache devient ainsi accessible à des instructions répétées plus courtes, à condition que le préfixe du prompt et le niveau d’effort restent stables.

Acheter le mode Fast pour la latence, pas pour la capacité

Le mode Fast est environ 2.5 fois plus rapide que le mode normal et coûte $10/$50 par million de tokens. Il ne transforme pas Opus en Fable. Dans l’exemple fixe de 100 tâches, il fait passer le total d’Opus de $22.50 à $45 avant mise en cache ou nouvelles tentatives.

Le mode Fast est proposé en research preview sur l’API Claude. Il n’est actuellement disponible ni sur Amazon Bedrock, ni sur Google Cloud, ni sur Microsoft Foundry. Une architecture multicloud ne peut donc pas supposer que ce réglage de vitesse suivra partout le modèle.

Considérer les nouvelles commandes bêta comme des fonctions bêta

La modification des outils en cours de conversation permet à une application d’ajouter ou de retirer des outils entre deux tours tout en conservant le cache du prompt. Cette fonction utilise l’en-tête bêta mid-conversation-tool-changes-2026-07-01.

Les fallbacks automatiques peuvent rediriger une requête Opus 5 ou Fable 5 signalée par un classificateur vers une solution de repli recommandée par Anthropic, au lieu de la bloquer. Les listes de fallback par défaut et explicites utilisent l’en-tête bêta server-side-fallback-2026-07-01.

Ces deux commandes résolvent des problèmes opérationnels, mais elles changent aussi ce qu’une même session logique peut faire et le modèle susceptible de répondre. Testez les changements d’autorisations, la gestion des échecs et la qualité des sorties avant de les activer sur un workflow irréversible.

Tester les cinq niveaux d’effort avant le déploiement

Une évaluation de 375 exécutions suffit pour transformer le réglage d’effort en données de routage : 25 tâches représentatives, cinq niveaux d’effort et trois répétitions de chaque combinaison.

Les répétitions sont indispensables, car un agent peut réussir une fois par chance, puis échouer en empruntant un autre parcours d’outils. La composition du jeu de tâches compte davantage que sa taille. Il doit réunir du travail ordinaire, des cas limites connus et des échecs ayant déjà nécessité une correction humaine.

Pendant ce test, ne changez pas l’effort au milieu d’une session si la production repose sur la mise en cache du prompt. Testez chaque niveau dans une conversation stable, faute de quoi les pertes de cache introduiront une variable non contrôlée.

Un résultat utile pourrait montrer que medium suffit au traitement courant des comptes, que high est nécessaire pour les exceptions et que xhigh améliore une catégorie étroite de débogage. Il ne justifierait pas xhigh partout, mais trois routes aux profils économiques différents.

La même méthode détermine si Fable 5 mérite son prix. N’ajoutez Fable qu’aux tâches qui restent sous le seuil avec Opus. Si Fable n’améliore pas assez l’acceptation pour couvrir son surcoût de $22.50 dans l’exemple des 100 tâches, conservez Opus.

Une frontière de sécurité différente de celle de Fable 5

Claude Opus 5 est moins restrictif que Fable 5 pour les activités légitimes de sécurité, sans pour autant être un modèle cyber sans limites.

Anthropic indique que les classificateurs cyber d’Opus 5 devraient intervenir environ 85% moins souvent que ceux de Fable 5. Le modèle peut trouver des vulnérabilités dans du code source, tandis que les garde-fous bloquent l’analyse de vulnérabilités dans des fichiers binaires, les tests d’intrusion et la génération d’exploits. Il reste aussi derrière Mythos 5 en cybersécurité offensive et en recherche biologique.

Cette frontière compte pour les agents de débogage et de sécurité. Une revue du code source peut aboutir, tandis qu’une étape ultérieure de validation d’exploit sera refusée ou redirigée. Concevez le workflow pour qu’un refus soit un état géré, et non une erreur de parsing inattendue.

Le Cyber Verification Program permet aux entreprises et chercheurs éligibles d’accéder à une version moins limitée sur le plan de la sécurité. Les utilisateurs ordinaires ne doivent pas concevoir un workflow de production autour de cette possibilité avant d’avoir obtenu la confirmation de leur accès.

L’audit comportemental interne d’Anthropic attribue à Opus 5 un score de 2.3 pour l’ensemble des comportements désalignés, le plus faible de ses modèles récents. Il s’agit d’un élément probant sur la propre suite de tests d’Anthropic, et non d’une autorisation à supprimer les approbations, le sandboxing ou le principe du moindre privilège pour les outils.

La décision

Claude Opus 5 devrait remplacer Opus 4.8 pour les nouvelles charges de travail premium et pour la plupart des charges existantes après une migration progressive. Il coûte le même prix, monte en puissance de façon plus fiable avec le niveau d’effort et se rapproche de Fable 5 sur plusieurs évaluations importantes.

Il ne doit pas remplacer Sonnet 5 sur toutes les routes à fort volume, ni faire de max le réglage par défaut. Le gain économique vient du routage : Sonnet ou un effort réduit pour le travail accepté à bas coût, Opus avec high pour les tâches quotidiennes difficiles, xhigh pour les cas de longue durée mesurés et Fable seulement lorsque l’échec d’Opus se révèle coûteux.

Le réglage d’effort est précieux parce qu’il rend cette politique explicite. Traitez-le comme une variable d’évaluation, gardez-le stable lorsque le cache compte et reliez chaque escalade à un échec clairement identifié.

Vous voulez transformer la prochaine évolution de modèle en décision de production ? Inscrivez-vous à la newsletter.