Dvanáctihodinová cache v OpenAI API: kdy ušetří a kdy prodraží opakovanou práci

Stejná dlouhá pravidla posíláte modelu ráno, po obědě a večer. Za jejich zpracování přitom nechcete zbytečně platit znovu. OpenAI 20. října 2026 přidalo volbu dvanáctihodinové prompt cache. Má pomoci tam, kde se stabilní vstup opakuje s delšími rozestupy. Delší uchování však stojí dražší zápis, takže při malém počtu opakování může účet zvýšit.

Vysvětlujeme rozdíl mezi zápisem a čtením, správný význam dvanácti hodin a vlastní cenový model pro GPT‑6.1 Sol. Údaje vycházejí z dokumentace a ceníku ověřených 25. října. Nejde o naměřenou úsporu konkrétní aplikace ani o tvrzení, že každé opakované zadání automaticky získá slevu.

Co se vlastně opakuje

Prompt cache pracuje se shodnou počáteční částí vstupu, tedy prefixem. Typicky může obsahovat stabilní instrukce, definice nástrojů a referenční podklady. Nová otázka potom následuje za nimi. Nestačí, že dvě otázky mají podobný význam nebo se týkají stejného tématu.

Když se změní něco na začátku vstupu, část za změnou už nemusí odpovídat uloženému prefixu. Prakticky proto záleží i na pořadí podkladů a na tom, kde se vkládá proměnlivý obsah. Denní datum před dlouhou společnou příručkou může mít jiný dopad než datum až za ní.

Dokumentace u GPT‑5.6 a novějších uvádí minimální způsobilou délku 1 024 tokenů a rozlišuje automatické a výslovně umístěné body ukládání. Konkrétní chování je potřeba ověřit pro použitý model a rozhraní. Krátká jednovětá otázka sama takový případ nepředstavuje.

Zápis je dražší, další čtení levnější

Pro novější podporované modely dokumentace uvádí běžnou třicetiminutovou variantu se zápisem za 1,25násobek běžného vstupu. Dvanáctihodinový zápis stojí 2,5násobek. To jsou celkové sazby zápisu, nikoli příplatky, které se ještě přičítají k běžné ceně týchž tokenů.

Čtení se účtuje samostatnou nižší sazbou. U GPT‑6.1 Sol je ve standardním režimu milion běžných vstupních tokenů za 2 USD, zápis na třicet minut za 2,50 USD, na dvanáct hodin za 5 USD a čtení za 0,10 USD. Výstupní tokeny zůstávají samostatnou položkou.

Úspora vzniká opakováním dostatečně stejného vstupu. Jestliže uložená část zůstane bez dalšího použití, zaplatili jste dražší první zpracování bez následného levného čtení. Proto se delší cache nemá zapínat podle délky dokumentu samotné, ale podle skutečného opakování.

Vlastní model pro desetitisícový prefix

Počítejme stabilní část o 10 000 tokenech ve standardním GPT‑6.1 Sol. Běžné zpracování stojí 0,02 USD. Dvanáctihodinový zápis stojí 0,05 USD a jedno plné následné čtení 0,001 USD. Předpokládáme shodný prefix, úspěšná čtení a žádný další zápis během hodnocené řady.

Pro různý počet použití vychází:

• Jedno použití: bez cache 0,02 USD, s delším zápisem 0,05 USD.
• Dvě použití: bez cache 0,04 USD, se zápisem a jedním čtením 0,051 USD.
• Tři použití: bez cache 0,06 USD, se zápisem a dvěma čteními 0,052 USD.
• Deset použití: bez cache 0,20 USD, se zápisem a devíti čteními 0,059 USD.

V tomto přesně vymezeném modelu začíná delší varianta vycházet levněji při třetím použití. Tento závěr neplatí automaticky pro celý účet. Nezahrnuje proměnlivý vstup, odpovědi, nástroje ani případ, kdy se prefix změní a musí se zapsat znovu.

Jak se malá částka projeví ve větším provozu

