Auto, TokenLab Verified oder Official: Die Wahl der richtigen Delivery Tier

Als wir eine unerwartete Route sahen, war der Modellname kein hilfreicher Hinweis; die Delivery-Stufe war es. Die Route, über die eine Anfrage bedient wird, kann die Preisberechtigung ändern, selbst wenn das logische Modell gleich bleibt. Genau diese Diskrepanz ist der Grund, warum wir die Delivery-Stufe als Routing-Entscheidung behandeln und nicht als Qualitätsmerkmal. Sie ist wichtig, wenn Preisberechtigung und Routing explizit sein müssen. Sie ist weit weniger wichtig, wenn Ihre Standardrichtlinie bereits Ihren Risiko- und Kostenzielen entspricht.

Wichtige Erkenntnisse

• Eine Anfrage kann über eine official-Route oder eine verified-Route bedient werden. Die Wahl wird pro Anfrage als resolvedDeliveryTier aufgezeichnet (verified oder official, null, wenn der Datensatz älter ist).
• auto ist die Standardrichtlinie, kein dritter Routentyp. Sie behält erreichbare Pfade bei und schätzt vor dem Versand den maximalen Betrag, den die Anfrage kosten kann.
• Die Vererbung von Richtlinien für Workspaces und API-Keys ist die übliche Konfiguration. Beim Produktions-Readback am 11.09.2026 hatten 5.536 Workspaces eine explizite Auto-Richtlinie, 217 erbten den Systemstandard und alle 4.134 API-Keys erbten von ihrem Workspace. Ein späteres Readback in derselben Woche zeigte 219 vererbte Richtlinien. Die Anzahl der expliziten Richtlinien blieb gleich, da es sich bei den vererbten Workspaces um neu erstellte Konten handelte, die noch keine Richtlinie festgelegt hatten. Diese Zahlen stammen aus dem Readback zum Start von TokenLab 2.0, das in internen Release-Probenotizen vom 11.09.2026 aufgezeichnet wurde; betrachten Sie sie als internes Produktions-Readback, nicht als öffentlichen Benchmark.
• Die Berechtigung für Official-Preise erfordert eine exakte Übereinstimmung mit einer Official-Route. Verified-Delivery bleibt verfügbar, wenn keine Official-Route übereinstimmt.
• Sie können die Delivery-Wahl pro Anfrage mit dem Header X-TokenLab-Delivery-Policy überschreiben. Ein Workspace-Standard deckt den Regelfall ab.

Was die drei Delivery-Stufen-Optionen tatsächlich sind

Kanäle deklarieren Delivery-Stufen als VERIFIED und OFFICIAL. Nur Kanäle mit einer aktiven öffentlichen Delivery-Stufe können an eine Organisations-Modellbindung gebunden werden. Ein Workspace kann ein logisches Modell an einen bestimmten Kanal binden. Diese Bindung wird abgelehnt, es sei denn, der Kanal ist aktiv, nicht gelöscht und deklariert eine aktive öffentliche Delivery-Stufe. Eine Route für das Modell auf diesem Kanal muss ebenfalls aktiviert sein.

Official bedeutet, dass die Route über den offiziellen Provider-Pfad bedient wird, während Verified einen von TokenLab verifizierten Pfad bedeutet. Auto ist die Richtlinie, die es dem Router ermöglicht, zwischen erreichbaren Routen zu wählen; wenn wir eine Anfrage nach dem Versand prüfen, gibt uns resolvedDeliveryTier an, ob verified oder official sie bedient hat. Dieses Feld ist null, wenn der Datensatz älter als die Funktion ist.

Was sich ändert, wenn Sie eine Delivery-Stufe wählen

Die Wahl einer Stufe ändert die Preisberechtigung, die Aufzeichnungen pro Anfrage und die Schätzung, die Sie vor dem Versand sehen. Die Preisgestaltung kann pro Delivery-Stufe durch Anpassungsregeln auf Organisationsebene angepasst werden, und diese Anpassung wird normalisiert und validiert, bevor sie angewendet wird. Nach dem Start gelten explizite Verified- oder Official-Wahlen weiterhin, während Anfragen, die vor der Richtlinie liegen, standardmäßig auf Auto gesetzt sind.

Auto schätzt den maximalen Betrag für die Anfrage anstelle eines einzelnen Preises. Es können mehrere Routen erreichbar sein, aber Auto behält jede erreichbare Route bei und verwirft nicht die teurere Route, um die Schätzung niedriger erscheinen zu lassen. In unserer Pipeline prüfen wir die Schätzung vor dem Versand und resolvedDeliveryTier nach Abschluss.

