Anthropic Python SDK v1.0 drops temperature, top_p and top_k in August 2026 but the API docs still list them

Summary. Anthropic published version 1.0.0 of its Python SDK to PyPI at 19:58 UTC on 20 August 2026, eight days after OpenAI shipped its own httpx2 rewrite as openai 3.0.0 on 12 August 2026. The Anthropic release raises the minimum Python version from 3.9 to 3.10, replaces the httpx HTTP layer with httpx2 (the Pydantic-maintained fork), deletes the legacy Text Completions API, and makes temperature, top_p and top_k a TypeError on every Messages method. That last change is the one that will bite, because the Claude Messages API reference still lists temperature with a documented default of 1.0 and a range of 0.0 to 1.0. The SDK is now stricter than the API it calls, and the same gap exists for structured outputs. Anthropic's own structured-outputs documentation says the API "continues to accept" the older output_format request field "for a transition period" while the Python SDK v1.0 refuses it.

What actually shipped, and when

The dependency metadata on PyPI is the cleanest evidence of the scope. Version 1.0.0 declares requires_python >=3.10 and pins httpx2<3,>=2.0.0. The previous release, 0.125.0, went out at 22:00 UTC on 19 August 2026, less than 22 hours before 1.0.0. Teams tracking the SDK with a loose anthropic>=0.1 constraint or an unpinned pip install anthropic in a container build picked up a major version with breaking changes inside a single day.

The SDK changelog lists exactly one breaking entry for 1.0.0: "upgrade to httpx2 and some minor breaking changes. See MIGRATION.md for details." The word "minor" is doing a lot of work there. The migration guide runs to fourteen sections.

Change in anthropic 1.0.0	Failure mode if you ignore it	Where it is documented
Minimum Python 3.10 (was 3.9)	pip refuses to install on 3.9	MIGRATION.md, "Environment requirements"
httpx replaced by httpx2>=2.0.0	TypeError at client construction if you pass an old httpx.Client	MIGRATION.md, "The SDK is built on httpx2"
temperature, top_p, top_k removed	TypeError on messages.create()	MIGRATION.md, "Removed: deprecated request parameters"
client.completions.create() removed	AttributeError; endpoint /v1/complete unreachable through the SDK	MIGRATION.md, "Removed: the legacy Text Completions API"
AnthropicBedrock() with no region	ValueError at construction instead of a silent fall back to us-east-1	MIGRATION.md, "Bedrock: a region is now required"
tool_runner(compaction_control=...) removed	TypeError; replacement has a 50,000-token floor	MIGRATION.md, "Removed: deprecated helper arguments and behaviour"

The sampling-parameter gap is the part to read twice

The migration guide's position is that the parameters are gone from the method signatures but not from the API: "models that predate the change still honour them." The prescribed workaround is extra_body, which the SDK merges into the request JSON untouched:

# Before
client.messages.create(..., model="claude-sonnet-4-6", temperature=0.2)

# After
client.messages.create(..., model="claude-sonnet-4-6", extra_body={"temperature": 0.2})

Meanwhile the Messages API reference, on the same documentation site, describes temperature as an optional number, "Amount of randomness injected into the response", with a default of 1.0, a range of 0.0 to 1.0, and the note that "even with temperature of 0.0, the results will not be fully deterministic." top_k ("Only sample from the top K options for each subsequent token") and top_p ("Use nucleus sampling") are both still there too, each flagged "Recommended for advanced use cases only." Neither carries a deprecation notice or a model cut-off.

So a reader has two Anthropic pages saying different things. The SDK guide says current models do not use these parameters. The API reference documents them as live request fields with defaults. Nothing on either page names the model version where the behaviour changed.

The practical consequence is that you cannot tell, from the documentation alone, whether the temperature=0 you have been sending has been doing anything for the last several model releases. If your evaluation harness pins temperature=0 and treats the result as reproducible, that assumption was already unsafe by the API reference's own wording, and v1.0 has now removed the parameter without telling you whether removing it changes your outputs. The honest engineering answer is to re-run your evals with and without extra_body={"temperature": 0} on the exact model you serve, and compare, rather than trusting either page.

