Monitoring kosztów — alerty, hard cap i routing tańszych modeli

Q21 · Operacje i higiena Jak monitorujesz zużycie tokenów / koszt agentów?

Maksymalna odpowiedź: “Mam alerty / hard caps i świadomie używam tańszych modeli do drogich pętli.”

Dlaczego to ważne: Bez monitoringu nie da się sensownie myśleć o routingu modeli ani długości sesji. Najtańszą dźwignią kontroli kosztów jest widoczność.

Dlaczego to ważne w 2026

Raport FinOps Foundation z 2026 pokazuje, że 98% organizacji aktywnie zarządza dziś spendem na AI — z 63% rok wcześniej — ale tylko 44% ma jakiekolwiek finansowe guardraile wpięte na produkcji. Lukę widać w liczbach: nieskrępowany coding agent rozwiązujący jedno zadanie klasy SWE-bench pali $5–8 w opłatach API, agenty robią 3–10× więcej wywołań LLM niż chatboty, a w kwietniu 2026 audyt Fortune 500 przypisał $400M zbiorczego przepalenia sesjom agentic bez per-session ceilings.

Dla pojedynczego developera matematyka jest brutalniejsza, nie łagodniejsza. Sesja Claude Code spokojnie schrupie $30–60 w tokenach Opus 4.7 w jedno popołudnie wielogodzinnego debugu. “Mały” fan-out — pięciu równoległych reviewerów na repo z 500 plikami — kosztuje grosze na Haiku 4.5 i ponad $40 na Opusie. Źle skonfigurowany agent na cronie, zapętlony na błędzie, potrafi w nocy wyparować miesięczny budżet subskrypcji.

Najtańszą dźwignią jest widoczność. Nie da się sensownie myśleć o routingu modeli (Q3), długości sesji ani o tym, które subagenty zepchnąć na Haiku, jeśli nie wiesz, ile kosztuje każda pętla. Monitoring kosztów to nie zadanie finansów — to feedback loop, który robi każdą decyzję operacyjną uczciwą. Bez niego zgadujesz, a rachunek powie Ci, że zgadłeś źle dopiero cztery tygodnie później.

Jak naprawdę wygląda maksymalny wynik

Pełne punkty za Q21 dostajesz tylko wtedy, gdy wszystkie cztery poniższe są prawdziwe:

• Masz dashboard, na który faktycznie patrzysz. Nie “jest jakaś strona usage w Console” — masz go w bookmarkach, zerkasz co tydzień i potrafisz z pamięci powiedzieć, ile wydałeś w zeszłym miesiącu i który model dominował. Dla Claude Code: widok usage w Anthropic Console plus lokalne ccusage. Dla Cursora — per-user dashboard. Dla czystego API albo OpenRouter — konsola providera plus filtry spend per key.
• Masz hard caps po stronie providera. Nie “popilnuję sam” — realny workspace spend limit w Anthropic Console (albo OpenAI hard limit, albo Cursor team spend cap), który odetnie Cię, zanim runaway loop wydrąży kartę. Pointa hard capa jest taka, że odpala się, gdy śpisz.
• Masz alerty, które odpalają przed capem. Soft alert na 50% i 80% dziennego albo tygodniowego budżetu — mail, Slack albo webhook — żebyś korygował zanim uderzysz w ścianę. Sam hard cap bez alertingu oznacza, że pierwszym sygnałem trouble jest agent zatrzymujący się w połowie zadania.
• Routujesz drogie pętle na tańsze modele świadomie. Pięciu równoległych code-reviewer subagentów chodzi na Haiku 4.5, nie Opusie. Codemod na 200 plików zjechał na Sonnet albo Haiku. Nie odpalasz “mądrych” modeli na głupich pętlach i potrafisz wymienić dwie pętle z ostatniego tygodnia, gdzie konkretnie wybrałeś Haiku, by zaoszczędzić.

Cokolwiek mniej — “sprawdzam rachunek na koniec miesiąca”, “mam wrażenie, że Opus jest drogi”, “mam zamiar ustawić limit” — to mid-tier na Q21.

Aktualny krajobraz (zweryfikowany przez web search)

Widok usage w Anthropic Console

