Maximum availability
How Kontinent keeps requests working when a provider fails, and how to make any model fail-safe.
Kontinent commits to at least 99% platform availability per calendar month in its terms of use (section 7, German). That covers Kontinent itself, not the individual providers and models behind it. Whether a model keeps answering when its provider fails depends on two mechanisms: standby routes that Kontinent maintains for many models, and routing policies that you define for any model you depend on.
Standby routes in the catalog
Many models in the catalog are served by more than one provider. For those, Kontinent keeps a primary route and a standby route on another provider. On each request it tries the primary first and moves to the standby when the primary cannot answer.
| Model | Primary | Standby |
|---|---|---|
mistral/mistral-medium-3.5 | Mistral | Scaleway |
Not every model has a standby route. Some models are offered by only one provider in the EU, and for those there is nothing to fail over to. Most models on AWS Bedrock, Claude among them, have no second provider, but Kontinent falls back between Bedrock's Frankfurt and Ireland regions.
The catalog does not list a model's standby route today. You see it afterwards: X-Provider and X-Served-Model on the response name the route that actually answered (see Request & response headers), and the request detail in the logs shows which provider failed and which one served.
Make any model fail-safe with a routing policy
If a use case must not stop when one provider fails, do not rely on the catalog. Define a routing policy with your own fallback models, ideally on different providers, and send policy/<slug> as the model:
- It works for every model, including the ones without a standby route.
- You decide the order and how often each model is tried.
- Changing the chain in the console takes effect within seconds, without a deploy.
This is the reliable way to get failover for a model you depend on.
When does a request fail over?
If an upstream returns 429, a 5xx, rejects Kontinent's own credentials with 401/403, or fails to connect, Kontinent tries the next route, transparently, before any bytes reach you. This applies to standby routes and to the models in a routing policy alike.
For streaming requests, failover happens before the first byte is streamed. Once the first token is out, an upstream failure surfaces as a terminal error mid-stream, so handle a truncated stream gracefully. See Streaming.
When no route is left, the request fails with the error of the last attempt: usually 502 upstream_error or 503 no_provider_available, also 429 upstream_rate_limited or 502 upstream_auth_error. See Handling errors.
What you don't have to build
No failover glue
Switching to the next route lives in the gateway, not your app. It happens immediately, without waiting between attempts.
No provider juggling
One id resolves to whichever route is healthy right now.
Rate limiting is fail-open: if our limiter's backing store has trouble, your requests are never blocked by it. A separate 429 upstream_rate_limited means a provider throttled us, so retry with backoff. See Rate limits & credits.