Cache promptu wygląda na darmową optymalizację, a jest zakładem: zapis kosztuje więcej niż jego brak. Rozbieram mechanizm u Anthropic i OpenAI, liczby i to, co realnie zrobić z pięciominutowym oknem.
Przemysław Zagórski7 min czytania
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. Po prostu zniknął cache.
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.
To nie jest pamięć odpowiedzi w stylu „już mnie o to pytałeś, oto zapisany wynik”. To zapis stanu wewnętrznego 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.
Tu jest rzecz, którą pomija większość poradników.
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.
Wynika z tego konsekwencja, której nikt się nie spodziewa 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. Cache nie jest przełącznikiem „włącz oszczędzanie”, tylko decyzją inwentaryzacyjną: czy ten prefiks 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, Sonnet 5 kosztuje 3 i 15, Haiku 4.5 kosztuje 1 i 5. Stosunek wychodzi ten sam, więc pięćdziesiąt jest własnością struktury cennika, a nie konkretnego modelu.
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 nie prowadzi dziennika na bieżąco, tylko 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.
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× | 0,1× |
| Punkty przerwania | jawne, maksymalnie 4 | 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.
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ą, tylko 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, tylko dlatego, że tyle wynosi okno, a nie dlatego, że ktoś je 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.
Nie jest darmowy. 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 opisane tu problemy brzmią znajomo, 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.
Slajd „95% wdrożeń AI kończy się porażką” trafił do każdej prezentacji sprzedażowej. Pokazuję, skąd naprawdę pochodzi ta liczba i podaję pięć wskaźników, które policzysz we własnej firmie w tydzień.
W randomizowanym badaniu programiści z AI pracowali 19% wolniej, a byli przekonani, że 20% szybciej. METR zaktualizował ten wynik. Pokazuję, co z niego zostało i co mówią dane GitClear oraz DORA.