← All articles

Claude Code API Error 500 & "Authorization Failed: Internal Server Error": Fixes

Fix Claude Code 'API Error: 500' mid-session and 'Authorization failed: Internal server error' at login: check status, recover OAuth, or use an API key.

UniRoute ·

Whether Claude Code blocks sign-in with "Authorization failed: Internal server error" or interrupts an active coding turn with "API Error: 500", the failure comes from the upstream authentication/API server or an intermediate gateway—not your prompt or project code. Match your scenario below for immediate recovery steps.

Scenario 1: Login Fails with "Authorization failed: Internal server error"

  1. Check status.claude.com: Inspect the claude.ai, Console, and Claude Code components first to see if Anthropic's OAuth endpoints are degraded.
  2. Run /login again (and wait a few minutes if OAuth is transiently failing): Running /login is the official fix for Login expired or OAuth token revoked (code.claude.com/docs/en/errors, 2026-10-27); for transient OAuth Internal server error responses, wait a few minutes before retrying /login.
  3. Handle browser callback or local listener errors by exact message: Per code.claude.com/docs/en/errors (2026-10-27):
    • If your terminal prints "The browser can't return the sign-in to Claude Code automatically", open the displayed URL in your browser and paste the authorization code into Paste code here >.
    • If your terminal prints "Couldn't start the local listener that receives the browser sign-in", run the same command again; if it still fails, sign in with a token or API key instead.
  4. Try another browser, disable proxy/VPN, and check /status: Complete the sign-in flow in a clean browser without a proxy or VPN, and run /status in Claude Code to check whether a stale ANTHROPIC_API_KEY environment variable is overriding /login (ANTHROPIC_API_KEY takes precedence over /login).
  5. Switch to API Key mode (skip browser OAuth): If web OAuth keeps failing, authenticate via ANTHROPIC_API_KEY or apiKeyHelper instead of /login:
    • Official Anthropic API Key: Create a key in the Anthropic Console and set export ANTHROPIC_API_KEY="sk-ant-...".
    • UniRoute API Key (one-command setup): Create a UniRoute API key and configure Claude Code without web OAuth. As of 2026-10-27, on UniRoute's discounted channel Anthropic Claude models are as low as 42% of official API rates (e.g., Claude Sonnet 5.5 is $0.84 / $4.20 per 1M input/output tokens vs. $2 / $10 official, and Claude Opus 5.5 is $1.68 / $8.40 vs. $4 / $20); when the discounted channel is unavailable, requests fail over automatically to the standard channel at official-level prices (how channels work; see current pricing and the Claude Code CLI setup guide):
      npx --yes --package=https://uniroute.app/community/uniroute-setup-0.1.2.tgz uniroute-setup models
      npx --yes --package=https://uniroute.app/community/uniroute-setup-0.1.2.tgz uniroute-setup configure claude --model MODEL_ID
      

Sources & background: While "Authorization failed: Internal server error" is not listed verbatim in the official Claude Code errors reference (as of 2026-10-27), users report this exact message during browser OAuth sign-in and token exchange in anthropics/claude-code Issue #36004 ([BUG] Authorization failed: "Internal server error" prevents Claude Code login) and Issue #10705 ([BUG] OAuth Request Failed Internal server error). The steps above combine the official login recovery steps (code.claude.com/docs/en/errors, 2026-10-27) with community workarounds.

Scenario 2: Mid-Session API Error: 500 During Coding

Per the official Claude Code errors reference (2026-10-27), the standard terminal message is:

API Error: 500 Internal server error. This is a server-side issue, usually temporary — try again in a moment. If it persists, check https://status.claude.com.

Anthropic notes that 5xx errors are unexpected internal API failures unrelated to your prompt, settings, or account. Follow these 4 steps:

  1. Check status.claude.com: Verify whether the API or Claude Code is experiencing an active incident.
  2. Wait a minute before retrying—do not loop-retry, and check usage first: Claude Code preserves your message (for long prompts, you can simply enter try again), but pause any automated retry loop and check whether the interrupted turn already modified local files or recorded token usage before resending.
  3. Gateway users (ANTHROPIC_BASE_URL set)—set ENABLE_TOOL_SEARCH=false: If ANTHROPIC_BASE_URL points to an LLM gateway and every request returns 500, run Claude Code with ENABLE_TOOL_SEARCH=false and test again (code.claude.com/docs/en/errors, 2026-10-27).
  4. Run /feedback if it persists with no status incident: When status.claude.com is green and direct requests still fail, submit /feedback from inside Claude Code.

Note on sustained upstream 5xx or overload: Because Claude overload depends on aggregate global server load, routing Claude Code through UniRoute (setup guide) dispatches requests to the most stable available regional capacity and automatically retries on another upstream if a 529 occurs before streaming starts (boundary: once streaming output begins, an active stream cannot be switched, and this does not guarantee zero overload or zero errors).


