Migration de Claude Opus 4.8 vers Opus 5 : Tous les changements de rupture

Remplacer claude-opus-4-8 par claude-opus-5 semble être un changement d'une seule ligne. C'est en grande partie le cas. Mais quelques paramètres par défaut ont changé, une combinaison de requêtes auparavant valide renvoie désormais une erreur 400, et une fonctionnalité pour laquelle les équipes d'entreprise paient a disparu sur le nouveau modèle.

Anthropic a lancé Claude Opus 5 le 24 juillet 2026 au même prix qu'Opus 4.8 (5 $ par million de tokens d'entrée, 25 $ par million de tokens de sortie), ce n'est donc rarement une décision budgétaire. C'est une décision de justesse. Vous trouverez ci-dessous toutes les différences qui peuvent casser une intégration fonctionnelle, classées par la probabilité qu'elles vous posent problème dès le premier jour, avec des extraits avant et après que vous pouvez coller dans votre client. Le guide de migration d'Opus 4.8 vers Opus 5 d'Anthropic est la source principale pour la surface de l'API. Pour tester chaque changement par rapport au point de terminaison en direct, enregistrez d'abord une requête dans Apidog et clonez-la par variante.

La version courte

1. La réflexion est activée par défaut, et max_tokens plafonne toujours tout

C'est le changement qui casse le code silencieux et fonctionnel.

Sur Opus 4.8, une requête sans champ thinking s'exécutait sans réflexion. Sur Opus 5, cette même requête exécute une réflexion adaptative. Votre JSON n'a pas changé, mais le modèle dépense désormais des tokens à raisonner avant d'écrire la réponse visible. Et max_tokens reste une limite stricte pour les tokens de réflexion plus les tokens de réponse combinés, de sorte qu'une requête qui s'inscrivait confortablement dans un budget de 1 024 tokens sur 4.8 peut maintenant brûler la majeure partie de ce budget en réflexion et renvoyer une réponse tronquée.

Voici la forme d'une requête qui était auparavant sûre :

{
  "model": "claude-opus-4-8",
  "max_tokens": 1024,
  "messages": [
    {"role": "user", "content": "Summarize this incident report in three bullets."}
  ]
}

Changez l'ID du modèle et rien d'autre, et vous avez un risque de troncation. La solution est de laisser de la marge au budget :

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "messages": [
    {"role": "user", "content": "Summarize this incident report in three bullets."}
  ]
}

Deux choses à vérifier après avoir augmenté la limite. Observez stop_reason dans la réponse : max_tokens signifie que vous avez été interrompu, end_turn signifie que le modèle a terminé. Lisez ensuite le bloc usage pour voir combien de budget la réflexion a réellement consommé sur vos invites réelles, et ajustez le nombre à partir de mesures plutôt qu'une estimation.

Si vous souhaitez vraiment l'ancien comportement sans réflexion, envoyez explicitement thinking: {"type": "disabled"}. Lisez d'abord la section suivante, car ce champ interagit désormais avec l'effort d'une manière qui renvoie une erreur.

2. L'erreur 400 : réflexion désactivée plus effort xhigh ou max

C'est le piège le plus susceptible d'apparaître dans vos journaux d'erreurs, car les deux moitiés étaient valides séparément sur Opus 4.8.

Sur Opus 5, thinking: {"type": "disabled"} combiné à output_config.effort défini sur xhigh ou max renvoie une erreur HTTP 400. Anthropic l'applique par requête, de sorte que cela échoue immédiatement et de manière cohérente plutôt que de se dégrader. La logique est simple : les deux niveaux d'effort supérieurs existent pour acheter plus de réflexion, donc demander un effort maximal avec la réflexion désactivée est une contradiction.

La requête qui échoue désormais :

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "thinking": {"type": "disabled"},
  "output_config": {"effort": "xhigh"},
  "messages": [
    {"role": "user", "content": "Refactor this module and explain the tradeoffs."}
  ]
}

Solution A, conserver la capacité. Supprimez le champ thinking, gardez l'effort élevé. C'est la direction recommandée par Anthropic, et c'est celle à choisir pour le codage et le travail d'agent :

{
  "model": "claude-opus-5",
  "max_tokens": 32000,
  "output_config": {"effort": "xhigh"},
  "messages": [
    {"role": "user", "content": "Refactor this module and explain the tradeoffs."}
  ]
}

Solution B, désactiver la réflexion. Pour un chemin sensible à la latence qui n'a vraiment pas besoin de réflexion, gardez disabled et réduisez l'effort à high ou moins :

{
  "model": "claude-opus-5",
  "max_tokens": 4096,
  "thinking": {"type": "disabled"},
  "output_config": {"effort": "high"},
  "messages": [
    {"role": "user", "content": "Classify this ticket into one of five categories."}
  ]
}

