Dobierz plan AI do zmierzonej pracy

Właściwy plan do programowania z AI to najtańszy poziom, który kończy reprezentatywny miesiąc pracy agentów z akceptowaną jakością, rzadko przerywany limitami, przy równoległości, jaką zespół zdąży przejrzeć, i w granicach zasad dotyczących danych oraz tożsamości. Dopasowanie mierzy się z logów użycia i zaakceptowanych pull requestów, a potem sprawdza co kwartał, bo limity i ceny się zmieniają.

Jest środa po południu, sesja Claude Code zatrzymuje się w połowie migracji z komunikatem o limicie, a najprostsze wyjście to kliknąć Upgrade. Albo odwrotnie: zespół płaci za najwyższy poziom na każdym stanowisku i nikt nie potrafi powiedzieć, czy dodatkowy limit kiedykolwiek pozwolił skończyć zadanie, którego tańszy plan by nie udźwignął. Ta strona jest dla programisty, który płaci za swój plan albo o niego wnioskuje, oraz dla tech leada, który zatwierdza poziomy stanowisk w zespole.

Scorecard Q2 · Plan: Który plan najlepiej pasuje do twojego rzeczywistego obciążenia (limity, długość sesji, równoległe sesje agentów)?

Odpowiedź za maksimum (3 punkty): „Kwartalny przegląd planu opiera się na reprezentatywnych zadaniach, równoległości, koszcie ukończonej pracy, danych o przerwach i wymaganiach nadzoru i zgodności (governance)”.

Co daje zmierzony przegląd planu

• Miesięczny zapis użycia zbudowany z /usage, ccusage i dziennika przerw, a nie ze wspomnienia najgorszego popołudnia.
• Regułę, która oddziela prawdziwy brak przepustowości od problemu z workflow, którego żaden plan nie naprawi.
• Tabelę decyzji, która każdemu wzorcowi w zapisie przypisuje zmianę planu, zmianę routingu albo brak zmian.
• Datowany zapis decyzji z właścicielem, warunkiem obniżenia planu i datą kolejnego przeglądu.
• Trzy prompty do skopiowania, które zamieniają logi w rekomendację możliwą do sprawdzenia.

Ceny planów i to, co zawiera każdy poziom, są na jednej stronie: ceny planów narzędzi AI do kodowania. Ta strona nazywa poziomy, ale nigdy nie powtarza ich cen, więc pozostaje poprawna, gdy cena się zmieni.

Które sygnały decydują o dopasowaniu planu?

Zbieraj sześć sygnałów przez reprezentatywny miesiąc. Pierwszy działa jak bramka: tańszy plan, który obniża jakość, wcale nie jest tańszy.

Sygnał	Jak go mierzyć	Decyzja, którą wspiera
Jakość zaakceptowanych zadań	Pull requesty agenta scalone bez istotnych poprawek oraz odsetek przejść przez bramki CI	Czy modele dostępne w planie w ogóle radzą sobie z zadaniem
Przerwy przez limity	Sesje zatrzymane przez limit pięciogodzinny lub tygodniowy, zapisane z datą i zadaniem	Czy większy limit w planie ma jakąkolwiek wartość
Koszt na zaakceptowane zadanie	Część subskrypcji plus opłaty za użycie ponad plan, podzielone przez zaakceptowane zadania	Czy tańszy albo większy poziom jest bardziej opłacalny
Bezpieczna równoległość	Liczba równoległych sesji agentów, które zdążysz przejrzeć w ciągu dnia bez nieaktualnych diffów i konfliktów scalania	Czy równoległa przepustowość jest użyteczna, czy tylko dostępna
Czas oczekiwania	Czas od komunikatu o limicie do wznowienia pracy	Czy czekanie na reset szkodzi dostarczaniu
Governance	Wymagania dotyczące tożsamości, retencji danych, audytu i administracji dla kodu, nad którym pracujesz	Czy plan osobisty w ogóle wchodzi w grę

