> ## Documentation Index
> Fetch the complete documentation index at: https://docs.layerx1.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Which model actually serves you.

> What the model field accepts — canonical ids, aliases, bare names, and the stock ids your SDK already has baked in — plus what happens when you leave it out or set it to auto.

## 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:

<Steps>
  <Step title="An exact catalog id">
    `lx1-gpt-oss-120b`. This is what [`GET /v1/models`](/api/models-endpoint) returns and
    what you should pin in production.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="A short family handle">
    A small set of one-word handles resolve to that family's current default — `glm`,
    `kimi`, `qwen`, `deepseek`, `gpt-oss`.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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.
  </Step>
</Steps>

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.

```json theme={null}
{ "model": "auto", "messages": [{ "role": "user", "content": "Summarize this." }] }
```

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:

| Where                        | Question it answers                                     |
| ---------------------------- | ------------------------------------------------------- |
| `x1-model` response header   | Which catalog model actually served this request.       |
| `model` in the response body | What your client asked for, echoed in the form it sent. |

For any request that names a real catalog id, both are the same string. They diverge only
on the compatibility paths above.

```sh theme={null}
curl -i https://api.layerx1.com/v1/chat/completions \
  -H "authorization: Bearer $LAYERX1_API_KEY" \
  -H "content-type: application/json" \
  -d '{"model":"gpt-4o","messages":[{"role":"user","content":"Hi"}]}' \
  | grep -i '^x1-model'
```

## 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](/api/models-endpoint) 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](/errors).
* **Match the tier to the step.** Agent loops are mostly cheap steps and a few hard ones;
  the [catalog](/models) 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](/plans)), so a cheaper model on the hot path is directly more requests.