TokenLab Request Console: Debuggen Sie AI API-Aufrufe über ein einziges Dashboard

Ein fehlgeschlagener KI-API-Aufruf kündigt sich selten klar an. Man erhält einen Statuscode, vielleicht einen Fehler-String und einen Support-Kanal, in dem jemand fragt: „Wie lautet die Request-ID?“ Wenn man diese nicht zur Hand hat, stockt die Untersuchung, bevor sie überhaupt begonnen hat. Wir haben die TokenLab Request Console entwickelt, um diese Lücke zu schließen, indem wir Details auf Request-Ebene in einer Dashboard-Ansicht zusammenführen. Sie zeigt Modell, Key, Cache-Status, Abrechnungsstatus, Timing und eine redigierte Vorschau der Payload. In unserer Pipeline behandeln wir die Request-ID als primären Suchschlüssel.

Wichtige Erkenntnisse

• Die TokenLab Request Console ist eine Oberfläche für das Debugging auf Request-Ebene innerhalb des TokenLab-API-Dashboards, kein Abrechnungsbericht.
• Jeder Request hat eine ID, nach der Sie direkt suchen können. Sie können mit der requestId in der URL direkt auf einen spezifischen Request verlinken.
• Die Konsole zeigt Routing, Abrechnungsstatus, Cache-Status, Modell-/Key-Kontext und redigierte Payload-Vorschauen für aktuelle Requests an.
• Der Zugriff ist auf Ihre Organisation beschränkt und unterliegt den Berechtigungen der Dashboard-Mitgliedschaft – Teammitglieder sehen das, was ihre Rolle erlaubt.
• Verwenden Sie für das Debugging einzelner Vorfälle die Konsole. Für die Kostenanalyse über Zeiträume hinweg nutzen Sie stattdessen die Nutzungs-Exporte.

Was die TokenLab Request Console ist

Sie erreichen sie unter /dashboard/api?tab=requestConsole im API-Bereich des TokenLab-Dashboards. Das API-Dashboard selbst befindet sich unter /dashboard/api. Die Konsole basiert auf einer Prämisse: Wenn ein Request fehlschlägt, erfolgt die schnellste Fehlerbehebung, wenn man den vollständigen Kontext vor sich hat, anstatt nur auf Basis einer Fehlermeldung zu raten.

Die Beschreibung im Dashboard bezeichnet die Konsole als Inspektor für aktuelle Requests, der Routing, Abrechnung, Request-/Response-Body und den Kontext des Modellanbieters abdeckt. Wir unterteilen sie in einige Arbeitsbereiche.

Listenansicht. Eine filterbare Tabelle aktueller Requests. Hier beginnen Sie, wenn Sie noch keine spezifische Request-ID haben. Sie suchen nach dem fehlgeschlagenen oder ungewöhnlichen Aufruf.

Inspektor-Panel. Sobald Sie einen Request auswählen, öffnet sich der Inspektor mit allen Details: Welches Modell hat ihn bedient, welcher API-Key wurde verwendet, wurde der Cache getroffen und wie war der finale Status.

Fehlerkontext. Wenn der Request fehlgeschlagen ist, zeigt die Konsole die Fehlerinformationen an, die mit diesem spezifischen Aufruf verknüpft sind. Sie müssen nicht in einem separaten Fehlerprotokoll nachschlagen.

Route und Abrechnungsstatus. Zeigt, wie der Request geroutet wurde und ob er abgerechnet, ausstehend, erstattet oder fehlgeschlagen ist. Diese vier Zustände sind am wichtigsten, wenn ein Kunde fragt: „Wurde mir dieser Fehler in Rechnung gestellt?“

Payload-Vorschau. Request- und Response-Bodies werden als redigierte Vorschauen angezeigt, sofern verfügbar. Dies gibt Ihnen Einblick in Form und Struktur, ohne sensible Daten im Body offenzulegen.

Modellanbieter- und Modell-Key-Kontext. Welcher Anbieter und welches spezifische Modell haben den Aufruf verarbeitet. Dies ist nützlich, wenn Sie mehrere Modelle hinter einer Integration betreiben und bestätigen müssen, dass das richtige Modell aufgerufen wurde.

Nichts davon erfordert, dass Sie Ihre eigene Logging-Pipeline über der API aufbauen. Es ist bereits pro Organisation verfügbar und durch die Berechtigungen der Dashboard-Mitgliedschaft gefiltert, sodass Teammitglieder mit entsprechendem Zugriff dieselben Request-Daten sehen wie Sie.

