Michael JohnsonFör en agent som anropar API:t flera gånger under en arbetsdag påverkar det kostnaden att skicka långa instruktioner på nytt. Den 20 oktober 2026 lade OpenAI till ett val av 12 timmars cachetid i Responses API: gemensamma instruktioner, verktyg och kontext kan förbli tillgängliga för återanvändning mellan förfrågningar med flera timmars mellanrum. OpenAI anger ett skrivpris som är 2,5 gånger det vanliga priset för inmatningstoken; det är hela skrivpriset, inte ett tillägg ovanpå det. Besparingen beror på hur ofta prefixet återanvänds och på priset för att läsa cachade token. OpenAI:s tillkännagivande i ändringsloggen är daterat den 20 oktober 2026.
Den här tidsgränsen är avsedd för arbetsflöden i flera steg: en agent kan till exempel analysera dokument på morgonen och fortsätta senare med samma instruktioner och verktyg. När du avgör om du ska aktivera 12-timmarsperioden är det viktigt att jämföra skrivkostnaden med kostnaden för upprepade läsningar och ta hänsyn till hur många förfrågningar som faktiskt återanvänder samma prefix.
Vad som cachas
Promptcachning återanvänder en identisk inledande del av indata. Efterföljande förfrågningar måste behålla den oförändrad; placera därför data som varierar efter den fasta delen. I OpenAI:s guide till promptcachning anges att du kan ställa in TTL till `30m` eller `12h` i Responses API för GPT‑5.6 och senare modeller. Tolv timmar är den minsta tid som en post ska förbli tillgänglig för cachad läsning; det innebär inte ett löfte om att den raderas exakt efter 12 timmar. Tillgänglighet och parametrar varierar beroende på modell.
Systeminstruktioner, verktygsdefinitioner och stabila bearbetningsregler passar bra i ett permanent prefix. Den aktuella frågan, uppgifts-ID:n och färska data bör läggas till längre fram. Om du ändrar tidiga delar av förfrågan blir det matchande prefixet kortare och antalet token som kan återanvändas kan minska.
Så bedömer du lönsamheten
Anta att det stabila prefixet innehåller P token, skickas N gånger, att priset för en vanlig inmatningstoken är C och att priset för cachad läsning för den valda modellen är R. Med en skrivning och cacheträff för alla efterföljande förfrågningar blir kostnaden för prefixet ungefär 2,5PC + (N−1)PR. Utan cache skulle det kosta NPC att skicka det. Beräkningen gäller bara det stabila prefixet: räkna separat med den föränderliga delen av förfrågan, cachemissar och ytterligare skrivningar. Läspriset varierar mellan modeller; dokumentationen anger exempelvis 0,05 av det vanliga priset för inmatningstoken för GPT‑6.1 Sol och 0,1 för GPT‑5.6 och senare modeller.
I den här förenklade modellen börjar cachen spara pengar på det återanvända prefixet när 2,5C + (N−1)R < NC. Den faktiska lönsamhetsgränsen beror på verkliga cacheträffar, upprepade skrivningar och den specifika prisplanen. Om förfrågningarna är sällsynta, instruktionerna ofta ändras eller prefixet är unikt varje gång kan de extra skrivkostnaderna överstiga besparingarna på läsning.
Testa med din arbetsbelastning
- Fastställ ett utgångsläge. Välj typiska förfrågningar, längden på det stabila prefixet, intervallen mellan anropen och kostnaden utan 12 timmars TTL.
- Skilj det fasta från det föränderliga. Behåll gemensamma instruktioner och verktygsscheman i början och placera användardata och den aktuella uppgiften efter dem.
- Jämför likvärdiga förfrågningar. Räkna skrivningar, mängden cachade inmatningstoken och den totala kostnaden för den valda modellen och lagringstiden.
- Utvärdera hela arbetsflödet. Ta hänsyn till cachemissar, upprepade skrivningar efter att tiden löpt ut och fall där ändringar i prefixet hindrar återanvändning.
API-svarets mätvärden hjälper dig att kontrollera den faktiska mängden cachade inmatningstoken och skrivningar; vilka uppgifter som rapporteras beror på modellen. En konfigurerbar period på 12 timmar passar ett stabilt, stort prefix som återanvänds med flera timmars mellanrum. För korta eller sällan upprepade förfrågningar bör du först mäta skrivningar, cacheträffar och totalkostnad för din egen trafik.