12-godzinny cache promptów w OpenAI API: kiedy się opłaca, a kiedy nie

20 października 2026 OpenAI dodało do Responses API możliwość wyboru 12-godzinnego cache’u promptów. Stabilne instrukcje, definicje narzędzi i wspólny kontekst zostają w cache’u co najmniej 12 godzin zamiast domyślnych 30 minut. Cena za tę wygodę: zapis kosztuje 2.5x ceny zwykłego wejścia, a odczyt tylko 0.1x (na GPT-6.1 Sol 0.05x).

Teza tego wpisu jest prosta. 12-godzinny cache nie jest ustawieniem “włącz i oszczędzaj”. To zakład, że ten sam prefiks promptu wróci co najmniej trzy razy w ciągu 12 godzin, a każde jego kolejne użycie będzie odczytem, nie nowym zapisem. Poniżej wyprowadzam wzór na próg opłacalności i przeliczam go na cenach GPT-6.1 Sol i GPT-6 Luna odczytanych ze strony cen OpenAI 22 października 2026.

W skrócie:

• Jak włączyć: prompt_cache_options.ttl: "12h" w żądaniu do Responses API albo prompt_cache_breakpoint.ttl: "12h" na pojedynczym bloku treści. Domyślnie jest "30m".
• Próg opłacalności: wersja 12h zwraca się od trzeciego żądania z tym samym prefiksem (czyli od drugiego odczytu). Mierząc inaczej: około 61-63% użyć prefiksu musi być odczytami, a reszta to zapisy.
• Kiedy 12h przegrywa: gdy prefiks wraca rzadziej niż trzy razy na 12 godzin albo gdy i tak wraca co kilkanaście minut, bo wtedy wystarcza tańszy cache 30-minutowy.
• Wszystkie liczby w przykładach to wyliczenia ilustracyjne z oficjalnego cennika, nie pomiar na prawdziwym ruchu.

Co dokładnie zmieniło się 20 października

Wpis w changelogu OpenAI API z 20 października jest krótki. Mówi, że można wybrać 12-godzinny cache w Responses API, że utrzymuje on wspólne instrukcje, narzędzia i kontekst dłużej, a zapisy w tym trybie kosztują 2.5x ceny wejścia. Szczegóły są w przewodniku po prompt cachingu.

Żeby zobaczyć, co jest nowe, trzeba odróżnić dwa światy:

Dokumentacja dodaje, że starszy parametr prompt_cache_retention nie zmienia się. Od 29 maja 2026 organizacje bez zero data retention mają domyślnie 24h, a z ZDR in_memory. Ta różnica ma znaczenie przy migracji: na starszych modelach długi cache nie miał osobnej opłaty za zapis, a na GPT-5.6 i nowszych ma.

Odpowiedź na pytanie z briefingu, jaki był poprzedni, krótszy czas życia: dla nowych modeli domyślne jest 30 minut, i to ono jest punktem odniesienia dla 12h.

Jak włączyć 12-godzinny cache w Responses API

Są dwa poziomy ustawienia. Na całe żądanie:

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "ttl": "12h" },
  "input": [ ... ]
}

I na pojedynczym punkcie podziału (breakpoint) w trybie jawnym. Poniższy układ jest skróconą wersją przykładu z dokumentacji: instrukcje developera na 12 godzin, reszta na domyślne 30 minut.

{
  "model": "gpt-6.1-sol",
  "prompt_cache_options": { "mode": "explicit", "ttl": "30m" },
  "input": [
    {
      "role": "developer",
      "content": [{
        "type": "input_text",
        "text": "...",
        "prompt_cache_breakpoint": { "mode": "explicit", "ttl": "12h" }
      }]
    },
    {
      "role": "user",
      "content": [{ "type": "input_text", "text": "..." }]
    }
  ]
}

Kilka faktów z dokumentacji, które łatwo przeoczyć:

• 12 godzin to minimum, nie termin ważności. OpenAI “może zachować wpis dłużej”. Ustawienie 12h nie zmienia też maksymalnych zasad przechowywania danych.
• Prefiks musi mieć co najmniej 1024 widoczne tokeny. Ukryta treść systemowa OpenAI się nie liczy.
• Tryb jawny daje do czterech zapisów na żądanie. Treść po ostatnim breakpoincie jest liczona jak zwykłe wejście, bez opłaty za zapis. Dzięki temu zmienny ogon promptu nie generuje kosztu zapisu.
• Nieobsługiwana wartość ttl kończy się błędem 400 invalid_request_error.
• Prewarming (prompt_cache_options.prewarm: true) zapisuje prefiks bez generowania odpowiedzi, np. przy starcie aplikacji. Zapis jest liczony po stawce wybranego czasu życia, więc 2.5x przy 12h.

Dokumentacja nazywa 12h “Responses API”. Czy ta sama opcja działa w Chat Completions, tego w dostępnych stronach nie znalazłem, więc nie zakładam, że tak.

Ceny z cennika OpenAI

Stan z 22 października 2026, strona cen OpenAI, tabela Standard dla kontekstu do 272K tokenów. Wszystkie kwoty w USD za milion tokenów.

Dla porównania GPT-6 Sol ma odczyt $0.20 (0.1x) przy tym samym zapisie 12h $5.00. GPT-6.1 Sol obniżył więc cenę odczytu o połowę, a zapisy zostały takie same. Powyżej 272K tokenów OpenAI liczy wyższą tabelę: dla Sola wejście $4.00, odczyt $0.20 i zapis 12h $10.00. Stosunki cen są te same, więc próg opłacalności poniżej się nie zmienia.

Dokumentacja podkreśla, że “cache-write pricing is not an additive fee”. Każdy token jest rozliczany po jednej stawce: zwykłej, odczytu albo zapisu. Zapis nie dokłada się do ceny wejścia, tylko ją zastępuje.

Wzór: ile odczytów zwraca koszt zapisu

Oznaczenia, wszystko w jednostkach zwykłej ceny wejścia (1x):

• W to mnożnik zapisu: 1.25 dla 30m, 2.5 dla 12h,
• r to mnożnik odczytu: 0.05 dla Sola, 0.1 dla Luny,
• n to liczba żądań z tym samym prefiksem w oknie jednego zapisu: jeden zapis i n - 1 odczytów.

Bez cache’u n żądań kosztuje n. Z cache’em kosztuje W + (n - 1) * r. Cache się opłaca, gdy:

W + (n - 1) * r  <  n
n  >  (W - r) / (1 - r)

Dla każdego wiersza wychodzi liczba, którą zaokrąglamy w górę do całkowitej liczby żądań:

Sprawdzenie na Solu dla 12h: dwa żądania kosztują 2.5 + 0.05 = 2.55x przy 2x bez cache’u, więc to strata. Trzy żądania to 2.5 + 0.1 = 2.6x przy 3x, czyli zysk. Dokumentacja OpenAI podaje analogiczny przykład dla zapisu 30m: jeden zapis i jeden odczyt to 1.35x zamiast 2x, a jeden zapis i dziewięć odczytów to 2.15x zamiast 10x (dla odczytu 0.1x).

Ta sama zasada, wyrażona jako odsetek odczytów

W prawdziwym ruchu nie wiesz z góry, ile będzie n. Wygodniej myśleć o odsetku odczytów h w tokenach prefiksu: ile z nich jest rozliczane jako odczyt, a ile jako zapis (zapisy pojawiają się po wygaśnięciu wpisu albo po zmianie prefiksu). Średni koszt jednego użycia prefiksu to (1 - h) * W + h * r. Cache się opłaca, gdy jest mniejszy od 1:

h  >  (W - 1) / (W - r)