Pokud by se stejný desetipoužitový scénář zopakoval tisíckrát nad odpovídajícími skupinami podkladů, cena společných částí by byla 200 USD bez cache a 59 USD s jedním delším zápisem na skupinu. Při kurzu ČNB z 23. října 2026, 21,741 Kč za dolar, jde asi o 4 348 Kč proti 1 283 Kč.

Rozdíl činí přibližně 3 065 Kč. Přepočet je orientační, bez daní a bankovního kurzu. Je to součet vlastního modelu, nikoli prognóza měsíčního účtu. Reálná aplikace musí doložit počet čtení a zápisů skutečnou evidencí využití.

Pokud ve stejném období vznikne desetkrát nový prefix místo devíti čtení původního, výsledek bude jiný. Právě proto je důležité sledovat, zda se stabilní část opravdu nemění. Dlouhý vstup s častými úpravami může být pro dražší dlouhodobý zápis méně vhodný než kratší, ale pravidelně opakovaný podklad.

Kdy zůstává výhodnější třicet minut

Pokud všech deset použití proběhne za podmínek umožňujících jeden třicetiminutový zápis a devět čtení, náš prefix stojí 0,025 plus 0,009 USD, tedy 0,034 USD. Je to méně než 0,059 USD u delšího zápisu. Dvanáct hodin tedy není obecně levnější režim.

Jeho smysl se objevuje u stabilních podkladů používaných přes delší přestávky. Přesný výsledek závisí také na tom, kdy se kratší pokrytí obnovuje a zda je stále platné. Nelze bez rozboru časů předpokládat, že každý další požadavek nutně vyvolá nový krátký zápis.

Při rozhodnutí porovnejte časový průběh práce. Série navazujících kroků jednoho agenta a několik oddělených dotazů během dne jsou různé situace. Stejný počet požadavků proto nemusí znamenat stejnou optimální dobu cache.

Dvanáct hodin není termín smazání

Dokumentace mluví o minimální době platnosti pro pravidla cache, nikoli o příslibu smazat data přesně po dvanácti hodinách. Výslovně rozlišuje tuto volbu od maximálních pravidel uchování dat. Pokud firma řeší soukromí, potřebuje posoudit odpovídající datové podmínky samostatně.

Nastavení ttl nenahrazuje pravidla ochrany dat. Stejně tak samotná cache není firemní archiv ani dlouhodobá paměť, ze které lze spolehlivě obnovovat dokumenty. Její účel souvisí se znovupoužitím zpracování vstupu, ne s evidencí schválených zdrojů.

Zůstaňte u přesného slovníku i v interní dokumentaci. Věta „uchovává se dvanáct hodin“ může nesprávně působit jako maximální limit. Správný popis má uvést, k jaké vlastnosti dvanáct hodin patří a které další podmínky organizace ověřila odděleně.

Stabilní obsah dejte před proměnlivý

Vlastní praktický postup může nejprve obsahovat schválené instrukce, potom neměnnou příručku a teprve následně konkrétní dotaz. Pokud aplikace pokaždé přestaví pořadí nástrojů nebo vloží jiné údaje dopředu, podobnost lidsky čtených textů nemusí stačit ke znovupoužití.

Před úpravou zkontrolujte, co aplikace skutečně odesílá, nikoli jen to, co vidí uživatel v okně. Výsledný kontext mohou měnit i nastavení, historie a definice výstupu. Není vhodné kvůli úspoře odstranit důležité instrukce nebo připojit staré podklady, které už nejsou správné.

Cena má následovat správný pracovní postup. Pokud se schválená příručka změní, aktualizujte ji i za cenu nového zápisu. Úspora za použití staré verze není výhoda, jestliže výsledkem jsou chybné odpovědi zákazníkům nebo kolegům.

Jak poznat skutečné zásahy cache

Sledujte přehled využití a odpovídající položky čtení a zápisu. Vývojář má umět propojit spotřebu s konkrétní skupinou úloh. Samotné zachování relace neprokazuje zásah cache a subjektivně rychlejší odpověď není spolehlivým účetním důkazem.

Pro kontrolu si připravte:

• Model, režim služby a verzi používaných instrukcí.
• Délku stabilní části a umístění proměnlivého obsahu.
• Počet a časy požadavků ve sledovaném období.
• Evidovaná čtení, zápisy a běžný neznovupoužitý vstup.
• Celkovou cenu včetně výstupů a neúspěšných opakování.

Na začátku má smysl krátké omezené sledování. Pokud očekávaná čtení nevznikají, nejprve zjistěte příčinu. Zvýšení počtu požadavků bez porozumění může pouze znásobit dražší zápisy. Dobře připravené zadání potom umožní ověřit, zda úprava skutečně pomohla.

Režimy a starší nastavení nemíchejte

Volba doby v novém rozhraní má konkrétní parametr a podporované hodnoty. Dokumentace rozlišuje nastavení pro novější modely od starších parametrů. Kopírování příkladu pro jinou generaci bez kontroly může skončit chybou nebo odlišným chováním.

Podobně nepřenášejte standardní sazby do režimu Ultrafast. Jeho ceny mají vlastní sloupce. Srovnání rychlosti a příplatku najdete v článku o Ultrafast pro GPT‑6.1 Sol. Základní tokenové náklady vysvětluje profil GPT‑6.1 Sol.

Každý rozpočtový model má uvést datum ceníku, model a použité předpoklady. Jinak se později snadno srovnají dvě částky, které vznikly v různých režimech nebo při jiném počtu opakování. Správně spočítané číslo bez tohoto kontextu může vést k nesprávnému rozhodnutí.

Kdy delší cache zavést

Začněte skupinou úloh se stabilními podklady a opakováním přes delší mezery. Nejprve spočítejte současný stav, potom omezený pilot a nakonec skutečný účet. Vyhodnocení má zahrnovat i cenu prvního zápisu, nejen působivou slevu u úspěšných čtení.

Při změně modelu, instrukcí nebo rytmu provozu výsledek přezkoumejte. Nastavení, které pomáhalo při pravidelných denních dotazech, nemusí dávat smysl u jednorázových dokumentů. Delší dobu volte tam, kde podporuje doložené používání, a ostatní úlohy ponechte s vhodnějším výchozím chováním.

Co předat správci po pilotu

Výsledek zapište tak, aby se dal později přepočítat: sledované období, počet skupin podkladů, skutečné opakování a použité sazby. Pokud část úspor vznikla také zkrácením vstupu, oddělte ji od změny doby cache. Jinak bude obtížné poznat, který zásah měl největší vliv a co se stane při návratu delších podkladů.

Připojte také známé situace, kdy cache nepomáhala. Může jít o jednorázové zadání, častou aktualizaci příručky nebo proměnlivé instrukce. Tyto výjimky jsou užitečné při dalším rozšiřování provozu: chrání před plošným zapnutím nastavení, jehož přínos byl ověřen jen na úzké skupině úloh.

Nakonec určete jednoduchý způsob pravidelné kontroly účtu odpovědným člověkem. Není potřeba vytvářet novou složitou administrativu, pokud stačí existující přehled spotřeby. Důležité je zachytit změnu poměru čtení a zápisů dříve, než se nepřesný předpoklad promítne do většího rozpočtu. Dokumentace konfigurace a reálné využití mají zůstat propojené.

Časté otázky

Zaplatím zápis navíc k obyčejnému vstupu?

U popsaných sazeb jde o celkovou cenu příslušných tokenů při zápisu, ne o další násobek přičtený k jejich běžné ceně. Zbytek vstupu a výstup se hodnotí podle odpovídajících pravidel zvlášť.

Stačí poslat podobný dokument?

Cache vyžaduje odpovídající shodný prefix a další podmínky modelu. Podobný význam nebo stejné téma nestačí. Rozhodující je skutečný kontext a evidence využití.

Je dlouhá cache vhodná pro jednorázovou otázku?

V našem modelu je samotný první zápis dražší než běžný vstup. Přínos vyžaduje další použití. Bez něj nevzniká úspora z levnějšího čtení a delší varianta účet společné části zvyšuje.