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.
  • 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.

​
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.