Claude Sonnet 5 vs Sonnet 4.6 : Nouveautés et faut-il upgrader ?

Anthropic a lancé Claude Sonnet 5 le 30 juin 2026, et il s'agit d'un remplacement direct pour Sonnet 4.6. Il suffit de changer l'ID du modèle et, dans la plupart des cas, votre code continue de fonctionner. Mais « dans la plupart des cas » est une précision importante dans cette phrase. Sonnet 5 est livré avec un nouveau tokenizer, une réflexion adaptative activée par défaut, et quelques paramètres de requête qui renvoient désormais des erreurs au lieu de s'exécuter. Cet article détaille exactement ce qui a changé, ce que cela coûte, et si la mise à niveau vaut la peine pour votre charge de travail.

En bref : même prix par jeton, meilleurs scores sur les tâches de codage et d'agent, trois petits changements de code, et une particularité non évidente du tokenizer qui affecte vos nombres de jetons et vos budgets. Lisez les détails avant de basculer en production.

La mise à niveau en un coup d'œil

Sonnet 5 conserve la même tarification par jeton que Sonnet 4.6, donc sur une base par jeton, rien ne change dans votre facture. Il améliore les benchmarks qui comptent pour l'utilisation d'outils et le codage. Et il modifie suffisamment le comportement par défaut pour qu'un échange aveugle puisse vous surprendre.

Voici le comparatif.

Tout le reste qui fonctionne sur Sonnet 4.6 fonctionne sur Sonnet 5 sans autre modification de code : les sorties structurées, la vision, la mise en cache des invites, l'utilisation d'outils et le traitement par lots sont tous conservés. La seule fonctionnalité de plateforme que vous perdez est le Priority Tier, qui n'est pas disponible sur Sonnet 5.

Ce qui s'est amélioré : les benchmarks

Sonnet 5 est positionné comme le modèle Sonnet le plus "agentic" à ce jour, et les chiffres rapportés le confirment pour les tâches intensives en outils. Il s'agit des benchmarks de lancement d'Anthropic, corroborés par les articles du jour du lancement. Considérez-les comme des chiffres rapportés, et non comme des tests indépendants.

C'est un réel bond sur les tâches où Sonnet est le plus utilisé : l'écriture et la correction de code avec des outils en boucle, et l'utilisation d'un ordinateur ou d'un terminal. Anthropic rapporte également que Sonnet 5 se rapproche d'Opus 4.8 une fois que les outils sont impliqués, à quelques points près sur les tâches agentiques, tout en coûtant beaucoup moins cher. Si votre application est de type agent, c'est la mise à niveau que vous attendiez. Pour le face-à-face avec le modèle premium, voir Sonnet 5 vs Opus 4.8.

Sonnet 5 est également plus sûr que la version 4.6 selon les mesures d'Anthropic : un taux plus faible de comportements indésirables, moins d'hallucinations et de flagorneries, et une meilleure résistance à l'injection d'invites. C'est le premier modèle de niveau Sonnet avec des protections de cybersécurité en temps réel. Un comportement à connaître : un refus d'une requête interdite revient sous la forme d'un HTTP 200 réussi avec stop_reason: "refusal", et non comme une erreur. Gérez cette raison d'arrêt dans l'analyse de votre réponse.

Les trois vrais changements de code

La plupart des migrations ne concernent que ces trois points. Passez-les en revue, ajustez si nécessaire, et le reste de votre intégration reste inchangé.

1. La réflexion adaptative est désormais activée par défaut

Sur Sonnet 4.6, l'absence de champ thinking signifiait pas de réflexion. Sur Sonnet 5, une requête sans champ thinking s'exécute avec la réflexion adaptative activée. Le modèle décide de la profondeur de la réflexion en fonction de la tâche, et vous contrôlez cette profondeur avec le paramètre `effort` (low, medium, high, ou xhigh).

C'est important car max_tokens est une limite stricte sur la sortie totale, et la sortie totale inclut désormais les jetons de réflexion en plus de votre texte de réponse. Un max_tokens qui était dimensionné pour le texte de réponse seul sur 4.6 peut désormais tronquer votre réponse sur Sonnet 5, car la réflexion utilise le même budget.

Si une charge de travail fonctionnait auparavant sans réflexion et que vous souhaitez qu'il en soit ainsi, désactivez explicitement la réflexion :

