Dogłębne rozumowanie w Claude Code: poziomy effort i rozszerzone myślenie

Claude Code steruje głębokością rozumowania poziomami effort (low, medium, high, xhigh, max), ustawianymi przez /effort, flagę --effort, zmienną środowiskową albo ustawienia. Na obecnych modelach myślenie jest adaptacyjne: model sam decyduje na każdym kroku, ile myśleć w ramach wybranego poziomu. Wyższy poziom effort opłaca się przy niejednoznacznych problemach obejmujących wiele systemów, a o poprawności wyniku przesądzają testy, nie samo rozumowanie.

Ta strona jest dla programistów, którzy codziennie pracują z Claude Code, oraz dla tech leadów ustalających domyślne poziomy i limity effort dla zespołu. Typowa sytuacja: endpoint zamówień zwraca timeout dla 3% żądań w szczycie, i to dopiero od wdrożenia integracji płatności w zeszłym tygodniu. Opisujesz problem i dostajesz „dodaj ponawianie”. To zgadywanie, nie analiza. Potrzebujesz, żeby Claude przeanalizował pulę połączeń, nowe wywołanie zewnętrzne i timeout bramki. A potem potrzebujesz testu, który pokaże, które wyjaśnienie jest prawdziwe. Jeśli nie masz jeszcze skonfigurowanych plików ustawień, zacznij od konfiguracji.

Co zyskasz, dostrajając poziom effort

• Tabelę decyzyjną, która przypisuje rodzaj zadania do poziomu effort, oraz kolejność eskalacji przed zmianą modelu.
• Dokładne polecenia i ustawienia, które ustalają effort dla jednej tury, sesji, modelu, subagenta albo całej organizacji.
• Trzy prompty do skopiowania, które zamieniają dogłębne rozumowanie w falsyfikowalne hipotezy, testowalną decyzję architektoniczną i zmierzone porównanie dwóch poziomów effort.
• Procedurę weryfikacji, która sprawdza wynik testami i bramkami review, więc nie musisz audytować rozumowania linijka po linijce.
• Rozwiązania siedmiu sytuacji, w których ustawienia effort nie działają albo szkodzą, każde z krokiem naprawczym.

Wszystko poniżej sprawdziliśmy 2026-09-26 na zainstalowanym CLI, Claude Code 2.1.283 (claude --help), oraz w oficjalnej dokumentacji konfiguracji modelu, z wyjątkiem wierszy Sonnet 5.5 i Haiku 5.5, opisu ultracode (v2.1.284) oraz każdego fragmentu, który podaje nowszą wersję lub datę 2026-10-12. Te elementy sprawdziliśmy ponownie na Claude Code 2.1.296 i na stronach Anthropic 2026-10-12.

Jak effort steruje rozumowaniem Claude?

Effort to główna kontrolka tego, ile Claude myśli. Na modelach z adaptacyjnym rozumowaniem myślenie jest opcjonalne na każdym kroku. Na niskim poziomie Claude szybko odpowiada na rutynowe kroki. Na wysokim zużywa więcej tokenów na eksplorację, zanim zacznie działać. Anthropic kalibruje skalę osobno dla każdego modelu, więc high na jednym modelu to nie ta sama ilość myślenia co high na innym.

Każdy model startuje z własnym domyślnym poziomem:

Model w Claude Code	Poziomy effort	Domyślny effort	Czy można wyłączyć myślenie?
Claude Opus 5.5 (model domyślny)	od low do max	medium	Nie
Claude Fable 5.1, Claude Fable 5	od low do max	high	Nie
Claude Sonnet 5, Claude Opus 5, Claude Opus 4.8	od low do max	high	Tak
Claude Sonnet 5.5	od low do max	medium	Nie (API odrzuca disabled)
Claude Haiku 5.5	od low do max	medium	Tak (API przyjmuje disabled na high lub niżej)
Claude Opus 4.7	od low do max	xhigh	Tak
Claude Opus 4.6, Claude Sonnet 4.6	low, medium, high, max (bez xhigh)	high	Tak
Claude Haiku 4.5	brak parametru effort	—	Tak

Ważniejsze od samej tabeli są dwie konsekwencje:

• Opus 5.5 startuje o poziom niżej niż Opus 5. Według dokumentacji Claude Code w testach Anthropic Opus 5.5 na medium dorównuje Opusowi 5 na high lub go przewyższa w ewaluacjach programistycznych i z pracy opartej na wiedzy. Anthropic podaje też, że Opus 5.5 na domyślnym poziomie effort pokonuje Opusa 5 na max w Terminal-Bench 4.0 za mniej więcej jedną piątą kosztu (anthropic.com, 2026-09-22). Oba twierdzenia pochodzą od producenta. Nie przenoś starego poziomu z Opusa 5; zacznij od medium i podnoś go dopiero wtedy, gdy zadanie pokaże, że trzeba.
• Wersja Claude Code decyduje o modelu domyślnym. Opus 5.5 jest domyślny od v2.1.280, co 2026-10-17 oznacza oba kanały wydań (stable to v2.1.292, latest to v2.1.302). Starsza wersja niż v2.1.280 nadal pracuje na Opusie 5 albo Sonnecie 5 z poziomem high. Uruchom /status, żeby zobaczyć model, a /effort status albo nagłówek sesji, żeby zobaczyć poziom effort. Ceny modeli i rozmiary kontekstu znajdziesz w przeglądzie modeli.

Jeśli ustawisz poziom, którego model nie obsługuje, Claude Code zejdzie do najwyższego obsługiwanego poziomu, równego ustawionemu lub niższego. Na przykład xhigh działa jako high na Opusie 4.6 i Sonnecie 4.6.

Jaki poziom effort wybrać?

Wybieraj według tego, jak bardzo zadanie wymaga rozumowania o wielu ruchomych częściach, a nie według tego, jak ważne się wydaje.

Poziom	Do czego	Przykład
low	Krótkie, wąskie kroki wrażliwe na opóźnienie, wymagające niewielkiego osądu	Zmiana nazwy symbolu, poprawka błędu lintera, opis commita
medium	Codzienna praca nad funkcjami i przebiegi, w których liczy się koszt. Domyślny na Opusie 5.5	Nowy endpoint według istniejącego wzorca
high	Błędy bez jasnej reprodukcji, zmiany w wielu plikach z ukrytymi zależnościami	Sporadyczny timeout, który pojawił się po wdrożeniu
xhigh	Długa agentowa eksploracja i projektowanie obejmujące kilka systemów	Wybór między kolejką a synchronicznym wywołaniem płatności
max	Problemy, nad którymi ekspert siedziałby godzinami. Anthropic ostrzega, że na tym poziomie model bywa skłonny do nadmiernego analizowania, więc przetestuj go przed szerszym użyciem	Błąd współbieżności, który przetrwał dwie próby na xhigh
ultracode	Duże zadania, które chcesz podzielić na dynamiczny workflow. To ustawienie Claude Code, nie poziom modelu: dodaje orkiestrację workflow na bieżącym poziomie effort sesji (od v2.1.284)	Migracja 40 serwisów na nowe API logowania

Eskaluj w tej kolejności i zatrzymaj się na pierwszym kroku, który działa:

1. Popraw prompt. Dodaj objaw, ograniczenie i dowody. Niejasny prompt na max przegrywa z precyzyjnym na medium.
2. Podnieś effort o jeden poziom dla sesji albo dodaj ultrathink dla jednej tury.
3. Świadomie zmień model. Anthropic sam zaleca sięgnięcie po Claude Fable 5.1 (/model fable), gdy twoje ewaluacje na Opusie 5.5 z wyższym poziomem effort nadal nie wystarczają. Fable 5.1 nigdy nie jest modelem domyślnym i w zależności od planu może być rozliczany z kredytów użycia.

Uwaga

ultrathink to jedyne słowo kluczowe, które pogłębia rozumowanie na jedną turę. Dodaje ono instrukcję w kontekście na jedną turę i nie zmienia poziomu effort wysyłanego do API. Osobne słowo ultracode włącza orkiestrację workflow na bieżącym poziomie effort sesji (zobacz wiersz ultracode powyżej). Frazy w rodzaju „think hard” czy „think more” to zwykły tekst promptu (sprawdzone w Claude Code 2.1.283). Nie ma też poleceń /think ani /ultrathink (lista poleceń, sprawdzone 2026-09-26).

