Auswahl eines TokenLab Delivery Tiers: Auto, Verified oder Official

Eine Anfrage kann mit einem 503-Fehler fehlschlagen, obwohl die Modell-ID vollkommen gültig ist. Die Ursache ist oft die von Ihnen festgelegte Delivery Tier. In unserer Pipeline stießen wir darauf, als wir eine Option für ein Modell erzwangen, das diese nicht anbot. Dieser Leitfaden erläutert die drei Delivery-Tier-Optionen, die Reihenfolge, in der die Einstellungen angewendet werden, und was jede einzelne für Ihre Abrechnung bedeutet. Alle nachstehenden Fakten stammen aus der TokenLab-Dokumentation und der Live-Modell-API, beobachtet am 03.10.2026.

Wichtige Erkenntnisse

• Eine Delivery Tier hat drei Werte: auto, verified und official.
• Ein Request-Header überschreibt die API-Key-Einstellung, welche wiederum den Workspace-Standard überschreibt.
• Wenn für die angeforderte Option kein Angebot verfügbar ist, erhalten Sie 503 delivery_tier_unavailable. Wenn retryable auf false steht, senden Sie dieselbe Anfrage nicht erneut.
• Sie zahlen einmalig für die Option, die die Anfrage abgeschlossen hat.
• Prüfen Sie GET /v1/models/{model}, bevor Sie eine Tier festlegen. Dies ist öffentlich und erfordert keinen Key.

Die drei Delivery-Tier-Optionen

Die API-Referenz (beobachtet am 03.10.2026) definiert drei Optionen:

• Auto verwendet TokenLab Verified, falls verfügbar, andernfalls Official. Sie zahlen für die Option, die Ihre Anfrage abschließt.
• TokenLab Verified ist eine von TokenLab verifizierte Bereitstellung. Es gelten die TokenLab-Preise.
• Official basiert auf dem öffentlichen Preis des Modellherstellers. Der auf TokenLab angezeigte Preis ist der, den Sie zahlen.

Generierungsanfragen akzeptieren den Header X-TokenLab-Delivery-Policy: auto | verified | official. Ein ungültiger Header-Wert gibt 400 zurück.

Welche Einstellung hat Vorrang

Die Delivery Tier kann an drei Stellen festgelegt werden. Die dokumentierte Reihenfolge ist:

1. Der Request-Header.
2. Die API-Key-Einstellung.
3. Der Workspace-Standard.

Der Header überschreibt den Key, und der Key überschreibt den Workspace. Echtzeit-Sitzungen sind die Ausnahme: Sie verwenden die API-Key- oder Workspace-Einstellung und akzeptieren keine Überschreibung per Query-String.

Festlegen der Delivery Tier für eine Anfrage

Hier ist ein Chat-Completions-Aufruf, der die Official-Bereitstellung festlegt. Die Modell-ID claude-sonnet-5 ist in der Live-Modell-API mit beiden verfügbaren Optionen gelistet. Siehe die Modellseite.

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

Derselbe Header funktioniert auch für den Anthropic Messages-Endpunkt. Für /v1/messages kann der Key-Header x-api-key lauten, was laut API-Referenz von Anthropic Messages akzeptiert wird.

curl https://api.tokenlab.sh/v1/messages \
  -H "x-api-key: $TOKENLAB_API_KEY" \
  -H "anthropic-version: 2023-06-01" \
  -H "Content-Type: application/json" \
  -H "X-TokenLab-Delivery-Policy: verified" \
  -d '{
    "model": "claude-sonnet-5",
    "max_tokens": 512,
    "messages": [{"role": "user", "content": "Hello!"}]
  }'

Festlegen der Delivery Tier für einen API-Key

Um eine Delivery Tier als Standard für einen Key festzulegen, verwenden Sie die Management-API mit einem Management-Token (mt-...). Die Seiten Create API Key und Update API Key (beide beobachtet am 03.10.2026) dokumentieren ein deliveryPolicy-Feld. Die Werte sind auto, verified, official oder null. Ein null-Wert übernimmt die Workspace-Richtlinie.