Option	Was wird optimiert	Wann wählen	Was Sie danach verifizieren können
Auto	Erreichbare Routen und maximale Kostenschätzung	Sie möchten, dass die Standardrichtlinie zwischen erreichbaren Routen wählt	resolvedDeliveryTier zeigt die Route, die die Anfrage bedient hat
TokenLab Verified	Zugriff auf TokenLab-verifizierte Pfade, wenn Official nicht verfügbar oder nicht erforderlich ist	Sie benötigen eine verifizierte Route oder es stimmt keine Official-Route überein	resolvedDeliveryTier zeigt verified
Official	Exakte Official-Routenübereinstimmung für offizielle Preisberechtigung	Sie benötigen offizielle Preisberechtigung	resolvedDeliveryTier zeigt official

Wie Teams normalerweise die Delivery-Stufen-Richtlinie konfigurieren

Die Readback-Zahlen in diesem Abschnitt stammen aus dem Readback zum Start von TokenLab 2.0, das in internen Release-Probenotizen vom 11.09.2026 aufgezeichnet wurde; betrachten Sie sie als internes Produktions-Readback, nicht als öffentlichen Benchmark.

Die Standardeinstellung ist Vererbung, nicht eine Zeremonie pro Anfrage. Beim Produktions-Readback am 11.09.2026 sahen wir 5.536 Workspaces mit einer expliziten Auto-Richtlinie, während weitere 217 den Systemstandard erbten. Alle 4.134 API-Keys erbten von ihrem Workspace, sodass alte Clients keinen neuen Header benötigten. Dieses Muster ist sinnvoll, da die Workspace-Richtlinie den Regelfall abdeckt und die Überschreibung pro Anfrage die Ausnahme bleibt.

Ein späteres Readback in derselben Woche zeigte 5.536 explizite und 219 vererbte Richtlinien, während die Anzahl der expliziten gleich blieb und die der vererbten von 217 auf 219 stieg. Bei diesen vererbten Workspaces handelte es sich um neu erstellte Konten, die noch keine Richtlinie festgelegt hatten, daher ändern sich diese Zahlen, wenn Konten erstellt werden. Das Festlegen einer Richtlinie war nie eine Migration, es wurde beim Start kein Massen-Backfill von Workspace- oder Key-Richtlinien durchgeführt, und vererbte Keys benötigten keine Client-Änderung.

Die Bindungsregeln gelten weiterhin, wenn ein Workspace ein logisches Modell an einen bestimmten Kanal bindet. Die Bindung wird abgelehnt, es sei denn, der Kanal ist aktiv, nicht gelöscht und deklariert eine aktive öffentliche Delivery-Stufe. Eine aktivierte Route für das Modell auf diesem Kanal muss ebenfalls existieren. Ein Kanal kann nur an eine Organisations-Modellbindung gebunden werden, während seine Registry-Deklaration ACTIVE ist und sein eigener Datensatz ACTIVE ist, ohne Lösch-Zeitstempel; ein pausierter oder stillgelegter Kanal kann also nicht fixiert werden.

Das Fixieren eines logischen Modells an einen bestimmten Kanal ist die Art und Weise, wie ein Workspace "immer Official" für dieses Modell ausdrückt, ohne einzelne Anfragen zu berühren. Anfragen, die vor der Delivery-Richtlinie liegen, sind standardmäßig auf Auto gesetzt. Es war keine Client-Änderung erforderlich, und beim Start wurde kein Massen-Backfill von Workspace- oder Key-Richtlinien durchgeführt. Für Kontext auf Modellebene kombinieren Sie dies mit dem Model Data Center Guide.

Wie man prüft, welche Delivery-Stufe eine Anfrage bedient hat

Wenn eine Anfrage abgeschlossen ist, lesen Sie resolvedDeliveryTier im Anfragedatensatz; der Wert ist verified oder official, und ein Null-Wert bedeutet, dass der Datensatz älter als das Feld ist. Die Anfrage trägt auch requestedDeliveryPolicy, das aufzeichnet, was der Aufrufer angefordert hat, und ist nullbar, wenn der Workspace-Standard angewendet wurde.

Um die Stufe für eine Anfrage zu überschreiben, fügen Sie den Header X-TokenLab-Delivery-Policy hinzu; die akzeptierten Werte sind auto, verified und official. Hier ist der Header für sich allein:

# Fügen Sie diesen Header zur Claude Sonnet 5 Anfrage hinzu
X-TokenLab-Delivery-Policy: verified

Zum Beispiel zielt dieser cURL-Aufruf auf Claude Sonnet 5 ab und fragt nach official:

curl https://api.tokenlab.sh/v1/chat/completions -H "Authorization: Bearer $TOKENLAB_API_KEY" -H "Content-Type: application/json" -H "X-TokenLab-Delivery-Policy: official" -d '{"model":"Claude Sonnet 5","messages":[{"role":"user","content":"Hello"}]}'

Nach dem Aufruf enthält der Anfragedatensatz für diesen Aufruf:

{
  "requestedDeliveryPolicy": "official",
  "resolvedDeliveryTier": "official"
}

Der Anfragedatensatz enthält auch Nutzungsfelder, und der Request Console Guide zeigt, wo sich dieser Datensatz befindet und wie die aktuellen Feldnamen für die Nutzung lauten.

