API Anthropic 2026-10-21 : temperature renvoie 400, même à 1.0

Une requête Claude envoyée avec la version d’API 2026-10-21 renvoie HTTP 400 si elle définit temperature, top_p ou top_k, même avec la valeur par défaut : temperature: 1.0 échoue avec le message « temperature: Extra inputs are not permitted ». Ces paramètres d’échantillonnage contrôlent la part d’aléatoire dans le choix de chaque token suivant. La version d’API se définit dans l’en-tête de requête anthropic-version. Elle détermine comment l’API Messages valide la requête et y répond ; l’ancienne valeur est 2023-06-01. Les versions majeures des SDK publiées par Anthropic le 21 octobre (Python 2.0.0, TypeScript 1.0.0 et cinq autres) l’envoient par défaut. Ces SDK n’exposent plus les paramètres d’échantillonnage. L’erreur 400 touche donc le code qui construit lui-même le corps de la requête : clients HTTP directs et champs ajoutés au corps. Nous avons testé huit formes de requêtes avec les deux versions sur Claude Sonnet 4.6 et Claude Sonnet 5.5, comparé deux versions du SDK Python et répété les tests via Synthorai.

TL;DR

• Avec 2026-10-21, temperature, top_p et top_k renvoient 400 sur Claude Sonnet 4.6 et Sonnet 5.5, y compris avec temperature: 1.0.
• 2026-10-21 rejette aussi les blocs document dans les messages assistant et les citations dans les blocs de texte utilisateur.
• Le SDK Python 2.x d’Anthropic envoie la clé dans Authorization: Bearer ; si une requête contient les deux en-têtes, l’API utilise x-api-key.
• Via Synthorai, les 32 requêtes ont renvoyé 200 avec les deux SDK, y compris les 12 que l’API Anthropic rejette sous 2026-10-21.

Quelles requêtes renvoient 400 avec la version d’API 2026-10-21 ?

Cinq changements provoquent ces erreurs 400 : les trois paramètres d’échantillonnage, un bloc document placé directement dans un message assistant et des citations (références reliant un bloc de texte à un passage d’un document) dans un bloc de texte d’un message utilisateur. Le tableau les couvre avec six cas rejetés et deux autres toujours acceptés. Nous avons envoyé chaque cas une fois par modèle et par version, directement à l’API Anthropic. Le code 200 signifie que la requête a été acceptée ; le code 400 signifie qu’elle a été rejetée avec invalid_request_error.

Les messages d’erreur avec la nouvelle version :

Claude Sonnet 5.5 rejetait déjà les valeurs d’échantillonnage autres que celles par défaut sous 2023-06-01, avec un autre message (« `temperature` is deprecated for this model. »), mais acceptait temperature: 1.0. Sous 2026-10-21, le paramètre lui-même a disparu : même sa valeur par défaut échoue. Claude Sonnet 4.6 acceptait tous les cas avec l’ancienne version. Le guide de migration d’Anthropic indique que les mêmes règles s’appliquent au comptage des tokens et à chaque requête d’un Message Batch (l’API Batch exécute de nombreuses requêtes de façon asynchrone à tarif réduit). Il ne donne aucune date de fin pour 2023-06-01.

Comment corriger chaque erreur 400 ?

Supprimez les trois paramètres d’échantillonnage, déplacez les documents dans les messages utilisateur et retirez les citations du texte envoyé en tant qu’utilisateur. Sans paramètres d’échantillonnage, la requête utilise les valeurs par défaut, dont 1.0 pour temperature, comme le faisait déjà une requête 2023-06-01 sans ces paramètres. Les citations dans les réponses précédentes de Claude et "citations": {"enabled": true} sur les documents restent acceptées.

Avec le SDK Python, cette requête fonctionne sous les deux versions :

import anthropic

client = anthropic.Anthropic()  # 2.x sends anthropic-version: 2026-10-21

message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    # no temperature, top_p or top_k: the parameters no longer exist in 2.x
    messages=[{"role": "user", "content": "Summarize this memo in one sentence."}],
)
print(message.content[0].text)