Ustaw effort dla tury, sesji lub modelu

Claude Code ustala effort w stałej kolejności. Wygrywa pierwsze źródło, które ma zastosowanie:

1. Wybór jawny: zmienna środowiskowa CLAUDE_CODE_EFFORT_LEVEL, flaga --effort albo /effort w sesji.
2. Twoje ustawienia: poziom zapisany dla modelu pod kluczem modelSettings albo klucz effortLevel.
3. Domyślny poziom modelu z tabeli powyżej.

Używaj tych poleceń, od najwęższego zakresu do najszerszego:

1. Sprawdź, co jest aktywne. W sesji uruchom:

   /effort status

   Nagłówek sesji też pokazuje poziom obok nazwy modelu, na przykład „with low effort”.

2. Pogłęb pojedynczą turę. Wstaw ultrathink w dowolnym miejscu promptu. Poziom sesji się nie zmienia.

3. Zmień poziom na tę sesję albo zapisz go dla tego modelu. Uruchom /effort bez argumentu, żeby otworzyć suwak. Enter zapisuje poziom jako domyślny dla aktywnego modelu, a s stosuje go tylko w tej sesji (od v2.1.257). Wpisanie poziomu, na przykład /effort high, też go zapisuje. /effort auto czyści zapisany poziom. max i ultracode wybrane przez /effort dotyczą tylko tej sesji. Żeby zachować max, ustaw CLAUDE_CODE_EFFORT_LEVEL=max; żeby zachować ultracode, ustaw "ultracode": true w ustawieniach.

4. Uruchom sesję od razu na danym poziomie. W terminalu:

   claude --effort xhigh

   claude --effort ultracode startuje na xhigh z włączonym ultracode, podobnie jak wartość effortLevel: "ultracode" w Agent SDK. Późniejsze włączenie lub wyłączenie ultracode przez /effort albo ustawienie ultracode nie zmienia poziomu.

5. Przypnij poziom dla całej powłoki albo zadania CI. Zmienna środowiskowa ma pierwszeństwo przed każdym innym źródłem, także przed /effort:

   export CLAUDE_CODE_EFFORT_LEVEL=high

   Przyjmuje wartości od low do max, auto albo unset (obie oddają wybór pozostałym źródłom), ale nie ultracode.

6. Przypnij poziom subagentowi albo skillowi. Dodaj effort do frontmattera pliku w .claude/agents/ albo do SKILL.md skilla. Recenzent tylko do odczytu, który musi myśleć dogłębnie, może działać na high, podczas gdy główna sesja zostaje na medium:

   ---
   name: concurrency-reviewer
   description: Reviews diffs that touch locks, pools, queues, or async code for race conditions.
   tools: Read, Grep, Glob
   effort: high
   ---

   Frontmatter nadpisuje poziom sesji, ale nie zmienną środowiskową. Od v2.1.292 (oba kanały wydań na 2026-10-17) Claude może też przekazać parametr effort narzędzia Agent, gdy poprosisz o subagenta na konkretnym poziomie; dla tego wywołania nadpisuje on frontmatter, a zmienna środowiskowa nadal wygrywa. Pełny format opisuje strona o własnych subagentach.

Ustaw domyślne poziomy i limity effort dla zespołu

Tech lead ma do dyspozycji dwa klucze ustawień, oba opisane w dokumentacji ustawień:

• effortLevel ustala poziom domyślny dla modeli bez zapisanego poziomu. Przyjmuje low, medium, high albo xhigh, nigdy max. W ustawieniach projektu, lokalnych albo zarządzanych dotyczy każdego modelu. We własnym ~/.claude/settings.json użytkownika nie działa już dla Opusa 5.5 i nowszych modeli, bo /effort zapisuje teraz poziomy osobno dla każdego modelu.
• maxEffortLevel ogranicza effort. Każde wyższe żądanie działa na poziomie limitu, niezależnie od źródła. Wdróż go w ustawieniach zarządzanych, żeby wymusić go w całej organizacji. Od v2.1.284 limit nie wyłącza już ultracode: ustawienie zostaje włączone na poziomie limitu.

{
  "maxEffortLevel": "xhigh"
}

