Prompt caching: den 90%-besparelse ingen taler om

Anthropics ephemeral cache er ikke nyt. Det har eksisteret siden 2024. Men de fleste teams, der bruger Claude i produktion, har endnu ikke implementeret det korrekt — og betaler 60-90% mere end nødvendigt på kald, der burde cachet.

Det er ikke fordi caching er svært. Det er fordi placement er kontraintuitiv, og fordi dokumentationen er teknisk korrekt uden at være praktisk nyttig.

Denne artikel forklarer mekanikken, placement-mønsteret og hvad der faktisk kan caches — og hvad der ikke kan.

Hvad er ephemeral cache

Anthropics ephemeral cache er en server-side caching-mekanisme, der gemmer dele af dit prompt på Anthropics infrastruktur i op til fem minutter. Når du sender det cachede indhold igen inden for de fem minutter, betaler du ikke for input-tokens — kun for output-tokens og et lille cache-read-gebyr.

Konkret rabat: typisk 90% på cachede input-tokens. Hvis du har en system-prompt på 5.000 tokens, der sendes ved hvert kald, og du cacher den, betaler du cache-read-prisen (typisk 10% af normal input-pris) i stedet for fuld input-pris.

For systemer med lange, statiske system-prompts er det transformativt.

Caching er ikke en optimering. Det er en fundamentel del af cost-modellen for AI-systemer i produktion. Et system, der sender 5.000 token-instrukser på hvert kald uden caching, er ikke cost-optimeret — det er ikke sat ordentligt op.

1024-token grænsen

Den vigtigste tekniske detalje er minimumsstørrelsen: din prompt-del skal være mindst 1.024 tokens, for at caching aktiveres.

Det betyder, at du ikke bare kan cache et kort system-prompt på 200 tokens og forvente rabat. Du skal enten:

1. Have nok indhold i din cachede blok (1.024+ tokens), eller
2. Opbygge din prompt, så de dele, der kan gentages, samles til én blok over grænsen.

I praksis er dette sjældent et problem for enterprise-systemer. System-prompts med domain context, eksempler (few-shot) og instrukser er typisk langt over 1.024 tokens.

For enklere systemer med korte instrukser er det en reel begrænsning — og et tegn på, at du bør overveje, om du skal tilføje few-shot-eksempler til din prompt alligevel (de forbedrer typisk output-kvaliteten og giver dig caching som sidegevinst).

Det er værd at understrege: 1.024 tokens er lavere end det lyder. En velformuleret system-prompt med to siders instrukser og tre eksempler på ønsket output er typisk 1.200-2.000 tokens. De fleste meningsfulde system-prompts er allerede over tærsklen.

cacheControl placement-mønsteret

Her er den del, der er mest forvirrende for teams, der implementerer caching for første gang: du cacher ikke "din system-prompt som helhed." Du markerer specifikke dele af dit messages-array som cacheable.

const result = await generateText({
  model: models.deep,
  messages: [
    {
      role: "user",
      content: [
        {
          type: "text",
          text: STATIC_SYSTEM_INSTRUCTIONS, // 2000+ tokens statisk tekst
          providerOptions: {
            anthropic: {
              cacheControl: { type: "ephemeral" },
            },
          },
        },
        {
          type: "text",
          text: userInput, // dynamisk — caches ikke
        },
      ],
    },
  ],
  experimental_telemetry: {
    isEnabled: true,
    functionId: "my-feature",
  },
})

Det kritiske punkt: cacheControl sættes på providerOptions på det specifikke TextPart — ikke på hele messages-arrayet, ikke i system-feltet og ikke i selve teksten.

Det er en almindelig fejl at sætte det forkert sted, og resultatet er, at caching ikke aktiveres — du betaler fuld pris og tror, du cacher.

En anden hyppig fejl: at bruge experimental_providerMetadata i stedet for providerOptions. Begge syntakser har eksisteret på tværs af AI SDK-versioner, men i AI SDK v6 er den korrekte felt providerOptions. Tjek Anthropic-dokumentationen for den version, du bruger.

Hvad der kan caches, og hvad der ikke kan

Kan caches: Statisk indhold, der er identisk på tværs af kald. Instrukser, rammer, few-shot-eksempler, domain-kontekst, role-definitions. Jo mere statisk, jo bedre.

Kan ikke caches effektivt: Brugerinput, real-time data, timestamps, indhold med unikke IDs. Caching fungerer kun, når det cachede indhold er bit-for-bit identisk med det, der er i cachen.

Placement-hierarki: Placer den cachede del tidligst muligt i messages-arrayet. Caching fungerer fra start til det punkt, du har markeret — det er ikke muligt at cache et fragment midt i et langt conversation-array.

TTL: Cache lever i op til fem minutter. For systemer med hyppige kald (chat, real-time analyse) er dette sjældent et problem. For batch-jobs med lang pause imellem kaldene udløber cachen, og du betaler fuld pris på næste kald.

Multi-turn conversations: Du kan cache den initielle system-context og dermed betale for den én gang per session-vindue. Brugerturns (der ændrer sig) kan du ikke cache.

Verifikation: er det faktisk cachet

Den mest kritiske fejl er at implementere caching og antage, at det virker. Verifikation kræver, at du checker response-metadata.

Via Langfuse eller direkte via Anthropic SDK kan du se:

// Fra Langfuse trace eller direkte API response
const usage = result.usage
// cache_creation_input_tokens: tokens brugt på at oprette cachen (første kald)
// cache_read_input_tokens: tokens læst fra cachen (efterfølgende kald)
// input_tokens: tokens, der ikke var cached

