Aller au contenu principal

Claude Sonnet 5.5 : le guide de terrain

Intermédiaire

Le 28 septembre 2026, Anthropic a sorti Claude Sonnet 5.5 (claude-sonnet-5-5) — le deuxième modèle de la famille 5.5, après Opus 5.5 six jours plus tôt. Le tarif est la partie intéressante précisément parce qu'il n'a pas bougé : 2 $ en entrée / 10 $ en sortie par MTok, exactement les mêmes prix que Sonnet 5, même tokenizer, mêmes tarifs de cache et de batch. L'affirmation d'Anthropic n'en est pas moins : une sortie plus de 30 % plus rapide et jusqu'à 30 % moins chère par tâche.

Les deux peuvent être vraies en même temps, et comprendre pourquoi est tout l'enjeu de cette page : sur Sonnet 5.5, l'économie se trouve dans le nombre de tokens et le nombre de tours, jamais dans le prix par token. Cela change ce que vous devez mesurer, et cela change le premier levier à actionner.

La deuxième chose à savoir dès le premier jour : le modèle bon marché n'est pas uniformément en retard sur le modèle cher. Sur Terminal-Bench 4.0, Sonnet 5.5 obtient 70,6 % contre 66,4 % pour Opus 5.5 — la seule ligne publiée où le modèle à moitié prix est devant. Et sur l'Elo travail de connaissance, les deux sont à égalité statistique. L'écart qui subsiste est concentré sur un point précis, et cette page dit lequel.

What you'll learn
  • Connaître les vrais chiffres : 2 $/10 $ par MTok inchangés depuis Sonnet 5, contexte de 1M, sortie max de 128K (300K en Batches), coupure de connaissances de juin 2026, effort par défaut high
  • Corriger les cinq changements cassants qui renvoient une erreur 400 sur une base de code Sonnet 5, et le sixième qui renvoie 200 et fait taire votre interface de progression
  • Utiliser correctement between_tools — le remplaçant de thinking disabled, qui est rejeté aux efforts xhigh et max et rejette tout champ compagnon
  • Lire le tableau de lancement honnêtement : où Sonnet 5.5 bat Opus 5.5, où il a 8 points de retard, et pourquoi une ligne affiche 10,3 %
  • Recalibrer l'effort depuis zéro plutôt que de reporter un réglage, et récupérer le ~1/3 du coût de session que l'effort max dépense en révision auto-initiée
  • Gérer les modes de défaillance plus discrets : les demandes de sortie structurée qui réfléchissent jusqu'à max_tokens, les noms d'outils différant par la casse, et les vrais messages utilisateur pris pour des injections de prompt

Spécifications, et les quatre chiffres qui ont changé​

Sonnet 5Sonnet 5.5Opus 5.5
ID Claude APIclaude-sonnet-5claude-sonnet-5-5claude-opus-5-5
Entrée / sortie par MTok2 $ / 10 $2 $ / 10 $4 $ / 20 $
Lecture cache / écriture 5m0,20 $ / 2,50 $0,20 $ / 2,50 $0,20 $ / 5 $
Prompt minimum cachable1 024 tokens512 tokens—
Contexte1M1M1M
Sortie max (synchrone)128K128K128K
Réglages de réflexion acceptésadaptive, disabledadaptive, between_toolsadaptive uniquement
Effort par défauthighhighmedium
Coupure de connaissances fiable—Juin 2026Juin 2026
Retrait au plus tôt—28 sept. 202722 sept. 2027