from anthropic import Anthropic

client = Anthropic()

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=1024,
    thinking={"type": "disabled"},
    messages=[
        {"role": "user", "content": "Return the OpenAPI 3.1 path object for GET /invoices/{id}."}
    ],
)

print(response.content[0].text)

Pour utiliser la réflexion adaptative avec une profondeur contrôlée, définissez l'effort au lieu de la désactiver :

response = client.messages.create(
    model="claude-sonnet-5",
    max_tokens=8192,
    thinking={"type": "adaptive"},
    effort="medium",
    messages=[
        {"role": "user", "content": "Draft integration tests for the POST /orders endpoint."}
    ],
)

Notez la forme : thinking={"type": "adaptive"}, et non un budget de jetons. Cela nous mène au changement suivant.

2. La réflexion étendue manuelle est supprimée

L'ancien modèle thinking: {type: "enabled", budget_tokens: N} renvoie une erreur 400 sur Sonnet 5. Il était déjà déprécié sur 4.6, la plupart des codes actuels l'ont donc abandonné, mais vérifiez-le. Remplacez tout budget manuel par la réflexion adaptative et le paramètre `effort`. Si vous définissiez un grand budget_tokens pour des tâches difficiles, effort="high" ou effort="xhigh" est le levier de remplacement.

3. Les paramètres d'échantillonnage renvoient désormais 400

Définir temperature, top_p, ou top_k à une valeur non par défaut renvoie une erreur 400 sur Sonnet 5. Les omettre, ou les laisser à leur valeur par défaut, est acceptable. Cette contrainte était déjà présente sur Opus 4.7 et versions ultérieures ; elle est nouvelle pour la classe Sonnet.

Si vous comptiez sur temperature=0 pour une sortie à l'allure déterministe, supprimez-le et orientez le comportement via votre invite système à la place. Soyez explicite quant au format, au ton et aux contraintes dans les instructions plutôt que par l'échantillonnage. Une recherche rapide de ces paramètres dans votre base de code vous évitera une série d'erreurs 400 en production.

Une chose qui n'a pas changé depuis 4.6 : le pré-remplissage des messages de l'assistant n'est toujours pas pris en charge et renvoie une erreur 400. Si vous forciez le début d'une réponse en pré-remplissant le tour de l'assistant, utilisez plutôt les sorties structurées, output_config.format ou les instructions de l'invite système.

Le piège du tokenizer dont personne ne vous parle

Sonnet 5 utilise un nouveau tokenizer. Le même texte d'entrée produit environ 30 % de jetons de plus qu'avec Sonnet 4.6, soit environ 1,3 fois plus. Ce n'est pas un changement d'API. Les formes des requêtes, des réponses et du streaming sont identiques, et vous n'écrivez pas de nouveau code pour cela. Mais cela modifie tout ce que vous mesurez ou budgétisez en jetons.

Voici ce qu'il faut remesurer :

• Comptes de jetons et champs usage. La même invite rapporte plus de jetons avec Sonnet 5. Ne réutilisez pas vos comptes de la version 4.6. Relancez le comptage de jetons pour claude-sonnet-5 pour toute invite que vous suivez.
• Votre fenêtre de contexte de 1M de jetons contient moins de texte. Chaque jeton couvre désormais en moyenne moins de texte, de sorte que la même fenêtre peut contenir moins de caractères de votre contenu. Si vous utilisiez le contexte au maximum, vérifiez qu'il convient toujours.
• Les budgets max_tokens dimensionnés près de la sortie attendue peuvent tronquer. Un budget qui contenait confortablement votre réponse typique sur la version 4.6 pourrait la tronquer sur Sonnet 5. Combiné à la réflexion adaptative partageant ce budget, c'est la cause la plus courante de réponses inopinément courtes après une mise à niveau.
• Le coût par requête d'un texte équivalent peut être plus élevé. Le taux par jeton est inchangé, mais plus de jetons par requête signifie que vous payez plus pour le même texte.

Ce dernier point mérite un exemple détaillé. Supposons qu'une invite plus une réponse représentaient 10 000 jetons sur Sonnet 4.6. Le même texte représente environ 13 000 jetons sur Sonnet 5. À un taux par jeton identique, cette requête coûte environ 30 % de plus, même si la grille tarifaire semble inchangée. Modélisez vos charges de travail réelles avec un comptage de jetons avant de supposer une parité de coûts plate. Le détail des prix de Sonnet 5 approfondit ce point avec le calcul introductif par rapport au standard.

