AIREITERHTTP 401 heißt zunächst nur: Der Server hat Zugangsdaten abgelehnt. Daraus folgt weder, dass dein Key-String falsch ist, noch dass ein 403 zwingend auf fehlende Berechtigungen hindeutet. Beide Anbieter verwenden diese Statuscodes auch dann, wenn die Zugangsdaten selbst völlig gültig sind. Eine Ausnahme solltest du allerdings zuerst prüfen: Gibt die Fehlermeldung einen maskierten Key zurück, dessen Anfang und Ende nicht zu deinem Key passen, hat der Server nicht die Zugangsdaten erhalten, die du senden wolltest.
Drei Ursachen, ein 401-Fehlerbild
Alle folgenden Fälle liefern HTTP 401 mit einem Authentifizierungsfehler, verlangen aber gegensätzliche Lösungen. Die Meldungen stammen von sechs Anfragen, die ich mit absichtlich ungültigen Keys an diese beiden Endpunkte gesendet habe. Da ein fehlerhafter Key abgewiesen wird, bevor die Autorisierung beginnt, brauchst du keinen echten Key, um das nachzustellen.
| Was tatsächlich passiert ist | Anthropic /v1/messages | OpenAI /v1/responses |
|---|---|---|
| Key kam an und wurde abgelehnt | API key is invalid. | Incorrect API key provided: sk-proj-**********-key. mit "code": "invalid_api_key" |
| Es kamen gar keine Zugangsdaten an | x-api-key header is required | Missing bearer or basic authentication in header |
| Zugangsdaten kamen im falschen Header an | Invalid bearer token | Missing bearer or basic authentication in header, identisch zur vorherigen Zeile |
Anthropic unterscheidet alle drei Fälle in der Meldung. Der OpenAI-Endpunkt liefert dagegen dieselbe Antwort, egal ob du gar nichts gesendet hast oder den Key in einem Header schickst, den der Dienst nicht auswertet. Deshalb kann bei einem Relay-Nutzer ein Fehler wegen eines fehlenden Headers erscheinen, obwohl der Key in der Shell nachweislich gesetzt ist.
Die Response-Header lösen diese Mehrdeutigkeit nicht vollständig auf, trennen aber einen abgelehnten Key von Zugangsdaten, die nie bis zur Autorisierung gelangt sind. Führe die sechs Aufrufe aus und lies die Header statt nur den Fehlermeldungstext:
show(){ shift; curl -sS -D - -o /dev/stdout "$@" \
| grep -iE "^HTTP|www-authenticate|x-openai-authorization-error|request-id|x-should-retry|message"; }
A=(-X POST https://api.anthropic.com/v1/messages -H "anthropic-version: 2023-06-01"
-H "content-type: application/json"
-d '{"model":"claude-sonnet-4-5","max_tokens":8,"messages":[{"role":"user","content":"hi"}]}')
O=(-X POST https://api.openai.com/v1/responses -H "content-type: application/json"
-d '{"model":"gpt-5.6","max_output_tokens":16,"input":"hi"}')
show a1 "${A[@]}" -H "x-api-key: sk-ant-api03-not-a-real-key" # rejected
show a2 "${A[@]}" # never arrived
show a3 "${A[@]}" -H "Authorization: Bearer sk-ant-api03-not-a-real-key" # wrong header
show o1 "${O[@]}" -H "Authorization: Bearer sk-proj-not-a-real-key" # rejected
show o2 "${O[@]}" # never arrived
show o3 "${O[@]}" -H "x-api-key: sk-proj-not-a-real-key" # wrong headerDas waren am 2026-07-31 die entscheidenden Zeilen, gekürzt auf die Felder mit abweichenden Werten:
o1 rejected HTTP/2 401 x-openai-authorization-error: 401 "code": "invalid_api_key"
o2 never arrived HTTP/2 401 www-authenticate: Bearer realm="OpenAI API"
o3 wrong header HTTP/2 401 www-authenticate: Bearer realm="OpenAI API"
a1 rejected HTTP/2 401 "request_id": null (no request-id, no x-should-retry)
a2 never arrived HTTP/2 401 request-id: req_011CdZnC9j… x-should-retry: false
a3 wrong header HTTP/2 401 request-id: req_011CdZnCDN… x-should-retry: falseBei beiden Endpunkten enthielt ein abgelehnter Key ein anbieterspezifisches Autorisierungsfeld, während der Challenge-Header fehlte. Wenn die Zugangsdaten die Autorisierung gar nicht erreichten, war es umgekehrt. Wiederholte Aufrufe zeigten dieselbe Trennung. Das ist jedoch eine datierte Beobachtung an zwei Endpunkten, kein dokumentiertes Verhalten. Verlass dich bei deinem Anbieter nicht darauf, sondern führe den obigen Block erneut aus. Landest du in der Kategorie „abgelehnt“, prüfst du auf der Key-Seite von OpenAI oder Claude vier Dinge: Leerzeichen vor oder nach dem Wert, einen gelöschten oder widerrufenen Key, einen Key für ein anderes Projekt oder eine andere Organisation als den angesprochenen Dienst sowie eine veraltete Kopie im Client-Cache. Erstelle erst dann einen neuen Key, wenn die ersten drei Punkte ausgeschlossen sind.
Welche Zugangsdaten deine CLI wirklich verwendet
Meldet eine Coding-CLI einen ungültigen Key, den du nach eigener Aussage nie eingerichtet hast, stammt er nicht zwangsläufig aus einem Cache. Wahrscheinlicher ist, dass eine höher priorisierte Quelle greift. Claude Code löst sechs Quellen in fester Reihenfolge auf. Diese dokumentierte Priorität bestimmt zugleich, über welchen Header die jeweiligen Zugangsdaten gesendet werden.
| Priorität | Quelle | Gesendeter Header |
|---|---|---|
| 1 | Cloud-Provider-Zugangsdaten (CLAUDE_CODE_USE_BEDROCK, _VERTEX, _FOUNDRY) | providerspezifisch |
| 2 | ANTHROPIC_AUTH_TOKEN | Authorization: Bearer |
| 3 | ANTHROPIC_API_KEY | X-Api-Key |
| 4 | Ausgabe des apiKeyHelper-Skripts | wie zurückgegeben |
| 5 | CLAUDE_CODE_OAUTH_TOKEN | OAuth |
| 6 | Abonnement-Login über /login | OAuth |
Ein gültiger ANTHROPIC_API_KEY hat Vorrang vor deinem Abonnement-Login. /login verdrängt ihn also nicht; mit dem Flag -p wird der Key stets verwendet, wenn er vorhanden ist. Anthropic empfiehlt: Zuerst in der Shell, aus der Claude Code gestartet wird, env | grep ANTHROPIC ausführen, danach /status prüfen und die Variable entfernen, falls du das Abonnement nutzen möchtest. Die env-Prüfung deckt nur die Zeilen 2 und 3 der Tabelle ab. Erst /status zeigt, ob als aufgelöste Quelle ein Cloud-Provider, ein Helper-Skript oder ein Login verwendet wird.
Der Key, den du angeblich nie gesetzt hast
Dieser Bericht zeigt ein typisches Muster:
"Claude is stuck in API billing mode even though there is no API env variable set and I have linked claude code to my pro max account successfully"
Ein Maintainer fragte als Erstes, ob ein apiKeyHelper konfiguriert sei. Das war der Fall, und dessen gesamter Inhalt gab PLACEHOLDER_NOT_IMPLEMENTED_ON_MAC_YET aus. Ein Helper, der Müll zurückgibt, mit einem Fehlerstatus endet oder nichts ausgibt, sendet einen Platzhalter als Zugangsdaten. Die API quittiert das mit einem 401, der den Key statt das Skript beschreibt. Claude Code meldet diesen Fehler inzwischen namentlich nach drei Versuchen. Derselbe Eintrag hält fest, dass Helper-Fehler vor v2.1.208 nach etwa zehn stillen Wiederholungen nur als allgemeiner 401 erschienen.
Auch Umgebungsvariablen können ohne bewusstes Zutun gesetzt werden: Anthropic nennt direnv, dotenv-Shell-Plugins und IDE-Terminals als Quellen, die einen veralteten Key aus einer projektbezogenen .env-Datei laden. Der Helper wird außerdem nach fünf Minuten oder bei einem HTTP 401 erneut aufgerufen. Ein defekter Helper taucht deshalb zeitgesteuert immer wieder auf.
Wenn die Base URL auf ein Gateway zeigt
Zeigt ANTHROPIC_BASE_URL auf ein LLM-Gateway, stammt der Text hinter dem 401 vom Gateway und nicht von Anthropic. /login kann daran nichts ändern. Umgekehrt gilt dasselbe für OpenAI-kompatible Clients, die auf ein Relay zeigen. Aus einem Codex-Bericht, dessen Fehlermeldung mit url: https://openrouter.ai/api/v1/responses endet:
"I tried clearing all the env variables related to api keys , tried deleting the auth file too didn't work relogged in many times error persists"
Lokale Zugangsdaten zu löschen kann das nicht beheben: Die Base URL entscheidet, wer die Anfrage bewertet. Der Key muss zum Dienst hinter diesem Endpunkt passen. Claude Code dokumentiert ANTHROPIC_AUTH_TOKEN für Gateways mit Bearer-Token-Authentifizierung. Legst du denselben Wert stattdessen in ANTHROPIC_API_KEY ab, wird er als X-Api-Key versendet – also gemäß Zeile drei der obigen Tabelle. Andere Clients folgen ihrem eigenen Vertrag; prüfe daher, welchen Header dein Client schickt. Claude Code on the Web ist die Ausnahme: Es verwendet immer die Zugangsdaten des Abonnements, und keine der beiden Variablen im Sandbox-Kontext überschreibt sie.
403-Fehler, obwohl der Key gültig ist
Die folgenden Fälle sind nicht selbst reproduziert, weil jeder von ihnen einen bestimmten Kontostatus oder Standort voraussetzt. Die Provider-Dokumentation ist jedoch eindeutig: Auch ein gültiger Key kann einen 403 auslösen.
OpenAIs Fehlerreferenz führt 403 - Country, region, or territory not supported auf. Das ist eine geografische Prüfung, der Key bleibt dabei unberührt. Zwei Zeilen darüber steht das Gegenstück: 401 - IP not authorized. Dieser Fehler tritt auf, wenn die IP-Adresse der Anfrage nicht auf der Allowlist des Projekts oder der Organisation steht. Der Key ist gültig, aber der aufrufende Client nicht.
Für API Error: 403 {"error":{"type":"forbidden","message":"Request not allowed"}} nach einem erfolgreichen Login nennt Anthropic drei Ursachen – und keine davon ist ein falsch eingegebener Key: ein inaktives Pro- oder Max-Abonnement, ein Console-Konto ohne die Rolle „Claude Code“ oder „Developer“ oder ein Unternehmens-Proxy, der die Anfrage beeinträchtigt. In der Platform API bedeutet 403 - permission_error, dass dem Key die Berechtigung für die angeforderte Ressource fehlt. Das wird anhand der Organisations- und Workspace-Einstellungen geprüft. An den Compliance-Endpunkten liefert ein gültiger Key mit falschen Scopes absichtlich 403 statt 401.
FAQ
Was bedeutet Fehlercode 403 in der Claude API?
Er kann zwei unterschiedliche Dinge bedeuten. permission_error heißt, dass dein Key keine Berechtigung für diese Ressource besitzt; das ist eine Einstellung auf Organisations- oder Workspace-Ebene. Request not allowed nach dem Login verweist dagegen auf den Abonnementstatus, eine fehlende Console-Rolle oder einen Proxy.
Lohnt es sich, einen 401 erneut zu versuchen?
Für sich genommen: nein. Abgelehnte oder fehlende Zugangsdaten liefern beim nächsten Versuch dasselbe Ergebnis. Anders als bei einem 429 ist hier kein Warten die Lösung; bei 429 hilft es, Retry-After zu beachten, bevor du den Backoff startest. Eine Ausnahme ist der Fall apiKeyHelper: Claude Code versucht ihn bereits noch zweimal, bevor der Fehler gemeldet wird.