Agent czeka sześć minut na zatwierdzenie i płaci prefiks od nowa. Cache wygasł w trakcie bramki

Agent pocztowy przygotowuje odpowiedź na zgłoszenie i zatrzymuje się na punkcie zatwierdzenia. Operator klika po sześciu minutach. Agent wraca do pracy z tym samym prefiksem co minutę wcześniej – trzydzieści tysięcy tokenów definicji narzędzi i procedury – i płaci za niego pełną stawkę, bo wpisu w cache już nie ma. Przy pięćdziesięciu takich zatrzymaniach dziennie to nie jest zaokrąglenie.

Cache promptów ma czas życia liczony w minutach, a przepływ agentowy ma opóźnienia liczone w minutach. Te dwie liczby stoją w tej samej skali i prawie nikt ich obok siebie nie stawia przy projektowaniu punktów zatrzymania. Skutkiem nie jest brak oszczędności, a koszt wyższy niż bez buforowania: zapis z pięciominutowym czasem życia kosztuje 1,25 raza cenę zwykłego tokena wejściowego, więc przepływ, który zapisuje i nigdy nie czyta, przepłaca o jedną czwartą za każdy token prefiksu.

Serwer liczy prefiks od pierwszego bajtu, nie od sensu promptu

Cache promptów nie jest pamięcią semantyczną. To dopasowanie prefiksu bajt po bajcie. Dostawca składa żądanie w ustalonej kolejności – najpierw definicje narzędzi, potem prompt systemowy, potem wiadomości – i szuka najdłuższego początku, który już widział. Dokumentacja stawia warunek bez miejsca na interpretację: trafienie wymaga w 100 procentach identycznych segmentów promptu, łącznie z całym tekstem i obrazami, aż do bloku oznaczonego punktem cięcia.

Z tego wynika hierarchia unieważnień, która w architekturze agenta waży więcej niż sam mnożnik. Zmiana definicji narzędzi kasuje cache narzędzi, promptu systemowego i wiadomości – czyli wszystko. Zmiana promptu systemowego kasuje prompt systemowy i wiadomości, ale zostawia narzędzia. Zmiana ostatniej wiadomości kasuje tylko ogon. Agent, który przy każdym uruchomieniu serializuje listę narzędzi z nieposortowanego słownika, dostaje za każdym razem inną kolejność bajtów i za każdym razem płaci pełny zapis całego prefiksu.

Dla pracy wdrożeniowej wynika z tego jedno: kolejność składania promptu jest decyzją kosztową, nie stylistyczną. Stabilne idzie na początek, zmienne na koniec.

Zapis kosztuje 1,25 raza, odczyt 0,05 raza – arytmetyka zwrotu

Liczby poniżej to cennik Claude Opus 5.5 w stanie na 26 października 2026; dla innych modeli mnożniki są te same, ceny bazowe inne. Cennik podaje 4 dolary za milion tokenów wejściowych, 5 dolarów za zapis pięciominutowy, 8 dolarów za zapis godzinny i 0,20 dolara za trafienie.

Ostatnia kolumna jest całą treścią decyzji i jest potwierdzona wprost w cenniku: cache zwraca się po jednym odczycie przy czasie życia 5 minut i po dwóch odczytach przy czasie życia godzinnego. Progi są więc bardzo niskie. Problem nigdy nie polega na tym, że agent czyta za mało razy, by zwrot nastąpił. Polega na tym, że czyta zero razy, bo wpisu już nie ma.

Mnożnik odczytu zależy od modelu i nie jest to szczegół księgowy. Na Opusie 5.5 i Sonnecie 5.5 trafienie kosztuje 0,05x ceny bazowej, na większości pozostałych modeli 0,1x. Ważniejsze od samego mnożnika jest to, że okno czasowe, w którym wpis żyje, też zależy od dostawcy, a od niego zależy budżet opóźnień całego przepływu. U OpenAI jest szerszy: na modelach GPT-5.6 i nowszych minimalny czas życia wpisu to 30 minut, a w wariancie dwunastogodzinnym odpowiednio więcej. Ten sam punkt zatwierdzenia, który na pięciominutowym oknie gubi prefiks przy każdym zgłoszeniu, na oknie półgodzinnym nie gubi go prawie nigdy. Projektowanie punktów zatrzymania bez sprawdzenia tej jednej liczby u swojego dostawcy jest zgadywaniem.

