Ü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?
Kurzes Beispiel
Wessen Nutzung Sie sehen
- Verwalteter API-Key – der an den Key gebundene
user_pathwird 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
Derusage-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):
usage aus.
Cache-Modus
Derusage-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:
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.