Provider Routing

The AI Gateway can route requests across compatible provider endpoints and try another eligible route when a provider request fails.

The Problem

Provider Outages

Provider downtime breaks your app and frustrates users

Rate Limits

Hit provider quotas and block your users from accessing your service

Regional Restrictions

Limited availability in certain regions reduces your global reach

Vendor Lock-in

Tied to one provider prevents cost optimization and flexibility

The Solution

Provider routing can make the same model available through multiple providers. When an eligible route returns a retryable error, the gateway can try another configured route without changing the client request.

Using Provider Routing

Zero configuration required. Just request a model:

const response = await client.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [{ role: "user", content: "Hello!" }],
});

That’s it. The gateway automatically:

Finds all providers offering this model
Routes to the cheapest available provider
Tries another eligible route for configured retryable errors

This reduces the number of provider-specific failures your application must handle directly. Your application should still implement timeouts and handle gateway errors.

How It Works

The gateway uses the Model Registry to find all providers supporting your requested model, then applies smart routing: Routing Priority:

Your provider keys (BYOK) if configured
Planck’s managed keys (credits), using the published model or route price

Selection: Routes to the cheapest provider first. Equal-cost providers are load balanced. Failover: Tries the next eligible provider route for configured retryable errors.

What are credits?

Credits provide managed access to supported models without requiring a separate account for every provider. Add funds to your Planck account and the gateway uses eligible managed provider routes. Learn more about credits.

OpenRouter

OpenRouter can serve the same model through several upstream providers, each with different prices and capabilities. Keep using your Planck API key and base URL, and choose the route in the request’s model string.

Model string	Behavior
`openrouter/sonnet-4.6`	Let OpenRouter choose the upstream.
`openrouter/sonnet-4.6?via=bedrock`	Use Amazon Bedrock’s global endpoint through OpenRouter.
`openrouter/sonnet-4.6?zdr`	Let OpenRouter choose among eligible ZDR endpoints.
`openrouter/sonnet-4.6?via=bedrock&zdr`	Use the Bedrock endpoint and require ZDR.

sonnet-4.6 is an alias for anthropic/claude-sonnet-4.6; other models can use their full OpenRouter ID, such as openrouter/openai/gpt-6-astra. The suffix belongs inside the model value, not in the API URL.

curl https://api.inquantum.ai/v1/chat/completions \
  -H "Authorization: Bearer $PLANCK_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openrouter/sonnet-4.6?via=bedrock&zdr",
    "messages": [{"role": "user", "content": "Explain vector search briefly."}]
  }'

These options support text generation through Planck’s standard POST /v1/chat/completions and POST /v1/responses routes. Use the same string in an OpenAI-compatible SDK’s model argument. Planck’s Chat page also supports these selections.

Choose in the chat picker

Click the chevron to the left of an OpenRouter model’s icon to compare its upstream prices and context limits. Click a provider row to select it, or Automatic to let OpenRouter choose. The ZDR button filters eligible choices and requires upstream ZDR when you select one, including Automatic. Chat browsing excludes dedicated batch variants and image generators. Use the Image tab for image generation models and their image, image-token, or megapixel prices.

Pricing and credentials

With Planck credits, Automatic uses the model’s published automatic rate; an explicit upstream uses that route’s published rate. Automatic pricing covers multiple possible upstreams, so selecting a specific route can change the price. Adding ?zdr to Automatic keeps the automatic rate. Compare the displayed input and output rates and their units before choosing. Requests still go through OpenRouter. If you use BYOK, configure an OpenRouter key in Provider Settings, including when the selected upstream is Bedrock or another provider.

ZDR and request details

?zdr requires OpenRouter to use a Zero Data Retention endpoint. Planck checks route eligibility and sends the requirement to OpenRouter. It does not fall back to a non-ZDR endpoint to satisfy the request. OpenRouter account privacy restrictions still apply. See OpenRouter’s ZDR documentation. Upstream ZDR governs inference at the selected endpoint. Planck’s request logging and retention are configured separately; this option does not establish HIPAA eligibility. See Data privacy and compliance. In Requests, the provider appears as OpenRouter → Amazon Bedrock, for example, when OpenRouter reports who served the request. The request details distinguish that reported provider from the requested upstream and the ZDR requirement. Without a reported provider, the label remains OpenRouter.

Full endpoint names and explicit fallbacks

bedrock is an alias for amazon-bedrock/global. Full endpoint tags work too:

openrouter/anthropic/claude-sonnet-4.6?via=amazon-bedrock/global&zdr=true

upstream is accepted as an alias for via, and zdr=true is equivalent to bare zdr. A slash in the upstream value can also be encoded as %2F.A provider family such as via=openai covers its eligible standard endpoints. A tag such as via=openai/fast selects that service tier when available. Family selection excludes fast, flex, and priority tiers unless explicitly selected. A family selection uses its published family rate, whichever member serves the request. See OpenRouter provider selection.A pinned route disables OpenRouter fallback outside the selected upstream. For an explicit API fallback chain, pin every entry to an OpenRouter upstream:

openrouter/sonnet-4.6?via=bedrock&zdr,openrouter/sonnet-4.6?via=google-vertex/global&zdr

The gateway tries these targets in order for eligible failures, using each route’s price. If any entry requires ZDR, every attempt must satisfy it. An automatic or non-OpenRouter route cannot be appended to a pinned chain. The chat picker selects one route; fallback chains are an API feature.Configure routing in the model string. Combining these options with custom targets or an OpenRouter-native provider request-body object is unsupported.