Hvis cache_read_input_tokens er 0 på opkald, der burde cache-ramme, er caching ikke aktiveret korrekt. Det kan skyldes forkert placement af cacheControl, tokens under 1.024-grænsen eller at TTL-vinduet er udløbet.

Tilføj observabilitet fra dag 1. Du kan ikke debugge caching uden at se, hvad der faktisk sker på token-niveau.

En god praksis: log cache-hit-rate som en metrik i dit AI-observabilitetssystem. Hvis hit-rate falder under 60% på kald, der burde ramme cachen, er der et problem — enten med TTL, placement eller med, at system-prompts ændres uventet.

Strategi for system-prompts med context

Den kraftigste use case er at cache domain-context, der er fælles for mange kald — men specifik nok til at drive output-kvaliteten.

Mønster 1 — Statisk + dynamisk:

const DOMAIN_CONTEXT = `
Du er en enterprise arkitektur-assistent. Du hjælper med at analysere 
IT-porteføljer ud fra følgende principper:
${PRINCIPLES}  // 500 tokens
${EXAMPLES}    // 800 tokens
${METHODOLOGY} // 600 tokens
`
// Total: ~1900 tokens — over 1024-grænsen, kan caches

const result = await generateText({
  messages: [
    {
      role: "user",
      content: [
        { type: "text", text: DOMAIN_CONTEXT, providerOptions: { anthropic: { cacheControl: { type: "ephemeral" } } } },
        { type: "text", text: `Analyser denne applikation: ${userApp}` }
      ]
    }
  ]
})

Mønster 2 — Few-shot caching:

Few-shot eksempler er ideelle til caching. De er statiske, relativt lange (200-300 tokens pr. eksempel) og forbedrer output-konsistens markant. Tre eksempler giver typisk 600-900 tokens — tilstrækkelig tæt på 1.024-grænsen til at supplere med en kortere instruks.

Mønster 3 — Workspace-specifik kontekst:

For multi-tenant systemer kan workspace-specifik kontekst (virksomhedens navneliste, branchespecifik terminologi, konfiguration) med fordel caches pr. session. Det forudsætter, at konteksten er stabil inden for en session-varighed på under fem minutter — og at den er samlet nok til at overstige 1.024-token-grænsen.

Flere cache-breakpoints i samme kald

En detalje, der sjældent fremgår af tutorials: du kan sætte cacheControl på flere punkter i det samme messages-array. Det giver dig mulighed for at cache i lag.

Et praktisk eksempel: et enterprise-analyse-kald med tre lag af statisk indhold:

Lag 1 — Globale instrukser (3.000 tokens): Systemets rolle, metodologi og output-format. Ændres sjældent.

Lag 2 — Workspace-kontekst (1.200 tokens): Virksomhedens IT-principper, strategiske temaer og relevante definitioner. Ændres månedligt.

Lag 3 — Session-kontekst (800 tokens): Det aktuelle analyseemne og relaterede data. Ændres per session.

Med tre cache-breakpoints betaler du kun for det lag, der ændrer sig. Lag 1 caches næsten aldrig om — du betaler cache-read-prisen 19 ud af 20 kald. Lag 2 recreates kun, når workspace-konteksten opdateres. Lag 3 er ny per session, men de to øvrige lag reducerer alligevel det samlede token-forbrug med 75-85%.

Implementeringsmæssigt sætter du cacheControl: { type: "ephemeral" } på afslutningen af hvert lag — ikke kun på det første.

Konsekvensen af model-skift

En cache er bundet til den specifikke model-version. Hvis du skifter fra claude-sonnet-4-6 til en nyere version, nulstilles cachen, og du betaler cache_creation_input_tokens på det første kald efter skiftet.

Det er ikke et problem — blot noget at planlægge for. Når du deployer en model-upgrade, forventes et spike i cache_creation_input_tokens i den første time. Det er normalt og forventet.

Det betyder også, at model-versioner bør styres konsistent med ai_model_version-feltet i ADR-0001-datamodellen — du kan se præcis, hvilke records der er genereret med den gamle model-version og potentielt trænger til re-generering.

Og det understreger, hvorfor AI-observabilitet og prompt-caching hører sammen: uden cache_read_input_tokens i dine traces ved du ikke, om cache-hit-raten er faldet efter et model-skift — og du opdager det tidligst på regningen.

Hvad gøres i morgen

Caching har den laveste implementeringspris af alle AI-cost-optimeringer — og en af de højeste besparelsespotentialer. Tre skridt:

Uge 1: Identificér de kald i produktet, der sender lange, statiske system-prompts. Mål token-volumenet på disse kald. Beregn den potentielle besparelse.

Uge 2: Implementér cacheControl på de statiske dele af de identifikerede kald. Verificér via telemetri, at cache_read_input_tokens stiger.

Uge 3: Mål den faktiske cost-reduktion i Langfuse eller Anthropic-konsollen. Sæt caching som standard-praksis for alle nye features med statisk system-context.

Prompt-caching er ikke en avanceret optimering. Det er en grundlæggende del af at bygge AI-systemer, der er cost-bæredygtige i produktion.

Referencer

[1] Anthropic, "Prompt Caching", tilgængeligt på docs.anthropic.com/en/docs/build-with-claude/prompt-caching (besøgt 2026-04-23).

[2] Anthropic, "Models Overview — Pricing", tilgængeligt på docs.anthropic.com/en/docs/models-overview (besøgt 2026-04-23).

[3] Vercel AI SDK, "Provider Options — Anthropic", tilgængeligt på sdk.vercel.ai/providers/ai-sdk-providers/anthropic (besøgt 2026-04-23).