Anthropic API 2026-10-21: temperature gibt auch bei 1.0 HTTP 400

Eine Claude-Anfrage mit API-Version 2026-10-21 liefert HTTP 400, sobald sie temperature, top_p oder top_k setzt. Das gilt auch für den Standardwert: temperature: 1.0 scheitert mit „temperature: Extra inputs are not permitted“. Diese Sampling-Parameter steuern, wie zufällig das Modell das jeweils nächste Token auswählt. Die API-Version wird über den Request-Header anthropic-version gesetzt. Sie bestimmt, wie die Messages API eine Anfrage validiert und beantwortet; der bisherige Wert ist 2023-06-01. Die neuen SDK-Hauptversionen, die Anthropic am 21. Oktober zusammen damit veröffentlicht hat (Python 2.0.0, TypeScript 1.0.0 und fünf weitere), senden die neue Version standardmäßig. In diesen SDKs gibt es die Sampling-Parameter gar nicht mehr. Der Fehler 400 betrifft deshalb Code, der den Request-Body selbst zusammenstellt: direkte HTTP-Clients und zusätzliche Body-Felder. Wir haben acht Anfragevarianten unter beiden Versionen mit Claude Sonnet 4.6 und Claude Sonnet 5.5 getestet, zwei Python-SDK-Versionen verglichen und die Tests über Synthorai wiederholt.

TL;DR

• Unter 2026-10-21 führen temperature, top_p und top_k bei Claude Sonnet 4.6 und Sonnet 5.5 zu HTTP 400, auch mit temperature: 1.0.
• 2026-10-21 lehnt außerdem document-Blöcke in Assistant-Nachrichten und citations an Textblöcken des Nutzers ab.
• Das Python-SDK 2.x von Anthropic sendet den Schlüssel als Authorization: Bearer. Enthält eine Anfrage beide Header, verwendet die API x-api-key.
• Über Synthorai lieferten alle 32 Anfragen mit beiden SDKs Status 200, einschließlich der 12, die die Anthropic API unter 2026-10-21 ablehnt.

Welche Anfragen liefern unter API-Version 2026-10-21 HTTP 400?

Fünf Änderungen verursachen die 400-Fehler: die drei Sampling-Parameter, ein direkt in einer Assistant-Nachricht platzierter document-Block und citations an einem Textblock in einer Nutzernachricht. citations sind Verweise von einem Textblock auf eine Passage in einem Dokument. Die Tabelle deckt diese Änderungen mit sechs abgelehnten und zwei weiterhin gültigen Fällen ab. Jeden Fall haben wir pro Modell und Version einmal direkt an die Anthropic API gesendet. 200 bedeutet, dass die Anfrage akzeptiert wurde; 400 bedeutet, dass sie mit invalid_request_error abgelehnt wurde.

Die Fehlermeldungen unter der neuen Version:

Claude Sonnet 5.5 lehnte abweichende Sampling-Werte bereits unter 2023-06-01 ab, allerdings mit einer anderen Meldung („`temperature` is deprecated for this model.“). temperature: 1.0 wurde akzeptiert. Unter 2026-10-21 gibt es den Parameter selbst nicht mehr, deshalb scheitert auch der Standardwert. Claude Sonnet 4.6 akzeptierte unter der alten Version alle Fälle. Laut Anthropics Migrationsanleitung gelten dieselben Regeln für die Token-Zählung und für jede Anfrage in einem Message Batch. Die Batch API führt viele Anfragen asynchron zu einem reduzierten Preis aus. Ein Enddatum für 2023-06-01 nennt die Anleitung nicht.

Wie lassen sich die einzelnen 400-Fehler beheben?

Entfernt die drei Sampling-Parameter, verschiebt Dokumente in Nutzernachrichten und entfernt citations aus Texten, die ihr als Nutzer sendet. Ohne Sampling-Parameter gelten die Standardwerte, einschließlich temperature 1.0. So verhielt sich bereits eine Anfrage unter 2023-06-01, die diese Parameter nicht setzte. Quellenverweise an früheren Antworten von Claude sowie "citations": {"enabled": true} an Dokumenten werden weiterhin akzeptiert.

Mit dem Python-SDK sieht eine Anfrage, die unter beiden Versionen funktioniert, so aus:

import anthropic

client = anthropic.Anthropic()  # 2.x sends anthropic-version: 2026-10-21

message = client.messages.create(
    model="claude-sonnet-5-5",
    max_tokens=1024,
    # no temperature, top_p or top_k: the parameters no longer exist in 2.x
    messages=[{"role": "user", "content": "Summarize this memo in one sentence."}],
)
print(message.content[0].text)

Braucht eine Anfrage einen anderen temperature-Wert für ein Modell, das ihn noch akzeptiert, etwa Claude Sonnet 4.6, muss sie bei der alten Version bleiben. Bei direktem HTTP-Zugriff setzt ihr dafür den Header selbst:

curl https://api.anthropic.com/v1/messages \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "content-type: application/json" \
  -d '{"model": "claude-sonnet-4-6", "max_tokens": 256, "temperature": 0.2,
       "messages": [{"role": "user", "content": "Pick a number from 1 to 100."}]}'

Was hat sich in den Anthropic-SDKs geändert?

Die SDK-Hauptversionen, die 2026-10-21 senden, sind Python 2.0.0, TypeScript 1.0.0, Go 2.0.0, Java 3.0.0, C# 13.0.0, PHP 1.0.0 und Ruby 2.0.0. Neben der API-Version ändern sie die Übertragung des Schlüssels und die Anzahl der Zugangsdaten, die ein Client halten kann. Außerdem stehen sie unter Apache 2.0 statt MIT. Wir haben das Python-SDK in Version 1.17.0 (der letzten 1.x-Version) und 2.3.0 installiert und beide auf einen lokalen Echo-Server gerichtet. Dieser zeichnet Header und Body jeder eingehenden Anfrage auf:

Das Argument temperature wurde bereits in Version 1.0.0 aus den Nachrichtenmethoden des Python-SDKs entfernt. Python-Nutzer stoßen deshalb nur über extra_body auf den serverseitigen 400-Fehler oder über HTTP-Clients und Bibliotheken, die den Request-Body selbst zusammenstellen. Mit der SDK-Option extra_body lassen sich zusätzliche Felder direkt in den Request-Body einfügen. Der Bearer-Header funktioniert unter beiden API-Versionen: Eine Anfrage nur mit Authorization: Bearer <key> lieferte auch unter 2023-06-01 Status 200. Die Umstellung der Authentifizierung und der API-Version lässt sich somit getrennt ausrollen.

Welcher Schlüssel wird verwendet, wenn beide Header gesendet werden?

Enthält eine Anfrage beide Header, verwendet die Anthropic API x-api-key. Wir haben fünf Header-Kombinationen unter beiden Versionen gesendet:

Ein Proxy oder Gateway vor Claude kann einen anderen Schlüssel als die API zur Zuordnung der Anfrage heranziehen. Mit SDK 2.x sendet Code, der über extra_headers={"X-Api-Key": other_key} einen zweiten Schlüssel ergänzt, nun zwei Schlüssel: den des Clients in Authorization und den anderen in x-api-key. Die Anthropic API authentifiziert die Anfrage mit other_key. Ein Proxy, der nur Authorization auswertet, ordnet sie dagegen dem Schlüssel des Clients zu. Dadurch können schlüsselbezogene Kontingente, Logs und Ausgabenlimits dem falschen Schlüssel zugeordnet werden. Die Migrationsanleitung empfiehlt für den Client, den zweiten Schlüssel als Authorization: Bearer <other_key> zu senden. Auf Proxy-Seite sollten beide Header gelesen werden. Übernehmt entweder die Priorität der API (x-api-key zuerst) oder lehnt Anfragen ab, deren Header unterschiedliche Schlüssel enthalten.

Was geht ohne temperature verloren?

Der Wegfall von temperature hat weniger Auswirkungen, als Teams erwarten könnten, die sich auf temperature: 0 verlassen haben. Laut Migrationsanleitung akzeptieren Claude 4.7 und spätere Modelle ohnehin nur die Standardwerte. Für sie ändert sich nichts. Bei einem Modell wie Claude Sonnet 4.6, das noch andere Werte annimmt, entfällt die Wirkung einer niedrigeren temperature auf die Gleichmäßigkeit der Ausgaben. Eine andere Einstellung als Ersatz gibt es nicht. Wir haben gemessen, wie viel dieser Effekt ausmacht: 20 Anfragen pro Einstellung an Sonnet 4.6 unter 2023-06-01, jeweils mit einer angehängten zufälligen Request-ID, damit keine zwei Anfragen identisch waren.

Bei diesen kurzen Antworten waren die Ausgaben von Sonnet 4.6 mit der Standard-Temperature ähnlich stark konzentriert wie bei 0. Das Entfernen von temperature: 0 änderte daher wenig. Auch temperature: 0 garantierte keine deterministischen Ergebnisse: In 20 Versuchen kamen zwei verschiedene Zahlen zurück. Der Prompt-Text beeinflusste die Ausgabe stärker als die Einstellung: Ohne angehängte Request-ID war 42 die häufigste Antwort (17 von 20 bei temperature: 0), mit ihr war es 47. Wer reproduzierbare Ausgaben braucht, sollte Antworten im Code vergleichen oder cachen. Der Sampling-Parameter hat das auch bisher nicht gewährleistet.

Wie behandelt Synthorai API-Version 2026-10-21?

