AIREITERDie meisten Anwendungen werden den Sprung auf Anthropic Python SDK v1.0 zunächst kaum bemerken. Genau das ist das Risiko: Mit dem Release auf PyPI am 20. August 2026 wechselte die HTTP-Schicht von httpx zu httpx2. Tracing, APM-Agenten und Test-Mocks, die httpx patchen, laufen dadurch womöglich weiter – erfassen aber unbemerkt keine SDK-Anfragen mehr. Bestandene Tests nach dem Upgrade sind also kein ausreichender Beleg dafür, dass alles funktioniert.
Auf drei 0.x-Releases folgt v1.0
Die Release-Historie von anthropic auf PyPI fasst die Entwicklung in fünf Zeilen zusammen: 0.123.0, 0.124.0 und 0.125.0 erschienen alle am 19. August 2026. Einen Tag später folgte 1.0.0 als reguläres Trusted-Publishing-Release.
Laut den offiziellen Release Notes ändert sich Folgendes:
- Die HTTP-Schicht wechselt von
httpxzuhttpx2, einem gepflegten und API-kompatiblen Fork. - Erforderlich ist jetzt Python 3.10 oder neuer; die Classifier führen Python 3.10 bis 3.14 auf.
- Lange veraltete Teile der API entfallen: die frühere Text-Completions-API, die Parameter
temperature,top_pundtop_kin Messages-Methoden sowiecompaction_controlfür die clientseitige Tool-Runner-Kompaktierung. AnthropicBedrockwirft nun einen Fehler, wenn keine AWS-Region konfiguriert ist, statt stillschweigendus-east-1zu verwenden.
Der GitHub-Tag v1.0.0 bezeichnet das Update als „upgrade to httpx2 and some minor breaking changes“. In den Release Notes leicht zu übersehen: Die Beta-Warnung bei den Helfern parse, stream und tool_runner ist verschwunden. Die Versionsnummer 1.0 ohne Beta-Einschränkung deutet darauf hin, dass Anthropic diese API-Oberfläche nun als stabil betrachtet.
Was der Wechsel von httpx zu httpx2 konkret bedeutet
Wer Clients schlicht instanziiert, merkt davon nichts. Wer die HTTP-Schicht selbst anfasst, muss dagegen aktiv werden.
Entscheidend ist, was an den Client übergeben wird. Numerische Werte funktionieren weiter: Anthropic(timeout=30.0) verhält sich unverändert. Bei Objekten sieht es anders aus: Ein gewöhnlicher httpx.Client als http_client= löst nun bereits beim Erzeugen des Clients einen TypeError aus, nicht erst bei der ersten Anfrage. Eigene Clients, Timeouts und Transports müssen daher mit httpx2 erstellt werden. Aus einem httpx.Timeout-Objekt wird anthropic.Timeout oder 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 und DefaultAsyncHttpxClient behalten Namen und Verhalten bei. Sie übernehmen weiterhin die empfohlenen SDK-Standardwerte für Timeouts, Connection Pooling und Redirects – nur jetzt auf Basis von httpx2. Auch der Hinweis von Platform-DevX-Ingenieur @cjav_dev führt zum sinnvollsten Einstiegspunkt: der offiziellen MIGRATION.md mit Vorher-Nachher-Beispielen für sämtliche Änderungen.
Für diesen Wechsel gibt es bereits ein Vorbild. Der httpx2-Migrationsleitfaden des OpenAI Python SDK beschreibt praktisch denselben Weg: derselbe Fork, dasselbe Helferprinzip mit DefaultHttpx2Client und dieselben Warnungen zur respx-Kompatibilität. Teams, die openai bereits migriert haben, können ihren Ablauf nahezu unverändert übernehmen.
Diese APIs und Parameter fallen mit v1.0 weg
| In v1.0 entfernt | Stattdessen verwenden |
|---|---|
client.completions.create() (Text Completions) | client.messages.create() |
HUMAN_PROMPT / AI_PROMPT constants | Inhalte im Messages-Format mit Content-Blöcken |
temperature, top_p, top_k in Methodensignaturen | extra_body={"temperature": ...} für ältere Modelle, die diese Parameter weiterhin akzeptieren |
messages.parse(stream=True) | messages.stream(...) |
tool_runner(compaction_control=...) | Serverseitige Konfiguration der Kompaktierung |
anthropic.Transport, anthropic.ProxiesTypes aliases | Transporttypen aus httpx2 |
body= bei Low-Level-Request-Methoden | content= |
output_format schema dict in Beta-APIs | output_config={"format": ...} (Structured-Output-Helper akzeptieren weiterhin output_format=MyModel) |
isinstance(stream, anthropic.Stream)-Prüfungen | Den konkreten Typ MessageStream prüfen |
Zwei wichtige Randnotizen zur Tabelle: Pydantic v1 und v2 werden beide weiterhin unterstützt, Modellklassen sind also nicht betroffen. Außerdem werden Header nun unabhängig von Groß- und Kleinschreibung zusammengeführt. Wer denselben Header bislang mit unterschiedlicher Schreibweise doppelt gesetzt hat, erhält dadurch ein anderes Verhalten – ohne Fehlermeldung.
Async-Fallen bei Raw Responses
Die Änderungen im Async-Bereich sind eng begrenzt, aber unerquicklich für Nutzer von .with_raw_response. Beim asynchronen Client benötigen parse(), read(), text() und json() jetzt ein await. Beim synchronen Client wurden .text und .content von Properties zu Methoden. Beides schlägt nicht schon beim Import fehl: Synchron erscheint deutlich ein Attribute Error, asynchron kann unauffällig eine Coroutine entstehen, die nie ausgeführt wurde.
Auch Request- und Response-Objekte in Exceptions sowie Raw Results sind jetzt Typen aus httpx2. Die meisten Attribute funktionieren weiter wie gewohnt. Prüfungen wie isinstance(x, httpx.Response) und Typannotationen müssen jedoch angepasst werden – genau die Art von Problem, die pyright und mypy zuverlässig finden.
Der Fehler, den Monitoring und Tests übersehen können
Der Changelog behandelt dieses Thema in einem Satz, doch für das Monitoring ist es entscheidend. Laut Anthropics Migrationsleitfaden können Tools, die HTTP-Verkehr durch Patchen von httpx beobachten oder mocken – etwa OpenTelemetry, Sentry, respx, pytest-httpx oder vcrpy – nach dem Upgrade weiterlaufen und dennoch SDK-Requests unbemerkt verpassen. Die Tools lassen sich weiterhin importieren, laufen weiter und liefern Reports. Sie sehen nur keinen Verkehr mehr, der nicht länger durch die von ihnen gepatchte Bibliothek fließt. Tests mit solchen Mocks können damit folgenlos grün werden, sofern sie nicht ausdrücklich prüfen, ob ein Intercept tatsächlich stattgefunden hat: Kein Request erreicht den Mock, also schlägt auch nichts fehl.
Als Ausweg dient httpx2.alias_httpx(). Der Aufruf muss so früh wie möglich beim Start der Anwendung oder der Tests erfolgen – laut Python-SDK-Dokumentation vor jedem httpx-Import. Die Funktion stellt httpx2 unter dem Namen httpx bereit, damit Patch-Werkzeuge weiterhin funktionieren. Der Migrationsleitfaden warnt ausdrücklich davor, sie in Bibliothekscode aufzurufen: Sie gehört ausschließlich an den Einstiegspunkt der Anwendung.
„Ein sauberer Start beweist nicht, dass eure AI-Aufrufe noch getraced oder gemockt werden.“ — @MarMarLabs, Post vom Tag nach dem Release
Der vollständige Beitrag lohnt sich: Er empfiehlt, diesen unsichtbaren Fehler zum ersten Migrationstest zu machen. Nach dem Upgrade sollte gezielt geprüft werden, ob jeweils ein getraceter und ein gemockter Request weiterhin registriert wird. Der Thread nennt zudem die weiteren stillen Risiken: eigene Transports, die manuell auf httpx2 umgestellt werden müssen, sowie die Python-3.10-Untergrenze, an der ältere CI-Images bereits bei der Installation scheitern.
Was ohne Anpassung weiterläuft
Für viele Codebasen lautet die ehrliche Antwort: Es gibt nichts zu tun. Von der HTTP-Migration ist nicht betroffen, wer keine eigenen Clients, Transports oder Timeout-Objekte erstellt. Unverändert bleiben insbesondere:
client.messages.create(...)-Aufrufe mit gewöhnlichen Parametern – gleicher Request, gleiche Response-Modelle.- Numerische Timeout-Werte und die SDK-Defaults: 2 Retries mit exponentiellem Backoff bei Verbindungsfehlern, 408, 409, 429 und 5xx; standardmäßig 10 Minuten Timeout.
- Das Routing über
base_url. Wer das SDK auf ein Gateway oder einen API-kompatiblen Relay wie den Claude API endpoint von AIReiter richtet, muss in v1.0 auf dieser Ebene nichts ändern – umgezogen ist der Client, nicht die URL. - Pydantic-v1- und -v2-Modelle, SSE-Streaming-Helper und Schnittstellen für Datei-Uploads.
Die einzige harte Voraussetzung lautet Python 3.10+. Alle übrigen Punkte der „sicheren“ Liste gelten erst, wenn diese Hürde erfüllt ist.
Eine Migrationsreihenfolge für saubere Reviews
- Zunächst bewusst pinnen: Wenn die Migration noch nicht ansteht, hält
anthropic>=0.125,<1die Version fest, bis Zeit für die Arbeit eingeplant ist. - Die Codebasis nach
import httpxundhttpx.durchsuchen – jeder Treffer in SDK-nahem Code ist ein Migrationspunkt. - In Claude Code
/claude-api upgrade pythonausführen. Der Befehl wird in der Release-Ankündigung von @cjav_dev empfohlen und erzeugt einen Diff der Änderungen im Projekt. - Eigene Clients, Transports und Timeouts mit
httpx2oder den HelfernDefaultHttpxClientneu aufbauen. httpx2.alias_httpx()am Einstiegspunkt der Anwendung ergänzen, falls irgendetwashttpxpatcht.- pyright oder mypy ausführen – die httpx2-Typänderungen zeigen sich bei Typannotationen und
isinstance-Prüfungen. - In der CI pro Test-Suite einen getraceten und einen gemockten Request verifizieren. Grüne Start-Logs sind kein Nachweis.
FAQ zum Anthropic Python SDK v1.0
Gibt es Anthropic Python SDK v1 bereits, oder ist das Paket noch auf 0.x?
Es gibt sie. anthropic 1.0.0 ging am 20. August 2026 auf PyPI live und wurde auf GitHub als v1.0.0 getaggt, nachdem 0.125.0 am Vortag erschienen war. Die Projektseite auf PyPI verweist Nutzer von 0.x inzwischen auf den Migrationsleitfaden für v1.
Wie übergebe ich temperature, top_p oder top_k nach v1.0?
Sie wurden aus den Methodensignaturen entfernt. Für ältere Modelle, die diese Werte serverseitig noch akzeptieren, lässt sich etwa extra_body={"temperature": 0.7} verwenden. Dabei gilt: Aktuelle Modelle liefern bei nicht standardmäßigen Sampling-Werten einen 400-Fehler – unabhängig vom SDK. Diese Änderung liegt auf Modellebene.
Funktionieren respx-, pytest-httpx- oder vcrpy-Tests weiterhin?
Nicht mit dem Standardclient des SDK, und sie erzeugen dabei keinen Fehler – sie matchen schlicht keine Requests. Entweder wird beim Teststart vor jedem httpx-Import httpx2.alias_httpx() aufgerufen, oder die Mocks werden auf httpx2.MockTransport umgestellt. Eine respx-Version, die nur das alte httpx patcht, kann SDK-Verkehr nicht abfangen.
Was macht /claude-api upgrade python?
Das ist ein Claude-Code-Befehl, der in der Ankündigung von Anthropic-DevX-Ingenieur @cjav_dev empfohlen wird. Er untersucht ein Projekt mit anthropic 0.x und erzeugt einen Migrations-Diff für Imports, Timeout-Objekte und Raw-Response-Aufrufe. Änderungen lassen sich damit prüfen, statt sie erst über Tracebacks zu entdecken.
Bei 0.125 bleiben oder auf 1.0 wechseln?
Eine allgemeingültige Antwort gibt es nicht; entscheidend ist der konkrete Zielkonflikt. Unter 1.0 zu bleiben erhält sämtliche Mocks, Tracer und eigenen Transports unverändert, lässt das Projekt aber auf einem SDK vor der Stabilitätsmarke. Dessen Versionierungspolitik erlaubt inkompatible Änderungen in Minor-Releases, während die verwendete veraltete Oberfläche – Completions und Sampling-Parameter – nun offiziell Altlast ist. Der Wechsel auf 1.0 bringt eine stabile API ohne Beta-Status, verlangt aber jetzt einen vollständigen Audit der HTTP-Schicht statt irgendwann später. Ausschlaggebend ist, wie viel HTTP-Code ein Team selbst besitzt: Ein Service mit einem einfachen Anthropic()-Aufruf ist schnell aktualisiert. Eine Plattform mit eigenen Transports und respx-Test-Suites sollte vor dem Deployment unbedingt die stillen Fehlerfälle prüfen.
Weiterführend: die Skills API, die in derselben Woche die Beta-Phase verlässt, sowie die am 10. August dauerhaft gewordene Preisgestaltung von Sonnet 5 – beide aus derselben Phase der Claude-Platform-Releases.