Vous pouvez mesurer le changement vous-même avec le point de terminaison de comptage de jetons :

curl https://api.anthropic.com/v1/messages/count_tokens \
  --header "x-api-key: $ANTHROPIC_API_KEY" \
  --header "anthropic-version: 2023-06-01" \
  --header "content-type: application/json" \
  --data '{
    "model": "claude-sonnet-5",
    "messages": [
      {"role": "user", "content": "Summarize the changelog for our billing API v3 release."}
    ]
  }'

Exécutez le même appel avec claude-sonnet-4-6 et comparez les comptes. Cette différence représente l'impact réel sur votre budget.

Ce que coûte la mise à niveau

Par jeton, Sonnet 5 coûte le même prix que Sonnet 4.6 : 3 $ par million de jetons d'entrée et 15 $ par million de jetons de sortie aux tarifs standards. Il y a un tarif de lancement de 2 $ par million d'entrée et 10 $ par million de sortie en vigueur jusqu'au 31 août 2026, après quoi il passera aux tarifs standards de 3 $ / 15 $.

Ainsi, pendant la période de lancement, un texte équivalent est moins cher par jeton que le tarif standard de la version 4.6, ce qui compense en partie l'augmentation d'environ 30 % des jetons due au tokenizer. Après le 31 août, les tarifs par jeton correspondent à nouveau à ceux de la version 4.6, et l'effet du tokenizer signifie qu'une requête équivalente peut coûter plus cher que la même requête sur la version 4.6. Modélisez cela par rapport à votre trafic réel. Pour les tarifs de traitement par lots et de mise en cache des invites, consultez la page des tarifs d'Anthropic plutôt que de supposer une remise fixe.

Si vous évaluez également l'ancienne génération en termes de coûts, les guides prix de Sonnet 4.6 et coût de l'API Claude vous donnent les bases de comparaison.

Devriez-vous faire la mise à niveau ? Un verdict par utilisateur

Le changement d'ID de modèle est trivial. La décision de le faire dépend de ce que vous exécutez.

Mettez à niveau dès maintenant si vous construisez des agents, des outils de codage ou des flux de travail fortement dépendants d'outils. C'est la victoire la plus nette. Les gains sur SWE-bench Pro et OSWorld se situent exactement là où se trouvent les applications agentiques, et les améliorations de sécurité réduisent les comportements indésirables dans les boucles autonomes. Effectuez la revue des trois paramètres, remesurez vos budgets de jetons, et déployez-le.

Mettez à niveau, mais testez avec précaution, si vous exécutez des charges de travail de production à grand volume. Le même prix par jeton est une bonne nouvelle, mais le tokenizer signifie que votre dépense totale en jetons et votre comportement de troncature max_tokens changent tous les deux. Effectuez un passage de comptage de jetons et une suite de régression avant de router le trafic réel. Le prix de lancement jusqu'au 31 août vous donne une fenêtre pour valider à un tarif réduit.

Mettez à niveau délibérément si vous dépendez de temperature, budget_tokens ou du pré-remplissage. Ceux-ci renvoient désormais 400. La migration est simple, déplaçant le déterminisme vers votre prompt système et échangeant les budgets contre l'effort, mais ce n'est pas un travail nul. Corrigez-les avant l'échange, pas après.

Conservez la version actuelle si vous avez spécifiquement besoin du Priority Tier. Il n'est pas disponible sur Sonnet 5. Si votre SLA en dépend, restez sur la version 4.6 pour ces chemins jusqu'à ce que vos exigences changent.

Pour la plupart des équipes, la réponse est de mettre à niveau, et bientôt, car vous obtenez de meilleures performances agentiques au même prix affiché. Traitez-le comme une véritable migration avec une passe de test, et non comme une modification d'un seul caractère que vous déployez un vendredi. Si vous comparez des générations plus largement, le guide de l'API Sonnet 4.6 documente la surface dont vous vous éloignez.

Détectez les régressions avec une suite de requêtes enregistrées dans Apidog

