O czym jest ten film
- Autor płaci 200 dolarów miesięcznie za Claude Code, a wbudowany panel zużycia nieustannie pokazuje 0 dolarów — i nigdy nie pokazał niczego innego.
- Powód jest prosty: panel liczy tokeny API, a subskrypcja takich danych nie generuje. Cała reszta widoku to procenty wyczerpanego limitu.
- Autor sięga po D-Zero z modułem AI SDLC Insights — telemetrię, która czyta sesje kodowania i pokazuje koszt każdej z nich oraz to, czy sesja w ogóle coś przyniosła.
- Fundamentem rozwiązania jest OpenTelemetry: plugin jest otwarty, jego kod można obejrzeć na GitHubie przed instalacją, a dane odpytywać przez PromQL i SQL.
- W konfiguracji kluczowe są dwa szczegóły: instalacja pluginu w zakresie „user” (nie „project”) oraz natychmiastowe podłączenie GitHuba, bo narzędzie nie uzupełnia historii wstecz.
- Dwa dni pracy wycenione po publicznych stawkach API to około 214–221 dolarów — czyli więcej niż miesięczna subskrypcja.
- Model Opus pochłonął 58% budżetu przy zaledwie 27 promptach, często na trywialne zadania typu zmiana nazwy pliku.
- Sortowanie sesji po koszcie ujawniło sesję za 44 dolary: cztery godziny pracy, 470 wywołań narzędzi, 35 nieudanych, a finalnie — usunięta gałąź bez pull requesta.
- Panel szczegółów sesji pokazuje odczyty z cache’a, nieudane wywołania narzędzi i pozwala odtworzyć całą rozmowę z agentem.
- Wniosek wdrożeniowy: 10 dolarów miesięcznie za pełną widoczność kosztów plus zmiana routingu modeli — Opus do planowania, Sonnet do wszystkiego innego.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Wbudowany licznik kosztu nie zadziała na subskrypcji
Na czym polega: Polecenie /usage w Claude Code pokazuje koszt wyłącznie dla rozliczenia po tokenach API. Na subskrypcji (np. plan za 200 dolarów) licznik stoi na zerze, bo z perspektywy systemu nie generujesz żadnych opłat.
Jak stosować: Nie traktuj zera jako „braku kosztu” — traktuj je jako brak pomiaru. Jeśli pracujesz na abonamencie i chcesz znać realny koszt swoich sesji, potrzebujesz pomiaru z zewnątrz.
Na co uważać: Panel /usage nadal mówi coś użytecznego o wyczerpaniu limitu i o tym, co napędza zużycie (np. sesje z subagentami, wielki kontekst). To dane o limicie, nie o pieniądzach — nie myl jednych z drugimi.
2.Koszt licz w ekwiwalencie API, nie jako rachunek
Na czym polega: Dostawca subskrypcji nie podaje kosztu pojedynczej sesji. D-Zero robi coś innego: bierze zużyte tokeny i wycenia je po publicznych stawkach pay-as-you-go. Powstaje liczba, która mówi, ile ta praca kosztowałaby przy rozliczaniu za zużycie.
Jak stosować: Taką wycenę czytaj jako miarę skali i porównania między sesjami oraz modelami — idealna do ustalania priorytetów optymalizacji.
Na co uważać: To nie jest kwota, którą faktycznie płacisz. Twoim realnym kosztem jest czas do wyczerpania limitu subskrypcji, a ta wycena jest jedynie przelicznikiem.
3.Wybieraj telemetrię, którą możesz podejrzeć
Na czym polega: Zebranie danych o własnej pracy wymaga zaufania do narzędzia. Tu zbieranie opiera się na OpenTelemetry — otwartym standardzie — a plugin ma otwarty kod dostępny na GitHubie przed instalacją. Dane pozostają odpytywalne przez PromQL i SQL.
Jak stosować: Przy wdrażaniu telemetrii do swojego środowiska sprawdź najpierw, co dokładnie jest wysyłane. Narzędzia zgodne z otwartymi standardami dają taką możliwość bez proszenia kogokolwiek o dostęp.
Na co uważać: Nawet otwarty plugin warto przejrzeć pod kątem tego, dokąd trafiają dane i jak długo są przechowywane — zgodność ze standardem nie zwalnia z tej weryfikacji.
4.Plugin instaluj w zakresie „user”, nie „project”
Na czym polega: Przy instalacji pluginu Claude Code pyta o zakres. Zakres „project” jest przypisany do ścieżki folderu — jeśli trzymasz to samo repozytorium w kilku katalogach roboczych (work trees), plugin po prostu nie wczyta się w pozostałych.
Jak stosować: Wybierz zakres „user”, a plugin będzie dostępny wszędzie tam, gdzie pracujesz jako ty — niezależnie od układu katalogów.
Na co uważać: Zakres „project” bywa sensowny, gdy plugin ma działać tylko w jednym repozytorium i towarzyszyć zespołowi w kodzie. Dla własnej, osobistej telemetrii to pułapka.
5.Podłącz GitHub w dniu konfiguracji
Na czym polega: Narzędzie łączy koszt sesji z jej efektem w repozytorium — ale widzi tylko te pull requesty, które zaobserwowało po połączeniu kont. Historii nie uzupełnia wcale.
Jak stosować: Skonfiguruj integrację z GitHubem od razu, jeszcze tego samego dnia, nawet jeśli analizę zostawiasz na później. Każdy dzień zwłoki to luka w danych o efektach pracy.
Na co uważać: Bez integracji dostaniesz pół obrazu — dokładne koszty sesji bez informacji, czy cokolwiek z nich trafiło do kodu. A to właśnie ta druga połowa pozwala wykryć wycieki.
6.Porównuj koszt modelu z liczbą promptów
Na czym polega: Panel kosztów wg modeli pokazuje obok siebie wydatki, udział procentowy i liczbę promptów. W przypadku autora Opus zjadł 58% budżetu przy 27 promptach — mniej niż jedna trzecia zapytań, prawie trzy piąte pieniędzy.
Jak stosować: Przyjrzyj się, do czego naprawdę idą drogie prompty. Jeśli najdroższy model zajmuje się błahostkami — zmianą nazwy pliku, drobnymi poprawkami — to gotowy obszar oszczędności.
Na co uważać: Na niską liczbę promptów przy wysokim koszcie można też patrzeć pozytywnie: znaczy, że pojedyncze zadania są ciężkie. Sedno w tym, czy te ciężkie zadania są tego warte.
7.Wprowadź routing modeli i zweryfikuj go za miesiąc
Na czym polega: Konkretna zasada autora: do planowania architektury i ważnych decyzji idzie Opus, wszystko inne zaczyna się na Sonnet. Zapowiedział powrót do tego samego panelu po czterech tygodniach, żeby sprawdzić, czy zasada się przyjęła.
Jak stosować: Ustal własny podział ról między modelami, zapisz go i zaplanuj ponowny przegląd danych po kilku tygodniach. Panel kosztów stanie się wtedy rozliczeniem z samego siebie, a nie jednorazową ciekawostką.
Na co uważać: Zmiana routingu wymaga nawyku — przełączanie modelu to dodatkowa czynność, o którą łatwo w trakcie pracy. Bez planowanego przeglądu dane szybko pokażą nawrót starych przyzwyczajeń.
8.Każdą drogą sesję konfrontuj z repozytorium
Na czym polega: Widok sesji pozwala sortować po koszcie i sprawdzić w gicie, co z nich wynikło. Najdroższa sesja autora: 44 dolary, cztery godziny, 10 promptów — a gałąź, nad którą agent pracował, nigdy nie stała się pull requestem, nie została scalona i w końcu została usunięta.
Jak stosować: Raz na jakiś czas posortuj sesje malejąco po koszcie i przejdź po górnym wierszach do repozytorium. Sesje bez pull requesta, scalenia czy choćby sensownego diffu to najszybszy trop do wycieków.
Na co uważać: Brak scalenia nie zawsze znaczy brak wartości — bywa, że sesja eksploracyjna świadomie kończy się porażką. Częsty jednak wzorzec: długa, kosztowna pętla pracy, która kończy się niczym, bo nikt jej nie przerwał w porę.
9.Nieudane wywołania narzędzi to sygnał kręcenia się w kółko
Na czym polega: Panel szczegółów sesji rozkłada ją na czynniki: tokeny wejściowe z osobnymi odczytami z cache’a, tokeny wyjściowe, wywołania narzędzi i te nieudane — tu 470 wywołań, z których 35 zawiodło. Poniżej ranking narzędzi i serwerów MCP z licznikami błędów, a w zakładce „conversations” da się odtworzyć całą rozmowę.
Jak stosować: Gdy sesja kosztuje podejrzanie dużo, zacznij od nieudanych wywołań i powtarzających się narzędzi z błędami. W przypadku autora błędy sypała głównie jedna rzecz — w kółko. To wskazówka, gdzie agent utknął.
Na co uważać: Pojedyncze błędy są normalne. Sygnałem dopiero jest powtarzalność: to samo narzędzie, ten sam błąd, rosnący licznik i kontekst, który puchnie z każdą próbą.
10.Długa nieprzerwana praca agenta to nie zawsze sukces
Na czym polega: Metryka czasu nieprzerwanej pracy pokazuje, jak długo agent działa, nim człowiek wkroczy i go przerwie. U autora niemal wszystko przekracza 20 minut, a najdłuższy słupek sięga ponad 40 — liczby wreszcie potwierdzają, że faktycznie deleguje pracę. Ale to sama w sobie nie jest zaleta: następna zakładka pokazała czterogodzinną sesję bez efektu.
Jak stosować: Traktuj ten pomiar w parze z efektami z repozytorium. Długi czas pracy plus scalony pull request to dobrze rozdysponowany czas; długi czas pracy plus usunięta gałąź to wyciek.
Na co uważać: Statystyka sama w sobie nie rozstrzyga — autonomiczność agenta bywa i osiągiem, i ryzykiem. Dopiero skrzyżowanie jej z kosztem i wynikiem w kodzie nadaje jej znaczenie.
Redakcyjne tłumaczenie
Zero, które zawsze jest zerem
Płacę 200 dolarów miesięcznie za Claude Code. W interfejsie jest okienko, które ma mi mówić, ile wydaję — u mnie widnieje w nim zero dolarów. Zawsze tak było. Postanowiłem więc zmierzyć swoje wydatki gdzie indziej. Okazało się, że dwa dni mojej pracy, przeliczone na rozliczenie za tokeny, odpowiadają 221 dolarom. Posortowałem potem wszystkie sesje według kosztu i na samej górze znalazłem jedną za 44 dolary: cztery godziny pracy, a w rezultacie — nic.
Właśnie o tym jest ten materiał. Zaczynajmy.
Dlaczego /usage nie mierzy subskrypcji
Pierwszą rzecz możesz sprawdzić od razu, teraz. Wpisz w Claude Code /usage — otworzy się panel. Na samej górze jest blok sesji z kwotą w dolarach: „total cost 0 USD”. I nie dlatego, że właśnie go otworzyłem. Ta liczba się nie rusza. Nigdy się nie ruszała, bo okienko liczy tokeny API — a ja jestem na subskrypcji. Z punktu widzenia tego licznika nie wydałem nigdy ani centa.
Wszystko poniżej to procenty. Bieżąca sesja: 0%. Bieżący tydzień: 14%. Dalej panel mówi, co napędza zużycie: 98% mojego limitu pochłonęły sesje intensywnie korzystające z subagentów, a 48% — praca z kontekstem przekraczającym 150 tysięcy tokenów. Potem jest rozbicie według umiejętności i subagentów, ale spójrzcie na kolumnę z danymi: to wciąż wyłącznie procenty. Widzę więc, jaką część limitu spaliłem. Nie widzę, ile to kosztowało — i tym bardziej nie widzę, czy cokolwiek z tego wyszło.
D-Zero: telemetria sesji zamiast serwerów
Narzędziem, do którego sięgnąłem, jest D-Zero, a konkretnie jego moduł AI SDLC Insights w sekcji Darkplane.
(Informacja dodatkowa: SDLC to skrót od software development life cycle — cykl wytwarzania oprogramowania od pomysłu po wdrożenie.)
Zasadnicza różnica: narzędzie czyta twoje sesje kodowania, a nie twoje serwery. Dzięki temu widać, ile kosztowała każda sesja — i czy sesja zamieniła się w cokolwiek konkretnego.
Że w ogóle zgadzam się, by coś czytało moją pracę? Da się to pogodzić z rozsądkiem, bo całość jest zbudowana na OpenTelemetry. Zbieranie danych to plugin o otwartym kodzie, oparty na otwartym standardzie — zanim cokolwiek zainstalujesz, możesz na GitHubie zobaczyć, dokładnie co przechwytuje. A własne dane nadal możesz odpytywać przez PromQL i SQL.
Konfiguracja krok po kroku
Zakładam konto, a z ustawień potrzebuję dwóch rzeczy: tokenu (znajdziesz go na stronie tokenów) oraz punktu końcowego OTLP.
(Informacja dodatkowa: OTLP to standardowy protokół przesyłania danych telemetrycznych w ekosystemie OpenTelemetry.)
Potem wracam do Claude Code i uruchamiam instalację pluginu oficjalnym poleceniem z rejestru Claude. Kluczowy moment przyjdzie, gdy instalator zapyta o zakres: wybierz „user”, nie „project”. Zakres „project” jest bowiem przypisany do ścieżki folderu — a ja trzymam to samo repozytorium w kilku katalogach roboczych i w pozostałych plugin po prostu by się nie wczytał.
Konfigurację kończę poleceniami pluginu — dokładnie w tej kolejności, w jakiej zaleca ją dokumentacja D-Zero — po czym przeładowuję pluginy i czekam na komunikat o połączeniu. I jedną rzecz radzę zrobić od razu, jeszcze dziś, a nie „kiedyś”: podłączenie GitHuba w ustawieniach, w sekcji integracji. Narzędzie liczy wyłącznie te pull requesty, które widziało na własne oczy, i nigdy nie uzupełnia historii wstecz.
Ile naprawdę kosztują dwa dni pracy
W panelu przechodzę do Darkplane, potem do AI SDLC Insights. Wzdłuż góry biegną zakładki: przegląd, koszty, adopcja, produktywność, narzędzia i umiejętności oraz sesje. Zacznijmy od kosztów.
Najpierw ważne zastrzeżenie: ta liczba to nie rachunek. Mam subskrypcję ze stałą opłatą i Anthropic w ogóle nie podaje mi kosztu pojedynczej sesji. D-Zero robi więc coś innego — bierze zużyte tokeny i wycenia je po publicznych stawkach dla płacących za zużycie. Powstaje ekwiwalent w cenach API. I tak: dwa dni mojej pracy to 214 dolarów, podczas gdy za cały miesiąc płacę 200. Szczerze mówiąc, pierwsza myśl po zobaczeniu tej liczby nie brzmiała „wydaję za dużo”. Raczej odwrotnie.
Kolejny panel to koszt według modeli. Każdy model dostaje pozycję w rankingu: wydatek, udział w całości i, obok, liczba promptów. Opus: 124 dolary, czyli 58% wszystkiego. A promptów? Dwadzieścia siedem. Jest tam też średni koszt na użytkownika, ale u mnie to ta sama liczba po raz drugi, bo jestem jedynym użytkownikiem — ten kafel nic nie wnosi.
Wróćmy jednak do sedna: prawie 60% pieniędzy przy mniej niż jednej trzeciej zapytań. I przy tym wielu z tych drogich promptów wcale nie dotyczyło decyzji architektonicznych. Spora ich część to ja, każący Opusowi zmienić nazwę pliku, bo nie chciało mi się wcześniej przełączyć modelu.
Agent pracuje bez nadzoru — i to widać
Druga rzecz, którą chcę pokazać, siedzi w zakładce adopcji: panel czasu nieprzerwanej pracy agenta. Mierzy, jak długo agent potrafi działać, nim człowiek wkroczy i go przerwie. U mnie na wykresie jest jeden malutki słupek poniżej pięciu minut — a cała reszta przekracza dwadzieścia, przy czym najwyższy sięga ponad czterdziestu.
Przez miesiące powtarzałem sobie, że deleguję pracę temu narzędziu. I przez raz w końcu moje własne liczby to potwierdzają. Choć, jak za chwilę zobaczycie w następnej zakładce, nie zawsze jest to dobra wiadomość.
Sesja za 44 dolary, która nic nie dostarczyła
To zakładka, po którą tu przyszedłem: sesje. Każdy wiersz to jedna sesja — użytkownik, godzina rozpoczęcia, czas trwania, modele, koszt, liczba promptów — i każdą kolumnę da się sortować. Sortuję po koszcie. Na samej górze: 44 dolary, cztery godziny, dziesięć promptów.
Wchodzę potem do gita, nad którym ta sesja pracowała, i oglądam gałąź. Ta gałąź nigdy nie stała się pull requestem. Nigdy nie została scalona. Usunąłem ją.
W panelu szczegółów sesji są tokeny wejściowe z osobno wydzielonymi odczytami z cache’a, tokeny wyjściowe, wywołania narzędzi i wywołania nieudane: 470 wywołań, z których 35 zawiodło. Poniżej widać najczęściej używane narzędzia i serwery MCP, ułożone w ranking z licznikami błędów tuż obok — od razu wiadomo, które z nich sypały błędami. W moim przypadku była to głównie jedna rzecz, powtarzana w kółko. A w zakładce „conversations”, wewnątrz tej samej sesji, można odtworzyć całą rozmowę od początku do końca.
Dziesięć dolarów miesięcznie za obudzenie
Cena narzędzia to 10 dolarów od użytkownika miesięcznie. Czy to się u mnie opłaca? To najprostsza decyzja w tym całym materiale: patrzyłem przed chwilą na dwa dni pracy warte 247 dolarów i nie miałem pojęcia, które ich części w ogóle działały.
To, co zmieniam od razu, to dobór modeli — bo tam właśnie siedzą pieniądze. Gdy coś planuję, ta praca bez dyskusji trafia do Opusa. Wszystko inne zaczyna się na Sonnet. I wrócę do tego samego panelu za cztery tygodnie, żeby sprawdzić, czy się tego trzymałem.
Jeśli chcesz uruchomić to u siebie, D-Zero znajdziesz pod adresem d-zero.com — link do rejestracji zostawiam w opisie. W środku jest mnóstwo rzeczy, których ja jeszcze nawet nie dotknąłem, na przykład zakładka narzędzi i umiejętności, pokazująca, ile kosztują cię poszczególne umiejętności i automatyzacje. Może zrobimy o tym osobny materiał, jeśli będzie zainteresowanie.
Na tym dziś wszystko. Jeśli znalazłeś tu coś wartościowego, polub film i zastanów się nad subskrypcją — do zobaczenia w następnym.