Tested fix · Updated

TypeError: Messages.create() got an unexpected keyword argument 'temperature'

The anthropic Python SDK removed temperature, top_p and top_k in version 1.0.0, released on 20 August 2026, not in 2.0. That is why the pin most people try, anthropic<2, does not fix this error: it installs 1.17.0, the latest 1.x, which doesn't have the argument either. anthropic<1 installs 0.125.0, the last release that has it. The SDK raises the error before anything is sent, so it isn't the API rejecting your request.

Version 2.0.0, released on 21 October 2026, made it harder to get round. It sends the new API version 2026-10-21, and under that version the API itself refuses the three parameters with a 400 error on every model. It also changed MessageParam, which breaks code that calls it. The same upgrade can show up as any of these:

TypeError: AsyncMessages.create() got an unexpected keyword argument 'temperature'
TypeError: Cannot instantiate typing.Union
ImportError: cannot import name 'HUMAN_PROMPT' from 'anthropic'
ModuleNotFoundError: No module named 'httpx'
anthropic.BadRequestError: Error code: 400 - {'type': 'error', 'error': {'type': 'invalid_request_error', 'message': 'temperature: Extra inputs are not permitted'}, ...}

If the traceback ends inside a library you installed, not in your own code, look the library up in the table below. We installed 25 libraries that depend on anthropic from scratch on 24 October 2026 and ran each one against a local test server.

anthropic versionHas temperature, top_p, top_kAPI version it sendsPin that installs it
0.125.0 and earlieryes2023-06-01anthropic<1
1.0.0 to 1.17.0no: TypeError2023-06-01anthropic<2
2.0.0 to 2.3.0no: TypeError2026-10-21anthropic (latest)

Fixes, by situation

1. Your own code passes temperature, top_p or top_k. Remove the argument. That is Anthropic's own advice, and the request then samples with the defaults, including a temperature of 1.0. On Claude 4.7 and later models nothing changes, because those models accept only the default values anyway. They have their own, separate 400 for a non-default value, quoted in public bug reports as temperature is deprecated for this model.

If you rely on a lower temperature on a model that still accepts it, such as Claude Sonnet 4.6, Anthropic's migration guide says to keep that request on API version 2023-06-01. The SDK has no argument for it, but you can still put the parameter in the request body:

# anthropic 1.x (pip install "anthropic<2"): sends API version 2023-06-01
client.messages.create(
    model="claude-sonnet-4-6",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello"}],
    extra_body={"temperature": 0.2},
)

On 2.x, the same extra_body goes out under 2026-10-21 and gets the 400. Set the old version on the client as well:

# anthropic 2.x: every request from this client sends API version 2023-06-01
client = anthropic.Anthropic(default_headers={"anthropic-version": "2023-06-01"})

Our test server received exactly that: temperature in the body, with anthropic-version: 2023-06-01, from 1.17.0 with extra_body and from 2.3.0 with both lines. We did not send these requests to Anthropic's API; Anthropic's migration guide names 2023-06-01 as the way to keep a non-default value. The alternative is pip install "anthropic<1", which keeps the argument as it was. You then give up every SDK release after 0.125.0 (19 August 2026), and the pin fails to resolve if another package needs anthropic>=1.

2. A library you installed raises it. Find the library in the table. There are two cases:

  • The library passes temperature itself, on every call. In our test, genagent 0.4.1, graphiti-core 0.31.2 and autogen-ext 0.7.5 did this. llama-index-llms-anthropic 0.12.3 did it on 1.x for every model except claude-sonnet-5-5 (on 2.x it fails earlier: situation 3). All of them sent their requests normally after pip install "anthropic<1". anthropic<2 did not help any of them.
  • The library only forwards your call. Monitoring and tracing wrappers like sentry-sdk, OpenTelemetry and OpenInference, and libraries like google-adk, outlines and weave, raise the error only when your code passes temperature. The traceback runs through the library, but the argument is yours: see situation 1.

3. TypeError: Cannot instantiate typing.Union. In 2.0, anthropic.types.MessageParam became a union of one type per role, and calling it as a function raises this error. If the call is in your code, write the message as a plain dict, as Anthropic's migration guide shows:

# Before (raises on anthropic 2.x)
message = MessageParam(role="user", content="Hello")
# After
message: MessageParam = {"role": "user", "content": "Hello"}

On 2.3.0, the first line raised the error and the second was sent normally. If the call is in a library, it needs a fix from the library. llama-index-llms-anthropic 0.12.3 fails this way on every model with 2.x. With anthropic<2 it works only for claude-sonnet-5-5 and gets the temperature error on the 4.x models. anthropic<1 makes it work on all four models we tried. If you are moving off claude-sonnet-4-5-20250929 anyway, Anthropic retires it on 30 November 2026 (Breakage Calendar).

