Claude Haiku 5.5 Prompt Caching: 12 Steg [2026]

Claude Haiku 5.5 landade den 7 oktober 2026 och blev därmed nyare än både Claude Sonnet 5.5 och Claude Opus 5.5, bara dagar efter att Anthropic sänkte priset på modellen med 75 procent. Modellen kör på ett kontextfönster med 1 miljon token och kostar 0,10 dollar per miljon indata-token och 0,50 dollar per miljon utdata-token för prompter upp till 100 000 token. Det låter redan billigt, men de flesta team som bygger AI-appar i produktion missar ett verktyg som kan sänka notan ytterligare: prompt caching. I den här guiden bygger du ett komplett projekt i Python som cachar systemprompter, långa dokument och verktygsdefinitioner mot Claude API, mäter exakt hur mycket du sparar och undviker de fallgropar som får caching att sluta fungera i tysthet.

Vad är prompt caching i Claude API och varför spelar det roll just nu

Prompt caching löser ett specifikt problem. Varje gång du skickar en förfrågan till Claude API betalar du för hela indatan, inklusive systemprompt, exempel och bakgrundsdokument som sällan ändras mellan anrop. Utan caching upprepar du den kostnaden om och om igen, även när 90 procent av texten är identisk från förra anropet. Anthropics dokumentation beskriver mekaniken tydligt: cachade token som läses tillbaka kostar generellt bara en tiondel av det vanliga indatapriset, en rabatt på 90 procent. Vissa nyare modeller får en ännu djupare rabatt på delar av sin trafik, men 90 procent är tumregeln du kan planera din budget efter.

Priset för att skriva till cachen är högre än grundpriset, inte lägre. En cache med 5 minuters livstid kostar 1,25 gånger grundpriset att skriva, alltså 25 procent mer än en vanlig token. Vill du hålla cachen vid liv i en timme istället betalar du 2 gånger grundpriset vid skrivning, en premie på 100 procent. Det är ett medvetet val från Anthropic: du betalar extra för att spara tid och pengar på alla efterföljande anrop som träffar samma cache. Minsta cachebara promptlängd ligger på 512 token för flera av dagens modeller, vilket betyder att korta systemprompter inte går att cacha över huvud taget.

Mekaniskt fungerar cachen som ett prefix-träd snarare än en enkel nyckel-värde-lagring. Claude API hashar innehållet i blocket fram till och med cache_control-markeringen och sparar resultatet på serversidan under TTL-fönstret. Nästa anrop som skickar exakt samma prefix, byte för byte, får en träff. Lägger du till text efter markeringen men låter prefixet vara orört, bevaras träffen för den delen även om resten av anropet är nytt. Det är precis den egenskapen som gör flervändade konversationer användbara att cacha, eftersom varje ny tur bara lägger till i slutet utan att röra det som redan skrivits.

Oktober 2026 är ett bra tillfälle att bygga om sina integrationer. Utöver Claude Haiku 5.5 har Google gett allmän tillgång till Gemini 4 Argon den 13 oktober, Mistral har släppt Large 4 i förhandsgranskning den 6 oktober och DeepSeek V4.1 Flash kom redan den 10 september med öppna vikter under MIT-licens, enligt DigitalApplied. Alla fyra modeller konkurrerar om samma sak: lägre kostnad per token och längre kontextfönster. Den som lär sig cachea rätt vinner oavsett vilken leverantör som vinner benchmarkracet denna månad.

Modell	Lanserad	Kontextfönster	Öppna vikter
Claude Haiku 5.5	7 oktober 2026	1 miljon token	Nej
Gemini 4 Argon	13 oktober 2026 (allmän tillgång)	1 miljon utdata-token	Nej
Mistral Large 4	6 oktober 2026 (förhandsgranskning)	Cirka 524 000–1 miljon token	Planerad senare i oktober
DeepSeek V4.1 Flash	10 september 2026	1 miljon token	Ja, MIT-licens

Tabellen visar varför oktober 2026 känns som ett vattenskifte snarare än en vanlig uppdateringsmånad. Tre stora leverantörer har släppt eller breddat tillgången till miljontal-kontext inom en och samma vecka, enligt LLM Gateways tidslinje för 2026. DeepSeek V4.1 Flash sticker ut genom att dela ut vikterna fritt, vilket gör den till ett naturligt jämförelseobjekt när du senare i guiden väger kostnaden för caching mot kostnaden för att självvärd en öppen modell.

Förkunskaper och verktyg du behöver innan du börjar