Was zuerst zu prüfen ist

Wenn ein API-Aufruf fehlschlägt, gibt es eine natürliche Reihenfolge für die Überprüfung. Direkt zu fragen „Ist das Modell ausgefallen?“, bevor man bestätigt hat, dass der Request überhaupt den richtigen Endpunkt erreicht hat, kostet Zeit.

Die Triage der fünf Felder

Prüfung	Was sie Ihnen sagt
Request ID	Bestätigt, dass Sie genau den betreffenden Aufruf betrachten, nicht einen ähnlichen
Status	Abgerechnet, ausstehend, erstattet oder fehlgeschlagen – sagt Ihnen, ob es eine Kostenfrage oder ein technisches Problem ist
Modell	Welches Modell den Request tatsächlich bedient hat (nützlich, wenn Sie über mehrere Modelle routen)
Cache-Status	Ob ein Prompt-Cache-Hit oder -Miss Kosten oder Latenz verändert hat
Key-Quelle	Welcher API-Key verwendet wurde, nützlich wenn mehrere Keys oder Umgebungen eine Integration teilen

Beginnen Sie mit der Request-ID. Wenn Sie diese aus einem clientseitigen Log, einem Support-Ticket oder einem Fehlerbericht haben, verwenden Sie das Deep-Link-Muster:

/dashboard/api?tab=requestConsole&requestId=%3Crequest_id>

Dies öffnet den Inspektor direkt für den betreffenden Request und überspringt die Listenansicht komplett. Es ist der schnellste Weg, wenn Ihnen jemand eine ID gibt und fragt: „Was ist hier passiert?“

Wenn Sie noch keine Request-ID haben, können Sie mit den Filtern der Konsole nach Modell, Zeitbereich, Prompt-Cache-Status, Key-Quelle und Status eingrenzen. Filtern Sie beispielsweise bei einem fehlgeschlagenen Request nach dem Status „failed“ innerhalb der letzten Stunde und suchen Sie dann in der Liste nach dem spezifischen Aufruf, nach dem ein Benutzer fragt.

Den Status-Status korrekt lesen

Die vier Zustände — abgerechnet, ausstehend, erstattet, fehlgeschlagen — beantworten unterschiedliche Fragen:

• Abgerechnet bedeutet, dass der Aufruf abgeschlossen wurde und Credits verbraucht hat. Wenn ein Benutzer einen Fehler meldet, der Request aber als abgerechnet angezeigt wird, sollte dies separat markiert werden. Es deutet darauf hin, dass der Fehler auf der Client-Seite nach einer erfolgreichen Antwort aufgetreten ist.
• Ausstehend bedeutet, dass der Request noch läuft oder auf die Abrechnung wartet. Behandeln Sie dies nicht voreilig als Fehler.
• Erstattet bedeutet, dass TokenLab die Gebühr storniert hat, normalerweise aufgrund eines Fehlers auf der Anbieter- oder Routing-Seite.
• Fehlgeschlagen bedeutet, dass der Aufruf nicht erfolgreich abgeschlossen wurde und nicht abgerechnet wurde.

Zu wissen, welcher dieser Zustände zutrifft, bevor Sie eskalieren, erspart Ihnen eine Runde Hin-und-Her mit dem Support.

Modell und Cache-Status bestätigen

Wenn Sie Requests gegen Modelle wie Claude Sonnet 5, DeepSeek V4 Pro oder Gemini 3.5 Flash über eine gemeinsame Integration ausführen, bestätigen Sie, dass die Konsole das von Ihnen erwartete Modell anzeigt. Ein falsch konfigurierter Client, eine veraltete Umgebungsvariable oder ein Routing-Override können Traffic an das falsche Modell senden, ohne dass ein offensichtlicher clientseitiger Fehler auftritt.

Der Cache-Status ist aus zwei Gründen wichtig: Kosten und Latenz. Ein Cache-Miss, bei dem Sie einen Hit erwartet haben, bedeutet normalerweise, dass sich das Prompt-Präfix geändert hat, selbst wenn nur geringfügig. Achten Sie auf einen Zeitstempel, ein neu angeordnetes Feld oder ein zusätzliches Leerzeichen. Der Cache-Status-Filter der Konsole ermöglicht es Ihnen, Hit- und Miss-Requests nebeneinander zu vergleichen.

