Après Claude Sonnet 5.5, le tarif n’a pas bougé — pourquoi l’extraction JSON fait encore 400. De between_tools au JSON Schema

D’emblée : Sonnet 5.5 garde chaque ligne de la grille tarifaire et change le contrat de requête. Le 28 septembre 2026, Anthropic a publié Claude Sonnet 5.5 (claude-sonnet-5-5). Entrée / sortie restent $2 / $10 ; les lectures cache restent $0.20. Anthropic dit que la sortie est 30 %+ plus rapide et que la plupart des charges coûtent environ 30 % moins — cette économie, ce sont les tokens par tâche, pas le prix affiché. Ce qui casse la production, ce sont les anciens interrupteurs copiés de Sonnet 5 : thinking: {"type": "disabled"} renvoie 400 ; les valeurs any et tool de tool_choice renvoient 400 ; un temperature, top_p ou top_k hors défaut est aussi 400. Le piège plus silencieux, c’est l’extraction JSON : sur une requête sans outils, between_tools signifie que le modèle ne pense pas d’abord, et Structured Output part quand même de travers. La page prompting d’Anthropic classe ce cas sous « Reasoning tasks with JSON output ».

Rédigé au 29 septembre 2026, d’après la page modèle, le « What’s new », et le guide de migration encore en vigueur ce jour-là. Ce site a déjà pourquoi Opus 5.5 ne vous laissera plus forcer du JSON avec tool_choice (24 septembre). Cet article ne réécrit pas ces quatre échecs. Il répond seulement à ce qu’un pipeline JSON Sonnet 5 → 5.5 doit changer en plus. Haiku 5.5 est encore « in the coming weeks ». Cet article n’emprunte pas cette date.

Ce qui a été publié le 28 septembre

Claude Sonnet 5.5 est le deuxième modèle de la famille Claude 5.5. Positionnement officiel : le milieu vitesse-et-intelligence ; coding quotidien, corrections de bugs, documents et tableurs. L’ID est claude-sonnet-5-5 sur l’API Claude, Google Cloud, Microsoft Foundry, et Claude Platform on AWS ; Bedrock utilise anthropic.claude-sonnet-5-5. Le retrait n’est pas avant le 28 septembre 2027. Le tokenizer correspond à Sonnet 5, donc le même texte produit les mêmes comptes de tokens.

Prix par million de tokens : $2 en entrée, $10 en sortie, $2.50 pour une écriture cache 5 minutes, $4 pour une écriture cache 1 heure, $0.20 pour une lecture cache. Le batch est à moitié prix. Le contexte est 1M ; la sortie synchrone max est 128K. Message Batches peut atteindre 300K avec output-300k-2026-03-24. Le prompt cacheable minimum descend des 1 024 tokens de Sonnet 5 à 512. L’effort par défaut est high — Opus 5.5 est à medium par défaut. Omettre effort et la requête tourne à high. Ce n’est pas une compatibilité silencieuse avec Sonnet 5.

Le lancement présente Sonnet 5.5 comme le complément plus rapide et moins cher d’Opus 5.5. Cet article ne choisit pas un modèle sur un classement. Ce qui compte, c’est que la grille tarifaire est restée en place pendant que thinking, tool_choice et le contrat d’extraction JSON ont bougé.

Cinq échecs durs, une table

La doc liste les requêtes qui deviennent 400 sur 5.5. Les trois premières partagent une racine avec Opus 5.5 et Fable 5.1. Le remplacement de la première ligne est différent :

Un autre changement ne fait pas échouer la requête mais se tait : les notes plus longues entre appels d’outils arrivent en blocs thinking. Avec le display: "omitted" par défaut, le texte est vide. Une UI qui streamait ces phrases comme barre de progression devient silencieuse. Pour la progression sous adaptive thinking, réglez thinking.display (updates a besoin d’un en-tête beta). between_tools renvoie le texte de résumé, et ce type refuse un champ display.

L’échantillonnage n’est plus un bouton. Un temperature, top_p ou top_k hors défaut est un 400. Les requêtes qui baissaient temperature pour « stabiliser le JSON » doivent maintenant stabiliser le schema à la place.

disabled a disparu ; between_tools est le plancher

Sonnet 5 coupait thinking avec disabled. Sur 5.5 cette ligne est un 400 dont le message pointe vers between_tools. Le réglage le plus bas ressemble à ceci :

{
  "model": "claude-sonnet-5-5",
  "thinking": { "type": "between_tools" },
  "output_config": { "effort": "high" }
}

