AIREITERAnthropic Python SDK v1.0 est arrivé sur PyPI le 20 août 2026. Dans la plupart des projets, les appels existants continuent de fonctionner sans modification. Le vrai piège est ailleurs : la couche HTTP passe de httpx à httpx2. Résultat, les outils de tracing, les agents APM et les mocks de test qui patchent httpx peuvent continuer à tourner tout en n’enregistrant plus aucune requête du SDK. Des tests au vert après la mise à niveau ne prouvent donc pas grand-chose.
Trois versions en deux jours avant le passage à la 1.0
L’historique PyPI d’anthropic résume bien la séquence : 0.123.0, 0.124.0 et 0.125.0 sont sorties le 19 août 2026, puis la version 1.0.0 a suivi le 20 août via une publication standard Trusted Publishing.
Voici les changements annoncés dans les notes de version officielles :
- La couche HTTP passe de
httpxàhttpx2, un fork maintenu et compatible au niveau de l’API. - Python 3.10 ou une version ultérieure est désormais requis ; les classifiers couvrent les versions 3.10 à 3.14.
- Les éléments dépréciés depuis longtemps disparaissent : l’ancienne API Text Completions, les paramètres
temperature,top_pettop_kdes méthodes Messages, ainsi quecompaction_controlcôté client dans le tool runner. AnthropicBedrocklève désormais une erreur lorsqu’aucune région AWS n’est configurée, au lieu de basculer silencieusement surus-east-1.
Le tag GitHub v1.0.0 parle d’une « mise à niveau vers httpx2 accompagnée de quelques changements incompatibles mineurs ». Un détail des notes de version mérite toutefois l’attention : l’avertissement bêta a disparu des helpers parse, stream et tool_runner. Avec une version 1.0 et plus de réserve sur leur statut bêta, Anthropic semble désormais considérer ces interfaces comme stables.
Le passage de httpx à httpx2, concrètement
Si vous utilisez le client de manière standard, vous ne verrez aucune différence. Dès que vous intervenez sur la couche HTTP, en revanche, la migration devient incontournable.
Tout dépend de ce que vous transmettez au client. Les valeurs numériques restent compatibles : Anthropic(timeout=30.0) se comporte exactement comme avant. Les objets, eux, changent la donne : passer un httpx.Client classique via http_client= déclenche désormais un TypeError dès la construction du client, et non lors de la première requête. Les clients, timeouts et transports personnalisés doivent être créés avec httpx2. De même, les objets httpx.Timeout utilisés pour les timeouts doivent devenir des objets anthropic.Timeout — ou httpx2.Timeout.
# 0.x
client = Anthropic(http_client=httpx.Client(proxy="http://proxy:8080"))
# 1.0
client = Anthropic(http_client=DefaultHttpxClient(proxy="http://proxy:8080"))DefaultHttpxClient et DefaultAsyncHttpxClient gardent leur nom et leur comportement. Ils conservent les valeurs recommandées par le SDK pour les timeouts, le pooling et les redirections, mais s’appuient désormais sur httpx2. L’annonce de @cjav_dev, ingénieur platform devx chez Anthropic, renvoie d’ailleurs vers le document à consulter en premier : le MIGRATION.md officiel, qui détaille chaque changement avec des exemples avant/après.
Ce changement n’est pas inédit. Le guide de migration httpx2 du SDK Python d’OpenAI avait déjà suivi exactement cette voie : même fork, même logique autour du helper DefaultHttpx2Client et mêmes avertissements de compatibilité avec respx. Les équipes qui ont déjà migré openai pourront donc reprendre leur méthode presque telle quelle.
La liste complète des suppressions de v1.0
| Supprimé dans v1.0 | À utiliser à la place |
|---|---|
client.completions.create() (Text Completions) | client.messages.create() |
Constantes HUMAN_PROMPT / AI_PROMPT | Blocs de contenu au format Messages |
temperature, top_p, top_k dans les signatures de méthode | extra_body={"temperature": ...} pour les anciens modèles qui les acceptent encore |
messages.parse(stream=True) | messages.stream(...) |
tool_runner(compaction_control=...) | Configuration de la compaction côté serveur |
Aliases anthropic.Transport, anthropic.ProxiesTypes | Types de transport httpx2 |
body= dans les méthodes de requête bas niveau | content= |
Dictionnaire de schéma output_format dans les API bêta | output_config={"format": ...} (les helpers de sortie structurée acceptent toujours output_format=MyModel) |
Vérifications isinstance(stream, anthropic.Stream) | Vérifier le type concret MessageStream |
Deux précisions à garder en tête. Pydantic v1 et v2 restent pris en charge : vos classes de modèles ne sont donc pas concernées. Par ailleurs, la fusion des en-têtes ne tient désormais plus compte de la casse. Le comportement change si vous définissez deux fois le même en-tête avec une casse différente — un cas marginal, certes, mais qui ne génère aucune erreur lorsqu’il se présente.
Les changements asynchrones qui concernent surtout les réponses brutes
Les évolutions côté async sont limitées, mais peuvent faire mal si vous utilisez .with_raw_response. Avec le client asynchrone, parse(), read(), text() et json() doivent désormais être précédées de await. Avec le client synchrone, .text et .content ne sont plus des propriétés, mais des méthodes. Rien ne casse au moment de l’import : le cas synchrone échoue clairement avec une erreur d’attribut, tandis que le cas asynchrone peut passer inaperçu si vous récupérez une coroutine sans jamais l’exécuter.
Autre conséquence : les objets de requête et de réponse présents dans les exceptions et les résultats bruts sont maintenant des types httpx2. L’accès à leurs attributs reste globalement identique, mais les tests isinstance(x, httpx.Response) et les annotations de type doivent être actualisés. C’est précisément le genre de régression que pyright et mypy peuvent repérer.
Le problème de migration que vos dashboards ne verront pas
Le changelog résume ce point en une phrase, mais votre monitoring risque de le payer cher. D’après le guide de migration d’Anthropic, les outils qui observent ou simulent le trafic HTTP en patchant httpx — OpenTelemetry, Sentry, respx, pytest-httpx, vcrpy — peuvent continuer à fonctionner après la mise à niveau tout en ignorant silencieusement les requêtes du SDK. Ils s’importent toujours, s’exécutent toujours et continuent de produire des rapports ; ils ne voient simplement plus le trafic qui ne passe plus par la bibliothèque patchée. Les tests reposant sur ces mocks peuvent alors réussir pour de mauvaises raisons s’ils ne vérifient pas qu’une interception a effectivement eu lieu : aucune requête n’atteint le mock, donc rien n’échoue.
La solution consiste à appeler httpx2.alias_httpx() le plus tôt possible au démarrage de l’application ou des tests — la documentation du SDK Python précise qu’il faut le faire avant tout import de httpx. Cette fonction expose httpx2 sous le nom httpx, ce qui permet aux outils de patching de continuer à fonctionner. Le guide de migration déconseille toutefois de l’appeler depuis le code d’une bibliothèque : faites-le uniquement au point d’entrée de l’application.
« Un démarrage sans erreur ne prouve pas que vos appels IA sont toujours tracés ou mockés. » — @MarMarLabs, dans un post publié le lendemain de la sortie
Le post mérite une lecture complète. Il recommande de faire de cette régression invisible le premier test de migration : mettre à niveau le projet, puis vérifier volontairement qu’un appel tracé et un appel mocké sont bien enregistrés. Le même fil évoque deux autres risques silencieux : les transports personnalisés qui nécessitent une migration manuelle vers httpx2, et le plancher Python 3.10 qui peut faire échouer les anciennes images CI dès l’installation.
Le code qui continue de fonctionner sans modification
Pour beaucoup de projets, la réponse honnête est simple : rien à faire. La migration HTTP ne vous concerne pas si vous ne construisez jamais de clients, de transports ou d’objets de timeout personnalisés. Les éléments suivants restent inchangés :
- Les appels
client.messages.create(...)avec des paramètres classiques : même requête, mêmes modèles de réponse. - Les valeurs numériques de timeout et les valeurs par défaut du SDK : 2 tentatives avec backoff exponentiel pour les erreurs de connexion, 408, 409, 429 et 5xx ; un timeout par défaut de 10 minutes.
- Le routage via
base_url. Si vous dirigez le SDK vers une passerelle ou un relais compatible avec l’API, comme l’endpoint Claude API d’AIReiter, v1.0 ne change rien à cette couche : c’est le client qui a changé, pas l’URL. - Les modèles Pydantic v1 et v2, les helpers de streaming SSE et les interfaces d’envoi de fichiers.
Le seul vrai prérequis bloquant est Python 3.10+. Tout le reste de cette liste « sûre » suppose que cette condition est déjà remplie.
Un ordre de migration qui tient face à la revue de code
- Commencez par verrouiller délibérément la version : si vous n’êtes pas prêt,
anthropic>=0.125,<1permet de rester en place le temps de planifier le chantier. - Recherchez
import httpxethttpx.dans tout le dépôt : chaque occurrence dans du code proche du SDK doit être examinée. - Lancez
/claude-api upgrade pythondans Claude Code — c’est la commande recommandée dans l’annonce de sortie de @cjav_dev — afin d’obtenir un diff généré des changements à effectuer dans votre projet. - Reconstruisez les clients, transports et timeouts personnalisés avec
httpx2ou les helpersDefaultHttpxClient. - Ajoutez
httpx2.alias_httpx()au point d’entrée de l’application si un composant patchehttpx. - Lancez pyright ou mypy : les changements de types liés à httpx2 apparaîtront sous forme d’erreurs d’annotation ou de
isinstance. - Dans la CI, vérifiez qu’une requête tracée et une requête mockée sont bien enregistrées dans chaque suite de tests. Des logs de démarrage au vert ne constituent pas une preuve.
FAQ sur Anthropic Python SDK v1.0
Anthropic Python SDK v1 existe-t-il vraiment, ou est-on encore en 0.x ?
Il existe bien. anthropic 1.0.0 a été publié sur PyPI le 20 août 2026 et porte le tag v1.0.0 sur GitHub, après la version 0.125.0 sortie la veille. La page du projet sur PyPI redirige désormais les utilisateurs de la série 0.x vers le guide de migration v1.
Comment transmettre temperature, top_p ou top_k après v1.0 ?
Ces paramètres ont disparu des signatures de méthode. Pour les anciens modèles qui les acceptent encore côté serveur, utilisez extra_body={"temperature": 0.7}. Attention toutefois : les modèles actuels renvoient une erreur 400 pour les valeurs d’échantillonnage non par défaut. Ce changement concerne le modèle lui-même, pas le SDK.
Les tests avec respx, pytest-httpx ou vcrpy fonctionnent-ils toujours ?
Pas avec le client par défaut du SDK, et ils ne signaleront pas d’erreur : ils ne correspondront simplement à rien. Appelez httpx2.alias_httpx() avant tout import de httpx au démarrage des tests, ou déplacez vos mocks vers httpx2.MockTransport. Une version de respx qui ne patche que l’ancien httpx ne peut pas intercepter le trafic du SDK.
Que fait /claude-api upgrade python ?
Il s’agit d’une commande Claude Code, recommandée dans l’annonce de @cjav_dev, ingénieur devx chez Anthropic. Elle analyse un projet utilisant anthropic 0.x et génère un diff de migration — imports, objets de timeout, appels de réponses brutes — pour vous permettre de relire les changements plutôt que de les découvrir au fil des tracebacks.
Rester en 0.125 ou passer à 1.0
Il n’existe pas de réponse universelle. Rester sous 1.0 permet de conserver tels quels les mocks, traceurs et transports personnalisés, mais vous maintient sur un SDK antérieur à la stabilité dont la politique de versionnement autorise les changements incompatibles entre versions mineures. Les interfaces dépréciées dont vous dépendez — completions et paramètres d’échantillonnage — sont en outre désormais officiellement condamnées. Passer à 1.0 offre une API stable et débarrassée de ses avertissements bêta, au prix d’un audit complet de la couche HTTP dès maintenant. Le choix dépend donc de la quantité de code HTTP que vous gérez : un service qui ne fait qu’un appel classique via Anthropic() migrera sans difficulté, tandis qu’une plateforme dotée de transports personnalisés et de suites respx doit impérativement vérifier les échecs silencieux avant la mise en production.
À lire également : le passage de la Skills API hors bêta la même semaine, ainsi que la pérennisation du tarif de Sonnet 5 le 10 août — deux annonces issues de la même période de sorties Claude Platform.