OpenRouter as a Claude Code fallback: check the route and the cost

Identify the failed service before changing the route

The 25 March 2026 video responds to an Anthropic and Claude Code outage. Luke describes routing through OpenRouter and providers such as Amazon Bedrock, Google Vertex or Azure. This is a historical incident response, not a current outage notice or a guarantee that every provider remains independent of the same underlying problem.

The description gives no exact shell variables or integration commands. Use the recorded key-creation sequence at 1:26 and integration at 2:23 for the demonstrated configuration. Keep the original setup recoverable so a temporary workaround does not become an unexplained permanent change.

1. Record the current project, model route and incomplete task before modifying the connection.
2. Create the intended OpenRouter key through the recorded route and keep it out of chat, screenshots and shared files.
3. Check the exact provider and model you intend to reach, rather than treating every route with a familiar model name as equivalent.

Test the shell change and preserve working context

At 3:28 the walkthrough updates shell profiles using Antigravity or Codex; context transfer and switching to Antigravity follow at 5:14. A profile change can affect later terminals, while a new tool still needs the project’s current goal and unresolved work. Keep those two transitions explicit.

1. Review the proposed profile change and preserve the prior values before applying the demonstrated setup.
2. Start a small request and inspect whether the intended connection responds before resuming a large coding task.
3. Carry the relevant files, decisions and remaining checks into the fallback session, then inspect the first change against the current repository.

Track paid usage and consider a different model

Luke reports accidentally spending $16 in an hour and discusses MiniMax via OpenRouter at 6:23; Gemini 3.1 Pro is another named fallback. These are options and historical costs, not proof of equivalent model quality or a current cheapest route.

1. Inspect usage after the first small request and set a spending boundary for the remaining task.
2. Compare a candidate fallback on a bounded job with a checkable outcome before transferring the full workload.
3. Restore or document the chosen configuration when the incident ends so the next session’s routing and billing are understandable.

The takeaway

A good fallback keeps the work recoverable and the billing visible; availability, model suitability and cost need separate checks.