Uwaga na nazwę. To nie jest “cache-hit rate” z dokumentacji, czyli cached_tokens / input_tokens po całym wejściu. Ten drugi współczynnik jest zaniżany przez zmienny ogon promptu. Tutaj liczy się tylko cacheowalny prefiks: cached_tokens / (cached_tokens + cache_write_tokens).

Przykład 1: ten sam prefiks, cztery wzorce ruchu

To wyliczenie ilustracyjne, nie pomiar. Prefiks 50 000 tokenów (instrukcje i definicje narzędzi), model GPT-6.1 Sol. Przy zwykłej cenie $2.00 za milion jedno użycie prefiksu kosztuje $0.10. Odczyt kosztuje $0.005, zapis 30m $0.125, zapis 12h $0.25. Kolumna “bez cache’u” oznacza tryb jawny bez breakpointów, który według dokumentacji nie tworzy zapisów. Kolumna “30m” zakłada pesymistycznie, że przerwy między żądaniami są dłuższe niż 30 minut, więc każde żądanie zapisuje prefiks od nowa.

Z tabeli wynikają trzy wnioski:

1. Przy rzadkim ruchu domyślny cache 30m może kosztować więcej niż jego brak. Każde żądanie płaci 1.25x za zapis, którego nikt potem nie odczyta. To wynika z cennika, ale zachowanie w praktyce zależy też od tego, jak długo OpenAI faktycznie trzyma wpis (dokumentacja mówi, że może dłużej niż minimum).
2. 12h wygrywa dopiero od trzeciego żądania w oknie 12 godzin. Dwa żądania to strata.
3. Przy gęstym ruchu 12h jest zbędnym wydatkiem. Kiedy prefiks i tak wraca co kilka minut, 30-minutowy zapis wystarcza i kosztuje o połowę mniej.

Ta sama arytmetyka dla GPT-6 Luna daje identyczne proporcje, tylko w kwotach około dwudziestu razy mniejszych: prefiks 50 000 tokenów kosztuje tam $0.005 zwykłego wejścia, $0.0005 odczytu i $0.0125 zapisu 12h. Przy dwunastu żądaniach co godzinę to około $0.018 z 12h wobec $0.060 bez cache’u. Na Lunie decyzja ma sens przy dużej liczbie żądań dziennie, nie przy pojedynczych.

Przykład 2: jak odsetek odczytów zmienia rachunek

Wyliczenie ilustracyjne, nie pomiar. Prefiks 100 000 tokenów na GPT-6.1 Sol z ustawionym ttl: "12h" i 1000 żądań dziennie. Bez cache’u prefiks kosztuje $0.20 za żądanie, czyli $200 dziennie. Zapis kosztuje $0.50, odczyt $0.01.

Ostatni wiersz to ostrzeżenie. Jeśli ustawisz ttl: "12h", ale prefiks zmienia się przy każdym żądaniu (znacznik czasu na początku, losowa kolejność narzędzi), każde żądanie płaci pełne 2.5x. To jest scenariusz gorszy niż wyłączenie cache’u.

Liczy się tylko część stabilna. Ogon promptu, wynik narzędzi i odpowiedź modelu mają swoje stawki, których to wyliczenie nie obejmuje. Koszt całego zadania agenta (z odczytami, zwykłym wejściem i wyjściem) liczyłem w tekstach o Kimi K3 i Gemini 4 Argon, na razie pomijając opłaty za zapis. Ten wpis pokazuje, kiedy te opłaty zaczynają mieć znaczenie.

Kiedy 12h się opłaca, a kiedy nie

Opłaca się, gdy:

• duży stabilny prefiks (długie instrukcje, regulamin, dokumentacja, zestaw narzędzi) wraca wiele razy dziennie, ale z przerwami dłuższymi niż 30 minut. Przykłady: wewnętrzny asystent firmowy, bot wsparcia z nieregularnym ruchem, nocne zadania wsadowe z tym samym promptem systemowym,
• masz wiele krótkich sesji różnych użytkowników, które zaczynają od tych samych instrukcji.