Wie die TokenLab Request Console mit Nutzungs-Exporten zusammenarbeitet

Die Request Console und Nutzungs-Exporte lösen unterschiedliche Probleme, daher ist es hilfreich, die Grenze explizit zu benennen. Die Konsole ist für die Untersuchung einzelner Requests gedacht: ein Aufruf, ein Fehler, eine Abrechnungsfrage, beantwortet im Inspektor-Panel. Sie öffnen sie, wenn ein spezifischer Request fehlschlägt und Sie sofort wissen müssen, warum.

Nutzungs-Exporte sind für die aggregierte Überprüfung gedacht: Ausgaben über einen Zeitraum, Aufschlüsselungen nach Modell oder Key und die Art der Berichterstattung, die Sie einem Finanzverantwortlichen vorlegen oder für einen monatlichen Abgleich verwenden würden. Wenn Sie beantworten möchten: „Wie viel haben wir letzte Woche für DeepSeek V4 Pro ausgegeben?“, ist das eine Export-Frage, keine Konsolen-Frage. Siehe dazu den Leitfaden für Nutzungs-Exporte im TokenLab-Dashboard.

Kurz gesagt: Konsole für Vorfälle, Exporte für Summen. Manche Teams verwenden beides nacheinander. Ein Export zeigt eine Anomalie bei den Gesamtausgaben auf, und in der Konsole gehen Sie dann ins Detail der spezifischen Requests, die diese verursacht haben.

Eine praktische Debugging-Routine

Ad-hoc-Debugging wird unter Druck zum Raten. Eine wiederholbare Routine verhindert, dass Vorfälle länger dauern als nötig.

Checkliste: wenn ein Request fehlschlägt

1. Holen Sie sich die Request-ID. Aus Ihren Client-Logs, der Fehlerantwort oder einem Benutzerbericht. Wenn Sie Request-IDs derzeit nicht protokollieren, fangen Sie jetzt damit an. Es ist der schnellste Suchschlüssel, den Sie haben.
2. Öffnen Sie die Konsole mit dem Deep Link. Verwenden Sie den requestId-Abfrageparameter, um direkt zum Inspektor zu springen.
3. Prüfen Sie zuerst das Status-Feld. Abgerechnet, ausstehend, erstattet oder fehlgeschlagen. Dies bildet den Rahmen für die weitere Untersuchung.
4. Bestätigen Sie das Modell, das den Request tatsächlich bedient hat. Vergleichen Sie es mit dem, das Sie erwartet hatten.
5. Prüfen Sie den Cache-Status. Ein Cache-Miss, bei dem Sie einen Hit erwartet haben, kann unerwartete Latenz oder Kosten erklären.
6. Prüfen Sie die Key-Quelle. Bestätigen Sie, dass der richtige API-Key und die richtige Umgebung verwendet wurden, insbesondere bei Staging-vs-Produktions-Setups.
7. Lesen Sie den Fehlerkontext und die Routeninformationen. Hier wird normalerweise die tatsächliche Ursache sichtbar.
8. Überprüfen Sie die redigierte Payload-Vorschau. Bestätigen Sie, dass die Form des Requests mit dem übereinstimmt, was Ihr Client gesendet hat. Fehlerhafte Parameter zeigen sich hier oft, bevor sie irgendwo anders auftauchen.
9. Vergleichen Sie bei Bedarf mit der API-Referenz. Die TokenLab Chat Completions API-Referenz unter https://docs.tokenlab.sh/api-reference/chat/create-completion dokumentiert die erwarteten Request- und Response-Formen. Nutzen Sie sie, um zu bestätigen, ob eine Payload auf der Client-Seite fehlerhaft war.
10. Wenn es ein Muster ist, kein Einzelfall, wechseln Sie zu Nutzungs-Exporten. Ein einzelner fehlgeschlagener Request ist ein Konsolen-Problem. Zehn fehlgeschlagene Requests innerhalb einer Stunde sind ein Muster, das es wert ist, exportiert und aggregiert überprüft zu werden.

Diese Reihenfolge — ID, Status, Modell, Cache, Key, Fehler, Payload — verhindert, dass Sie das Feld überspringen, das den Fehler tatsächlich erklärt.

FAQ

Wie finde ich einen fehlgeschlagenen Request ohne Request-ID?