Still Not Fixed? Troubleshoot Step by Step

If your setup uses custom gateways, OpenRouter, or automated wrappers and the quick steps above did not resolve the 500, use the interactive triage tool below to isolate the exact failure layer. This guide covers Anthropic direct access, OpenRouter, and UniRoute—changing providers, replacing a key, or adding funds only helps when the evidence points to that specific problem.

Claude Code 500 Troubleshooting Helper

Select the active service, observed error status, and whether output or tool actions started to see the most important next step, stopping rules, and verification links.

Most important next stepCheck original request first

Execution progress is unknown: do not assume the request failed before running. Check service request logs, local workspace changes, and usage records by timestamp and model ID before trying again.

What this error means

Observed error is unknown: run /status inside Claude Code to confirm the active service address and model, then inspect that service’s activity records for the incident timestamp to find the recorded HTTP status and error category. Keep missing fields marked as unknown.

Service check & routing note

Destination service is unknown: run /status inside Claude Code and privately inspect ANTHROPIC_BASE_URL in .claude/settings.json or your shell environment. Confirm whether requests target api.anthropic.com, OpenRouter, or https://api.uniroute.app before checking account logs.

Gateway mapping remains unknown: gateways or proxies may remap or wrap upstream HTTP codes. A 500 returned by a gateway or terminal alone does not prove Anthropic generated an upstream api_error.

When to stop & billing note

Stopping condition: while original request acceptance, tool side effects, or token charges remain started or unknown, do not resend the prompt. Repeating a prompt can trigger a second generation and another charge; an error code or missing client summary does not guarantee zero cost.

Step-by-step checks
  1. Step 1 (Verify original request & side effects): record the incident timestamp (with timezone) and exact model ID, inspect your workspace for file edits or executed tool commands, and check the active service’s usage logs for completed or failed entries before resending.
  2. Step 2 (Confirm the active destination): run /status in Claude Code and privately check ANTHROPIC_BASE_URL to determine whether traffic goes to Anthropic, OpenRouter, or UniRoute before changing keys or checking bills.
  3. Step 3 (Reconcile or escalate privately): once original execution and usage are checked, if the failure persists or records remain unclear, send a sanitized summary (no keys, prompts, or full bodies) to the active service’s private support.

Options and troubleshooting calculations run in memory on this page—changing selections or resetting does not send or save your input, while clicking a documentation or console link navigates normally. Suggestions help order your checks and do not replace verifying the original request and billing records.

Identify the path and the error

Record claude --version in your terminal. Inside Claude Code, use /status to check the selected provider, model, and authentication. Review effective settings privately if the destination is unclear. The UniRoute setup tutorial explains its root Base URL and credential configuration; the OpenRouter setup guide covers that service's distinct address and key.

Save the observed HTTP status and structured error category when available. A client summary, a gateway response, and an upstream response are different observations; a gateway's 500 alone does not establish that Anthropic generated it.

Error triage table

These pairs follow the Anthropic API error reference. Gateways may use different mappings.

Observed status or symptomMeaning to distinguishFirst action
401, authentication_errorCredential problemVerify the destination's key locally.
402, billing_errorBilling problemCheck billing with that service.
403, permission_errorResource access deniedCheck model and route permissions.
429, rate_limit_errorRate or spending limitRead the specific limit and retry guidance.
500, api_error on AnthropicInternal service failureCheck status, then use bounded backoff.
529, overloaded_error on AnthropicTemporary overloadReduce concurrent submissions, switch models, or see the Claude API 529 overloaded error guide.
504, timeout, or disconnectIncomplete observationCheck request state before resending.
HTTP 200 followed by a stream errorStream failed after startingInspect stream events and usage.

Save the request-id header or body request_id privately. Streams can fail after HTTP 200. Other services may omit these identifiers.

For stream idle timeout - partial response received, follow the Claude stream timeout guide for event timing, a local SSE probe, and checks before retrying. For Repeated 529 Overloaded errors or overloaded_error, see the Claude API 529 overloaded guide.

Work through one request, in order

Use one incident as the reference. A timestamp with its timezone and an exact model ID help distinguish it from parallel requests, automatic retries, and other team activity.

Investigation and recovery table

CheckWhat to doEvidence and stopping point
Service statusRead Claude status or OpenRouter status for the destination. For a UniRoute route, also check its error record and support response.Record the incident window. A green status page does not rule out a route-specific fault.
Effective destinationCheck /status, the model, and settings scope. Use the documented Base URL for that provider.If the destination is wrong, fix only that configuration. Keep a private backup before persistent changes.
Failure detailsMatch the error time to the request, HTTP status, and any separate upstream status.Keep unavailable fields as unknown. A gateway status and upstream status may differ.
Retry ownershipIdentify whether Claude Code, an SDK, a proxy, or your wrapper already retries.Choose one owner for any additional retry policy. Stop a repeating wrapper before diagnosing.
Stream progressNote whether output or a tool action already started.Inspect changes and usage first. Do not blindly replay a task that may have modified files or external systems.
Controlled recoveryAfter the service recovers or a configuration issue is corrected, consider one short request without private project content.This is a new billable request. Confirm destination, budget, and prior request state first.
Persistent failureRetain a sanitized summary and contact the service handling your request.Stop when the retry budget expires or the original outcome remains uncertain.

