DEVELOPER DOCUMENTATION

Provider verification

How we make sure a discounted route serves the model you asked for.

Last reviewed October 12, 2026.

• We test before we enable. Tools, reasoning controls and prompt caching are enabled on a discounted supplier only after the model passes our tests for them there.
• Every seller is checked before it serves. A seller’s endpoint must belong to an allowlisted provider and answer a live request for the model, and it leaves rotation as soon as it starts failing.
• Every request is recorded. We send the exact model ID, and Activity shows the model the provider reported back.

How we choose a supplier

Each request goes to the lowest-cost eligible supplier for the model you chose. A supplier is eligible only when it supports every parameter in your request and is currently healthy. We exclude supplier and model combinations that fail our checks.

What “trusted” means

A marketplace seller does not run a server in your request’s path. The seller lists an API key for its own account with a model provider, and your request goes directly to that provider’s API with that key. Only provider addresses on an allowlist are accepted, and we use only sellers marked trusted, meaning the address belongs to a known provider. Trust describes who operates the endpoint; it is not a background check on the seller.

Because the provider account belongs to the seller, the provider’s policies and that account’s settings govern retention. Depending on the provider, the account holder may be able to view request logs. ZDR requests never use these sellers; send "zdr": true when a prompt must not be retained.

Neither the trusted label nor our tests certify a supplier’s legal identity, resale rights, security program, or contracts with model developers.

Seller checks

Before a seller can serve a request:

• Its endpoint must be on an allowlist of provider addresses. Private network addresses are refused.
• A live request to the model with the seller’s own key must succeed. If it fails, the offer is not listed.
• The model name must match a known model, and one key can back only one offer per provider and model.

While a seller serves:

• A seller that fails on live traffic is marked unhealthy and stops receiving requests until a recovery check passes.
• Keys that the provider confirms are invalid are delisted.

What we test

Each test is a short synthetic conversation with random values. The model can answer correctly only if it uses what it was given: the system prompt, an earlier turn, a tool result, or digits that appear only in an image’s pixels. A successful response with the wrong answer fails. Depending on the feature, we also check:

• Tools: the right tool and arguments, then a follow-up turn that uses the tool result, streamed and not streamed.
• Structured output: the reply matches the requested JSON format.
• Reasoning: a requested effort produces reasoning, and turning reasoning off produces none.
• Prompt caching: a repeated call reads from the cache.
• Every test: the reply is complete, the parameters we sent were accepted unchanged, and usage and the final bill were reported.

A feature is enabled only after repeated passing runs. Where we can, we run the same conversation on the model’s list-price route and judge the discounted route against how the same model behaves there, which helps catch a weaker model behind a familiar name.

When a request that uses images, reasoning controls or prompt caching goes to a seller, it stays with sellers on the provider that passed those tests for the whole request, including streaming. When a route fails a test, we withdraw that feature from it.

On every request

We send the exact upstream ID of the model you chose. Similar names, revisions and variants are never treated as the same model. If we fail over to another supplier, the model stays the same. A Fusion can choose different models by design.

Each response carries x-gpu-router-upstream-model and a model field with the GPU Router model ID that served it: the model you asked for, or the one a Fusion chose. In Activity, View details shows the model you asked for and the model served. The same record is in modelReceipt on GET /v1/receipts/:reservationId.

When a route fails

If a route fails before output starts, we can retry on another eligible route for the same model. Routes that keep failing are paused or excluded. See Routing for retry behavior.

Privacy is checked separately

A trusted supplier or a passing test does not mean zero data retention. Send "zdr": true on each request that must not be retained; if no eligible route is available, the request fails. See Privacy & call data and the ZDR guide.

Report a suspected model problem

Email hi@gpustrategy.fun with the model, the time and time zone, and the reservation ID from Activity or the x-gpu-router-reservation header. Include x-gpu-router-upstream-model if your client shows it.

Describe what looked wrong and, if you can, share a short example with made-up data. Do not send API keys, private code, personal information or confidential prompts. A model naming itself in its answer is not reliable evidence; request records and reproducible behavior are.