Advanced: Customizing Routing

The default routing handles most use cases. Customize only if you need specific control:

Lock to Specific Provider

Force requests to only use one provider by adding the provider name after a slash:

model: "gpt-4o-mini/openai"; // Only route through OpenAI

When to use: Compliance requirements mandate a specific provider, or you’re testing provider-specific features. What happens: The gateway only attempts this provider. No automatic failover to other providers.

Use Your Own Deployment

Target a specific deployment you’ve configured in Provider Settings:

model: "gpt-4o-mini/azure/clm1a2b3c"; // Your Azure deployment ID

When to use: You want to target a configured deployment or use provider credits. What happens: Requests only go through your configured deployment. The deployment ID (CUID) is shown in your Provider Settings.

Manual Fallback Chain

Specify exactly which providers to try, in order:

model: "gpt-4o-mini/azure,gpt-4o-mini/openai,gpt-4o-mini";

When to use: You want to prioritize your Azure credits, fall back to OpenAI if Azure fails, then try all other providers. What happens: Gateway tries each provider in the exact order you specify.

Bring Your Own Keys (BYOK)

Add your provider API keys in Provider Settings: What happens: Your keys are always tried first, then Planck’s managed keys as fallback. This gives you control over provider accounts while maintaining reliability. Benefits: Use provider credits, meet compliance requirements, or maintain direct provider relationships while still getting automatic failover.

The gateway forwards any model/provider combination, even models not yet in our registry. Unknown models only route through your BYOK deployments.

Exclude Specific Providers

Prevent automatic routing from using specific providers:

model: "!openai,gpt-4o-mini"; // Use any provider EXCEPT OpenAI

When to use: Known provider issues, compliance restrictions, or testing without certain providers. What happens: The gateway tries all available providers except those you’ve excluded. Exclude multiple providers with commas: "!openai,!anthropic,gpt-4o-mini".

Failover Triggers

The gateway automatically tries the next provider when encountering these errors:

Error	Description
429	Rate limit errors
401	Authentication errors
400	Context length errors
408	Timeout errors
500+	Server errors

Real World Examples

Scenario: OpenAI Outage

Your production app uses GPT-4. OpenAI goes down at 3am.

// Your code doesn't change
const response = await client.chat.completions.create({
  model: "gpt-4o-mini",
  messages: [{ role: "user", content: "Process this customer request" }],
});

What happens: Gateway automatically fails over to Azure OpenAI, then AWS Bedrock if needed. Your app stays online, customers never notice.

Scenario: Using Azure Credits

Your company has $100k in Azure credits to burn before year-end.

// Prioritize Azure but keep fallback for reliability
const response = await client.chat.completions.create({
  model: "gpt-4o-mini/azure,gpt-4o-mini",
  messages: messages,
});

What happens: Tries your Azure deployment first (using credits), but falls back to other providers if Azure fails. Balances credit usage with reliability.

Scenario: Avoiding Provider Issues

You notice one provider is experiencing higher latency or errors today.

// Exclude the problematic provider from automatic routing
const response = await client.chat.completions.create({
  model: "!openai,gpt-4o-mini",
  messages: [{ role: "user", content: "Analyze this data" }],
});

What happens: Gateway automatically routes to all available providers except OpenAI. If you also want to exclude another provider, use "!openai,!anthropic,gpt-4o-mini".

Next Steps

Browse Models

Explore all available models and providers

Add Provider Keys

Connect your provider accounts

Prompt Management

Combine routing with managed prompts

Get Started

Models & Inference

Reliability & Controls

Observability

Prompt Management

Integrations

Provider Routing

The Problem

Provider Outages

Rate Limits

Regional Restrictions

Vendor Lock-in

The Solution

Using Provider Routing

How It Works

OpenRouter

Choose in the chat picker

Pricing and credentials

ZDR and request details

Advanced: Customizing Routing

Lock to Specific Provider

Use Your Own Deployment

Manual Fallback Chain

Bring Your Own Keys (BYOK)

Exclude Specific Providers

Failover Triggers

Real World Examples

Scenario: OpenAI Outage

Scenario: Using Azure Credits

Scenario: Avoiding Provider Issues

Next Steps

Browse Models

Add Provider Keys

Prompt Management

​The Problem

Provider Outages

Rate Limits

Regional Restrictions

Vendor Lock-in

​The Solution

​Using Provider Routing

​How It Works

​OpenRouter

​Choose in the chat picker

​Pricing and credentials

​ZDR and request details

​Advanced: Customizing Routing

​Lock to Specific Provider

​Use Your Own Deployment

​Manual Fallback Chain

​Bring Your Own Keys (BYOK)

​Exclude Specific Providers

​Failover Triggers

​Real World Examples

​Scenario: OpenAI Outage

​Scenario: Using Azure Credits

​Scenario: Avoiding Provider Issues

​Next Steps

Browse Models

Add Provider Keys

Prompt Management

The Problem

The Solution

Using Provider Routing

How It Works

OpenRouter

Choose in the chat picker

Pricing and credentials

ZDR and request details

Advanced: Customizing Routing

Lock to Specific Provider

Use Your Own Deployment

Manual Fallback Chain

Bring Your Own Keys (BYOK)

Exclude Specific Providers

Failover Triggers

Real World Examples

Scenario: OpenAI Outage

Scenario: Using Azure Credits

Scenario: Avoiding Provider Issues

Next Steps