Skip to main content

Przegląd

GET /v1/usage zwraca zużycie i limity samego wywołującego – bez dostępu administracyjnego. Odpowiada na trzy pytania w jednym wywołaniu:
  • Ile już zużyłem (requesty, tokeny, szacowany koszt)?
  • Ile budżetu mi zostało i kiedy się odnowi?
  • Które limity żądań mnie dotyczą i ile zostało zapasu?
Wszystko jest ograniczone do efektywnej ścieżki użytkownika wywołującego, więc narzędzie z zarządzanym kluczem API – plugin OpenCode, CLI, widget statusu – może odpytywać ten endpoint tym samym kluczem, którego już używa do inferencji. Odpytywanie nie zużywa limitu żądań.

Szybki przykład

Czyje użycie widzisz

  • Zarządzany klucz API – używana jest user_path przypisana do klucza. Nie trzeba podawać żadnych parametrów, a posiadacz klucza nie może odczytać danych spoza własnego poddrzewa.
  • Master key (lub tryb unsafe) – przekaż X-GoModel-User-Path, aby wybrać ścieżkę, albo go pomiń, aby zobaczyć / (wszystko):

Pola odpowiedzi

usage

Agregowane z śledzonych requestów w danym oknie dat, z taką samą semantyką tokenów i szacowanego kosztu jak w dashboardzie. Pola kosztów mają wartość null, gdy żaden pasujący request nie ma ceny. Cały blok ma wartość null, gdy żaden backend storage nie zapisuje użycia (USAGE_ENABLED=false lub brak bazy danych).

budgets

Jeden wpis na każdy budżet obejmujący ścieżkę – łącznie z budżetami dziedziczonymi ze ścieżek nadrzędnych, takich jak /. remaining może być ujemne, a usage_ratio większe niż 1 – oba oznaczają przekroczenie budżetu; exceeded odzwierciedla egzekwowanie, więc gdy ma wartość true, requesty są odrzucane aż do period_end (period_seconds równe 2592000 to wartość specjalna oznaczająca miesiąc kalendarzowy, a nie dosłownie 30 dni). resets_in_seconds odlicza czas do period_end względem server_time, więc można go bezpiecznie wyświetlać bez obaw o rozjazd zegara klienta.

rate_limits

Bieżące liczniki dla każdej reguły limitu żądań opartej na ścieżce użytkownika, która obejmuje daną ścieżkę. max_tokens/tokens_remaining/tokens_usage_ratio pojawiają się tylko w regułach z limitami tokenów; period_label o wartości concurrent oznacza limit równoległych requestów, gdzie in_flight to bieżąca liczba (i źródło requests_usage_ratio). Pola *_usage_ratio to stosunek zużycia do limitu w danym wymiarze, bez obcinania – okna tokenów mogą przekroczyć 1. exhausted ma wartość true, gdy którykolwiek wymiar jest w pełni wykorzystany, a resets_in_seconds odlicza czas do window_end względem server_time (pomijane dla reguł równoległości, które nie mają okna). Reguły ograniczone do providera i modelu nie są wymieniane: opisują współdzieloną przepustowość infrastruktury, a nie wywołującego.
Liczniki limitów żądań są przechowywane w pamięci każdej instancji gatewaya: zerują się po restarcie, a przy N replikach każda replika ma własne liczniki. Budżety to trwałe wartości wspólne dla wszystkich instancji.

Okno dat

Blok usage domyślnie obejmuje ostatnie 30 dni (granice dni w UTC). Zawęź je parametrami zapytania – days albo jawnymi start_date/end_date (YYYY-MM-DD, maksymalnie 365 dni):
Budżety i limity żądań zawsze raportują własne bieżące okresy; okno dat wpływa tylko na usage.

Tryb cache

Blok usage liczy tylko requesty wysłane do providera, więc zgadza się z budżetami i kosztami. Cache hity cache’u odpowiedzi też są zapisywane, a cache_mode pozwala je zobaczyć:
Porównanie cached z wartością domyślną to najszybszy sposób, by sprawdzić, ile ruchu przejmuje cache. Nierozpoznane wartości są traktowane jak uncached. cache_mode wpływa tylko na usage: budżety i limity żądań nigdy nie liczą cache hitów, bo hit nic nie kosztuje i nie zużywa limitu.

Błędy

Ostatnia modyfikacja 24 października 2026