← BASELOAD English

Every Claude Error Message, and How to Fix It

August 26, 2026 · 68 min read 한국어 원문

When Claude gives you red text instead of an answer, you want the fix — not an essay. This page is a lookup table: find the exact wording on your screen, get the answer in the first line of that section.

The three most common ones, answered up front.

Start with one distinction, because it trips up almost everyone: those first two look similar and call for opposite actions. The next two sections separate them.

Photo by Pixabay on Pexels

”This response didn’t load” — check the status page before you wait

Answer first: don’t just retry. Open status.claude.com first.

You get a grey placeholder where the answer should have been. It usually appears after a reply has already started rendering.

This string isn’t catalogued in Anthropic’s official error documentation. And critically, it tells you nothing about the cause — you can’t tell a transient hiccup from a live incident by looking at it. Anthropic’s own incident notices describe symptoms in exactly these terms, e.g. users “may experience errors … completing chats with Claude” (sample incident). So unlike the capacity message below, rule out an outage first.

In order:

1. Check status.claude.com. If there’s an active incident, waiting is the only move.
2. No incident? Resend. It may be a transient network or streaming failure.
3. Still repeating? Try the same prompt in a fresh conversation. That tells you whether the problem lives in one conversation’s state.

”Due to unexpected capacity constraints…” — this one is not an outage

Answer first: wait two or three minutes and send the same prompt again. No need to start a new chat or log out.

“Due to unexpected capacity constraints, Claude is unable to respond to your message. Please try again soon.”

Anthropic’s support documentation is unambiguous about what this is. The system is working; demand across all users is simply spiking, and the platform is shedding load. The wording is explicit:

“These are not outages—the system functions normally while managing demand.”

Here’s where this diverges sharply from the previous section. The docs state that capacity constraints do not appear on the status page:

“Capacity constraints won’t appear on the status page because they represent normal load management rather than technical problems.”

So checking the status page for this message gets you nothing. Flip that around and it becomes useful: if there is a notice on the status page, what you’re hitting is not a capacity constraint — it’s a separate incident.

If it keeps repeating, switch models. Capacity is tracked per model, so Opus can be saturated while Sonnet is wide open. The docs’ only prescription here is “retry in a few minutes”; model switching is what they recommend for 529s specifically.

The “5-hour limit” family — waiting is the only fix

Answer first: wait until the reset time shown. The one exception is an Opus-specific limit, where switching models keeps you working.

Three different messages relate to plan usage. They read similarly but mean different things.

A common misconception: session and weekly limits are quota attached to your account, so refreshing, logging out and back in, or switching browsers changes nothing.

Switching models usually doesn’t help either. The official docs put it plainly:

“Session and weekly limits are shared across all models, so switching models won’t restore access.”

One exception. If you hit You've hit your Opus limit — an Opus-specific cap — then /model to Sonnet or another model lets you keep going.

To raise the ceiling you upgrade the plan or buy usage credits. On Pro and Max, /usage-credits purchases additional usage.

”Your message will exceed the length limit” — split the conversation

Answer first: start a new conversation, or attach less.

“Your message will exceed the length limit for this chat. Try attaching fewer or smaller files or starting a new conversation.”

This isn’t a server problem. Your input exceeded the model’s context window. Every turn resends the whole conversation, so headroom shrinks as the chat grows.

Pick one:

• Split long documents. Feed them chapter by chapter instead of all at once.
• Summarise and carry over. Move the conclusions into a fresh chat — context preserved, length reset.
• Start over. The most reliable option.

In Claude Code it’s one command. /compact compresses the history, /clear starts fresh, and /context shows how full you are.

Login failures — kill the VPN and the extensions first

If login throws a vague error, the cause is almost always one of three:

1. VPN — turn it off and retry
2. Browser extensions — ad blockers and script blockers especially
3. Cache and cookies — stale credentials colliding

If none of that works, check status.claude.com for a login-related incident.

Photo by Luca Bravo on Unsplash

API error codes — the number tells you whose problem it is

Answer first: 4xx is yours to fix, 5xx is yours to wait out. 429 splits two ways, covered below.

Source: Claude API errors

Confusing 429 with 529 sends you down the wrong path

They look alike on screen and have opposite causes.

• 429 is you. Your organisation exceeded its per-minute limit or hit a spend cap. Slow down, or negotiate a higher limit.
• 529 is not you. Anthropic’s servers are saturated across all users. Reducing your own traffic changes nothing. Wait, or switch models.