The structured-outputs fork is the same shape

Anthropic's structured outputs page states the rule directly: the output_format parameter has moved to output_config.format, beta headers are no longer required, and "the API continues to accept the old beta header (structured-outputs-2025-11-13) and the output_format request field for a transition period, but the Python SDK (v1.0 and later) does not accept output_format={...} on client.beta.messages.create() or count_tokens() and raises a TypeError; use output_config instead."

That is an unusually clear statement of an unusual situation: the transport library has ended a transition period that the service has not. Any code path still passing a raw schema dict, including messages.stream() and messages.count_tokens() (which used to accept one and forward it), now fails locally rather than at the API boundary. The output_format=MyModel class form on the parse(), stream(), count_tokens() and tool_runner() helpers is unchanged, and the DeprecationWarning it used to emit is gone.

httpx2, and the one line that decides whether your tracing keeps working

httpx2 is a fork of httpx maintained by the Pydantic team. Its README states the reason plainly: "With HTTPX itself seeing limited activity recently, Pydantic is picking up stewardship under the HTTPX2 name so that users have a reliably maintained path forward - including timely security updates for a library that sits in the critical path of so many production systems." The fork keeps the same classes, the same behaviour, HTTP/1.1 and HTTP/2 support, and a requests-compatible API.

If your application only passes plain values such as timeout=30.0 and max_retries=3, the migration guide says there is likely nothing to do. The breakage is elsewhere, and it is quiet. Libraries that observe HTTP traffic by patching the httpx package (the guide names OpenTelemetry's HTTPXClientInstrumentor, Sentry's httpx integration, respx, pytest-httpx and vcrpy) patch a package the SDK no longer uses. They do not error. They keep running and stop seeing Claude API calls.

The fix is a single process-global call, and it has rules:

# the very first lines of your entry point
import httpx2

httpx2.alias_httpx()

import httpx  # this is now the httpx2 module
assert httpx.Client is httpx2.Client

alias_httpx() makes import httpx and import httpcore resolve to httpx2 and httpcore2 for the whole process. It raises a RuntimeError if anything has already imported httpx, and the guide is explicit that it is for applications: "a library should never call it on behalf of its users." Under pytest, the guide recommends registering an early plugin via addopts = "-p tests._alias_httpx" so it runs before respx and your test modules load.

Passing an old httpx.Client as http_client= raises a TypeError at construction, so that particular mistake cannot fail silently. Losing your APM spans can.

If you run both OpenAI and Anthropic in one service

The two SDKs converged on the same fork within eight days, and the version pins are compatible rather than conflicting.

	anthropic	openai
Latest version (22 Aug 2026)	1.0.0, uploaded 20 Aug 2026 19:58 UTC	3.3.1, uploaded 19 Aug 2026 16:31 UTC
requires_python	>=3.10	>=3.10
httpx2 constraint	httpx2<3,>=2.0.0	httpx2<3,>=2.7.0
Major version cut-over	20 Aug 2026	12 Aug 2026 (openai 3.0.0)

Because openai pins >=2.7.0 and anthropic pins >=2.0.0, a shared environment resolves to at least httpx2 2.7.0 and both are satisfied. You only need alias_httpx() once, at the top of the entry point, and only if something in your stack patches httpx. Teams already carrying the openai 3.0 migration will recognise most of this work; the certifi and TLS behaviour in that upgrade is covered in our note on the OpenAI Python 3.0 httpx2 and certifi container breakage.

The compaction floor nobody mentions in the release note

The tool runner's client-side compaction_control argument is gone, replaced by server-side compaction. The migration guide's before-and-after uses a 100,000-token threshold, so the mapping looks clean:

# After
runner = client.beta.messages.tool_runner(
    ...,
    betas=["compact-2026-01-12"],
    context_management={
        "edits": [
            {"type": "compact_20260112", "trigger": {"type": "input_tokens", "value": 100_000}}
        ]
    },
)

