Gdzie mamy limit wydatków, a gdzie tylko nadzieję
Inwentarz wszystkich subkont resellerskich: jakie projekty widzi billing i czy każdy z nich ma limit wydatków na monitorowanych usługach AI. Zestawienie czyta przegląd pokrycia i stan potwierdzony przez API; edytorzy mogą ustawić cap, zwolnić przypięcie albo zastosować sugestię — zmiany idą przez Spend Caps API i trafiają do księgi zdarzeń.
Ogółem w księdze
Cała księga klientów, niezależnie od filtrów poniżej.Automatyzacja capów (API)
Cap usage alerts
Sugestie do zatwierdzenia
W tym widoku
Te liczby liczą się z tego, co przepuszczają filtry.Wczytywanie…
Jak to czytamy · Kolory i liczby
Jak to czytamy. Google nie udostępnia żadnego API do
zakładania ani odczytywania spend capów — w API budżetu nie ma pola
mówiącego, czy limit twardo blokuje wydatki. Dlatego cap
rozpoznajemy po nazwie budżetu: znacznik
[SpendCaps] plus tag usługi, np.
[SpendCaps] [Gemini] prod. Status CAP znaczy
„ktoś oznaczył ten budżet jako limit i jego kształt na to pozwala",
nigdy „Google potwierdza, że blokada działa" — to trzeba sprawdzić w
konsoli. CAP ŹLE to budżet z tym znacznikiem, który
capem być nie może (obejmuje kilka usług, kilka projektów, nie jest
miesięczny albo nie ma kwoty). ALERT to budżet celowany w tę
usługę, ale bez znacznika — powiadomi, nie zatrzyma. Budżet na całe
konto bez filtra usługi nie liczy się jako pokrycie, bo liczyłby się
dla wszystkiego naraz.
Kolory i liczby. Zielony status i „pokrycie potwierdzone" to wyłącznie to, co odczytaliśmy z API. Klienci z luką liczy subkonta, nie pary: jedno subkonto z choćby jedną usługą bez capa to jeden klient na liście, a próg (nic nie wydaje / poniżej 1000 € / 1000–10 000 € / od 10 000 €) bierze wydatek całego subkonta z 30 dni, a nie pojedynczego projektu. Ten sam próg wybierają filtry nad listą, więc kafelek i lista zawsze pokazują ten sam zbiór. Zawieszone konta są osobnym widokiem — nie mogą wydawać, więc nie ma czego na nich ograniczać.