Nøkkelinnsikt

• Prompt caching gir opptil 90% rabatt på input-tokens med GPT-5+ og opptil 67% raskere responstid
• Bruk prompt_cache_key for å rute relaterte forespørsler til samme server. Én kunde gikk fra 60% til 87% cache hit rate
• Warp doblet sin cache hit rate ved å strukturere caching i tre nivåer: globalt, bruker og oppgave
• Det finnes ingen kvalitetsforskjell mellom svar med og uten caching. Outputen er matematisk identisk

---

Kort fortalt

OpenAIs Build Hour om prompt caching, en teknikk som lar AI-modeller huske arbeid de allerede har gjort, slik at du sparer penger og får raskere svar. Erica fra OpenAI forklarer hvordan det fungerer under panseret, viser live demoer med en AI styling-assistent, og deler fem konkrete optimaliseringstips. Siraj fra Warp (et utviklerverktøy med 700 000+ brukere) viser hvordan de mer enn doblet andelen forespørsler som traff cachen.

---

Hva er prompt caching?

Hver gang du sender en melding til en AI-modell via et programmeringsgrensesnitt (API), må modellen gjøre tungt matematisk arbeid for å forstå alt du har sendt: instruksjoner, tidligere meldinger, bilder, og så videre. Prompt caching betyr at modellen husker dette arbeidet fra forrige gang. Hvis du sender det samme innholdet på nytt, slipper den å gjøre jobben om igjen. Som Erica fra OpenAI forklarer det: vi gjenbruker beregningskraft. Når flere forespørsler deler samme prefiks (den identiske delen i starten av et prompt), hopper vi over å prosessere de tokenene og bruker kun ressurser på det nye (3:15).

Grunnregler

Erica gikk gjennom grunnleggende regler for hvordan OpenAIs prompt caching fungerer (3:43):

• Minimum 1024 tokens: promptet ditt må være på minst 1024 tokens (ca. 750 ord) før caching slår inn. Kortere prompts caches ikke
• Blokker på 128 tokens: etter de første 1024 tokenene caches innholdet i blokker på 128 tokens
• Rekkefølgen må være identisk. Modellen gjenkjenner bare arbeid den har gjort før hvis alt kommer i nøyaktig samme rekkefølge. Bytter du om på to avsnitt, må den gjøre alt på nytt
• Fungerer for alt: tekst, bilder og audio
• Skjer automatisk. Du trenger ikke endre koden din. OpenAI cacher automatisk (dette kalles implisitt caching) (4:14)
• Varer 5–10 minutter. Etter det slettes cachen fra minnet. Med extended prompt caching kan du forlenge dette til 24 timer (4:34)

---

Hva sparer du? Pris og hastighet

Pris

Når modellen gjenbruker cachet arbeid, koster tokenene mye mindre. Erica viste hvordan rabattene har økt med nyere OpenAI-modeller (5:00):

Med GPT-5 betaler du altså bare 10 % av normalprisen for den delen av promptet som allerede er cachet. For audiomodellen er det nesten gratis.

Hva betyr dette i kroner og øre?

Tenk deg at du bygger en chatbot for en nettbutikk. Den håndterer 1000 samtaler om dagen, og hver samtale sender med de samme produktbeskrivelsene, instruksjonene og FAQ-en. Det er ca. 3000 tokens som er identiske hver gang.

Det er forskjellen mellom en merkbar utgiftspost og noe som knapt synes på regningen. Og dette er bare input-tokens (det du sender til modellen). Output-tokens (det modellen sender tilbake) koster det samme uansett.

Hastighet (latens)

Latens er ventetiden fra du sender en forespørsel til du får det første ordet tilbake, ofte kalt time-to-first-token (TTFT). Erica testet 2300 forespørsler med varierende lengde (5:38) og fant:

• For korte prompts: minimal forskjell (~7 % raskere med cache)
• For lange prompts: opptil 67 % raskere med cache (6:08)

Jo lengre promptet er, desto mer tid sparer caching. Det er fordi caching gjør at ventetiden avhenger av hvor mye nytt innhold modellen skal generere, ikke hvor lang hele samtalehistorikken er.