Synthorai akzeptiert Anfragen mit beiden API-Versionen und aus beiden SDKs. Ein Upgrade auf SDK 2.x oder das Senden von anthropic-version: 2026-10-21 lässt deshalb keine zuvor funktionierende Anfrage scheitern. Wir haben die Testmatrix mit 16 Fällen für beide Modelle über Synthorai mit beiden anthropic-version-Werten wiederholt: Alle 32 Anfragen lieferten Status 200, einschließlich der 12, die die Anthropic API unter 2026-10-21 ablehnt. Das Python-SDK 1.17.0 (mit x-api-key) und 2.3.0 (mit Authorization: Bearer) funktionierten beide mit base_url="https://synthorai.io" und demselben Schlüssel. Das galt auch für temperature, wenn der Parameter über extra_body gesendet wurde.

Synthorai verhält sich aus vier Gründen so:

• Ein Modell, mehrere Anbieter. Ein Claude-Modell kann über die Anthropic API, Amazon Bedrock oder Google Cloud Vertex AI bereitgestellt werden. Jeder Anbieter verwendet seine eigene Versionskennung. Synthorai sendet jedem Anbieter die erwartete Version. Der anthropic-version-Header des Clients bestimmt deshalb nicht, wie eine Anfrage validiert wird.
• Unterschiedliche Clients während der Migration. Teams aktualisieren ihre Dienste nacheinander. Deshalb sendet dasselbe Konto wochenlang 2023-06-01 aus SDK 1.x und 2026-10-21 aus SDK 2.x. Da beide akzeptiert werden, lässt sich jeder Dienst nach seinem eigenen Zeitplan umstellen. Derselbe Schlüssel funktioniert mit den Authentifizierungs-Headern beider SDKs.
• Modellwechsel ohne Codeänderung. Code, der temperature: 0.2 für Claude Sonnet 4.6 setzt, läuft weiter, wenn der Modellname auf Claude Sonnet 5.5 geändert wird. Obwohl dieses Modell den Parameter nicht akzeptiert, scheitert die Anfrage nicht am Wechsel.
• Keine fehlgeschlagene Anfrage wegen eines Standardwerts. temperature: 1.0 ist ohnehin der Wert, den das Modell verwendet. Ihn abzulehnen würde die Anfrage scheitern lassen, ohne die Ausgabe zu verändern.

Der Nachteil: Status 200 bedeutet nicht, dass jeder Parameter wirksam war. Sonnet 5.5 akzeptiert nur die Standardwerte für Sampling. Eine Anfrage mit temperature: 0.2 über Synthorai ist deshalb erfolgreich, kann die Zufälligkeit aber nicht verringern. Falls eure Ausgabe von einem Sampling-Wert abhängt, vergleicht die Ergebnisse mit und ohne diesen Wert anhand eurer eigenen Prompts. In der obigen Messung war der Effekt bei kurzen Antworten gering.

Was sollte vor dem Upgrade geprüft werden?

FAQ

Warum scheitert meine Claude-Anfrage mit „temperature: Extra inputs are not permitted“? Die Anfrage wurde mit anthropic-version: 2026-10-21 gesendet. In dieser Version gibt es den Parameter temperature nicht mehr. Deshalb führt jeder Wert zu HTTP 400, auch 1.0. Die neuen SDK-Hauptversionen senden diese Version standardmäßig. Entfernt den Parameter oder setzt für Anfragen mit abweichenden Werten explizit 2023-06-01, sofern das Modell diese Werte noch akzeptiert.

Wird anthropic-version 2023-06-01 eingestellt? Anthropic hat kein Enddatum für 2023-06-01 angekündigt. Weder die Migrationsanleitung noch die API-Release-Notes vom 21. Oktober nennen eines. Anfragen, die den Header explizit setzen, behalten das alte Verhalten bei. So lässt sich temperature für einzelne Anfragen an Claude Sonnet 4.6 weiterverwenden.

Akzeptiert die Anthropic API weiterhin den Header x-api-key? Die Anthropic API akzeptiert unter beiden Versionen sowohl x-api-key als auch Authorization: Bearer. Nur die SDKs haben geändert, welchen Header sie senden. Sind beide vorhanden, verwendet die API x-api-key.

Weiterführende Artikel

• Kosten von Claude Sonnet 5.5: Was das Modell im Vergleich zu Sonnet 5 kostet
• LLM-Denkprozesse steuern: Welche Reasoning-Einstellungen neuere Claude-Modelle akzeptieren
• OpenCode-Sicherheitsvorfall: API-Schlüssel schützen: Den möglichen Schaden durch einen geleakten Schlüssel begrenzen
• Ratenlimits für LLM-APIs: Wie Limits pro Schlüssel gezählt werden

← Zurück zum Blog