Zarządzanie kosztami narzędzi AI

Pierwszego dnia miesiąca pisze do Ciebie dział finansowy: pozycja za narzędzia AI urosła z błędu zaokrąglenia do pięciu cyfr, nikt nie potrafi powiedzieć, który zespół to wygenerował, a rozmowa o przedłużeniu subskrypcji jest już za tydzień. Nie masz jeszcze problemu z wydatkami — masz problem z widocznością. Tokeny są rozliczane według zużycia, a nie za miejsce, więc jeden inżynier uruchamiający agentowy refaktor na 200K tokenów na flagowym modelu potrafi w jedno popołudnie wydać więcej niż inny przez cały miesiąc. Ten przewodnik pokazuje, jak opanować te wydatki w Cursorze, Claude Code i Codeksie przy użyciu realnych, udokumentowanych mechanizmów każdego z narzędzi — bez budowania własnej platformy do zarządzania kosztami.

Co z tego wyniesiesz

• Działającą konfigurację widoczności kosztów dla każdego narzędzia: metryki OpenTelemetry w Claude Code, zespołowy dashboard użycia w Cursorze oraz raportowanie zużycia w Codeksie
• Realną konfigurację OTEL_RESOURCE_ATTRIBUTES, która przypisuje wydatki do zespołu i centrum kosztów
• Politykę wyboru modeli, która domyślnie sięga po tańsze modele i eskaluje tylko wtedy, gdy zadanie to uzasadnia
• Gotowe do wklejenia prompty do przeprowadzenia audytu wydatków i przeglądu routingu modeli z asystentem AI
• Konkretne tryby awarii (cicha telemetria, nadpisania z managed settings, alerty budżetowe, które nigdy się nie odpalają) i sposoby ich naprawy

Gdzie naprawdę uciekają pieniądze

Zanim cokolwiek oprzyrządujesz, ułóż sobie właściwy model myślowy. Rachunek napędzają trzy zmienne, w kolejności wpływu:

• Wybór modelu. Różnica między modelem flagowym a ze średniej półki to z grubsza 1,5–5x na token. Domyślne uruchamianie każdego zadania na najdroższym modelu to pojedyncze największe źródło marnotrawstwa.
• Rozmiar kontekstu. Za tokeny wejściowe też płacisz. Ładowanie całego repozytorium do kontekstu dla zmiany w jednym pliku jest po cichu kosztowne, a odczyty z cache tylko częściowo to równoważą.
• Pętle agentowe. Autonomiczne, wieloetapowe przebiegi (duże refaktory, pętle test-naprawa, dogłębny research) zwielokrotniają zużycie tokenów. Często są tego warte — ale muszą być świadomym wyborem, a nie przypadkiem.

Zarządzanie kosztami sprowadza się głównie do uczynienia tych trzech zmiennych widocznymi i nałożenia lekkich, nieblokujących barier ochronnych na kosztowne ścieżki. Nie potrzebujesz własnej „bramki kosztów” opartej na MCP ani wymyślonego frameworka w YAML-u. Każde narzędzie dostarcza gotowe prymitywy.

Krok 1: Włącz widoczność kosztów

Nie da się zarządzać tym, czego nie widać. Każde narzędzie udostępnia zużycie inaczej — telemetria CLI w Claude Code, dashboard administracyjny w Cursorze i raportowanie zużycia na poziomie organizacji w Codeksie. Skonfiguruj wszystkie trzy; tutaj przepływy pracy faktycznie się różnią.

Cursor

Cursor jest zorientowany na IDE, więc jego kontrole kosztów żyją w zespołowym dashboardzie administracyjnym (cursor.com/dashboard), a nie w plikach konfiguracyjnych. Jako administrator zespołu dostajesz:

• Zużycie według członka zespołu, podzielone na dwie wliczone pule na każde miejsce: Composer + Auto (modele własne Cursora) oraz Third-Party API (zużycie modeli na własnym kluczu BYO). To natychmiast ujawnia najintensywniejszych użytkowników.
• Miesięczne limity wydatków dla całego zespołu, które ucinają przekroczenia, zanim wymkną się spod kontroli.
• Inteligentne alerty na progach kwotowych, dostarczane na Slacka lub e-mailem, zanim spadnie na Ciebie niespodzianka na rachunku.
• Rekomendacje typu miejsca — Cursor sygnalizuje, kiedy zużycie danego członka pasuje do miejsca Standard ($32/miejsce/mies. rocznie) zamiast Premium ($96/miejsce/mies. rocznie), więc nie przepłacasz za lekkich użytkowników.

Nie ma nic do instalowania: widoczność jest wbudowana w dashboard planu Business/Teams. Twoim zadaniem jest włączenie limitu wydatków i alertów, a następnie comiesięczny przegląd rozbicia na poszczególnych członków.

