12-godzinny cache w OpenAI API: kiedy obniża koszt długich zapytań

W przypadku agenta, który w ciągu dnia roboczego wielokrotnie korzysta z API, ponowne przesyłanie długich instrukcji wpływa na koszty. 20 października 2026 roku OpenAI dodało do Responses API możliwość wyboru 12-godzinnego czasu cache’owania: wspólne instrukcje, narzędzia i kontekst mogą pozostać dostępne do ponownego wykorzystania między zapytaniami wysyłanymi w odstępach kilku godzin. OpenAI podaje stawkę zapisu wynoszącą 2,5-krotność standardowej ceny tokenów wejściowych; jest to pełna stawka za zapis, a nie dopłata do niej. Oszczędności zależą od ponownego wykorzystania prefiksu i ceny odczytu tokenów z cache. Ogłoszenie w dzienniku zmian OpenAI jest datowane na 20 października 2026 roku.

Ten czas przechowywania sprawdza się w wieloetapowych procesach roboczych: na przykład agent może rano analizować dokumenty, a później kontynuować zadanie, korzystając z tych samych instrukcji i narzędzi. Aby zdecydować o włączeniu 12-godzinnego czasu przechowywania, warto porównać koszt zapisu z wydatkami na ponowne odczyty i uwzględnić, ile zapytań rzeczywiście ponownie wykorzystuje ten sam prefiks.

Co dokładnie jest cache’owane

Cache’owanie promptów pozwala ponownie wykorzystać zgodny początkowy fragment wejścia. Kolejne zapytania muszą zachować go bez zmian; zmienne dane warto umieszczać po części stałej. Przewodnik OpenAI dotyczący cache’owania promptów podaje, że w Responses API dla modeli GPT‑5.6 i nowszych można ustawić TTL `30m` lub `12h`. Dwanaście godzin to minimalny okres, przez który zapis powinien pozostać dostępny do odczytu z cache; nie oznacza to obietnicy usunięcia go dokładnie po 12 godzinach. Dostępność i parametry zależą od modelu.

W stałym prefiksie warto umieszczać instrukcje systemowe, definicje narzędzi i stabilne reguły przetwarzania. Bieżące pytanie, identyfikatory zadania i najnowsze dane lepiej dodawać dalej. Zmiana wcześniejszych części zapytania skraca zgodny prefiks i może ograniczyć liczbę tokenów możliwych do ponownego wykorzystania.

Jak ocenić opłacalność

Załóżmy, że stabilny prefiks zawiera P tokenów, jest wysyłany N razy, standardowa cena tokena wejściowego wynosi C, a stawka za odczyt z cache dla wybranego modelu to R. Przy jednym zapisie i trafieniu do cache we wszystkich kolejnych zapytaniach koszt obsługi tego prefiksu wyniesie w przybliżeniu 2,5PC + (N−1)PR. Bez cache jego wysyłanie kosztowałoby NPC. To oszacowanie dotyczy wyłącznie stabilnego prefiksu: osobno uwzględnij zmienną część zapytania, nietrafienia do cache i dodatkowe zapisy. Stawka za odczyt zależy od modelu; dokumentacja podaje na przykład, że dla GPT‑6.1 Sol wynosi ona 0,05 standardowej ceny tokena wejściowego, a dla GPT‑5.6 i nowszych modeli — 0,1.

W tym uproszczonym modelu cache zaczyna przynosić oszczędności na ponownie używanym prefiksie, gdy 2,5C + (N−1)R < NC. Rzeczywisty próg opłacalności zależy od liczby faktycznych trafień, ponownych zapisów i konkretnego cennika. Jeśli zapytania są rzadkie, instrukcje często się zmieniają albo prefiks za każdym razem jest unikatowy, dodatkowe koszty zapisu mogą przewyższyć oszczędności na odczycie.

Test na rzeczywistym obciążeniu

1. Ustal punkt odniesienia. Wybierz typowe zapytania, długość stabilnego prefiksu, odstępy między wywołaniami i koszty bez 12-godzinnego TTL.
2. Rozdziel część stałą i zmienną. Umieść wspólne instrukcje i schematy narzędzi na początku, a dane użytkownika i bieżące zadanie — za nimi.
3. Porównaj porównywalne zapytania. Policz zapisy, liczbę tokenów wejściowych odczytanych z cache oraz łączne koszty dla wybranego modelu i czasu przechowywania.
4. Oceń cały cykl pracy. Uwzględnij nietrafienia, ponowne zapisy po wygaśnięciu czasu przechowywania oraz sytuacje, w których zmiana prefiksu uniemożliwia jego ponowne wykorzystanie.

Metryki odpowiedzi API pomagają sprawdzić rzeczywistą liczbę tokenów wejściowych odczytanych z cache oraz zapisów; zakres raportowania zależy od modelu. Konfigurowany 12-godzinny czas przechowywania sprawdza się w przypadku dużego, stabilnego prefiksu wykorzystywanego ponownie w odstępach kilku godzin. W przypadku krótkich lub rzadko powtarzanych zapytań najpierw zmierz zapisy, trafienia i łączny koszt na własnym ruchu.