Passage à Claude Opus 5.5 : Cinq changements majeurs derrière l’ID du modèle.

Une seule chaîne, cinq surprises

Imaginez le vendredi suivant l’annonce de la sortie. Anthropic a déployé Claude Opus 5.5 (22 septembre 2026), décrit comme étant au niveau de Fable pour la plupart des tâches, environ 40 % moins cher lors d’une exécution typique, avec un prix de base de 4 dollars pour l’entrée et 20 dollars pour la sortie par million de tokens. Tout le monde est ravi de cette réduction, tandis que votre outil de production est encore conçu pour Opus 5 et qu’un seul paramètre de modèle fait obstacle. Vous changez model en claude-opus-5-5.

Le premier canari ne semble pas plus intelligent. Il échoue avec une erreur HTTP 400 en raison d’une réflexion excessive sur ce qui était censé être incorrect, ou à cause d’un tool_choice que la boucle impose à chaque étape. Ou bien la requête passe, les outils continuent d’apparaître, mais le récit entre les outils, que l’interface de progression diffusait auparavant, devient silencieux. Aucune erreur, aucun agent plus performant, et les opérateurs commencent à se demander si la tâche est bloquée.

Ce n’est pas un bilan de lancement, mais plutôt une étape de vérification préalable. Cinq éléments attendent derrière le nouveau ID de modèle : une réflexion permanente, l’utilisation forcée d’outils, des blocages de réflexion liés au modèle, un outil de traitement informatique désactivé, ainsi qu’un changement dans la structure du flux qui ne génère jamais d’erreur 400. Changer la chaîne de caractères est simple. Survivre à la requête suivante, c’est là le véritable défi.

Ce que dit la couverture de tests et ce que disent les documents

La couverture médiatique se concentre sur le prix. L’annonce et les articles qui l’accompagnent mettent en avant les prétentions au niveau de Fable, les mesures de sécurité cybernétique ainsi qu’un Opus moins cher. Les chiffres d’Anthropic confirment cela : des résultats de niveau Fable 5.1 pour la plupart des tâches, une dépense environ 40 % inférieure pour une exécution typique, 4 $ / 20 $ contre 5 $ / 25 $ pour Opus 5, et un temps de traitement plus rapide de plus de 30 %. Un taux de lecture en mémoire cache de 0,20 $ n’est qu’une ligne dans la liste des prix et ne constitue pas l’élément principal.

La documentation en dit moins, mais elle est précise. Son aperçu de la plateforme mentionne quatre modifications majeures concernant le code qui fonctionne déjà sur Opus 5. Il est impossible de désactiver la capacité de réflexion. Des erreurs surviennent en cas d’utilisation forcée d’outils. Les blocs de réflexion sont liés à un modèle et à une conversation donnés. De plus, l’outil ancien computer_20251124 n’est pas accepté par l’API Claude ni par Google Cloud.

Le risque concerne les boucles d’agents personnalisées de la Messages API, les routeurs multi-modèles, ainsi que les workflows qui imposent l’utilisation d’outils et d’agents informatiques avec la Claude API ou GCP, car tous eux envoient encore des requêtes de type Opus 5. Certaines configurations sont plus sûres. Les Claude Managed Agents n’ont besoin que du nouveau nom de modèle, et Claude Code ainsi que l’Agent SDK s’ajoutent aux conversations, ce qui réduit la vulnérabilité liée au verrouillage de la réflexion. Affirmer que tout cesse de fonctionner serait inexact. Néanmoins, cette mise à niveau mérite d’être adoptée, et les conséquences sont réelles pour quiconque considère un post de lancement comme une porte d’accès définitive. Les prix ont baissé tandis que les règles de requête se sont renforcées, il ne s’agit donc pas d’un simple remplacement de texte.

Les cinq points sont les suivants :

1. La réflexion adaptative est toujours activée. Tant thinking.type.disabled que enabled associé à budget_tokens renvoient une erreur 400.

La mise forcée de tool_choice à any ou tool génère une réponse 400.

Les blocs de réflexion sont liés au modèle qui les a créés, ce qui fait que les routeurs perdent les raisonnements illisibles même si la requête réussit.

computer_20251124 est rejeté par l’API Claude et GCP (Bedrock le accepte encore).

La narration entre outils est placée dans des blocs thinking qui restent vides avec la valeur par défaut display: "omitted", et cela ne provoque jamais de réponse 400.