Claude Code

Claude Code jest zorientowany na CLI i eksportuje najbogatszą telemetrię kosztów z całej trójki, poprzez OpenTelemetry. Włącz ją zmiennymi środowiskowymi (zweryfikowane względem oficjalnej dokumentacji monitorowania):

# Włącz telemetrię i wybierz eksportery
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER=otlp        # otlp | prometheus | console
export OTEL_LOGS_EXPORTER=otlp

# Wskaż swój collector (Grafana/Prometheus, Honeycomb, Datadog itd.)
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://collector.company.com:4317
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer ${OTEL_TOKEN}"

Metryki, które liczą się w pracy nad kosztami, są realne i udokumentowane: claude_code.cost.usage (USD, otagowane przez model), claude_code.token.usage (otagowane przez type: input/output/cacheRead/cacheCreation oraz model), claude_code.session.count i claude_code.active_time.total. Ta metryka cost.usage to cała gra — zsumuj ją, pogrupuj po model i zespole, a masz wydatki per zespół bez budowania czegokolwiek.

Przy wdrożeniu na całą organizację przepchnij te same zmienne przez plik managed settings, żeby każdy deweloper raportował automatycznie i nie mógł tego po cichu wyłączyć.

Codex

Codex jest wielopowierzchniowy (App, CLI, IDE, Cloud) i od kwietnia 2026 wszystkie te powierzchnie działają domyślnie na GPT-5.5 (dla przepływów uwierzytelnianych kluczem API użyj gpt-5.2-codex). Ponieważ rozciąga się na wiele powierzchni, zużycie agreguje się na poziomie organizacji, a nie per CLI:

• W ChatGPT Business/Enterprise zużycie Codeksa jest wliczone w przydział kredytów planu, a administratorzy workspace’u widzą konsumpcję w analityce użycia/administracyjnej organizacji — w tym samym miejscu, gdzie zarządzasz miejscami.
• W przypadku zużycia na kluczu API (CLI lub IDE uwierzytelnione kluczem OpenAI) wydatki pojawiają się w dashboardzie użycia platformy OpenAI, gdzie możesz ustawić miesięczne limity budżetu i alerty e-mail na projekcie/organizacji.

Praktyczny ruch: zdecyduj dla każdego zespołu, czy Codex działa na kredytach planu (przewidywalne, ograniczone liczbą miejsc), czy na rozliczeniu API (pay-as-you-go, wymaga ustawienia limitu budżetu na platformie). Nie mieszaj jednego z drugim po cichu w obrębie jednego zespołu.

Notatka

Konfiguracja MCP jest identyczna we wszystkich trzech narzędziach. Jeśli dodasz serwer MCP związany z kosztami lub zużyciem (na przykład serwer kosztów chmury tylko do odczytu, jak ten od Vantage), konfiguracja JSON mcpServers ma ten sam kształt dla Cursora, Claude Code i Codeksa — różni się tylko lokalizacja pliku. Nie potrzebujesz żadnej „bramki kosztów” specyficznej dla narzędzia; traktuj MCP jako opcjonalny dodatek raportowy, a nie warstwę kontrolną.

Krok 2: Przypisz wydatki do zespołów

Zagregowane wydatki to liczba, którą się panikuje; przypisane wydatki to liczba, na której się działa. W Claude Code przypisanie to zmiana w jednej linijce. Zmienna OTEL_RESOURCE_ATTRIBUTES taguje każdą metrykę dowolnymi wymiarami, które ustawisz — i jest zgodna ze specyfikacją W3C Baggage, co oznacza brak spacji w wartościach (częsta pułapka):

# Poprawnie: pary key=value rozdzielone przecinkami, bez spacji, zamiast nich podkreślenia
export OTEL_RESOURCE_ATTRIBUTES="department=engineering,team.id=platform,cost_center=eng-123"

# Źle: spacje są nieprawidłowe i po cichu psują atrybut
# export OTEL_RESOURCE_ATTRIBUTES="cost_center=Eng Platform"

Teraz claude_code.cost.usage da się odpytywać po team.id i cost_center w Twoim backendzie. Cursor załatwia to za Ciebie — dashboard jest już per członek i per zespół. Atrybucja w Codeksie jest per workspace/projekt, więc umieść każdy zespół w osobnym workspace ChatGPT lub projekcie API, jeśli potrzebujesz czystych liczb per zespół.

Uwaga

Nie buduj systemu inwigilacji. Taguj na poziomie zespołu i centrum kosztów, a nie pojedynczej osoby — chyba że inżynier sam się zgłosi po osobiste wskazówki optymalizacyjne. Zagregowany, zanonimizowany benchmarking daje 95% zysków kosztowych bez nadszarpywania zaufania. Claude Code pozwala nawet usunąć user.account_uuid i session.id z metryk poprzez OTEL_METRICS_INCLUDE_ACCOUNT_UUID=false i OTEL_METRICS_INCLUDE_SESSION_ID=false, jeśli wymaga tego Twoja polityka.

