Empty model picker on a custom endpoint: read /v1/models first

A working key and a working URL do not guarantee a populated dropdown. The picker is fed by a separate route, and some clients do not fetch it at all — so the empty box tells you nothing about whether your configuration is correct. The endpoint's own model list is the only authority, and it is one curl away.

curl https://aicomp.ai/v1/models \
  -H "Authorization: Bearer sk-your-gateway-key"

The route that feeds the dropdown

The list endpoint is a normal GET on your base URL, and the response shape is fixed: an object whose object is list, containing a data array of entries each carrying an id.

GET /v1/models
Authorization: Bearer sk-...

200 OK
{
  "object": "list",
  "data": [
    {"id": "gpt-5.6-luna", "object": "model", "created": 1750000000, "owned_by": "openai"},
    {"id": "claude-sonnet-5", "object": "model", "created": 1750000001, "owned_by": "anthropic"}
  ]
}

That id is the only string the completion route will accept as model. Not the display name, not the vendor's marketing name, not the slug in a documentation URL.

# The endpoint's own list is the only authoritative source of model ids.
curl -s https://aicomp.ai/v1/models -H "Authorization: Bearer $GATEWAY_API_KEY" > /tmp/models.json

head -c 200 /tmp/models.json
#   -> starts with {"object":"list" ...   good
#   -> starts with <!DOCTYPE or <html     something else answered; fix the URL first

python3 - <<'PY'
import json
d = json.load(open("/tmp/models.json"))
ids = [m.get("id") for m in d.get("data", [])]
print(len(ids), "models returned")
print("\n".join(str(i) for i in ids[:10]))
PY

Run it once and keep the output. Everything else on this page is downstream of what it prints.

Four ways an empty picker happens

They look identical in the UI, and only one of them is actually about your configuration:

• The route is not implemented. The endpoint serves /chat/completions and nothing else. The picker stays empty; a hand-typed id works immediately.
• Something else answered. A wrong path, a corporate proxy or a captive portal returns HTML with a 200. Check that the body parses as JSON before you trust the status code — this is the same first check as in base URL not working.
• The key is scoped to nothing. Authentication succeeded and data came back empty. The credential is fine; its permissions are not.
• The client never fetches the list. Some clients populate the picker from the route and some expect you to type the id. Which behaviour you get varies by client and version, so test once rather than assuming — and note that manual entry is the deterministic path in either case.

Why copying the id from the wrong place 404s

Ids get rewritten for the address bar. In our catalogue, 15 of the tracked model ids differ from the slug used in their URL — the dot in gpt-5.6-luna becomes a hyphen in gpt-5-6-luna, for instance. Send the slug and the server sees a model it does not serve.

Showing 8 of 15. The full catalogue exposes 839 ids — too many for any picker, which is the next point.

When the list is too big to be useful

A gateway catalogue runs to 839 entries. A picker that renders all of them is technically working and practically unusable, and it makes the "empty dropdown" failure and the "unusable dropdown" failure look like the same bug. If your client supports pinning a shortlist or typing an id, use it.

Rates checked 2026-09-26. Gateway rates move with upstream promotions — verify the current number in your dashboard before committing to a budget.

Rates checked 2026-09-26. Gateway rates move with upstream promotions — verify the current number in your dashboard before committing to a budget.

The failure that does not announce itself

Here is the expensive one. Clients infer a model's context window from its name. Serve a model under an id the client does not recognise and it may assume a small window and trim your prompt to fit — silently, with no error and a perfectly valid response. You get shorter answers and occasional nonsense, and nothing points at the model id.

Where the client exposes a model configuration section — context window, maximum output tokens, image support, tool support — fill it in explicitly for any custom id. That turns an inference into a stated fact.

Related guides

• One endpoint for every tool — the hub for tool-specific setup
• Cline with a custom endpoint — where the id goes in Cline
• Continue with a custom endpoint — the same pattern in Continue
• Base URL not working — when the URL itself is the problem
• context_length_exceeded — the window the client guessed
• Endpoint error codes — reading a 404 on a model id

Empty-picker failures and what each one is actually telling you

When this is the wrong move

Four assumptions behind most empty-picker tickets

Rolling it out without finding out the hard way

The failure mode you want to avoid is discovering a problem through a production bill or a customer-visible error. Four steps, in order:

1. Prove it on one request with the id copied from /v1/models, with the window set explicitly. One call, from a script, with an explicit timeout and the model ID echoed back. You are testing reachability, authentication and model availability — three things that can fail independently.
2. Measure before you switch. Record tokens per task and cost per task on the current path first. Without that baseline, "it got cheaper" is an impression, not a result.
3. Move one workload, not everything. Pick the workload with the most predictable shape — batch jobs over interactive traffic. Leave the interactive path on the old configuration until the batch numbers are in.
4. Decide the rollback condition in advance. Write down what makes you revert (error rate above X, cost per task above Y, latency above Z) before you start, so the decision is not made under pressure.

Keep the base URL in configuration, never inline. That single choice is what makes step four take a minute instead of an afternoon.

FAQ

Get API access