AIREITER

Anthropic Python SDK v1.0 Migration Guide: What Breaks

Last Updated: 2026-08-22 00:24:02

Anthropic Python SDK v1.0 landed on PyPI on August 20, 2026, and most calling code survives it untouched. The genuinely dangerous part is invisible: the HTTP layer moved from httpx to httpx2, so tracing, APM agents, and test mocks that patch httpx keep running while quietly recording zero SDK requests. If your tests pass after upgrading, that proves less than you think.

Three releases in two days, then 1.0

The PyPI release history for anthropic tells the story in five lines: 0.123.0, 0.124.0, and 0.125.0 all shipped on August 19, 2026, and 1.0.0 followed on August 20 as a standard Trusted Publishing release.

What changed, per the official release notes:

Anthropic Platform release notes showing the August 20, 2026 Python SDK v1.0 entry
  • The HTTP layer moves from httpx to httpx2, a maintained, API-compatible fork.
  • Python 3.10 or later is required; classifiers list 3.10 through 3.14.
  • Long-deprecated surface is removed: the legacy Text Completions API, the temperature, top_p, and top_k parameters on Messages methods, and the tool runner's client-side compaction_control.
  • AnthropicBedrock now raises an error when no AWS region is configured, instead of silently defaulting to us-east-1.

The GitHub tag v1.0.0 describes it as "upgrade to httpx2 and some minor breaking changes," and one side effect is easy to miss in the release notes: the beta warning on the parse, stream, and tool_runner helpers is gone. A 1.0 number with no beta caveats suggests Anthropic now treats this surface as stable.

The httpx to httpx2 switch, in practice

If you construct clients plainly, nothing happens. If you touch the HTTP layer, everything happens.

