Cache promptu wygląda na darmową optymalizację, a jest zakładem: zapis kosztuje więcej niż jego brak. Mechanizm u Anthropic i OpenAI, liczby z cenników i poprawki od najtańszej.
Przemysław Zagórski9 min czytaniaakt. 26 września 2026
Agent dostaje zadanie, czyta repozytorium, uruchamia testy. Testy chodzą siedem minut. Agent wraca z wynikiem, dokleja go do rozmowy i wykonuje kolejną turę.
Ta tura kosztuje dwanaście razy więcej niż poprzednia. Nic się nie wywaliło, nic nie zgłosiło błędu, w logach nie ma żadnego ostrzeżenia, bo cache po prostu wygasł.
Kto pracuje z agentami dłużej, zna ten objaw z drugiej strony: limit wyczerpany w środku dnia, mimo że rozmowa nie była dłuższa niż wczoraj. Warto wiedzieć, skąd to się bierze, bo mechanizm jest prosty, a wnioski z niego są mniej oczywiste, niż się wydaje.
Pierwsze nieporozumienie dotyczy tego, co w ogóle jest w cache'u.
Nie ma tam zapisanych odpowiedzi w stylu „już mnie o to pytałeś, oto zapisany wynik”. Jest stan wewnętrzny modelu po przeczytaniu początku Twojego promptu. Model przetwarza tekst po kolei i buduje w trakcie strukturę pośrednią. Cache przechowuje tę strukturę dla ustalonego prefiksu, żeby przy kolejnym zapytaniu nie liczyć jej od nowa.
Stąd bierze się jedyna reguła, z której wynika cała reszta: to dopasowanie prefiksu. Zmiana jednego bajtu w dowolnym miejscu unieważnia wszystko, co jest po nim.
Kolejność jest ustalona: najpierw narzędzia, potem instrukcja systemowa, na końcu wiadomości. Wstawienie znacznika czasu w nagłówek instrukcji systemowej unieważnia więc całą rozmowę pod nim, przy każdym zapytaniu, na zawsze.
U Anthropic zapis do cache'u kosztuje więcej niż zwykłe przetworzenie tekstu. Przy domyślnym oknie pięciominutowym to 1,25 raza stawki bazowej, przy oknie godzinnym 2 razy. Odczyt kosztuje 0,1 stawki bazowej w obu wariantach, a w modelach Opus 5.5, Fable 5.1 i Mythos 5.1 jeszcze mniej, o czym niżej.
Wynika z tego konsekwencja, która zaskakuje przy pierwszym włączeniu:
Prefiks zapisany i nigdy nieodczytany kosztuje od 25 do 100 procent więcej, niż gdyby cache'a w ogóle nie włączać. Płacisz premię za zapis i nie odzyskujesz jej żadnym odczytem.
Próg opłacalności liczy się prosto. Przy oknie pięciominutowym: zapis 1,25 plus odczyt 0,1 to 1,35 wobec 2,0 za dwa zapytania bez cache'u, więc drugie zapytanie już wychodzi na plus. Przy oknie godzinnym: 2,0 plus dwa odczyty po 0,1 to 2,2 wobec 3,0, więc potrzebujesz co najmniej trzech.
To zmienia sposób myślenia. Włączenie cache'u przestaje być przełącznikiem „włącz oszczędzanie” i staje się pytaniem o konkretny prefiks: czy zostanie odczytany wystarczająco wiele razy, zanim wygaśnie.
Zestawmy dwie stawki z cennika Claude. Tokeny wyjściowe kosztują pięć razy więcej niż wejściowe, a odczyt z cache'u to jedna dziesiąta wejściowych.
Czyli wygenerowanie jednego tokenu kosztuje tyle, co odczytanie pięćdziesięciu z cache'u.
Nie jest to ciekawostka o jednym modelu. Proporcja pięć do jednego między wyjściem a wejściem trzyma się w całej bieżącej linii Claude. Opus 5 kosztuje 5 i 25 dolarów za milion tokenów, Sonnet 5 kosztuje 2 i 10, Haiku 4.5 kosztuje 1 i 5. Przy odczycie za 0,1 stawki każdy z nich daje tę samą pięćdziesiątkę.
Aktualizacja z 11 września 2026. W pierwszej wersji tego tekstu podałem dla Sonneta 5 stawki 3 i 15 dolarów, czyli cenę, która miała obowiązywać po okresie promocyjnym. Ta podwyżka nie weszła: 2 i 10 dolarów jest dziś ceną stałą. Proporcja się przez to nie zmieniła. Zmieniło się co innego. W modelach Fable 5.1 i Mythos 5.1 odczyt z cache'u kosztuje 0,025 stawki wejściowej zamiast 0,1. Przy cenach 10 i 50 dolarów jeden wygenerowany token kosztuje tam tyle, co dwieście tokenów odczytanych z cache'u. Pisałem wcześniej, że pięćdziesiąt wynika ze struktury całego cennika. Dla tych dwóch modeli już nie, a wniosek z następnego akapitu jest przy nich czterokrotnie mocniejszy. Praktyczny wniosek dotyczy popularnego wzorca, w którym agent po każdym kroku aktualizuje plik ze stanem pracy. Zapisanie tysiąca tokenów kosztuje tyle, co przeczytanie pięćdziesięciu tysięcy z cache'u. Przy pięćdziesięciu takich zapisach w sesji płacisz równowartość dwóch i pół miliona odczytanych tokenów, żeby oszczędzić na kontekście, który i tak byłby tani.
Odwrócenie tego wzorca jest tanie: agent zamiast prowadzić dziennik na bieżąco zrzuca stan raz, na wyraźne polecenie, przed przerwą. Płacisz za generowanie jeden raz zamiast pięćdziesięciu, a w trakcie sesji korzystasz z pełnej historii, która w gorącym cache'u kosztuje grosze.
Aktualizacja z 26 września 2026. 22 września wyszedł Claude Opus 5.5 w cenie 4 i 20 dolarów za milion tokenów. Odczyt z cache'u kosztuje w nim 0,05 stawki wejściowej, czyli 20 centów za milion, więc jeden wygenerowany token kosztuje tyle, co sto odczytanych z cache'u. Pięćdziesiątka dotyczy teraz Opusa 5, Sonneta 5 i Haiku 4.5, a nie całej bieżącej linii Claude.
OpenAI szło inną drogą i doszło mniej więcej w to samo miejsce.
Starsze modele miały cache automatyczny i niewidoczny. System sam wykrywał wspólny prefiks powyżej progu długości, a za zapis nie pobierał opłaty. Retencją sterował parametr prompt_cache_retention: przy ustawieniu w pamięci wynosiła od pięciu do dziesięciu minut, najwyżej godzinę. Deweloper nie miał na to wpływu i nie widział, czy trafił.
Od GPT-5.6 obraz jest inny i wyraźnie zbieżny z Anthropic:
| Anthropic | OpenAI (GPT-5.6 i nowsze) | |
|---|---|---|
| Zapis | 1,25× (5 min) / 2× (1 h) | 1,25× |
| Odczyt | 0,1× (Opus 5.5: 0,05×, Fable 5.1 i Mythos 5.1: 0,025×) | 0,1× |
| Punkty przerwania | jawne (maksymalnie 4) albo automatyczne | jawne, prompt_cache_breakpoint |
| TTL | 5 minut domyślnie, 1 godzina opcjonalnie | 30 minut, jedyna wartość i domyślna |
| Próg długości | 512 do 4096 tokenów, zależnie od modelu | 1024 tokeny |
Kierunek zmiany jest jednoznaczny: od automatu bez gwarancji do jawnej deklaracji z ceną. Obie firmy oddały inżynierowi kontrolę nad granicą między stałą a zmienną częścią promptu i obie zaczęły za tę kontrolę liczyć premię od zapisu.
Uzupełnienie z 11 września 2026. Anthropic opisuje dziś w dokumentacji także tryb automatyczny: jedno pole cache_control na poziomie całego zapytania, a system sam przesuwa punkt przerwania na koniec rosnącej rozmowy. Dokumentacja poleca go jako punkt startu przy rozmowach wieloturowych. Automat wrócił więc u Anthropic jako wygoda, ale z tą samą ceną i tym samym oknem, a nie jako darmowy mechanizm bez gwarancji. Mnożniki cenowe są identyczne, więc wszystko, co piszę niżej o premii za zapis i oknie czasowym, dotyczy obu trybów.
Różnica została jedna, ale istotna. U OpenAI prompt_cache_options.ttl przyjmuje wyłącznie wartość 30m, która jest zarazem domyślna. Nie ma czym kręcić. U Anthropic masz wybór między pięcioma minutami a godziną, ale ten wybór kosztuje.
Krąży teza, że Anthropic po cichu obniżył domyślny TTL z godziny do pięciu minut. Sprawdziłem dokumentację i nie ma tam śladu takiej zmiany: pięć minut jest opisane jako wartość domyślna, godzina jako płatne rozszerzenie. Sama konstrukcja cennika przeczy tej historii, bo nikt nie liczy podwójnej stawki za coś, co wcześniej było domyślne i darmowe.
Zjawisko jest prawdziwe, wyjaśnienie nie. Cache faktycznie znika po pięciu minutach, bo tyle wynosi okno. Nikt go nie skrócił.
Weźmy prefiks 164 tysięcy tokenów, czyli typową sesję agentową z instrukcją systemową, schematami narzędzi i narosłą historią. Model Opus 5, stawka wejściowa 5 dolarów za milion.
Dwanaście i pół raza drożej, na każdej turze po przerwie. Przy agencie, który dziesięć razy dziennie czeka ponad pięć minut na testy, to dziesięć dolarów dziennie na samym odtwarzaniu tego, co już raz policzono.
Przesuń zmienne rzeczy na koniec. Najczęstsza przyczyna zerowego trafienia to nie okno czasowe, tylko coś, co zmienia się w prefiksie przy każdym zapytaniu. Data w instrukcji systemowej, identyfikator sesji, słownik serializowany bez ustalonej kolejności kluczy, zestaw narzędzi budowany per użytkownik. To nic nie kosztuje naprawić i często załatwia sprawę w całości.
Sprawdź, czy w ogóle trafiasz. Odpowiedź zawiera trzy pola: cache_creation_input_tokens, cache_read_input_tokens i input_tokens. Jeśli drugie jest zerem przy powtarzalnym prefiksie, masz cichego unieważniacza. Uwaga na pułapkę: input_tokens to wyłącznie reszta nieobjęta cache'em, a nie całość promptu. Rozmiar promptu to suma trzech pól, więc agent pokazujący cztery tysiące tokenów po godzinie pracy nie jest oszczędny, tylko dobrze zbuforowany.
Nie wszystko unieważnia wszystko. To rozróżnienie oszczędza sporo niepotrzebnej ostrożności. Zmiana definicji narzędzi albo modelu kasuje cache w całości. Ale przełączenie tool_choice, dorzucenie obrazu czy włączenie i wyłączenie myślenia zachowuje warstwę narzędzi i instrukcji systemowej. Możesz tym kręcić per zapytanie bez obaw.
Rozgrzej cache przed ruchem. Zapytanie z max_tokens: 0 przechodzi przez fazę czytania promptu, zapisuje cache i wraca natychmiast z pustą treścią, nie naliczając tokenów wyjściowych. Sensowne przy starcie procesu albo na początku okna, w którym spodziewasz się ruchu. Bez sensu przy ruchu ciągłym, bo tam pierwsze prawdziwe zapytanie i tak rozgrzewa cache, a osobne rozgrzewanie to czysty dodatkowy zapis.
Dopiero na końcu sięgaj po dłuższe okno. Godzinny TTL u Anthropic rozwiązuje problem przerw wprost, ale kosztuje podwójny zapis i zwraca się dopiero przy trzecim odczycie. Ma sens przy ruchu z długimi dziurami, nie ma przy zapytaniach częstszych niż co pięć minut.
Równoległe zapytania nie czytają się nawzajem. Wpis staje się czytelny dopiero, gdy pierwsza odpowiedź zacznie spływać. Wysłanie dziesięciu zapytań z tym samym prefiksem naraz oznacza dziesięć pełnych opłat, bo żadne nie zdąży przeczytać tego, co pozostałe dopiero zapisują. Przy rozsyłaniu równoległym wyślij jedno, poczekaj na pierwszy token, dopiero potem resztę.
Okno przeszukiwania ma dwadzieścia bloków. Punkt przerwania cofa się najwyżej o dwadzieścia bloków treści, szukając wcześniejszego wpisu. Tura agentowa z długą serią wywołań narzędzi potrafi ten limit przekroczyć i wtedy kolejne zapytanie po prostu nie znajduje poprzedniego cache'u. Objaw wygląda identycznie jak wygaśnięcie, a przyczyna jest zupełnie inna.
Cache po stronie dostawcy jest jedyną optymalizacją kosztów, która nie wymaga rezygnacji z niczego: ten sam model, ten sam kontekst, ta sama jakość. Dlatego łatwo potraktować go jak darmowy przełącznik.
Tymczasem ma premię od zapisu, próg opłacalności i okno czasowe, a wszystkie trzy działają przeciwko wzorcowi pracy, w którym agent regularnie czeka po kilka minut na świat zewnętrzny.
Reguła, którą bym zapamiętał: zanim wydłużysz okno, sprawdź, czy w ogóle trafiasz. W większości audytów, jakie widziałem, problemem nie było pięć minut, tylko data w instrukcji systemowej.
Pokrewne teksty na tym blogu: higiena kontekstu o tym, dlaczego więcej kontekstu nie znaczy lepiej, oraz słowniczek z definicjami tokenu i okna kontekstowego.
Programista i architekt, 14+ lat w telco i enterprise IT. Prowadzi warsztaty z inżynierii kontekstu, GitHub Copilota, Google ADK oraz ekosystemu Gemini dla zespołów, które muszą dowozić produkcyjnie.
Jeśli widzisz te problemy u siebie, zwykle da się je rozbroić w kilka dni roboczych. Nie kolejnym narzędziem, tylko zmianą sposobu pracy zespołu. Chętnie omówię Wasz przypadek.
Pi to otwarty agent do kodu w terminalu, który celowo nie ma MCP, subagentów ani trybu planu. Zmierzyłem, ile wysyła do modelu na starcie, i opisuję, dla kogo to dobry wybór.
Specyfikacja przed kodem zamienia jedną dużą decyzję modelu na kilka małych, które da się sprawdzić. Zbieram, co mówią badania, jak robią to Spec Kit i Kiro i kiedy ten narzut się nie zwraca.