Verwenden Sie die Filter in der Listenansicht der TokenLab Request Console. Grenzen Sie nach Modell, Zeitbereich, Prompt-Cache-Status, Key-Quelle und Status ein. Filtern Sie beispielsweise nach dem Status „failed“ innerhalb der letzten Stunde und suchen Sie dann nach dem Aufruf, nach dem ein Benutzer fragt. Sobald Sie ihn gefunden haben, öffnen Sie den Inspektor und kopieren Sie die Request-ID für zukünftige Protokolle.

Warum wird ein Request als abgerechnet angezeigt, wenn der Client einen Fehler meldet?

Abgerechnet bedeutet, dass der Aufruf abgeschlossen wurde und Credits verbraucht hat. Wenn ein Benutzer einen Fehler meldet, der Request aber als abgerechnet angezeigt wird, ist der Fehler wahrscheinlich auf der Client-Seite nach einer erfolgreichen Antwort aufgetreten. Markieren Sie diesen Fall separat, da er auf einen anderen Lösungsweg hinweist als ein fehlgeschlagener oder erstatteter Request.

Was sagt mir ein Cache-Miss im Inspektor?

Ein Cache-Miss bedeutet, dass der Request den Prompt-Cache nicht getroffen hat. Das ist wichtig für Kosten und Latenz. Ein Miss, bei dem Sie einen Hit erwartet haben, bedeutet normalerweise, dass sich das Prompt-Präfix geändert hat, selbst wenn nur geringfügig. Achten Sie auf einen Zeitstempel, ein neu angeordnetes Feld oder ein zusätzliches Leerzeichen.

Kann ich einen Request-Link mit einem Teammitglied teilen?

Ja, wenn dessen Berechtigungen für die Dashboard-Mitgliedschaft dies zulassen. Request-Daten sind auf Ihre Organisation beschränkt. Verwenden Sie das Deep-Link-Format /dashboard/api?tab=requestConsole&requestId=<request_id>, um den Inspektor direkt zu öffnen. Teammitglieder sehen das, was ihre Rolle erlaubt.

Wann sollte ich von der Konsole zu Nutzungs-Exporten wechseln?

Wechseln Sie, wenn das Problem ein Muster ist, kein Einzelfall. Ein einzelner fehlgeschlagener Request ist ein Konsolen-Problem. Zehn fehlgeschlagene Requests innerhalb einer Stunde sind ein Muster, das es wert ist, exportiert und aggregiert überprüft zu werden. Verwenden Sie Exporte für Ausgaben über einen Zeitraum, Aufschlüsselungen nach Modell oder Key und für den monatlichen Abgleich.

Quellen und Aktualität

• TokenLab Request Console — /dashboard/api?tab=requestConsole — beobachtet am 09.07.2026
• TokenLab Chat Completions API-Referenz — https://docs.tokenlab.sh/api-reference/chat/create-completion — beobachtet am 09.07.2026
• TokenLab Dashboard Usage Exports — /blog/tokenlab-dashboard-usage-exports — beobachtet am 09.07.2026
• TokenLab öffentliches Modellverzeichnis — /models — beobachtet am 09.07.2026
• TokenLab API-Key-Dashboard — /dashboard/api — beobachtet am 09.07.2026

Die referenzierten Modellbeispiele (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) spiegeln den aktuellen Modell-SSOT-Stand vom 19.09.2026 wider. Der Quell-Snapshot für diesen Konsolen-Hinweis wurde am 09.07.2026 beobachtet; das ursprüngliche Modell-SSOT-Datum in der Quelle war der 07.07.2026.

Nächste Schritte

Wenn Sie KI-API-Fehler derzeit durch Greppen in clientseitigen Logs und Abgleichen mit einem separaten Abrechnungs-Dashboard debuggen, entfernt die Request Console einen Schritt aus diesem Kreislauf. Die Konsole befindet sich unter /dashboard/api?tab=requestConsole. Das API-Key-Dashboard finden Sie unter tokenlab.sh/dashboard/api. Die Form der Chat-Completions-Requests/-Responses ist unter https://docs.tokenlab.sh/api-reference/chat/create-completion dokumentiert. Für die Überprüfung der Gesamtausgaben verwenden Sie Nutzungs-Exporte. Details zu Modellpreisen und Kontextfenstern finden Sie im Modellverzeichnis. Öffnen Sie die Konsole und suchen Sie einen kürzlich fehlgeschlagenen Request anhand der ID.