KI-API-Guthaben prüfen, ohne fünf Dashboards zu öffnen

Drei verschiedene Fragen hinter einem Wort

„Guthaben“ steht für drei Dinge, die sich völlig unterschiedlich verhalten. Wer sie verwechselt, wird mitten in einer Aufgabe überrascht.

Ein Prepaid-Guthaben ist Geld, das Sie bereits eingezahlt haben und das pro Anfrage abgebucht wird. Es wird nie zurückgesetzt: Es sinkt nur, bis Sie aufladen. DeepSeek und Moonshot funktionieren so.

Ein Tarif-Kontingent ist ein Anteil an einem Zeitfenster: ein Coding-Tarif, der Ihnen pro 5 Stunden, pro Woche oder pro Monat eine bestimmte Menge gibt und sich auffüllt, sobald das Fenster endet. Kimi Code, der Coding-Tarif von MiniMax und der GLM-Coding-Tarif von Z.ai funktionieren so.

Ein Prozentwert bedeutet hier etwas anderes als der Prozentwert eines Guthabens. Wenn ein Fenster Sonntagabend zurückgesetzt wird, steht es am Montag um 09:00 mit 90 % deutlich schlechter da als am Sonntag um 17:00 mit 90 %, denn das Zurücksetzen liegt fast eine Woche entfernt statt nur Stunden.

Ausgaben sind schlicht das, was ein Schlüssel bisher gekostet hat, ohne eine Obergrenze. Das ist die einfache Antwort, wenn es kein Limit gibt, von dem sich ein Anteil bilden ließe. Genau diesen Fall hat OpenRouter bei einem Schlüssel ohne Limit.

Was jeder Anbieter tatsächlich bereitstellt

DeepSeek veröffentlicht GET https://api.deepseek.com/user/balance, autorisiert mit einem gewöhnlichen API-Schlüssel als Bearer-Token. Der Endpunkt liefert balance_infos[], eine Zeile pro Währung.

Jede Zeile enthält total_balance (was Sie tatsächlich ausgeben können), topped_up_balance (Guthaben, das Sie bezahlt haben) und granted_balance (Aktionsguthaben), als Dezimalzahlen in Textform und in ganzen Währungseinheiten. Die Trennung zwischen bezahltem und gewährtem Guthaben ist wichtig, denn gewährtes Guthaben verfällt meist zuerst.

Moonshot (die Kimi Open Platform) beantwortet GET /v1/users/me/balance auf api.moonshot.ai international und auf api.moonshot.cn für die China-Plattform. Die Antwort enthält available_balance neben cash_balance und voucher_balance. Ein Schlüssel gehört zu einer Plattform und funktioniert auf der anderen nicht.

Eine Einschränkung, bevor Sie darauf etwas aufbauen: Die Antwort enthält überhaupt kein Währungsfeld. Die Währung wird aus dem antwortenden Host abgeleitet, CNY für den China-Host und sonst USD. Das ist eine Annahme, keine Angabe des Servers.

Kimi Code ist ein Abonnement, kein Guthaben. GET https://api.kimi.com/coding/v1/usages liefert ein Nutzungskontingent über 7 Tage sowie kürzere Rate-Limit-Fenster. Der monatliche Pool „Total usage“ auf der Seite von Kimi stammt aus einem anderen Web-Endpunkt, der per Cookie authentifiziert wird. Mit einem API-Schlüssel allein erhalten Sie diesen Wert also nicht.

MiniMax verwendet einen Coding-Tarif-Schlüssel, der mit sk-cp- beginnt. Abgefragt wird GET /v1/token_plan/remains auf api.minimax.io weltweit oder auf api.minimaxi.com für die China-Plattform. Ein älterer Pfad /v1/api/openplatform/coding_plan/remains antwortet bei manchen Konten weiterhin. Zurück kommt die verbleibende Kapazität des Tarifs pro Fenster, kein Geld.

OpenRouter dokumentiert dafür einen eigenen Endpunkt: GET https://openrouter.ai/api/v1/key liefert limit, limit_remaining und usage des aufrufenden Schlüssels, alle in USD. Hat der Schlüssel ein Ausgabenlimit, erhalten Sie einen echten Prozentwert.

Z.ai (und BigModel, die China-Plattform) stellt das Coding-Tarif-Kontingent unter /api/monitor/usage/quota/limit auf api.z.ai oder open.bigmodel.cn bereit. Dieser Endpunkt steht nicht in der veröffentlichten API-Referenz von Z.ai. Ihn ruft das Open-Source-Usage-Plugin von Z.ai selbst auf, er ist also vom Anbieter veröffentlichter Client-Code und keine zugesagte Schnittstelle, und er kann sich ohne Ankündigung ändern.