Krok 3: Ustal politykę wyboru modelu

To tutaj rodzi się większość oszczędności. Zasada jest prosta: domyślnie sięgaj po najtańszy model, który wykona zadanie, eskaluj świadomie i wrzucaj kosztowne myślenie na początek tam, gdzie zapobiega ono drogim poprawkom. Oto rozsądna domyślna polityka dla obecnej oferty (czerwiec 2026):

Zadanie	Model domyślny	Eskaluj do	Kiedy eskalować
Poprawki składni, zmiany nazw, porządkowanie importów	Haiku 4.5 / Auto	-	Nigdy
Codzienna praca nad funkcjami, przeglądy kodu	Sonnet 4.6	Opus 4.8	Zmiana wrażliwa pod kątem bezpieczeństwa lub architektoniczna
Złożone debugowanie (wyścigi, wydajność)	Sonnet 4.6	Opus 4.8	Reprodukcja nieoczywista po pierwszym podejściu
Projektowanie architektury, duże refaktory	Opus 4.8	Fable 5	Gdy złożoność uzasadnia szczytową inteligencję, a budżet jest drugorzędny
Budowanie od zera, refaktory między repozytoriami, długotrwałe zadania	Fable 5	-	Używaj jako modelu domyślnego, gdy szybkość i jakość ważniejsze niż koszt tokenów; subagenci nadal działają automatycznie na niższych poziomach, więc koszty pozostają pod kontrolą

W Cursorze selektor modelu czyni z tego decyzję per żądanie — zacznij na Auto/Sonnet 4.6 i przeskocz na Opus 4.8 dopiero wtedy, gdy zadanie utknie. W Claude Code ustaw domyślny model w ustawieniach i przełączaj w trakcie sesji przez /model. W Codeksie GPT-5.5 napędza wszystkie powierzchnie; cięższy wysiłek rozumowania zarezerwuj dla naprawdę trudnych zadań, zamiast uruchamiać każdy prompt na maksimum.

Wskazówka

Gotowy prompt — przeprowadź comiesięczny przegląd routingu modeli. Wklej to do Claude Code lub agenta Cursora skierowanego na wyeksportowaną telemetrię lub eksport z dashboardu:

Here is last month’s AI usage data (cost by model and by team). Act as a FinOps reviewer.

1. Which teams are running flagship-tier models (Fable 5 / Opus 4.8 / max-effort GPT-5.5) for tasks that a mid-tier model (Sonnet 4.6) would handle? Quantify the spend on those tasks.
2. Where is cache-read token usage low relative to input tokens, suggesting context is being reloaded instead of reused?
3. Recommend three specific routing changes, each with an estimated monthly dollar saving and the quality risk of making it. Be concrete and show your arithmetic. Do not recommend changes that would slow down incident response.

Krok 4: Nałóż lekkie bariery ochronne na kosztowne ścieżki

Twarde blokady rodzą shadow IT i niechęć. Stawiaj na przejrzystość i delikatne podpowiedzi zamiast bramek akceptacji:

1. Ogranicz przypadki niekontrolowane, nie rutynowe. Ustaw miesięczny limit wydatków dla całego zespołu w Cursorze oraz limit budżetu na platformie Codeksa jako zabezpieczenie przed wypadkami (zapomniana pętla, źle skonfigurowana automatyzacja), a nie jako codzienną smycz. Ustaw próg tam, gdzie żyje prawdziwa niespodzianka — 150–200% normalnego miesiąca — żeby odpalał się tylko na anomaliach.

2. Alarmuj, zanim zablokujesz. Podepnij inteligentne alerty Cursora do Slacka na, powiedzmy, 80% limitu miesięcznego. W Claude Code alarmuj, gdy claude_code.cost.usage przekroczy kroczący próg w Grafanie/Twoim backendzie. Ludzie sami się korygują, kiedy widzą licznik.

3. Uczyń dyscyplinę kontekstu nawykiem, a nie regułą. Najtańszy token to ten, którego nie wysyłasz. Zachęcaj do zawężania kontekstu do plików w grze i korzystania z kompaktowania w każdym narzędziu (/compact w Claude Code, rozpoczynanie świeżych sesji do niezwiązanej pracy) zamiast wleczenia rozdętego kontekstu między zadaniami.

4. Przeglądaj co miesiąc, koryguj co kwartał. Wyciągnij rozbicie per zespół raz w miesiącu, uruchom powyższy prompt do przeglądu routingu i rewiduj budżety oraz politykę tylko wtedy, gdy mówią o tym dane.