Quatre choses dans ce tableau sont véritablement nouvelles, et une seule fait la une quelque part :

  1. Le prompt minimum cachable a été divisé par deux, de 1 024 à 512 tokens. Si votre prompt système se situe entre 600 et 1 000 tokens, il était silencieusement non cachable sur Sonnet 5 et l'est désormais, à 10 % du prix d'entrée en lecture. Aucun changement de code, aucun en-tête bêta. C'est le gain le moins cher de toute la page.
  2. thinking: {"type": "disabled"} a disparu, remplacé par between_tools. Sonnet 5.5 se situe entre Sonnet 5 (qui acceptait disabled) et Opus 5.5 (qui n'accepte ni l'un ni l'autre) — il peut toujours sauter la réflexion préalable, simplement sous un nouveau nom et avec de nouvelles limites.
  3. L'effort par défaut est resté high — notez que c'est plus élevé que le défaut medium d'Opus 5.5. Le modèle le moins cher réfléchit davantage par tour dès la sortie de la boîte que le modèle cher.
  4. temperature, top_p et top_k renvoient 400 à toute valeur non par défaut, comme sur le reste de la gamme 5.x. Les balayages de paramètres d'échantillonnage ne sont pas un levier de réglage ici ; effort l'est.

Le tokenizer est inchangé par rapport à Sonnet 5, donc le même texte produit les mêmes comptages de tokens. Tout changement que vous mesurez sur votre facture est un changement dans le nombre de tokens que le modèle a choisi d'émettre.

Pourquoi la facture baisse alors que le prix ne bouge pas​

C'est la partie que la plupart des couvertures de lancement compressent en « 30 % moins cher » et se trompent subtilement. Le tarif est identique. L'affirmation d'Anthropic se décompose en trois effets distincts, et ils ne sont pas tous aussi faciles à capturer :

Guided walkthrough1 of 3
  1. La sortie est le côté cher à 10 $/MTok contre 2 $ en entrée. Sonnet 5.5 atteint le même résultat en moins de tokens de sortie que Sonnet 5, ce qui inclut les tokens de réflexion — la réflexion est facturée comme de la sortie même quand son texte ne vous est jamais retourné. Cet effet, vous l'obtenez gratuitement, sur le même code.

Les effets 1 et 2 sont exactement ce qu'un réglage effort reporté peut annuler. C'est pourquoi la section suivante est celle à lire avant de changer votre ID de modèle.

Effort : recalibrer, ne pas reporter​

Anthropic est explicite sur le fait que les niveaux d'effort sont recalibrés — un niveau n'achète pas la même quantité de réflexion qu'il achetait sur Sonnet 5. Il n'existe pas de table de conversion, par conception. Relancez votre balayage.

Les points de départ publiés ne sont pas le défaut :

Charge de travailCommencer àPourquoi
Général / incertainhighLe défaut de l'API.
Codage agentique, usage d'outils multi-étapes, bien spécifiémediumPuis passer à high pour les tâches plus difficiles ou plus longues.
Chat, sensible à la latencemedium ou lowUn effort plus élevé signifie une attente plus longue avant que la réponse ne commence.
N'importe quoixhigh / maxSeulement là où vous avez mesuré un gain de qualité.

Trois conséquences qui mordent en production :

  • Changer l'effort de premier niveau entre les requêtes invalide le cache de prompt. Si vous voulez une session interactive bon marché qui monte en gamme sur les tours difficiles, utilisez la bêta effort par message (output_config.effort sur un seul message), qui conserve le cache. Cette bêta est nouvelle sur 5.5 et n'était pas disponible sur Sonnet 5.
  • max_tokens doit couvrir la réflexion plus la réponse. La réflexion compte contre cette limite même quand le texte de réflexion est omis de la réponse. Une limite dimensionnée pour une requête sans réflexion sera tronquée. Pour le codage agentique, la consigne d'Anthropic est directe : réglez max_tokens sur 128 000 et diffusez en streaming.
  • Demander au modèle de moins réfléchir ne fonctionne pas de façon fiable. Baisser le niveau d'effort, si. À partir de medium, il réfléchit avant presque chaque réponse ; à low, il saute la réflexion sur la plupart des requêtes simples.

La taxe de révision à l'effort maximal​

À xhigh et max, Sonnet 5.5 ne s'arrête pas quand la tâche est terminée. Il lance ses propres tours de révision et de vérification, et si votre harnais propose des sous-agents, il lancera des sous-agents réviseurs — sans qu'on le lui demande. Anthropic a publié le correctif et, exceptionnellement, son ampleur : dans leurs tests sur des tâches de codage à l'effort max, le paragraphe ci-dessous a réduit le coût de session d'environ un tiers sans changement de qualité.

Arrêter les tours de revue auto-initiés aux efforts xhigh et max

When the work the user asked for is done and its checks pass, stop and report. Don't start extra
rounds of review or hardening on your own, and don't launch reviewer sub-agents unless the user
asked for a review. If you think a deeper review is worth doing, say so at the end.

Cela rend les révisions auto-initiées plus rares plutôt qu'impossibles. Le problème miroir existe au bas de la plage : à low et medium sur des tâches agentiques longues, le modèle est plus susceptible de s'arrêter et de faire un point avant de terminer, et à low, il signale parfois un changement de code terminé sans avoir exécuté une vérification qui le met à l'épreuve.

Les cinq changements cassants​

Chacun d'eux renvoie un HTTP 400 invalid_request_error sur du code qui fonctionnait sur Sonnet 5.

1. disabled → between_tools​

thinking: {"type": "disabled"} renvoie 400 avec un message qui nomme son remplaçant :

"thinking.type.disabled" is not supported for this model. Use "thinking.type.between_tools" for the
lowest thinking setting, or "thinking.type.adaptive" and "output_config.effort" to control thinking
behavior.

between_tools est le réglage de réflexion le plus bas sur Sonnet 5.5. Il ne nécessite aucun en-tête bêta et fonctionne sur toutes les plateformes qui proposent le modèle. Mais il est plus capricieux que ne l'a jamais été disabled :

  • Accepté à low, medium, high. À xhigh ou max, il renvoie 400 — ces niveaux exigent la réflexion adaptative (omettre thinking, ou envoyer thinking: {"type": "adaptive"} ; c'est équivalent).
  • L'effort ne peut pas changer en cours de conversation. Un output_config.effort par message qui diffère du niveau en vigueur renvoie 400. L'effort par tour nécessite la réflexion adaptative.
  • Il n'accepte aucun champ compagnon. display, budget_tokens ou block_binding envoyé à ses côtés renvoie 400. Les budgets manuels (thinking: {"type": "enabled", "budget_tokens": N}) renvoient 400 aussi.
  • Avec le repli côté serveur, une requête between_tools qui se replie sur Sonnet 5 s'y exécute avec thinking: {"type": "disabled"} — les réglages sont transposés à travers le repli pour vous.

Un piège de plus : avec between_tools, supprimez toute instruction disant au modèle de ne pas réfléchir. Ces lignes le rendent plus susceptible d'écrire des balises XML internes dans sa sortie visible.

Migrer une intégration avec la réflexion désactivée — de Sonnet 5 à Sonnet 5.5

# Before — accepted on Sonnet 5
client.messages.create(
  model="claude-sonnet-5",
  max_tokens=16000,
  thinking={"type": "disabled"},
  output_config={"effort": "xhigh"},      # fine with disabled on Sonnet 5
  messages=[{"role": "user", "content": "..."}],
)

# After — on Sonnet 5.5: rename the type AND drop effort to high or below
client.messages.create(
  model="claude-sonnet-5-5",
  max_tokens=16000,
  thinking={"type": "between_tools"},     # xhigh/max with this -> 400
  output_config={"effort": "high"},
  messages=[{"role": "user", "content": "..."}],
)

# If you need xhigh or max, use adaptive thinking instead of between_tools:
#   thinking={"type": "adaptive"}   (or omit the field entirely)

# SDKs that predate between_tools fail type checking on the literal.
# Update the SDK, or pass the value as raw JSON.

2. L'usage forcé d'outils est rejeté​

tool_choice réglé sur {"type": "any"} ou {"type": "tool", "name": "..."} renvoie 400 :

tool_choice: type "tool" and "any" are not supported for this model.

auto (le défaut) et none fonctionnent toujours. La même vérification s'applique sur le point de terminaison de comptage de tokens, ce qui est facile à manquer dans une suite de tests qui n'exerce que /v1/messages.

L'usage forcé d'outils remplissait deux rôles ; séparez-les :

  • La validité du schéma provient de l'usage strict d'outils (strict: true sur l'outil) ou des sorties structurées.
  • Le pilotage — amener le modèle à appeler l'outil tout court — provient du prompt indiquant quand l'outil s'applique.

3. Les blocs de réflexion sont liés au modèle, à la conversation et au compte​

Chaque bloc de réflexion enregistre quel modèle l'a produit, et les modèles ne lisent que certains blocs d'autres modèles. Le graphe est asymétrique et peu intuitif :

Blocs produits parSonnet 5.5 peut-il les lire ?
Sonnet 5.5 lui-mêmeOui
Sonnet 5, Opus 4.8, Haiku 4.5 et antérieursOui
Opus 5, Opus 5.5Non
Tout modèle Fable ou MythosNon

Et dans l'autre sens : aucun autre modèle ne lit les blocs de réflexion de Sonnet 5.5. Ainsi une conversation qui migre vers le haut de Sonnet 5 vers Sonnet 5.5 conserve son raisonnement ; une conversation qui quitte Sonnet 5.5 pour autre chose — y compris Opus 5.5, une voie de montée en gamme tentante — exécute chaque tour suivant sans lui. Les blocs illisibles sont supprimés avant que le modèle ne les voie, la requête réussit, et les blocs supprimés ne sont pas facturés. Avec l'en-tête bêta thinking-binding-controls-2026-08-01, les suppressions sont détaillées dans un tableau input_transformations de premier niveau.

Deux liaisons supplémentaires se superposent :

  • Préfixe de conversation. L'API vérifie si le prompt system, la liste tools, ou tout message antérieur a changé depuis qu'un bloc de réflexion de Sonnet 5.5 a été produit. Elle applique cela par défaut pour les comptes créés à partir du 31 août 2026, 00h00 UTC sur la Claude API, Bedrock et Google Cloud — rejouer un bloc après une telle modification y renvoie 400. Pour supprimer les blocs affectés plutôt que d'échouer, envoyez thinking-binding-controls-2026-08-01 et réglez thinking.block_binding.prefix_mismatch_behavior sur "drop_block". Notez que block_binding ne fonctionne qu'avec la réflexion adaptative ; sous between_tools, vos seules options sont un historique en ajout uniquement ou la suppression des blocs de réflexion à partir du tour modifié.
  • Compte. Les blocs de réflexion de Sonnet 5.5 ne fonctionnent que dans le compte qui les a produits, ou un compte lié. Un autre compte qui les envoie les voit supprimés, avec reason: "organization_binding_mismatch" sous la bêta de contrôles de liaison. Les blocs de modèles antérieurs ne sont pas affectés.
Guided walkthrough1 of 5
  1. Claude Code, claude.ai, Claude Managed Agents et le Claude Agent SDK le font déjà. Les intégrations en ajout uniquement n'ont pas besoin de changer.

4. computer_20251124 est rejeté — sur deux plateformes sur trois​

Sur la Claude API et Google Cloud, Sonnet 5.5 ne prend en charge l'usage d'ordinateur que via le jeu d'outils computer_toolset_20260801. Déclarer l'ancien outil computer_20251124 renvoie 400 :

'claude-sonnet-5-5' does not support tool types: computer_20251124.

Sur Amazon Bedrock, Sonnet 5.5 accepte toujours computer_20251124. Cette asymétrie est le genre de chose qui fait passer un déploiement multi-plateforme en CI sur un cloud et échouer sur un autre. Migrer signifie : abandonner l'ancien en-tête bêta, remplacer l'entrée tools par {"type": "computer_toolset_20260801"}, et mettre à jour la boucle d'agent pour les blocs tool_use membres, les actions par lots, et toolset_name sur les résultats. Les intégrations déjà sur le jeu d'outils, et tout ce qui utilise l'outil d'usage du navigateur, n'ont pas besoin de changer.

5. Les associations de conseillers se sont resserrées​

Avec l'outil conseiller (bêta), un Sonnet 5.5 exécuteur accepte Mythos 5.1, Fable 5.1, Mythos 5, Fable 5, Opus 5.5, Opus 5, ou Sonnet 5.5 lui-même comme conseiller. Opus 4.8, Opus 4.7 et Sonnet 5 sont rejetés avec 400 — les trois fonctionnaient pourtant comme conseillers pour un exécuteur Sonnet 5. Chaque conseiller que Sonnet 5.5 accepte retourne son conseil chiffré, sous forme de bloc advisor_redacted_result, de sorte que votre client ne peut pas lire le texte du conseil.

Le sixième changement : HTTP 200, et votre interface se tait​

Celui-ci ne fait échouer rien et est le plus susceptible d'atteindre vos utilisateurs avant d'atteindre vos journaux.

Entre les appels d'outils, Sonnet 5.5 écrit des notes destinées à l'utilisateur sur ce qu'il vient de trouver et ce qu'il va faire ensuite. Les notes de plus d'une phrase ou deux reviennent désormais sous forme de blocs thinking de mise à jour de progression ; les remarques plus courtes restent en text. Au réglage par défaut display: "omitted", le champ texte d'un bloc de mise à jour de progression est vide. Un client qui n'affiche que les blocs text ne montre donc rien du tout pendant un long tour agentique — aucune erreur, aucun avertissement, juste du silence là où il y avait auparavant de la narration.

Trois issues, par ordre de simplicité :

  1. Utilisez between_tools. Les notes reviennent avec leur texte de résumé, sans besoin du champ display (et aucun n'est accepté).
  2. Réglez display: "updates" avec l'en-tête bêta thinking-display-updates-2026-08-18. Vous obtenez un court résumé de chaque mise à jour de progression pendant que le raisonnement lui-même reste caché.
  3. Donnez au modèle un outil pour envoyer un message à l'utilisateur, pour les cas où il a besoin d'afficher un texte exact en cours de tour — un extrait de code, une question à laquelle il a besoin d'une réponse. Dites-lui de n'utiliser cet outil que pour ce type de contenu, et déclarez l'outil dans la première requête pour que tools ne change plus jamais ensuite.

Ensuite, nettoyez autour : supprimez les instructions du type « gardez tous les résultats pour la réponse finale », et si vous voulez des mises à jour à des moments prévisibles, demandez-les explicitement — une ligne avant le premier appel d'outil, un récapitulatif à la fin. Le modèle suit cela.

Si les longs tours restent silencieux, votre harnais peut relancer — avec précaution. Comptez les étapes consécutives d'appel d'outils qui n'ont envoyé aucun texte à l'utilisateur, et après plusieurs (disons cinq), ajoutez un rappel d'un tour après les derniers résultats d'outils, sous forme de message système limité au tour :

Relance du harness pour un tour agentique silencieux

The user hasn't heard from you in a while — say in a few words what you're doing, then continue.

Arrêtez après le deuxième ou troisième essai si cela ne prend pas. Un texte fréquent du harnais après des résultats d'outils fait soupçonner au modèle une injection de prompt — ce qui est la section suivante. Comme le rappel est ajouté plutôt qu'inséré puis retiré, le cache de prompt et la réflexion préservée survivent tous deux. Mesure d'Anthropic : à l'effort high avec un outil de message à l'utilisateur disponible, cela raccourcit les plus longs silences sans changement mesurable de la qualité de la tâche.

Lire honnêtement le tableau de lancement​

BenchmarkSonnet 5Sonnet 5.5Opus 5.5Sonnet 5.5 en % d'Opus 5.5
Terminal-Bench 4.010,3 %70,6 %66,4 %106 %
GDPval-AA v2.1 (Elo)14491844184699,9 %
AA-Briefcase v1.1 (Elo)13591811182299,4 %
OSWorld 2.1 (crédit partiel)—80,1 %81,8 %98 %
CursorBench 4.034,1 %55,5 %57,8 %96 %
Chartography (sans outils)—61,6 %64,4 %96 %
Humanity's Last Exam (avec outils)54,9 %64,5 %67,7 %95 %
FrontierCode 1.1 (effort max)42,4 %46,2 %54,4 %85 %

Quatre lectures honnêtes de ce tableau :

  • L'écart n'est pas uniforme, et le moyenner l'efface, ce qui cache le signal utile. Sur l'Elo travail de connaissance, les deux modèles sont dans la marge de bruit l'un de l'autre. Sur le benchmark de codage le plus difficile, FrontierCode 1.1, Sonnet 5.5 a 8,2 points de retard — 85 % d'Opus 5.5. Cette seule ligne est la base honnête de la propre position d'Anthropic selon laquelle Opus 5.5 reste nettement plus fort sur le travail complexe et ouvert exigeant un jugement soutenu.
  • Terminal-Bench 4.0 est la seule ligne où le modèle à moitié prix l'emporte, 70,6 % contre 66,4 %. Ce benchmark est le proxy publié le plus proche de « faire tourner un agent dans un shell jusqu'à ce que le travail soit fait », exactement là où moins d'appels d'outils et moins de tokens se cumulent.
  • Traitez les 10,3 % de Sonnet 5 sur Terminal-Bench 4.0 avec suspicion, pas avec admiration. Un bond générationnel de 60 points sur une version de benchmark en dit au moins autant sur le harnais et la version de notation que sur le modèle. Utilisez-le pour conclure « cette version de ce benchmark pénalise le comportement d'agent de Sonnet 5 », pas « Sonnet 5.5 est sept fois meilleur en codage agentique ».
  • Les sources divergent sur FrontierCode au sommet de la plage d'effort. Le tableau d'Anthropic rapporte 46,2 % à l'effort max ; au moins un agrégateur rapporte un chiffre plus élevé de 52,1 % à xhigh. Nous n'avons pas pu confirmer ce second chiffre par rapport au tableau principal, donc considérez-le comme non vérifié — mais notez que « plus d'effort a donné un score plus bas » est cohérent avec le conseil de la documentation elle-même de réserver xhigh et max aux cas où vous avez mesuré un gain, plutôt que de supposer une amélioration monotone.

La mesure indépendante, comme toujours, arrive plus basse que la mesure du fournisseur sur les benchmarks agentiques. Faites tourner vos propres évaluations avant d'inscrire un chiffre sur une diapositive.

Les modes de défaillance discrets​

Aucun d'eux ne lève d'erreur. Tous vous coûtent de la précision ou de la confiance.

Les sorties structurées qui réfléchissent jusqu'à épuisement​

Demandez une réponse JSON pour une tâche nécessitant quelques étapes de calcul — additionner des chiffres d'un document, appliquer une règle, classer des éléments — et Sonnet 5.5 répond souvent sans réfléchir au préalable, surtout aux efforts low et medium. Avec les sorties structurées, le texte de réponse ne contient que le JSON, donc le travail intermédiaire n'a nulle part où aller sauf la réflexion ; sauter la réflexion fait chuter la précision.

  • Avec la réflexion adaptative, ajouter « Réfléchissez au problème avant de répondre. » au prompt système rapproche la précision à l'effort high de celle à xhigh, pour une hausse modeste des tokens de sortie.
  • between_tools est le mauvais réglage pour ces requêtes : sans outil en jeu, cela signifie aucune réflexion du tout, et cette ligne n'a aucun effet.
  • À low et medium avec les sorties structurées, le modèle continue parfois à réfléchir jusqu'à atteindre max_tokens. Traitez toute réponse avec stop_reason: "max_tokens" comme échouée et à relancer, même quand son texte contient par ailleurs un JSON valide. C'est la façon la plus probable de livrer un chiffre faux avec assurance.

Si vous ne pouvez pas utiliser les sorties structurées et demandez du JSON dans le prompt, le modèle a tendance à travailler le problème dans le texte de la réponse et à placer le JSON à la fin. Ne découpez pas du premier { au dernier } — il écrit parfois un brouillon avant la réponse finale et vous capteriez les deux.

Extraire la valeur JSON finale d'une réponse mixte

# Read only text blocks. Treat stop_reason == "max_tokens" as a failure and retry.
# Starting at each { or [, try to parse a JSON value; continue from the END of a value
# that parses, so values nested inside it are not counted on their own. Keep the LAST one.

import json

def last_json_value(text):
  dec, best, i = json.JSONDecoder(), None, 0
  while i < len(text):
      if text[i] in "{[":
          try:
              value, end = dec.raw_decode(text, i)
          except ValueError:
              i += 1
              continue
          best, i = value, end          # jump past it: skip nested values
      else:
          i += 1
  return best

# Then check the fields you expect are present, and retry once if they are not.

De vrais messages utilisateur pris pour des injections de prompt​

Sonnet 5.5 est entraîné à résister à l'injection indirecte de prompt — des instructions arrivant via des résultats d'outils et d'autre contenu qu'il lit en cours de tâche. Parfois, il classe mal de cette façon un message authentique de l'utilisateur, dit à l'utilisateur que le résultat d'outil contenait un texte se faisant passer pour un message de sa part, et soit l'ignore, soit demande une confirmation. Le déclencheur est le placement : un texte arrivant immédiatement après des résultats d'outils, surtout à chaque étape.

  • Ne mettez jamais de texte utilisateur à l'intérieur d'un bloc tool_result. C'est le placement qu'il interprète le plus souvent de travers.
  • Livrez la saisie utilisateur en cours de tour comme un tour utilisateur : ajoutez ses mots comme bloc de texte dans le message utilisateur qui porte les blocs tool_result, après le dernier tool_result.
  • Gardez les avis du harnais dans un message système en cours de conversation séparé, après les mots de l'utilisateur. Ne mettez jamais un avis et les mots de l'utilisateur dans le même bloc.
  • Abandonnez votre propre compte à rebours de tokens/budget après les résultats d'outils dans les sessions interactives où les utilisateurs peuvent taper en cours de tour. Un compte à rebours par étape en est la cause classique. La bêta des budgets de tâche ajoute un compte à rebours similaire mais n'a pas été observée comme causant cette mauvaise interprétation.

Noms d'outils différant par la casse​

Sonnet 5.5 appelle parfois un outil déclaré avec un nom qui ne diffère que par la casse — bash pour Bash — ou passe un paramètre connu sous un nom légèrement différent. Ne traitez pas cela comme fatal. Soit acceptez l'appel quand la correspondance est sans ambiguïté, soit renvoyez un tool_result avec is_error: true indiquant le nom exact attendu ; le modèle se corrige généralement de lui-même au tour suivant.

Graphiques : donnez-lui des outils avant de lui donner de l'effort​

Pour les graphiques denses et les dessins techniques, donnez au modèle un moyen de recadrer, zoomer ou exécuter du code sur l'image. Le résultat mesuré mérite d'être intériorisé : avec des outils à l'effort high, il a lu les graphiques plus précisément que sans outils à l'effort max, pour une fraction du coût. Sur les dessins techniques, les outils n'aident qu'à partir de high, et le plus à xhigh et max. Tendez la main vers l'outil, pas vers le curseur.

Refus : cinq catégories, et seulement deux sont relancées​

Une requête refusée est un HTTP 200 avec stop_reason: "refusal" et un objet stop_details nommant la catégorie. Sonnet 5.5 est le premier Sonnet à embarquer des garde-fous cyber comparables à ceux des modèles les plus capables d'Anthropic, et le premier avec des classificateurs qui bloquent l'extraction de raisonnement.

Catégorie stop_detailsCe qu'elle couvreLe repli côté serveur la relance-t-il sur Sonnet 5 ?
cyberPourrait permettre un dommage cyber — malware, développement d'exploit. Trouver des vulnérabilités dans du code source est autorisé ; le travail à double usage à haut risque ne l'est pas.Oui
frontier_llmPourrait aider au développement de modèles d'IA concurrents.Oui
bioPourrait permettre un dommage biologique. Les questions de santé et d'éducation courantes ne sont pas affectées.Non
reasoning_extractionDemande au modèle de reproduire son raisonnement interne dans le texte de la réponse.Non
general_harmsUn autre domaine de la politique d'usage. Un travail bénin peut aussi déclencher cela.Non

Deux notes pratiques. D'abord, si vos prompts demandent au modèle d'inclure son raisonnement dans la réponse, supprimez ces lignes — elles invitent des refus reasoning_extraction. Lisez le raisonnement depuis des blocs de réflexion résumés (display: "summarized") à la place. Ensuite, le fait qu'un refus arrivant avant toute sortie soit facturé dépend de sa catégorie, et il compte dans tous les cas contre vos limites de débit.

Le travail légitime en sciences de la vie bloqué par le classificateur bio peut faire l'objet d'une candidature au Life Sciences Verification Program d'Anthropic.

Alors, quel modèle faire tourner concrètement ?​

Guided walkthrough1 of 5
  1. Tâches courantes, corrections de bugs, usage d'outils multi-étapes, documents et tableurs soignés. Commencez à l'effort medium pour le codage agentique, high pour le travail général, et mesurez. À 2 $/10 $ avec un contexte de 1M, c'est le modèle le moins cher de la gamme qui reste proche de la frontière sur le travail de connaissance.

La migration elle-même est un échange d'ID de modèle plus six vérifications, et Anthropic en fournit l'automatisation : dans Claude Code, /claude-api migrate this project to claude-sonnet-5-5 applique l'échange d'ID et les changements de paramètres cassants sur toute une base de code et vous remet une checklist de ce qu'il faut vérifier à la main. Elle vous demande de confirmer le périmètre avant de modifier quoi que ce soit. Si vous utilisez Claude Managed Agents plutôt que l'API Messages directement, le nom du modèle est le seul changement requis.

Appuyez sur Entrée ou Espace pour retourner la carte. Utilisez les flèches gauche et droite pour naviguer entre les cartes.Terme affiché.
1 / 10

Check yourself

0/6
  1. Sonnet 5.5 facture exactement les prix de Sonnet 5 — 2 $/10 $ par MTok, mêmes tarifs de cache, même tokenizer. Anthropic continue d'affirmer jusqu'à 30 % de moins par tâche. D'où vient l'économie ?
  2. Votre intégration fait tourner Sonnet 5 avec thinking: {"type": "disabled"} et un effort output_config "xhigh". Quel est le changement minimal correct pour Sonnet 5.5 ?
  3. Après avoir migré un produit de chat vers Sonnet 5.5, des utilisateurs signalent que l'assistant paraît figé pendant les longs tours utilisant des outils, bien que la réponse finale arrive correctement et qu'aucune erreur ne soit journalisée. Que s'est-il passé ?
  4. Un tour difficile arrive dans une conversation Sonnet 5.5 et vous voulez plus de profondeur. Quelle option préserve le raisonnement accumulé jusque-là ?
  5. Vous utilisez les sorties structurées à l'effort medium pour extraire des totaux de factures. Une réponse revient avec stop_reason "max_tokens" mais son texte se parse comme un JSON valide avec des chiffres plausibles. Que doit faire votre code ?
  6. Quelle affirmation sur le tableau de benchmark de lancement est exacte ?

Suite​

Sources et lectures complémentaires​