Wynikają z tego dwie reguły. Po pierwsze, porównuj koszt na zaakceptowane zadanie, nigdy cenę za token ani za stanowisko: mały plan, który wymusza ponowne uruchomienia i ręczne poprawki, może kosztować więcej na scaloną zmianę niż większy. Po drugie, ogranicz równoległość do przepustowości review. Każdy równoległy agent na subskrypcji korzysta z tych samych okien pięciogodzinnych i tygodniowych, więc trzech agentów, których wyniki czekają dwa dni na przegląd, zużywa limit i niczego nie dostarcza.

Gdzie odczytać użycie i limity w każdym narzędziu?

Każde narzędzie raportuje użycie inaczej, a kwota w widoku użycia nie zawsze jest twoim rachunkiem. Odczytuj widok na własnym koncie w dniu, w którym go zapisujesz.

Claude Code

Wpisz /usage w sesji. W planach Pro, Max, Team i Enterprise pokazuje paski wykorzystania planu, statystyki aktywności i rozbicie tego, co liczy się do limitów. /usage-credits zarządza płatnym użyciem ponad plan; wymaga logowania subskrypcją claude.ai, nie kluczem API.

Plany Pro, Max, Team i Enterprise działają w kroczącym oknie pięciogodzinnym oraz w oknie tygodniowym. W planach Team i Enterprise ten limit jest współdzielony z czatem Claude i Cowork, więc twój własny czat Claude i Cowork zużywają tę samą pulę stanowiska co twoje sesje agentów. Wraz z Claude Opus 5.5 (2026-09-22) Anthropic podniósł limity pięciogodzinne w planach Pro, Max, Team i Enterprise rozliczanym per stanowisko oraz dał subskrybentom reset limitu, który można zachować i użyć w wybranym momencie.

Trzy wybory korzystają z kredytów użycia albo z osobnego limitu zamiast ze zwykłej puli planu: Fast mode (w planach subskrypcyjnych wyłącznie przez kredyty użycia), Claude Fable 5.1 (może być rozliczany z kredytów użycia zależnie od planu i poziomu stanowiska, ma własny limit tygodniowy widoczny w /usage) oraz zarządzany Code Review i uruchomienia Ultrareview. Zapisuj je osobno, bo to decyzje routingowe, a nie dowód, że plan jest za mały.

Do miesięcznego zapisu odczytaj lokalne logi narzędziem ccusage (npm ccusage 20.0.26, sprawdzone 2026-09-26):

# Terminal: miesiąc dziennego użycia z lokalnych logów, z podziałem na agentów
npx ccusage@latest daily --since 2026-09-01 --by-agent --json > usage-2026-09.json
# Pięciogodzinne bloki Claude Code z ostatnich trzech dni, łącznie z aktywnym
npx ccusage@latest blocks --recent

daily --by-agent już obejmuje Codeksa; codex daily używaj tylko do widoku samego Codeksa, a nie jako dodatkowej sumy.

Codex

Wpisz /usage w sesji Codeksa (CLI 0.156.0 i nowsze), aby zobaczyć użycie konta albo wykorzystać zachowany reset limitu. /status pokazuje konfigurację sesji i zużycie tokenów, a w uprawnionych przestrzeniach roboczych także szacunkowe kredyty lub koszt na wątek.

Codex jest zawarty w planach ChatGPT Plus, Pro, Business, Edu i Enterprise. Limity działają w oknach pięciogodzinnych i tygodniowych, a po ich wyczerpaniu Codex oferuje kredyty i resety limitu. Dwa poziomy Pro dają pięć i dwadzieścia razy więcej użycia Codeksa niż Plus (źródło wtórne: TechCrunch, 2026-04-09). Pozostałe warunki planu nie są tu zweryfikowane (stan na 2026-09-26); bierz je ze swojego konta ChatGPT.

ccusage czyta też lokalne logi Codeksa. Eksport daily --by-agent z zakładki Claude Code już obejmuje Codeksa, więc tego polecenia używaj tylko do widoku samego Codeksa, a nie jako dodatkowej sumy:

# Terminal: użycie Codeksa dzień po dniu w miesiącu przeglądu
npx ccusage@latest codex daily --since 2026-09-01 --json > codex-2026-09.json

Cursor