Le moyen le plus sûr de mettre à niveau est de comparer Sonnet 5 à Sonnet 4.6 sur vos propres invites, et non sur un tableau de benchmarks. C'est exactement le type de test avant-après pour lequel une plateforme API est conçue.

Apidog est un outil tout-en-un de développement et de test d'API. Lorsque vous appelez l'API Claude, vous frappez un point de terminaison HTTP avec des en-têtes d'authentification, un corps de requête JSON et une réponse JSON. Apidog vous permet d'enregistrer cette requête une fois et de la réexécuter en tant que collection réutilisable, ce qui transforme une migration de modèle en un test reproductible plutôt qu'une tentative manuelle.

Un flux de travail de migration pratique ressemble à ceci :

1. Enregistrez vos requêtes de l'API Messages de production comme une collection Apidog, une par invite représentative.
2. Stockez votre ANTHROPIC_API_KEY en tant que variable d'environnement afin de ne jamais la coller dans un corps de requête.
3. Configurez deux environnements qui ne diffèrent que par la valeur du model : claude-sonnet-4-6 et claude-sonnet-5.
4. Ajoutez des assertions sur la forme de la réponse et sur les nombres de jetons usage, puis exécutez la collection sur les deux environnements.
5. Comparez les deux exécutions. Les deltas de comptage de jetons vous montreront l'impact réel du tokenizer sur vos invites, et toute assertion échouée est une régression à investiguer avant de livrer.

Vous pouvez également simuler le point de terminaison Claude dans Apidog pour construire et tester votre intégration environnante, y compris le chemin stop_reason: "refusal", sans dépenser de jetons. Si votre application est de type agent et appelle d'autres outils, Apidog est l'endroit où vous testez et simulez également ces API en aval.

Téléchargez Apidog pour créer la suite de comparaison, ou ouvrez Apidog dans le navigateur pour commencer à partir d'une requête. Si vous abandonnez Postman pour cela, le guide Tests d'API sans Postman couvre le flux équivalent.

FAQ

Claude Sonnet 5 est-il un remplacement direct de Sonnet 4.6 ? Principalement. Vous changez l'ID du modèle de claude-sonnet-4-6 à claude-sonnet-5, puis vous examinez trois points : la réflexion adaptative est désormais activée par défaut (ce qui affecte max_tokens), la réflexion étendue budget_tokens renvoie 400, et les paramètres d'échantillonnage non par défaut renvoient 400. Tout le reste est conservé. Consultez le guide de l'API Sonnet 5 pour la configuration complète de la requête.

Sonnet 5 coûte-t-il plus cher que Sonnet 4.6 ? Par jeton, non. Les deux coûtent 3 $ par million de jetons d'entrée et 15 $ par million de jetons de sortie aux tarifs standards. Mais le nouveau tokenizer de Sonnet 5 produit environ 30 % de jetons de plus pour le même texte, donc une requête équivalente peut coûter plus cher même au même taux par jeton. Il existe un tarif de lancement de 2 $ / 10 $ par million jusqu'au 31 août 2026.

Pourquoi ma réponse est-elle tronquée après la mise à niveau ? La réflexion adaptative est activée par défaut sur Sonnet 5, et les jetons de réflexion partagent le même budget max_tokens que votre texte de réponse. Un budget qui suffisait pour votre réponse sur 4.6 peut maintenant la tronquer. Augmentez max_tokens, ou définissez thinking={"type": "disabled"} si vous ne voulez pas de réflexion sur cet appel.

Dois-je modifier mon code pour le nouveau tokenizer ? Non. Les formes des requêtes, des réponses et du streaming sont identiques, donc aucune modification de code n'est nécessaire. Mais vous devriez remesurer tout ce qui est budgétisé en jetons : les nombres de jetons, le dimensionnement de max_tokens et les estimations de coût par requête. Ne réutilisez pas vos nombres de jetons de Sonnet 4.6.

Qu'est-il arrivé à temperature et budget_tokens ? Les deux renvoient désormais une erreur 400 sur Sonnet 5 lorsqu'ils sont définis à des valeurs non par défaut. Supprimez les valeurs non par défaut de temperature, top_p et top_k, et orientez le comportement via votre invite système. Remplacez la réflexion étendue de budget_tokens par la réflexion adaptative avec le paramètre `effort`. Le guide Changements de l'API Fable 5 et Mythos couvre le même modèle sur le niveau supérieur.