Nie opłaca się, gdy:

• prefiks pojawia się dwa razy dziennie albo rzadziej,
• ruch jest gęsty (kolejne żądanie zawsze w ciągu 30 minut), bo domyślny cache robi to samo taniej,
• prefiks jest niestabilny: zmienia się początek promptu, kolejność narzędzi, schemat odpowiedzi albo poziom reasoning.effort,
• prefiks jest krótszy niż 1024 widoczne tokeny, bo w ogóle się nie zapisze.

Rozsądny układ dla większości aplikacji: instrukcje i narzędzia z ttl: "12h" na breakpoincie, historia rozmowy i zmienny kontekst na domyślnych 30 minut. Dokumentacja radzi dokładnie to: dłuższe życie dla wspólnego materiału, krótsze dla kontekstu sesji.

W agentach, które pracują długo i bez przerw, ważniejsze od ustawienia TTL jest to, żeby nie niszczyć prefiksu w trakcie pracy. Dokumentacja wprost wymienia kompakcję, streszczanie i obcinanie historii jako operacje, które mogą zresetować ponowne użycie cache’u. Podobny problem, tylko po stronie Claude Code, opisałem przy kompakcji bezczynnych sesji w wersji 2.1.299: tam kompakcja startuje przed wygaśnięciem godzinnego cache’u, żeby wznowiona sesja nie wczytywała całego kontekstu od zera.

Co wkładać do stabilnego prefiksu, a co go psuje

Według przewodnika OpenAI cache wymaga, by cały wyrenderowany prefiks zgadzał się do breakpointu. Praktycznie:

Do stabilnego początku:

1. Instrukcje developera i wspólny materiał referencyjny.
2. Definicje narzędzi z niezmienną kolejnością, nazwami, opisami i schematami.
3. Stałe ustawienia: model, parallel_tool_calls, text.format, text.verbosity.

Co psuje prefiks:

• Zmienna treść przed stałą. Znacznik czasu, nazwa użytkownika albo identyfikator sesji na początku promptu kasują reużycie wszystkiego, co po nim. Zmienne wartości przenieś na koniec.
• Zmiana narzędzi. Dodanie, usunięcie albo przestawienie narzędzia zmienia prefiks. Dokumentacja zaleca aktualizacje append-only i opcje takie jak allowed_tools czy tool_choice: "none" zamiast przebudowy listy.
• Zmiana reasoning.effort w żądaniu. Na modelach GPT-6 użyj elementu configuration_update w historii. Szerzej o tym pisałem w tekście o GPT-6.1 Sol.
• Przepisywanie wcześniejszych tur. Dopisuj nowe wiadomości, nie edytuj starych.
• Rozszerzenie wiadomości. Zmiana “Treść A” na “Treść A + Treść B” w tej samej wiadomości nie wykorzysta wcześniejszego punktu bez własnego breakpointu.
• Zmiana trybu. Żądanie w trybie wyłącznie jawnym nie użyje prefiksów zapisanych wcześniej w trybie niejawnym, jeśli breakpointy się nie zgadzają.
• Ruch przekraczający około 15 żądań na minutę na klucz. Cache żyje na pojedynczych maszynach, a nadmiar ruchu może trafić na inne, gdzie prefiksu nie ma. prompt_cache_key wpływa na routing, ale według dokumentacji nie przypina żądań do maszyny i nie gwarantuje trafienia.
• Granice organizacji i regionów. Cache nie jest współdzielony między organizacjami ani między regionalnymi granicami przetwarzania.

Odczytane tokeny nadal liczą się do limitów tokenów na minutę. Cache obniża koszt, nie limit.

Jak mierzyć odsetek odczytów

Dokumentacja wskazuje pola w response.usage:

• usage.input_tokens: wszystkie tokeny wejścia,
• usage.input_tokens_details.cached_tokens: tokeny rozliczone jako odczyt (bez tokenów liczonych jako zapis),
• usage.input_tokens_details.cache_write_tokens: tokeny rozliczone jako zapis,
• cache_write_tokens_details.ttl_30m_tokens i ttl_12h_tokens: podział zapisów na czas życia, sumujący się do cache_write_tokens.

Zwykłe wejście to input_tokens - cached_tokens - cache_write_tokens. Dokumentacja pokazuje też wzór na koszt, który można zaimplementować w kilku linijkach:

def input_cost_usd(usage: dict, price_per_m: float, read_per_m: float) -> float:
    d = usage["input_tokens_details"]
    cached = d["cached_tokens"]
    w30 = d["cache_write_tokens_details"]["ttl_30m_tokens"]
    w12 = d["cache_write_tokens_details"]["ttl_12h_tokens"]
    ordinary = usage["input_tokens"] - cached - w30 - w12
    tokens_cost = ordinary * price_per_m + cached * read_per_m + w30 * 1.25 * price_per_m + w12 * 2.5 * price_per_m
    return tokens_cost / 1_000_000

Pole cache_write_tokens_details występuje według dokumentacji tylko w modelach Responses, które obsługują prompt_cache_options. Przykład z oficjalnej strony: 1000 tokenów zwykłych, 4000 odczytanych, 3000 zapisanych na 30m i 4000 zapisanych na 12h przy $1.00 za milion wejścia i $0.10 za milion odczytu daje $0.01515. Ta sama liczba wychodzi z funkcji powyżej.

Poza własnym liczeniem są dwa narzędzia od OpenAI. Według changelogu Prompt Caching dashboard (od 20 sierpnia 2026) pokazuje odsetek trafień, odczyty na zapis i podział tokenów, a Prompt Cache Diagnostics (od 8 września 2026 w ogólnej dostępności w Responses API dla GPT-5.6 i nowszych) porównuje ponowne użycie cache’u z wcześniejszymi odpowiedziami i wyjaśnia pudła. Przewodnik nie opisuje szczegółów włączania diagnostyki, więc tego nie rozwijam.

Mierzenie tokenów to inny poziom niż mierzenie, czy agenci dowożą wynik. Do tego drugiego zobacz wpis o mierzeniu pracy agentów AI. Jeśli budujesz agenta na Agents API i harnessie Codexa, sprawdź w jego dokumentacji, czy prompt_cache_options jest tam dostępne. Tego nie weryfikowałem.

Jak to wygląda u konkurencji

Stan z 22 października 2026, strony cen Anthropic i Google oraz ich dokumentacja cachingu. Kwoty w USD za milion tokenów.

Wnioski:

• Anthropic ma krótsze długie okno (1 godzina zamiast 12), ale tańszy zapis ($4.00 zamiast $5.00 przy tej samej cenie bazowej). Próg opłacalności wychodzi podobny: według strony Anthropic 1-godzinny cache zwraca się po dwóch odczytach. Kiedy odstępy między żądaniami to 2-6 godzin, 1-godzinny cache Claude’a nie wystarczy, a 12-godzinny OpenAI tak.
• Gemini 4 Argon nie ma tego dylematu, bo ma wyłącznie cache niejawny. Strona cen nie podaje dla Argona osobnej opłaty za zapis ani za przechowywanie. Za to cena odczytu podwaja się 1 grudnia, o czym szerzej w tekście o Gemini 4 Argon.
• Cena odczytu Sonneta 5.5. Strona cen Anthropic z dnia odczytu podaje $0.10 za milion (0.05x), a nie $0.20, jak w moich wcześniejszych tekstach, np. w porównaniu GPT-6.1 Sol z Claude Sonnet 5.5. Nie wiem, kiedy to się zmieniło. W tym wpisie używam bieżącej strony producenta.

Jeśli porównujesz dostawców, zapis i odczyt to dopiero połowa rachunku. Całościowy koszt zadania zależy jeszcze od liczby tokenów, kroków i ceny wyjścia, o czym pisałem w porównaniu Opusa 5.5 z GPT-6 Sol i Luną.