Warunki planów Cursora nie są zweryfikowane na potrzeby tej strony (stan na 2026-09-26). Czytaj stronę użycia na swoim koncie przez pełny cykl rozliczeniowy i zapisuj datę każdego odczytu.

Aby trzymać kopię na własnej maszynie, użyj tokscale (npm 4.17.0), które pobiera użycie z API eksportu użycia Cursora. Najpierw zaloguj się w aplikacji desktopowej Cursora, a potem uruchom:

npx tokscale@latest cursor login --name work

Przewodnik po śledzeniu kosztów agentów pokazuje kolejne polecenia synchronizacji i raportu.

Kwota użycia na subskrypcji to szacunek

Claude Code liczy kwotę sesji w /usage lokalnie według cen katalogowych, a dla subskrybentów Pro i Max Anthropic pisze, że ta kwota „isn’t relevant for billing purposes”; to paski użycia pokazują, z czego faktycznie korzystasz. ccusage też wycenia tokeny z lokalnych logów. Używaj obu liczb do porównywania miesięcy i klas zadań, a do kosztu na zaakceptowane zadanie bierz fakturę.

Zapisuj przerwy przez miesiąc

Widoki użycia mówią, ile zużyłeś. Nie mówią, który komunikat o limicie zatrzymał prawdziwą pracę. Prowadź w repozytorium mały dziennik, jeden wiersz na przerwę, i uzupełniaj go w chwili, gdy komunikat się pojawi:

docs/ai/plan-fit-log.csv

date,tool,plan,task_class,parallel_sessions,model,effort,limit_hit,minutes_blocked,workaround,task_accepted,pr
2026-09-09,claude-code,Max 5x,multi-file change,3,claude-opus-5-5,high,five-hour,95,waited,yes,#412
2026-09-17,codex,Plus,review,1,gpt-6-astra,medium,weekly,0,used saved reset,yes,#431

Wypełniaj task_class ze stałej listy, na przykład small edit (mała edycja), multi-file change (zmiana w wielu plikach), review i long-running task (długie zadanie), aby dało się grupować wiersze. Kolumny parallel_sessions i effort są ważne, bo to dwie dźwignie, które zmieniają zużycie bez zmiany planu.

Przeprowadź kwartalny przegląd planu

Rób to raz na kwartał i dodatkowo po każdej zmianie warunków planu u dostawcy. Jednemu programiście zajmuje to godzinę. Zespołowi popołudnie, w większości spędzone na wspólnym czytaniu liczb.

1. Ustal zestaw zadań. Wybierz pięć do dziesięciu reprezentatywnych zadań na klasę spośród pull requestów scalonych w zeszłym miesiącu, łącznie z pracą równoległą lub długą, jeśli naprawdę ją wykonujesz. Zachowaj ten zestaw na wszystkie kolejne przeglądy, aby liczby były porównywalne.

2. Zbierz miesiąc dowodów. Wyeksportuj JSON z ccusage, dziennik przerw i listę pull requestów agenta ze statusem scalenia (gh pr list --state merged --limit 500 --search "merged:>=2026-09-01 merged:<2026-10-01" --json number,title,headRefName,labels,mergedAt > prs-2026-09.json). Bez --limit gh zwraca tylko 30 pull requestów. Pull requesty agentów rozpoznasz po etykiecie lub prefiksie gałęzi, na przykład label:agent.

3. Oddziel limity planu od wad workflow. Oznacz każdą przerwę jako przepustowość, routing (Fast mode, Fable, maksymalny poziom wysiłku (effort), zbyt wiele równoległych sesji agentów) albo workflow (niejasne zadanie, brak kontekstu, ponowne uruchomienia po nieudanych bramkach). Tylko wiersze z przepustowością uzasadniają dokupienie limitu.

4. Wyklucz niedopuszczalne plany. Odrzuć każdy poziom, który nie spełnia wymagań dotyczących danych, tożsamości, retencji lub administracji, zanim spojrzysz na cenę. Plan osobisty, który nie spełnia wymagań nadzoru i zgodności, nie jest opcją, nawet jeśli jest tani.