The compaction documentation adds a constraint the migration example does not exercise: input_tokens is the only supported trigger type, and value "must be at least 50,000 tokens." If your agent compacted at 20,000 or 30,000 input tokens, which is common for small-context cost control on long tool loops, there is no server-side equivalent. You either raise the threshold to 50,000 and pay for the larger context on every turn before compaction fires, or you write the trimming yourself against the raw Messages API. The real cost of this upgrade is usually that decision, not the import edits.

Who is affected, and how to tell in one command

You are affected if pip index versions anthropic resolves above 0.x in your next build and any of the following is true: your runtime is Python 3.9; you construct httpx.Client, httpx.Timeout or httpx.HTTPTransport and hand it to the SDK; you pass temperature, top_p or top_k; you call client.completions.create() or import anthropic.HUMAN_PROMPT; you build AnthropicBedrock() without aws_region or AWS_REGION set; you use await-free .parse() on the async client's .with_raw_response; or you rely on response.text and response.content as attributes rather than methods.

Three items deserve their own check because they change behaviour rather than raising:

• Header merging is now case-insensitive everywhere the SDK merges headers, including ANTHROPIC_CUSTOM_HEADERS. An entry replaces a same-named header whatever its casing instead of being sent alongside it. If you relied on two casings producing two header lines, send one comma-joined value.
• On Bedrock, unknown streaming events are now skipped rather than yielded. The migration guide names amazon-bedrock-invocationMetrics as the only known case.
• isinstance(obj, anthropic.Stream) returns False for MessageStream objects. The compatibility shim that kept those checks passing with a DeprecationWarning is gone; import MessageStream from anthropic.lib.streaming instead.

This is the second Anthropic SDK-surface break in four days. The computer use toolset left beta on 19 August 2026 with its own request-shape change, covered in our note on the Claude computer use toolset 20260801 migration, and the browser use toolset shipped the same day with the token accounting described in Claude browser use toolset token overhead. If you are choosing which model tier to carry through the upgrade, our Gemini 3.5 Pro vs GPT-5.6 vs Claude Fable 5 comparison sets out the current pricing positions.

The upgrade command itself is one line, pip install --upgrade "anthropic>=1,<2", and the guide's own advice is to run a type checker afterwards, since pyright or mypy will flag nearly every removed parameter and renamed type as an error. That is the cheapest possible test suite for this migration.

India-specific considerations

Python 3.9 reached end of life on 31 October 2025, and 3.10 is in security-fix-only status until October 2026 on the CPython release schedule. A large share of the managed-hosting and legacy container images still running in Indian enterprises ship 3.9 as the system interpreter, which turns a one-line SDK bump into an interpreter upgrade and a full dependency re-resolution. Budget it as an infrastructure change, not a library change.

The Bedrock region change matters more here than elsewhere. AnthropicBedrock() previously fell back to us-east-1 with a warning; it now raises a ValueError. Any Indian deployment that assumed a default region was pointing inference at a US region without an explicit configuration line. That is worth checking against your own DPDP data-residency position before you fix the crash and move on. The region is resolved from aws_region=, then AWS_REGION or AWS_DEFAULT_REGION, then the boto3 session for the named aws_profile. That last path is new: the profile argument was previously ignored for region lookup.

What is still unknown

Three things are not answerable from the published documentation as of 22 August 2026. Which model version stopped honouring temperature, top_p and top_k? No page names it. How long the API's "transition period" for output_format and the structured-outputs-2025-11-13 beta header runs — no end date is given. And whether the Messages API reference will be updated to mark the sampling parameters as legacy, or whether the SDK guide's claim will be softened. Until one of those pages moves, treat the SDK as the stricter contract and the API reference as the historical one.

FAQ

When did the Anthropic Python SDK v1.0 release?

Version 1.0.0 was uploaded to PyPI at 19:58 UTC on 20 August 2026. The previous release, 0.125.0, went out at 22:00 UTC on 19 August 2026, so the major version landed less than 22 hours later. The changelog records one breaking entry pointing at the migration guide.

