Vilka modeller stödjer prompt caching?

Anthropic var först ut med explicit prompt caching för Claude (Haiku, Sonnet, Opus) — du markerar själv vilka block som ska cachas. OpenAI har automatisk prompt caching på GPT-4o, GPT-4o mini och o-serien sedan slutet av 2024 — den triggas när prefixet är minst 1 024 tokens och matchas exakt. Google Gemini och Mistral har också liknande funktioner men med olika villkor.

Hur mycket kan jag spara med prompt caching?

Spannet är 25–90 % rabatt på den cachade delen av input. Anthropic ger ca 90 % rabatt på cached input (10 % av normalt pris). OpenAI ger 50 % rabatt på cached input för GPT-4o. För en chatbot med 2 000 ord lång system-prompt och 10 000 förfrågningar per dag kan caching halvera totalkostnaden eftersom input vanligen är hälften av notan.

När är prompt caching inte värt det?

När din input är kort (under 1 000 tokens), när den ändras vid varje anrop, eller när du har låg volym (under 100 anrop per timme). Hos Anthropic har cache-write en överkostnad (1,25× normalt pris) som gör caching olönsamt om du inte återanvänder cachen flera gånger inom TTL-fönstret (5 minuter default, 1 timme opt-in).

Hur implementerar jag prompt caching i min applikation?

Hos Anthropic: lägg till `cache_control: { type: 'ephemeral' }` på de meddelandeblock du vill cacha — typiskt system-prompt och eventuell dokumentkontext. Hos OpenAI är det automatiskt — du behöver bara strukturera din prompt så att den oföränderliga delen kommer först. Mät cache hit rate via `usage.cache_read_input_tokens` (Anthropic) eller `usage.prompt_tokens_details.cached_tokens` (OpenAI) — om du ser 0 % hit rate är något fel med strukturen.

Prompt caching — så halverar du AI-kostnaden

Skriven av Christoffer Nolét, Grundare på Ncom·Publicerad 16 maj 2026·Uppdaterad 25 maj 2026

Senast uppdaterad 25 maj 2026Verifierad av Aikostnad.se redaktion

Prompt caching är den mest underutnyttjade prisoptimeringen i LLM-världen. För chatbots och RAG-applikationer kan rätt cache-strategi sänka månadsnotan med 40–60 % utan att tappa kvalitet. Den här guiden förklarar hur det fungerar, vad varje leverantör erbjuder, och när det faktiskt lönar sig.

Vad är prompt caching?

Varje gång du skickar en fråga till en LLM måste modellen processa hela inputen — system-prompt, eventuell dokumentkontext, chatthistorik och den nya användarfrågan. Den här bearbetningen dominerar input-kostnaden.

Problemet: i de flesta produktions-applikationer ändras stora delar av input inte mellan anrop. System-prompten är samma. Den uppladdade PDF:en är samma. Bara den nya användarfrågan är ny. Trots det betalar du för bearbetning av hela inputen varje gång.

Prompt caching löser det. Leverantören sparar en bearbetad version av din återanvända input i en cache och läser tillbaka den vid nästa anrop — för en bråkdel av normalt pris.

Hur det fungerar tekniskt

Tre koncept du behöver förstå:

Cache-prefix. Caching gäller den första delen av din prompt. Om du har system-prompt + dokument + användarfråga, kan system-prompt och dokument cachas — men inte användarfrågan (den ändras).
TTL (time-to-live). Cachen försvinner efter en viss tid utan användning. Hos Anthropic är default 5 minuter, opt-in för 1 timme. Hos OpenAI typiskt 5–10 minuter automatiskt.
Cache-write vs cache-read. Första gången du skickar ny input som ska cachas debiteras du extra för cache-write (ca 1,25× normalt pris hos Anthropic). Efterföljande läsningar är billigast. Du måste återanvända cachen flera gånger inom TTL-fönstret för att det ska löna sig.

Det betyder att caching inte är "gratis besparing". Det är "amortisering" — du tar en initial kostnad och får tillbaka den över flera anrop.

När caching lönar sig

Tumregler från praktiken:

✓ Stark kandidat för caching

System-prompt över 1 000 tokens (typiskt 750+ ord)
RAG-applikation med samma dokumentkontext över flera turns
Volym över 100 anrop per timme
Förutsägbara trafikmönster — kontorstid, kampanjer, etc.
Multi-turn-chatt där tidigare meddelanden återanvänds

✗ Caching lönar sig inte

