You call messages.create, and back comes error.type: "not_found_error" with model_not_found. Nothing meaningful changed in your code, but a script that worked yesterday refuses to run today. If you use the Claude API in production, almost everyone hits this at some point.
I've done it myself. I copied an older project's snippet that still hardcoded claude-3-5-sonnet-20241022, assumed it would "just work because I haven't touched it in a while," and burned half an hour before realizing my mistake. Nine times out of ten the cause isn't permissions — it's a typo, a stale alias, or the wrong organization selected in the console. Once you know the order to check things in, recovery takes about five minutes.
This article walks through the model IDs that actually exist as of April 2026, the most common misunderstandings I see in real codebases, and a tiny diagnostic snippet that pinpoints the cause in one shot.
Decode the Error: "Doesn't Exist" and "No Access" Are Bundled Together
Anthropic's API actually folds two distinct situations into the same model_not_found response. The body looks like this:
{
"type": "error",
"error": {
"type": "not_found_error",
"message": "model: claude-sonnet-4-5 does not exist or you do not have access to it"
}
}The wording does not exist or you do not have access to it matters. Anthropic deliberately groups "this model isn't real" and "your account can't see it" under a single error, so the message alone won't tell you whether you mistyped the ID or whether your tier doesn't include the model yet.
In my own debugging notes, the breakdown for this error tends to look something like:
- Pasted an old model ID with a typo: ~60%
- Calling a deprecated model that no longer ships: ~20%
- Tier or region restrictions on the account: ~15%
- Wrong organization selected in the console: ~5%
The rule of thumb: suspect spelling before you suspect permissions. If you reverse the order, you'll waste time poking at console settings when the answer is in your source file.
Model IDs That Actually Exist as of April 2026
Claude's model IDs evolve with each release. The main IDs you can pass to model in messages.create right now are:
claude-opus-4-6— the latest flagship; strongest at deep reasoning and structured long-form outputclaude-sonnet-4-6— the balanced workhorse; fine for most production workloadsclaude-haiku-4-5-20251001— the fast, low-cost option; great for batch jobs and summaries
Watch the naming convention carefully. Haiku 4.5 carries a date stamp (-20251001) at the end, while the latest Opus and Sonnet use only the hyphenated generation suffix. That inconsistency comes from Anthropic's release cadence, and it's a frequent stumbling block when porting code from older repos.
A common variant of this error is "claude-sonnet-4-5 worked, but claude-sonnet-4-6 is rejected." Most of the time the API key belongs to an older account that hasn't been granted access to the new generation yet — the diagnostic in the next section will surface this immediately.
Older IDs like claude-3-5-sonnet-20241022 may still resolve as of writing, but Anthropic has been clear about phasing them out gradually. If your codebase still hardcodes one of those, treat it as technical debt that's about to bite.
Verify Tier, Region, and Console Access in Three Minutes
Once spelling is ruled out, suspect the account side. There are really only three things to check.
1. Confirm which organization is active in Anthropic Console
If you belong to multiple orgs, this is where most people trip. Look at the organization name in the Console's top-left dropdown. A common pattern is keeping a personal key and a work key, with code reading the personal key from ANTHROPIC_API_KEY while you're staring at the work org in the browser. They never match up.
# Confirm which key your environment is using
echo $ANTHROPIC_API_KEY | head -c 15
# Sample output: sk-ant-api03-XXCompare the first 15 or so characters with the key list in the Console — that alone usually reveals the org mismatch.
2. Make sure the model is enabled for your organization
Under Settings → Models, each org sees a list of accessible models. New flagships like Opus 4.6 sometimes roll out gradually, and on Free or Build tier they may be temporarily hidden.
3. Are you really calling Anthropic directly — or going through Bedrock / Vertex?
When you reach Claude through AWS Bedrock or Google Vertex AI, the model identifiers change shape entirely.
- Bedrock: something like
anthropic.claude-sonnet-4-6-v1:0 - Vertex AI: something like
claude-sonnet-4-6@20260301(with date suffix)
A surprisingly common bug is having a Bedrock-only environment but copy-pasting sample code from Anthropic's docs that hardcodes the direct ID. If you also see authentication errors mixed in, the 401 invalid-key checklist for Claude API is worth reading next.
Migrating Old Code to Sonnet 4.6 Without Drama
The most common trigger for model_not_found is reviving an older project where the model name has drifted out of date. Here is the migration pattern I reach for, designed to keep risk low.
# anthropic_client.py — keep model names in exactly one place
import os
from anthropic import Anthropic
# Centralize model selection so you can switch via env var in an emergency
DEFAULT_MODEL = os.getenv("CLAUDE_MODEL", "claude-sonnet-4-6")
FALLBACK_MODEL = os.getenv("CLAUDE_FALLBACK_MODEL", "claude-haiku-4-5-20251001")
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
def chat(messages: list[dict], model: str = DEFAULT_MODEL) -> str:
"""Catch model_not_found and fall back automatically — minimal version."""
try:
response = client.messages.create(
model=model,
max_tokens=1024,
messages=messages,
)
return response.content[0].text
except Exception as e:
# We could import APIError from anthropic._exceptions, but matching on
# the type string keeps this snippet free of internal dependencies.
if "not_found_error" in str(e) and model != FALLBACK_MODEL:
print(f"[fallback] {model} not available, retrying with {FALLBACK_MODEL}")
return chat(messages, model=FALLBACK_MODEL)
raise
# Quick check
if __name__ == "__main__":
result = chat([{"role": "user", "content": "Hello"}])
print(result)
# Expected output: a short greeting like "Hello! How can I help you today?"The key idea is: never write the model name in more than one place. If grep -r "claude-sonnet" . returns just one hit, future migrations stop being scary.
For higher availability, the layered fallback pattern in building a multi-model fallback for Claude API goes further than this minimal example.
A Diagnostic Snippet That Pins Down the Cause Immediately
When the error happens in production at 2 a.m., I don't want to guess whether it's a typo, a permissions issue, or something else entirely. So I keep a tiny diagnostic script around that sweeps the candidates in one go.
# diagnose_model.py — narrow down model_not_found in three seconds
import os
import sys
from anthropic import Anthropic
CANDIDATES = [
"claude-opus-4-6",
"claude-sonnet-4-6",
"claude-haiku-4-5-20251001",
]
def diagnose():
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])
print(f"API Key prefix: {os.environ['ANTHROPIC_API_KEY'][:15]}...")
print()
for model in CANDIDATES:
try:
client.messages.create(
model=model,
max_tokens=1,
messages=[{"role": "user", "content": "ping"}],
)
print(f"OK {model}: accessible")
except Exception as e:
err = str(e)
if "not_found_error" in err:
print(f"NG {model}: not accessible (deprecated or no access)")
elif "authentication_error" in err:
print(f"KEY {model}: API key is invalid")
sys.exit(1)
else:
print(f"WARN {model}: {err[:60]}")
if __name__ == "__main__":
diagnose()
# Sample output:
# API Key prefix: sk-ant-api03-XX...
#
# OK claude-opus-4-6: accessible
# OK claude-sonnet-4-6: accessible
# OK claude-haiku-4-5-20251001: accessibleWiring this into your CI/CD health check prevents the embarrassing scenario where production deploys and you discover Opus was never enabled on the prod org. Each call uses max_tokens=1, so the total cost is well under a cent.
If transient 503s or rate limit errors muddy the diagnostic, combine it with the exponential backoff pattern from a practical guide to Claude API rate limits and 429 handling and the picture clears up quickly.
A Few Subtle Cases I See Repeatedly
Beyond the main causes above, there are three subtle variants that quietly account for a lot of support tickets.
The first is typed-out variants of the model name that look right but aren't. claude-sonnet-4.6 (with a dot) and claude_sonnet_4_6 (with underscores) both fail with model_not_found. The official format always uses hyphens — claude-sonnet-4-6. Linters won't catch this because the value is a plain string, so I've started keeping a small enum or const map at the top of every project to normalize the spelling.
The second is case sensitivity from rendering tools. If you build prompts in a Markdown editor or a CMS that auto-capitalizes, Claude-Sonnet-4-6 slips in and breaks. The API rejects any non-lowercase variant. A quick model.lower() before the call closes this off in environments where humans hand-edit configs.
The third is multi-tenant SaaS plumbing. If you sell an AI feature to your own customers and let them bring their own Anthropic key, you'll occasionally see model_not_found from a customer key whose account has a narrower model allowlist than yours. The diagnostic in the previous section handles this well — surface a clear message back to the customer like "this model is not enabled on your Anthropic account" rather than a raw stack trace, and support load drops noticeably.
Wrap-Up: Next Time, You'll Move Through This in Five Minutes
model_not_found looks alarming, but the resolution order is fixed: spelling → alias generation → org and key → regional ID format. Walk through that list and most cases close in under five minutes.
A small concrete step you can take today: run grep -rn "claude-" --include="*.py" --include="*.ts" against your project and count how many places hardcode a model name. If you find more than one, that's a time bomb waiting for the next deprecation. Centralizing into a single environment variable now is something your future self will quietly thank you for.