4. ImportError: cannot import name 'HUMAN_PROMPT' from 'anthropic'. 1.0 removed the legacy Text Completions API, and HUMAN_PROMPT with it. The import fails on 1.17.0 and 2.3.0 and works on 0.125.0. swebench 5.0.2 fails this way when it calls Claude. Pin anthropic<1, or move the code to the Messages API.

5. ModuleNotFoundError: No module named 'httpx'. 1.0 moved the SDK's HTTP layer from httpx to httpx2, so installing anthropic no longer installs httpx. A library that imports httpx without listing it as a dependency then fails at import. graphiti-core 0.31.2 did this on 1.17.0 and 2.3.0. pip install httpx gets it past the import, but it then raises the temperature error; anthropic<1 fixes both.

6. 400 ... temperature: Extra inputs are not permitted. This one comes from the API, not from the SDK. You are on SDK 2.x, so requests carry API version 2026-10-21, and something still sends temperature in the body, usually through extra_body. See where this 400 comes from.

Using Python 3.9? Versions 1.0.0 and later require Python 3.10 or newer, so pip on Python 3.9 still installs 0.125.0 and none of this applies yet. It will when that project moves to 3.10.

Why anthropic<2 doesn't fix it

Two releases two months apart did two different things:

  • 1.0.0, 20 August 2026. Anthropic's release notes for that day say v1.0 "removes long-deprecated surface, including the legacy Text Completions API, the temperature, top_p, and top_k parameters on Messages methods". The API version did not change: 1.x still sends 2023-06-01, which accepts the parameters. Only the Python method signatures lost them. In the SDK's source, temperature appears 36 times in anthropic/resources/messages/messages.py in 0.125.0 and 0 times in 1.0.0, 1.17.0 and 2.3.0.
  • 2.0.0, 21 October 2026. It switched the SDK to API version 2026-10-21, under which a request with any of the three parameters returns a 400 error on every model, and made MessageParam a union.

Most of the attention went to 2.0, and the migration guide for 2026-10-21 says that "as of the latest major versions, the SDK and the CLI no longer have the three parameters". So when a project starts failing, pinning below 2 looks like the fix. The TypeError comes from the August change, though, so only anthropic<1 undoes it.

A library that lists anthropic with no upper version bound picks up whichever major version is newest when someone installs it. Of the 15,000 most-downloaded projects on PyPI, 52 depend on anthropic with no upper bound. Some of them are capped indirectly by another dependency: langchain-aws gets 1.17.0 through langchain-anthropic, and openhands-ai gets 0.125.0 through browser-use.

25 libraries on a fresh install

Five of the 25 failed on their default call. Twelve more raised the error, or sent or dropped temperature, only when a temperature was set. Each library was installed on its own in a new environment on 24 October 2026, with Python 3.12 and only releases published before 12:00 UTC that day. Each one then made one call through its documented Claude path against a local test server. "Set temperature" means the library's own temperature setting set to 0, or, for wrappers, your code passing temperature=0 through them. Then we pinned anthropic<2 and anthropic<1 and ran both again.

Libraryanthropic 2.3.0, default call2.3.0, set temperatureanthropic<2 (1.17.0)anthropic<1 (0.125.0)
llama-index-llms-anthropic 0.12.3Cannot instantiate typing.Union, all 4 modelssametemperature TypeError, except claude-sonnet-5-5works
graphiti-core 0.31.2 [anthropic]No module named 'httpx'; with httpx added, AsyncMessages.create() temperature TypeErrorsamesamerequest sent
genagent 0.4.1temperature TypeErrorsamesameworks
autogen-ext 0.7.5 [anthropic]No module named 'tiktoken' (every version); with tiktoken added, AsyncMessages.create() temperature TypeErrorsamesameworks with tiktoken added
swebench 5.0.2cannot import name 'HUMAN_PROMPT'samesameworks
sentry-sdk 2.73.0 [anthropic]workstemperature TypeErrorsame as 2.3.0works
langchain-google-vertexai 3.2.5 [anthropic]workstemperature TypeErrorsame as 2.3.0works
google-adk 2.13.0 [extensions]worksAsyncMessages.create() temperature TypeErrorsame as 2.3.0works
opentelemetry-instrumentation-anthropic 0.62.4workstemperature TypeErrorsame as 2.3.0works
openinference-instrumentation-anthropic 3.1.0workstemperature TypeErrorsame as 2.3.0works
outlines 1.3.3 [anthropic]workstemperature TypeErrorsame as 2.3.0works
codewords-client 0.4.11 [anthropic]workstemperature TypeErrorsame as 2.3.0works
weave 0.54.0 [anthropic]workstemperature TypeErrorsame as 2.3.0works
agentscope 2.0.10worksAsyncMessages.create() temperature TypeErrorsame as 2.3.0works
pydantic-ai-slim 2.61.0 [anthropic]workssends temperature under 2026-10-21: the 400works, sent under 2023-06-01works
agno 3.1.10 [anthropic]workssends temperature under 2026-10-21: the 400works, sent under 2023-06-01works
prompty 2.1.0 [jinja2,anthropic]worksno error, but temperature is left out of the requestsame as 2.3.0works, temperature sent
langchain-aws 1.9.0 [anthropic]gets 1.17.0, worksworksworksworks
openhands-ai 1.11.0gets 0.125.0, worksworks; temperature not in the requestworksworks
opentelemetry-instrumentation-bedrock 0.62.4works (calls Bedrock through boto3, not the SDK)worksworksworks
harbor 0.24.0 [computer-1]worksno temperature settingworksworks
graphifyy 0.9.95 [anthropic]worksno temperature settingworksworks
csp-toolkit 0.9.0 [ai]worksno temperature settingworksworks
tokencost 0.1.26worksno temperature settingworksworks
sglang 0.5.22not runnot runnot runnot run

