💬 NLP

Don't Break the Cache: An Evaluation of Prompt Caching for Long-Horizon Agentic Tasks

Dit artikel presenteert een uitgebreide evaluatie van prompt caching bij drie grote LLM-providers voor langdurige agentische taken, waarbij wordt aangetoond dat strategische cachingtechnieken—zoals het uitsluiten van dynamische toolresultaten en het beheren van de promptstructuur—de API-kosten met 41–80% kunnen verlagen en de tijd tot het eerste token met 13–31% kunnen verbeteren in vergelijking met naïeve full-context caching.

Oorspronkelijke auteurs: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

Gepubliceerd 2026-02-03

📖 4 min leestijd☕ Koffiepauze-leesvoer

CC BY 4.0

Oorspronkelijke auteurs: Elias Lumer, Faheem Nizar, Akshaya Jangiti, Kevin Frank, Anmol Gulati, Mandar Phadate, Vamse Kumar Subbiah

Oorspronkelijk artikel gelicentieerd onder CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Dit is een AI-gegenereerde uitleg van het onderstaande artikel. Het is niet geschreven of goedgekeurd door de auteurs. Raadpleeg het oorspronkelijke artikel voor technische nauwkeurigheid. Lees de volledige disclaimer

Stel je voor dat je een briljante maar dure research assistent inhuurt om een complex mysterie op te lossen. Deze assistent moet een enorme instructiehandleiding (de "system prompt") lezen voordat hij aan het werk gaat. Terwijl hij werkt, maakt hij tientallen telefoontjes naar verschillende bronnen, krijgt antwoorden en schrijdt deze op in een notitieblok.

Elke keer dat hij een nieuw telefoontje pleegt, moet hij de hele instructiehandleiding vanaf de eerste pagina opnieuw lezen om te onthouden wat hij moet doen. Dit kost veel tijd en veel geld, omdat de assistent rekent per pagina die hij leest.

"Prompt Caching" is alsof je die assistent een magische markeerstift geeft. Als de instructiehandleiding niet is veranderd, kan de assistent de eerste 90% van het boek overslaan en direct naar het nieuwe deel springen waar de resultaten van de telefoontjes staan. Dit bespaart tijd en geld.

Echter, dit artikel stelt een lastige vraag: Werkt die magische markeerstift altijd, of kunnen we het verpesten?

De onderzoekers testten dit bij drie grote "assistent"-bedrijven (OpenAI, Anthropic en Google) met behulp van een benchmark genaamd DeepResearch Bench, waarbij agenten lange, meerstaps webzoekopdrachten uitvoeren om moeilijke vragen te beantwoorden. Ze probeerden drie verschillende manieren om de markeerstift te gebruiken:

De "Naïeve" Aanpak (Full Context): Alles markeren, inclusief de nieuwe resultaten van de telefoontjes.
De "Sticky Note" Aanpak (System Prompt Only): Alleen de instructiehandleiding markeren, maar de nieuwe resultaten van de telefoontjes ongemarkeerd laten.
De "Clean Break" Aanpak (Exclude Tool Results): De handleiding en de telefoontjes markeren, maar een speciaal "stop"-bord plaatsen na elk nieuw resultaat, zodat de markeerstift niet per ongeluk de slordige aantekeningen van de volgende persoon oppakt.

Wat ze vonden

1. Het bespaart veel geld (De "Wallet" Win)
Ongeacht welke methode ze gebruikten, de magische markeerstift bespaarde een enorme hoeveelheid geld. Afhankelijk van het bedrijf bespaarden ze tussen de 41% en 80% op de rekening.

Analogie: Het is alsof je beseft dat je niet elke keer een nieuwe bibliotheekkaart hoeft te kopen als je de bibliotheek binnenloopt; je gebruikt gewoon de kaart die je al hebt.

2. Snelheid is lastig (Het "Verkeer" Probleem)
Hoewel het besparen van geld makkelijk was, was het besparen van tijd moeilijker.

De Verrassing: Soms maakte het markeren van alles (de Naïeve aanpak) de assistent zelfs langzamer.
Analogie: Stel je een bezorger voor die probeert het adres van elk pakketje dat hij bezorgt te onthouden. Als hij probeert een pakketje te onthouden dat slechts één keer wordt bezorgd en nooit meer terugkomt, verspilt hij tijd aan het onthouden ervan. Wanneer het volgende pakketje komt, moet hij het oude "ontleren" om ruimte te maken voor het nieuwe. Dit "schrijven naar het geheugen" vertraagt hem.
Het artikel vond dat als je alleen de stabiele delen (de instructiehandleiding) markeert en de rommelige, veranderende delen (de resultaten van de telefoontjes) ongemarkeerd laat, de assistent snel blijft.

