Claude Opus 4.7 — pierwsze wrażenia po tygodniu z 1M context

Anthropic wypuścił Claude Opus 4.7 z 1M context window. Używam go od tygodnia jako default w Claude Code, na tej samej maszynie co wcześniej Sonnet 4.6. Ten post to konkretne obserwacje, co realnie się zmieniło, gdzie warto przepłacić, a gdzie zostaję przy tańszym modelu.

Założenie: piszę z perspektywy codziennego użytkownika Claude Code w terminalu, nie z benchmarków. Mam też swój home-labowy setup (cztery maszyny, agent na mini PC, opisałem to wcześniej), więc obciążam go nietrywialnie.

Co dostajesz w 4.7

Trzy rzeczy które realnie zmieniają sposób pracy:

Reszta to inkrementalne usprawnienia w tool use i instrukcji follow-through. Niewielkie, ale zauważalne na dużych zadaniach.

1M kontekstu — kiedy ma znaczenie

Najbardziej praktyczna zmiana. Trzy realne sytuacje z tygodnia:

Refactor średniego repo. Wrzucam 60 plików (~150k tokenów) i pytam o spójność wzorca. Wcześniej musiałem dzielić kontekst albo używać sub-agentów. Teraz model trzyma wszystko, łączy fakty z różnych końców kodu.

Code review całego PR z dyskusją. PR + cały feedback z review + linkowane fragmenty z innych branchy. 4.6 by się zatkał na samej historii, 4.7 to przelatuje.

Długie sesje debugowania. Nie muszę kompaktować rozmowy gdy lecę 4 godziny z jednym problemem. To największa cicha zmiana, produktywność rośnie nie przez "lepsze odpowiedzi", tylko przez brak utraty kontekstu.

Ale uwaga na cache:

✅ < 200k tokenów → cache trafiony, koszt jak na Sonnet
⚠️ > 200k tokenów → cache miss, każdy turn drogi

Jeśli sesja przekracza 200k, każdy mój prompt re-czyta cały kontekst od zera. Praktyczna konsekwencja: na dużych zadaniach planuje od razu kontekst, nie dorzucam plików dynamicznie.

Plan mode — przestałem ignorować

W 4.6 plan mode był "ok, czasami warto". W 4.7 jest oddzielny tryb z osobnymi regułami: nie może edytować plików (poza plikiem planu), wymusza ExitPlanMode na końcu, nie może uruchamiać destruktywnych komend.

Workflow który mi się sprawdza:

# 1. Otwierając zadanie nietrywialne — startuję w plan mode
# 2. Model rozprasza explore agenty równolegle, zbiera mapę
# 3. Pisze plan z konkretnymi ścieżkami plików i listą zmian
# 4. Pyta tylko o realnie ważne rozwidlenia
# 5. Po akceptacji wychodzi z plan mode i wykonuje

Co się zyskuje: przestaję dostawać "po cichu rozszerzony" scope. Plan jest spisany, jak coś się rozjedzie, wiem gdzie. Co tracisz: ~5 minut na każde zadanie. Na fix typo to overkill, na refaktor sieciowy, zawsze.

Fast mode toggle

Komenda /fast przełącza Claude Code na Opus 4.6 ze przyspieszonym outputem. Nie jest to downgrade do mniejszego modelu, to ten sam Opus 4.6 z innym sampling profilem. Używam tego do trzech rzeczy:

• Kwerendy do dokumentacji ("co to jest X w mojej wewnętrznej bibliotece"), odpowiedź szybko, koszt niski
• Generowanie boilerplate (testy jednostkowe, schematy walidacyjne)
• Czat o architekturze zanim siądę do kodu

Nie używam fast mode do: code review, debugowania, refaktorów. Tam wolniejszy reasoning kosztuje, ale gubi się mniej.

Koszt: jak myślę o budżecie

Opus 4.7 jest droższy niż Sonnet 4.6. Na pierwszy rzut oka. W praktyce:

Zadanie 10 minut na Sonnet 4.6: ~$0.40
To samo zadanie na Opus 4.7: ~$0.85 (bez cache)
                          → ~$0.45 (z prompt caching aktywnym)

Prompt caching to kluczowa optymalizacja. Cache TTL to 5 minut, jeśli odpowiadam w tym oknie, koszt prompta spada o 90%. W praktyce: nie myśl o tokenach, myśl o kadencji.

Reguła którą stosuję:

• Krótkie sesje (< 30 min, < 200k tokenów) → Opus 4.7 default
• Długie idle pauzy (idę na obiad) → przed pauzą zapisuję stan, po pauzie nowa sesja
• Batch processing tysięcy podobnych zapytań → Sonnet 4.6 wciąż wygrywa

Czego 4.7 nie naprawił

Trzy rzeczy które dalej drażnią:

1. Tool calling w długich łańcuchach. Po ~30 narzędziach z rzędu jakość spadała w 4.6. W 4.7 też spada, tylko od ~50. Kompaktowanie konwersacji przed dalszą pracą wciąż się przydaje.

2. Brak prawdziwej pamięci między sesjami. Każda nowa sesja zaczyna od zera. Memory system w Claude Code (lokalne pliki) to obejście, nie rozwiązanie. Czekam aż Anthropic da to natywnie.

3. Halucynacje w obszarach niszowych. Pytasz o nową bibliotekę z ostatnich kilku miesięcy, model konfabulu. Knowledge cutoff to wciąż fakt, ratuje grep w docsach przez WebFetch.

Konkretny przykład: refaktor który robiłem dzisiaj

Dual-locale dla bloga (PL + EN) na tej stronie. Workflow który zadziałał:

# 1. Plan mode — agent odpalił 2 explore'y równolegle (blog + automation)
# 2. Wynik: dokładna mapa plików, wybór wzorca i18n bez next-intl
# 3. Drugi agent (Plan subagent) zaprojektował route'y i loader
# 4. Pytania: dwa rozwidlenia (mechanizm postowania, język)
# 5. ExitPlanMode → 30 minut implementacji

Bez 1M kontekstu agent musiałby wczytywać pliki na bieżąco. Z 1M trzymał całe lib/blog/ + 4 istniejące posty + komponenty + sitemap w głowie naraz. Plan był po prostu spójny.

Werdykt

Opus 4.7 jest moim domyślnym wyborem od tygodnia i nie wracam. Nie dlatego że jest "magicznie mądrzejszy", różnica w jakości pojedynczej odpowiedzi jest mała. Wygrywa konsekwencja przez długie zadania: nie gubi kontekstu, plan mode realnie chroni przed scope creepem, fast toggle daje wybór gdy nie potrzebuję pełnego reasoningu.

Kiedy NIE Opus 4.7:

• Skrypty batch processing (token-cost dominuje)
• Trywialne edycje (przeczyść formatowanie, dopisz komentarz)
• Środowiska z hard cap budżetu (np. zlecone API calls bez cache)

Wszystko inne, Opus 4.7 wygrywa o włos, ale wygrywa.

Jeśli budujesz coś z Claude Code i chcesz pogadać o kompromisach modelowych, napisz. W poprzednim poście o skill'ach opisywałem które custom workflow przeniosłem na 4.7, większość bez zmian, kilka uprościłem korzystając z 1M kontekstu.