"Works" means the call completed against our test server, so it is about what the SDK and the library do, not about what Anthropic's API returns. "Request sent" for graphiti-core means the request went out with temperature; the library then could not parse our test server's canned reply, which is not a real Claude response. We did not run sglang, because a full install pulls in the CUDA stack. Its Anthropic backend always passes temperature, top_p and top_k to messages.create, so on anthropic 1.0 or later it should raise the TypeError. That is from reading its source only.

Where the 400 comes from

Anthropic's API versions page says that under 2026-10-21 "the temperature, top_p, and top_k request parameters are removed. A request that sends any of them returns a 400 error on every model." The migration guide adds that this applies "even at the parameter's default value".

The exact message, temperature: Extra inputs are not permitted, comes from public reports, not from our own calls. inspect_ai's pull request #6003 (21 October 2026) reports it for temperature, top_p and top_k, checked on claude-haiku-4-5, claude-sonnet-4-6 and claude-sonnet-5, and reports that with 2023-06-01 the two 4.x models accepted all three. The same report quotes Amazon Bedrock refusing 2026-10-21 for Sonnet 4.6 with 400 Invalid API version: 2026-10-21. Anthropic's migration guide says that on Bedrock 2026-10-21 is available only for Claude 4.7 and later models.

Two libraries in our test send temperature this way on SDK 2.x when you set it: pydantic-ai-slim 2.61.0 and agno 3.1.10. Our test server saw temperature in the body with anthropic-version: 2026-10-21, which is the documented 400 case. We did not send these requests to Anthropic. To avoid it, don't set a temperature in those libraries, or pin anthropic<2: both then sent the same body under 2023-06-01.

How we tested

The library calls ran on 24 October 2026 between 10:43 and 11:03 UTC, and the direct calls in the fixes section at 11:18 UTC. Each environment was new and installed with:

uv pip install --exclude-newer 2026-10-24T12:00:00Z "<library>[extra]"
uv pip install --exclude-newer 2026-10-24T12:00:00Z "<library>[extra]" "anthropic<2"
uv pip install --exclude-newer 2026-10-24T12:00:00Z "<library>[extra]" "anthropic<1"

with uv 0.8.2 and Python 3.12.11 in a disposable Linux container. With no cap, every library resolved anthropic 2.3.0 except langchain-aws (1.17.0) and openhands-ai (0.125.0). anthropic<2 resolved 1.17.0 and anthropic<1 resolved 0.125.0.

Calls went to a local test server that records each request's path, headers and JSON body and returns a fixed, valid Messages response, with a placeholder API key. "Default call" uses the library's documented setup with no temperature setting. The 25 libraries are, in order of 30-day downloads, the first among the 15,000 most-downloaded PyPI projects that list anthropic as a runtime dependency with no upper bound. We skipped six of the first 31: five make no Claude call we could drive, and one failed to build a dependency unrelated to anthropic. Where a library's normal entry point needs outside services (a Docker task environment, a Weights & Biases login, a Hugging Face dataset), we called the function that sends the Claude request directly.

Not tested: Anthropic's real API (we saw no 400 ourselves), Bedrock or Vertex AI accepting or refusing 2026-10-21, streaming except in pydantic-ai, the TypeScript SDK and other SDKs, libraries that cap anthropic below 2.0 (they get 1.17.0, which already lacks temperature), and sglang.