Migrer vers la version d'API 2026-10-21

Ce guide répertorie les modifications de code nécessaires pour passer de la version d'API 2023-06-01 à 2026-10-21. Les étapes de mise à niveau indiquent ce qu'il faut faire, dans l'ordre.

Étapes de mise à niveau

1. 1

   Passer à 2026-10-21

   Si vous utilisez un SDK, vos requêtes utilisent la version d'API qui était en vigueur lors de la publication de la version majeure de votre SDK. Les versions indiquées pour votre langage sont les premières à utiliser 2026-10-21 ; effectuez donc la mise à niveau vers celles-ci. Si vous appelez l'API sans SDK, définissez l'en-tête anthropic-version sur 2026-10-21.

   cURLCLIPythonTypeScriptC#GoJavaPHPRuby

   Python

   Mettez à niveau le paquet anthropic vers la version 2.0.0.

   Publiez la mise à niveau en même temps que vos corrections de l'étape suivante.

2. 2

   Mettre à jour votre code pour les changements incompatibles

   Parcourez les changements incompatibles et mettez à jour votre code pour chacun de ceux qui vous concernent. Effectuez également les modifications de code requises par la nouvelle version du SDK ou de la CLI.

3. 3

   Tester avec 2026-10-21

   Testez votre intégration avec 2026-10-21 avant de la publier.

Changements incompatibles

API Messages

Ces changements s'appliquent aux requêtes vers l'API Messages (POST /v1/messages), au comptage de tokens et à chaque requête d'un Message Batch créé avec 2026-10-21.

Les blocs de document dans les messages de l'assistant renvoient une erreur

Vous concerne si vous envoyez des blocs document directement dans des messages assistant.

Dans 2026-10-21, une requête qui place un bloc document directement dans un message assistant renvoie une erreur 400. Envoyez plutôt les documents dans des messages user. Un document imbriqué dans un autre bloc, comme un résultat de l'outil de récupération web renvoyé par Claude, est toujours accepté.

Les citations dans les messages de l'utilisateur renvoient une erreur

Vous concerne si vous envoyez des citations sur des blocs text dans des messages user, y compris à l'intérieur de blocs search_result.

Dans 2026-10-21, une requête qui envoie un bloc text avec un tableau citations non vide dans un message user renvoie une erreur 400. Supprimez citations de ces blocs. Les citations sur les blocs text dans les messages assistant, comme les réponses précédentes de Claude que vous renvoyez, sont toujours acceptées, tout comme le paramètre "citations": {"enabled": true} sur les documents et les résultats de recherche.

Les paramètres d'échantillonnage sont supprimés

Vous concerne si vous envoyez temperature, top_p ou top_k dans des requêtes Messages ou des requêtes Message Batch.

Dans 2026-10-21, une requête qui envoie temperature, top_p ou top_k renvoie une erreur 400, même avec la valeur par défaut du paramètre.

Supprimez ces trois paramètres de vos requêtes.

Depuis les dernières versions majeures, le SDK et la CLI ne comportent plus ces trois paramètres.

Sans ces paramètres, une requête échantillonne avec leurs valeurs par défaut, y compris une temperature de 1.0, comme une requête 2023-06-01 qui les omet. Les modèles qui n'acceptent déjà que les valeurs par défaut, comme les modèles Claude 4.7 et ultérieurs, échantillonnent comme auparavant. Sur les modèles qui acceptent d'autres valeurs, comme Claude Sonnet 4.6, une requête qui abaissait temperature pour obtenir une sortie plus cohérente perd cet effet. Aucun autre paramètre ne le remplace. Si une requête dépend d'une valeur autre que celle par défaut, cessez d'envoyer le paramètre ou conservez cette requête sur 2023-06-01.

Admin API et Claude Enterprise Analytics API

Vous concerne si votre code lit les champs de réponse de l'Admin API ou de la Claude Enterprise Analytics API figurant dans les tableaux suivants.

Dans 2026-10-21, les réponses de l'Admin API et de la Claude Enterprise Analytics API n'incluent plus les anciens noms des champs renommés. Utilisez plutôt les nouveaux noms.

Admin API :

Claude Enterprise Analytics API :

Le paramètre de requête group_type sur les points de terminaison de liste des limites de débit et le filtre workspace_id sur le point de terminaison de liste des clés API restent inchangés.

workspace_id sur les clés API

Vous concerne si votre code lit workspace_id sur les clés API.

