The model does not exist or you do not have access to it

The model does not exist or you do not have access to it

One message, three providers, four causes. The message itself does not distinguish "no such model" from "not yours", which is the root of the confusion.

{
  "error": {
    "message": "The model `gpt-5.2` does not exist or you do not have access to it.",
    "type": "invalid_request_error",
    "param": null,
    "code": "model_not_found"
  }
}

Cause one: the ID was retired

This is the single most common cause in 2026, because all three providers retired a great deal of their previous generation. A retirement is not a soft failure: on the day, requests stop working. Our model directory keeps one card per live identity with its canonical id and known aliases, which is a faster way to confirm a replacement than reading three deprecation pages.

OpenAI

The current lineup is three text models: gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna, with gpt-5.6 aliasing to Sol. A change worth noting if your code pins snapshots defensively: the model pages list only bare IDs, with no dated snapshot variants of the GPT-5.6 family. Note also that the undated gpt-4o and gpt-4o-mini aliases are not on the deprecation list; only gpt-4o-2024-05-13 is.

Anthropic

Current IDs are claude-fable-5, claude-opus-5, claude-sonnet-5, and claude-haiku-4-5-20251001. Two things to know: from the 4.6 generation onward the IDs are dateless but still pinned snapshots rather than evergreen pointers, and the nearest retirement floor on a currently active model is claude-sonnet-4-5-20250929, not before 29 September 2026. Anthropic commits to at least 60 days of notice for publicly released models, and Bedrock and Google Cloud run their own schedules that can differ.

Gemini

The 2.0 Flash family (gemini-2.0-flash, -001, -lite, -lite-001) shut down on 1 June 2026, replaced by 3.6 Flash and 3.1 Flash-Lite. gemini-3-pro-preview went on 9 March 2026 in favour of gemini-3.1-pro-preview, and the imagen-4.0-*-001 models went on 17 August 2026. Google's wording is worth internalising: the published dates "indicate the earliest possible dates on which a model might be retired", so treat them as a floor and not a promise.

Cause two and three: entitlement, and the wrong surface

The model exists. You still cannot call it. Two separate gates, and they are easy to confuse because both can produce a 404-shaped complaint.

Entitlement

• Project-level model access. An OpenAI project can be restricted to a subset of models. Calling one outside it returns 403 with Project \`proj_id\` does not have access to model \`X\`. Fix it in the project's allowed-models setting, not in your code.
• Approval-gated models. gpt-5.6-cyber and the Daybreak family are the clear current example: the docs say plainly that the model "requires separate approval and provisioning" and point at an application form. No amount of correct spelling gets you in.
• Organization verification. OpenAI has historically gated some capabilities, streaming on frontier models among them, behind ID verification of the organization. The current GPT-5.6 model pages list no verification requirement, unlike Cyber which states its gate explicitly, so treat this as a possibility to check rather than a certainty.
• Usage tier. Tiers move rate limits rather than model availability on the current lineup, but a very new model appearing for some accounts and not others is a normal rollout state, not a bug in your code.

The wrong API surface

A model can exist and simply not be served by the endpoint you called. On OpenAI all three GPT-5.6 text models work on /v1/chat/completions, /v1/responses, and /v1/batch, but gpt-5.6-cyber is Responses-only: the docs state that "only the v1/responses endpoint is supported".

There is a subtler version of the same thing that costs real capability rather than returning an error. On Chat Completions, OpenAI documents that function tools are "compatible with reasoning_effort: \"none\" only", while reasoning, persisted reasoning, and Pro mode live on Responses. A tool-calling agent left on Chat Completions therefore runs without reasoning and looks merely worse rather than broken, which is harder to notice than a 404.

Cause four: the gateway rewrote your model name

Every gateway maintains its own namespace, and the translation between yours and theirs is where the last category of these errors lives.

OpenRouter

• Slugs are vendor/model, for example google/gemini-3.7-flash or anthropic/claude-haiku-4.5. The full list is public and unauthenticated at https://openrouter.ai/api/v1/models, which makes a startup validation check trivial.
• Aliases resolve silently. The docs give the example of anthropic/claude-3-5-sonnet redirecting to the canonical anthropic/claude-3.5-sonnet. Useful, and a trap: a wrong-punctuation slug can work for months and then stop when the alias is retired.
• Each model has a canonical_slug that never changes, distinct from the id you send. Pin against the canonical one if you need reproducibility.
• Variants are suffixes on the slug: :free, :thinking, :batch. A missing suffix is a different model, not a formatting nicety. A leading ~ marks a floating "latest" pointer.
• The typed error code is not_found with a 404. Other codes in the same family are worth knowing for a failover policy: provider_overloaded at 503, provider_unavailable at 502, and timeout at 504.

LiteLLM

LiteLLM does not return a 404 for an unrecognized name. It raises a BadRequestError because it could not work out which provider you meant, and the message is unusually helpful:

LLM Provider NOT provided. Pass in the LLM provider you are trying to call.
You passed model=gpt-5.6-sol
 Pass model as E.g. For 'Huggingface' inference endpoints pass in
`completion(model='huggingface/starcoder',..)` Learn more:
https://docs.litellm.ai/docs/providers

Resolution runs in order: an explicit custom_llm_provider wins, then a split on the first / to take a provider prefix, then bare-name lookups in per-provider registries, then prefix rules, then a generalization fallback. Only after all of that does it raise. So the fix is nearly always to add the prefix: openai/gpt-5.6-sol rather than gpt-5.6-sol.

The base URL that is not a model problem at all

Worth its own paragraph because it produces a 404 and sends people straight to the model ID. The OpenAI SDK merges a request path onto the base URL's path rather than replacing it: the leading slash on /chat/completions is stripped and the result is appended. So base_url must include /v1.

# correct
OpenAI(base_url="https://gateway.example.com/v1")
#   -> https://gateway.example.com/v1/chat/completions

# missing /v1: 404
OpenAI(base_url="https://gateway.example.com")
#   -> https://gateway.example.com/chat/completions

# doubled /v1, because the gateway docs said to append it: 404
OpenAI(base_url="https://gateway.example.com/v1/v1")
#   -> https://gateway.example.com/v1/v1/chat/completions

The tell is the body. These 404s usually return HTML from a web server rather than a JSON error object, and the HTML then fails to parse as JSON, so what surfaces in your logs is often a decoding exception rather than a 404 at all.

A diagnostic in four requests

# OpenAI
curl -sS https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | jq -r '.data[].id' | sort

# Anthropic
curl -sS https://api.anthropic.com/v1/models \
  -H "x-api-key: $ANTHROPIC_API_KEY" \
  -H "anthropic-version: 2023-06-01" | jq -r '.data[].id'

# OpenRouter, no auth needed
curl -sS https://openrouter.ai/api/v1/models | jq -r '.data[].id' | grep claude

Questions people ask

Keep reading

Continue through Errors and fixes with LLM API timeout errors: which layer actually killed your request.