Ten limit trzyma max, który dokumentacja Anthropic opisuje jako skłonny do nadmiernego analizowania, z dala od rutynowej pracy, a ultracode zostawia dostępny. Połącz go z mechanizmami opisanymi w kontroli kosztów.

Zobacz, jak Claude rozumował i ile to kosztuje

Claude Code domyślnie zwija myślenie. Naciśnij Ctrl+O, żeby rozwinąć transkrypt i zobaczyć rozumowanie jako szary tekst kursywą. Sesje interaktywne na Anthropic API dostają zredagowane bloki myślenia, chyba że ustawisz "showThinkingSummaries": true. Redakcja zmienia tylko to, co widzisz: każdy wygenerowany token myślenia liczy się do kosztu lub limitu planu, pokazany czy nie. Wydatki sesji sprawdzisz przez /usage.

Traktuj widoczne rozumowanie jako pomoc przy debugowaniu, a nie jako dowód. Czytaj je, gdy odpowiedź cię zaskakuje i chcesz wiedzieć, które założenie do niej doprowadziło. Nie czytaj go, żeby rozstrzygnąć, czy odpowiedź jest poprawna; rozstrzygają to testy z sekcji o weryfikacji poniżej.

Stare kontrolki myślenia, które nie dotyczą już modelu domyślnego

Starsze poradniki, w tym wcześniejsze wersje tej strony, każą przełączać myślenie. Te kontrolki nadal istnieją, ale na Opusie 5.5 i modelach Fable myślenia nie da się wyłączyć, więc nic tam nie zmieniają:

• Option+T (macOS) albo Alt+T (Windows i Linux) przełącza myślenie w sesji.
• /config ustala globalne ustawienie domyślne myślenia (włączone/wyłączone), zapisywane jako alwaysThinkingEnabled w ~/.claude/settings.json.
• MAX_THINKING_TOKENS=0 wyłącza myślenie na Anthropic API, z wyjątkiem Opusa 5.5 i Fable.
• Fable, Sonnet 5 oraz Opus 4.7 i nowsze zawsze używają rozumowania adaptacyjnego, więc dodatnie wartości MAX_THINKING_TOKENS nic tam nie zmieniają. Opus 4.6 i Sonnet 4.6 mogą wrócić do stałego budżetu po ustawieniu CLAUDE_CODE_DISABLE_ADAPTIVE_THINKING=1; Haiku 4.5 nie ma parametru effort i zachowuje ręczny budżet myślenia.

Na modelu domyślnym effort jest jedyną dźwignią. Żeby ograniczyć myślenie, obniż effort.

Prompty, dzięki którym dogłębne rozumowanie się opłaca

Effort kupuje więcej myślenia. Prompt decyduje, czy to myślenie kończy się czymś, co da się sprawdzić. Każdy prompt poniżej żąda wyniku falsyfikowalnego: hipotez z testami, decyzji z kryteriami akceptacji albo zmierzonego porównania. Prompty zostawiamy po angielsku, bo w tej formie trafiają do agenta.

Prompt do skopiowania: od sporadycznego błędu do falsyfikowalnych hipotez

ultrathink. /api/orders returns 504 for about 3% of requests between 14:00 and 16:00 UTC,
starting after the payment integration was deployed last Tuesday. Database query time stays
under 50 ms and memory is flat. Read @src/pages/api/orders.ts and @src/lib/payments.ts.

Do not change application code yet. List at most four hypotheses, ranked by likelihood. For each one give:
1. the mechanism, citing file and line;
2. a test or measurement that would fail if the hypothesis is true and pass if it is false;
3. the evidence that would rule it out.
Then write the test for the top hypothesis only, run it, and report whether it fails.

Prompt do skopiowania: decyzja architektoniczna z kryteriami akceptacji

We must decide how /api/orders confirms payment: (A) keep the synchronous call to the payment
provider with a 2-second timeout and a circuit breaker, or (B) accept the order as "pending"
and confirm payment in a queue consumer. Constraints: p99 latency for
/api/orders must stay under 800 ms, clients already poll order status, and the v1 API
response shape cannot change.

Explore the codebase first, then write docs/adr/0007-payment-confirmation.md with: context,
both options, failure modes of each (provider outage, duplicate webhook, retry storm), the
recommendation, and five acceptance criteria phrased as tests we can automate. Mark every
assumption you could not confirm from the code as UNVERIFIED.