Du behöver inte vara AI-expert för den här guiden, men ett par saker måste finnas på plats innan steg 1. Har du aldrig anropat Claude API tidigare kan det vara värt att först läsa vår grundläggande genomgång av Claude API, eftersom den här guiden utgår från att du redan kan skicka ett enkelt meddelande till modellen. Sätt av 60 minuter för hela genomgången, inklusive testning.

Python 3.11 eller senare installerat lokalt eller i en container
Ett Anthropic-konto med fakturering aktiverad på platform.claude.com
Anthropics officiella Python-SDK, senaste versionen, installeras med pip
En textredigerare eller IDE, till exempel VS Code
Grundläggande kunskap om REST-API:er och JSON
Ett terminalfönster med miljövariabler (bash, zsh eller PowerShell)
Valfritt: Node.js 20 LTS eller senare om du vill bygga webbgränssnittet i steg 11 med Express istället för Flask

Kontrollera modellnamnet du tänker använda direkt i Anthropics dokumentation innan du skriver kod. API-identifierare för nya modeller ändras ibland under de första veckorna efter lansering, så behandla modellsträngen i exemplen nedan som en platshållare och verifiera den exakta identifieraren i ditt eget konto innan du kör mot produktion.

Den här guiden passar bäst för tre typer av projekt. Den första är en kundtjänstbot eller intern supportassistent med en lång, återanvändbar systemprompt som sällan ändras under dagen. Den andra är ett dokumentgranskningsverktyg där en jurist, ekonom eller handläggare ställer flera frågor i rad mot samma underlag, till exempel ett avtal eller en utredning. Den tredje är en agent med ett stort verktygsbibliotek som anropas upprepade gånger i en loop, där samma funktionsscheman annars skulle skickas om och om igen helt i onödan. Om din app bara gör ett enstaka anrop per användare utan upprepning finns det fortfarande lärdomar att hämta här, men besparingen blir mindre dramatisk.

Steg 1 och 2: Skapa API-nyckel och installera SDK

Logga in på Claude-konsolen, gå till nyckelhantering och skapa en ny API-nyckel. Spara den direkt i en miljövariabel istället för att klistra in den i koden. Det är det vanligaste säkerhetsmisstaget nya utvecklare gör, och det är enkelt att undvika.

# Terminal: skapa en virtuell miljö och installera SDK
python3 -m venv .venv
source .venv/bin/activate
pip install anthropic python-dotenv

# Spara nyckeln i en lokal .env-fil (lägg aldrig denna i git)
echo "ANTHROPIC_API_KEY=din-nyckel-har" > .env
echo ".env" >> .gitignore

Testa installationen med ett minimalt skript innan du bygger vidare. Om det här anropet misslyckas är felet nästan alltid en felaktig eller saknad API-nyckel, inte något i caching-logiken du ska bygga senare.

import os
from dotenv import load_dotenv
from anthropic import Anthropic

load_dotenv()
client = Anthropic(api_key=os.environ["ANTHROPIC_API_KEY"])

response = client.messages.create(
    model="claude-haiku-5-5",  # verifiera exakt modell-id i din konsol
    max_tokens=100,
    messages=[{"role": "user", "content": "Svara bara med ordet redo."}],
)
print(response.content[0].text)

Steg 3 och 4: Bygg grundstrukturen och skriv din första cachade systemprompt

Caching aktiveras per textblock, inte per hela anropet. Du lägger till en cache_control-markering på det block du vill spara. Den vanligaste startpunkten är systemprompten, eftersom den ofta är lång, statisk och återanvänds i varje anrop till en given assistent. Skapa en fil som heter app.py och bygg en kundtjänstbot för ett svenskt företag som exempel genom hela guiden.

SYSTEM_PROMPT = """Du är en kundtjänstassistent for Nordkompass AB.
Du svarar alltid på svenska, kort och sakligt.
Du känner till foljande policyer:
- Returer godkänns inom 30 dagar med kvitto.
- Fri frakt över 500 kronor inom Sverige.
- Leveranstid till Norge och Danmark är 3-5 arbetsdagar.
[... ytterligare 800 rader produktinformation, FAQ och tonfallsregler ...]
"""

response = client.messages.create(
    model="claude-haiku-5-5",
    max_tokens=500,
    system=[
        {
            "type": "text",
            "text": SYSTEM_PROMPT,
            "cache_control": {"type": "ephemeral"},
        }
    ],
    messages=[{"role": "user", "content": "Hur länge har jag på mig att returnera en vara?"}],
)
print(response.content[0].text)
print(response.usage)

Kör skriptet två gånger i rad. Första körningen skriver till cachen och kostar enligt skriv-multiplikatorn. Andra körningen läser från cachen om den körs inom TTL-fönstret och kostar en bråkdel av priset. Du ser skillnaden direkt i usage-objektet, vilket leder till nästa steg.

