Skip to main content

Übersicht

GET /v1/usage gibt den eigenen Verbrauch und die eigenen Limits des Aufrufers zurück – ohne Admin-Zugriff. Ein einziger Aufruf beantwortet drei Fragen:
  • Wie viel habe ich verbraucht (Requests, Token, geschätzte Kosten)?
  • Wie viel Budget bleibt mir, und wann wird es zurückgesetzt?
  • Welche Rate-Limits gelten für mich, und wie viel Spielraum bleibt?
Alles bezieht sich auf den effektiven User Path des Aufrufers. Ein Tool mit einem verwalteten API-Key – ein OpenCode-Plugin, eine CLI, ein Status-Widget – kann den Endpunkt also mit dem Key abfragen, den es ohnehin für Inferenz verwendet. Das Abfragen verbraucht kein Rate-Limit-Kontingent.

Kurzes Beispiel

Wessen Nutzung Sie sehen

  • Verwalteter API-Key – der an den Key gebundene user_path wird verwendet. Es sind keine Parameter nötig, und der Inhaber des Keys kann nichts außerhalb seines eigenen Teilbaums lesen.
  • Master-Key (oder Unsafe-Modus) – übergeben Sie X-GoModel-User-Path, um einen Pfad auszuwählen, oder lassen Sie den Header weg, um / (alles) zu sehen:

Response-Felder

usage

Aggregiert aus erfassten Requests innerhalb des Datumsfensters, mit derselben Token- und Kostenschätzungs-Semantik wie im Dashboard. Kostenfelder sind null, wenn für keinen passenden Request Preise vorliegen. Der gesamte Block ist null, wenn kein Storage-Backend die Nutzung aufzeichnet (USAGE_ENABLED=false oder keine Datenbank).

budgets

Ein Eintrag pro Budget, das den Pfad abdeckt – einschließlich Budgets, die von übergeordneten Pfaden wie / geerbt werden. remaining kann negativ werden und usage_ratio über 1 steigen – beides bedeutet, dass das Budget überschritten ist. exceeded spiegelt die Durchsetzung wider: Ist der Wert true, werden Requests bis period_end abgelehnt (period_seconds mit dem Wert 2592000 ist der Sentinel-Wert für den Kalendermonat, nicht buchstäblich 30 Tage). resets_in_seconds zählt relativ zu server_time bis period_end herunter, sodass Sie den Wert anzeigen können, ohne sich um Uhrzeitabweichungen auf dem Client kümmern zu müssen.

rate_limits

Live-Zähler für jede User-Path-Rate-Limit-Regel, die den Pfad abdeckt. max_tokens/tokens_remaining/tokens_usage_ratio erscheinen nur bei Regeln mit Token-Limits; ein period_label mit dem Wert concurrent kennzeichnet eine Obergrenze für gleichzeitige Requests, wobei in_flight die aktuelle Anzahl ist (und in requests_usage_ratio einfließt). Die *_usage_ratio-Felder geben pro Dimension verbraucht/Limit an, ohne Begrenzung – Token-Fenster können über 1 hinausschießen. exhausted ist true, wenn irgendeine Dimension vollständig ausgeschöpft ist, und resets_in_seconds zählt relativ zu server_time bis window_end herunter (entfällt bei Regeln für gleichzeitige Requests, die kein Fenster haben). Regeln mit Provider- oder Modell-Scope werden nicht aufgeführt: Sie beschreiben gemeinsam genutzte Infrastrukturkapazität, nicht den Aufrufer.
Rate-Limit-Zähler liegen pro Gateway-Instanz im Arbeitsspeicher: Sie werden bei einem Neustart zurückgesetzt, und bei N Replikaten führt jedes Replikat seine eigenen Zähler. Budgets sind die dauerhaften, instanzübergreifenden Werte.

Datumsfenster

Der usage-Block umfasst standardmäßig die letzten 30 Tage (Tagesgrenzen in UTC). Schränken Sie ihn mit Query-Parametern ein – days oder explizit start_date/end_date (YYYY-MM-DD, maximal 365 Tage):
Budgets und Rate-Limits melden immer ihre eigenen aktuellen Zeiträume; das Fenster wirkt sich nur auf usage aus.

Cache-Modus

Der usage-Block zählt nur Requests, die an einen Provider gehen, damit er mit Budgets und Kosten übereinstimmt. Treffer im Response-Cache werden ebenfalls erfasst, und cache_mode macht sie sichtbar:
Ein Vergleich von cached mit dem Standardwert zeigt am schnellsten, welchen Anteil Ihres Traffics der Cache abfängt. Nicht erkannte Werte fallen auf uncached zurück. cache_mode wirkt sich nur auf usage aus: Budgets und Rate-Limits zählen nie Cache-Treffer, weil ein Treffer nichts kostet und kein Kontingent verbraucht.

Fehler

Zuletzt geändert am 24. Oktober 2026