Prompt caching w OpenAI API. Jak działa i jak sprawdzić, czemu cache nie trafia

Co zmieniło się 8 września

Wpis w dzienniku zmian OpenAI API z 8 września 2026 roku ogłosił ogólną dostępność Prompt Cache Diagnostics w Responses API. Funkcja porównuje bieżące zapytanie z wcześniejszą odpowiedzią i wskazuje, co uniemożliwiło ponowne użycie zapisanego prefiksu. Działa z GPT-5.6 i nowszymi obsługiwanymi modelami, w tym z rodziną GPT-6.

Do tej pory zespół widział jedynie liczbę tokenów odczytanych z cache w polu usage. Niski wynik nie mówił, czy winna jest zmiana narzędzi, inny model, nowy znacznik czasu w instrukcji systemowej czy kompresja historii rozmowy. Diagnostyka zamienia to zgadywanie w konkretny kod przyczyny.

Cache na 12 godzin - nowa opcja od 20 października

Wpis w dzienniku zmian OpenAI API z 20 października 2026 roku dodał możliwość wyboru 12-godzinnego cache w Responses API. Dotyczy modeli GPT-5.6 i nowszych. Ustawia się go parametrem prompt_cache_options.ttl z wartością 12h, a pojedyncze punkty zapisu mogą mieć własne ustawienie w prompt_cache_breakpoint.ttl. Domyślnie nadal obowiązuje wartość 30m, czyli co najmniej 30 minut.

Dłuższy cache ma wyższą cenę zapisu. Przy 12h zapis kosztuje 2,5 zwykłej stawki wejścia, a przy 30m 1,25 stawki. Odczyt kosztuje w obu przypadkach 0,1 stawki, a w GPT-6.1 Sol 0,05 stawki. Opcja przydaje się tam, gdzie te same instrukcje, narzędzia i materiały wracają co kilka godzin, a nie co kilka minut, na przykład w agentach uruchamianych według harmonogramu albo w narzędziach wewnętrznych używanych w ciągu dnia pracy.

Według dokumentacji ustawienie 12h nie wyznacza terminu usunięcia danych i nie zmienia polityki przechowywania danych organizacji. Nie zmienia też starszego parametru prompt_cache_retention. Nieobsługiwana wartość ttl kończy się błędem 400 invalid_request_error.

• Przy 2 użyciach prefiksu w odstępie ponad 30 minut koszt wynosi 2 jednostki bez cache, 2,5 z cache 30m i 2,6 z cache 12h.
• Przy 3 użyciach w ciągu dnia to 3 jednostki bez cache, 3,75 z cache 30m i 2,7 z cache 12h, więc dłuższy cache zaczyna się opłacać.
• Przy 10 użyciach w ciągu dnia to 10 jednostek bez cache, 12,5 z cache 30m i 3,4 z cache 12h.
• Przy zapytaniach co kilka minut wystarczy domyślne 30m, bo wpis pozostaje aktywny, a zapis jest dwa razy tańszy.

Jak działa prompt caching w OpenAI API

Model przetwarzający zapytanie oblicza dla każdego tokena wewnętrzne stany uwagi, tak zwane stany klucz-wartość (KV). Prompt caching zapisuje te stany dla początku zapytania. Jeśli kolejne zapytanie zaczyna się dokładnie tak samo, model korzysta z zapisanych obliczeń i przetwarza tylko nową część.

Mechanizm jest włączony domyślnie w obsługiwanych modelach i nie wymaga zmian w kodzie. W GPT-5.6 i nowszych modelach prefiks musi mieć co najmniej 1024 widoczne tokeny wejściowe. Liczy się dokładna zgodność od pierwszego tokena, więc jedno zmienione słowo w instrukcji systemowej przerywa dopasowanie od tego miejsca.

Cache jest przechowywany na konkretnych maszynach, a OpenAI samo kieruje ruch tam, gdzie może znajdować się pasujący wpis. Wpisy nie są współdzielone między organizacjami ani między regionami przetwarzania. Firma korzystająca z przetwarzania w regionie UE nie odczyta więc cache zapisanego w innym regionie.