5. Sprawdź aktualne warunki. Odczytaj bieżącą cenę, zawarte użycie, zasady dopłat, dostęp do modeli i warunki danych dla pozostałych poziomów na stronie dostawcy i na swoim koncie. Zapisz datę. Porównanie cen planów to punkt wyjścia, a nie ostatnie słowo.

6. Zmień jedną zmienną na dwa tygodnie. Przejdź o jeden poziom w górę lub w dół albo zmień routing (poziom wysiłku, model, liczbę równoległych sesji), ale nie jedno i drugie. Uruchom ponownie stały zestaw zadań i dalej prowadź dziennik.

7. Zapisz decyzję. Dodaj do repozytorium (commit) poniższy zapis decyzji razem z plikami dowodów, właścicielem, warunkiem obniżenia lub podniesienia planu i datą kolejnego przeglądu.

Jaką zmianę planu uzasadniają dowody?

Porównaj miesięczny zapis z tą tabelą. Zmieniaj plan tylko wtedy, gdy zapis pasuje do wiersza, który to mówi.

Wzorzec w zapisie	Prawdopodobna przyczyna	Działanie
Brak przerw przez limity, a w większości tygodni zużyta mniej niż połowa okna tygodniowego	Plan za duży	Przetestuj przez dwa tygodnie poziom niżej na tym samym zestawie zadań, na przykład Max 20x na Max 5x albo stanowisko Team Premium z powrotem na Team Standard.
Limit pięciogodzinny osiągany w większość dni roboczych, okno tygodniowe rzadko wyczerpane	Skokowe użycie, często przez równoległe sesje agentów	Zmniejsz liczbę równoległych sesji do tego, co zdążysz przejrzeć, i zmierz ponownie. Jeśli przerwy trwają przy takiej równoległości, przejdź poziom wyżej.
Limit tygodniowy wyczerpany przed końcem tygodnia, w wierszach z przepustowością	Prawdziwy niedobór	Przejdź poziom wyżej (Pro na Max 5x, Plus na Pro, stanowisko Team Standard na Team Premium) i uruchom ponownie zestaw zadań.
Większość przerw to wiersze routingu	Fast mode, Fable lub maksymalny poziom wysiłku używane domyślnie	Najpierw popraw trasę na stronie o routingu modeli. Bez zmiany planu.
Wiele ponownych uruchomień i nieudanych bramek przed akceptacją	Wada workflow	Popraw zakres zadań, kontekst i bramki. Większy plan tylko szybciej opłaci te same porażki.
Intensywne, nierówne użycie w zespole	Stanowiska dobrane do najbardziej intensywnego użytkownika	Dobieraj stanowiska per osoba: Team Premium dla zmierzonych intensywnych użytkowników, Team Standard dla reszty albo Enterprise rozliczany za użycie, jeśli pasuje do umowy.
Kod objęty firmowymi wymaganiami (tożsamość, retencja, audyt) na planie osobistym	Plan niedopuszczalny	Przed jakąkolwiek inną zmianą przejdź na plan organizacyjny i zobacz konta zespołowe.

W planach rozliczanych za użycie porównuj się z wartością podawaną przez dostawcę tylko jako kontrolą zdrowego rozsądku. Strona kosztów Anthropic (code.claude.com, odczyt 2026-09-26) podaje dla wdrożeń enterprise średnio „around $13 per developer per active day and $150-250 per developer per month” za Claude Code. To liczba samego Anthropic; zastępuje ją twój miesiąc logów.

Zapisz decyzję o planie w repozytorium

Trzymaj jeden zapis na osobę lub zespół w repozytorium, obok dziennika, z którego powstał. Recenzent sprawdza liczby w podlinkowanych plikach, a nie w opisie.

docs/ai/plan-fit-2026-Q4.yaml

reviewed: 2026-09-26
owner: tech lead, platform team
scope: 6 developers, Claude Code primary, Codex for review
evidence:
  usage: usage-2026-09.json
  interruptions: docs/ai/plan-fit-log.csv
  task_set: evals/plan-fit/tasks.md
