Cursor model_not_found: the string is the problem
model_not_found means routing worked. The credential was accepted, the path was right, the endpoint understood the request, and then it could not find the model you named.
That is good news relative to the other errors, because it narrows the field to one thing: the exact string in the model field. Not the key, not the base URL, not the network.
https://aicomp.ai/v1).
Create one free →
The dropdown is not a catalogue
The single most useful fact about this error: in a generic OpenAI Compatible setup, the model list is a snapshot that shipped with the client. It is not fetched from your endpoint.
Two consequences follow, and both surprise people:
- A model can exist, bill correctly, and still be missing from the list. Absence from the dropdown is not evidence that your endpoint is broken.
- An empty dropdown is not a failure. It tells you nothing either way.
So stop treating the list as the source of truth and go to the endpoint:
# The authoritative list, straight from the endpoint you are actually calling
curl -s https://aicomp.ai/v1/models \
-H "Authorization: Bearer $OPENAI_API_KEY" \
| jq -r '.data[].id'Copy from that output. Do not retype it, and do not reconstruct it from memory. Model IDs are case- and punctuation-sensitive, and vendor APIs do not fuzzy-match them. A near miss returns model_not_found rather than quietly serving something similar.
The four ways the string goes wrong
| What you typed | What the endpoint wanted | Why it fails |
|---|---|---|
Claude Sonnet 5 | claude-sonnet-5 | Display name, not ID |
claude-sonnet-5.0 | claude-sonnet-5 | Version suffix that does not exist |
gpt-5 | gpt-5 | Trailing space from a manual selection |
| The ID that worked last month | The current ID | Catalogues change when upstream renames |
The last one is the one that catches people twice. Models get renamed and retired upstream, and a configuration that worked for months starts failing with no change on your side. When an unchanged setup breaks, check whether the ID still exists before you touch anything else.
Confirm the model is served before you chase the client
One command separates "wrong string" from "not available to you". If the ID is present in the list the endpoint returns, the problem is in the field you typed. If it is absent, either the name changed or your access does not include it.
# Is the exact string you are using present?
curl -s https://aicomp.ai/v1/models -H "Authorization: Bearer $OPENAI_API_KEY" \
| jq -r --arg m "claude-sonnet-5" \
'.data[] | select(.id == $m) | "\(.id)\tctx \(.context_length // "n/a")\tmax_out \(.max_output_tokens // "n/a")"'Those last two columns matter for the next section, and they are also the values a generic provider cannot fill in for you. Under a named vendor the client knows a model's limits; under a generic endpoint it cannot, so those fields start empty and manual. Set them from this output rather than from round numbers — a max_output_tokens below what your edits need produces truncated diffs that look like model failures.
Why one endpoint makes this a smaller problem
With direct vendor keys, "which models can I actually call" is a question you answer per vendor, in per-vendor dashboards, with per-vendor naming conventions. With one gateway endpoint, it is one list, fetched once, in one format, and a fallback is a different string from the same list rather than a new credential.
Rates and availability differ per model, so the model price index is where to check what a given ID costs before you commit to it.
When a model name changes upstream, you see it in one place.
FAQ
FAQ
Why does the model exist in the docs but not in my dropdown?
Because the dropdown is a static list shipped with the client, not a live query against your endpoint. Models added after your build are absent from it even though they work. Type the ID into the field (under a generic provider it accepts free text) and copy it from GET /v1/models.
Is model_not_found a permissions error?
Usually not. Access problems tend to surface as 401 or 403. model_not_found almost always means the string did not match anything in the catalogue. Confirm by checking whether the ID appears in the list your endpoint returns: present means a typo, absent means renamed or not available to you.
Does capitalisation really matter?
Yes. Model IDs are matched exactly, not normalised. Claude-Sonnet-5 and claude-sonnet-5 are different strings to the endpoint, and the failure looks identical to a wrong model name. This is why copying from the endpoint beats typing.
Why did it stop working when I changed nothing?
Catalogues move. Upstream renames and retirements change what the endpoint serves without any change on your side, so a configuration that worked for months can start returning model_not_found. Check the current list before debugging the client.
Should I fill in context window and max output manually?
For a generic endpoint, yes. The client cannot know a model's limits when it does not know which model it is talking to, so those fields start empty. Set them from GET /v1/models output, a too-low max output truncates long responses, and a too-high context window produces requests the model rejects outright.
Related
- Cline models list empty — the same snapshot behaviour in another client
- LiteLLM model name mapping When one client's name for a model differs from the endpoint's
- Cursor with an OpenAI-compatible endpoint — where the model field lives
- Cursor API key errors — the codes that fire before routing
- OpenAI-compatible error codes, what each status means, in order
- Model price index (every model with a page), and its rates