Dieser Entwurf folgt der dokumentierten PATCH-Form. Die Key-ID ist der Beispielwert aus der Dokumentation.

curl -X PATCH "https://api.tokenlab.sh/v1/management/api-keys/key_abc123def456" \
  -H "Authorization: Bearer mt-your-management-token" \
  -H "Content-Type: application/json" \
  -d '{
    "deliveryPolicy": "verified"
  }'

Ein Update erfordert mindestens ein Feld, daher ist dieser Body für sich genommen gültig. Antworten melden die Einstellung als delivery_policy, wobei null bedeutet, dass der Key den Workspace-Standard erbt. Der Create-Endpunkt akzeptiert dasselbe deliveryPolicy-Feld im Request-Body. Das Weglassen beim Erstellen ist konsistent mit der dokumentierten null-Vererbung, da die Beispielantwort beim Erstellen delivery_policy: null zeigt.

Wenn die angeforderte Option nicht verfügbar ist

Wenn für die von Ihnen angeforderte Option kein Angebot verfügbar ist, gibt TokenLab 503 delivery_tier_unavailable und eine Request-ID zurück. Der Leitfaden zur Fehlerbehandlung (beobachtet am 03.10.2026) erklärt, wie man retryable liest.

Ein 5xx-Status bedeutet nicht immer einen vorübergehenden Ausfall. Wenn der ausgewählte Vorgang in dieser Tier kein Angebot hat, ist retryable auf false gesetzt und retry_after wird weggelassen. Wiederholen Sie dieselbe Anfrage nicht unverändert. Stattdessen:

1. Lesen Sie code und retryable, nicht die menschenlesbare message.
2. Speichern Sie die Request-ID aus den Antwort-Headern.
3. Prüfen Sie die Verfügbarkeit der Modell-Bereitstellung mit GET /v1/models, bevor Sie ein anderes Modell oder eine andere Tier wählen.

Der Leitfaden warnt davor, dass ähnliche Modellnamen keine Verfügbarkeit garantieren. Ein Client sollte basierend auf dem code verzweigen und einen 5xx-Fehler nur dann wiederholen, wenn retryable auf true steht, wobei retry_after zu beachten und die Anzahl der Versuche zu begrenzen ist.

Prüfen, welche Optionen ein Modell hat

Der Modell-Endpunkt meldet die delivery availability by option. Diese Werte stammen aus der Live-Modell-API, beobachtet am 03.10.2026:

Modell-ID	Verified	Official	Modellseite
claude-sonnet-5	true	true	/models/claude-5/claude-sonnet-5
gpt-5.6-terra	true	true	/models/gpt-5-6/gpt-5.6-terra
deepseek-v4-flash	false	true	/models/deepseek-v4/deepseek-v4-flash

Zum Beispiel würde das Festlegen von verified für deepseek-v4-flash zu delivery_tier_unavailable führen, da die API heute kein Verified-Angebot meldet. Official und Auto bleiben dort gültig.

Prüfen Sie jedes Modell selbst:

curl "https://api.tokenlab.sh/v1/models/deepseek-v4-flash"

Die Verfügbarkeit wird bei jeder Anfrage geprüft, und der Billing-Leitfaden besagt, dass Delivery-Labels die unterstützten Optionen beschreiben. Betrachten Sie die Modell-API als Momentaufnahme und lesen Sie sie erneut, bevor Sie eine Tier fest kodieren.

Wie sich die Wahl auf Ihre Kosten auswirkt

Der Billing-Leitfaden (beobachtet am 03.10.2026) besagt, dass jede abgeschlossene Anfrage einmalig für die Option berechnet wird, die das Ergebnis geliefert hat:

• TokenLab Verified verwendet die öffentlichen Preise von TokenLab.
• Official verwendet die Official-Preisstufe basierend auf dem öffentlichen Preis des Modellherstellers.
• Auto berechnet die Option, die die Anfrage abschließt.