Skalibruj effort na własnym zadaniu

Tabela powyżej to punkt wyjścia. Uruchomienie tego samego zadania na dwóch poziomach we własnym kodzie powie ci więcej niż jakakolwiek ogólna reguła. W terminalu, z katalogu głównego repozytorium, daj obu przebiegom zadanie, które ma test do zaliczenia. Najpierw zatwierdź albo odłóż (git stash) swoje zmiany: git worktree add ... HEAD pobiera ostatni commit, więc niezatwierdzona praca nie trafiłaby pod test. Nowy worktree nie ma też node_modules, dlatego przed przebiegami zainstaluj zależności w każdym z nich:

git worktree add ../effort-medium HEAD
git worktree add ../effort-high HEAD
(cd ../effort-medium && npm ci)
(cd ../effort-high && npm ci)
TASK="Make tests/orders/timeout.test.ts pass without editing that test file."
(cd ../effort-medium && claude -p "$TASK" --effort medium --permission-mode acceptEdits --allowedTools "Bash(npm test *)")
(cd ../effort-high && claude -p "$TASK" --effort high --permission-mode acceptEdits --allowedTools "Bash(npm test *)")

--permission-mode acceptEdits pozwala każdemu przebiegowi w trybie nieinteraktywnym (-p) edytować pliki, a --allowedTools pozwala mu uruchamiać wyłącznie twoje polecenie testowe. Prompt umieść przed --allowedTools: flaga przyjmuje kilka wartości i połknęłaby prompt jako drugą regułę narzędzia, a przebieg zakończyłby się błędem „Input must be provided” (sprawdzone w 2.1.283). Potem porównaj oba wyniki w zwykłej sesji:

Prompt do skopiowania: porównanie dwóch przebiegów effort

Compare the worktrees ../effort-medium and ../effort-high. In each one, run npm test and
npx tsc --noEmit, and collect git diff --stat against HEAD. Check that
tests/orders/timeout.test.ts is unchanged in both. Give me a table with: tests passed, tests
failed, type errors, files changed, lines changed, and whether the test file was modified.
Then tell me which run I should keep and why, in three sentences. Do not merge or delete anything.

Powtórz to na trzech do pięciu reprezentatywnych zadaniach, zanim zmienisz domyślny poziom zespołu, i porównaj zysk z dodatkowym zużyciem, które pokazuje /usage.

Planuj na wysokim poziomie effort, buduj na domyślnym

Tryb planowania i effort dobrze się łączą, bo plan to miejsce, w którym dodatkowe rozumowanie kosztuje najmniej. Błędny plan kosztuje jedną odpowiedź; błędna implementacja kosztuje revert.

1. Wejdź w tryb planowania przez /plan albo przełącz się do niego skrótem Shift+Tab.
2. Podnieś effort na czas planowania: uruchom /effort, przesuń suwak na xhigh i naciśnij s, żeby zmiana dotyczyła tylko tej sesji.
3. Opisz zmianę i poproś o plan z listą plików do zmiany, testów do dodania i kryteriów akceptacji.
4. Porównaj plan ze swoimi kryteriami akceptacji i odrzuć wszystko, czego nie da się przetestować.
5. Zanim go zatwierdzisz, wróć do swojego zwykłego poziomu: uruchom /effort, przesuń suwak z powrotem i naciśnij s (albo użyj /effort auto, jeśli nigdy nie zapisałeś poziomu dla tego modelu). Potem pozwól Claude go zaimplementować.

Zmiana poziomu effort w środku rozmowy może unieważnić cache promptu i Claude Code może cię przed tym ostrzec. Zmieniaj poziom na granicy tur, a nie w tę i z powrotem. Alias modelu opusplan automatyzuje podobny podział między modelami: Opus w trybie planowania, Sonnet przy wykonaniu. Więcej o planowaniu przeczytasz na stronach o planowaniu funkcji i decyzjach architektonicznych.

Jak zweryfikować wynik dogłębnego rozumowania bez czytania całości?

Dłuższy łańcuch myśli brzmi bardziej przekonująco, ale nie jest przez to bardziej prawdziwy. Oceniaj wynik po tym, co pozwala sprawdzić.