terms_checked: 2026-09-26, claude.com/pricing and the admin console
eligible_plans: [Team Standard, Team Premium, Enterprise]   # Pro and Max excluded: personal plans, our policy requires org SSO
decision: 4 Team Standard seats, 2 Team Premium seats
reason: two developers hit the weekly window on capacity rows in 3 of 4 weeks at 2 parallel sessions
cost_per_accepted_task: { before: "fill from invoice", after: "fill after trial" }
downgrade_trigger: a Premium seat uses under half its weekly window for 4 straight weeks
escalation_trigger: more than 2 capacity interruptions per developer per week at reviewable concurrency
next_review: 2026-12-15

Progi w warunkach to polityka startowa, a nie standard branżowy. Ustal własne na podstawie pierwszego miesiąca.

Prompty do skopiowania przy przeglądzie planu

Prompt do skopiowania: zbuduj miesięczny zapis użycia

Read usage-2026-09.json (ccusage output), docs/ai/plan-fit-log.csv, and the merged
pull request list in prs-2026-09.json. For each week, report: tokens and estimated cost
per agent, number of limit interruptions by type (five-hour, weekly), minutes blocked,
peak parallel sessions, and agent pull requests merged. Then compute cost per accepted
task for the month using the subscription cost I give you: SUBSCRIPTION_USD=200.
Report only numbers that come from these files and mark missing values as missing.
Do not edit any files.

Prompt do skopiowania: oddziel przepustowość od problemów workflow

Classify every row of docs/ai/plan-fit-log.csv as exactly one of:
capacity (the limit stopped accepted work at normal effort and reviewable concurrency),
routing (Fast mode, Fable, maximum effort, or more parallel sessions than were reviewed
that day), or workflow (the task was rerun because of vague scope, missing context,
or failed tests). Show the rule you applied to each row in one line.
End with a count per class and say whether the capacity rows alone justify a larger plan.

Prompt do skopiowania: porównaj dopuszczalne plany i przygotuj zapis

Here are the plan terms I copied today from the vendor pages and my admin console:
<paste terms>. Use only these terms. Drop any plan that fails these requirements:
SSO, 30-day retention or less, admin audit log. For the remaining plans, estimate
monthly cost for our measured usage from the record above, and list every term that
is missing (region, tax, overage behaviour, model access, retention).
Then draft docs/ai/plan-fit-2026-Q4.yaml with a decision, a downgrade trigger,
an escalation trigger, and a next review date. Do not invent any price.

Trzeci prompt celowo prosi o listę brakujących warunków: porównanie, które uzupełnia luki z pamięci modelu, to najczęstsza droga, którą nieaktualna cena trafia do decyzji.

Jak udowodnić, że zmiana planu zadziałała, bez czytania każdego diffa?

Zmiana planu to eksperyment, a dowody już są w twoich narzędziach.

• Zestaw zadań jest ewaluacją. Po zmianie uruchom ponownie te same stałe zadania. O zaliczeniu decydują ich bramki (testy, sprawdzanie typów, lint), dokładnie jak w ewaluacji routingu modeli.
• CI raportuje jakość. Odsetek przejść przez bramki i udział pull requestów agenta scalonych bez poprawek, według definicji z metryk cyklu życia, muszą się utrzymać lub poprawić po obniżeniu planu.
• Dziennik raportuje przepustowość. Po podniesieniu planu liczba przerw z powodu przepustowości na programistę tygodniowo musi spaść. Jeśli nie spada, problem leżał w routingu albo w workflow.
• Faktura raportuje koszt. Koszt na zaakceptowane zadanie pochodzi z faktury i scalonych pull requestów, a nie z szacunków /usage czy ccusage. Metoda kosztu zaakceptowanej zmiany definiuje pełny wzór, gdy zapyta dział finansów.
• Jedna osoba zatwierdza. Programista zatwierdza własny plan. Tech lead jest właścicielem poziomów stanowisk w zespole i zapisu decyzji przez CODEOWNERS, a dział finansów widzi zapis przed każdym zobowiązaniem rocznym.

Co psuje się przy doborze planu AI?

