> For the complete documentation index, see [llms.txt](https://docs.kontinent.ai/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.kontinent.ai/documentation/dokumentation/models-and-routing/routing-policies.md).

# Routing-Policies

Eine **Routing-Policy** ist eine benannte Liste von Modellen, die Sie wie ein einzelnes Modell ansprechen. Statt `anthropic/claude-opus-4.8` fest in Ihre Anwendung zu schreiben, senden Sie `policy/eu-prod`, und Kontinent arbeitet die konfigurierten Modelle ab — der Reihe nach, gewichtet, ganz wie die Policy es vorgibt.

Die Policy gehört Ihrer Organisation, nicht Ihrem Code. Tauschen Sie die Modelle dahinter in der Konsole aus, und jede Anfrage folgt der Änderung innerhalb von Sekunden — ohne Deployment.

{% hint style="success" %}
**Verwenden Sie die vollständige ID inklusive `policy/`-Präfix.** Die Konsole zeigt sie als kopierbaren Chip: `policy/eu-prod`. Genau diese Zeichenkette gehört ins Feld `model`.
{% endhint %}

## Was eine Policy bringt

<table data-view="cards"><thead><tr><th></th><th></th><th></th></tr></thead><tbody><tr><td><h4><i class="fa-list-ol" style="color:$primary;">:list-ol:</i></h4></td><td><strong>Ihre eigene Kette</strong></td><td>Anbieterübergreifender Fallback, den Sie definieren — nicht nur die eingebauten Routen pro Modell.</td></tr><tr><td><h4><i class="fa-code" style="color:$primary;">:code:</i></h4></td><td><strong>Eine ID im Code</strong></td><td>Modelle in der Konsole ändern; der Request-Body bleibt gleich.</td></tr><tr><td><h4><i class="fa-scale-balanced" style="color:$primary;">:scale-balanced:</i></h4></td><td><strong>Traffic aufteilen</strong></td><td>90 % auf ein günstiges Modell, 10 % auf ein starkes — über Gewichte.</td></tr></tbody></table>

Das ist die Ebene *über* [maximaler Verfügbarkeit](/documentation/dokumentation/models-and-routing/availability.md). Das eingebaute Failover verschiebt ein logisches Modell zwischen Anbietern. Eine Policy wechselt zwischen **verschiedenen Modellen** — auch verschiedener Anbieter —, weil Sie es so festgelegt haben.

## Policy anlegen

{% stepper %}
{% step %}

### Routing-Policies öffnen

In der Konsole: **Routing** → **Policy erstellen**.
{% endstep %}

{% step %}

### Benennen

Der Name wird zur Policy-ID: `EU Prod` → `policy/eu-prod`. Die ID wird einmal erzeugt und ändert sich **nie**, auch nicht beim Umbenennen. Namen müssen innerhalb der Organisation eindeutig sein.
{% endstep %}

{% step %}

### Strategie wählen

**Fallback**, **Lastverteilung** oder **Latenz** — siehe [unten](#strategien).
{% endstep %}

{% step %}

### Modelle hinzufügen

Modelle aus dem Katalogpanel hinzufügen und mit den Pfeilen sortieren. Bei Fallback setzen Sie **Versuche** pro Modell (1–5), bei Lastverteilung ein **Gewicht** (1–100).
{% endstep %}

{% step %}

### ID verwenden

Den Chip `policy/<slug>` kopieren und als `model` senden. Rund 30 Sekunden nach dem Speichern aktiv.
{% endstep %}
{% endstepper %}

## Strategien

| Strategie          | Reihenfolge der Modelle                                                                                                                       | Einstellung pro Modell |
| ------------------ | --------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------- |
| **Fallback**       | Von oben nach unten, genau wie gelistet. Jedes Modell wird `attempts`-mal versucht, bevor die Kette weitergeht.                               | `attempts` (1–5)       |
| **Lastverteilung** | Gewichteter Zufall. Ein 90/10-Paar schickt rund 9 von 10 Anfragen zum ersten Modell — die übrigen Einträge bleiben als Fallback in der Kette. | `weight` (1–100)       |
| **Latenz**         | Schnellstes zuerst. Aktuell in der gelisteten Reihenfolge, solange Latenzdaten erhoben werden.                                                | —                      |

Ein fehlschlagendes Modell ist nie eine Sackgasse: Was die Strategie auch zuerst wählt, die restlichen Einträge werden weiterhin der Reihe nach versucht. Es gelten dieselben Failover-Regeln wie für normale Modelle — `429`, `5xx` und Verbindungsfehler führen zum nächsten Kandidaten, immer **vor dem ersten Byte**. Siehe [Wiederholungen & Backoff](/documentation/dokumentation/best-practices/retries-and-backoff.md).

## Verwendung

{% tabs %}
{% tab title="curl" %}

```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"}]
  }'
```

{% endtab %}

{% tab title="Python" %}

```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"}],
)
```

{% endtab %}
{% endtabs %}

Policies funktionieren auf `/v1/chat/completions` und `/v1/embeddings` sowie mit Streaming.

## Regeln, die Sie kennen sollten

* **Echte Modell-IDs gewinnen immer.** Kollidiert ein Policy-Slug mit einer Katalog-Modell-ID, wird das Katalogmodell bedient. Eine Policy kann ein echtes Modell nie überdecken.
* **Policies gehören einer Organisation.** Der Slug einer anderen Organisation existiert für Ihren Key schlicht nicht.
* **Einträge des falschen Typs werden übersprungen.** Ein Embedding-Modell in einer Chat-Anfrage wird ignoriert, nicht als Fehler behandelt.
* **Nicht verfügbare Modelle fallen heraus.** Verlässt ein Modell den Katalog, wird es übersprungen; die restliche Kette bedient weiter. Die Konsole markiert es als *nicht mehr verfügbar*.
* **Guardrails gelten weiterhin.** Key-Guardrails, Allowlists, Zero-Retention-Vorgaben und Souveränitätssegmente greifen *nach* dem Auflösen der Policy. Eine Policy kann sie nicht umgehen — ist jeder Eintrag blockiert, wird die Anfrage abgelehnt.
* **Eine Policy ist eine explizite Übersteuerung.** Es werden nur die gelisteten Modelle genutzt; die eingebauten Anbieter-Fallbacks dieser Modelle werden nicht stillschweigend angehängt.
* **Abgerechnet wird das bedienende Modell.** Der Usage-Datensatz hält beides fest: `model` ist `policy/eu-prod`, `served_model` das tatsächlich ausgeführte Modell — und die Kosten laufen auf Letzteres.

## Fehlersuche

| Symptom                              | Ursache                                                                                                                      |
| ------------------------------------ | ---------------------------------------------------------------------------------------------------------------------------- |
| `404 model_not_found`                | Falsche ID oder falsche Organisation. Chip aus der Konsole kopieren — die ID lautet `policy/<slug>`, z. B. `policy/eu-prod`. |
| Änderung wirkt nicht                 | Der Katalog-Snapshot wird etwa alle 30 Sekunden aktualisiert. Kurz nach dem Speichern erneut versuchen.                      |
| Ein Modell der Policy läuft nie      | Falscher Typ (Embedding statt Chat), im Katalog deaktiviert oder vom Guardrail des Keys blockiert.                           |
| `502` / `429` trotz weiterer Modelle | Alle Einträge der Kette sind fehlgeschlagen. Siehe [Fehler behandeln](/documentation/dokumentation/features/errors.md).      |

{% hint style="info" %}
Beim Löschen einer Policy wird ihre ID sofort ungültig. Anfragen mit `policy/<slug>` erhalten dann `404 model_not_found`.
{% endhint %}

Eine Policy ist eine explizite Kette, die Sie als `policy/<slug>` adressieren. Für einen Router, der jede Anfrage klassifiziert und unter einem von Ihnen konfigurierten Pool wählt, siehe [Preis & Performance](/documentation/dokumentation/models-and-routing/price-performance.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.kontinent.ai/documentation/dokumentation/models-and-routing/routing-policies.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.