Bei kostenpflichtigen Generierungen zeigt die Konsole vor der Bestätigung eine maximale Schätzung an, und die Nutzung (Usage) zeigt die endgültige Abrechnung. Nicht genutzte reservierte Beträge werden freigegeben. Auf der Modellseite bedeutet ein Bindestrich in der TokenLab-Preisspalte, dass derzeit kein Verified-Angebot verfügbar ist. Es bedeutet nicht, dass es kostenlos ist.

Der Leitfaden dokumentiert keine feste Preisdifferenz zwischen Verified und Official, daher werden wir keine solche behaupten. Für den aktuellen TokenLab-Preis für claude-sonnet-5 listet die Modell-API den Input bei 0,9 USD und den Output bei 4,5 USD pro 1 Mio. Token (Preise aktualisiert am 02.10.2026). Als Schätzung: 100.000 Input-Token plus 10.000 Output-Token ergeben 0,09 + 0,045 = 0,135 USD. Dieser Wert verwendet nur den gelisteten TokenLab-Preis. Lesen Sie den Official-Preis auf der Modellseite, bevor Sie vergleichen.

Ein kurzer Entscheidungsleitfaden

• Standardmäßig Auto, wenn Sie möchten, dass die Anfrage abgeschlossen wird und Sie beide Preisstufen akzeptieren können.
• Verified festlegen, wenn Sie TokenLab-Preise benötigen und das Modell verified: true meldet.
• Official festlegen, wenn Sie die öffentliche Preisbasis des Modellherstellers benötigen oder wenn das Modell kein Verified-Angebot hat.
• Key-Standard festlegen für Worker, die immer dieselbe Tier benötigen, und verwenden Sie den Header für einmalige Ausnahmen.

Bevor Sie eine Festlegung treffen, lesen Sie GET /v1/models/{model}. Führen Sie einen kleinen Test durch und bestätigen Sie die Abrechnung unter Usage.

Nächster Schritt: Einen Key mit einer Delivery-Richtlinie erstellen

Erstellen Sie einen API-Key in der Konsole oder rufen Sie POST /v1/management/api-keys mit einem Management-Token auf und setzen Sie deliveryPolicy im Body, wie auf der Seite Create API Key beschrieben. Senden Sie dann eine kleine Anfrage mit dem oben genannten Header und prüfen Sie die Abrechnung unter Usage.

FAQ

Welche Einstellung gewinnt, wenn Header, API-Key und Workspace widersprüchlich sind?

Der Request-Header gewinnt. Die API-Key-Einstellung überschreibt den Workspace-Standard. Echtzeit-Sitzungen ignorieren den Header und verwenden die Key- oder Workspace-Einstellung.

Warum habe ich 503 delivery_tier_unavailable erhalten und sollte ich es erneut versuchen?

Die von Ihnen angeforderte Tier hat für diesen Vorgang kein Angebot. Lesen Sie retryable: Wenn es false ist, senden Sie dieselbe Anfrage nicht erneut. Prüfen Sie die Verfügbarkeit mit GET /v1/models und ändern Sie die Tier oder das Modell.

Kostet Official mehr als TokenLab Verified?

Die Dokumentation nennt keinen festen Unterschied. Verified verwendet die öffentlichen Preise von TokenLab, und Official verwendet die öffentliche Preisbasis des Modellherstellers. Vergleichen Sie beide auf der Modellseite und bestätigen Sie die endgültige Abrechnung unter Usage.

Wie sehe ich, welche Delivery-Optionen ein Modell unterstützt?

Rufen Sie GET /v1/models/{model} auf, was keinen Key erfordert. Heute melden claude-sonnet-5 und gpt-5.6-terra Verified und Official, während deepseek-v4-flash nur Official meldet.

Kann ich eine Delivery-Option für Echtzeit-Sitzungen festlegen?

Ja, über die API-Key- oder Workspace-Einstellung. Echtzeit-Sitzungen akzeptieren keine Überschreibung per Query-String.

Erstellen Sie Ihren TokenLab API-Key in der Konsole