between_tools n’a besoin d’aucun en-tête beta et est accepté sur chaque plateforme qui offre le modèle. Il coupe seulement le thinking préalable. Les notes de progression plus longues entre appels d’outils reviennent encore en blocs thinking. Renvoyez-les sans modification ; le modèle reçoit la note complète, pas le résumé. Sans outils, la réponse n’est en général que du texte — la forme de l’ancien disabled.

Les limites sont strictes. Il est accepté à low / medium / high. Associez-le à xhigh ou max et vous avez 400. Ajoutez display, budget_tokens ou block_binding et vous avez aussi 400. Un changement en milieu de conversation de output_config.effort est un 400 — l’effort par tour a besoin d’adaptive thinking. Quand le fallback côté serveur atterrit sur Sonnet 5, between_tools y est traduit en disabled.

Donc 5.5 n’oblige pas thinking à rester à pleine profondeur. Il retire l’ancien interrupteur disabled. Une fois cet interrupteur parti, ceux qui veulent couper thinking doivent envoyer un nouveau type. Ceux qui veulent un JSON stable ne devraient souvent pas le couper — voir la section suivante.

Pour extraire du JSON sans outil, ne coupez pas thinking

La page prompting d’Anthropic a sa propre section pour ça : donnez à Sonnet 5.5 une tâche JSON qui demande quelques étapes (totaux, une règle, un classement) et à low / medium il répond souvent sans penser d’abord. Avec Structured Output, le texte visible ne peut être que du JSON, donc le travail ne peut se faire que dans thinking. Sautez thinking et la précision chute.

L’ordre documenté est :

1. Utilisez Structured Output quand vous le pouvez. Le corps est alors un objet qui correspond au schema. Vous ne faites pas JSON.parse sur la prose du chat. Voir ce qu’est le Structured Output.
2. Utilisez adaptive thinking, pas between_tools. Sur une requête sans outils, between_tools signifie pas de thinking d’abord. Une ligne « réfléchissez avant de répondre » dans le prompt n’y a aucun effet. Découper « répondre, puis JSON » en deux requêtes a bien score dans leurs tests et coûtait trop de latence et de tokens pour être un défaut.
3. Terminez le prompt system par Think the problem through before you answer. À high, la précision s’approche de xhigh pour un surplus modeste de tokens de sortie. À low / medium elle monte aussi, à un coût en tokens plus large.
4. Laissez de la place dans max_tokens pour thinking. Avec Structured Output à low / medium, le modèle pense parfois jusqu’au plafond. Traitez une réponse dont le stop_reason est max_tokens comme un échec même si le texte est du JSON valide, et réessayez.