Ile kosztuje zapis i odczyt cache

W modelach GPT-5.6 i nowszych OpenAI rozlicza cache w dwóch krokach. Pierwsze zapytanie zapisuje prefiks po stawce 1,25 zwykłej ceny wejścia, a każde kolejne trafienie odczytuje go po stawce 0,1. Starsze modele nie naliczają osobnej opłaty za zapis i mają własne ceny wejścia z cache.

Dla GPT-6 Sol, którego wejście kosztuje 2 USD za milion tokenów, odczyt z cache kosztuje 0,20 USD, a zapis wynika z mnożnika i wynosi 2,50 USD. Po kursie NBP z 25 września 2026 roku (1 USD = 3,8404 zł) to odpowiednio około 0,77 zł i 9,60 zł za milion tokenów, bez VAT. Poniższe zestawienie pokazuje, jak rozkłada się koszt przy rosnącej liczbie zapytań z tym samym prefiksem.

• 2 zapytania: 1,35 jednostki kosztu z cache wobec 2 jednostek bez cache.
• 10 zapytań: 2,15 jednostki wobec 10 jednostek.
• Prefiks krótszy niż 1024 tokeny: brak cache, każde zapytanie płaci pełną stawkę.
• Prefiks użyty tylko raz: zapis kosztuje 25 proc. więcej niż zwykłe wejście, więc cache nie przynosi oszczędności.

Przykład: czat obsługi klienta na GPT-6 Sol

Przyjmijmy polski sklep internetowy, którego asystent wysyła przy każdym zapytaniu instrukcje, regulamin zwrotów i definicje narzędzi o łącznej długości 12 tys. tokenów. Miesięcznie obsługuje 100 tys. zapytań. Bez cache sam ten stały fragment to 1,2 mld tokenów wejściowych, czyli 2400 USD, około 9217 zł netto.

Zakładamy, że 90 proc. zapytań trafia w cache, a pozostałe 10 proc. zapisuje prefiks od nowa. Zapisy kosztują wtedy 300 USD, a odczyty 216 USD. Łącznie to 516 USD, około 1982 zł netto, czyli mniej więcej 78 proc. mniej za ten fragment wejścia. To wyliczenie redakcji na podstawie cennika i mnożników z dokumentacji. Nie obejmuje tokenów wyjściowych ani zmiennej części zapytania, a rzeczywisty odsetek trafień zależy od ruchu i budowy zapytań.

Jak włączyć diagnostykę cache

Diagnostyka wymaga wskazania odpowiedzi bazowej, z którą ma być porównane nowe zapytanie. Wynik pojawia się w obiekcie odpowiedzi, a przy strumieniowaniu w zdarzeniu response.completed. Funkcja nie ma dodatkowej opłaty i nie liczy się osobno do limitów zapytań.

1. Wyślij pierwsze zapytanie przez Responses API i zapisz identyfikator odpowiedzi.
2. W kolejnym zapytaniu ustaw prompt_cache_options.comparison_response_id na ten identyfikator.
3. Odczytaj pole prompt_cache_diagnostics w odpowiedzi. Typ cache_hit oznacza brak chybienia, cache_miss podaje przyczynę (reason) i liczbę utraconych tokenów (cache_missed_tokens).
4. Typy comparison_response_not_found i unavailable oznaczają, że porównanie nie było możliwe, na przykład z powodu wygaśnięcia rekordu lub nieobsługiwanego modelu.
5. Do stałego nadzoru nad całą aplikacją użyj panelu Prompt Caching Dashboard w ustawieniach zużycia platformy OpenAI.

Dziewięć przyczyn chybienia cache

Dokumentacja wymienia dziewięć kodów przyczyn. Większość wynika z decyzji po stronie aplikacji, więc da się je usunąć bez kontaktu z OpenAI.

