TokenLab Request Console: KI-API-Aufrufe über ein einziges Dashboard debuggen

Ein fehlgeschlagener KI-API-Aufruf kündigt sich selten klar an. Man erhält einen Statuscode, vielleicht eine Fehlermeldung und einen Support-Kanal, in dem jemand fragt: „Wie lautete die Request-ID?“ Wenn man diese nicht zur Hand hat, kommt die Untersuchung zum Erliegen, bevor sie überhaupt begonnen hat.

Die TokenLab Request Console wurde entwickelt, um diese Lücke zu schließen. Sie stellt Details auf Request-Ebene – Modell, Key, Cache-Status, Abrechnungsstatus, Timing und eine redigierte Payload-Vorschau – in einer einzigen Dashboard-Ansicht bereit. So gelangen Sie von „dieser Aufruf ist fehlgeschlagen“ zu „hier ist der Grund“, ohne Protokolle aus drei verschiedenen Quellen zusammenfügen zu müssen.

Dieser Artikel erläutert, was die Konsole anzeigt, was bei Problemen zuerst zu prüfen ist und wie sie sich in die Nutzungsexporte für Teams einfügt, die auch Berichte auf Kostenebene benötigen.

Wichtige Erkenntnisse

• Die 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. Zudem können Sie mit requestId in der URL einen Deep-Link zu einem spezifischen Request erstellen.
• Die Konsole zeigt Routing, Abrechnungsstatus, Cache-Status, Modell-/Key-Kontext sowie 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 nur das, was ihre Rolle erlaubt.
• Verwenden Sie für das Debugging einzelner Vorfälle die Konsole. Für die Analyse von Kosten über Zeiträume hinweg nutzen Sie stattdessen die Nutzungsexporte.

Was die Request Console ist

Sie erreichen sie unter https://tokenlab.sh/en/dashboard/api?tab=requestConsole im API-Bereich des TokenLab-Dashboards. Sie basiert auf einer Grundannahme: 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. In der Praxis unterteilt sich dies 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 den Aufruf bedient, welcher API-Key wurde verwendet, wurde der Cache genutzt und wie lautete der finale Status?

Fehlerkontext. Wenn der Request fehlgeschlagen ist, zeigt die Konsole die Fehlerinformationen an, die mit diesem spezifischen Aufruf verknüpft sind, sodass Sie kein separates Fehlerprotokoll abgleichen müssen.

Routing- und Abrechnungsstatus. Zeigt an, wie der Request geroutet wurde und ob er abgerechnet, ausstehend, erstattet oder fehlgeschlagen ist – die vier Zustände, die am wichtigsten sind, wenn ein Kunde fragt: „Wurde mir dieser Fehler berechnet?“

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.

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

Nichts davon erfordert, dass Sie eine eigene Logging-Pipeline über der API aufbauen. Die Daten werden bereits pro Organisation bereitgestellt 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 bei der Ü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 und keinen ä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:

https://tokenlab.sh/en/dashboard/api?tab=requestConsole&requestId=<request_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 die Filter der Konsole nutzen, um nach Modell, Zeitbereich, Prompt-Cache-Status, Key-Quelle und Status einzugrenzen. Ein häufiges Muster: Filtern Sie nach dem Status „failed“ innerhalb der letzten Stunde und suchen Sie dann in der Liste nach dem spezifischen Aufruf, zu dem ein Benutzer eine Frage hat.

Den Status-Status korrekt lesen

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

• Abgerechnet (Billed) 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, da es darauf hindeutet, dass der Fehler nach einer erfolgreichen Antwort auf der Client-Seite aufgetreten ist.
• Ausstehend (Pending) bedeutet, dass der Request noch verarbeitet wird oder auf die Abrechnung wartet. Behandeln Sie dies nicht voreilig als Fehler.
• Erstattet (Refunded) bedeutet, dass TokenLab die Gebühr zurückgebucht hat, typischerweise aufgrund eines Fehlers auf der Seite des Anbieters oder beim Routing.
• Fehlgeschlagen (Failed) bedeutet, dass der Aufruf nicht erfolgreich abgeschlossen wurde und nicht abgerechnet wurde.

Zu wissen, welcher dieser Zustände zutrifft, bevor Sie das Problem eskalieren, spart 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, lohnt es sich zu bestätigen, dass die Konsole das 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 – ein Zeitstempel, ein neu geordnetes Feld, ein zusätzliches Leerzeichen. Der Cache-Status-Filter der Konsole ermöglicht es Ihnen, Hit- und Miss-Requests direkt miteinander zu vergleichen.

Wie es mit Nutzungsexporten zusammenarbeitet