Sans Structured Output, le modèle travaille souvent dans la prose et met le JSON à la fin. Parser toute la réponse échoue. Le fallback documenté : lisez seulement les blocs text, tentez un parse depuis chaque { ou [, et gardez la dernière valeur complète. Ne prenez pas l’intervalle du premier { au dernier } — un brouillon peut s’asseoir au milieu. Voir pourquoi JSON.parse échoue. C’est un fallback, pas un contrat.

Les outils forcés sont un 400, comme sur Opus 5.5

La famille 5.5 partage la même erreur :

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

Le remplacement reste : gardez tool_choice sur auto, mettez strict: true sur l’outil, et épinglez les paramètres avec JSON Schema. Posez la réponse finale sur Structured Output. Si vous voulez que le modèle appelle un outil plutôt que de répondre en prose, dites dans le prompt quand l’outil s’applique. Le prompt influence quel outil auto choisit. Il ne remplace pas le schema. La version longue est dans pourquoi Opus 5.5 ne vous laissera plus forcer du JSON avec tool_choice et pourquoi le Tool Calling dépend de JSON Schema.

5.5 ajoute une note de tolérance : il appelle parfois un outil avec la mauvaise casse, ou un paramètre sous un nom légèrement différent. Ne traitez pas ça comme fatal. Acceptez l’appel quand la correspondance est unique, ou renvoyez is_error: true avec le nom exact. Gardez le schema strict. La correspondance des noms peut être d’un cran plus lâche.

La grille tarifaire n’a pas bougé ; l’effort par défaut est high

Les prix affichés correspondent à Sonnet 5. Le « environ 30 % moins cher » officiel, ce sont moins de tokens par tâche, pas le menu. Des écrits indépendants montrent déjà l’autre face : quand une tâche ne borne pas sa propre sortie, le nouveau modèle peut coûter plus. Faites passer le même schema dans une passe d’extraction avant de changer le routage.

Les paliers d’effort sont recalibrés. Le même high n’est pas la même quantité de thinking que sur Sonnet 5. La doc part de high pour le travail quotidien ; medium pour le coding agentique bien spécifié et les boucles d’outils ; medium ou low pour le chat et le travail sensible à la latence. Changer l’effort de premier niveau casse le prompt cache. Les changements par tour ont besoin de l’effort per-message (beta) sous adaptive thinking. between_tools ne laissera pas effort bouger en milieu de conversation.

Ne mélangez pas les défauts avec Opus 5.5 : ce modèle est à medium par défaut ; Sonnet 5.5 est à high. Échangez seulement la chaîne modèle et la facture comme la latence sautent. Les blocs thinking ne voyagent pas librement non plus. 5.5 peut lire les blocs de Sonnet 5, Opus 4.8, Haiku 4.5 et des modèles plus anciens. Il ne lit pas Opus 5, Opus 5.5, Fable ni Mythos. Aucun autre modèle ne lit les blocs Sonnet 5.5. Déplacez une conversation d’Opus 5.5 vers Sonnet 5.5 et l’API jette le reasoning. La requête renvoie encore 200 ; les blocs jetés ne sont pas facturés.

Température, cache, computer use, advisor

Un temperature / top_p / top_k hors défaut est un 400. Les pipelines qui « serraient le JSON » avec l’échantillonnage doivent maintenant serrer le schema. Le plancher cache est 512 tokens, donc les prompts system courts se cachent plus facilement. Changer l’effort de premier niveau invalide encore ce cache.

Sur l’API Claude et Google Cloud, computer use n’accepte que computer_toolset_20260801. Bedrock accepte encore computer_20251124. L’outil advisor (beta) ne laissera pas un exécuteur 5.5 s’apparier avec Opus 4.8 / 4.7 ou Sonnet 5. Les advisors que 5.5 accepte renvoient des blocs advisor_redacted_result chiffrés ; le client ne peut pas lire le texte du conseil.

Pour changer un schema d’outil en milieu de conversation, inline-tools-2026-09-15 peut porter une définition complète dans un message system intermédiaire sans modifier le tableau tools de premier niveau. C’est la même règle que le thinking lié au préfixe : ajoutez à l’historique. La compaction (compact-2026-09-04) peut substituer un résumé signé tout en gardant thinking valide, aux conditions de la page Compaction d’Anthropic.

Cinq contrôles avant de changer la chaîne modèle

1. Cherchez thinking. Enlevez disabled et budget_tokens. Pour couper le thinking préalable, envoyez between_tools à high ou en dessous. Pour les tâches de raisonnement JSON, utilisez adaptive thinking.
2. Cherchez tool_choice. Remplacez chaque any / tool nommé par auto. Activez strict et serrez input_schema.
3. Cherchez temperature / top_p / top_k. Supprimez les hors-défaut. Stabilisez le JSON avec le schema, pas avec l’échantillonnage.
4. Posez effort explicitement. N’héritez pas le high par défaut. Un routage partagé avec Opus 5.5 a deux défauts différents.
5. Replay et cache. Sur les comptes après le 31 août, ne modifiez pas tools ni system dans l’historique. En venant d’Opus 5.5, attendez-vous à ce que les blocs thinking soient jetés.

Inspecter le schema avec les outils JSON locaux

Avant de poser le modèle sur claude-sonnet-5-5, étalez trois textes dans le navigateur : l’ancien input_schema, un objet arguments que vous obteniez avec disabled ou un tool_choice forcé, et le schema que vous comptez poser sur Structured Output.

• Validateur JSON — la grammaire est-elle légale ; si vous avez un schema, vérifiez ensemble champs required et clés en trop.
• Formateur JSON — déroulez une définition d’outil sur une ligne et voyez si additionalProperties est posé.
• JSON Diff — comparez un échantillon thinking coupé avec le plus petit objet que le schema strict autorise.

Rien ne quitte le navigateur. Stabilisez le contrat, puis changez la chaîne modèle. 5.5 changera effort et rejettera disabled et l’ancien tool_choice. Vos noms de champs et la liste required ne devraient pas se relâcher avec lui.

FAQ

Résumé

Sonnet 5.5 tient la grille tarifaire immobile et transforme disabled en un 400. Copiez une requête Sonnet 5 et vous échouez dur sur thinking, tool_choice et temperature. Pour couper le thinking préalable, envoyez between_tools. Pour un JSON stable, utilisez adaptive thinking plus Structured Output, ou auto plus strict plus JSON Schema. Sur une tâche de raisonnement sans outil, couper thinking est une baisse de précision mesurée.

Aplatissez d’abord le schema, un objet arguments d’échantillon, et le contrat strict dans un validateur local, puis passez à claude-sonnet-5-5. Le prix affiché peut rester. Le contrat de champs ne devrait pas se relâcher avec lui.