Skip to main content

​
The short version

Put a catalog id in model and you get that model. Everything else on this page exists so that a tool you did not write, pointed at Layer X1 without being reconfigured, still works.

​
What model accepts

Resolution runs in a fixed order and the first match wins:
1

An exact catalog id

lx1-gpt-oss-120b. This is what GET /v1/models returns and what you should pin in production.
2

A published alias

Each entry’s aliases array in the catalog. Aliases are part of the contract; read them from the endpoint rather than guessing.
3

The bare id, without the `lx1-` prefix

gpt-oss-120b resolves to lx1-gpt-oss-120b. Casing does not matter on any of these paths.
4

A short family handle

A small set of one-word handles resolve to that family’s current default — glm, kimi, qwen, deepseek, gpt-oss.
5

A known foreign stock name

A finite list of ids that SDKs and agents commonly ship hard-coded — gpt-4o, claude-sonnet-4-5, o3, codex, gemini-2.5-pro, mistral-large and a handful of others — each mapped to a catalog model. See below.
6

A `vendor/model` string, retried on its basename

OpenRouter-style ids like openai/gpt-4o are retried as gpt-4o through the same ladder above.
Anything that survives all six is a 404 — an unknown model fails closed rather than silently becoming something else.

​
Foreign model ids

An agent arriving with gpt-4o or claude-sonnet-4-5 baked into its config works without being reconfigured. This is a finite, explicit compatibility list, not a pattern match: invented or future ids (gpt-7, claude-opus-9) are not silently accepted. Two consequences worth knowing:
  • The response echoes your string. Send gpt-4o and the response body says gpt-4o, because a strict client that round-trips the model id would otherwise reject its own conversation. The x1-model response header tells you what actually served the request.
  • The mapping can move. These handles point at whichever catalog model is the right landing spot today. Treat them as a compatibility shim for tools you cannot configure — never as a production pin. Pin lx1-* ids in anything you own.

​
Omitting the model, and auto

Leave model out, or set it to auto, and you are telling the gateway that the choice is its to make. Both do the same thing: they resolve to the platform default and additionally unlock the router’s automatic tier, which may serve an equivalent model when it can do the work.
Use it for high-volume work where “a good answer” is the requirement. Do not use it where you need a specific model’s exact behavior — name the model instead. A named model is never silently upgraded to a more expensive one.

​
Reading back what served you

Two places, and they answer different questions: For any request that names a real catalog id, both are the same string. They diverge only on the compatibility paths above.

​
Picking a model deliberately

  • Pin an lx1-* id for anything whose output you depend on — evals, structured extraction, a golden-path agent step.
  • Check capabilities before you send. capabilities.vision, capabilities.tools and supported_parameters on the catalog entry tell you whether a model will accept what you are about to send. A capability a model cannot guarantee returns 422 rather than being quietly dropped — see Errors.
  • Match the tier to the step. Agent loops are mostly cheap steps and a few hard ones; the catalog is grouped by tier so you can put the workhorse on the loop and a frontier model on the step that needs it. Included usage is one pool measured in dollars (Plans & limits), so a cheaper model on the hot path is directly more requests.