Steg 5 och 6: Cacha långa dokument för svenska avtal utan RAG

Med ett kontextfönster på 1 miljon token kan Claude Haiku 5.5 hålla hela avtal, årsredovisningar eller produktkataloger i minnet utan att du behöver bygga ett separat vektorsök. Det fungerar bäst när dokumentet är relativt statiskt och flera frågor ställs mot samma underlag inom kort tid, till exempel när en jurist går igenom ett kontrakt fråga för fråga.

with open("hyresavtal_2026.txt", encoding="utf-8") as f:
    kontraktstext = f.read()  # t.ex. 40 000 ord svensk juridisk text

response = client.messages.create(
    model="claude-haiku-5-5",
    max_tokens=800,
    system=[
        {
            "type": "text",
            "text": "Du analyserar svenska hyresavtal och svarar kort med källhänvisning till paragraf.",
        },
        {
            "type": "text",
            "text": kontraktstext,
            "cache_control": {"type": "ephemeral", "ttl": "1h"},
        },
    ],
    messages=[{"role": "user", "content": "Vilken uppsägningstid gäller enligt paragraf 12?"}],
)
print(response.content[0].text)

Lägg märke till att dokumentet ligger i ett eget block, separat från den korta instruktionen. Det gör att du kan byta instruktion mellan anrop utan att ogiltigförklara cachen för det stora dokumentet, eftersom cache-nyckeln baseras på innehållet fram till och med markeringen. Här används en timmes TTL eftersom en genomgång av ett avtal sällan är klar inom 5 minuter.

Metoden fungerar bäst för dokument i spannet mellan några tusen och några hundra tusen token. Går du betydligt över det, till exempel en hel kunskapsbas med flera tusen sidor, blir det ofta smartare att kombinera caching med ett lättviktigt söksteg som filtrerar fram relevanta avsnitt innan de skickas in, snarare än att försöka hålla absolut allt i ett enda cachat block. Gränsen är inte hugget i sten, utan beror på hur ofta innehållet ändras och hur många olika frågor som faktiskt ställs mot det under en given dag.

Kostnadstyp	Multiplikator	Pris per miljon token (Haiku 5.5-bas 0,10 USD)	När den gäller
Vanlig indata (ingen cache)	1x	0,10 USD	Standardanrop utan cache_control
Cache-skrivning, 5 minuter	1,25x	0,125 USD	Första anropet, kort TTL
Cache-skrivning, 1 timme	2x	0,20 USD	Första anropet, lång TTL
Cache-läsning (träff)	0,1x	0,01 USD	Efterföljande anrop inom TTL
Utdata (opåverkad av caching)	5x indata	0,50 USD	Alla svar, cachas aldrig

Steg 7: Flervändade konversationer med flera cache-brytpunkter

En chattbot som för ett längre samtal ackumulerar historik för varje tur. Utan caching betalar du för hela konversationshistoriken igen vid varje nytt meddelande, vilket gör långa samtal dyra snabbt. Lösningen är att lägga en ny cache-brytpunkt vid slutet av konversationshistoriken varje gång du skickar ett anrop, så att nästa tur bara betalar fullt pris för det senaste tillägget.

def skicka_med_cache(historik, nytt_meddelande):
    historik.append({"role": "user", "content": nytt_meddelande})

    # Markera det sista blocket i historiken som cachebart
    meddelanden = historik.copy()
    if meddelanden:
        sista = meddelanden[-1]
        meddelanden[-1] = {
            "role": sista["role"],
            "content": [
                {
                    "type": "text",
                    "text": sista["content"],
                    "cache_control": {"type": "ephemeral"},
                }
            ],
        }

    svar = client.messages.create(
        model="claude-haiku-5-5",
        max_tokens=600,
        system=[{"type": "text", "text": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}}],
        messages=meddelanden,
    )
    historik.append({"role": "assistant", "content": svar.content[0].text})
    return svar

samtal = []
svar1 = skicka_med_cache(samtal, "Jag vill beställa 5 st artikel 4410.")
svar2 = skicka_med_cache(samtal, "Kan ni leverera till Trondheim också?")
print(svar2.usage)

Du kan ha upp till fyra aktiva cache-brytpunkter per anrop. Lägg dem strategiskt: en för systemprompten, en för statiska referensdokument och en för konversationshistoriken. Varje brytpunkt är en egen cachepost med sin egen TTL, så du kan blanda en lång TTL för dokumentet med en kort TTL för den rörliga chatthistoriken.

Hantera växande historik med ett sliding window

