Übersicht
Die Agent-First API von TokenLab ergänzt Fehlermeldungen um strukturierte Hinweise, die KI-Agenten sofort parsen und umsetzen können — keine Websuchen, keine Dokumentationsrecherche, kein Rätselraten. OpenAI-kompatible Gateway-Fehler von Chat Completions und Responses können optionale Felder wiedid_you_mean, suggestions, hint, retryable und retry_after im error-Objekt enthalten. Anthropic Messages und Gemini behalten ihre nativen Fehlerformen und versprechen diese Erweiterungen nicht.
Felder für Fehlerhinweise
Bei OpenAI-kompatiblen Gateway-Fehlern sind alle Hinweisfelder optionale Erweiterungen innerhalb deserror-Objekts:
Beispiele für Fehlercodes
model_not_found (400)
Wenn ein Modellname keinem aktiven Modell entspricht:did_you_mean verwendet:
- Statische Aliaszuordnung (aus produktiven Fehlerdaten)
- Normalisierte String-Übereinstimmung (entfernt Bindestriche, Groß-/Kleinschreibung wird ignoriert)
- Edit-Distanz-Abgleich (Schwelle ≤ 3)
did_you_mean, suggestions und hint und versuche es dann mit einem unterstützten öffentlichen Modell erneut.
insufficient_balance (402)
Wenn das Kontoguthaben für die geschätzten Kosten zu niedrig ist:suggestions enthält Modelle, die günstiger sind als die geschätzten Kosten und auf die der Agent wechseln kann.
all_channels_failed (503)
Wenn alle Upstream-Kanäle für ein Modell nicht verfügbar sind:retryable ist false, wenn der Grund no_channels ist (keine Kanäle für dieses Modell konfiguriert). Es ist nur bei transienten Fehlern wie Circuit-Breaker-Auslösungen oder erschöpfter Quote auf true gesetzt.rate_limit_exceeded (429)
retry_after wird aus dem tatsächlichen Reset-Zeitpunkt des Rate-Limit-Fensters berechnet.
OpenAI-kompatible Endpunkte verwenden TokenLab’s stabile öffentliche Fehlertypen wie
rate_limit_exceeded, upstream_error und all_channels_failed. Anthropic-kompatible und Gemini-kompatible Endpunkte verwenden ihre eigenen nativen Antwortformen.context_length_exceeded (400)
Wenn die Eingabe das Kontextfenster des Modells überschreitet (Upstream-Fehler, mit Hinweisen angereichert):Erkennung nativer Endpoints
Leiten Sie die Verfügbarkeit eines nativen Protokolls weder aus dem Modell- oder Anbieternamen noch aus Chat-Antwort-Headern ab. Lesen Sie vor der Wahl eines nativen EndpointsGET /v1/models/{model} und verwenden Sie nur ein Anfrageformat, das in den Modelldetails ausgewiesen ist und über eine Route mit demselben Protokoll verfügt.
Das maßgebliche Feld ist tokenlab.accepted_request_formats.
Ein ausgewiesenes Anfrageformat bestimmt die Verfügbarkeit des Endpoints; die Unterstützung einzelner Felder und Tools bleibt vom Upstream abhängig.
Verbesserungen bei /v1/models
/v1/models enthält jetzt nicht-chatbezogene Empfehlung-Metadaten, die Agenten vor dem Aufruf von Bild-, Video-, Musik-, 3D-, TTS-, STT-, Embedding-, Rerank- oder Übersetzungsendpunkten nutzen können.
Wenn
recommended_for vorhanden ist, wird agent_preferences aus einem zwischengespeicherten 24-Stunden-Erfolgsraten-Snapshot abgeleitet:
- Fenster: 24 Stunden
- Snapshot-Cache: stale-while-revalidate
status = "ready"bedeutet, dass das Modell genügend jüngere Samples hat, um an der Rangfolge teilzunehmenstatus = "insufficient_samples"bedeutet, dass das Modell sichtbar bleibt, aber nicht vor bewerteten Modellen platziert wird
Kategoriefilterung
Empfehlungserkennung
Für Nicht-Chat-Workflows sollten Agenten zuerst die aktuelle empfohlene Shortlist abrufen:recommended_for sind:
imagevideomusic3dttssttembeddingreranktranslation
category als auch recommended_for vorhanden sind, müssen sie genau übereinstimmen.
Empfohlener Agentenablauf:
GET /v1/models?recommended_for=<scene>- Wähle das erste Modell mit
agent_preferences.<scene>.status == "ready" - Rufe den Endpunkt explizit mit
model=<selected>auf - Bei ausschließlich transienten Fehlern: erneuter Versuch mit dem nächsten
ready-Modell
llms.txt
Eine maschinenlesbare API-Übersicht ist verfügbar unter:- Erstaufruf-Vorlage mit einem funktionierenden Beispiel
- Häufige Modellnamen (dynamisch aus Nutzungsdaten generiert)
- Alle 12 API-Endpunkte
- Filterparameter zur Modellerkennung
- Hinweise zur Fehlerbehandlung
llms.txt vor ihrem ersten API-Aufruf lesen, können in der Regel beim ersten Versuch erfolgreich sein.
Verwendung im Agenten-Code
Python (OpenAI SDK)
JavaScript (OpenAI SDK)
Designprinzipien
Schnell fehlschlagen, informativ fehlschlagen
Fehler werden sofort mit allen Daten zurückgegeben, die ein Agent zur Selbstkorrektur benötigt.
Keine automatische Weiterleitung
Die API substituiert niemals stillschweigend ein anderes Modell. Der Agent entscheidet.
Datengetriebene Vorschläge
Alle Empfehlungen stammen aus Produktionsdaten, nicht aus hartkodierten Listen.
Rückwärtskompatibel
Alle Hinweisfelder sind optional. Bestehende Clients bemerken keinen Unterschied.