Dans 2023-06-01, le workspace_id d'une clé API est l'ID de l'espace de travail auquel la clé est liée, ou null pour une clé liée au Default Workspace et pour une clé qui n'est pas liée à un seul espace de travail (une clé pour tous les espaces de travail).

Dans 2026-10-21, workspace_id est supprimé. Lisez plutôt scope : pour une clé liée à un espace de travail, y compris le Default Workspace, scope.workspace_id est l'ID réel de cet espace de travail, et une clé pour tous les espaces de travail a un scope de {"type": "organization"}, sans workspace_id.

Si votre code traitait un workspace_id null comme le Default Workspace, comparez plutôt scope.workspace_id avec l'ID de votre Default Workspace. Pour trouver cet ID, appelez List Workspaces avec include_default=true et prenez l'espace de travail nommé "Default".

Modifications du SDK et de la CLI

Les versions antérieures du SDK et de la CLI envoyaient anthropic-version: 2023-06-01 avec chaque requête. Les versions indiquées sous Passer à 2026-10-21 envoient 2026-10-21. Les modifications décrites dans Changements incompatibles s'y appliquent également : les paramètres supprimés et les anciens noms de champs ont aussi disparu des types du SDK ainsi que des options et de la sortie de la CLI.

Version d'API sur Amazon Bedrock et Google Cloud

Le client du SDK pour Google Cloud's Agent Platform indique la version dans le corps de la requête plutôt que dans un en-tête. Il envoie anthropic_version: 2026-10-21, là où les versions antérieures envoyaient vertex-2023-10-16, et aucun en-tête anthropic-version.

Le client Amazon Bedrock fait de même. Il envoie anthropic_version: 2026-10-21, là où les versions antérieures envoyaient bedrock-2023-05-31, et aucun en-tête anthropic-version. Les modèles antérieurs à Claude Opus 4.7 ne prennent pas encore en charge la version d'API 2026-10-21 sur Bedrock, et une requête qui l'indique peut recevoir une erreur 400. Si vous utilisez l'un d'eux, conservez pour l'instant la version antérieure du SDK, ou effectuez la mise à niveau et envoyez vous-même bedrock-2023-05-31.

MessageParam est une union avec un type par rôle

Dans les versions antérieures, MessageParam était un type unique pour tous les rôles. Chaque rôle a désormais son propre type : UserMessageParam, AssistantMessageParam et SystemMessageParam. BetaMessageParam est divisé de la même manière, en BetaUserMessageParam, BetaAssistantMessageParam et BetaSystemMessageParam. Les requêtes envoyées par le SDK ont les mêmes champs et valeurs qu'auparavant.

# Avant
message = MessageParam(role="user", content="Hello")

# Après
message: MessageParam = {"role": "user", "content": "Hello"}

# Avant
def to_message(role: Literal["user", "assistant"], text: str) -> MessageParam:
    return {"role": role, "content": text}


# Après
def to_message(role: Literal["user", "assistant"], text: str) -> MessageParam:
    if role == "user":
        return {"role": "user", "content": text}
    return {"role": "assistant", "content": text}

Les enums à une seule valeur sont des constantes

Ce changement concerne les SDK C#, Go, Java, PHP et Ruby ainsi qu'une option de la CLI. Dans les versions précédentes, un champ obligatoire qui ne peut contenir qu'une seule valeur avait son propre type « enum » (énumération) avec un seul membre. Ces champs sont désormais des constantes, et les types enum ont disparu. Le JSON que le SDK envoie et lit reste le même.

La compaction côté client est supprimée du tool runner