Ett samtal som pågår i timmar växer till slut så stort att hela historiken riskerar att krocka med kontextfönstret, även med 1 miljon token tillgängliga. Det blir dessutom dyrare att skriva om cachen när den växer, eftersom en ny brytpunkt i slutet av en lång historik fortfarande måste hasha allt innehåll fram till den punkten. En vanlig lösning är att klippa bort de äldsta turerna när historiken passerar en tröskel, till exempel 50 000 token, och istället sammanfatta dem i en kort textrad som läggs först i systemprompten. Du förlorar en del detaljrikedom från tidigt i samtalet, men du håller både kostnad och latens under kontroll genom resten av sessionen. Testa tröskeln mot dina egna användningsfall, eftersom en kundtjänstbot med korta ärenden sällan behöver den logiken alls, medan en analysagent som kör i timmar nästan alltid gör det.

Steg 8: Mät cache-träffar och bygg en kostnadskalkylator

Du kan inte förbättra det du inte mäter. Varje svar från Claude API innehåller ett usage-objekt med fälten cache_creation_input_tokens och cache_read_input_tokens. Skillnaden mellan dessa två fält avgör hur mycket du faktiskt sparar, och de bör loggas för varje anrop i produktion, inte bara under utveckling.

def berakna_kostnad(usage, pris_in=0.10, pris_ut=0.50):
    skrivna = getattr(usage, "cache_creation_input_tokens", 0) or 0
    lasta = getattr(usage, "cache_read_input_tokens", 0) or 0
    ovrigt_in = usage.input_tokens - skrivna - lasta
    ut = usage.output_tokens

    kostnad = (
        ovrigt_in * pris_in
        + skrivna * pris_in * 1.25
        + lasta * pris_in * 0.1
        + ut * pris_ut
    ) / 1_000_000

    utan_cache = (usage.input_tokens * pris_in + ut * pris_ut) / 1_000_000
    besparing = 0 if utan_cache == 0 else (1 - kostnad / utan_cache) * 100

    print(f"Faktisk kostnad: {kostnad:.6f} USD")
    print(f"Kostnad utan caching: {utan_cache:.6f} USD")
    print(f"Besparing denna förfrågan: {besparing:.1f} procent")
    return kostnad

berakna_kostnad(svar2.usage)

Exempel på utskrift efter ett par turer i en chatt med en 1 200 token systemprompt och cachad historik:

Faktisk kostnad: 0.000182 USD
Kostnad utan caching: 0.000640 USD
Besparing denna förfrågan: 71.6 procent

Siffran varierar beroende på hur stor andel av din indata som faktiskt är cachebar. En kort chatt sparar mindre procentuellt än en lång dokumentgenomgång, eftersom det korta nya meddelandet väger tyngre i förhållande till den cachade delen. Logga både absolut kostnad i dollar och procentuell besparing per endpoint, så ser du snabbt vilka delar av din app som drar mest nytta av caching och vilka som knappt märker av det.

Skicka loggen vidare till samma observability-stack ni redan använder för övrig drift, till exempel Grafana eller en intern Elastic-stack, istället för att bygga ett separat system bara för AI-kostnader. Lägg till cache_read_input_tokens och cache_creation_input_tokens som egna mätvärden per endpoint, med tagg för vilken kund eller marknad anropet gäller. Då kan ni sätta ett larm som går av om den genomsnittliga träffraten faller under en tröskel, till exempel 60 procent, istället för att upptäcka problemet när ekonomiavdelningen hör av sig om en oväntat hög faktura.

Steg 9: Välj rätt TTL, 5 minuter eller 1 timme

Det finns inget universellt rätt val här, bara en avvägning mellan skrivkostnad och hur ofta cachen faktiskt återanvänds inom sitt fönster. En kundtjänstbot med spridda, oregelbundna frågor under hela dagen vinner sällan på en timmes TTL, eftersom cachen oftast hinner gå ut mellan besökarna. En intern analysagent som körs i tät följd under ett arbetspass vinner nästan alltid på den längre TTL:en.

Scenario	Rekommenderad TTL	Motivering
Kundtjänstbot med ojämn trafik	5 minuter	Lägre skrivpremie, cachen förnyas naturligt vid aktivitet
Dokumentanalys i en session	1 timme	Flera frågor i rad mot samma underlag inom en arbetsstund
Nattlig batchbearbetning	5 minuter, återskapa per batch	Varje batch är oberoende, ingen anledning till lång livstid
Intern kunskapsassistent, kontorstid	1 timme	Kontinuerlig användning under dagen håller cachen varm
Engångsanalys av en enskild rapport	5 minuter	Dokumentet används bara en gång, ingen återanvändning att vinna