The dividing line is what you pass to the client. Numeric values keep working — Anthropic(timeout=30.0) behaves exactly as before. Objects do not: passing a regular httpx.Client as http_client= now raises a TypeError at construction, not at first request. Custom clients, timeouts, and transports must be built from httpx2 instead, and timeouts that were httpx.Timeout objects become anthropic.Timeout (or 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 and DefaultAsyncHttpxClient are unchanged in name and behavior — they preserve the SDK's recommended timeout, pooling, and redirect defaults, now over httpx2. Anthropic's employee announcement from platform devx engineer @cjav_dev points to the same place everyone should start: the official MIGRATION.md, which lists every change with before-and-after snippets.

There is precedent for this exact move. The OpenAI Python SDK's httpx2 migration guide walked the same path first, down to the same fork, the same DefaultHttpx2Client helper pattern, and the same respx compatibility warnings. Teams that already migrated openai can reuse their playbook nearly verbatim.

Everything v1.0 removed

Removed in v1.0What to use instead
client.completions.create() (Text Completions)client.messages.create()
HUMAN_PROMPT / AI_PROMPT constantsMessages-formatted content blocks
temperature, top_p, top_k in method signaturesextra_body={"temperature": ...} for legacy models that still accept them
messages.parse(stream=True)messages.stream(...)
tool_runner(compaction_control=...)Server-side compaction configuration
anthropic.Transport, anthropic.ProxiesTypes aliaseshttpx2 transport types
body= on low-level request methodscontent=
output_format schema dict in beta APIsoutput_config={"format": ...} (structured-output helpers still accept output_format=MyModel)
isinstance(stream, anthropic.Stream) checksCheck the concrete MessageStream type

Two footnotes to that table. Pydantic v1 and v2 both remain supported, so model classes are safe. And header merging is now case-insensitive, which changes behavior if you ever set the same header twice with different casing — an edge case, but one that produces no error when it bites.

Async changes that only bite raw-response users

The async changes are narrow but nasty if you use .with_raw_response. On the async client, parse(), read(), text(), and json() now require await. On the sync client, .text and .content changed from properties to methods. Neither fails at import time; the sync one fails loudly with an attribute error, the async one fails subtly if you awaited nothing and got a coroutine you never ran.

Related: request and response objects inside exceptions and raw results are now httpx2 types. Attribute access mostly works the same, but isinstance(x, httpx.Response) checks and type annotations need updating, which is exactly the kind of thing pyright and mypy will catch for you.

The migration failure you cannot see

Here is the section the changelog compresses into one sentence and your monitoring dashboard will not forgive. Per Anthropic's migration guide, tooling that observes or mocks HTTP traffic by patching httpx — OpenTelemetry, Sentry, respx, pytest-httpx, vcrpy — can keep running after the upgrade while silently missing SDK requests. Those tools keep importing, keep running, and keep reporting; they just stop seeing traffic that no longer flows through the library they patch. Tests built on such mocks can pass vacuously when they do not assert that an interception actually happened: no traffic reaches the mock, nothing fails.

The escape hatch is httpx2.alias_httpx(), called at the earliest point in your application or test startup — the Python SDK docs specify before any httpx import. It aliases httpx2 under the httpx name so patching tools keep working, and the migration guide warns against calling it from library code: only from the application entry point.

"A clean startup does not prove your AI calls are still traced or mocked." — @MarMarLabs, posting the day after release

That post is worth reading in full: it recommends treating the invisible failure as the first migration test — run your upgrade, then deliberately verify that one traced call and one mocked call still register. The same thread flags the other silent risks: custom transports that need manual migration to httpx2, and the Python 3.10 floor breaking older CI images at install time.

Code that keeps working untouched

For a lot of codebases the honest answer is: nothing to do. You are unaffected by the HTTP migration if you never build custom clients, transports, or timeout objects. Specific things that do not change:

  • client.messages.create(...) calls with plain parameters — same request, same response models.
  • Numeric timeout values and the SDK defaults: 2 retries with exponential backoff on connection errors, 408, 409, 429, and 5xx; a 10-minute default timeout.
  • base_url routing. If you point the SDK at a gateway or an API-compatible relay such as AIReiter's Claude API endpoint, v1.0 changes nothing about that layer — the client, not the URL, is what moved.
  • Pydantic v1 and v2 models, SSE streaming helpers, and file-upload interfaces.

The one hard gate is Python 3.10+. Everything else in the "safe" list assumes you clear that bar first.

A migration order that survives code review

  1. Pin deliberately first: if you are not ready, anthropic>=0.125,<1 holds the line while you schedule the work.
  2. Grep the codebase for import httpx and httpx. — every hit inside SDK-adjacent code is a migration item.
  3. Run /claude-api upgrade python in Claude Code — the command @cjav_dev's release announcement recommends — to get a generated diff of what changes in your project.
  4. Rebuild custom clients, transports, and timeouts from httpx2 or the DefaultHttpxClient helpers.
  5. Add httpx2.alias_httpx() at the application entry point if anything patches httpx.
  6. Run pyright or mypy — the httpx2 type changes surface as annotations and isinstance errors.
  7. In CI, assert one traced request and one mocked request per test suite. Green startup logs are not evidence.

Anthropic Python SDK v1.0 FAQ

Does Anthropic Python SDK v1 exist, or is it still 0.x?

It exists. anthropic 1.0.0 went live on PyPI on August 20, 2026, tagged v1.0.0 on GitHub, following 0.125.0 the day before. PyPI's project page now directs 0.x users to the v1 migration guide.

How do I pass temperature, top_p, or top_k after v1.0?

They are gone from the method signatures. For legacy models that still accept them server-side, pass extra_body={"temperature": 0.7}. Note that current models return a 400 for non-default sampling values regardless — that change happened at the model level, not in the SDK.

Do respx, pytest-httpx, or vcrpy tests still work?

Not against the SDK's default client, and they will not error — they will match nothing. Either call httpx2.alias_httpx() before any httpx import in test startup, or move mocks to httpx2.MockTransport. A respx release that patches only legacy httpx cannot intercept SDK traffic.

What does /claude-api upgrade python do?

It is a Claude Code command, recommended in Anthropic devx engineer @cjav_dev's announcement, that scans a project using anthropic 0.x and produces a migration diff — imports, timeout objects, raw-response calls — so you review changes instead of discovering them from tracebacks.

Pin at 0.125 or move to 1.0

This one has no universally right answer, so here is the actual trade-off. Staying below 1.0 preserves every mock, tracer, and custom transport exactly as built, but keeps you on a pre-stability SDK whose versioning policy allows backward-incompatible changes in minor releases, with the deprecated surface you depend on (completions, sampling params) now officially dead weight. Moving to 1.0 buys a stable, non-beta API surface at the price of doing the full HTTP-layer audit now instead of someday. The deciding factor is how much HTTP-layer code you own: a service with one plain Anthropic() call upgrades trivially, while a platform with custom transports and respx suites owes itself the silent-failure checks before shipping.

Related reading: the Skills API leaving beta the same week, and Sonnet 5's pricing becoming permanent on August 10 — both from the same stretch of Claude Platform releases.