Skip to content

Where your requests go

How to see and restrict which companies handle your traffic, and why region pinning is not among them.

4 min read

Who sees a request

Exactly one provider per attempt, plus us. Nothing is broadcast and nothing is mirrored. Which providers exist, what their API base URLs are, and whether this deployment can currently reach each one is public:

bash
curl https://api.multigrid.ai/v1/providers

For one model specifically, the exact order we will try, with the price on each route:

bash
curl https://api.multigrid.ai/v1/models/anthropic/claude-sonnet-5/endpoints

If a request needed more than one attempt, every provider that was tried is on the request row and comes back from GET /generation. So “who handled this specific request” is a question with an answer, not an inference.

Restricting it

provider.ignore removes providers from a request entirely, and provider.allow_fallbacks: false pins it to the first usable route so a failover cannot move it somewhere you did not intend.

json
{
  "model": "meta/llama-3.3-70b-instruct",
  "provider": { "order": ["together"], "ignore": ["groq", "deepinfra"] }
}

Adding your own provider key is the strongest version of this: the request goes to a company you already have a contract with, under terms you negotiated. See bring your own key.

Region pinning is not built

There is no residency control
Nothing in the gateway pins a request to a geography, and no request fails because a region was unavailable. The catalogue records which company serves a route, not which datacentre. If you have a residency requirement, the honest answer today is to restrict the request to providers whose region you already know, with ignore, with allow_fallbacks: false, or with your own key against a regional endpoint you control.

It is not built because the data to build it on does not exist. The one machine-readable source of provider geography we could find publishes a datacenters field for a quarter of the providers it lists and for none of the ones this gateway routes to. A filter whose input is unknown for every route would have to exclude every route, and a filter keyed on where a company is registered instead would be a jurisdiction control wearing a residency label. Neither is worth shipping, and a dial that cannot be sourced is a dial that should not be drawn.

What is knowable is on each provider’s page and on GET /providers: headquarters, the company’s own privacy policy, and its terms. Those are linked rather than summarised, because a paraphrase of somebody else’s privacy policy is a claim we would be making on their behalf. Headquarters is the jurisdiction whose courts and disclosure law reach the company — a different question from where the GPU is, and the only one of the two that has an answer here.

What we keep

Prompts are never written to our database, not redacted, not briefly. What the request row stores is token counts, timings, cost, which provider answered and your own metadata labels.

Completions are written in exactly two places, both of which you switch on yourself. A batch keeps each submitted line and each result until you delete the batch, because a job submitted now and collected later cannot work otherwise. And a request that sends X-Multigrid-Cache-Ttl has its reply stored for the lifetime it asked for, capped at 24 hours and keyed to your account. The prompt is held only as the hash used to look it up. Send neither and there is nothing of your content here to retain, disclose or train on.

Each provider’s own retention is theirs, governed by the agreement between you and them if you use your own key, and by ours if you use our credit. That is the part this page cannot promise on their behalf.

Something here disagrees with what the API actually did? That is a bug in this page, and worth reporting.

Report it