Agent czeka sześć minut na zatwierdzenie i traci wpis w cache

Domyślny czas życia wpisu to pięć minut, odświeżane bezpłatnie przy każdym użyciu. Haczyk jest w punkcie odniesienia. Dokumentacja precyzuje, że czas życia liczy się od początku żądania, które zapisuje lub czyta wpis, nie od końca odpowiedzi – jeśli odpowiedź strumieniuje się cztery minuty, następne żądanie ma około minuty, nie pięciu.

Przepływ agentowy produkuje dokładnie takie opóźnienia, i to w miejscach, które projektuje się celowo:

• Punkt zatwierdzenia przez człowieka. Agent przygotowuje odpowiedź, zatrzymuje się, czeka na kliknięcie. Operator wraca po kilku minutach. Wpis wygasł, kolejna tura to pełny zapis.
• Długa tura narzędziowa. Agent wykonuje serię wywołań do systemów firmy, jedno z nich odpytuje bazę przez trzy minuty. Zegar nie czeka na koniec tury, tyka od jej początku.
• Ruch rozproszony. Faktury wpadają średnio co dwadzieścia minut. Każda to osobny zapis, zero odczytów, rachunek wyższy o 25 procent niż bez cache.
• Kolejka wieczorna. Agent przerabia paczkę raz na dobę. Tu cache pięciominutowy działa dobrze w obrębie paczki i jest bezwartościowy między paczkami.

Trzeci przypadek generuje zgłoszenie „rachunek wzrósł po włączeniu cache” i jest jedynym, w którym odpowiedź nie brzmi „wyłącz cache”. Odpowiedź brzmi: przejdź na czas życia godzinny. Zapis kosztuje wtedy 2x zamiast 1,25x, ale wpis dożywa następnego żądania i zaczyna zwracać się po drugim odczycie.

Dla dwóch pierwszych przypadków – tych, które wynikają z projektu przepływu, a nie z rozkładu ruchu – lekarstwo jest po stronie architektury i sprowadza się do trzech decyzji:

• Zbieraj zatwierdzenia w paczki, nie po jednym. Dziesięć spraw podanych operatorowi w jednym ekranie to jedna przerwa w strumieniu żądań, a nie dziesięć. Ten sam wpis obsługuje wtedy wszystkie dziesięć powrotów, zamiast wygasać dziewięć razy. Przy projektowaniu bramek zatwierdzania liczy się więc nie tylko to, co człowiek widzi, ale i to, jak długa cisza powstaje za każdym kliknięciem.
• Stawiaj punkt zatrzymania przed drogim prefiksem, nie za nim. Jeśli agent ma zapytać człowieka, zanim ruszy kosztowną część pracy, wywołanie przed bramką może chodzić na krótkim prompcie bez pełnej wiedzy dołączonej. Pełny prefiks ładuje się po zatwierdzeniu i od razu jest czytany kilka razy w jednej serii, zamiast czekać na decyzję i wygasnąć.
• Ponowienia licz jako odczyty, nie jako nowy koszt. Ponowienie po błędzie narzędzia albo po przekroczeniu limitu wysyła ten sam prefiks jeszcze raz. Jeśli trafi w okno, jest odczytem za 0,05x i ponowienia są tanie. Jeśli ścieżka ponowienia dokleja do promptu numer próby albo znacznik czasu, każde ponowienie jest nowym zapisem – i wtedy przepływ, który czasem się potyka, kosztuje wielokrotnie więcej niż ten, który nie potyka się nigdy.

Agent dokleja znacznik czasu do promptu systemowego i nigdy nie trafia w cache