En enkel tumregel: om du förväntar dig fler än tre återanvändningar av samma cache inom en timme är den längre TTL:en nästan alltid billigare totalt, trots den högre skrivkostnaden. Räkna igenom ditt eget användningsmönster med kalkylatorn från steg 8 innan du låser valet i produktionskoden.

Ett konkret räkneexempel gör skillnaden tydligare. Säg att din systemprompt och referensmaterial väger 20 000 token. Med 5 minuters TTL betalar du 0,10 USD per miljon gånger 1,25 för skrivningen, vilket blir 0,0025 USD, och sedan 0,0002 USD per efterföljande läsning. Med 1 timmes TTL blir skrivningen istället 0,0004 USD dyrare men du slipper skriva om var femte minut om trafiken fortsätter in i nästa fönster. Break-even ligger runt den tredje till fjärde återanvändningen inom samma timme, exakt den gräns tumregeln ovan pekar på. Kör alltid din egen trafikdata genom samma formel innan du låser valet, eftersom verkliga mönster sällan är lika jämna som ett räkneexempel.

Steg 10: Kombinera caching med function calling och verktyg

Verktygsdefinitioner, alltså JSON-scheman för function calling, är ofta lika statiska som systemprompten och lika stora i tokenantal när en agent har tillgång till många funktioner. De går att cacha på samma sätt genom att markera verktygslistan med cache_control. Det här är särskilt värdefullt för agenter som anropas upprepade gånger i en loop, där samma verktygsschema skickas om och om igen.

tools = [
    {
        "name": "sok_lagerstatus",
        "description": "Slar upp aktuellt lagersaldo for en artikel i Nordkompass lagersystem.",
        "input_schema": {
            "type": "object",
            "properties": {"artikelnummer": {"type": "string"}},
            "required": ["artikelnummer"],
        },
    },
    # ... ytterligare 10-15 verktygsdefinitioner i ett verkligt agentsystem
]

response = client.messages.create(
    model="claude-haiku-5-5",
    max_tokens=500,
    tools=tools,
    extra_headers={"anthropic-beta": "token-efficient-tools"},
    system=[{"type": "text", "text": SYSTEM_PROMPT, "cache_control": {"type": "ephemeral"}}],
    messages=[{"role": "user", "content": "Finns artikel 4410 i lager?"}],
)

# Lägg cache_control på det sista verktyget i listan för att cacha hela blocket
tools[-1]["cache_control"] = {"type": "ephemeral"}

Precis som med systemprompten och dokumenten gäller att cachen täcker allt innehåll fram till markeringen. Lägg verktygen i en fast ordning och markera det sista, så cachas hela listan som ett block. Om du sorterar om verktygen mellan anrop, även om innehållet är identiskt, räknas det som ett nytt cache-innehåll och du förlorar besparingen.

Headern anthropic-beta i exemplet styr ett separat funktionsflagga för hur verktygsanrop kodas i svaret, inte caching i sig, men de två funktionerna samspelar väl eftersom båda syftar till att minska mängden upprepad data som skickas fram och tillbaka i en agentloop. Kontrollera alltid release-noteringarna för vilka beta-headrar som fortfarande krävs, eftersom Anthropic regelbundet flyttar funktioner från beta till allmän tillgänglighet och då tar bort kravet på headern helt.

Steg 11 och 12: Driftsätt tjänsten och testa med svenska dokument

Paketera logiken i en minimal Flask-tjänst så att frontend eller andra system kan anropa den via HTTP istället för att importera Python-modulen direkt. Håll klienten och systemprompten som moduldata som laddas en gång vid uppstart, inte per förfrågan.

from flask import Flask, request, jsonify

app = Flask(__name__)

@app.route("/chatta", methods=["POST"])
def chatta():
    data = request.get_json()
    svar = skicka_med_cache(data.get("historik", []), data["meddelande"])
    kostnad = berakna_kostnad(svar.usage)
    return jsonify({
        "svar": svar.content[0].text,
        "kostnad_usd": round(kostnad, 6),
        "cache_lasta_token": svar.usage.cache_read_input_tokens,
    })

if __name__ == "__main__":
    app.run(port=8080)

Testa sedan med riktiga svenska dokument innan du går live, inte bara engelska exempeltexter. Ladda in en faktisk svensk årsredovisning eller ett kommunalt beslutsunderlag och ställ fem till tio verkliga frågor i rad. Kontrollera att teckenkodningen är UTF-8 genomgående, eftersom å, ä och ö annars tenderar att trasas sönder i terminaler med fel lokalinställning, vilket i sin tur kan göra att cachen byggs på korrupt text.

Komplett fungerande projekt: mappstruktur och sammanfattning

