Skip to main content
A model name here is a routing key, not a product name. deepseek-v4.1-flash 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

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:

Your integration does not move

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.

Capacity can be plural

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.

A name invites a dependency

Published names get branched on. Then a routing change becomes a breaking change for people who were never promised anything.
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 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. Before the first token, the platform already tries standbys itself: at most five upstream attempts per request in all.
  • 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.
  • 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.

​
Letting the platform choose: auto

auto is Prentis One. Its open-weight-only sibling auto-open (Prentis One Open), how the two compare, and their limits and billing are on the Prentis One page; this section covers auto.
auto is rolling out gradually. Where it is not yet available, it answers MODEL_NOT_FOUND like any unknown model name, and GET /v1/models does not list it.
Send "model": "auto" (the same router as accounts/maas/routers/auto) on any of the four inference endpoints, and the platform picks a model for each call. It looks at what the call is about and how hard it is. Then, among the models your key may call and that can take this request (tools, images, response format, parameters, context length), it picks the most capable one. If that model fails before it has sent anything, the call moves on to the next choice. The whole call still makes at most five upstream attempts, each of at most 120 seconds. Your key needs auto in its allowed models, and every model you list after auto: has to be allowed too. Same boundary as everywhere else. The response, every stream chunk and every error name what you wrote: auto, or your auto:… string. Which model answered is not shown, and your usage and billing pages show it as Prentis One. The one extra header is x-router-trace-id, the id of the choice. Quote it with x-request-id when you ask us why a call went where it did. Conversations stay on one model. Switching models mid-conversation costs you prompt-cache hits and consistency, so the platform keeps a conversation where it is when it can:
  • a turn that hands back a tool result goes to the model that asked for the tool;
  • a new turn stays on the previous model while that model is still among the best two for it.
Conversations are recognised by, in order:
  1. the x-session-affinity header;
  2. the request’s prompt_cache_key;
  3. failing both, the system prompt and first user message.
Send the same x-session-affinity on every turn if you want to be sure. A conversation is remembered for an hour after its last turn. Billing. Tokens are billed at the price of the model that answered, exactly as if you had called it directly. A call that auto had to classify carries a small routing fee: the classifier’s input tokens, currently $0.042 per million (a reference price that may change). It shows as its own line under Prentis One. There is no fee when you name a single model with auto:<model>, on a tool-result turn that continues a conversation, or when the classifier could not answer. Known limits. Switching providers mid-conversation can still lose prompt-cache hits and reasoning continuity. auto chooses for capability, not for cost or speed.

​
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

Models and resource names

How to write the name in the first place.

Data handling

What is kept, and what is never written down.