Where your requests go
How to see and restrict which companies handle your traffic, and why region pinning is not among them.
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:
curl https://api.multigrid.ai/v1/providersFor one model specifically, the exact order we will try, with the price on each route:
curl https://api.multigrid.ai/v1/models/anthropic/claude-sonnet-5/endpointsIf 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.
{
"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
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