Does the Claude API still accept temperature?

The migration guide says models that predate the change still honour the sampling parameters, and the Messages API reference still documents temperature with a default of 1.0 and a range of 0.0 to 1.0. Only the Python SDK method signatures dropped them. Pass the value through extra_body if you need it.

What is httpx2 and why did the SDK switch?

httpx2 is an API-compatible fork of httpx maintained by the Pydantic team. Its README says Pydantic picked up stewardship because httpx itself had seen limited activity, and points to timely security updates as the reason. Anthropic 1.0.0 pins httpx2<3,>=2.0.0 as a hard dependency.

Will my OpenTelemetry or Sentry tracing keep working?

Not by default. Libraries that patch the httpx package, including OpenTelemetry's HTTPXClientInstrumentor, Sentry's httpx integration, respx, pytest-httpx and vcrpy, keep running but stop seeing SDK requests. Call httpx2.alias_httpx() at the very top of your entry point before anything imports httpx.

What breaks on Amazon Bedrock?

AnthropicBedrock and AsyncAnthropicBedrock used to log a warning and fall back to us-east-1 when no region was found. They now raise a ValueError at construction. Unknown streaming events are also skipped rather than yielded, with amazon-bedrock-invocationMetrics named as the only known case affected.

Can I run the OpenAI and Anthropic SDKs in the same environment?

Yes. As of 22 August 2026 openai 3.3.1 pins httpx2<3,>=2.7.0 and anthropic 1.0.0 pins httpx2<3,>=2.0.0, so the resolver settles on at least 2.7.0 and satisfies both. Both packages also require Python 3.10 or later, so the interpreter floor is shared.

What replaced the tool runner's compaction_control argument?

Server-side compaction, enabled with the compact-2026-01-12 beta header and a compact_20260112 edit inside context_management. The compaction documentation requires the input_tokens trigger value to be at least 50,000 tokens, and input_tokens is the only supported trigger type, so any client-side threshold below that figure has no direct server-side equivalent today.

Is there a fast way to find every break in my codebase?

Run a type checker. The migration guide notes that pyright or mypy will flag almost everything the release removed, because the deleted parameters, renamed response classes and dropped type aliases all surface as static errors. Upgrade with pip install --upgrade "anthropic>=1,<2", then read the type checker output as your checklist.

How eCorpIT can help

Our senior engineering teams handle SDK major-version migrations as infrastructure work rather than dependency bumps: interpreter upgrades, observability re-instrumentation, and evaluation re-runs on the exact model you serve so a removed sampling parameter does not quietly change your outputs. We are CMMI Level 5, MSME certified and ISO 27001:2022 certified, and we design applications aligned with DPDP requirements where inference region matters. If you are running the Anthropic or OpenAI Python SDKs in production and need the upgrade scoped before it reaches your build pipeline, contact us.

References

1. Claude Platform release notes: 20 August 2026 entry announcing Python SDK v1.0.
2. Migrating to v1: anthropic-sdk-python MIGRATION.md: full list of removals and before/after edits.
3. anthropic-sdk-python CHANGELOG.md: 1.0.0 dated 2026-08-20, single breaking entry.
4. anthropic on PyPI: version 1.0.0, requires_python >=3.10, httpx2<3,>=2.0.0.
5. openai on PyPI: version 3.3.1, httpx2<3,>=2.7.0, 3.0.0 released 12 August 2026.
6. Claude Messages API reference: temperature, top_p and top_k still documented as request fields.
7. Structured outputs: Claude docs: API accepts output_format for a transition period; SDK v1.0 raises TypeError.
8. Compaction: Claude docs: compact-2026-01-12 beta header and the 50,000-token trigger floor.
9. HTTPX2 on GitHub: Pydantic stewardship statement and feature list.
10. HTTPX2 documentation: project documentation for the fork.
11. Claude Python SDK documentation: current installation and client reference.
12. Status of Python versions: Python Developer's Guide: 3.9 end-of-life 31 October 2025; 3.10 security status to October 2026.

Last updated: 22 August 2026.