Ce changement concerne les SDK TypeScript et Ruby. La « client-side compaction » (compaction côté client) dans le « tool runner » (exécuteur d'outils) a été supprimée au profit de la compaction côté serveur, qui résume la conversation au sein de l'API plutôt qu'au moyen d'une requête supplémentaire du client.

// Avant
const runner = client.beta.messages.toolRunner({
  // ...
  compactionControl: { enabled: true, contextTokenThreshold: 100_000 }
});

// Après
const runner = client.beta.messages.toolRunner({
  // ...
  betas: ["compact-2026-01-12"],
  context_management: {
    edits: [{ type: "compact_20260112", trigger: { type: "input_tokens", value: 100_000 } }]
  }
});

Le seuil de déclenchement doit être d'au moins 50 000 tokens. Consultez la compaction pour les autres options (pause_after_compaction, instructions personnalisées).

Text Completions est supprimé

L'ancienne API Text Completions est supprimée des SDK TypeScript, Go, Java et Ruby ainsi que de la CLI. Les modèles et fonctionnalités plus récents ne la prennent pas en charge. Utilisez plutôt l'API Messages.

# Avant
ant completions create \
  --model "$MODEL" \
  --max-tokens-to-sample 1024 \
  --prompt $'\n\nHuman: Hello, Claude\n\nAssistant:'

# Après
ant messages create \
  --model "$MODEL" \
  --max-tokens 1024 \
  --message '{role: user, content: "Hello, Claude"}'

betas est supprimé des méthodes Models non bêta

Les méthodes Models non bêta ne prennent plus betas, et les commandes ant models ne prennent plus --beta. Pour envoyer des en-têtes bêta, appelez les mêmes méthodes sur client.beta.models, ou ant beta:models dans la CLI. Dans le SDK, ces méthodes renvoient BetaModelInfo là où les méthodes non bêta renvoient ModelInfo.

# Avant
page = client.models.list(betas=[beta])

# Après
page = client.beta.models.list(betas=[beta])

Les clés API sont envoyées sous la forme Authorization: Bearer

Le SDK et la CLI envoient votre clé API sous la forme Authorization: Bearer <key> au lieu de l'en-tête X-Api-Key. Modifiez donc tout proxy ou passerelle qui lit ou définit X-Api-Key pour qu'il utilise Authorization, ou envoyez vous-même la clé dans X-Api-Key. L'API Claude accepte une clé dans l'un ou l'autre en-tête, donc un programme qui communique directement avec l'API n'a besoin d'aucune modification.

# Before
X-Api-Key: <key>

# After
Authorization: Bearer <key>

Si un proxy ou une passerelle lit X-Api-Key

import httpx2
from anthropic import Anthropic, DefaultHttpxClient


def send_x_api_key(request: httpx2.Request) -> httpx2.Request:
    if request.headers.get("Authorization") == f"Bearer {api_key}":
        del request.headers["Authorization"]
        request.headers["X-Api-Key"] = api_key
    return request


client = Anthropic(api_key=api_key, http_client=DefaultHttpxClient(auth=send_x_api_key))

Si vous définissiez ou supprimiez X-Api-Key sur une requête

Ce changement concerne les SDK Python, TypeScript, Go, PHP et Ruby.

Si vous supprimiez X-Api-Key pour qu'une requête n'envoie qu'un jeton d'authentification, supprimez ce code au lieu de le modifier, car supprimer Authorization supprimerait le jeton. Un client détient un seul identifiant, assurez-vous donc qu'il s'agit du jeton : si aucun n'est passé dans le code et que ANTHROPIC_API_KEY et ANTHROPIC_AUTH_TOKEN sont tous deux définis, le client utilise la clé.

Un client détient un seul identifiant

Une clé API et un jeton d'authentification partagent désormais un en-tête, de sorte qu'un client SDK détient un seul identifiant. Si aucun n'est transmis dans le code, il suit l'ordre de priorité des identifiants.

client = Anthropic(api_key=key, auth_token=token)

# Avant : envoyait `X-Api-Key: <key>` et `Authorization: Bearer <token>`
# Après : lève `ValueError`

Modifications dans un seul SDK ou dans la CLI

Chacune de ces modifications concerne un seul SDK ou la CLI.

# Avant
ant --api-key "$KEY" models list

# Après, depuis l'environnement
export ANTHROPIC_API_KEY="$KEY"
ant models list

# Après, depuis un gestionnaire de secrets
op read op://vault/anthropic/api-key | ant --api-key-stdin models list

La licence est Apache 2.0

À partir de ces versions, le SDK et la CLI sont distribués sous la licence Apache, version 2.0. Les versions antérieures restent sous licence MIT. Aucune modification de code n'est nécessaire. Si vous suivez les licences de vos dépendances, mettez à jour leurs entrées.

• TypeScript : les paquets de plateforme (@anthropic-ai/bedrock-sdk, @anthropic-ai/vertex-sdk, @anthropic-ai/foundry-sdk, @anthropic-ai/aws-sdk et @anthropic-ai/google-cloud-sdk) changent de licence dans leurs propres versions 1.0.0.
• C# : les autres paquets (Anthropic.Bedrock, Anthropic.Vertex, Anthropic.Foundry, Anthropic.Aws, Anthropic.GoogleCloud et Anthropic.Mcp) changent de licence dans leurs propres versions 1.0.0.
• Java : la modification couvre tous les artefacts com.anthropic.