Die Request Console und Nutzungsexporte lösen unterschiedliche Probleme. Es ist wichtig, die Grenze zu kennen, damit Sie nicht zum falschen Werkzeug greifen.

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.

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

Kurz gesagt: Konsole für Vorfälle, Exporte für Summen. Manche Teams nutzen beides nacheinander – ein Export deckt 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 schnell 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 bisher 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-Query-Parameter, um direkt zum Inspektor zu springen.
3. Prüfen Sie zuerst das Status-Feld. Abgerechnet, ausstehend, erstattet oder fehlgeschlagen – dies rahmt den Rest der Untersuchung ein.
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, wo 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 Routing-Informationen. Hier wird meist die eigentliche 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 dokumentiert die erwarteten Request- und Response-Formen, was nützlich ist, um zu bestätigen, ob eine Payload auf der Client-Seite fehlerhaft war.
10. Wenn es ein Muster ist, kein Einzelfall, wechseln Sie zu Nutzungsexporten. Ein einzelner fehlgeschlagener Request ist ein Problem für die Konsole. 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.

Nächste Schritte

Wenn Sie KI-API-Fehler derzeit durch Greppen in Ihren eigenen clientseitigen Logs und den Abgleich mit einem separaten Abrechnungs-Dashboard debuggen, entfernt die Request Console einen Schritt aus dieser Schleife. Beginnen Sie damit, einen kürzlich fehlgeschlagenen Request zu finden und direkt zu öffnen.

• Öffnen Sie die Konsole und suchen Sie einen Request per ID: https://tokenlab.sh/en/dashboard/api?tab=requestConsole
• Erstellen Sie einen TokenLab API-Key unter tokenlab.sh/en/dashboard/api, um Requests aus Ihrer eigenen Konsole oder Skripten zu starten.
• Überprüfen Sie die Form der Chat-Completions-Request/Response, wenn Sie eine fehlerhafte Payload vermuten: https://docs.tokenlab.sh/api-reference/chat/create-completion
• Für die Überprüfung der Gesamtausgaben verwenden Sie Nutzungsexporte statt der Konsole: https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports
• Wenn Sie Modelle vor einem Wechsel hinsichtlich Kosten oder Fähigkeiten vergleichen, finden Sie im Modellverzeichnis aktuelle Preise und Details zum Kontextfenster: https://tokenlab.sh/en/models

FAQ

Was ist die TokenLab Request Console? Es ist eine Debugging-Ansicht auf Request-Ebene innerhalb des TokenLab-API-Dashboards. Sie zeigt Routing, Abrechnungsstatus, Cache-Status, Modell- und Key-Kontext sowie redigierte Payload-Vorschauen für aktuelle Requests, beschränkt auf Ihre Organisation.

Kann ich einen Request anhand der Request-ID untersuchen? Ja. Verwenden Sie das Deep-Link-Format /dashboard/api?tab=requestConsole&requestId=<request_id>, um den Inspektor direkt für einen spezifischen Request zu öffnen, oder suchen Sie in der Listenansicht nach der Request-ID.

Ersetzt die Konsole die Nutzungsexporte? Nein. Die Konsole dient der Untersuchung einzelner Requests – ein Fehler, eine Abrechnungsfrage. Nutzungsexporte dienen der aggregierten Ausgabenüberprüfung über einen Zeitraum. Verwenden Sie beides zusammen, wenn ein Export ein Muster aufdeckt, dem Sie nachgehen müssen.

Was sollte ich zuerst prüfen, wenn ein KI-API-Request fehlschlägt? Beginnen Sie mit der Request-ID, um zu bestätigen, dass Sie den richtigen Aufruf betrachten, prüfen Sie dann das Status-Feld (abgerechnet, ausstehend, erstattet, fehlgeschlagen), das Modell, das ihn tatsächlich bedient hat, und den Cache-Status. Von dort aus machen der Fehlerkontext und die Payload-Vorschau die Ursache meist sichtbar.

Quellen und Aktualität

• TokenLab Request Console — https://tokenlab.sh/en/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 Nutzungsexporte — https://tokenlab.sh/en/blog/tokenlab-dashboard-usage-exports — beobachtet am 09.07.2026
• Öffentliches TokenLab-Modellverzeichnis — https://tokenlab.sh/en/models — beobachtet am 09.07.2026

Die referenzierten Modellbeispiele (Claude Sonnet 5, DeepSeek V4 Pro, Gemini 3.5 Flash) spiegeln die aktuelle Modell-SSOT zum Stand 07.07.2026 wider. Für exakte aktuelle Preise und Verfügbarkeiten prüfen Sie bitte den Link zum Modellverzeichnis oben, bevor Sie Routing-Entscheidungen treffen.