Wenn die angeforderte Stufe keine aktivierte Route hat, antwortet das Gateway mit delivery_tier_unavailable und greift nicht stillschweigend auf eine andere Stufe zurück. Die Request Console zeigt, wo sich dieser Datensatz befindet, und der Request Console Guide erklärt, wie man ihn findet. Wir beginnen dort, wenn ein Preis oder eine Route unerwartet erscheint, da die Konsole und die Anfragenachweise zeigen können, welche Stufe den Datenverkehr bedient hat.

Wenn Auto eine Delivery-Stufe wählt, die Sie nicht erwartet haben

Wenn Auto eine Stufe wählt, die Sie nicht erwartet haben, lesen Sie resolvedDeliveryTier in der Anfrage und vergleichen Sie es mit den Kanälen, die Ihre Organisation gebunden hat. Binden Sie dann entweder das Modell an den gewünschten Kanal oder überschreiben Sie die Stufe für diese Anfrage. Dies hält die Standardrichtlinie einfach und gibt Ihnen gleichzeitig eine konkrete Möglichkeit, eine überraschende Route zu korrigieren.

Einschränkungen

Die Zahlen hier sind ein Readback zu einem bestimmten Zeitpunkt vom 11.09.2026 und werden sich verschieben. Die Verfügbarkeit der Delivery-Stufe hängt davon ab, welche Routen für Ihr Modell und Ihre Organisation aktiv sind. Eine Workspace-Bindung kann abgelehnt werden, wenn der Kanal inaktiv, gelöscht ist, keine aktive öffentliche Delivery-Stufe hat oder keine aktivierte Route für das Modell besitzt. Die Preisanpassung pro Delivery-Stufe hängt von Ihren eigenen Organisationsregeln ab. Wir können keinen universellen Vergleich anbieten, da die Quelldaten keinen liefern. Die Delivery-Entscheidung wird nach der Routenauswahl getroffen, daher hängt die Stufe, die Sie erhalten, davon ab, welche Routen für Ihre Organisation in diesem Moment aktiviert sind.

FAQ

Was wählt Auto tatsächlich?

Auto ist die Standardrichtlinie, kein dritter Routentyp. Sie behält erreichbare Pfade bei und schätzt vor dem Versand den maximalen Betrag, den die Anfrage kosten kann. Anfragen, die vor der Richtlinie liegen, sind standardmäßig auf Auto gesetzt. Nach dem Versand zeichnet resolvedDeliveryTier auf, ob die Anfrage über eine verified- oder official-Route bedient wurde.

Warum könnte eine Verified-Route mehr kosten als eine Official-Route?

Die Preisgestaltung kann pro Delivery-Stufe durch Anpassungsregeln auf Organisationsebene angepasst werden. Die Anpassung wird normalisiert und validiert, bevor sie angewendet wird. Der Unterschied hängt also von Ihrer Konfiguration ab, und Sie sollten den vor dem Versand angezeigten Preis prüfen.

Muss ich für jede Anfrage eine Delivery-Stufe festlegen?

Nein. Die Vererbung von Richtlinien für Workspaces und API-Keys ist die übliche Konfiguration. Beim Produktions-Readback am 11.09.2026 hatten 5.536 Workspaces eine explizite Auto-Richtlinie, 217 erbten den Systemstandard und alle 4.134 API-Keys erbten von ihrem Workspace. Die Anzahl der vererbten Richtlinien stieg später in dieser Woche auf 219, als neue Konten erstellt wurden. Diese Zahlen stammen aus dem Readback zum Start von TokenLab 2.0, das in internen Release-Probenotizen vom 11.09.2026 aufgezeichnet wurde; betrachten Sie sie als internes Produktions-Readback, nicht als öffentlichen Benchmark. Sie können die Delivery-Wahl pro Anfrage überschreiben, aber ein Workspace-Standard deckt den Regelfall ab.

Woher weiß ich, welche Stufe eine abgeschlossene Anfrage bedient hat?

Lesen Sie resolvedDeliveryTier im Anfragedatensatz. Der Wert ist verified oder official, und er ist null, wenn der Datensatz älter als das Feld ist. requestedDeliveryPolicy zeigt, was der Aufrufer angefordert hat, und ist nullbar, wenn der Workspace-Standard angewendet wurde. Die Request Console und der Request Console Guide zeigen, wo sich dieser Datensatz befindet.

Was passiert, wenn ich eine Stufe ohne aktivierte Route anfordere?

Das Gateway antwortet mit delivery_tier_unavailable. Es greift nicht stillschweigend auf eine andere Stufe zurück. Lesen Sie den Anfragedatensatz, aktivieren Sie dann eine passende Route oder ändern Sie die angeforderte Richtlinie.

Erstellen Sie einen API-Key und vergleichen Sie die Stufe, die Sie erhalten, mit der Stufe, die Sie erwartet haben; der Request Console Guide zeigt, wo sich dieser Datensatz befindet.