For installation or configuration problems, start with Claude Code troubleshooting, which points to the relevant error and settings references. Run /doctor for a local diagnostic when appropriate; review any proposed changes before applying them. You do not need to delete a working login to investigate a 500.

Read the structure without sharing the body

This is a synthetic illustration of an Anthropic-shaped error, not a captured UniRoute incident or a reproduced production failure:

{
  "type": "error",
  "error": {
    "type": "api_error",
    "message": "Illustrative server failure"
  },
  "request_id": "req_example_only"
}

Use the structure to distinguish the category from the human message. Do not copy complete response bodies into a public issue: they can contain private text. An HTML proxy error page, missing category, or missing ID needs a different investigation; do not invent the fields in this example when they are absent.

Set a retry limit before retrying

The official TypeScript SDK reference describes two automatic retries by default for certain connection, rate-limit, and server errors. Its maxRetries option can change or disable that behavior. This SDK setting is not a universal Claude Code terminal switch; check the actual client's behavior and version.

For a wrapper you control, a reasonable starting policy is at most two additional attempts for a confirmed transient failure, with increasing delays and jitter, within a fixed elapsed-time and spending budget. Honor a valid server retry instruction. This is a suggested application policy, not a guarantee that a request is safe to repeat. Do not layer it on top of an SDK policy without accounting for the resulting total attempts.

Stop immediately for an authentication, permission, or unresolved billing error and correct its cause. Stop when the same transient fault persists past your limit. For interrupted output or uncertain tool execution, investigate the original work before authorizing a fresh attempt. Repeating a prompt can create another generation and another charge; a request identifier is not an idempotency guarantee.

Reconcile usage and charges

For a UniRoute request, open your usage records. Select the relevant time range and inspect successful and failed entries. A successful entry may be relevant even when the terminal later reported an interruption. Compare the available model, time, request identifier, usage, and actual cost; not every error entry contains all of them.

Request and spending reconciliation table

What you observedWhat to checkWhat remains unknown without more evidence
Client stopped before a confirmed responseClient time, gateway records, and any completed requests nearbyWhether the upstream accepted or processed the request
Explicit rejection before generationRecorded reason, matching error entry, and any related successful attemptsThe charge state of separate retries
Partial answer or interrupted streamSuccessful and failed records, observed tokens, and recorded actual costUnreported usage or the final outcome of an incomplete record
Completed reply but a later client errorMatching completed request and its actual chargeWhether a subsequent request caused the displayed error
Missing record or missing actual costCorrect account, provider, timezone, filters, and support lookupFinal consumption and settlement; absence is not a zero-dollar bill

Use the rate and accounting rules for the matching request. The Claude Code API cost guide explains ordinary input, output, cache writes, and cache reads. A client estimate or a wallet balance difference is insufficient to attribute one charge when several requests are active. A key's spending allowance is also separate from wallet funds.

If the original outcome is unknown, keep that label. Do not infer a refund or zero consumption from an error code. For OpenRouter or Anthropic direct requests, use that service's own activity and billing records; UniRoute cannot show those private account records.

Prepare a useful support report

In UniRoute, open the relevant usage detail and use its diagnostic summary when available. Review the copied fields before sending them. Include your client version and whether output appeared, since the service record alone may not establish what the terminal displayed. Missing HTTP status, request ID, or error type should remain unknown.

For a private support ticket, this minimal format is enough to begin:

Client and version: Claude Code, version observed locally
Time and timezone: incident time, with timezone
Provider and endpoint path: selected service, /v1/messages
Model: exact selected model ID
Observed HTTP status / error category: observed values, or unknown
Request ID: if available; private support only
Stream progress: no output / partial output / completed reply / unknown
Retry attempts: observed count, or unknown
Usage and actual charge: matching record values, or unknown

Do not include a key, authorization header, cookie, full configuration file, prompt, project content, or complete response. Keep private identifiers out of public screenshots and issue reports. If you must report publicly, remove the request identifier and send it separately through the provider's private support channel.

For requests handled by UniRoute, send your reviewed summary to support@uniroute.app, the support address linked in this site's footer. For configuration questions, use the Claude Code connection tutorial; for budgeting, use the API pricing and actual usage guide.

Adding funds is relevant to a confirmed funds problem in the correct account. It is not a general fix for server error 500. Recover by identifying the request path, resolving the specific failure, and checking what actually ran before sending the task again.