Prompt caching — jak liczę koszty Opus 4.7 (i czemu rachunek nie jest taki straszny)

Opus 4.7 ma wyższą cenę per-token niż Sonnet 4.6. Patrząc na cennik, dwa razy więcej. Patrząc na rachunek po miesiącu, różnica jest mała. Sekret to prompt caching, mechanizm który zmienia ekonomikę długich sesji.

Jak działa cache

Anthropic API od dłuższego czasu wspiera prompt caching. W Claude Code jest włączony domyślnie. Cache TTL = 5 minut.

Gdy wysyłasz prompt:

System sprawdza czy initial część kontekstu (system prompt + tools + conversation history) była już ostatnio użyta
Jeśli tak (cache hit) → płacisz 10% standardowej ceny za zacache'owane tokeny
Jeśli nie (cache miss) → płacisz 125% (cache write cost)

Czyli pierwsza wiadomość po przerwie jest droższa, każda kolejna w 5-minutowym oknie, tania.

Konkretny rachunek

Przykład sesji 30-minutowej z 8 turnami:

Turn	Czas od poprzedniego	Cache state	Koszt prompta
1	start	miss	125% (write)
2	30s	hit	10%
3	1min	hit	10%
4	2min	hit	10%
5	6min	miss (TTL)	125% (write)
6	1min	hit	10%
7	2min	hit	10%
8	1min	hit	10%

2 cache writes (drogo) + 6 cache hits (tanio). Średni koszt prompta to ~30% standardowej ceny. Realne dane z mojego billingu: typowa sesja 30-minutowa to $0.40-0.60 zamiast spodziewanych $1.50-2.00.

Co psuje cache

Trzy najczęstsze przyczyny niespodziewanych kosztów:

1. Idle pause > 5 min. Agent czeka, ja jadę po kawę, wracam, cache wymarły. Cold start = full cost.

2. Edycja system prompta. Zmiana CLAUDE.md w trakcie sesji albo /model flip → cały cache zwalony.

3. Long context > 200k. Powyżej 200k tokenów cache działa inaczej (sliding window) i niektóre wzorce kadencji nie chwytają. Praktyczna konsekwencja: na dużych zadaniach planuję od razu kontekst.

Strategia trzymania cache'a

Co robię żeby cache działał na moją korzyść:

1. Decoupluj idle work. Jeśli wiem że muszę odejść na 10 minut, kończę sesję, zaczynam nową po powrocie. Nie zostawiam Claude'a "oczekującego". Ten cold start jednorazowo kosztuje, ale dalej już cheap.

2. Batchuj decyzje. Zamiast 5 promptów po 1 minucie z przerwami, formułuję 1 dłuższy prompt z 5 pytaniami. Mniej promptów = mniej cache writes.

3. Pomijam żabki. Małe potwierdzenia ("ok", "tak", "dalej") robią cache hit. Nie kostują dużo, ale i nie odsuwają TTL, TTL liczy się od ostatniego cache write, nie od ostatniego promptu.

4. Plan mode na duże zadania. Plan mode robi cały kontekst w jednej fazie. Po jego ukończeniu mam świeży cache na fazę implementacji.

Pomiar w praktyce

Anthropic console pokazuje per-call koszt. Sprawdzam co tydzień:

Sesje > 10 min: średni koszt $0.45/sesja
Sesje 5-10 min: średni koszt $0.30/sesja
Sesje < 5 min: średni koszt $0.20/sesja

Krótsze sesje są tańsze nominalnie, ale cache write dominuje. Dla 30-minutowej sesji koszt na minutę spada wyraźnie.

Anti-pattern: "częściej, krócej"

Intuicja: krótsze sesje są tańsze, więc rób je krótsze. NIE prawda. Krótsze sesje płacą cache write proporcjonalnie więcej.

Lepiej: jedna 30-minutowa sesja niż 6 × 5-minutowych w ciągu godziny.

Kiedy cache nie pomaga

Trzy scenariusze:

1. Batch processing. Generujesz 100 niezależnych raportów. Każdy to świeży kontekst → cache nie pomaga. Wybór: Sonnet 4.6 (tańszy nominalnie).

2. Bardzo długie idle. Cron job co 6 godzin → 5-min TTL nie ma znaczenia. Każde wywołanie to fresh cost. Wybór: Sonnet 4.6 albo Haiku.

3. Hard cap na koszty. Jeśli rozliczasz API per-call (queue z budżetem), cache niespodzianki niewykonalne. Sonnet 4.6.

Reguła którą stosuję

Use case	Model
Aktywna sesja 5-60 min	Opus 4.7
Cron co < 5 min	Opus 4.7 (cache hit zwykle)
Cron co > 5 min	Sonnet 4.6
Batch processing	Sonnet 4.6
Quick ad-hoc query	Opus 4.7 z `/fast` (Opus 4.6 fast mode)
Background agent z >5 min idle	Sonnet 4.6

Cena per-token to nie to samo co cena per-zadanie. Z prompt cachingiem Opus 4.7 jest tańszy niż się wydaje. Mierz, optymalizuj kadencję, nie modele.