Requesty
Routing

Route every request to the right model.

Fail over across providers, split traffic by share, or send each request to whichever model is fastest right now. One API, 600+ models.

Speak to founders
600+ models30+ providers99.25% eventual success on a policy
requests / req_8c14f0a2
policy/prod-chain
What the caller never saw
request enters the gateway+0 ms
model: policy/prod-chain
primary returns 429+412 ms
provider throttled, nothing sent back to your app
second model on the chain+418 ms
same prompt, different provider
response streamed to your app+1.9 s
one call from the caller’s point of view
Policies

Pick the models. Pick how they are chosen.

A policy is a list of models and a strategy. Nest them when one is not enough.

Failover

Tried in the order you set. A 429 or 5xx on one moves the request to the next.

strategy / failover
in order
Top to bottom
1claude-opus-5primary
2gpt-5.6-solon 429 or 5xx
3gemini-3.7-proon 429 or 5xx

Load balance

Split by the shares you set. Most traffic to the proven model, a slice to the challenger.

strategy / load balance
by share
Weights you set
claude-opus-5
60%
gpt-5.6-sol
30%
gemini-3.7-pro
10%

Latency

Fastest right now wins, scored on time to first token and generation speed. Order is ignored.

strategy / latency
measured live
ttft · speed, last hour
claude-opus-51.44 s71 tok/s
gpt-5.6-sol0.62 s96 tok/s
gemini-3.7-pro1.29 s84 tok/s
In your code

One string in the model field

Build the policy in the dashboard, then name it where the model used to go. Reorder the chain, change a share or add a model, and nothing ships.

  • Nest policiesA latency policy per region, a failover across them
  • Stay in regionA chain of region-pinned models never fails over out of it
  • Sticky when it mattersPass a trace_id and the ordering holds for that trace
app.py
policy/prod-chain
response = client.chat.completions.create(
    model="policy/prod-chain",
    messages=messages,
)

# the chain, shares and fallbacks live in the policy
Regions

Four gateways. You choose.

Point your client at the EU, US or AP gateway and every request is handled there. Point it at Global and it lands on the nearest one. Requesty never guesses from the caller.

  • Chosen by base URLSame key and request shape on all four
  • Restrict per organizationAllow EU only, and the other three reject
  • Inference is separateApprove region-pinned models to keep it in region
gateways
same key on all four
Global
https://router.requesty.ai/v1
nearest gateway to the caller
EU
https://router.eu.requesty.ai/v1
Frankfurt, eu-central-1
US
https://router.us.requesty.ai/v1
United States
AP
https://router.ap.requesty.ai/v1
Asia Pacific
base_urldecides the gateway.Nothing is inferred from the caller.
Scopes

A policy per team, per use case, per key

Set an organization default, a stricter chain for one team, a policy of its own for a batch job. Spend limits and model restrictions cascade the same way.

policies / by scope
4 scopes
ScopeRouting policyModels it may reachMonthly ceiling
acme-incprod-chainapproved list$20,000
paymentseu-only-chaineu-region models only$6,000
dana@acme-incinherits prod-chaininherits the org list$500
sk-...3f9cnightly-batchtwo cheap models$60

A scope can narrow what it inherits. It can never widen it.

99.25%

eventual success for requests on a routing policy, April 2026.

Open data note

85.01%

for callers going direct to a single provider, same month, same upstream events.

65.8%

of provider failures are 429 rate limits. A chain absorbs exactly those.

Open data note

Agents

A different chain for every agent

A review agent reaches for the strongest model you allow. A batch job runs on the cheapest one you trust. Each gets its own policy, and its own cap.

policies / by agent
3 policies
code-reviewfallback chain
claude-opus-5claude-fable-5cap $400
ticket-triagelatency routed
gemini-3.7-flashgpt-5.6-solcap $120
nightly-batchweighted 80/20
deepseek-v4-flashglm-5.3cap $60

Let a policy pick the model

One string in the model field. The chain behind it is yours to change.

Speak to founders