Wskazówka

Gotowy prompt — rozpoczęcie sesji ze świadomością kosztów. Użyj tego na początku ciężkiej sesji w dowolnym z trzech narzędzi, by uczynić koszt ograniczeniem pierwszej kategorii:

Before we start: this is a [bug fix / refactor / feature] in [area]. Optimize for cost without hurting quality.

1. Propose the minimal set of files you actually need in context for this task, and tell me which ones you’d skip.
2. Recommend a model: default to the cheaper tier unless you can justify the flagship for this specific task in one sentence.
3. If you hit a point where escalating the model or widening context would clearly pay off, stop and ask me first instead of doing it silently.

Kiedy to się psuje

Realne tryby awarii z wdrażania tego w zespołach — i jak je naprawić.

• Metryki nigdy nie docierają do backendu. Niemal zawsze to zły endpoint albo niezgodność protokołu. Upewnij się, że OTEL_EXPORTER_OTLP_ENDPOINT wskazuje na port, którego Twój collector faktycznie nasłuchuje (gRPC domyślnie :4317, HTTP :4318), oraz że OTEL_EXPORTER_OTLP_PROTOCOL się zgadza (grpc vs http/protobuf). Najpierw zdebuguj lokalnie z export OTEL_METRICS_EXPORTER=console i OTEL_METRIC_EXPORT_INTERVAL=1000, by zobaczyć metryki wypisywane w terminalu w ciągu sekundy.

• Telemetria jest po cichu wyłączona. Jeśli CLAUDE_CODE_ENABLE_TELEMETRY nie jest ustawione (albo plik managed settings nadpisuje Twój eksport z powłoki), żadne metryki nie płyną, a Twoje dashboardy pozostają puste, podczas gdy wydatki rosną. Managed settings z założenia wygrywają nad zmiennymi środowiskowymi użytkownika — sprawdź kolejność pierwszeństwa ustawień, jeśli konfiguracja organizacji i lokalna się nie zgadzają.

• Atrybucja wraca pusta lub przekręcona. Spacje w OTEL_RESOURCE_ATTRIBUTES łamią specyfikację W3C Baggage i psują wartość. Cudzysłowy nie escapują spacji — org.name="My Team" zapisuje dosłowne cudzysłowy. Użyj podkreśleń lub camelCase.

• Alerty budżetowe, które nigdy się nie odpalają. Limit wydatków bez alertu poniżej niego to po prostu mur, w który wjeżdżasz na pełnej prędkości. Zawsze ustawiaj próg alertu (np. 80%) poniżej dowolnego twardego limitu i przetestuj go, tymczasowo obniżając próg poniżej bieżących wydatków, by potwierdzić, że ścieżka Slack/e-mail faktycznie dostarcza.

• Nazwy modeli rozjeżdżają się w dokumencie polityki. Polityka routingu przypięta do modeli z poprzedniego cyklu po cichu kieruje pracę do modeli wycofanych lub droższych, niż to konieczne. Co kwartał ponownie weryfikuj aktualną ofertę i cennik — krajobraz modeli zmienia się szybko, a „domyślnie Opus 4.8 / Sonnet 4.6” dziś nie będzie właściwym ciągiem za pół roku.

• Błędy uwierzytelniania bramki MCP. Jeśli jednak postawisz raportowanie kosztów na serwerze MCP, błąd 401/403 na jego endpoincie oznacza, że cała ścieżka raportowania gaśnie, nie krzycząc głośno w Twoich dashboardach. Traktuj serwery raportowe MCP jako wzbogacenie typu best-effort, nigdy jako podstawowe źródło prawdy — niech telemetria natywna dla narzędzia pozostanie źródłem prawdy.

Co dalej

• Strategie wdrażania i adopcji w zespole - doprowadź cały zespół do produktywności w tych narzędziach, zanim zaczniesz optymalizować jego wydatki
• Standardy bezpieczeństwa i zgodność - kontrole dostępu i ślady audytowe, które idą w parze z zarządzaniem kosztami
• Optymalizacja kosztów kontekstu - głębsza wersja powyższych taktyk dyscypliny kontekstu
• Wprowadzenie do Model Context Protocol - jak identyczna konfiguracja MCP działa we wszystkich trzech narzędziach

Notatka

Zacznij od małego. 30-dniowy pilotaż wystarczy, by udowodnić wartość: włącz metryki OpenTelemetry w Claude Code dla jednego zespołu, uruchom zespołowy limit wydatków i alerty na Slacku w Cursorze oraz raz przeprowadź comiesięczny prompt do przeglądu routingu. To da Ci realne liczby per zespół i jedną rundę optymalizacji, zanim zdecydujesz się na coś większego.