---

Under panseret: Hva ligger egentlig i cachen?

For å forstå hvorfor tipsene senere fungerer, hjelper det å vite litt om hvordan AI-modeller faktisk prosesserer tekst. Erica bruker noen minutter på å forklare dette (6:32).

Attention — hvordan modellen «leser»

Hjertet i en moderne AI-modell er en mekanisme kalt attention (oppmerksomhet). Den lar modellen bestemme hvilke deler av teksten som er relevante for hvert enkelt ord den skal forstå.

Tenk på det slik: Når du leser setningen «hun gikk til banken for å fiske», vet du at «banken» betyr elvekanten — fordi du ser ordet «fiske» i konteksten. Erica bruker nettopp dette eksempelet for å vise hvordan modellen gjør noe lignende, men matematisk (8:59).

For hvert token lager modellen tre representasjoner (8:01):

• Query (spørsmål): «hva trenger jeg å vite om de andre ordene for å forstå meg selv?»
• Key (nøkkel): «hva representerer jeg? Er jeg et verb, et sted, en farge?»
• Value (verdi): «hvis jeg er relevant, her er informasjonen jeg kan bidra med»

Modellen sammenligner hvert tokens query med alle andre tokens' key for å finne ut hva som er relevant, og henter deretter informasjon fra de relevante tokenenes value. Denne prosessen skjer i lag. En modell kan ha 32 til 64 slike lag stablet oppå hverandre, og resultatet blir en stadig rikere forståelse av teksten.

Hva cachen faktisk lagrer

Alt dette query-key-value-arbeidet produserer store mengder tall. Uten caching må modellen gjøre hele denne jobben på nytt for hvert API-kall, selv om 90 % av teksten er identisk med forrige gang. Som Erica sier: det som lagres i cachen er bare en gigantisk haug med flyttall (desimaltall som 0,7382). Ikke ordene dine, ikke teksten, men de ferdige matematiske representasjonene som attention-prosessen har produsert (9:14).

---

Hva skjer når du sender en API-forespørsel til OpenAI?

Erica gikk gjennom den faktiske flyten som skjer bak kulissene (9:38):

---

Fem optimaliseringstips

Erica presenterte fem konkrete tips for å maksimere cache hit rate (15:05).

1. Bruk prompt cache key

Problemet: OpenAI bruker de første 256 tokenene til å bestemme hvilken server forespørselen din sendes til. Men hvis du sender tusenvis av forespørsler med samme start, må trafikken spres over flere servere for å unngå overbelastning. Da treffer de ikke hverandres cache (15:36).

Løsningen: Send med en prompt_cache_key, en valgfri parameter som hjelper OpenAI gruppere relaterte forespørsler på samme server. Tenk på det som en postadresse: uten den havner pakkene dine på tilfeldige postkontorer. Med den går alt til riktig sted. Erica sammenligner det med en shard key (en merkelapp som forteller en database hvilken server som skal lagre bestemte data) i en database (20:20).

Resultater: En kodekunde økte sin cache hit rate (andelen forespørsler som treffer cachen) fra 60 % til 87 % bare ved å legge til denne parameteren (16:23).

Strategier for å velge nøkkel:

• Per bruker: når samme bruker jobber på samme kodebase over flere samtaler
• Per samtale: når brukere har helt urelaterte oppgaver
• Gruppert: samle flere brukere under én nøkkel for å utnytte serverkapasiteten (maks 15 forespørsler/min per server)

2. Vær bevisst på context engineering

Context engineering handler om å styre hva modellen ser: fjerne irrelevant informasjon, oppsummere lange samtaler, og så videre. Men her oppstår et dilemma. Context engineering endrer innholdet, mens caching krever at innholdet forblir identisk. Erica kaller dem «inherently at odds», i utgangspunktet motsetninger (22:00).

To tilnærminger:

• Trimming: fjern eldre samtalehistorikk helt. Gjør store kutt sjeldent fremfor små kutt på hvert kall. Tenk på det som å rydde skrivebordet. Det er bedre å gjøre en skikkelig opprydding en gang i blant enn å flytte på én ting hele tiden
• Oppsummering (compaction): i stedet for å slette gammel kontekst, bruk OpenAIs nye compaction-endepunkt (responses/compact) til å lage et sammendrag som erstatter de fulle samtalene