Quatre de ces cas se terminent par une erreur manifeste avec un code 400. Les autres ne le font pas, c’est ainsi que l’interface de suivi disparaît derrière une réponse 200. L’effort par défaut a également changé : Opus 5 utilisait high tandis que 5.5 utilise medium, donc un simple changement modifie le comportement même en l’absence d’erreur. Un Opus moins cher qui rejette votre configuration entraîne une interruption de service accompagnée d’un communiqué de presse.

Règle n°1 : la réflexion ne peut pas être éteinte

Au niveau Opus 5, l’envoi de thinking: {"type": "disabled"} avec un niveau d’effort high ou inférieur fonctionnait, tout comme le mode enabled manuel associé à des budget_tokens. Opus 5.5 ignore ce que faisait auparavant le chemin de latence. La documentation indique que la réflexion adaptative est toujours active et que la profondeur de réflexion est contrôlée via le paramètre d’effort.

Lorsque l’on envoie thinking.type.disabled, l’API répond par une erreur HTTP 400 indiquant thinking.type.adaptive et output_config.effort. La même situation se produit avec la valeur enabled. Les routes de chat optimisées pour la latence ainsi que les boucles d’outils peu coûteuses qui désactivent la réflexion pour économiser des tokens échouent en premier, dès la première requête après ce changement. Le code qui s’attend à ce que le premier bloc de contenu soit de type text échoue également, car les réponses peuvent commencer par des blocs thinking dont le texte est vide en raison de la valeur par défaut display: "omitted".

Réparations :

• Omettre thinking, ou envoyer {"type": "adaptive"}.
• Définir la profondeur avec output_config.effort, en gardant à l’esprit que la valeur par défaut est medium. Lorsque la réflexion a été désactivée précédemment, choisir low.

Sélectionnez les blocs de contenu par type, et affichez les réflexions telles quelles dans les boucles d’outil.

Laissez de la marge dans max_tokens pour les réflexions que vous ne pouvez plus désactiver.

Être toujours actif ne signifie pas nécessairement produire toujours plus, car l’effort est le paramètre à régler. Un mode rapide (environ 2,5 fois plus rapide pour 8 $ / 40 $) n’existe que sur l’API Claude, dans les cas où la latence est le véritable obstacle, et non sur Bedrock ou GCP. thinking: disabled n’est pas simplement obsolète : c’est une erreur 400.

Deuxième avantage : fin de l’utilisation forcée des outils

Opus 5.5 ne prend pas en charge l’utilisation forcée d’outils, ce qui constitue un changement de comportement et non une dépréciation progressive. Une valeur tool_choice égale à {"type": "any"} ou {"type": "tool", "name": "..."} génère une erreur 400 indiquant que les types tool et any ne sont pas pris en charge par ce modèle. Les valeurs auto (par défaut) et none continuent de fonctionner.

Les agents qui imposent l’utilisation d’un outil à chaque tour, tels que les recherches météorologiques, les appels à une base de données ou une règle exigeant systématiquement l’appel à search_codebase, ne fonctionnent plus dans ce cas, tout comme le contrôle du schéma qui dépendait de la désignation d’un outil. Les vérifications préalables CI qui envoient des requêtes au point de terminaison de comptage des tokens avec un choix forcé échouent également, ce qui peut entraîner une erreur de calcul des frais avant même que l’appel à Messages ne soit effectué. De l’extérieur, la panne semble résulter d’un simple changement de modèle, tandis que l’historique des erreurs montre que vous envoyez toujours un plan de contrôle Opus 5.

Réparations :

• Utiliser tool_choice: {"type": "auto"}.
• Ajouter strict: true aux outils, ou utiliser des sorties structurées.
• Préciser dans la demande quand chaque outil doit être utilisé, par exemple « appeler l’outil get_X lorsque... », ce qui fonctionne mieux qu’un choix forcé désormais rejeté par l’API.

Réexécutez chaque appel à count_tokens si celui-ci passe encore les tests any ou tool.

Cela échoue avant même que le modèle ne s’exécute, et il n’y a pas de solution de secours permettant au modèle d’utiliser principalement l’outil. Une politique consistant à « toujours effectuer une recherche » est devenue un obstacle à la mise en œuvre.

Problème trois : blocages de réflexion liés à un modèle