Objaw	Przyczyna	Naprawa
Najwyższy poziom na każdym stanowisku i nikt nie wie dlaczego	Plan wybrany według marki albo najgorszego popołudnia	Zbieraj logi przez miesiąc, przeprowadź przegląd i przetestuj poziom niżej, zaczynając od najmniej intensywnych użytkowników.
Podniesienie planu nie zmniejszyło liczby przerw	Przerwy były wierszami routingu lub workflow	Cofnij zmianę przy najbliższej dacie rozliczenia, popraw trasę albo zakres zadań i zmierz ponownie.
Limity osiągane tylko w dni z wieloma równoległymi agentami	Równoległość powyżej przepustowości review	Ogranicz równoległe sesje do tego, co zostanie przejrzane tego dnia, a resztę uruchamiaj po kolei w izolowanych worktree.
„You’ve hit your session limit”, a zmiana modelu nie pomaga	Okna pięciogodzinne i tygodniowe są wspólne dla wszystkich modeli	Poczekaj na reset podany w komunikacie albo wykorzystaj zachowany reset. Tylko komunikat dotyczący konkretnego modelu („You’ve hit your Opus limit”) da się obejść, przełączając rodzinę modeli przez /model.
Komunikat Codeksa o limicie w oknie pięciogodzinnym albo tygodniowym	Pula planu ChatGPT na to okno jest wyczerpana	Otwórz /usage (Codex CLI 0.156.0 i nowsze), aby wykorzystać zachowany reset limitu, albo użyj kredytów. Zapisz to jako wiersz przepustowości tylko wtedy, gdy praca stanęła przy równoległości mieszczącej się w możliwościach review.
Stanowisko Team wyczerpuje się, choć agent jest używany lekko	Limit stanowiska jest współdzielony z czatem Claude i Cowork	Przed podniesieniem stanowiska uwzględnij w dzienniku użycie czatu i Cowork.
Tańszy plan wygląda dobrze, ale scalonej pracy jest mniej	Jakość spadła i nikt tego nie zmierzył	Traktuj jakość jak bramkę: przywróć poprzedni poziom, a potem spróbuj zmiany routingu.
Roczne zobowiązanie podjęte na podstawie anegdot	Brak testu i warunku wyjścia	Najpierw testuj w cyklu miesięcznym na stałym zestawie zadań i przed podpisaniem wpisz warunek obniżenia do zapisu decyzji.
Porównanie używa cen z poprzedniego kwartału	Warunki skopiowane z artykułu albo z pamięci	W dniu przeglądu odczytaj ponownie stronę dostawcy i swoje konto oraz opatrz datą każdy warunek w zapisie.
Firmowy kod na planie osobistym	Governance sprawdzone po cenie	Najpierw zastosuj wymagania dotyczące tożsamości, retencji i audytu, a potem porównuj tylko dopuszczalne plany.

Sprawdź swój przegląd planu

• Stały zestaw zadań i miesięczny okres pomiaru są spisane.
• Eksporty użycia, dziennik przerw i scalone pull requesty są dodane do repozytorium (commit) lub podlinkowane.
• Każda przerwa ma klasę: przepustowość, routing albo workflow.
• Niedopuszczalne plany odrzucono przed porównaniem cen.
• Aktualne warunki planów odczytano w podanym dniu na stronie dostawcy i na koncie.
• Koszt na zaakceptowane zadanie pochodzi z faktury, a nie z szacunku w widoku użycia.
• Zapis decyzji wskazuje właściciela, warunek obniżenia, warunek podniesienia i datę kolejnego przeglądu.
• Każdą zmianę planu sprawdzono na tym samym zestawie zadań.

Co dalej po doborze planu

Przed tą stroną wybierz główne narzędzie do pracy z agentami (Q1), bo plan wynika z narzędzia. Po niej przypisz każdą klasę zadań do modelu na podstawie dowodów (Q3), co często jest tańszym lekarstwem na przerwy niż większy plan.

Ceny planów narzędzi AI Aktualne poziomy, ceny i rozliczanie użycia ponad stanowisko.

Śledzenie kosztów agentów /usage, ccusage, monitory i budżety zespołów.

Konta zespołowe Powiąż loginy z organizacją i co miesiąc uzgadniaj stanowiska.

Klucz: scorecard dewelopera Każde pytanie scorecardu przypisane do strony kanonicznej.