For realtime-APIet (tale) med sin 32K-token-grense viste Erica at en retention_ratio på 0.7 (behold 70 % av konteksten, slett 30 % ved behov) kan spare 70 % på 30-minutters sesjoner (25:36), sammenlignet med å trimme litt på hvert kall.

3. Bruk Responses API med reasoning-modeller

Reasoning-modeller (resonneringsmodeller, som o3, o4-mini) tenker steg-for-steg internt før de gir et svar. De genererer skjulte «tanketokens» (modellens interne resonnering som brukeren aldri ser). Hvis du bruker det eldre Chat Completions-APIet, blir disse tanketokenene forkastet mellom samtaletrinn. Det betyr at modellen «glemmer» sin egen tankegang, og cachen brytes.

Med OpenAIs Responses API bevares tanketokenene. Erica viste at å bare bytte API kan øke cache hit rate fra 40 % til 80 %, pluss smartere svar fordi modellen beholder sin resonneringshistorikk (28:49).

4. Vurder flex processing fremfor Batch API

Hvis du prosesserer store mengder data (f.eks. bilder over natten), bruker du kanskje allerede Batch API (sende mange forespørsler samlet i stedet for én og én) for å få 50 % rabatt. Flex processing gir deg den samme rabatten, men med mer kontroll (29:16):

• Sett service_tier: "flex" på enkeltforespørsler i stedet for å sende alt som én batch
• Kombiner det med extended prompt caching og prompt cache key, noe Batch API ikke støtter

Erica testet med 10 000 forespørsler og fant 8,5 % høyere cache hit rate og 23 % lavere kostnad på input-tokens med flex (30:23).

5. Bruk allowed_tools i stedet for å endre verktøysettet

Når du bruker OpenAIs API med verktøy (function calling), er verktøydefinisjonene en del av prefikset som caches. Hvis du fjerner eller legger til et verktøy, brytes cachen (30:44).

Løsningen: definer alle verktøyene dine én gang, og bruk allowed_tools-parameteren til å styre hvilke verktøy modellen faktisk kan bruke på en gitt forespørsel. Verktøydefinisjonene forblir identiske (cachen bevares), men modellen ser bare de verktøyene du tillater.

---

Kundecase: Warp

Siraj er teknisk leder i Warp, en utviklerplattform der AI-agenter skriver og feilsøker kode for 700 000+ utviklere. Her deler han hvordan de tenker om prompt caching i praksis (35:15).

Hvordan en kode-agent fungerer

Siraj forklarer at AI-agenter i Warp jobber i løkker (37:05): brukeren gir en oppgave (f.eks. «fiks denne kompileringsfeilen»), agenten leser filer, kjører kommandoer, tenker over resultatet, og gjentar. Steg for steg. For hvert steg vokser promptet, men det meste av innholdet er identisk fra forrige steg. Det gjør kode-agenter til et perfekt bruksområde for prompt caching. Verktøy som Claude Code, der sub-agenter (mindre AI-hjelpere som startes av en hovedagent) kjører i parallelle løkker, forsterker denne effekten ytterligere.

Tre nivåer av caching

Warp strukturerer caching i tre lag, fra bredt til smalt (41:30):

Nøkkelen: Warp fjernet all dynamisk informasjon fra system promptet og la det i en separat melding etterpå. På den måten deler alle brukere den globale cachen, samtidig som hver bruker får sin egen cache på nivå to.

Gyllen regel: Aldri endre historikken

Siraj deler en viktig lærdom (40:32): hvis en bruker ombestemmer seg midt i en samtale, er det fristende å gå tilbake og endre den opprinnelige meldingen. Men det ødelegger cachen for alt som kom etterpå. Warps løsning er å legge til en ny melding på slutten som sier «brukeren har endret plan». Da bevares hele den eksisterende cachen.

Resultater