Chaque bloc de réflexion porte la marque du modèle qui l’a généré, et un modèle peut interpréter ses propres blocs ainsi qu’un ensemble limité de blocs provenant d’autres modèles. Opus 5.5 prend en charge les blocs de réflexion générés par Opus 5 et les versions antérieures d’Opus, ainsi que par Sonnet et Haiku. Les sorties de Fable et Mythos ne font pas partie de cet ensemble. Inversement, seuls Fable 5.1 et Mythos 5.1 (sur l’API Claude) peuvent interpréter ce que a généré Opus 5.5.

Si un routeur ou un mécanisme de secours envoie une conversation depuis claude-opus-5-5 vers Sonnet, GPT ou un autre modèle, l’API élimine les blocs que la cible ne peut pas lire. La requête réussit néanmoins, et les blocs éliminés ne donnent pas lieu à facturation. Cela se traduit par une baisse silencieuse de la qualité, sans erreur 400, avec un raisonnement moins approfondi et un tableau de bord qui reste vert.

Modifier les paramètres system, tools ou des paramètres antérieurs au milieu d’une conversation peut également rendre les blocs invalides. Les comptes ouverts le 31 août 2026 (00:00 UTC) ou après reçoivent par défaut une erreur 400 lorsque un bloc de réflexion est rejoué après modification du préfixe. La version bêta thinking-binding-controls-2026-08-01 permet d’utiliser plutôt prefix_mismatch_behavior: "drop_block". Claude Code, claude.ai, Managed Agents et l’Agent SDK n’ajoutent que des blocs, ce qui limite leur exposition.

Réparations :

• Garder les conversations en mode ajout uniquement.
• Changer les instructions au moyen de messages système pendant la conversation, et non en réécrivant le préfixe.
• Considérer un changement de modèle comme un réinitialissement du raisonnement, sauf si la documentation indique le contraire.
• Rétablir les blocs de réflexion tels qu’ils étaient, et ne pas supposer que chaque modèle Claude puisse suivre le raisonnement de 5.5 après un transfert.

Même une solution de secours qui « fonctionne » peut encore éliminer le raisonnement qui a permis à cette étape de fonctionner.

Cas particulier quatre : l’ancien outil d’utilisation informatique

Opus 5 nécessite à la fois computer_toolset_20260801 et, en version bêta, computer_20251124. Sur la API Claude et Google Cloud, Opus 5.5 ne requiert que le toolset, et la déclaration de computer_20251124 génère une erreur 400 indiquant que claude-opus-5-5 ne prend pas en charge ce type d’outil. Amazon Bedrock le accepte toujours, donc rien ne change de ce côté-là. La famille de modèles reste identique tandis que la matrice des plateformes diffère ; par conséquent, les collaborateurs utilisant uniquement Bedrock ne doivent pas être contraints à une réécriture inutile.

Les agents de bureau et de navigateur sur l’API Claude ou GCP qui déclarent encore le type ancien et envoient l’en-tête computer-use-2025-11-24 beta échouent dès la première déclaration d’outil. Changer simplement le type ne suffit pas, car les boucles qui lisent input.action se brisent également. Les blocs contenant le membre tool_use placent l’action dans le champ name du bloc ; une seule itération peut contenir plusieurs utilisations d’outil, et chaque résultat nécessite que toolset_name: "computer" soit renvoyé.

Réparations :

• Supprimer l’en-tête beta.
• Envoyer tools=[{"type": "computer_toolset_20260801"}], en omettant name ainsi que les dimensions d’affichage dans la déclaration.
• Mettre à jour la boucle d’agent afin qu’elle utilise les noms de membres et toolset_name.

Les capacités se sont améliorées (un score OSWorld 2.0 rapporté par l’entreprise de 81,8 %, qualifié de partiel), et l’outil d’intégration est arrivé avec elles.

Coup cinq : le flux devient silencieux

Sous Opus 5, les échanges entre les appels d’outils apparaissaient sous forme de blocs text, permettant à l’interface d’afficher des messages tels que « Vérification des migrations... » et de maintenir le calme parmi les opérateurs. Opus 5.5 conserve la structure de Fable 5.1, où ces échanges apparaissent désormais sous forme de blocs thinking indiquant l’avancement, un par appel d’outil au maximum. Comme thinking.display est défini par défaut sur « omitted », le champ thinking reste vide. La documentation met en garde contre le fait qu’une interface affichant ces lignes en temps réel devient silencieuse entre les appels d’outils tant qu’une valeur display permettant de restituer le texte n’a pas été choisie.

Aucune demande échoue et le statut est 200. Les fragments d’outil sont toujours affichés, mais les échanges entre eux ont disparu, et les utilisateurs pensent que l’agent est bloqué.