Druga kategoria to unieważnienia, których nikt nie zgłasza, bo nie rzucają błędu. Rachunek po prostu nie spada tam, gdzie miał spaść.

• Dynamiczna data w prompcie systemowym. Jedna linia z bieżącą godziną i sekundową precyzją na początku promptu systemowego unieważnia prefiks przy każdym żądaniu. Jeśli agent naprawdę potrzebuje zegara, jego miejsce jest po ostatnim punkcie cięcia, nie przed nim.
• Prefiks poniżej progu. Minimalna długość buforowanego prefiksu to 512 tokenów na Opusie 5.5, Sonnecie 5.5 i Haiku 5.5, 1024 na Opusie 4.8 i Sonnecie 5, a 4096 na Opusie 4.6. Krótszy prompt nie jest buforowany i nie zwraca żadnego błędu.
• Zmiana poziomu wysiłku lub parametrów myślenia w trakcie rozmowy. Unieważnia bloki wiadomości. Przełączanie agenta na niższy wysiłek w połowie zadania kasuje cache historii, którą ten agent właśnie zbudował.
• Limit punktów cięcia. Można zdefiniować najwyżej cztery punkty cięcia, a buforowanie automatyczne zajmuje jeden z nich – przy czterech zdefiniowanych ręcznie dochodzi odpowiedź 400, bo nie ma wolnego miejsca.
• Próg długiego promptu na Haiku 5.5. Cennik stwierdza wprost, że długość promptu liczy wszystkie tokeny wejściowe żądania, w tym trafienia i zapisy w cache. Duży buforowany kontekst na tym modelu przepycha żądanie przez próg 100 tysięcy tokenów i każe mu płacić wyższą stawkę, mimo że prefiks był trafieniem.

Weryfikacja jest jednoliniowa i nie wymaga narzędzia poza odpowiedzią API. Pole cache_read_input_tokens mówi, ile tokenów przyszło z cache, cache_creation_input_tokens – ile do niego zapisano. Jeśli przy powtarzanych żądaniach o tym samym prefiksie pierwsze zostaje na zerze, a drugie rośnie, działa któryś z punktów powyżej.

Rachunek miesięczny dla dwóch wzorców ruchu

Założenia wspólne: prefiks stabilny 30 tysięcy tokenów – definicje narzędzi, prompt systemowy, procedura obsługi – 1200 wywołań miesięcznie, Claude Opus 5.5 w cenach z tabeli wyżej. Ten sam agent, ten sam prompt, różnica wyłącznie w rozkładzie żądań w czasie.

Rachunek dla drugiego wiersza i drugiej kolumny: 1200 zapisów po 30 tysięcy tokenów to 36 milionów tokenów po 5 dolarów, czyli 180 dolarów, wobec 144 dolarów przy wyłączonym cache. Dokładnie 1,25 raza. Dla trzeciej kolumny tego samego wiersza: w godzinie mieszczą się trzy żądania, więc 400 zapisów (12 mln tokenów po 8 dolarów to 96 dolarów) i 800 odczytów (24 mln tokenów po 0,20 dolara to 4,80 dolara) dają razem 100,80 dolara.

Błąd, który produkuje ten rozjazd, nie jest specyficzny dla agentów. To wycena zasobu po jego najbardziej widocznym składniku: przy druku na zlecenie liczy się filament i pomija koszt godziny maszyny, przy agencie liczy się tokeny promptu i pomija mnożnik zapisu. W obu przypadkach pozycja pominięta jest tą, która decyduje o znaku wyniku.

Wniosek z tabeli nie brzmi „włączaj cache” ani „nie włączaj”. Brzmi: oszczędność jest funkcją rozkładu żądań w czasie, a nie wielkości promptu. Ten sam prefiks przy ruchu skupionym daje 85 procent oszczędności, a przy rozproszonym 25 procent straty, jeśli czas życia wpisu dobrano do złego wzorca. Rozkład żądań w czasie jest więc parametrem architektury agenta i trzeba go znać przed włączeniem flagi, nie po pierwszej fakturze.

