Jak pracować z Opusem 4.7 w Claude Code, żeby nie przepłacać za myślenie

👁 129 przeczytań

Nowy model ma inny poziom wysiłku domyślnie, inny silnik myślenia, inny tokenizer i kilka subtelnych zmian zachowania, które potrafią zepsuć stare prompty. Poradnik dla osób, które chcą szybko wejść w tryb, w którym to narzędzie zaczyna zwracać się za swoje pieniądze.

Między Opusem 4.6 a 4.7 jest różnica, której trudno dopatrzyć się po pierwszej komendzie. Uruchamiasz Claude Code, wklejasz ten sam prompt, co wczoraj - i dostajesz coś nieco innego. Krótszą odpowiedź. Mniej wywołań narzędzi. Dziwniejsze decyzje. To nie jest bug. To jest nowy model, zaprojektowany inaczej, na który trzeba przestawić własne nawyki - nie tylko konfigurację.

Anthropic opublikował wraz z premierą osobny poradnik o tym, jak pracować z Opusem 4.7 w Claude Code. Część rzeczy brzmi banalnie. Część nie. Poniżej - materiał przepuszczony przez praktyczne sito, z kilkoma uwagami z polskiego rynku, gdzie sporo osób buduje własne konfiguracje pod code review, automatyzacje i długie uruchomienia agentowe.

Google · Twoje źródłaDodaj promptowy.com do preferowanych źródeł w Google→

Traktuj go jak inżyniera, któremu coś zlecasz

To jest pierwsza i najważniejsza zmiana mentalna. Opus 4.7 jest zoptymalizowany pod długie, jednoturowe zadania. Kiedy rozmawiasz z nim tak, jak z pair programmerem - tura po turze, „a teraz dodaj to, a teraz tamto” - model myśli po każdej twojej wypowiedzi, ponosisz narzut, a rachunek rośnie. Kiedy opiszesz zadanie porządnie w pierwszej turze i puścisz go do pracy, w praktyce dostajesz więcej za mniej tokenów.

Zbuduj endpoint POST /api/orders, który przyjmuje JSON
ze strukturą Order z pliku schemas/order.ts.
Użyj istniejącego OrderService w services/orders.ts.

Kryteria akceptacji:
- walidacja Zod
- response 201 z utworzonym zasobem
- obsługa błędów 4xx z kodami domenowymi
- testy w __tests__/orders.spec.ts,
  pokrycie happy path + ścieżki błędnej walidacji
- respektuj konwencje istniejących endpointów

Nie pytaj o potwierdzenia, leć do końca.

Tak pisze się prompt dla Opusa 4.7. Intencja, ograniczenia, kryteria akceptacji, lokalizacje plików. Nie dlatego, że model nie poradzi sobie z czymś krótszym - poradzi. Tylko dlatego, że każdy cykl komunikacji (round-trip) z użytkownikiem to dodatkowe myślenie i dodatkowe tokeny. Im mniej ich potrzebujesz, tym taniej kończysz zadanie.

Auto mode to coś, z czym warto się zaprzyjaźnić

Wraz z premierą tryb auto mode rozszerzono na użytkowników planu Max. Włącza się go skrótem Shift+Tab. Model podejmuje decyzje o wywoływaniu narzędzi bez pytania o zgodę na każdy krok. Brzmi ryzykownie - i jest, jeśli zadanie polega na operowaniu na krytycznych plikach bez kopii zapasowej. Ale dla długich zadań, w których dałeś modelowi pełny kontekst na starcie i chcesz wrócić po czterdziestu minutach, różnica w czasie cyklu jest wyraźna.

Praktyczna zasada: auto mode ma sens dla zadań typu „rozgryzienie obszernego buga w logach”, „refaktor w izolowanym module”, „generowanie testów do istniejącego kodu”. Nie ma sensu dla zadań, w których model ma sięgać do baz produkcyjnych, kasować pliki albo dotykać konfiguracji wdrożeniowych.

Tip. Poproś Claude’a, żeby odtworzył dźwięk po ukończeniu zadania - sam zbuduje sobie powiadomienie oparte na hookach Claude Code. To banał, który drastycznie zmienia komfort pracy przy długich procesach. Przestajesz ciągle patrzeć w ekran.

