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 kacher 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).

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 marker 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.

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 cachedete 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.

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.

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).