One trap worth knowing: a 429 caused by the tier’s monthly spend cap carries no retry-after header. It will keep failing until access resumes, so retry logic alone will quietly pile up failures. Use the presence of that header to tell the two kinds of 429 apart.

Also: ramping usage sharply can trip acceleration limits and produce 429s. Increase traffic gradually.

Request size limits

If you got a 413, check against this.

Claude Code errors you’ll actually hit

Answer first: most of these end with /login, /compact, or /clear.

The terminal surfaces a different vocabulary of errors.

Source: Claude Code error reference

When a response cuts off, don’t ask again

The response above may be incomplete appears in four situations. The exact strings:

• Server error mid-response — a 5xx while streaming
• Connection lost mid-response — the connection dropped
• Your computer went to sleep mid-response — your machine slept
• The response stopped arriving — the stream stalled and the idle watchdog cut it (byte-level watchdog: 180 seconds on the direct Anthropic API, 300 elsewhere)

Plenty of people re-ask from scratch here, which wastes tokens. Completed blocks are still on screen, and replying continue resumes from the last one.

Diagnostic commands and environment variables

When something keeps recurring, check state first. These are slash commands you type inside a Claude Code session — typing claude /status in your shell just passes that string as the opening prompt.

Version checks belong in the shell:

claude --version
claude --debug     # verbose logs, written to ~/.claude/debug/<session-id>.txt

To tune retry behaviour:

For developers — handling errors in code

Three habits cover most of it.

Use the official SDK. It retries connection errors, rate limits, and 5xx with exponential backoff — twice by default — and honours retry-after when present. There’s rarely a reason to hand-roll retry logic.

Catch types, not strings. The SDKs raise typed exceptions: a 404 is anthropic.NotFoundError in Python, Anthropic::Errors::NotFoundError in Ruby. Matching on message text breaks the moment wording changes.

Log the request_id. Every response carries a request-id header, and the same value appears in the error body. Support resolves issues far faster with it.

{
  "type": "error",
  "error": {
    "type": "not_found_error",
    "message": "The requested resource could not be found."
  },
  "request_id": "req_011CSHoEeqs5C35K2UUqR7Fy"
}

For long work, prefer streaming or batches. Some networks drop idle connections, so a non-streaming request with a large max_tokens can fail without ever returning. If you expect to exceed ten minutes, look at the streaming Messages API or the Message Batches API.

Common questions

Why does the same error read differently in the web app, the desktop app, and the terminal? Because the surfaces phrase things differently. Web and app give you a human sentence (Due to unexpected capacity constraints...); the API and Claude Code give you a number (529). Those two are the same overload. But some displays, like This response didn't load, don’t name a cause at all — that could be capacity or an outage, which is why the status page comes first there. Group by cause, not by wording.

Can I get around a limit with a second account? The terms explicitly prohibit sharing accounts, API keys, or credentials, and the usage policy prohibits evading a ban with a different account. Multi-accounting purely to dodge a usage cap doesn’t land squarely on either clause, but it’s a grey area. Usage credits or a plan upgrade is the safe route.

Does switching models reset my limit? It depends which limit. Session and weekly limits are shared across all models, so switching doesn’t help. An Opus-specific cap is different — /model gets you working again. And 529 capacity is tracked per model, so switching genuinely works there.

Is it safe to just auto-retry everything? Mostly, with one exception. As noted, a tier monthly spend cap 429 has no retry-after and keeps failing. Infinite retries just fill your logs. Be careful with CLAUDE_CODE_RETRY_WATCHDOG=1 in CI.

I keep seeing “your computer went to sleep.” Long responses die when your laptop sleeps mid-stream. For long jobs, disable sleep temporarily. If it already happened, continue picks it back up.

The order to work through

When you can’t find your exact message, work down this list. The earlier steps are cheaper to check.

One misconception to close on. Red text doesn’t mean Claude is down. Capacity constraints aren’t outages, a 5-hour limit is the system working as designed, and a 529 usually clears in minutes. Real outages show up on the status page — checking there first saves more time than anything else on this page.

Sources

• Troubleshoot Claude error messages — Anthropic Help Center; usage, length, login, and capacity errors
• Claude API errors — HTTP codes, size limits, SDK exceptions, request IDs
• Claude Code error reference — CLI errors, diagnostics, environment variables
• Claude status page — live incident notices
• Related: How to check Claude’s status in under a minute