Si une requête a besoin d’une temperature autre que la valeur par défaut sur un modèle qui l’accepte encore, comme Claude Sonnet 4.6, elle doit rester sur l’ancienne version. En HTTP direct, il faut définir l’en-tête soi-même :

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 256, "temperature": 0.2,
       "messages": [{"role": "user", "content": "Pick a number from 1 to 100."}]}'

Qu’est-ce qui change dans les SDK Anthropic ?

Les versions majeures des SDK qui envoient 2026-10-21 sont Python 2.0.0, TypeScript 1.0.0, Go 2.0.0, Java 3.0.0, C# 13.0.0, PHP 1.0.0 et Ruby 2.0.0. Outre la version d’API, elles modifient la façon d’envoyer la clé et le nombre d’identifiants qu’un client peut détenir. Elles passent aussi de la licence MIT à Apache 2.0. Nous avons installé les versions 1.17.0 (la dernière 1.x) et 2.3.0 du SDK Python, puis les avons fait pointer vers un serveur d’écho local qui enregistre les en-têtes et le corps de chaque requête reçue :

L’argument temperature a été retiré des méthodes de messages du SDK Python en 1.0.0. Les utilisateurs Python ne rencontrent donc l’erreur 400 côté serveur qu’en passant par extra_body (l’option du SDK qui ajoute des champs bruts au corps de la requête), ou par des clients HTTP et des bibliothèques qui construisent eux-mêmes ce corps. L’en-tête Bearer fonctionne avec les deux versions d’API : une requête contenant uniquement Authorization: Bearer <key> a aussi renvoyé 200 sous 2023-06-01. Les changements d’authentification et de version peuvent donc être déployés séparément.

Quelle clé est utilisée si les deux en-têtes sont envoyés ?

L’API Anthropic utilise x-api-key quand une requête contient les deux en-têtes. Nous avons envoyé cinq combinaisons d’en-têtes avec les deux versions :

Un proxy ou une passerelle placés devant Claude peuvent ne pas retenir la même clé que l’API. Avec le SDK 2.x, le code qui ajoute une seconde clé via extra_headers={"X-Api-Key": other_key} envoie désormais deux clés : celle du client dans Authorization et l’autre dans x-api-key. L’API Anthropic authentifie la requête avec other_key, tandis qu’un proxy qui ne lit que Authorization l’attribue à la clé du client. Les quotas, les journaux et les plafonds de dépenses par clé risquent alors d’être imputés à la mauvaise clé. Côté client, le guide recommande d’envoyer la seconde clé dans Authorization: Bearer <other_key>. Côté proxy, lisez les deux en-têtes et appliquez l’ordre de priorité de l’API (x-api-key d’abord), ou rejetez les requêtes dont les deux en-têtes contiennent des clés différentes.

Que perd-on en supprimant temperature ?

Supprimer temperature a moins d’impact que ne pourrait le penser une équipe qui s’appuyait sur temperature: 0. Le guide de migration indique que Claude 4.7 et les modèles suivants n’acceptent déjà que les valeurs par défaut : rien ne change pour eux. Sur un modèle qui accepte encore d’autres valeurs, comme Claude Sonnet 4.6, une requête qui abaissait temperature pour stabiliser les réponses perd cet effet, et aucun autre réglage ne le remplace. Nous avons mesuré cet effet : 20 requêtes par réglage sur Sonnet 4.6 sous 2023-06-01, chacune avec un identifiant de requête aléatoire ajouté à la fin pour qu’aucune ne soit identique.

Sur ces réponses courtes, les sorties de Sonnet 4.6 étaient à peu près aussi concentrées à la température par défaut qu’à 0. Supprimer temperature: 0 changeait donc peu de choses. temperature: 0 ne garantissait pas non plus le déterminisme : le modèle a renvoyé deux nombres différents en 20 essais. Le texte du prompt a davantage influencé les réponses que le réglage : sans l’identifiant de requête ajouté à la fin, 42 était la réponse la plus fréquente (17 sur 20 avec temperature: 0) ; avec cet identifiant, c’était 47. Si vous avez besoin de réponses reproductibles, comparez-les dans le code ou mettez-les en cache ; le paramètre d’échantillonnage ne le garantissait pas auparavant.

Comment Synthorai gère-t-il la version d’API 2026-10-21 ?