Poziomy wysiłku - który wybrać

Poziom domyślny w Claude Code to teraz xhigh. Jeśli nigdy ręcznie nie grzebałeś w tym ustawieniu, zostaniesz na nie automatycznie przeniesiony. Jeśli grzebałeś, czas je zrewidować. Nowe poziomy wyglądają tak:

Krzywa malejących korzyści (diminishing returns) jest tu widoczna bardzo wyraźnie. Między high a xhigh jakość rośnie jeszcze sensownie, między xhigh a max - praktycznie stoi, a zużycie tokenów rośnie ponad dwukrotnie.

low / medium

Dla pracy wrażliwej na koszt lub opóźnienia (latencję) - drobne poprawki, banalne zapytania, małe skrypty. Mniej zdolny niż wyższe poziomy, ale wciąż lepszy niż Opus 4.6 na tym samym poziomie wysiłku. Dobry do zadań, które wcześniej wysyłałeś do Sonneta.

high

Balans inteligencji i kosztu. Wybór dla osób, które uruchamiają wiele sesji równolegle i nie chcą przepalać budżetu. Jakość spada nieznacznie wobec xhigh, ale oszczędność tokenów jest znacząca.

xhigh (domyślne i rekomendowane)

Ma autonomię i inteligencję bez patologicznego palenia tokenów, które potrafi się zdarzyć na poziomie max. Zostawiaj tutaj, chyba że masz konkretny powód, żeby to zmienić.

max

Ostatni procent wydajności przy naprawdę trudnych problemach. Malejące korzyści i tendencja do nadmiernego myślenia. Używaj świadomie - głównie do ewaluacji i zadań, w których liczy się dosłownie każdy punkt jakości, a budżet nie jest kluczowym czynnikiem.

Adaptive thinking - zapomnij o sztywnym budżecie

Opcja Extended Thinking ze sztywnym budżetem tokenów nie istnieje już w Opusie 4.7. Zastąpiło ją adaptive thinking - model sam decyduje, kiedy pomyśleć i jak długo. Proste pytanie → szybka odpowiedź bez rozmyślań. Trudny problem → realna analiza. W praktyce to ogromne ułatwienie dla osób, które nie chcą ręcznie zarządzać budżetami myślenia na każdym kroku.

Co jeśli chcesz więcej albo mniej myślenia? Piszesz wprost:

Pomyśl uważnie i krok po kroku, zanim odpowiesz.
Ten problem jest trudniejszy, niż wygląda.

Priorytetyzuj szybką odpowiedź zamiast głębokiego myślenia.
W razie wątpliwości odpowiadaj bezpośrednio.

Pierwszy prompt wymusza myślenie, drugi je ogranicza. Oszczędzisz tokeny, ale możesz stracić trochę dokładności przy trudniejszych krokach. To świadomy kompromis, a nie defekt.

Cztery rzeczy, które się zmieniły i mogą złamać twoje promptowe rusztowania

1. Odpowiedzi są domyślnie krótsze

Opus 4.6 bywał rozgadany - domyślnie produkował dużo tekstu, nawet na proste pytania. Opus 4.7 kalibruje długość do złożoności zadania. Proste wyszukiwania (lookupy) dostają krótkie odpowiedzi, analizy otwarte dostają długie. Jeśli twój workflow polega na tym, że model zwraca pełne sekcje komentarzy do każdej funkcji, a nagle dostajesz skróty - napisz to wprost w prompcie. Podawaj przykłady tego, co chcesz widzieć, zamiast list instrukcji typu „nie rób X”.

2. Mniej wywołań narzędzi, więcej myślenia

Nowy model rzadziej sięga po narzędzia, częściej rozumuje z tego, co już ma w kontekście. To zazwyczaj lepsze rozwiązanie - szczególnie gdy ma bogaty kontekst. Ale jeśli twój agent opiera się na agresywnym przeszukiwaniu plików albo ściąganiu logów, musisz to wymusić. Jasny opis, kiedy i dlaczego używać danego narzędzia, załatwia sprawę.

3. Mniej subagentów z automatu

Opus 4.7 jest oszczędniejszy w powoływaniu subagentów. Jeśli twój use case korzysta z równoległych podzleceń - fan-out po plikach, niezależne pozycje do przetworzenia równolegle - napisz to wprost:

Nie powołuj subagenta do pracy, którą możesz wykonać
bezpośrednio w jednej odpowiedzi. Uruchamiaj wielu
subagentów w jednej turze przy fan-out po plikach
albo niezależnych pozycjach.

4. Tokenizer się zmienił, myślenie nasila się w długich sesjach

Input potrafi przełożyć się na 1,0 do 1,35 raza więcej tokenów niż w wersji 4.6. Długie sesje agentowe palą więcej outputu, bo model myśli intensywniej w późniejszych turach. Efekt netto - według testów Anthropic - jest z reguły korzystny, bo zadania kończą się szybciej i czyściej. Ale to trzeba zmierzyć na własnym ruchu. Przez pierwsze dni po migracji uważnie obserwuj rachunki.

Uwaga przy migracji. Jeśli masz prompty, które działały na Opusie 4.6 i na których cyzelowanie spędziłeś dużo czasu - nie przenoś ich jeden do jednego. Eksperymentuj z poziomem wysiłku. Zacznij od xhigh dla głównego workflow, zejdź na high przy zadaniach masowych, nie ruszaj max bez wyraźnego powodu.

/ultrareview - rzecz warta osobnej sesji

To nowa komenda w Claude Code. Uruchamia dedykowaną sesję code review - model czyta zmiany w kodzie i flaguje błędy oraz problemy projektowe, które wyłapałby staranny programista. Użytkownicy planów Pro i Max dostają trzy darmowe sesje ultrareview na start. To rodzaj funkcji, która ma sens w konkretnych momentach - przed dużym PR-em, po refaktorze ruszającym pół aplikacji, przy zmianach w krytycznym kodzie.

To nie zastępuje ludzkiego reviewera. Robi jednak rzecz, której ludzie regularnie nie robią - czyta wszystko, konsekwentnie, i nigdy nie ma gorszego dnia.

Lista kontrolna migracji

• Zrewiduj stare prompty - nowy model czyta literalnie, stare „nie rób X” mogą produkować nieoczekiwane wyniki.
• Zostaw domyślne xhigh albo ustaw je świadomie - to najlepszy punkt startowy dla większości zadań.
• Jeśli używałeś Extended Thinking z budżetem - zaplanuj migrację na adaptive thinking.
• Dodawaj prompty „pomyśl uważniej” lub „odpowiadaj szybko” tam, gdzie trzeba celowo wpłynąć na tryb myślenia.
• Mierz zużycie tokenów przez pierwsze 3-5 dni - tokenizer się zmienił, koszty mogą wyglądać inaczej.
• Jeśli potrzebujesz subagentów albo agresywnych wywołań narzędzi - napisz to wprost.
• Podawaj przykłady pożądanej formy wyjścia, zamiast listy zakazów.
• Strukturyzuj zadania w pierwszej turze: intencja, ograniczenia, kryteria akceptacji, lokalizacje plików.
• Używaj auto mode przy dłuższych, niekrytycznych uruchomieniach - oszczędzi to Twoje cykle.

Jedna obserwacja na koniec

Modele językowe dojrzewają w dziwny sposób. Wczesne wersje zachęcały do mikrozarządzania - człowiek pisał prompt, model dorzucał akapit, człowiek poprawiał, model poprawiał. To była rozmowa. Opus 4.7 idzie w drugą stronę: prosi, żeby go traktować jak kolegę z pracy, któremu rzucasz zadanie i zostawiasz w spokoju na dwie godziny. Ta zmiana w sposobie pracy jest prawdopodobnie ważniejsza niż cokolwiek z tabelki benchmarków.

Jeśli dopiero zaczynasz z Claude Code, Opus 4.7 to doskonały moment na wejście. Ustawienia domyślne są rozsądne, adaptive thinking zdejmuje z głowy zarządzanie budżetem myślenia, a auto mode na planie Max pozwala od razu poczuć, co znaczy „delegować” zamiast „nadzorować”. Jeśli jesteś weteranem - podejdź do migracji jak do refaktoru. Nowy model jest świetny, ale jest świetny inaczej - i zestrojenie własnych nawyków chwilę potrwa.