Claude Code 'There's an Issue With the Selected Model': It's Usually Just a 404

This is one of the most-reported errors in Claude Code. There are over 90 GitHub issues containing it:

There's an issue with the selected model (claude-sonnet-5-5). It may not exist or
you may not have access to it. Run /model to pick a different model.

It reads like a verdict on the model. So people do what it says: they switch models, re-check their plan, log out and in, and file a ticket about access. Often the model was never the problem.

My test result: every HTTP 404 becomes this message. A wrong model name, a wrong URL, and a proxy's generic error page all look identical. Here's the test, how to find which one you have, and the fixes for each.

How I tested it

I installed Claude Code 2.1.291, the current release, into a temp folder. Then I ran it against a fake API server on my own machine that returns whatever error I tell it to and logs exactly what Claude Code sent. It ran with a dummy API key and an empty config folder, so no request ever reached Anthropic. This was on Windows 11.

Each test used non-interactive mode (claude -p), which is why the message says Run --model rather than Run /model. Anthropic's docs note the hint changes by surface.

Three completely different problems, one message. In the second and third rows, the model was fine: sonnet resolved correctly to claude-sonnet-5-5, and that's what the server received.

Every other status kept its own, accurate message. The disguise is specific to 404. If you see this error, read it as "the server answered 404" and work out why.

Step 1: see what actually happened

The error throws away the useful detail, but the debug log keeps it. Run the same thing with --debug:

claude --debug

Then open the newest file in ~/.claude/debug/. For the stray /v1 test, the log said:

[DEBUG] [API REQUEST] /v1/v1/messages source=sdk
[ERROR] API error (attempt 1/1): 404 404 <h1>404 Not Found</h1>
[WARN] Streaming endpoint returned 404, falling back to non-streaming mode
[ERROR] Non-streaming fallback also failed: 404 <h1>404 Not Found</h1>

Two lines tell you nearly everything:

• The path. Anything other than /v1/messages means your base URL is wrong.
• The reply. An HTML page (<h1>404 Not Found</h1>) came from a web server or proxy, not the model API. A JSON not_found_error that names the model is a genuine model problem.

The warning in the middle explains something else people notice: each failure makes two requests, because the CLI retries a failed streaming request without streaming.

Cause 1: the model name is wrong or stale

This is the case Anthropic's docs describe: "The configured model name was not recognized or your account lacks access to it."

A typo. On 2.1.291, a misspelled name did produce an early clue in non-interactive mode, before the error:

"sonet" isn't described by this version's model catalog; update Claude Code, or map it ...

If you see that line, stop there — it's the name. In interactive sessions, though, one open report says a typo shows no warning at all: the header and /status display it like a real model until your first prompt fails.

A stale value set somewhere you forgot. The model can come from five places, highest priority first:

1. /model during the session
2. claude --model … at startup
3. The ANTHROPIC_MODEL environment variable
4. The model field in a settings file
5. ANTHROPIC_DEFAULT_MODEL, the default for new sessions

If the wrong model keeps coming back, it's in one of these. A shell profile exporting ANTHROPIC_MODEL from months ago is the usual culprit. One user's scheduled tasks failed on every run naming an OpenRouter model they'd configured once and removed — it had been saved somewhere the task still read.

The fix Anthropic recommends: use an alias — sonnet, opus, haiku — rather than a full versioned ID. Aliases "resolve to a maintained default so they don't go stale."

Cause 2: your gateway URL has an extra /v1

If you route Claude Code through an LLM gateway, LiteLLM, a company proxy or a router, this is the first thing to check. It's exactly what happened in issue #97393, and my test reproduced it.

Claude Code adds /v1/messages itself. So ANTHROPIC_BASE_URL should stop before /v1:

# Wrong — requests go to /v1/v1/messages
export ANTHROPIC_BASE_URL=https://gateway.example.com/v1
 
# Right
export ANTHROPIC_BASE_URL=https://gateway.example.com

The same applies to path-based gateways: if the gateway serves /provider/v1/messages, the base URL is https://gateway.example.com/provider.

In #97393, the model ID had a [1m] suffix, and that's what the user suspected first — "the obvious suspect and the wrong one," as they put it. The message points you at the model, so you debug the model. The debug log's path line ends that in seconds.

Cause 3: something returned a 404 page

If the debug log shows an HTML 404, the reply came from something in front of the API, not the model API itself. Common sources:

• A company proxy or firewall answering for a host it doesn't allow
• A gateway route that doesn't exist, or exists under a different path
• A reverse proxy that only forwards some paths

The fix belongs to whoever runs that hop. Show them the path from your debug log, and ask why it returns 404.

One report, #94442, fits this pattern. A Pro user with no custom configuration got this error on every model, while claude.ai worked fine on the same account. The attached error log shows Error: 404 <h1>404 Not Found</h1> — the same HTML-page signature as my proxy test, not the API's normal JSON error. That issue is still open and I can't tell you its cause. But the signature says the 404 came from somewhere other than a "this model doesn't exist" check, so switching models was never going to fix it.

Cause 4: the model in the error isn't the one you chose

A lot of reports — and searches that land on this site — name claude-haiku-4-5-20251001. If you didn't choose Haiku, there's a likely reason it's in the message.

Anthropic's model docs explain why that's possible. ANTHROPIC_DEFAULT_HAIKU_MODEL sets "the model to use for haiku, or background functionality." Claude Code uses the Haiku slot for background work as well as when you select it. If your gateway, router or third-party provider doesn't serve the default Haiku ID, those requests can 404, and the error names Haiku.

The fix is to pin that slot to something your provider actually serves:

export ANTHROPIC_DEFAULT_HAIKU_MODEL=<a model ID your gateway serves>

The same pattern exists for ANTHROPIC_DEFAULT_SONNET_MODEL, ANTHROPIC_DEFAULT_OPUS_MODEL and ANTHROPIC_DEFAULT_FABLE_MODEL. (ANTHROPIC_SMALL_FAST_MODEL is the old, deprecated name for the Haiku one.)

To be clear about what I tested: my non-interactive runs only sent the main model, so I didn't observe a background Haiku request myself. This cause rests on Anthropic's documentation of that variable.

One case that isn't a 404

An expired login on an old version. Before v2.1.206, an expired claude.ai login that couldn't refresh failed every model with this exact error. Newer versions say Login expired instead. If you're on something older, run /login — or better, claude update.

On Google Cloud, the region and project settings produce their own versions of this problem. I covered those in Claude Code on Vertex AI: model not found.

Two-minute triage

1. Run with --debug and open the newest file in ~/.claude/debug/.
2. Path isn't /v1/messages? Remove the extra /v1 (or path segment) from ANTHROPIC_BASE_URL.
3. Reply is an HTML page? Something in front of the API answered. Take the path to whoever runs your proxy or gateway.
4. Reply is JSON "not found" naming your model? It's the name. Check the five places a model can be set, and use an alias.
5. Error names Haiku but you chose something else? Set ANTHROPIC_DEFAULT_HAIKU_MODEL to a model your provider serves.
6. None of the above? Run claude update. Clients older than v2.1.206 report an expired login this way.

If the "something in front of the API" turns out to be a company proxy, its certificate is usually the next thing to break — see Claude Code behind a corporate proxy. Getting AI tools working cleanly inside locked-down company networks is a lot of the work I do — see recent projects.