Die Antwort vermischt außerdem zwei verschiedene Pools: das Token- oder Credit-Kontingent des Tarifs und ein separates Monatskontingent, das MCP-Tool-Aufrufe wie die Websuche zählt. Beide sind nicht austauschbar. Wer den zweiten für den ersten hält, glaubt schnell, der Tarif sei fast aufgebraucht, obwohl er es nicht ist.

Selbst auslesen

Für ein paar davon brauchen Sie gar kein Tool. DeepSeek und OpenRouter sind einfache GET-Anfragen mit einem Bearer-Token. curl -H "Authorization: Bearer $DEEPSEEK_API_KEY" https://api.deepseek.com/user/balance liefert den Wert von DeepSeek, und curl -H "Authorization: Bearer $OPENROUTER_API_KEY" https://openrouter.ai/api/v1/key den von OpenRouter.

Leiten Sie beides durch jq, und Sie haben in etwa einer Minute eine Shell-Funktion, die Sie an einen Alias binden können. Für einen oder zwei Anbieter ist das eine gute Antwort.

Im Betrieb skaliert es nicht mehr. Jeder Schlüssel muss irgendwo liegen, wo Ihre Shell ihn lesen kann, meist in einer Dotfile oder einer exportierten Umgebungsvariable. Sie müssen daran denken, den Befehl auszuführen, und die Antwort ist nur so aktuell wie Ihr letzter Aufruf. Bei Anbietern mit undokumentierten Endpunkten pflegen Sie außerdem einen Scraper gegen etwas, das sich ohne Changelog-Eintrag ändern kann.

Die andere kostenlose Möglichkeit ist das Dashboard des jeweiligen Anbieters. Es zeigt immer die maßgebliche Zahl und außerdem, was ein API-Schlüssel nicht liefert: Rechnungen, Ablaufdaten von gewährtem Guthaben, Aufschlüsselungen pro Schlüssel. Für den monatlichen Abgleich ist es der richtige Ort.

Für die Frage „Geht mir gleich mitten in der Aufgabe das Guthaben aus?“ eignet es sich schlecht. Diese Frage stellen Sie zehnmal am Tag und möchten sie beantwortet haben, ohne das zu verlassen, woran Sie gerade arbeiten.

Was der Token Meter von MXterm Pro damit macht

Alle sechs wurden in 1.0.22 zum Token Meter hinzugefügt, und unter Einstellungen → Token Meter gibt es dafür eine Zeile pro Anbieter.

Fügen Sie einen API-Schlüssel ein und wählen Sie eine Region, wo der Anbieter eine hat (Moonshot international/China, MiniMax weltweit/China, Z.ai weltweit/China; Schlüssel von Moonshot und Z.ai funktionieren nur in ihrer eigenen Region). Dieser Anbieter erscheint dann im Popover mit seinem Guthaben, seinen Kontingentfenstern oder seinen Ausgaben, im Hintergrund aktualisiert. Das Popover listet jeden eingerichteten Anbieter, und unter Einstellungen → Token Meter können Sie einen oben anheften (standardmäßig Claude Code). Siehe auch die Seite zum Token Meter und die Dokumentation zum Token Meter.

Der einzelne Chip in der Titelleiste zeigt das knappste Kontingent überhaupt, eingefärbt nach dem Abstand zum Limit. Aus dem Grund im ersten Abschnitt zählt ein Guthaben oder ein Ausgabenwert nie als Prozentwert und wird nie zu einem Balken. Gibt es kein Kontingent und sind weder Claude Code noch Codex installiert, zeigt der Chip das niedrigste USD-Guthaben als Geldbetrag.

Jede Zeile nennt das Alter ihrer Messung und was schiefgelaufen ist: Schlüssel abgelehnt, Anbieter nicht erreichbar, Rate Limit erreicht oder eine Antwort, die sich nicht lesen ließ. Ist der Anbieter nicht erreichbar oder begrenzt er die Abfrage per Rate Limit, behält die Zeile die letzte gute Messung und kennzeichnet sie als veraltet, statt eine alte Zahl als aktuell auszugeben. Ein abgelehnter Schlüssel oder eine unlesbare Antwort zeigt stattdessen diese Meldung.

Wo die Schlüssel liegen und was nie den Rechner verlässt

Hier die Einzelheiten, denn „Wir speichern es sicher“ ist keine Aussage, die sich prüfen lässt.

Ein eingefügter Schlüssel landet im Zugangsdatenspeicher Ihres Betriebssystems. Unter macOS ist das ein Keychain-Eintrag, den MXterm selbst angelegt hat, unter dem Dienst MXterm Pro und dem Konto account-usage.<provider>. Der Windows-Build ist so ausgelegt, dass er den Zugangsdatenspeicher von Windows verwendet, das ist dort aber nicht verifiziert. Im aktuellen Build wird der Schlüssel weder in die eigenen Dateien der App noch in den Browser-Speicher geschrieben.

