Claude Outage Fallback: Request Failed, Files Still Changed

by

If Claude goes down in the middle of an agent task, you can switch to Codex for reading and analysis right away. If the agent was editing files, run git status and git diff first. A failed response can still leave changed files, and a second agent that doesn’t know about them starts on top of a half-done change.

A Claude outage fallback is the plan for where your coding work goes when Anthropic’s API or Claude Code stops answering. I used to think that plan was one line: if Claude dies, use Codex.

I dropped that idea after the September 3, 2026 outage, once I learned a failed response can leave edited files behind. Fallback, for me, is less about picking the next model and more about recovering what the first one already changed.

On this page
  1. My two outages: September 3 and September 29
  2. Should you switch from Claude Code to Codex during an outage?
  3. Why a failed response can still leave edited files
  4. Resume from git state, not a fresh prompt
  5. Which agent tasks can fall back automatically?
  6. Does Claude Code’s –fallback-model help in an outage?
  7. A 429 is a different problem
  8. Three providers, and stopping is still the last fallback
  9. Checklist before you fall back
  10. FAQ

My two outages: September 3 and September 29

On September 3, requests kept failing and retrying while I was working in a repository. I suspected my own network or session first.

Then I opened other AI services. Anthropic and OpenAI were both having problems in the same time window, and I then confirmed a provider outage on the status pages (Claude, OpenAI). Codex had stretches where it wasn’t working normally either.

On September 29, new requests failed and sessions wouldn’t start reliably. After a few retries, I confirmed it was a provider outage and stopped retrying.

Here is what the official records say, checked again on November 2, 2026:

  • September 3: Anthropic’s incident record covers elevated errors on several models, posted from 13:26 to 16:23 UTC, with impact ending at 16:16 UTC. As of October 2, 2026, it didn’t name Claude Code. The record now lists claude.ai, the Claude API, Claude Code, and Claude Cowork as affected.
  • September 29: the incident record covers elevated errors on claude.ai, Claude Code, Claude Cowork, and the Claude API, with impact from 14:00 to 14:59 UTC.
  • OpenAI: its status history shows ChatGPT and Codex incidents on both dates. Whether the Anthropic and OpenAI outages shared a cause hasn’t been confirmed.
Recreated Claude status incident record for September 29, 2026, showing the title Elevated errors and the 14:00–14:59 UTC impact window, with update rows hidden
The September 29 incident record redrawn with only its title and impact window (AI-recreated screen, values hidden).

Should you switch from Claude Code to Codex during an outage?

You can switch, but that’s not where it ends. The context doesn’t come with it, and on a day when several providers wobble, there may be nowhere stable to switch to.

I’ve switched from Claude Code to Codex by hand several times when Claude Code was unstable. I handed over repository analysis or the remaining edits.

The cost was context reconstruction. I had to write down five things for the new agent:

  1. The current goal
  2. The changes already made
  3. The work left
  4. The git diff state
  5. The tests that verify it

Project instructions don’t carry over on their own either. As of November 2, 2026, Codex reads AGENTS.md, not CLAUDE.md. Its project_doc_fallback_filenames setting in ~/.codex/config.toml lets you add other instruction file names.

I wrote about carrying context into a fresh Codex session in recovering from Codex’s context window error.

Why a failed response can still leave edited files

An agent can finish editing files before it sends its final response. If it fails between those two steps, the API call ends in an error while the edits stay in your workspace.

I once had a session fail before the agent returned its final explanation. The response never completed, so I assumed the task had failed too.

When I opened the workspace, there were modified files. git diff showed part of the code change I’d asked for, already applied.

Since then, before any provider fallback, I check what the first request left behind, not whether it failed.

Diagram of an agent run that edits files and then fails at the final response: the API shows an error, while changes may remain in the workspace, checked with git diff
One failure seen from two sides, the API and the workspace.

The handoff I regret

The case I regret is one where I handed off without knowing that state. The agent had edited some files when the first provider request failed. I gave the same task, unchanged, to another model.

The workspace wasn’t clean. The first agent’s partial changes were still there, so the second model started work on top of changes it knew nothing about.

It didn’t end in the same change going in twice. But when one task runs twice, the edits can overlap or conflict. That risk is why I stopped automatic fallback afterward.

When I cleaned up, I didn’t start with a full rollback. I used git status and git diff to see what the agent had actually changed. I kept the parts that came out as intended and split off only the incomplete parts, or the ones for the next agent.

Resume from git state, not a fresh prompt

I don’t give the new provider the original prompt from the top. I check how far the work got, then hand over finished and unfinished parts separately.

The order:

  1. Look at the changed files with git status and git diff.
  2. Check the test results and the agent’s command log.
  3. Split what’s done from what isn’t, and give that to the next agent.
# Example commands, not output from an actual outage
git status --short        # which files changed?
git diff --stat           # how much changed?
git diff --staged --stat  # is anything already staged?
git log --oneline -3      # did the agent go as far as a commit?
git diff path/to/file     # is this the change I intended?

This assumes a workspace where git shows you the state. I don’t cover resuming queue- or worker-based jobs here.

