API Error: 500 is what Claude Code prints when the request it sent to Anthropic came back as a server failure. It lands mid-task, without warning, and the first thing most people want to know is whether they caused it.
A 500 from Claude Code is a failure inside the API the tool is talking to, which is Anthropic’s own API unless the trailing sentence names another provider or a gateway (see below), and Anthropic’s error reference states plainly that it is not caused by your prompt, settings, or account. The work already on your disk usually survives it. Claude Code retries a transient failure up to 10 times before the message ever reaches you.
The error text, the retry rules and the recovery steps below come from five Anthropic pages read on 25 August 2026: Claude Code’s error reference, its troubleshooting page, its checkpointing page, the Claude API error list, and the Claude status page. No error was triggered on purpose to produce them, and no reading of a status page, this one included, is worth much an hour later.
Who this lands on is worth saying out loud. One person, describing how their team works, wrote: “None of us are developers, but we have been using Claude Code for a few months now for documents, our website and small internal tools.” When the terminal stops for them, there is no second way in.
What a 500 from Claude Code actually is
The Claude Code error reference covers the whole 5xx family in one line: “Claude Code shows the status code and the API’s error message for any 5xx response.” On the Anthropic API, the 500 case prints like this:
API Error: 500 Internal server error. This is a server-side issue, usually temporary ...The rest of that line, cut here, tells you to try again in a moment and to check the status page if it keeps happening. Which status page it names is not fixed. Anthropic’s own wording is that “The trailing sentence names where to check service health and varies by provider”: an Amazon Bedrock, Google Cloud’s Agent Platform or Microsoft Foundry setup names that provider’s service status instead, and a custom ANTHROPIC_BASE_URL names the gateway host. That detail decides where you look, and a reader who goes to Anthropic’s status page while their message named a gateway host will read a green page about a service they are not calling.
Then the sentence that answers the first question: “This indicates an unexpected failure inside the API. It is not caused by your prompt, settings, or account.”
Four different situations produce a 500 or its close relative in this terminal, and they are not equally bad.
| What just happened | What Claude Code prints | Where the fault sits | What it does to work on disk |
|---|---|---|---|
| An unexpected failure inside Anthropic’s API | API Error: 500 Internal server error ... | Anthropic | Nothing, as long as the failure arrived before Claude started answering |
| Capacity is full across every user on that model | API Error: Repeated 529 Overloaded errors ... | Anthropic, and everyone else on the same model | Nothing. Claude Code has already retried several times before it prints this |
| A failure on the route between you and the API | The same 500 text, with the trailing sentence naming your gateway host rather than Anthropic’s status page | The gateway, proxy or provider your ANTHROPIC_BASE_URL points at | Nothing, but the status page you go and check is the wrong one |
| A failure that lands after Claude has already started answering | API Error: Server error mid-response. The response above may be incomplete. | Anthropic, at the least convenient moment | Real changes. Any tool call Claude finished before the error has already run |
The last row is the one this page spends its time on. The other three cost you a wait.
How to tell an Anthropic outage from something on your machine
Start at the status page the error’s trailing sentence names. For a direct Anthropic setup that is Anthropic’s status page; for Bedrock, Google Cloud, Foundry or a custom gateway it is that provider’s page, and Anthropic’s will tell you nothing. Read the component list rather than the banner. On 25 August 2026 that page returned a 200 and the banner said “All Systems Operational”, above six separately tracked components with their own 90-day uptime figures: claude.ai at 99.35%, Claude Console at 99.86%, Claude API at 99.45%, Claude Code at 99.37%, Claude Cowork at 99.46% and Claude for Government at 100.0%.
Six rows is the useful part. “Claude” on that page is six products, and the two that decide whether your terminal works are the row named Claude Code and the row named Claude API, because the tool in your terminal is a client of that API. A green claude.ai row says nothing about either.
The incident list on the same page, on the same day, carried resolved entries from 24 August 2026 and 20 August 2026, two of them named for models rather than for products: “Elevated errors for multiple models” and “Elevated errors on requests to multiple models”. A fair number of these end on that incident list, so read it before you start pulling your own setup apart.
Green is not proof, though. A component can read operational while one model is under enough load to fail your requests, which is why Claude Code has a message for that case specifically and offers to move you to a different model.
If the status page is clean, the next surfaces are local. The troubleshooting page points at one command for the whole class: run /doctor inside Claude Code “for an automated check of your installation, settings, extensions, and context usage”. If claude will not start at all, the same page says to run claude doctor from your shell instead. It also says to run /mcp to check MCP server status, because a connected server that drops out mid-session fails in a way that looks nothing like a 500 and gets blamed on one anyway.
Then the honest limit. As of 25 August 2026 nothing Anthropic publishes tells you how long an incident will run. The error reference’s own instruction for a 500 is “Wait a minute, then send your message again”, and for repeated 529s it is “Try again in a few minutes”. No page read here gives an expected duration, and the status page posts incidents rather than estimates.
One complaint that arrives at this same search is a different complaint. Someone writing about their own sessions put it this way: “it as if it has been compacted 100 times and never cleared. it fails to do tasks that 4.8 were able to do very easily”. That is a judgement about the quality of answers, not a status code, and no component list will settle it either way.
Two neighbouring questions have their own answers. Lovable, Replit, Base44 and Bolt each publish their own component list, and working out whether the tool itself is down before you take your own project apart is a different reading from this one. And none of this is about a published app going dark: the order of the first hour when the app itself is dark is not the order of this page.
Did the 500 cost you your work?
Work lost to a 500 is the exception, and what survives is documented rather than lucky. Your original message stays in the conversation. A failure that lands mid-response is deliberately not retried, and Claude Code keeps every block Claude had already finished, including the tool calls that had already run.
Take those in order, because they answer three different worries.
The prompt is the easy one. The error reference says so directly: “Your original message is still in the conversation, so for a long prompt you can type try again instead of pasting the whole thing.” A long instruction you spent twenty minutes building is not gone.
The second point is the one nobody writing about this query explains. Claude Code retries most transient failures, but there is a documented exception, and it covers the exact case where a retry would be dangerous. The page lists what it will not retry: “A server error, dropped connection, or stalled stream that arrives after Claude has completed a block of text or a tool call, or has started one after finishing its thinking, but before it finishes the response.” The reason sits in the same section: “Re-sending the request could run the same tool calls twice, so Claude Code keeps the output Claude completed and appends this notice instead of discarding the turn.” What lands on screen is this:
API Error: Server error mid-response. The response above may be incomplete.That behaviour needs Claude Code v2.1.199 or later. Before that version the same case discarded the partial output and reported the whole turn as an error, which is why older accounts of this error read as though everything vanished.
You can pick the turn back up. The instruction is to reply with continue, and Claude carries on from its last completed block. Read what is still on screen first, because Claude Code keeps every block Claude completed before the error but discards an interrupted final block when the turn ends, so the last sentences or tool calls may simply not be there.
The third point is what turns this from an annoyance into something worth checking.
Claude Code still runs any tool calls Claude completed and continues the turn from their results.
Those tool calls include the ones that write to your files. A 500 that lands halfway through a turn can leave a real, half-finished change on disk, and the notice on your screen tells you the response may be incomplete, not the edit. That is the thing to check before you re-send anything.
A separate scare belongs here too, because it looks worse than it is. If the terminal itself dies, the conversation is not gone: “Restarting doesn’t lose your conversation. Run claude --resume in the same directory to pick the session back up.”
None of that covers the other kind of undo. A builder like Lovable or Replit keeps its own record of what the AI changed, and undoing an AI change in the builder’s own history is a different surface from a checkpoint in a terminal.
When the edit landed halfway
Claude Code takes a snapshot of your code before every prompt you send, which is what makes a half-applied edit recoverable at all. The checkpointing page sets the terms: “checkpointing automatically captures the state of your code before each user prompt”, every prompt creates a new checkpoint, file snapshots for the 100 most recent checkpoints in a session are kept, they are saved with the conversation so /rewind still works after you resume a session, and they are deleted along with sessions after 30 days.
- 01 Read the response still on screen before you type anything. It names which tool calls finished, and those are the ones that already touched files.
- 02 Run
/rewind, or pressEsctwice while the prompt input is empty, to open the rewind menu. - 03 Pick the prompt you want to go back to, then choose an action:
Restore code and conversation,Restore conversation,Restore code, orNever mindto back out. The two code options appear only when that checkpoint has tracked file changes to revert. - 04 Read the line that comes back. A restore that skipped files says so, in the form
Restored the code, but skipped N files. - 05 Check
git statusor your editor's diff view before you re-send the prompt. What a checkpoint restored and what your version control shows can disagree, and the three reasons why are below.
The first gap is the shell. Anthropic’s own line is “Checkpointing does not track files modified by bash commands”, and the page adds that only direct file edits made through Claude’s file editing tools are tracked. A file the assistant deleted, moved or copied from a shell command therefore sits outside everything the rewind menu can reach. How much of your working tree that covers depends on which commands Claude Code can run without asking you first, which is a setting you chose long before the 500 arrived.
The second gap is subagents. When work runs in a subagent, the checkpointing page is blunt: “rewinding doesn’t restore the edits. Use git to revert them.” The exception is narrow. A forked skill running in the foreground edits your working tree during your own turn, so a rewind covers that one; anything running in the background does not.
The third gap is links. A restore skips any tracked path that is a symlink or a hard link, prints the Restored the code, but skipped N files warning, and leaves those files with the contents they have now. Two ordinary setups land here: config files a dotfile manager symlinks into a project, and files pnpm hard-links into place.
Anthropic frames the whole feature the same way: “Checkpoints are designed for quick, session-level recovery.” For anything you would be upset to lose, the answer is the boring one, and a commit before a long session costs nothing. When a rewind comes up short, putting the code back to a state you know worked is the wider version of the same move.
The tempting alternative is to describe the half-finished state to the same assistant and ask it to put things back. Sometimes that works. Asking the same tool to fix what it just broke has its own success rate, and it is worth knowing that rate before you spend an afternoon finding out.
500, 529 and 429 are three different stops
The terminal message is one half of the picture. The Claude API error list is the other, because it names each code and says what the API expects a client to do about it.
| Code | What Anthropic calls it | What it is telling you | What to do |
|---|---|---|---|
| 500 | api_error | ”An unexpected error has occurred internal to Anthropic’s systems.” | Retry with exponential backoff. If it persists, contact support with the request ID |
| 529 | overloaded_error | ”The API is temporarily overloaded.” Anthropic adds that these “can occur when the API experiences high traffic across all users” | Wait a few minutes, then run /model and switch, since capacity is tracked per model |
| 429 | rate_limit_error | A rate limit, a tier spend cap, or a spend limit on the Claude Code workspace. A ceiling rather than a fault | Read the line for a reset time, and treat it as a question about allowances |
Two things in that table are easy to misread.
The first is the quota question, and it needs stating as an absence rather than as reassurance. As of 25 August 2026 the Claude Code error reference says of a 529 that “A 529 is not your usage limit and doesn’t count against your quota”, and says nothing of the kind about a 500. Anthropic has published no equivalent statement for the 500 case on the pages read here, which is not the same as a promise that a failed request costs you nothing.
The second is the 429. It is a limit rather than a failure, it usually carries a reset time inside the line, and that reset time is the tell. A stop that names a clock is your allowance ending rather than Anthropic failing, and which allowance ran out, and when it refills, is answered by your plan rather than by this page.
If you also run an app of your own against the Claude API, these codes have a second life in your server logs. Handling the same codes arriving in your own server logs under a traffic spike is a different job from reading one in a terminal.
One field carries over from the API to a support conversation. Every API response includes a unique request-id header, and the same value comes back in the body of an error as request_id. It is the thing Anthropic’s own instruction for a persistent 500 asks you to bring with you.
How long to wait, and when it is not going to clear
The error on your screen is already a second opinion. “Claude Code retries transient failures up to 10 times with exponential backoff before showing you an error”, so by the time you read the word 500, the tool has tried and failed repeatedly without saying anything. That is worth holding on to, because the instinct is to hammer the same prompt. The one exception is a 500 that arrived mid-response: those are not retried, and the next move is to inspect what landed on disk and continue from there, as the recovery section below sets out.
Two environment variables change that budget, and neither is a fix for an outage. CLAUDE_CODE_MAX_RETRIES sets the number of retry attempts. CLAUDE_CODE_RETRY_WATCHDOG, set to 1, is documented for unattended sessions such as CI jobs, where it keeps retrying capacity errors instead of failing after the normal budget, with one exception the same page states plainly: “Claude Code fails at once on a 429 that reports a spend limit or exhausted usage credits”. Turning the first one down is the more useful move for a person sitting at a terminal, because it surfaces failures faster instead of hiding them behind minutes of backoff.
The published waits are short and vague, and they are all there is. A 500 gets “Wait a minute, then send your message again”. Repeated 529s get “Try again in a few minutes”. Neither page read here gives an expected duration for an incident, so the honest planning assumption is that you do not know, and a wait you cannot size is a good reason to go and do something else for half an hour.
When it does not clear and no incident is posted, the error reference’s instruction is to run /feedback “so Anthropic can investigate with your request details”. Know what that sends before you send it. A submitted transcript is retained far longer than a normal session and can carry file contents with it, and what a feedback submission actually sends is worth two minutes of reading on a repository with anything sensitive in it.
It does occasionally get bad enough that the answer is nothing you can do. An issue on the Claude Code repository titled [Bug] API Error 500 on every prompt - Claude Max completely unusable was opened on 25 February 2026 and closed as a duplicate of issue 28602. A total, every-prompt failure has happened, and that one was folded into a wider report rather than tracked on its own.
What a Claude Code 500 does not touch
Your deployed app keeps serving. A 500 in a terminal stops the assistant from writing code, and it does not reach the hosting, the database or the payment provider the app you already published runs on. Nobody using that app sees a thing from the terminal error itself. The one case to check separately is an app that calls the Claude API at runtime: a provider-wide incident can affect those calls, and that is a dependency of your app rather than of your terminal.
That gap is wider than it feels while the terminal is red. One person who builds this way described their site as running on more than the part Claude Code produced with them, which is the accurate picture: the assistant wrote some of the code, and everything that code sits on belongs to other services with their own status pages and their own bad days.
Which leaves the honest question of when somebody outside is worth calling. Not for an Anthropic incident. Nobody outside Anthropic can shorten one, and anyone offering to is selling you a wait you were going to have anyway. The call is worth making for the other thing: the app that has been sitting broken since an edit landed halfway, where the rewind came up short and every prompt since has made the change harder to read.
If the stopping is the pattern rather than the exception, the question changes shape again, and what else there is, if a whole week of this is the pattern is a fair thing to look at. People also ask whether ChatGPT’s coding tools stop the same way, and how the two tools compare when something breaks is its own comparison.
Common questions about a Claude Code 500
What does API Error 500 mean in Claude Code?
It means the request Claude Code sent to Anthropic’s API failed inside Anthropic’s own systems. The error reference calls it an unexpected failure inside the API and says it is not caused by your prompt, settings, or account. The API’s own name for the code is api_error. In most cases it is temporary, and the documented first move is to check the status page and send the message again after a minute.
Is Claude Code down, or is it just me?
Anthropic’s status page tracks Claude Code as its own component, separately from claude.ai and the Claude API, so the row to read is the one named Claude Code, together with the Claude API row, because the terminal tool is a client of that API. If both are green and your requests still fail, the next checks are local: /doctor inside Claude Code, claude doctor from your shell if the tool will not start, and /mcp for connected servers.
Did I lose my work when Claude Code returned a 500?
Usually not. Your original message stays in the conversation, so a long prompt does not have to be typed again. If the failure landed after Claude had already completed part of the response, Claude Code keeps what was finished and appends a notice saying the response above may be incomplete. The case worth checking is your files, because any tool call that finished before the error has already run.
What is the difference between a 500 and a 529 in Claude Code?
A 500 is an unexpected failure inside the API, which Anthropic names api_error. A 529 means the API is temporarily overloaded, named overloaded_error, and Anthropic says these can happen when traffic is high across all users. A 529 also reaches you only after Claude Code has retried several times, and switching model with /model can get you moving again because capacity is tracked per model.
Is a 500 the same as hitting my usage limit?
No. A usage limit usually prints a line with a reset time in it and names which ceiling you reached, with one exception Anthropic documents on the API side: a tier spend-cap 429 “has no retry-after header and keeps failing until access resumes”. A 500 carries no reset time, no ceiling and no reference to your plan. If the message in front of you names a clock, you are reading a limit rather than a server failure, and the answer to that one is about allowances rather than incidents.
Does a 500 use up any of my usage?
Anthropic has not published an answer for the 500 case. As of 25 August 2026 the Claude Code error reference states that a 529 is not your usage limit and does not count against your quota, and it makes no equivalent statement about a 500. Treat that as an absence in the documentation rather than a guarantee in either direction.
Should I retry, or wait?
Wait first, unless the failure landed mid-response. Claude Code has already retried a request that failed before any answer began, up to 10 times with exponential backoff, so an immediate re-send repeats work the tool has just finished doing. A 500 that arrived while Claude was already answering is not retried: read what is on screen, check the disk, then continue rather than re-send. The documented instruction for a 500 is to wait a minute and send the message again, and for repeated 529s to try again in a few minutes and switch model in the meantime.
What do I do if an edit landed halfway?
Read what is still on screen to see which tool calls finished, then open the rewind menu with /rewind, or by pressing Esc twice on an empty prompt, and restore the code to the checkpoint before that prompt. Check the result afterwards, because a rewind does not cover files changed by a shell command, most subagent edits, or symlinked and hard-linked paths.
Does a Claude Code 500 take my live app down?
No. Claude Code talks to Anthropic’s API from your machine. Your published app runs on its own hosting, database and services, and a failed request in your terminal never reaches any of them. The two meet in two cases only: an incomplete edit that had already been deployed, which is a separate problem with a separate fix, and an app that itself calls the Claude API at runtime during a provider-wide incident, which is a runtime dependency to check on its own.
Where do I report a 500 that will not clear?
Run /feedback inside Claude Code, which is the documented route for a persistent error with no posted incident. Keep the request ID: every API response carries a unique request-id header, the same value appears in the body of an error, and Anthropic’s instruction for a 500 that persists is to contact support with it.
Built it with AI. Can’t get the last part right?
That’s the normal state of an AI-built app, and it’s fixable. I trace what the app actually does, explain what needs changing, and build it if you want me to.
Talk about your app → 
Free 20-minute video call with Bilal.