Anthropic Console (console.anthropic.com) to główna powierzchnia dla każdego na Claude API albo płatnym planie Claude Code. Widok usage rozbija spend per workspace, API key, model i dzień — dokładnie ta granulacja, której potrzebujesz, by wyłapać, że jeden subagent robi całe zniszczenie. Workspace spend limits pozwalają ustawić twardy sufit per workspace; jak go przekroczysz, requesty failują, póki nie podniesiesz capa albo nie zresetuje się okres. Sparuj to z usage alerts (mail po przekroczeniu procentu capa), a masz miękki sygnał i kill-switch.

Dla subskrybentów Claude Code slash command /usage pokazuje aktualne 5-godzinne okno, pozostały limit i szacunek kosztu sesji. /context pokazuje wypełnienie kontekstu — long-context sessions to miejsce, gdzie przejazdy Opusem cicho stają się drogie. Plany Team i Enterprise dodają widok zagregowany na claude.com/console.

ccusage i podobne CLI cost trackery

ccusage to de-facto open-source tracker dla Claude Code w 2026. Czyta lokalne pliki JSONL sesji w ~/.claude/projects/, parsuje każde wywołanie narzędzia i daje per-session, per-day i per-model szacunki kosztu bez dotykania API Anthropica. Działa offline, pokazuje koszt per sesja (wychwytujesz tę 4-godzinną sesję na Opusie za $28), i można go zaaliasować do shell prompta albo statusline.

Sąsiednie narzędzia warto znać:

• Claude Code Usage Monitor (Maciek-roboblog/Claude-Code-Usage-Monitor) — terminal dashboard z predykcjami burn-rate i ostrzeżeniami “time to limit”.
• claude-usage (phuryn/claude-usage) — lokalny dashboard z wykresami; subskrybenci Pro/Max dostają progress bar.
• ccflare — alternatywny parser plików sesji, czasem szybszy na dużej historii.
• cc-budget — community enforcer owijający Claude Code w per-session ceilings.

Żaden nie rozwiązuje dobrze spendu team-level — to narzędzia per-developer czytające lokalne pliki. Do widoczności zespołowej wciąż potrzebujesz Anthropic Console (albo warstwy LLM-observability — patrz niżej).

Dashboard kosztów Cursora

Model cenowy Cursora w 2026 jest request-based z miesięcznym capem zależnym od tieru i overage billingiem. Dashboard pod cursor.com/dashboard (i pod Settings → Account) pokazuje requesty zużyte, zostałe, stawkę overage i breakdown per model. Plan team dodaje per-seat breakdowns. Cursor dodał w 2026 per-user hard caps dla team adminów — ustawiasz sufit per seat, a Cursor zacznie obciążać użytkownika bezpośrednio (albo go zablokuje), gdy go przekroczy.

Dashboard usage OpenAI

Dla używających GPT-5.x jako fallback cross-vendor (Q3), dashboard Usage OpenAI (platform.openai.com/usage) to odpowiednik: spend per dzień, model i API key, plus konfigurowalne hard limits (odcinają) i soft limits (alert mailem). Hard limits OpenAI działają na poziomie organizacji — jeśli masz wiele projektów w jednym org, ustaw per-project dla izolacji.

Ustawianie hard caps + alertów (provider-side i self-hosted)

Wzorzec wszędzie ten sam; różni się tylko UI.

• Anthropic — Console → Settings → Workspaces → Spend limit. Miesięczny hard cap i alert mailowy na 80% (i opcjonalnie 50%). Dla subskrybentów Claude Code sama subskrypcja działa jako soft cap w 5-godzinnym oknie, ale dla użycia API-key i tak ustaw workspace limit.
• OpenAI — Settings → Billing → Usage limits. Ustaw hard i soft limit; zaznacz toggle per-project.
• Cursor — Settings → Team → Spending controls. Per-user caps dla adminów; pojedynczy użytkownicy ustawiają własny sufit w personal settings.
• OpenRouter / AI.cc — per-key spend limits plus webhook notifications. Przydatne, gdy abstrahowałeś nad providerami.
• Self-hosted observability — Langfuse, Helicone, Portkey, Vantage i Traceloop to dominujący stack 2026 dla atrybucji kosztu na poziomie trace’u. Siedzą przed wywołaniami LLM (proxy albo SDK middleware), tagują każdy request metadanymi (sesja, user, agent, numer PR) i pozwalają alertować na pochodne metryki — np. “alertuj, gdy sesja przekroczy $5”. Overkill dla solo developera, właściwa odpowiedź dla zespołów 3–4+ osób.