Schemat przepływu: gdzie postawić punkty cięcia

Kolejność warstw żądania jest ustalona przez dostawcę i wygląda tak samo za każdym razem. Zadaniem wdrożeniowca jest poukładać własną treść wewnątrz tych warstw od najbardziej do najmniej stabilnej.

Dwie rzeczy w tej tabeli są częściej psute niż pozostałe. Pierwsza: warstwa trzecia bywa wsuwana między historię i zmienną treść, bo tak wygodniej budować prompt w kodzie – i wtedy codzienna aktualizacja cennika kasuje cache całej historii rozmowy. Druga: warstwa piąta bywa wklejana do promptu systemowego, bo „to tylko jedna linijka” – i ta jedna linijka unieważnia wszystko, co jest za nią, czyli cały prefiks.

Operator mid-rozmowy to wariant warstwy piątej wart osobnej uwagi. Instrukcję, która przychodzi w trakcie rozmowy, dokłada się jako wiadomość na końcu tablicy wiadomości, nie przez edycję górnego promptu systemowego. Pierwszy sposób zostawia cache historii nietknięty, drugi kasuje go w całości.

Co zmierzyć, zanim zostawisz cache włączony na produkcji

Kolejność poniżej jest ułożona tak, żeby każdy krok dawał liczbę, na podstawie której można podjąć decyzję o następnym.

• Policz rozkład odstępów między żądaniami z logów ostatnich dwóch tygodni, nie średnią. Średnia 20 minut przy rozkładzie dwumodalnym (serie po kilka żądań, potem godziny ciszy) prowadzi do innej decyzji niż równomierne 20 minut.
• Zmierz długość stabilnego prefiksu w tokenach. Poniżej progu modelu nie ma czego buforować, a flaga nie zgłosi problemu.
• Włącz cache na jednym przepływie i odczytaj stosunek odczytów do zapisów z pól cache_read_input_tokens i cache_creation_input_tokens. Jeden odczyt na zapis przy pięciu minutach to już zwrot; zero odczytów to wzrost rachunku o 25 procent.
• Przy zerze odczytów przełącz czas życia na godzinny zamiast wyłączać buforowanie, i zmierz jeszcze raz. Dwa odczyty na zapis to próg zwrotu dla tego wariantu.
• Dopiero potem tnij prefiks. Skracanie promptu systemowego przy sprawnym cache oszczędza 0,05x, a przy niesprawnym 1,25x – kolejność tych dwóch prac decyduje o tym, ile jest warta ta druga.
• Wystaw stosunek odczytów do zapisów na stały podgląd obok liczby obsłużonych spraw. Jeśli spadnie po wydaniu nowej wersji, znaczy, że zmiana ruszyła prefiks – najczęściej kolejność narzędzi albo nowa linia w prompcie systemowym.

Ten stosunek jest też najtańszym punktem kontrolnym w umowie z wykonawcą. Jeśli agent powstaje na zlecenie, licznik odczytów i zapisów wchodzi do warunków odbioru obok skuteczności obsługi – zespoły, które wdrażają i utrzymują agentów na zlecenie, raportują go od pierwszego tygodnia, zamiast tłumaczyć rozjazd rachunku kwartał później.

Decyzja do podjęcia po przeczytaniu jest jedna i nie dotyczy flagi w kodzie. Zanim ktokolwiek włączy albo wyłączy buforowanie, trzeba zestawić dwie liczby tego konkretnego przepływu: rozkład odstępów między żądaniami i czas życia wpisu u dostawcy. Dla ruchu skupionego sensowny domyślny wybór to pięć minut, dla rozproszonego godzina, dla paczek nocnych pięć minut w obrębie paczki i świadoma zgoda na pełny zapis przy pierwszym żądaniu każdej z nich. Jeśli te dwie liczby się nie spinają, przesuń punkt zatrzymania, zanim ruszysz prompt – bramka postawiona w złym miejscu kosztuje więcej niż cały prefiks, który przez nią wygasa.