Czego nie udało się potwierdzić

• Czy 12-godzinny odczyt przedłuża okno 12h. Dokumentacja opisuje tylko, że odczyt 30m odświeża 30-minutowe pokrycie, ale nie restartuje zegara 12h. O odczycie w trybie 12h nie mówi nic.
• Czy 12h działa w Chat Completions. Dokumentacja wspomina wyłącznie o Responses API.
• Czy da się całkiem wyłączyć cache. Strona tego nie opisuje. Wiadomo tylko, że tryb jawny bez breakpointów nie tworzy zapisów.
• Jaki jest domyślny tryb (niejawny czy jawny). Dokumentacja wprost tego nie rozstrzyga.
• Cena promocyjna. Strona cen wspomina o cenie promocyjnej obowiązującej co najmniej do 21 listopada 2026, ale nie ustaliłem jednoznacznie, którego modelu dotyczy. Wszystkie ceny w tekście pochodzą z tabeli Standard i mogą się zmienić.
• Rzeczywisty odsetek odczytów w Twojej aplikacji. Przykłady wyżej są wyliczeniami z cennika. Prawdziwy wynik zależy od routingu, ruchu i tego, jak stabilny jest prefiks.

FAQ

Ile kosztuje 12-godzinny cache w OpenAI API?

Zapis kosztuje 2.5x zwykłej ceny wejścia: $5.00 za milion tokenów na GPT-6.1 Sol i $0.25 na GPT-6 Luna. Odczyt kosztuje 0.05x ceny wejścia na GPT-6.1 Sol ($0.10 za milion) i 0.1x na pozostałych modelach, niezależnie od wybranego czasu życia. Ceny z 22 października 2026.

Od ilu żądań 12-godzinny cache się opłaca?

Od trzeciego żądania z tym samym prefiksem w oknie 12 godzin, czyli od drugiego odczytu. Wzór: n > (W - r) / (1 - r), gdzie W to mnożnik zapisu (2.5), a r mnożnik odczytu (0.05 lub 0.1). Dla Sola wychodzi 2.58, dla Luny 2.67.

Jak włączyć 12-godzinny cache w Responses API?

Ustaw prompt_cache_options.ttl na "12h" w żądaniu albo prompt_cache_breakpoint.ttl na "12h" na wybranym bloku treści w trybie jawnym. Domyślna wartość to "30m". Starszy parametr prompt_cache_retention jest osobny i dotyczy starszych modeli.

Czy 12 godzin to gwarancja?

Nie. To minimalny czas życia wpisu, a OpenAI może go zachować dłużej. Dokumentacja zaznacza, że minimum wyznacza, kiedy obowiązuje cena odczytu, ale nie gwarantuje skrócenia opóźnienia ani tego, że zapisane dane zostaną użyte ponownie.

Jak sprawdzić, czy cache działa?

Czytaj usage.input_tokens_details.cached_tokens i cache_write_tokens z każdej odpowiedzi, a odsetek odczytów licz jako cached_tokens / (cached_tokens + cache_write_tokens). Pomocne są też Prompt Caching dashboard i Prompt Cache Diagnostics w panelu OpenAI.

Czy cache zmienia odpowiedzi modelu?

Według dokumentacji nie. Cache ponownie wykorzystuje stan KV wspólnego prefiksu i nie zmienia generowanego wyniku.

Źródła pierwotne

• OpenAI: Prompt caching (czas życia, ceny zapisu i odczytu, pola usage, praktyki optymalizacji)
• OpenAI: Pricing (tabela cen GPT-6.1 Sol i GPT-6 Luna, odczyt 22.10.2026)
• OpenAI: API changelog (wpis z 20 października 2026, dashboard z 20 sierpnia, diagnostyka z 8 września)
• Anthropic: Pricing i Prompt caching
• Google: Gemini API pricing