12-timers hurtigbuffer i OpenAI API: Når den reduserer kostnadene ved lange forespørsler

For en agent som bruker et API flere ganger i løpet av en arbeidsdag, påvirker gjentatt overføring av lange instruksjoner kostnadene. 20. oktober 2026 la OpenAI til muligheten til å velge en hurtigbufferperiode på 12 timer i Responses API: felles instruksjoner, verktøy og kontekst kan fortsatt brukes på nytt mellom forespørsler som kommer med flere timers mellomrom. OpenAI oppgir en skrivepris som er 2,5 ganger den vanlige prisen for inngående tokener; dette er den totale skriveprisen, ikke et tillegg oppå den. Besparelsen avhenger av om prefikset brukes på nytt, og av prisen for å lese bufrede tokener. Kunngjøringen i OpenAIs endringslogg er datert 20. oktober 2026.

En slik periode er beregnet på arbeidsflyter med flere trinn: En agent kan for eksempel analysere dokumenter om morgenen og fortsette senere med de samme instruksjonene og verktøyene. Når du vurderer om du skal aktivere 12-timersperioden, bør du sammenligne skrivekostnaden med kostnadene ved gjentatte lesinger og ta hensyn til hvor mange forespørsler som faktisk bruker det samme prefikset på nytt.

Hva bufres?

Bufring av prompter gjenbruker et samsvarende innledende segment av inndataene. Senere forespørsler må beholde dette segmentet uendret; plasser data som endres etter den faste delen. I OpenAIs veiledning om hurtigbufring av prompter står det at du kan angi TTL-en `30m` eller `12h` i Responses API for GPT‑5.6 og nyere modeller. Tolv timer er den minste perioden en oppføring skal være tilgjengelig for bufret lesing; det er ikke et løfte om at den slettes nøyaktig etter 12 timer. Tilgjengelighet og innstillinger avhenger av modellen.

Systeminstruksjoner, definisjoner av verktøy og stabile behandlingsregler egner seg godt i et fast prefiks. Det gjeldende spørsmålet, oppgave-ID-er og ferske data bør legges til lenger bak. Hvis du endrer de tidlige delene av forespørselen, blir det samsvarende prefikset kortere, og antallet tokener som kan gjenbrukes, kan bli redusert.

Slik beregner du lønnsomheten

La det stabile prefikset inneholde P tokener, sendes N ganger, ha en vanlig pris per inngående token på C, og la prisen for bufret lesing for den valgte modellen være R. Med én skriving og treff i hurtigbufferen for alle påfølgende forespørsler blir kostnaden for prefikset omtrent 2,5PC + (N−1)PR. Uten hurtigbufring ville overføringen kostet NPC. Dette anslaget gjelder bare det stabile prefikset: Ta hensyn til den delen av forespørselen som endres, bom i hurtigbufferen og ekstra skrivinger separat. Leseprisen avhenger av modellen; dokumentasjonen oppgir for eksempel 0,05 ganger den vanlige prisen for inngående tokener for GPT‑6.1 Sol, og 0,1 for GPT‑5.6 og nyere modeller.

I denne forenklede modellen begynner hurtigbufring å spare penger på det gjenbrukte prefikset når 2,5C + (N−1)R < NC. Det faktiske lønnsomhetspunktet avhenger av reelle treff, gjentatte skrivinger og den konkrete prisplanen. Hvis forespørslene er sjeldne, instruksjonene endres ofte eller prefikset er unikt hver gang, kan de ekstra skrivekostnadene overstige besparelsen ved lesing.

Testing med arbeidsbelastningen din

1. Fastsett et utgangspunkt. Bruk typiske forespørsler, lengden på det stabile prefikset, intervallene mellom kallene og kostnadene uten 12-timers TTL.
2. Skill mellom fast og variabelt innhold. La felles instruksjoner og verktøyskjemaer stå først, og plasser brukerdata og den aktuelle oppgaven etter dem.
3. Sammenlign tilsvarende forespørsler. Beregn antall skrivinger, mengden bufrede inngående tokener og de samlede kostnadene for den valgte modellen og lagringstiden.
4. Vurder hele arbeidsflyten. Ta med bom i hurtigbufferen, nye skrivinger etter at perioden utløper, og tilfeller der endringer i prefikset hindrer gjenbruk.

Måleverdier fra API-svarene kan brukes til å kontrollere den faktiske mengden bufrede inngående tokener og skrivinger; hvilke opplysninger som rapporteres, avhenger av modellen. En konfigurerbar periode på 12 timer passer for et stort, stabilt prefiks som brukes på nytt med flere timers mellomrom. For korte forespørsler eller forespørsler som sjelden gjentas, bør du først måle skrivinger, treff og totalkostnad med din egen trafikk.