Claude Code’s own /rewind doesn’t replace this check. Its checkpointing docs (as of November 2, 2026) say it tracks edits made by Claude’s file editing tools. A file that only Bash commands changed isn’t tracked, and the docs point you to version control, such as Git, for those.

Provider-side history is shaky ground too. The September 29 record says some messages sent between 14:00 and 14:59 UTC may not have been saved. It doesn’t say whether that applies to Claude Code work, so I look for the resume point in my own workspace.

Which agent tasks can fall back automatically?

In my setup, reads fall back automatically because they have no side effects. Work already in progress falls back only after I check its state and narrow the scope. File changes, external actions, and deploys wait for a human.

I built a provider fallback path into the Task Risk routing layer on the API and agent side, and tested it. The policy has three tiers.

Risk Tasks Fallback
Low Read, summarize, analyze Auto retry elsewhere
Medium Partly done work Check state, narrow scope
High File changes, external API actions, deploys No auto; human checks

Low tasks have no side effects. Medium tasks are already partly done, so I need the current state before deciding, and I don’t re-run existing changes from the start. High tasks can’t move without a state check, so they resume after a person looks.

Flowchart after a failed request: Low-risk tasks retry on another provider, Medium tasks check the current state and then take a narrower fallback, High tasks get no automatic fallback until a human checks
My decision order after a failed request, branching on task risk.

Two Medium examples

Say the code change is done and only the tests failed. I freeze the change as a diff and hand it off with: “Don’t redo the edit from scratch. Review this diff and analyze only why the tests failed.”

If only some of several files were edited, I leave the finished files alone. I hand over only the remaining files and the analysis.

When the state is hard to check, or an external side effect is possible, I don’t hand off automatically. I stop.

Five actions that wait for a state check

These never fall back automatically until I’ve checked how far the first run got:

  • File writes
  • Git commit and push
  • Sending external messages
  • Irreversible actions such as payments or deletions
  • Database mutations

For the commit step, I covered a separate guard in making CI the real gate when an agent runs git commit --no-verify.

None of this is about model quality. If a second run starts without knowing where the first one stopped, you can get duplicate side effects. My short version: reads are easy to retry; for writes, check the current state first.

Switching models also isn’t like swapping an HTTP endpoint. Tool schema interpretation, structured output compliance, context handling, latency, and cost all change. I design for the same request being carried out in a different way, down to which tool the agent calls.

Does Claude Code’s –fallback-model help in an outage?

It switches between Claude models only. As of November 2, 2026, the model configuration docs describe --fallback-model and the fallbackModel setting as a chain of Claude models, capped at three. Claude Code tries the next one when the primary model is overloaded, unavailable, or returns another non-retryable server error.

Three details matter for an outage plan:

  • Authentication, billing, rate-limit, request-size, and transport errors never trigger the switch.
  • The switch lasts for the current turn only. Your next message tries the primary model again.
  • The docs’ examples are all Claude models. Nothing on that page describes moving to another provider.

So the flag can keep a turn alive when one model is overloaded. It doesn’t move work to Codex or Gemini, and it doesn’t check what the failed turn already changed in your files.

A 429 is a different problem

A 429 is a rate-limit signal, not an outage. In the Claude API error reference, 429 is rate_limit_error and 529 is overloaded_error, a temporary overload under high traffic across all users.

I handle 429 separately from provider fallback. For the Gemini API, I set a retry cap of 4 with backoff of 1, 2, 4, and 8 seconds.

When a rate-limit signal comes in, I don’t move to another model. I wait, or I fix the call structure.

I’m careful with n8n’s Retry On Fail for the same reason. No second request until I know how far the first one got.

Three providers, and stopping is still the last fallback

My setup gives me access to Claude, OpenAI/Codex, and Gemini models. I still don’t assume that protects me from outages.

On September 3, when I checked, Anthropic and OpenAI were shaky in the same time window. Switching to Codex wasn’t a fully working option that day.

I don’t know whether the cause was the same. What matters to me is that outages can overlap.

So the final fallback may not be a fourth model. It may be stopping. For High tasks, stopping is my default, and on September 29 I stopped retrying instead of sending the same request again.

Checklist before you fall back

Before I move work to another model, I look at five things:

  • How far did the first run get?
  • Is this task Low, Medium, or High risk?
  • Does it include even one write or external action?
  • Is the context for the new model ready (goal, changes made, work left, git diff, tests)?
  • Under what conditions do I stop instead of falling back?

My view is that fallback isn’t a model-switching feature. It’s a procedure for finding out what already happened and continuing from there.

FAQ

How do I tell a Claude outage from my own network problem?

Check status.claude.com before you retry again. That was my order on September 3: other AI services first, then the status pages.

If I get a 429, should I switch to another model?

Wait and adjust the call structure first. A 429 is a rate-limit signal, so moving to another model doesn’t fix the root cause. If writes are involved, check the state first, whatever the error.

Sources

Related posts

I first wrote this in Korean on my blog: https://jjeongil.tistory.com/3583.