Routing drogich pętli na Haiku/Sonnet

Monitoring bez routingu to tylko obserwacja. Realna oszczędność pojawia się, gdy świadomie pchasz high-volume low-judgment pętle na tańsze modele. Drabinka 2026: Opus 4.7 za $5/$25, Sonnet 4.6 za $3/$15, Haiku 4.5 za $1/$5 — 5× spread na output. Pięciu równoległych Haiku subagentów kosztuje mniej niż jedno przejście Opusem.

Prawie zawsze na Haiku:

• Subagenty code review. Czytanie diffa i flagowanie problemów to kompetencja Haiku 4.5; i tak chcesz fan-outować 3–5 reviewerów.
• Codemody i mechaniczne refaktory. “Zmień nazwę funkcji w 200 plikach.” Haiku spokojnie; Opus to 5× podatek przy zerowym zysku jakości.
• Triage, klasyfikacja, summarization. Sortowanie ticketów, klasyfikacja linii logów, summarization changelogów.
• Fan-out subagentów. Jeśli orchestrator jest na Sonnet, liście zwykle powinny być na Haiku.

Uzasadnia Sonnet albo Opusa:

• Planowanie w Plan mode dla nietrywialnych zmian — Opus 4.7.
• Refaktory cross-file trzymające 30+ plików w spójnym kontekście — Opus.
• Normalne coding loopy (czytaj, edytuj, testuj, popraw) — Sonnet 4.6.
• Cokolwiek, gdzie Haiku zawiódł w A/B vs Sonnet. Oparte na dowodach, nie przeczuciach.

Wdrożenie krok po kroku

1. Otwórz Anthropic Console i popatrz na zeszły miesiąc. console.anthropic.com → Usage. Przefiltruj per model. Zanotuj ile poszło na Opusa vs Sonnet vs Haiku, który dzień był najdroższy i jak to się ma do budżetu planu. Pierwsza sesja jest czysto diagnostyczna — jeszcze nic nie zmieniaj.

2. Zainstaluj ccusage lokalnie. npm install -g ccusage (albo pipx install ccusage). Odpal po typowej sesji. Gdy zaufasz liczbom, zaaliasuj go do shell prompta albo statusline, byś widział koszt na żywo, a nie na koniec miesiąca.

3. Ustaw workspace spend hard cap w Anthropic Console. Wybierz ~1,3× Twojego typowego miesiąca — wystarczająco wysoko, by nie odpalał się w normalnej pracy, wystarczająco nisko, by łapać runaway w nocy. Console → Settings → Workspaces → Spend limit.

4. Ustaw soft alerty na 50% i 80% capa. Ten sam ekran, “Usage alerts” — dodaj notyfikacje mailowe. Zweryfikuj — chwilowo obniż próg, aż odpali raz, potem zresetuj.

5. Zrób to samo dla OpenAI, jeśli używasz GPT-5.x jako fallback. platform.openai.com/usage → Limits. Jeśli masz wiele projektów w jednym org, ustaw per-project.

6. Zidentyfikuj trzy najdroższe pętle z dashboardu. Ostatnie 30 dni — wybierz trzy kombinacje model-loop, które zjadły najwięcej tokenów. Dla każdej: czy to musiało być na Opusie, czy Sonnet/Haiku zrobiłby tę samą robotę?

7. Przekieruj top loop na tańszy tier. Subagent na Opusie → zmiana w Haiku frontmatter. Bulk codemod na Sonnet → odpal go przez Haiku. Wcommituj zmianę, nie pamiętaj o niej “na słowo”.

8. Dodaj linię kosztu per-PR do workflowu. Albo proxy Langfuse / Helicone tagujące per branch, albo ccusage --since <start-brancha> na końcu każdego PR-a. Koszt musi być czytelny w jednostce pracy, którą shipujesz.

9. Zrób z tego cotygodniowy nawyk. Każdy piątek: otwórz dashboard, popatrz na split per model, zapytaj “czy coś mnie zaskoczyło?” Zaskoczenia to miejsca, gdzie żyje następna decyzja o routingu.

10. Re-check po każdym release modelu. Gdy pojawia się nowy tier, przerankuj top trzy pętle pod nowy rate card. Cała pointa widoczności jest taka, że re-routing to zmiana jednej linii w configu.