Ved å innføre en oppgave-scopet prompt cache key doblet Warp sin cache hit rate (43:41). Siraj understreker at det handler om balanse. Nøkkelen bør være stabil nok til å gi høy treffrate, men ikke så smal at den sprer forespørsler over for mange servere.

---

Ingen trade-offs, seriøst

Erica er krystallklar: det finnes ingen kvalitetsforskjell mellom svar med og uten caching. Gitt identisk input vil de matematiske representasjonene i cachen være nøyaktig de samme som om modellen beregnet dem fra bunnen av. Svarene er identiske (52:09).

Den eneste avveiningen er arkitekturmessig. Hvis du designer hele systemet kun for å maksimere caching, kan du ende opp med å gi modellen for mye irrelevant kontekst fordi du ikke tør å endre den. Det handler om å finne balansen mellom god kontekststyring og høy cache-utnyttelse.

---

Sjekkliste: Hvorfor treffer jeg ikke cachen?

Erica avsluttet med en feilsøkingsliste (33:49). Opplever du lavere cache hit rate enn forventet? Gå gjennom denne:

• Endrer du innholdet? Selv et ekstra mellomrom eller et tidsstempel i promptet bryter cachen
• Endrer du verktøysettet? Bruk allowed_tools i stedet (se tips 5)
• Har det gått for lang tid? Standard cache varer 5–10 minutter. Bruk extended prompt caching for 24 timer
• For mange forespørsler? Høyt volum sprer trafikken over flere servere. Bruk prompt cache key for å styre rutingen
• For kort prompt? Prompts under 1024 tokens caches ikke. Erica viste at selv med bare 50 % cache hit rate sparer du 33 % på tokenkostnader ved å utvide promptet over 1024-grensen (51:01)
• Feil API? Chat Completions med reasoning-modeller gir lavere cache hit. Bytt til Responses API
• Batch API med eldre modeller? Pre-GPT-5-modeller støtter ikke caching i Batch API. Prøv flex processing

Praktiske implikasjoner

Hvis du jobber alene

Start med implisitt caching. Du trenger ikke endre koden din i det hele tatt. Bare bruk GPT-5+ så får du automatisk opptil 90 % rabatt på gjentatt innhold. Hvis promptene dine er under 1024 tokens, vurder å legge til et detaljert system prompt for å komme over grensen. Selv 50 % cache hit rate sparer deg 33 % på tokenkostnader.

Hvis teamet ditt bygger produksjonsapper

Følg Warp-mønsteret: strukturer promptene i tre lag (globalt system prompt, brukerkontekst, oppgavekontekst) og bruk prompt_cache_key for å rute relaterte forespørsler til samme server. Flytt all dynamisk informasjon ut av system promptet og inn i en separat melding. Denne ene endringen kan doble cache hit raten din.

Hvis budsjettet er stramt

Kombiner prompt caching med flex processing for å få 50 % rabatt pluss cache-fordeler. Hvis du allerede bruker Batch API, test om flex processing gir lavere totalkostnad. Ericas benchmark viste 23 % lavere kostnad på input-tokens med flex sammenlignet med batch.

Test deg selv

1. Arkitekturvalg: Context engineering og caching er «inherently at odds». Hvordan ville du designet et system som balanserer begge, og når ville du prioritert det ene over det andre?
2. Kostnadsmodell: Med 90 % rabatt på cachede tokens i GPT-5+, på hvilket punkt blir det billigere å sende for mye kontekst enn å investere i smart trimming?
3. Server-routing: Prompt cache key styrer hvilken server forespørselen lander på. Hva kan gå galt hvis nøkkelen er for bred (for mange brukere per nøkkel) vs. for smal?
4. Utvikleratferd: Erica sier at caching ikke påvirker kvaliteten. Men kan det påvirke utvikleres atferd, f.eks. at de unngår å forbedre prompts fordi endringer bryter cachen?
5. Overføringsverdi: Warp strukturerer caching i tre nivåer (globalt, bruker, oppgave). Hvordan ville denne strategien sett ut for en helt annen applikasjon, f.eks. en medisinsk rådgivningstjeneste?

---

Ordliste

---

Kilder og ressurser