• model_changed - zapytanie trafiło do innego modelu niż odpowiedź bazowa.
• prompt_cache_key_changed - zmienił się klucz grupujący zapytania.
• service_tier_changed - zmienił się poziom usługi, na przykład z domyślnego na priorytetowy.
• tools_changed - dodano, usunięto, przestawiono albo zmodyfikowano narzędzia.
• text_format_changed - zmienił się format odpowiedzi lub schemat JSON.
• reasoning_effort_changed - zmieniono parametr reasoning.effort.
• verbosity_changed - zmieniono parametr text.verbosity.
• context_compacted - kompresja kontekstu zastąpiła wcześniejszą część rozmowy.
• input_changed - zmieniła się wcześniejsza treść wejścia. Zmienne dane trzeba przenieść za stały prefiks.

Jak budować zapytania, żeby cache trafiał

Podstawowa zasada brzmi: stałe elementy na początku, zmienne na końcu. Instrukcje systemowe, materiały referencyjne i definicje narzędzi powinny się nie zmieniać między zapytaniami. Data, nazwa użytkownika czy identyfikator zamówienia w pierwszym akapicie instrukcji wystarczą, żeby każde zapytanie zapisywało cache od nowa.

W rozmowach wieloetapowych nowe wiadomości trzeba dopisywać, a nie przepisywać wcześniejsze. Streszczanie lub przycinanie historii zmienia prefiks. OpenAI zaznacza jednak, że kompresja może się opłacać mimo spadku trafień, bo krótsze wejście bywa tańsze od lepiej buforowanego długiego. Decyzję warto oprzeć na porównaniu całkowitego kosztu, a nie samego odsetka trafień.

GPT-5.6 i nowsze modele pozwalają też sterować miejscem zapisu. Tryb jawny (prompt_cache_options.mode ustawione na explicit) z punktami prompt_cache_breakpoint umożliwia zapis maksymalnie czterech prefiksów w jednym zapytaniu. Opcja prewarm przygotowuje cache bez generowania odpowiedzi, co skraca czas do pierwszego tokena w aplikacjach interaktywnych. Tokeny zapisane w ten sposób są rozliczane po stawce zapisu.

Ograniczenia i ryzyka

W nowszych modelach prompt_cache_options.ttl przyjmuje wartości 30m (domyślnie) i 12h, przy czym 12h działa w Responses API. Wyliczenia w zestawieniu powyżej są redakcyjne i zakładają, że wpis przetrwa co najmniej deklarowany czas oraz że zapytania trafiają do tego samego regionu przetwarzania. Starsze modele korzystają z parametru prompt_cache_retention z wartościami in_memory i 24h, a domyślna wartość zależy od tego, czy organizacja ma włączone Zero Data Retention.

Diagnostyka działa na zasadzie najlepszych starań. Zwraca tylko pierwszą rozpoznaną przyczynę, nie klasyfikuje każdego chybienia, a jej rekordy szybko wygasają. OpenAI deklaruje, że na potrzeby tej funkcji nie przechowuje treści zapytań ani odpowiedzi, a jedynie metadane konfiguracji, szacunkowe liczby tokenów i skróty (hashe).

Cache nie zmniejsza obciążenia limitów. Odczytane tokeny nadal liczą się do limitu tokenów na minutę, co ma znaczenie przy nagłym wzroście ruchu i błędach 429. Nie da się też ręcznie wyczyścić cache, a identyczne zapytanie z trafieniem nie gwarantuje identycznej odpowiedzi.

Co zrobić teraz

W naszej ocenie diagnostyka jest najbardziej przydatna dla zespołów, które mają długie instrukcje systemowe, dużo narzędzi albo agentów pracujących w wielu krokach. Tam różnica między 30 a 90 proc. trafień przekłada się bezpośrednio na miesięczny rachunek. Mała aplikacja z krótkimi zapytaniami poniżej 1024 tokenów nie skorzysta z cache w ogóle.

Na początek wystarczy sprawdzić w logach pola cached_tokens i cache_write_tokens w usage.input_tokens_details oraz policzyć odsetek trafień dla głównych ścieżek aplikacji. Jeśli wynik jest niski, kilka zapytań z parametrem comparison_response_id pokaże, czy problem leży w kolejności treści, zmieniających się narzędziach czy innym modelu. W firmach rozliczających koszty AI między działami osobne wartości prompt_cache_key ułatwiają przypisanie oszczędności do konkretnych klientów lub projektów.