När du har följt alla steg ovan har du en fristående tjänst med följande struktur, redo att containeriseras eller köras direkt på en server i Stockholm, Oslo eller Helsingfors:

claude-cache-projekt/
├── .env                  # ANTHROPIC_API_KEY, aldrig i git
├── .gitignore
├── app.py                # Flask-tjanst med /chatta-endpoint
├── cache_utils.py        # skicka_med_cache() och berakna_kostnad()
├── hyresavtal_2026.txt   # exempel pa langt cachebart dokument
├── requirements.txt      # anthropic, flask, python-dotenv
└── test_cache.py         # enkla tester for cache-traff vs cache-miss

I test_cache.py behöver du bara två tester för att fånga de vanligaste regressionerna. Det första skickar samma systemprompt två gånger i rad och kontrollerar att cache_read_input_tokens är större än noll i det andra svaret, vilket bevisar att träffen faktiskt sker. Det andra testet ändrar en enda bokstav i systemprompten mellan anropen och kontrollerar att cache_read_input_tokens då är noll, vilket bevisar att du korrekt upptäcker en cache-miss istället för att bara anta att allt fungerar. Kör båda testerna i din CI-pipeline varje gång någon rör filer som bygger systemprompten, så fångar du de tysta regressionerna innan de hamnar i produktion och syns först på fakturan i slutet av månaden.

Den färdiga tjänsten cachar systemprompt, referensdokument, verktygsscheman och konversationshistorik separat, med egna TTL-val för var och en. Det är precis den uppdelningen som gör skillnaden mellan en demo och något som faktiskt håller kostnaderna nere när trafiken skalar från tio till tio tusen anrop om dagen.

Säkerhet och dataskydd när du cachar kunddata

En sårbarhetsskanner eller brandvägg skyddar inte mot ett eget designfel i hur du hanterar cachad text, och det är precis det ni på säkerhetsavdelningen bör granska innan tjänsten går live. Cachen lagras på Anthropics infrastruktur under hela TTL-fönstret, vilket betyder att personuppgifter som fastnar i en cachad systemprompt eller ett cachat dokument ligger kvar där i upp till en timme, inte bara under ett enskilt anrop. För svenska och nordiska bolag som hanterar persondata enligt GDPR är det en skillnad som måste in i både dataskyddsbedömningen och leverantörsavtalet med Anthropic, inte bara i den tekniska dokumentationen.

Bygg därför in tre vanor direkt från start. Håll kunddata, personnummer och sessionsspecifik information helt utanför de block du markerar med cache_control, och placera dem istället i det senaste, icke-cachade meddelandet i varje anrop. Separera cachen per tenant om din tjänst betjänar flera kunder i samma kodbas, så att en cache-nyckel från kund A aldrig av misstag kan återanvändas för kund B, vilket annars är ett klassiskt mönster för dataläckage mellan hyresgäster i multi-tenant-system. Logga vilka fält som faktiskt hamnar i cachebara block under kodgranskningen, inte bara vid lansering, eftersom en senare refaktorering lätt kan flytta in känslig data i fel block utan att någon märker det i en vanlig funktionstest.

Tänk också på revisionsspår. Om en incidentutredning någon gång behöver svara på vad en AI-assistent visste vid en given tidpunkt, är det enklare att rekonstruera om du loggar hashen av det cachade blocket tillsammans med tidsstämpel och TTL, inte bara det slutgiltiga svaret till användaren. Det kostar några rader extra kod men sparar timmar om något går fel och ni behöver visa exakt vilken version av systemprompten som var aktiv under en incident.

7 vanliga fallgropar med prompt caching

De här misstagen dyker upp om och om igen i kodgranskningar, oftast efter att en tjänst redan gått live och någon undrar varför kostnaden inte sjönk som förväntat.

Att ändra en enda bokstav i den cachade texten. Cache-nyckeln baseras på exakt innehåll. Ett extra blanksteg eller ett bytt datum i systemprompten ogiltigförklarar hela cachen utan felmeddelande, du bara betalar skrivpriset igen utan att förstå varför.
Att cacha för kort text. Om blocket ligger under minimigränsen, 512 token för flera av dagens modeller, ignoreras cache_control-markeringen helt och anropet faktureras som vanligt.
Att sortera om listor mellan anrop. Verktyg, exempel eller dokumentavsnitt i en annan ordning än förra gången räknas som nytt innehåll, även om varje enskild del är identisk.
Att glömma mäta i produktion. Utvecklare testar caching lokalt, ser besparingen, och glömmer sedan logga cache_read_input_tokens när koden går live, vilket gör det omöjligt att upptäcka om cachen tystnat efter en deploy.
Att välja fel TTL för trafikmönstret. En timmes TTL på en tjänst med få och spridda anrop ger bara högre skrivkostnad utan några lästräffar att väga upp den med.
Att blanda cachebart och icke-cachebart innehåll i samma textblock. Markeringen gäller hela blocket. Lägg rörlig data, som dagens datum eller användarnamn, i ett separat block utanför det cachade avsnittet.
Att anta att caching alltid är billigare. För en tjänst med låg återanvändningsgrad kan skrivpremien på 25 eller 100 procent göra helheten dyrare än att köra utan cache. Räkna alltid igenom scenariot med kalkylatorn innan du aktiverar cache_control i produktion.