Częste pułapki

• Brak kosztu per-PR albo per-task. Znasz miesięczny rachunek, ale nie potrafisz powiedzieć, ile naprawdę kosztowało wyshipowanie wczorajszego feature’a. Bez kosztu per-unit nie odróżnisz drogich i tanich featurów, nie zdecydujesz, czy warto puszczać agenta na tę klasę zadania. Fix: taguj trace’y per PR/branch (Langfuse / Helicone) albo czytaj ccusage --since na końcu każdego brancha.
• Runaway loopy bez kill-switcha. Agent w cyklu błąd → retry → re-prompt pali $50 w godzinę. Hard cap to ostatnia linia obrony, lepszy fix to per-session ceiling: cc-budget, max-token wrapper, albo alert na koszt sesji w Langfuse z auto-anulowaniem.
• Ignorowanie outlierów w miesięcznym total. Jeśli 70% spendu zeszłego miesiąca z trzech sesji, to tam żyje następna optymalizacja — nie w ścinaniu 5% z każdej innej. Posortuj malejąco i przeczytaj top trzy.
• Optymalizacja niewłaściwej pętli. Spędzasz popołudnie migrując subagenty na Haiku, by zaoszczędzić $4/miesiąc, a faktyczny Opus debug loop kosztuje $200/miesiąc. Rankuj po koszcie, zanim optymalizujesz; dashboard mówi, które ryby są duże.
• Hard cap bez alertingu. Cap się odpala, agent ginie w środku PR-a, Ty triagujesz nie ten problem (zablokowany merge) zamiast realnego (cap za nisko). Zawsze paruj hard cap z soft alertem na 80%.
• Ufanie self-reportowi modelu zamiast dashboardowi. /usage w Claude Code jest dobry do bieżącej sesji, do księgowości miesięcznej zawsze ufaj Console. Lokalne estymatory (w tym ccusage) mogą się rozjeżdżać, gdy zmieni się model card albo tokenizer.
• Traktowanie Opusa 4.7 jak Opusa 4.6. Tokenizer Opusa 4.7 generuje do 35% więcej tokenów dla tego samego inputu. Ten sam prompt, ten sam rate card, wyższy rachunek. Patrz na rachunek, nie tylko na opublikowaną stawkę.

Jak sprawdzić, czy już tam jesteś

• Otwierasz widok usage w Anthropic Console w mniej niż 10 sekund i zaglądałeś tam w ostatnich 7 dniach.
• Masz skonfigurowany workspace spend limit i wiesz, na jakiej liczbie jest ustawiony, bez sprawdzania.
• Masz soft alerty na 50% i 80% capa, a przynajmniej jeden z nich odpalił się w ostatnich 90 dniach (dowód, że działa).
• Masz ccusage albo odpowiednik zainstalowany lokalnie i potrafisz odczytać koszt ostatniej sesji jedną komendą.
• Potrafisz wymienić dwie konkretne pętle z ostatnich dwóch tygodni, gdzie świadomie wybrałeś Haiku albo Sonnet zamiast Opusa, by zaoszczędzić koszt.
• Przynajmniej jeden subagent w Twoim projekcie chodzi na Haiku 4.5 konkretnie dlatego, że to skosztorysowałeś, a nie tylko z defaultu.
• Znasz swoje top trzy najdroższe sesje z zeszłego miesiąca i wiesz, co napędziło koszt.
• Masz przynajmniej jedną liczbę kosztu per-PR albo per-task, nawet jeśli to ręczny odczyt ccusage --since.
• Jeśli używasz fallback vendora (Q3), ustawiłeś hard caps także na tym vendorze — nie tylko na Anthropicu.
• Re-checkujesz dashboard kosztów po każdym release modelu.

Dalsza lektura

Q3 · Routing modeli Wybieraj Opus / Sonnet / Haiku per zadanie — decyzja o routingu, której monitoring kosztów daje co mierzyć.

Q2 · Dopasowanie planu Dobierz plan Anthropica tak, by sama subskrypcja działała jako soft cap na miesięczny spend.

Q22 · Zarządzanie sekretami Drugie pytanie z higieny operacyjnej — trzymaj API keys poza repo i rotuj je według harmonogramu.

Zrób Developer Scorecard Oceń się na wszystkich 25 pytaniach w ~10 minut.