3. De "Breek de Cache Niet" Regel
De belangrijkste les gaat over waar je de grens trekt.

Als je dynamische, veranderende informatie (zoals "Huidige tijd: 14:00 uur" of "Gebruikers-ID: 123") in de instructiehandleiding plaatst, breekt de magische markeerstift. Het systeem denkt dat de handleiding is veranderd, waardoor het stopt met markeren en vanaf het begin opnieuw begint met lezen.
De Oplossing: Houd de instructiehandleiding puur en statisch. Als je toch veranderende informatie wilt opnemen, plaats deze dan helemaal aan het einde van de handleiding, als een briefje op de laatste pagina. Op die manier blijft de eerste 99% van de handleiding gemarkeerd en herbruikbaar.

De Conclusie

Voor bedrijven die AI-agenten bouwen die lange, complexe taken uitvoeren:

Ja, gebruik prompt caching. Het zal je kosten drastisch verlagen.
Maar, wees slim. Zet het niet zomaar voor alles aan.
De Beste Strategie: Cache alleen de stabiele "instructiehandleiding" (System Prompt). Laat de veranderende delen (tool results) vrij doorstromen zonder te worden gecached. Dit geeft je de beste mix van lage kosten en hoge snelheid.

Als je probeert de veranderende delen te cachen, kun je er uiteindelijk voor betalen dat je de "schrijfactie" van de cache betaalt zonder de "leesvoordelen" te krijgen, wat je systeem zelfs kan vertragen.

Technische Samenvatting: Verbreek de Cache Niet: Een Evaluatie van Prompt Caching voor Langdurige Agentische Taken

Probleemstelling

Recente ontwikkelingen in Large Language Model (LLM) agenten hebben complexe, multi-turn agentische taken mogelijk gemaakt die uitgebreide tool-aanroepen omvatten, zoals diepgaand onderzoek en autonome codering. Deze workflows omvatten vaak tientallen API-aanroepen met contextvensters die tientallen duizenden tokens accumuleren, wat resulteert in aanzienlijke operationele kosten en latentie-overhead. Hoewel grote LLM-providers (OpenAI, Anthropic, Google) functies voor prompt caching aanbieden om eerder berekende key-value (KV) tensoren te hergebruiken en redundante berekeningen te verminderen, blijft het specifieke voordeel van deze functies voor agentische workloads onderbelicht. Bestaande literatuur richt zich op geheugenbeheer op inferentieniveau of beveiligingsauditing, maar mist een kwantitatieve analyse van kostenbesparingen of vergelijkende evaluaties van caching-strategieën voor dynamische, multi-turn sessies van agenten.

Methodologie

De auteurs voerden een uitgebreide evaluatie uit van prompt caching bij drie grote LLM-providers: OpenAI, Anthropic en Google. De studie maakte gebruik van vier vlaggenschipmodellen: GPT-5.2, GPT-4o (OpenAI), Claude Sonnet 4.5 (Anthropic) en Gemini 2.5 Pro (Google).

Experimentele Opstelling:

Benchmark: De evaluatie gebruikte de DeepResearch Bench, een multi-turn agentische benchmark waarbij agenten autonoom real-world webzoekopdrachten uitvoeren om complexe, PhD-niveau onderzoeksvragen te beantwoorden.
Schaal: De studie omvatte meer dan 500 agent-sessies met 10.000-token systeemprompts. Elk model werd getest met 40 onafhankelijke sessies per cache-conditie.
Cache-strategieën: De auteurs implementeerden en vergeleken vier verschillende condities om de cache-grenzen precies te controleren met behulp van unieke identificatoren (UUID's):
1. Geen Cache (Baseline): Een UUID wordt voorafgevoegd aan de systeemprompt om de herberekening van alle tokens te forceren, wat een scenario simuleert met dynamische inhoud (bijv. tijdstempels) die de cache verbreekt.
2. Full Context Caching: Geen UUID's worden toegevoegd, waardoor het automatische caching-mechanisme van de provider kan opereren op de volledige gesprekshistorie, inclusief dynamische tool-resultaten.
3. Alleen Systeemprompt Caching: Een UUID wordt aan het einde van de systeemprompt toegevoegd, wat ervoor zorgt dat alleen de statische systeeminstructies worden gecached, terwijl de dynamische gesprekshistorie en tool-resultaten opnieuw worden berekend.
4. Uitsluiten van Tool-resultaten Caching: UUID's worden toegevoegd na de systeemprompt en na elk tool-resultaat, waardoor dynamische tool-outputs expliciet worden uitgesloten van de cache.

Metrieken:
De studie mat API-kosten (onderscheidend tussen standaard, gecachte lees- en cache-schrijftokens) en Time to First Token (TTFT) als de primaire latentie-metriek. Statistische significantie werd bepaald met onafhankelijke steekproeven t-testen ( $\alpha = 0,05$ ).

Belangrijkste Bijdragen

Eerste Kwantitatieve Evaluatie: Dit werk biedt de eerste uitgebreide kwantificering van de voordelen van prompt caching specifiek voor langdurige agentische taken over meerdere providers en modellen.
Strategievergelijking: Het vergelijkt naïeve full-context caching met strategische controlemethoden voor grenzen (alleen systeemprompt, uitsluiten van tool-resultaten), wat onthult dat "naïeve" benaderingen contraproductief kunnen zijn.
Verschillen tussen Providers: De studie identificeert significante verschillen in hoe providers caching implementeren, met name met betrekking tot hoe ze dynamische inhoud afhandelen en de resulterende impact op latentie versus kosten.
Ablatie-inzichten: Door middel van ablatie-studies over promptgroottes (500–50.000 tokens) en het aantal tool-aanroepen (3–50), demonstreren de auteurs universele lineaire kosten- en TTFT-voordelen nadat aan de provider-specifieke token-minimums is voldaan.

Resultaten

De evaluatie leverde drie primaire bevindingen op:

Substantiële Kostenverminderingen: Prompt caching verminderde de API-kosten consistent met 41% tot 80% over alle providers en modellen. De belangrijkste drijfveer van deze besparingen was het cachen van de grote, stabiele systeemprompt.
Variabele Latentieverbeteringen: TTFT-verbeteringen varieerden van 13% tot 31%, afhankelijk van de provider en strategie. Echter, de latentiewinsten waren niet uniform; voor sommige modellen (bijv. GPT-4o) leidde full-context caching tot een latentie-regressie van 8,8%.
Strategische Grenscontrole is Cruciaal: De studie vond dat strategische controle over de prompt cache blokken beter presteert dan naïeve full-context caching.
- Alleen Systeemprompt en Uitsluiten van Tool-resultaten strategieën boden de meest consistente voordelen.
- Full Context Caching introduceerde vaak overhead door dynamische tool-aanroepen en resultaten te cachen die niet worden hergebruikt in volgende sessies, wat paradoxaal genoeg de latentie verhoogt.
- Voor GPT-4o verbeterde de beste strategie (Alleen Systeemprompt) de TTFT met 30,9%, terwijl Full Context Caching de prestaties verslechterde.

Betekenis en Claims

Het artikel beweert voorzien te voorzien in genuanceerde begeleiding voor de implementatie van prompt caching in productie-agentische systemen. De auteurs benadrukken dat hoewel providers veel van het caching-mechanisme abstraheren, beoefenaars strategische controle moeten uitoefenen over de cache-grenzen.

Het kernargument is dat in agentische workloads, waar de context dynamisch en sessie-specifiek is, het cachen van de volledige context (naïeve benadering) nadelig kan zijn. In plaats daarvan moeten beoefenaars ervoor zorgen dat alleen stabiele, herbruikbare inhoud (zoals de systeemprompt) wordt gecached, terwijl dynamische elementen (tool-resultaten, gesprekshistorie) worden uitgesloten via expliciete grenzen (bijv. UUID's). Deze aanpak maximaliseert de kostenefficiëntie en de latentieverbeteringen, door de overhead van het cachen van inhoud die niet zal worden hergebruikt te vermijden. Het werk dient als een praktische gids voor het optimaliseren van enterprise-grade agentische systemen, waarbij wordt benadrukt dat de "beste" caching-strategie provider-specifiek is en afhankelijk is van het optimalisatiedoel (kosten versus latentie).