Das Eingabefeld, in das Sie einfügen, ist absichtlich unkontrolliert (im React-Sinn). Der Schlüssel liegt in diesem DOM-Eingabefeld und nirgendwo sonst, bis ihn „Speichern“ an das Backend übergibt, das das Feld danach leert. Der Zustand der App enthält ihn nicht.

Eine zweite Datei ohne Geheimnisse im Datenverzeichnis der App, account-usage.json, merkt sich pro Anbieter nur drei Dinge: ob ein Schlüssel gespeichert ist, seine letzten vier Zeichen und die Region. Die Titelleiste liest sie bei jedem Laden, damit die App weiß, was Sie eingerichtet haben, ohne einen einzigen Aufruf des Zugangsdatenspeichers. Ist nichts eingerichtet, führt der Token Meter weder einen Aufruf des Zugangsdatenspeichers noch einen Netzwerkaufruf aus.

Im aktuellen Build geht jeder Schlüssel nur an fest eingebaute HTTPS-Hosts des Anbieters, zu dem er gehört. Weiterleitungen werden nicht verfolgt, sodass ein Bearer-Token nicht auf einen anderen Host umgeleitet werden kann. Es gibt keine einstellbare Basis-URL, mit der sich ein Schlüssel woandershin schicken ließe.

Fehlertexte sind eine feste Kategorie, keine rohe Antwort: „invalid credentials“, „unreachable“, „unreadable“ oder „rate limited“. Jeder Typ, der ein Geheimnis hält, gibt beim Debuggen [redacted] aus. Als einziger Teil eines gespeicherten Schlüssels zeigt die App … plus seine letzten vier Zeichen, und nur dann, wenn der Schlüssel lang genug ist, dass vier Zeichen nichts verraten.

Was er bewusst nicht tut

Ein Meter, der Zugangsdaten liest, sollte man ebenso daran messen, was er nicht tut, wie an dem, was er kann. Diese Grenzen sind bewusst gesetzt.

Keine Management-Schlüssel. Eine OpenRouter-Antwort, die angibt, von einem Management- oder Provisioning-Schlüssel zu stammen, wird als ungültig abgelehnt, weil solche Schlüssel API-Schlüssel anlegen und löschen können. Die App ruft außerdem nie den Endpunkt für Konto-Guthaben auf, der nur mit Management-Schlüsseln funktioniert.

Keine Browser-Cookies und keine gespeicherten Zugangsdaten anderer Apps. Gelesen werden nur die Zugangsdaten, die Sie eingefügt haben, und, allein für Kimi, die eigene Token-Datei der Kimi Code CLI: gelesen, nie geschrieben, nie erneuert, weil sie der CLI gehört.

Manche Tools legen eine Datei mit der Geräte-ID an, wenn sie fehlt. MXterm tut das nicht, weil es nicht in das Verzeichnis eines anderen Programms schreibt. Fehlt diese Datei, ist der CLI-Pfad schlicht nicht verfügbar, und der Anbieter gilt als nicht eingerichtet.

Kein Dauerfeuer. Jeder Anbieter wird höchstens alle fünf Minuten gefragt. Ein 429 sperrt ihn für fünfzehn. Ein 401 oder 403 sperrt ihn, bis Sie die Zugangsdaten ändern, statt einen abgelehnten Schlüssel im Takt erneut zu versuchen. Das eigene Polling der App läuft nur, solange mindestens ein Anbieter eingerichtet ist: ein gespeicherter Schlüssel oder die Zugangsdaten-Dateien der Kimi Code CLI.

Eine eigene Identität, mit einer Ausnahme. Die App identifiziert sich mit einem User-Agent, der MXterm und seine Version nennt. Der Source-Header von MiniMax trägt den eigenen Namen von MXterm, und OpenRouter bekommt gar keinen Attributions-Header.

Die Ausnahme ist der Pfad über die Kimi Code CLI. Dort wird das Token der CLI mit der Plattform-Identität der CLI (X-Msh-Platform: kimi_code_cli) und ihrer Geräte-ID gesendet, zusammen mit der Version von MXterm.

Die Einschränkung, die man klar sagen sollte

Das Parsing von MXterm Pro wurde gegen Fixtures und Beispiele aus der Dokumentation geschrieben und getestet, nicht gegen aufgezeichnete Live-Antworten jedes Anbieters.

Benennt ein Anbieter ein Feld um, das der Parser braucht, zeigt die Zeile also „Die Antwort konnte nicht gelesen werden“ statt einer falschen Zahl. Das ist die Fehlerart, die Sie wollen. Betrachten Sie trotzdem nichts davon als Buchhaltungsquelle.

Wenn Geld stimmen muss (bei einer Rechnung, einem Budget, einer Rückbuchung), gehen Sie zum Dashboard des Anbieters. Für die Frage „Läuft dieser Schlüssel gleich leer, während drei Agents arbeiten?“ ist eine Liste, die sich in der Fensterecke selbst aktualisiert, das bessere Werkzeug.