Anthropic présente un guide consacré aux différences entre Claude Opus 5.5 et Claude Opus 5. Il traite du réglage de l’effort, du thinking dans les intégrations API et les chats, des mises à jour de progression, des tâches autonomes et multiagents, des refus de sécurité, de la génération frontend, des entrées visuelles complexes, des workflows entre plusieurs applications et du texte collé dans les messages utilisateur. Une migration séparée décrit quatre changements d’API incompatibles.

Claude Opus 5.5 génère ses tokens de sortie plus de 30 % plus vite que Claude Opus 5 et termine généralement une même tâche avec moins de tokens. Les prompts existants devraient continuer à fonctionner dans la plupart des cas. Anthropic considère les recommandations pour Claude Opus 5 comme un point de départ valable.

Pour le développement agentique et la revue de code, Anthropic indique que Opus 5.5 avec un effort moyen a égalé ou dépassé Opus 5 avec un effort élevé dans ses tests, avec moins d’étapes et de tokens. L’entreprise rapporte aussi une meilleure endurance pour les audits de plusieurs heures et les migrations de grandes bases de code avec des sous-agents parallèles et peu de supervision. Des premiers testeurs ont trouvé davantage de bugs et moins de faux positifs en revue de code. Le modèle explique ses changements en langage clair.

Dans les tâches de connaissance, le modèle donne moins de chiffres erronés et de mauvaises références. Le guide cite la modélisation financière, les feuilles de valorisation, une date associée au mauvais jour de la semaine dans un long fil de planification et un graphique incohérent avec les données sous-jacentes. Les documents, feuilles de calcul et présentations produits demanderaient moins de retouches. Anthropic décrit également des rapports d’avancement et des synthèses finales plus explicites.

Les performances visuelles progressent. Dans les tests d’Anthropic, Opus 5.5 au niveau d’effort le plus bas a lu des graphiques denses avec plus de précision que Opus 5 au niveau le plus haut, tout en utilisant une petite fraction des tokens de sortie. Il comprend mieux les relations de position dans les organigrammes, les différences entre deux versions d’un diagramme et les horaires de début et de fin dans une capture de calendrier. Pour le computer use, l’effort par défaut a atteint le taux de réussite qu’Opus 5 obtenait avec un effort beaucoup plus élevé.

L’effort est le principal réglage, car le thinking est toujours actif. Anthropic conseille de commencer avec medium, la valeur par défaut de Opus 5.5, puis de comparer les niveaux avec ses propres évaluations. Opus 5 utilise high par défaut. Les noms des niveaux ne représentent pas la même quantité de raisonnement d’un modèle à l’autre. Dans les évaluations de code et de travail de connaissance, medium sur Opus 5.5 a égalé ou dépassé high sur Opus 5. Low s’en est approché dans plusieurs tests de code, avec un coût inférieur.

À niveau égal, Opus 5.5 a tendance à réfléchir plus longtemps que Opus 5, surtout avec `xhigh` et `max`. La limite `max_tokens` doit réserver de la place au thinking et à la réponse, même lorsque le contenu du thinking reste masqué. Anthropic indique que `128,000`, le maximum du modèle, convient aux longues tâches de code agentique. `xhigh` et `max` doivent être réservés aux cas où un gain de qualité a été mesuré. Réduire l’effort diminue la réflexion, le coût et la latence plus sûrement que des consignes de prompt. Modifier l’effort global invalide le cache du prompt. Une modification par message, disponible en bêta, conserve le cache.

Claude Opus 5 accepte `thinking` désactivé avec un effort élevé ou inférieur. Opus 5.5 pense toujours. Lors d’une migration, Anthropic recommande donc de commencer avec low et de mesurer la qualité et la latence. Une consigne système demandant une réponse directe peut réduire davantage le thinking, avec un risque pour la qualité. Les prompts qui demandent une reproduction visible du raisonnement doivent être retirés. Les applications doivent lire les blocs de thinking résumés avec `display: "summarized"` et gérer la catégorie de refus `reasoning_extraction`. Le client doit examiner le type de chaque bloc, car une réponse peut commencer par un bloc de thinking dont le champ `thinking` est vide avec l’affichage par défaut `omitted`.

Dans les longues tâches sans supervision, un tour composé uniquement de texte et terminé par `stop_reason: "end_turn"` peut constituer un rapport d’étape. Anthropic recommande une checklist externe, la poursuite des éléments ouverts et l’attente des commandes en arrière-plan ou des sous-agents. Le harness peut envoyer une courte relance mentionnant les tâches restantes. Il doit arrêter les continuations automatiques après deux ou trois tentatives pour éviter les boucles. Un prompt système peut désigner les résumés prématurés et les offres d’attendre comme des arrêts indésirables. Cette consigne doit être présente dès la première requête, car une modification ultérieure invalide les anciens blocs de thinking. Elle peut augmenter le nombre d’appels d’outils et de tokens. Une confirmation séparée reste nécessaire pour les actions risquées.

