12hodinová mezipaměť v OpenAI API: kdy snižuje náklady na dlouhé požadavky

U agenta, který během pracovního dne několikrát volá API, ovlivňuje cenu opakované odesílání dlouhých instrukcí. OpenAI 20. října 2026 přidala do Responses API možnost zvolit 12hodinovou dobu ukládání do mezipaměti: společné instrukce, nástroje a kontext mohou zůstat použitelné pro opakované využití mezi požadavky, které od sebe dělí několik hodin. OpenAI uvádí sazbu za zápis ve výši 2,5násobku běžné ceny vstupních tokenů; jde o celou sazbu za zápis, nikoli o příplatek k ní. Úspory závisí na opakovaném využití prefixu a ceně čtení tokenů z mezipaměti. Oznámení v protokolu změn OpenAI je datováno 20. října 2026.

Taková doba uchovávání je určena pro vícekrokové pracovní postupy: agent může například ráno analyzovat dokumenty a později pokračovat v úkolu se stejnými instrukcemi a nástroji. Při rozhodování, zda 12hodinovou dobu zapnout, je důležité porovnat cenu zápisu s náklady na opakovaná čtení a zohlednit, kolik požadavků skutečně znovu využívá stejný prefix.

Co přesně se ukládá do mezipaměti

Ukládání promptů do mezipaměti znovu využívá shodnou počáteční část vstupu. Následující požadavky ji musí zachovat beze změny; proměnlivá data je vhodné umístit až za ni. Průvodce OpenAI ukládáním promptů do mezipaměti uvádí, že v Responses API lze pro modely GPT‑5.6 a novější nastavit TTL `30m` nebo `12h`. Dvanáct hodin je minimální doba, po kterou má záznam zůstat dostupný pro čtení z mezipaměti; neznamená to, že bude přesně po 12 hodinách odstraněn. Dostupnost a nastavení se liší podle modelu.

Do stálého prefixu se hodí systémové instrukce, definice nástrojů a stabilní pravidla zpracování. Aktuální otázku, identifikátory úloh a čerstvá data je lepší přidat až za něj. Pokud se změní dřívější části požadavku, shodný prefix se zkrátí a může klesnout počet opakovaně využitých tokenů.

Jak odhadnout návratnost

Označme stabilní prefix o P tokenech, který se odešle Nkrát; cenu běžného vstupního tokenu označme C a sazbu za čtení z mezipaměti pro zvolený model R. Pokud proběhne jeden zápis a všechny následující požadavky se trefí do mezipaměti, náklady na tento prefix budou přibližně 2,5PC + (N−1)PR. Bez mezipaměti by jeho odeslání stálo NPC. Tento odhad se týká pouze stabilního prefixu: proměnlivou část požadavku, neúspěšné zásahy do mezipaměti a další zápisy počítejte zvlášť. Sazba za čtení závisí na modelu; dokumentace například uvádí pro GPT‑6.1 Sol hodnotu 0,05násobku běžné ceny vstupního tokenu a pro GPT‑5.6 a novější modely 0,1násobek.

V tomto zjednodušeném modelu začne mezipaměť u opakovaně využívaného prefixu šetřit, když platí 2,5C + (N−1)R < NC. Skutečný bod návratnosti závisí na reálném počtu zásahů, opakovaných zápisech a konkrétním tarifu. Pokud jsou požadavky vzácné, instrukce se často mění nebo je prefix pokaždé jedinečný, dodatečné náklady na zápis mohou převážit úspory za čtení.

Ověření na vlastním provozu

1. Stanovte výchozí scénář. Vezměte typické požadavky, délku stabilního prefixu, intervaly mezi voláními a náklady bez 12hodinového TTL.
2. Oddělte stálé a proměnlivé části. Společné instrukce a schémata nástrojů ponechte na začátku, uživatelská data a aktuální úkol umístěte za ně.
3. Porovnejte srovnatelné požadavky. Pro zvolený model a dobu uchovávání spočítejte zápisy, objem vstupních tokenů čtených z mezipaměti a celkové náklady.
4. Vyhodnoťte celý pracovní cyklus. Zohledněte neúspěšné zásahy, opakované zápisy po vypršení doby uchovávání i případy, kdy změna prefixu brání jeho opakovanému využití.

Metriky odpovědi API pomáhají ověřit skutečný objem vstupních tokenů čtených z mezipaměti a zápisů; vykazované údaje se liší podle modelu. Nastavitelná 12hodinová doba se hodí pro dlouhý stabilní prefix, který se opakovaně využívá v několikahodinových intervalech. U krátkých nebo zřídka opakovaných požadavků nejprve změřte zápisy, zásahy do mezipaměti a celkové náklady na vlastním provozu.