Felsökning: 8 vanliga problem och hur du löser dem

De flesta cachingproblem syns inte som felmeddelanden, de syns som en faktura som inte minskar trots att du har implementerat allt rätt enligt dokumentationen. Gå igenom listan nedan i ordning innan du antar att funktionen är trasig på Anthropics sida, vilket den nästan aldrig är.

Problem	Trolig orsak	Åtgärd
cache_read_input_tokens är alltid 0	Innehållet skiljer sig mellan anrop	Diffa exakt textsträng mellan två anrop, leta efter dolda tecken eller tidsstämplar
Hög kostnad trots cache_control	Blocket är under 512 token	Slå ihop flera korta block eller förläng referensmaterialet
401-fel vid anrop	API-nyckeln saknas eller har gått ut	Kontrollera miljövariabeln och generera en ny nyckel i konsolen
Cache-träff fungerar lokalt men inte i produktion	Lastbalanserare skickar anrop till flera instanser	Cacheminnet är inte delat mellan processer, överväg sticky sessions eller gemensam cache-nyckel
Svaret kommer men usage saknar cache-fält	Äldre version av SDK:n	Uppgradera anthropic-paketet till senaste versionen med pip install –upgrade anthropic
Verktygsanrop ignorerar cache_control	cache_control ligger på fel nivå i JSON-strukturen	Placera markeringen på det sista objektet i tools-listan, inte på hela listan
Kostnaden sjunker inte trots cache-träffar	Utdatatoken, inte indata, dominerar kostnaden	Be modellen om kortare svar eller sätt ett lägre max_tokens-värde
Svensk text med å, ä, ö visas som konstiga tecken	Fel teckenkodning vid filinläsning	Öppna filer explicit med encoding=”utf-8″ i Python
Cache-träff byter plötsligt till miss mitt i en session	TTL hann gå ut mellan två anrop	Mät tiden mellan anropen, byt till 1 timmes TTL om glappen ofta är längre än 5 minuter
Olika resultat i test och produktion trots identisk kod	Olika modellversioner i de två miljöerna	Lås modell-id:t i en konfigurationsfil och versionshantera det tillsammans med koden

Avancerade tips för produktion i Norden

När grundflödet fungerar finns det ett par förbättringar som sällan syns i enkla exempel men märks tydligt i en skarp driftsmiljö. Separera systemprompten i två delar: en som sällan ändras, som tonfall och policyer, och en som ändras per kund eller per marknad, som produktinformation för en specifik nordisk filial. Lägg bara den första delen i cachen.

Om din tjänst betjänar både Sverige, Norge, Danmark och Finland, bygg en separat cache per marknad istället för att försöka dela en gemensam cache med marknadsspecifika tillägg längst ner. Det kostar mer i totala skrivningar men ger betydligt högre träffrate per marknad, eftersom trafiken för varje land är mer regelbunden i sitt eget flöde.

Bygg också en varningsfunktion som jämför dagens genomsnittliga träffrate mot föregående vecka. En plötslig nedgång i cache_read_input_tokens är ofta det första tecknet på att någon av dina kollegor av misstag lagt in en tidsstämpel eller ett sessions-ID mitt i den text som ska vara statisk, ett fel som annars kan gå obemärkt i veckor medan API-notan sakta klättrar uppåt.

Bygg en liten dashboard, även om det bara är ett dagligt Slack-meddelande med tre siffror: total kostnad, andel lästa cache-token och andel skrivna cache-token. Ett team som bara tittar på totalkostnaden missar ofta att en enskild ny funktion plötsligt skriver om cachen vid varje anrop istället för att återanvända den, vilket äter upp hela besparingen utan att synas i den övergripande trenden förrän fakturan kommer. Samma princip gäller om ni bygger agenter mot flera leverantörer, som i vår guide till att bygga en AI-agent med Gemini API, där kostnadsspårning är lika viktig som själva cachingen.