Une mise en garde concernant la Solution B. Anthropic documente deux artefacts qui apparaissent occasionnellement lorsque la réflexion est désactivée : les appels d'outils écrits en texte brut au lieu d'être exécutés, et les balises XML internes telles que <thinking> qui s'infiltrent dans la sortie visible. Dans une boucle d'agent, le texte divulgué empoisonne également les tours suivants. La propre atténuation d'Anthropic est de maintenir la réflexion activée et de contrôler les coûts avec un niveau d'effort inférieur à la place. Traitez la Solution B comme l'option étroite, et non comme l'option par défaut.

3. Les niveaux d'effort ont été recalibrés, donc refaites un balayage au lieu de copier les réglages

Opus 5 utilise par défaut l'effort high, et les niveaux eux-mêmes ont été recalibrés. low et medium sont significativement plus puissants sur Opus 5 que sur les modèles Opus précédents, donc un réglage que vous avez affiné sur 4.8 n'aboutit plus au même point de coût et de qualité. Anthropic dit clairement d'effectuer un nouveau balayage d'effort plutôt que de reprendre votre configuration 4.8, et ce conseil a des implications dans les deux sens :

• Les charges de travail épinglées à high ou xhigh sur 4.8 pour la qualité peuvent se maintenir à medium sur Opus 5, ce qui représente une réelle réduction de facture à un prix par token identique.
• Les charges de travail épinglées à low pour le coût peuvent valoir la peine d'être augmentées d'un niveau, car la qualité par token s'est améliorée.

Pour le codage et les travaux d'agent à long terme, xhigh reste le point de départ recommandé. Associez-le à un max_tokens généreux (64k est un budget de départ raisonnable aux niveaux supérieurs) afin que la réflexion ait de la place.

Effectuez le balayage sur votre propre jeu d'évaluation, et non sur un benchmark. Fixez l'invite, ne variez que la valeur de l'effort, et enregistrez la qualité de sortie, la latence et l'usage pour chaque niveau. L'analyse approfondie du paramètre d'effort couvre la mécanique de chaque niveau ; pour l'aspect coût de la même décision, consultez la répartition des prix d'Opus 5.

4. Supprimez l'en-tête bêta de contexte long

Opus 5 est livré avec une fenêtre de contexte de 1M de tokens, à la fois par défaut et au maximum. Il n'y a pas d'en-tête bêta pour l'activer et aucun coût supplémentaire pour le contexte long n'est associé.

Si votre client envoie toujours la valeur bêta de contexte étendu dans l'en-tête anthropic-beta de votre configuration Opus 4.8, c'est un poids mort maintenant. Supprimez-la. Les valeurs bêta obsolètes dans un client HTTP partagé sont la raison pour laquelle vous finissez par déboguer une requête sans rapport six mois plus tard.

La sortie maximale sur l'API Messages est de 128k tokens. Si vous avez besoin de plus, l'API Batch va jusqu'à 300k tokens de sortie avec l'en-tête bêta output-300k-2026-03-24, une option distincte de tout ce que vous faisiez pour la longueur du contexte.

5. Le minimum du cache d'invites passe à 512 tokens

Sur Opus 4.8, un segment d'invite devait atteindre 1 024 tokens pour être éligible au caching. Sur Opus 5, le seuil est de 512. Rien dans votre code n'a besoin de changer, et les lectures du cache à 0,50 $ par million sont les tokens les moins chers sur la grille tarifaire par rapport aux 5 $ d'entrée de base.

Ce qui vaut la peine d'être fait est un examen. Recherchez les invites système, les définitions d'outils et les blocs few-shot qui se situaient entre 512 et 1 024 tokens et qui ne justifiaient jamais un point d'arrêt cache_control auparavant. Ils en valent un maintenant. Confirmez l'effet en lisant cache_read_input_tokens dans le bloc usage de la réponse : lors du deuxième appel identique, il devrait être non nul. Notre guide pour réduire une facture d'API Claude couvre la stratégie de caching plus large.

6. Les messages système en milieu de conversation sont maintenant acceptés

Opus 4.8 rejetait une entrée {"role": "system"} dans le tableau messages avec un 400. Opus 5 l'accepte. C'est additif, donc cela ne casse rien, mais cela peut supprimer une solution de contournement. Si vous avez construit un mécanisme qui intègre les changements d'instructions en milieu de conversation dans un tour utilisateur synthétique, vous pouvez maintenant placer l'instruction en ligne là où elle doit être :

{
  "model": "claude-opus-5",
  "max_tokens": 8192,
  "messages": [
    {"role": "user", "content": "Draft the release note."},
    {"role": "assistant", "content": "Here is a first draft..."},
    {"role": "system", "content": "From here on, keep responses under 150 words."},
    {"role": "user", "content": "Tighten it."}
  ]
}

