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

# Routing and providers

> What the platform tells you about who served your call, and what it deliberately does not.

export const exampleModel = 'deepseek-v4.1-flash';

A model name here is a routing key, not a product name. <code>{exampleModel}</code> names
weights and a service level; it does not name a company, and neither does anything in the
response.

This page is about that boundary — what you can see, what you cannot, and why the second
list is on purpose.

## What you can see

| Header             | On             | Value                                                   |
| ------------------ | -------------- | ------------------------------------------------------- |
| `x-request-id`     | every response | The handle that reaches the whole path the request took |
| `x-provider-class` | success        | `primary` or `fallback`                                 |
| `x-config-version` | success        | Which routing configuration was in effect               |

`x-provider-class` answers the question that actually affects you — *did I get the first
choice, or a standby?* — without answering the one that does not. A run of `fallback`
alongside slower responses is worth telling us about, with the request ids.

`x-config-version` is only useful comparatively: two calls that behaved differently under
the same version point at something other than routing.

## What you cannot see, and why

**Nothing in the response names who ran the model.** Not a header, not a field, not an
error message. That is a rule the error catalogue is checked against, not a convention.

Three reasons, in the order they will matter to you:

<CardGroup cols={2}>
  <Card title="Your integration does not move" icon="anchor">
    When capacity for a model shifts, your code does not change. There is nothing to
    change — you were never given the name that would have needed updating.
  </Card>

  <Card title="Capacity can be plural" icon="layer-group">
    One model may be servable from several places at once. A single vendor name would be a
    lie on some calls and unstable on the rest.
  </Card>

  <Card title="A name invites a dependency" icon="link-slash">
    Published names get branched on. Then a routing change becomes a breaking change for
    people who were never promised anything.
  </Card>
</CardGroup>

The trade is explicit: you give up knowing which company served a given call, and you get
an integration that survives us changing that.

## What this means in practice

* **`owned_by` is an account, not a vendor.** On [`GET /v1/models`](/api-reference/list-models)
  it says which account a model belongs to — the platform's own, or yours.
* **A retry may land somewhere else.** After `UPSTREAM_RATE_LIMITED` or
  `UPSTREAM_UNAVAILABLE`, a retry may be served by a standby. That is the mechanism
  working, and it is why those codes are retryable.
* **Model names never mirror an upstream catalogue.** If a name you know from elsewhere
  does not work here, that is the reason — look it up rather than translating it. See
  [Models and resource names](/models-and-resource-names).
* **Error messages stay ours.** An upstream failure is reported as `UPSTREAM_UNAVAILABLE`
  or `UPSTREAM_TIMEOUT` with our wording, never with a third party's text.

## Reporting something

Quote `x-request-id`. It is enough on its own — we can see which route a call took, what
it cost and where the time went, without you having to guess at any of it.

## Next

<CardGroup cols={2}>
  <Card title="Models and resource names" icon="boxes" href="/models-and-resource-names">
    How to write the name in the first place.
  </Card>

  <Card title="Data handling" icon="shield" href="/data-handling">
    What is kept, and what is never written down.
  </Card>
</CardGroup>