Wynik	Bramka, która go dowodzi	Kto zatwierdza
Diagnoza błędu	Test reprodukujący, który nie przechodzi na obecnym kodzie i przechodzi po poprawce, commitowany razem z poprawką	Programista
Poprawka	Pełny zestaw testów, sprawdzanie typów i lint w CI; /code-review na diffie	Programista, potem recenzent PR
Decyzja architektoniczna	ADR, którego kryteria akceptacji są zapisane jako testy automatyczne; każde założenie UNVERIFIED rozstrzygnięte albo zaakceptowane przez wskazaną osobę	Tech lead
Domyślny poziom effort dla zespołu	Porównanie kalibracyjne powtórzone na trzech do pięciu reprezentatywnych zadaniach	Tech lead

Dwie zasady pilnują uczciwości. Po pierwsze, nigdy nie pozwalaj agentowi edytować testu, który dowodzi jego własnej poprawki; zobacz ochronę wyroczni testowej. Po drugie, gdy diagnoza wskazuje mechanizm, którego nie da się przetestować, traktuj ją jako hipotezę, a nie ustalenie. Pełną pętlę debugowania opisuje strona o debugowaniu z Claude Code.

Gdy ustawienia effort nie działają tak, jak oczekujesz

Wyższy effort daje tę samą błędną odpowiedź. Brakuje kontekstu, nie rozumowania. Dodaj fragment logu, nieudane żądanie albo plik odpowiedzialny za zachowanie, a jeśli dane są poza repozytorium, podłącz ich źródło przez MCP. Potem ponów próbę na tym samym poziomie.

/effort niczego nie zmienia. Ustawione jest coś o wyższym priorytecie. Uruchom w terminalu echo $CLAUDE_CODE_EFFORT_LEVEL; zmienna środowiskowa wygrywa z /effort. Potem sprawdź, czy w ustawieniach zarządzanych nie ma limitu maxEffortLevel, i pamiętaj, że xhigh spada do high na Opusie 4.6 i Sonnecie 4.6. /effort status pokazuje faktycznie zastosowany poziom.

Zapisany effortLevel jest ignorowany po przejściu na Opusa 5.5. Klucz effortLevel na najwyższym poziomie ustawień użytkownika nie dotyczy już Opusa 5.5. Uruchom raz /effort high w sesji na Opusie 5.5 i naciśnij Enter; Claude Code zapisze poziom dla tego modelu pod modelSettings.

Przełącznik myślenia nic nie robi. Pracujesz na Opusie 5.5 albo modelu Fable, gdzie myślenie jest zawsze włączone. Żeby ograniczyć myślenie, obniż effort.

ultracode nie chce się włączyć. Wymaga modelu obsługującego xhigh i włączonych workflow. Limit effort ani CLAUDE_CODE_EFFORT_LEVEL jej nie blokują: od v2.1.284 ultracode zostaje włączony na poziomie, który ustawiają.

Limit użycia kończy się w połowie tygodnia. Poziom max albo xhigh został włączony przy rutynowej pracy. Wróć do domyślnego poziomu modelu przez /effort auto, wyższe poziomy zostaw dla konkretnych zadań i poproś tech leada o limit maxEffortLevel. /usage pokazuje, gdzie poszły tokeny.

Claude krąży wokół niejednoznacznego problemu na max. Dokumentacja Anthropic ostrzega, że na max model potrafi przesadnie długo analizować. Zawęź pytanie („tylko cykl życia puli połączeń, nie cała ścieżka żądania”), zejdź na xhigh i poproś o jedną najbardziej prawdopodobną hipotezę razem z jej testem.

Dokąd dalej z dogłębnym rozumowaniem

W innych narzędziach: Codex ma własne poziomy reasoning effort (zobacz konfigurację Codex), a Cursor dobiera rozumowanie przez wybór modelu (zobacz wybór modelu w Cursorze).

Konfiguracja MCP Daj Claude dostęp do logów, bazy danych i trackera zadań, żeby rozumowanie miało na czym się oprzeć

Odzyskiwanie po błędach Rewind, checkpointy i ratowanie sesji, która poszła źle

Debugowanie z Claude Code Pełna pętla od hipotezy do testu regresji

Przegląd modeli Aktualne modele, ceny i okna kontekstu w jednym miejscu