Ceci est une capacité par modèle. Si vous routez le même historique de conversation vers Opus 4.8 en tant que solution de repli, l'ancien modèle renverra toujours un 400 sur ce message.

7. Le Niveau de Priorité n'est pas pris en charge sur Opus 5

C'est un coup dur pour les équipes d'entreprise, et c'est facile à manquer car il s'agit d'une absence plutôt que d'une erreur que l'on peut rechercher. Opus 4.8 prend en charge le Niveau de Priorité. Opus 5 ne le fait pas. Si vous avez acheté un débit engagé pour garantir la latence sur un chemin de production, la migration de ce chemin le ramène à la capacité standard.

Il n'y a pas de solution astucieuse. Soit vous maintenez le trafic critique en latence sur claude-opus-4-8 pendant que tout le reste passe à Opus 5, soit vous acceptez la capacité standard et mesurez si votre latence de queue se dégrade réellement. Divisez la migration par charge de travail plutôt que de basculer toute la flotte en une seule fois.

8. Le mode rapide fonctionne maintenant, et il existe un nouveau mécanisme de repli en cas de refus cybernétique

Le mode rapide fonctionne sur Opus 5. Il renvoyait une erreur sur Opus 4.7 et s'exécutait silencieusement à vitesse standard sur Opus 4.6. Sur Opus 5, il offre environ 2,5 fois la vitesse de sortie pour 10 $ par million d'entrées et 50 $ par million de sorties. Il s'agit d'un aperçu de recherche, API propriétaire uniquement (pas Amazon Bedrock, Google Cloud ou Microsoft Foundry), et il ne se combine pas avec l'API Batch. Utilisez-le pour les chemins interactifs, pas pour les tâches de fond.

Repli côté serveur pour les refus cybernétiques. L'envoi de fallbacks: "default" avec l'en-tête bêta server-side-fallback-2026-07-01 fait en sorte qu'une requête qu'Opus 5 refuse pour des raisons de catégorie cybernétique retombe automatiquement sur Opus 4.8. C'est là que les outils de sécurité trouvent leur utilité.

Il existe également un en-tête bêta mid-conversation-tool-changes-2026-07-01 qui vous permet d'ajouter ou de supprimer des définitions d'outils entre les tours sans invalider le cache d'invites : un levier de coût pour les longues sessions d'agent avec un ensemble d'outils changeant.

9. Ce qui n'a pas changé

Il est utile de savoir ce que vous pouvez laisser tel quel :

• Les paramètres d'échantillonnage renvoient toujours un 400. temperature, top_p et top_k avec des valeurs non par défaut sont rejetés, comme sur Opus 4.8. Dirigez le comportement via l'invite système.
• Les décomptes de tokens sont à peu près les mêmes. Opus 5 utilise la même famille de tokenizeurs qu'Opus 4.8, de sorte que les budgets de tokens et les modèles de coûts existants sont repris sans nouveau décompte. C'est l'inverse du passage de Sonnet 4.6 à Sonnet 5, qui a modifié les décomptes d'environ 30%.
• Le prix de base est identique. 5 $ en entrée, 25 $ en sortie, correspondant à Opus 4.8, 4.7, 4.6 et 4.5. Voir la page de tarification d'Opus 4.8.
• Forme des requêtes et réponses. Le streaming, l'utilisation d'outils, la vision, les sorties structurées et le traitement par lots fonctionnent tous comme avant.

Une chose a changé même là où l'API n'a pas changé : Opus 5 vérifie son propre travail sans y être invité, de sorte que les instructions héritées "vérifiez votre réponse" entraînent une sur-vérification et un gaspillage de tokens. Les réponses par défaut sont également plus longues que celles de 4.8, et la réduction de l'effort réduit la réflexion plutôt que la longueur visible, il faut donc demander explicitement la concision. Ce sont des correctifs au niveau des invites, couverts dans l'utilisation d'invites avec Claude Opus 5.

Vérifiez la migration avant de la déployer

Chaque élément ci-dessus est une différence de niveau HTTP, ce qui la rend testable en dehors de votre application. Une boucle de travail dans Apidog :

1. Enregistrez une requête vers le point de terminaison Messages avec votre clé stockée comme variable d'environnement, jamais en ligne dans le corps.
2. Clonez-la en variantes : claude-opus-4-8 de base, claude-opus-5 avec les valeurs par défaut, et un clone par niveau d'effort.
3. Déclenchez délibérément la combinaison réflexion désactivée plus xhigh et enregistrez le corps de l'erreur 400, afin de la reconnaître dans les journaux de production.
4. Faites une assertion sur stop_reason afin qu'une réponse max_tokens tronquée fasse échouer votre test au lieu d'être discrètement déployée.
5. Envoyez deux fois une requête en cache identique et vérifiez usage.cache_read_input_tokens lors du deuxième appel.
6. Exécutez une requête de streaming et confirmez que votre parseur SSE gère les blocs de réflexion qui arrivent désormais par défaut.