Input under 500 tokens — inte tillräckligt att cacha
Varje anrop har unik kontext (inga återanvändbara prefixer)
Mindre än 5–10 anrop per minut — TTL hinner gå ut
Single-shot-applikationer (en fråga, ett svar, ny session)

Hur leverantörerna jämför sig

De stora leverantörerna hanterar caching olika — både i hur du aktiverar det och hur stor rabatt du får:

Leverantör	Aktivering	Cache-rabatt	TTL
Anthropic (Claude)	Manuell via `cache_control`	~90 % billigare	5 min default, 1 h opt-in
OpenAI (GPT-4o)	Automatisk vid 1 024+ tokens	~50 % billigare	5–10 min automatiskt
Google (Gemini)	Manuell context caching	~75 % billigare	Konfigurerbar
Mistral / DeepSeek	Varierar per modell	Varierar	—

Källor: Anthropic Prompt Caching · OpenAI Prompt Caching. Verifierade maj 2026.

Anthropic vinner på rabattens storlek — 90 % är massivt. Men du måste själv markera vad som ska cachas, vilket kräver lite mer ingenjörsarbete. OpenAI vinner på enkelhet — automatisk caching kräver inget extra från dig, men rabatten är hälften så stor.

Konkret räkneexempel

Scenario: En kundtjänst-chatbot med en system-prompt på 2 000 ord (≈2 600 tokens på svenska). Boten hanterar 10 000 förfrågningar per dag där varje användarfråga är ca 100 ord och svaret 200 ord.

Utan caching (Claude Sonnet 4.6):

System-prompt-tokens per anrop: 2 600 (input)
User-fråga-tokens per anrop: 130 (input)
Svar-tokens per anrop: 260 (output)
Per månad (22 dagar): 600 Mtok input + 57 Mtok output (avrundat)
Kostnad: 600 × $3 + 57 × $15 = $2 655/månad (~27 900 kr)

Med caching (system-prompt cachas):

Cache-read input: 572 Mtok × $0,30 (10 %) = $172
Ny input per anrop (user-fråga): 28 Mtok × $3 = $84
Output: 57 Mtok × $15 = $855
Plus initial cache-write-overhead: ~$3
Total: ~$1 114/månad (~11 700 kr)

Besparing: ~58 %, eller cirka 16 000 kr/månad i det här scenariot. Det här är inte ett ovanligt utfall — det är vad de flesta chatbot-byggare som inte använder caching betalar i onödan.

Implementation — fem tips

Strukturera prompten med statisk del först. System-prompt och dokumentkontext före användarfrågan — då kan leverantören matcha prefix:et exakt.
Cacha inte chathistoriken om den växer. Varje ny turn ändrar prefix:et och invaliderar cachen. Strategi: cacha system-prompt + dokument, lämna konversationsturer utanför.
Mät cache hit rate. Anthropic visar cache_read_input_tokens i usage-objektet. OpenAI visar cached_tokens. Om hit rate är under 50 % är något fel med strukturen.
Tänk på TTL. Om din applikation har bursttrafik följt av låg aktivitet — använd Anthropics 1-timmes-TTL. Det kostar mer per write men sparar pengar om volymen är ojämn.
Cacha inte små promtar. Under 500 tokens lönar det sig sällan. Cache-write-overheaden äter upp besparingen.

Räkna på din specifika situation

Om du redan kör en chatbot eller RAG-applikation i produktion — kolla din nuvarande månadsfaktura mot priserna i exemplet ovan. En 50-procentig sänkning är inom räckhåll om du inte har caching aktiverat idag.

För att räkna grovt på din egen volym:

Använd kalkylatorn på startsidan — räkna utan caching och estimera 40–60 % lägre med caching
Räkna specifikt på Claude — Anthropic ger bäst cache-rabatt
Komplett chatbot-kostnadsguide — där caching är ett av fyra knep

Sammanfattning

Prompt caching är gratis pengar för rätt arbetsbelastning. Om din applikation har en återanvänd system-prompt över 1 000 tokens och minst 100 anrop per timme — caching kommer halvera din input-kostnad. Anthropic ger störst rabatt (90 %), OpenAI ger enklast aktivering (automatisk), Google ligger däremellan.

Det viktigaste beslutet är inte vilken leverantör — det är att överhuvudtaget aktivera caching. De flesta produktionsapplikationer vi ser i Sverige idag har det inte aktiverat.

Priser och cache-rabatter verifierade 2026-05-15 mot officiella dokumentationer. Caching-modeller utvecklas snabbt — kontrollera alltid mot leverantörens senaste guide innan ni produktionsätter.