Réparations :

• Choisissez display: "updates" (nécessite la version bêta thinking-display-updates-2026-08-18) pour afficher le texte de progression sans les raisonnements, ou "summarized" pour les deux, et affichez tout raisonnement non vide avant l’instruction tool_use suivante. Les blocages sont renvoyés tels quels.

Les quatre interruptions majeures génèrent un code 400, tandis que celle-ci ne le fait jamais, ce qui explique pourquoi les interfaces de progression semblent fonctionner correctement alors qu’elles échouent en réalité. Le bug de migration le plus problématique est celui qui renvoie un statut 200.

La liste de vérification avant déploiement

Considérez cette étape comme un test de canary et non comme une simple modification de configuration du vendredi. Avant que claude-opus-5-5 ne reçoive du trafic :

• Mettre à jour l’ID du modèle en claude-opus-5-5, en utilisant l’ID spécifique à la plateforme sur Bedrock, GCP ou Azure.
• Supprimer thinking: disabled et enabled ainsi que budget_tokens, puis définir explicitement output_config.effort, car la valeur par défaut est medium.
• Remplacer tool_choice par any ou tool par auto, en ajoutant des outils stricts ou des sorties structurées ainsi qu’une instruction de prompt.
• Pour une utilisation sur ordinateur via la API Claude ou GCP, passer à computer_toolset_20260801 et mettre à jour la boucle d’agent. Bedrock peut conserver computer_20251124.
• Au niveau des routeurs, s’attendre à une perte de fonctionnement liée au processus de réflexion en passant de la version 5.5, sauf pour Fable ou Mythos 5.1 sur l’API Claude.
• Sélectionner le contenu par type et reproduire les blocs thinking sans modification.

Pour les interfaces en cours de développement, définissez display sur "updates" ou "summarized".

Gardez les conversations en mode ajout uniquement, et suivez les directives relatives au maintien des pensées si des préfixes sont modifiés, en particulier pour les comptes créés à partir du 31 août 2026.

Réévaluez les coûts et les délais en fonction des efforts réellement souhaités, et testez dans l’environnement de développement avant d’intégrer le trafic en production.

Optionnellement, exécutez la compétence Claude Code /claude-api migrate.

Seuls les agents gérés par Claude peuvent être mis à jour uniquement avec le nom, et la documentation indique simplement que c’est le nom du modèle qui doit être mis à jour. Les outils de l’API Custom Messages ne font pas partie de ce groupe, et ils conservent les schémas de requête d’Opus 5 jusqu’à ce que la liste soit validée. La compétence migrate peut détecter les schémas obsolètes avant la mise à jour, mais les routeurs et les interfaces de suivi nécessitent toujours vos propres tests, car elle ne remplace pas un système de test canari. L’effort requis est passé de élevé dans Opus 5 à moyen dans 5.5, donc ne transférez pas vos anciennes hypothèses concernant un effort élevé à un niveau par défaut moyen.

Effectuez la mise à jour intentionnellement

Opus 5.5 mérite d’être adopté délibérément, car pour les exigences de niveau Fable, il offre environ 40 % de réduction des coûts par exécution typique ainsi qu’une production plus rapide. Migratez parce que le modèle est meilleur, et non parce qu’un annonce de lancement ressemble à une porte d’accès. C’est la forme de la demande qui importe désormais, et les quatre pannes documentées ainsi que le flux silencieux constituent cette porte d’accès. La couverture ne les liste pas à côté de la réduction de prix.

Les erreurs graves se manifestent bruyamment, tandis que les pannes de routeur et display: "omitted" restent silencieuses ; instrumentez donc les deux cas, sinon vous ne détecterez que les pannes qui font du bruit. Les différences de plateforme comptent : Bedrock accepte encore computer_20251124, tandis que l’API Claude et GCP ne le font pas. Les Agents gérés nécessitent un changement de nom, mais une solution personnalisée basée sur l’API Messages n’a pas ce privilège. L’effort a remplacé l’interrupteur d’arrêt, il faut donc établir de nouvelles bases pour les coûts et la latence, et on ne doit pas supposer que les principes économiques liés à l’état désactivé s’appliquent également.

Changer la chaîne de caractères ne coûte rien, tandis que la migration en coûte. La mise à niveau est réelle, et l’idée d’un remplacement direct n’est qu’une fiction. Suivez la liste de contrôle, évaluez à nouveau les efforts requis, puis seulement redirigez le trafic vers claude-opus-5-5.