Téléchargez Apidog pour conserver cela comme une collection réutilisable pour chaque futur échange de modèle.

Une mise en garde honnête avant de tout migrer

Opus 5 n'est pas le sommet de la pile Claude. Fable 5 reste le modèle le plus performant d'Anthropic largement diffusé, et Opus 5 est toujours en retrait par rapport à Mythos 5 en matière d'exploitation de la cybersécurité et de recherche en biologie autonome. Anthropic le dit elle-même dans le post de lancement. Les affirmations de benchmark de lancement (Frontier-Bench, ARC-AGI 3, OSWorld 2.0, CursorBench 3.2) sont exécutées par le fournisseur et non reproduites de manière indépendante à la date du 25 juillet 2026. Traitez-les comme les chiffres rapportés par Anthropic et exécutez vos propres évaluations avant de s'engager avec une charge de travail de production. Le résumé précis : une capacité de classe frontalière à la moitié du prix frontalier, avec un plafond nommé au-dessus.

Liste de contrôle de migration

Parcourez cette liste dans l'ordre :

1. Changez la chaîne de modèle en claude-opus-5 exactement. Pas de suffixe de date.
2. Augmentez max_tokens sur chaque requête qui omettait auparavant thinking. La réflexion s'exécute maintenant par défaut et partage ce budget.
3. Recherchez "disabled" dans votre codebase et confirmez qu'aucune requête ne l'associe à l'effort xhigh ou max. Cette combinaison est une erreur 400 stricte.
4. Supprimez la valeur bêta de contexte long de anthropic-beta. La fenêtre de 1M est maintenant la valeur par défaut.
5. Réexécutez votre balayage d'effort à partir de zéro sur vos propres évaluations. Ne portez pas les réglages de 4.8.
6. Ajoutez des points d'arrêt cache_control aux segments d'invites entre 512 et 1 024 tokens.
7. Identifiez tout trafic sur le Niveau de Priorité et décidez par charge de travail s'il reste sur claude-opus-4-8.
8. Supprimez les instructions de vérification héritées de vos invites, et ajoutez des instructions explicites de concision lorsque la longueur de la sortie est importante.
9. Activez éventuellement fallbacks: "default" si votre charge de travail déclenche des refus de catégorie cybernétique.
10. Faites une assertion sur stop_reason dans votre suite de tests afin que la troncation apparaisse comme un échec, et non comme une réponse subtilement pire.

Pour une présentation complète des requêtes, consultez le guide API de Claude Opus 5, ou commencez par ce qu'est Claude Opus 5 pour les spécifications et la disponibilité. Si vous utilisez toujours l'ancien modèle à certains endroits, l'explication d'Opus 4.8 et sa procédure pas à pas de l'API restent exactes pour celui-ci. La présentation des modèles d'Anthropic est la source de référence pour les ID, les fenêtres de contexte et les limites.

FAQ

La migration d'Opus 4.8 vers Opus 5 est-elle une migration directe ? Presque, mais pas tout à fait. Changer la chaîne du modèle fonctionne pour la plupart des requêtes. Deux choses peuvent casser : la réflexion s'exécute désormais par défaut et partage votre budget max_tokens, et thinking: {"type": "disabled"} avec un effort xhigh ou max renvoie un 400. Le trafic du Niveau de Priorité nécessite également une décision, car Opus 5 ne le prend pas en charge.

Pourquoi est-ce que j'obtiens une erreur 400 après être passé à claude-opus-5 ? La cause la plus fréquente est la désactivation de la réflexion tout en demandant un effort xhigh ou max. Soit vous supprimez le champ thinking et gardez l'effort élevé, soit vous gardez la réflexion désactivée et réduisez l'effort à high ou moins. Les valeurs non par défaut de temperature, top_p ou top_k renvoient également toujours un 400, exactement comme sur Opus 4.8.

Dois-je recompter mes tokens après la migration ? Non. Opus 5 utilise la même famille de tokenizeurs qu'Opus 4.8, donc les décomptes sont à peu près inchangés et les budgets existants sont reportés. Les frais généraux de l'invite système d'utilisation d'outils sont légèrement inférieurs, à 286 tokens contre 290. Le prix de base est également identique, à 5 $ en entrée et 25 $ en sortie, bien que votre facture puisse toujours varier si la réflexion par défaut augmente les tokens de sortie.