Synthorai accepte les requêtes des deux versions d’API et des deux SDK. Passer au SDK 2.x ou envoyer anthropic-version: 2026-10-21 ne casse donc pas une requête qui fonctionnait auparavant. Nous avons repris la matrice de 16 cas pour les deux modèles via Synthorai, avec les deux valeurs d’anthropic-version : les 32 requêtes ont renvoyé 200, y compris les 12 que l’API Anthropic rejette sous 2026-10-21. Les SDK Python 1.17.0 (qui envoie x-api-key) et 2.3.0 (qui envoie Authorization: Bearer) ont tous deux fonctionné avec base_url="https://synthorai.io" et la même clé, tout comme temperature envoyé via extra_body.

Synthorai fait ce choix pour quatre raisons :

• Un modèle, plusieurs hébergeurs. Un modèle Claude peut être servi par l’API Anthropic, Amazon Bedrock ou Google Cloud Vertex AI, chacun utilisant sa propre chaîne de version. Synthorai envoie à chaque hébergeur la version qu’il attend. L’en-tête anthropic-version du client ne détermine donc pas la validation de la requête.
• Des clients de versions différentes pendant la migration. Les équipes mettent à jour un service à la fois. Pendant plusieurs semaines, un même compte envoie donc 2023-06-01 depuis le SDK 1.x et 2026-10-21 depuis le SDK 2.x. Accepter les deux permet à chaque service de migrer à son rythme, et la même clé fonctionne avec l’en-tête d’authentification des deux SDK.
• Un changement de modèle sans changer le code. Le code qui définit temperature: 0.2 pour Claude Sonnet 4.6 continue de fonctionner lorsque le nom du modèle devient Claude Sonnet 5.5, qui n’accepte pas ce paramètre, au lieu d’échouer au moment du changement.
• Pas d’échec pour une valeur par défaut. temperature: 1.0 est de toute façon la valeur utilisée par le modèle. La rejeter ferait échouer la requête sans modifier la sortie.

En contrepartie, un code 200 ne signifie pas que tous les paramètres ont été appliqués. Sonnet 5.5 n’accepte que les valeurs d’échantillonnage par défaut. Lui envoyer temperature: 0.2 via Synthorai réussit, mais ne réduit pas la part d’aléatoire. Si vos résultats dépendent d’une valeur d’échantillonnage, comparez les sorties avec et sans cette valeur sur vos propres prompts ; la mesure ci-dessus a montré un effet limité sur les réponses courtes.

Que vérifier avant la mise à jour ?

FAQ

Pourquoi ma requête Claude échoue-t-elle avec « temperature: Extra inputs are not permitted » ? La requête a été envoyée avec anthropic-version: 2026-10-21, qui ne contient plus le paramètre temperature. Toute valeur renvoie donc 400, y compris 1.0. Les nouvelles versions majeures des SDK envoient cette version par défaut. Supprimez le paramètre ou fixez la version à 2023-06-01 pour les requêtes qui ont besoin d’une autre valeur sur un modèle qui l’accepte encore.

La version anthropic-version 2023-06-01 va-t-elle être retirée ? Anthropic n’a annoncé aucune date de fin pour 2023-06-01 : ni le guide de migration ni les notes de version de l’API du 21 octobre n’en donnent. Les requêtes qui définissent explicitement cet en-tête conservent l’ancien comportement. Une requête précise peut ainsi continuer à utiliser temperature sur Claude Sonnet 4.6.

L’API Anthropic accepte-t-elle toujours l’en-tête x-api-key ? L’API Anthropic accepte x-api-key et Authorization: Bearer avec les deux versions ; seuls les SDK ont changé l’en-tête qu’ils envoient. Quand les deux en-têtes sont présents, l’API utilise x-api-key.

À lire aussi

• Coût de Claude Sonnet 5.5 : le coût du modèle par rapport à Sonnet 5
• Réglages du raisonnement des LLM : les paramètres de raisonnement acceptés par les modèles Claude récents
• Faille OpenCode : protéger les clés API : limiter les possibilités d’utilisation d’une clé divulguée
• Limites de débit des API LLM : comment sont comptabilisées les limites par clé

← Retour au blog