Routing policies

Named model chains you address like a model id: policy/<slug> for fallback, load balancing, and cost control.

A routing policy is a named list of models that you address like a single model. Instead of hard-coding bedrock/claude-opus-4-8 in your app, you send policy/eu-prod and Kontinent works down the models you configured: in order, by weight, whatever the policy says.

The policy lives in your organization, not in your code. Swap the models behind it in the console and every request follows the change within seconds, no deploy.

Use the full id, including the policy/ prefix. The console shows it as a copyable chip: policy/eu-prod. That exact string goes into the model field.

What a policy gives you

Your own chain

Cross-vendor fallback you define, not just the built-in per-model routes.

One id in your code

Change models in the console; the request body never changes.

Traffic splitting

Send 90% to a cheap model and 10% to a strong one, by weight.

This is the layer above maximum availability. Built-in failover moves one logical model between providers. A policy moves between different models, including different vendors, because you said so.

Create one

Open Routing policies
In the console, go to Routing → Create policy.
Name it
The name becomes the policy id: EU Prod → policy/eu-prod. The id is generated once and never changes, even if you rename the policy later. The generated id must be unique within your organization, so EU Prod and eu-prod cannot both exist.
Pick a strategy
Fallback, Load balance, or Latency. See below.
Add models
Add models from the catalog panel. For fallback, order them with the arrows. For fallback, set attempts per model (1–5). For load balance, set a weight (1–100).
Use the id
Copy the policy/<slug> chip and send it as model. Live within ~30 seconds of saving.

Strategies

Strategy	Order of models	Per-model setting
Fallback	Top to bottom, exactly as listed. Each model is tried up to `attempts` times in total before moving on.	`attempts` (1–5)
Load balance	Weighted random. A 90/10 pair sends roughly 9 in 10 requests to the first model. The other entries stay in line as fallbacks.	`weight` (1–100)
Latency	Fastest-first, by the median time until each entry's provider sends response headers, measured across all traffic. Ties keep the listed order.	none

A model that fails is never a dead end: whatever the strategy picked first, the remaining entries are still tried: in the listed order for fallback and latency, in weighted random order for load balance. Failover rules are the same as for regular models: 429, 5xx, upstream 401/403 and connection errors move on to the next candidate, always before the first byte reaches you. See Retries & backoff.

Use it

bash

curl https://api.kontinent.ai/v1/chat/completions \
  -H "Authorization: Bearer $KONTINENT_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "policy/eu-prod",
    "messages": [{"role": "user", "content": "Hallo"}]
  }'

python

from openai import OpenAI
 
client = OpenAI(base_url="https://api.kontinent.ai/v1", api_key=KONTINENT_API_KEY)
 
client.chat.completions.create(
    model="policy/eu-prod",
    messages=[{"role": "user", "content": "Hallo"}],
)

Policies work on every endpoint (/v1/chat/completions, /v1/responses, /v1/embeddings, /v1/audio/transcriptions, /v1/audio/speech) and with streaming.

Rules worth knowing

Real model ids always win. If a policy slug collides with a catalog model id, the catalog model is served. A policy can never shadow a real model.
Policies are private to your organization. Another org's slug simply doesn't exist for your key.
Wrong-kind entries are skipped. An embedding model in a policy used for chat is ignored, not an error.
Unavailable models drop out. If a model leaves the catalog, it is skipped and the rest of the chain still serves. The console marks it as no longer available so you can fix the policy.
Guardrails still apply. Key guardrails, allowlists, zero-retention requirements, and sovereignty segments are enforced after the policy expands. A policy cannot route around them. If every entry is blocked, the request is refused.
A policy is an explicit override. Only the models you listed are used; the built-in provider fallbacks of those models are not silently appended.
Usage is billed to the model that served. The usage record keeps both: model is policy/eu-prod, served_model is the model that actually ran, and spend is attributed to the latter.

Troubleshooting

Symptom	Cause
`404 model_not_found`	Wrong id or wrong org. Copy the chip from the console. The id is `policy/<slug>`, e.g. `policy/eu-prod`.
Change had no effect	The catalog snapshot refreshes about every 30 seconds. Retry shortly after saving.
A model in the policy never runs	It is a different kind (embedding vs. chat), disabled in the catalog, or blocked by the key's guardrail.
`502` / `429` although models remain	Every entry in the chain failed. See Handling errors.

Deleting a policy stops resolving its id within about 30 seconds. Requests still sending policy/<slug> will get 404 model_not_found.

A policy is an explicit chain you address as policy/<slug>. For a router that classifies each request and picks among a pool you configured, see Price & performance.