Om din tjänst körs i flera regioner, till exempel en instans nära Stockholm och en nära Frankfurt för redundans, dela inte automatiskt cache-nycklar mellan regionerna utan att testa det. Nätverkslatensen mellan regioner äter ofta upp hela besparingen från en delad cache, och det är i de flesta fall enklare och billigare att låta varje region bygga sin egen lokala cache mot samma innehåll.

Slutligen: testa samma caching-strategi mot flera modeller innan du låser in en leverantör. Prissättningen och cache-mekaniken skiljer sig mellan Claude Haiku 5.5, Gemini 4 Argon, Mistral Large 4 och DeepSeek V4.1 Flash, och en strategi som är optimal för en modell är inte automatiskt optimal för en annan. Om du redan kör Claude Sonnet 5.5 i ett säkerhetskänsligt arbetsflöde gäller samma caching-principer, bara med andra baspriser att räkna på. Håll kalkylatorn från steg 8 modulär så att du kan byta prisparametrar utan att skriva om hela flödet.

Sammanfattningsvis handlar prompt caching om tre saker i praktiken: markera rätt block med cache_control, mät varje anrop så att du faktiskt vet om träffen sker, och välj TTL utifrån ert eget trafikmönster istället för en standardinställning ni aldrig räknat på. Gör du alla tre delarna rätt sänker du kostnaden för Claude API med tiotals procent på de arbetsflöden som upprepar samma systemprompt, dokument eller verktygslista flera gånger, utan att göra avkall på svarskvalitet eller hastighet.

Vanliga frågor om prompt caching i Claude API

Kostar det något att skapa en cache om jag aldrig återanvänder den?
Ja. Skrivningen faktureras med sin egen multiplikator, 1,25x eller 2x grundpriset, oavsett om du sedan läser från cachen eller inte. Cacha bara innehåll du faktiskt förväntar dig att återanvända inom TTL-fönstret.

Fungerar prompt caching med streaming-svar?
Ja, cache_control fungerar oberoende av om du använder streaming eller vanliga anrop. Cachningen gäller indata, inte hur svaret levereras tillbaka till dig.

Kan jag cacha bilder och PDF-filer, inte bara text?
Multimodalt innehåll kan markeras med samma cache_control-fält i de block som stödjer det, men kontrollera alltid aktuell dokumentation för just den innehållstyp och modell du använder, eftersom stödet varierar.

Vad händer om cachen går ut mitt i en lång sekvens av anrop?
Nästa anrop efter utgången behandlas som en ny skrivning till full skrivkostnad. Det är därför tätt återkommande trafik, som en aktiv chattsession, ofta gynnas av längre TTL.

Är caching värt besväret för en liten app med få användare?
Räkna på det med kalkylatorn från steg 8 innan du bestämmer dig. För en app med enstaka anrop per timme är besparingen marginell och komplexiteten kanske inte är motiverad. För allt som skalar till hundratals eller tusentals anrop per dag blir besparingen snabbt betydande.

Påverkar caching svarskvaliteten eller gör modellen långsammare?
Nej, caching ändrar bara hur indatan prissätts och bearbetas internt. Modellens svar baseras på samma innehåll som utan caching, och många användare upplever snarare lägre latens eftersom cachad indata inte behöver processas från grunden varje gång.

Hur vet jag om min app redan borde använda caching?
Om samma systemprompt, dokument eller verktygslista skickas i fler än ett anrop inom en femminuters- eller enfilestimmesperiod, är svaret nästan alltid ja. Logga dina nuvarande anrop en vecka och se hur stor andel av indatan som upprepas.

Måste jag byta SDK-version för att få tillgång till caching?
Funktionen kräver en tillräckligt ny version av Anthropics officiella SDK. Kör pip install –upgrade anthropic innan du börjar, och verifiera i release-noteringarna att cache_control och usage-fälten för cache stöds i den version du installerar.

Kan jag använda samma cachade systemprompt mot flera olika modeller samtidigt?
Nej, cachen är knuten till en specifik modell. Byter du från Claude Haiku 5.5 till en annan modell i samma familj måste du skriva om cachen från grunden, även om texten i systemprompten är exakt identisk mellan de två modellerna.

Syns cachad text för andra kunder om vi kör en delad backend?
Nej, varje cachepost är knuten till ditt eget konto och din egen API-nyckel, inte delad mellan olika Anthropic-kunder. Däremot måste du själv säkerställa isolering mellan dina egna kunder om du bygger en multi-tenant-tjänst ovanpå en gemensam API-nyckel, vilket beskrivs närmare i avsnittet om säkerhet och dataskydd ovan.

Claude Haiku 5.5: Prompt Caching i 12 Steg, 60 Min [2026]