Le modèle utilise des classificateurs de sécurité pour la biologie, la cybersécurité et l’extraction de raisonnement. Les protections biologiques correspondent à celles de Claude Fable 5.1 et sont nouvelles pour les utilisateurs venant de Opus 5. Les questions courantes de santé et d’éducation restent accessibles. Anthropic renvoie les organisations de sciences de la vie concernées vers son Life Sciences Verification Program. La recherche de vulnérabilités dans du code source est autorisée. Les activités de cybersécurité à double usage et à haut risque restent limitées. Un refus arrive comme une réponse normale avec `stop_reason: "refusal"` et une catégorie dans `stop_details`. La plupart des refus peuvent déclencher automatiquement un modèle de secours. Pour `reasoning_extraction`, le secours côté serveur renvoie le refus sans nouvelle tentative.

Les mises à jour entre les appels d’outils arrivent sous forme de blocs de thinking dédiés à la progression. Le client doit activer `display: "updates"` et envoyer l’en-tête bêta `thinking-display-updates-2026-08-18` pour recevoir leur texte. Une application qui doit transmettre un contenu verbatim pendant un long tour peut fournir un outil de message dédié dès la première requête. L’ajouter plus tard modifie le préfixe de la conversation et invalide les anciens blocs de thinking. Les prompts système peuvent demander des mises à jour plus fréquentes. Après plusieurs étapes silencieuses, cinq par exemple, le harness peut ajouter un rappel dans un message système limité au tour, avec `clear_at: "next_user_message"` et l’en-tête bêta `mid-conversation-system-clear-at-2026-08-21`. Anthropic rapporte que cette méthode a réduit d’environ moitié les longues périodes silencieuses dans ses tests de code agentique, sans changement mesurable du coût.

Pour les workflows reliant e-mails, documents, feuilles de calcul et fiches CRM, Anthropic conseille d’explorer les sources pertinentes avant toute action, y compris celles qui ne sont pas citées dans la demande. Ses tests montrent une meilleure réussite avec medium et max, au prix de quelques appels d’outils et tokens supplémentaires. Les contenus non fiables doivent rester en dehors des données consultées par l’agent.

Les harnesses multiagents peuvent fournir le temps écoulé et un budget, par exemple `elapsed 340s / 1200s`. Dans les évaluations d’Anthropic, ces signaux ont permis à de petites équipes d’agents de recherche de terminer plus vite, avec une qualité comparable à celle d’un agent unique. Le budget reste indicatif. Un délai maximal doit être géré séparément par l’application. Un effort réduit diminue le travail effectué. Un budget temporel favorise surtout le parallélisme.

Pour les applications de chat, Anthropic conseille de retirer les instructions générales demandant de réfléchir avec soin. Opus 5.5 contrôle le thinking avec le niveau d’effort. Les tests ont montré des réponses qui commencent plus vite, sans baisse claire de qualité. Lors d’un suivi, le modèle peut réexaminer une réponse précédente, ce qui augmente la latence. Une consigne système peut lui demander de considérer les réponses terminées comme acquises jusqu’à un signalement de problème. Anthropic observe alors moins de thinking et des réponses plus rapides, avec une moindre propension à repérer seul ses erreurs précédentes.

Selon le guide, Opus 5.5 résiste mieux que les anciens modèles Opus aux instructions indirectes présentes dans les résultats d’outils, les pages web et les contenus affichés à l’écran. Les applications doivent encadrer le texte collé par l’utilisateur avec des balises `<pasted_content>` portant le même identifiant aléatoire court. Le prompt système doit préciser que le bloc peut contenir des instructions provenant d’une autre source. Ces instructions ne doivent être suivies que si le message rédigé par l’utilisateur le demande.

Pour les graphiques, diagrammes et captures complexes, le guide conseille de réévaluer les protections ajoutées aux anciennes versions. Une résolution élevée aide les dessins techniques. Un conteneur équipé de PIL et OpenCV peut recadrer, agrandir, mesurer et vérifier les images. Un outil de recadrage seul demande moins d’infrastructure. Un effort élevé améliore l’utilisation d’outils visuels. Sans outil, il aide davantage les dessins techniques que les graphiques.

Sans consignes de design, Opus 5.5 applique certains styles frontend récurrents. Anthropic recommande de nommer les motifs à éviter et d’examiner le premier résultat par itérations. Son exemple demande un site personnel en Vanilla HTML/CSS avec des données fictives. Il exclut les arrière-plans crème ou blanc cassé, les mots en italique dans les titres, les labels numérotés `01/02/03`, les labels en monospace et les boutons en forme de pilule.