Als je dagelijks coding-agents draait, valt iets op. Sommige weken oogt de rekening bijna saai. Dan komen er scherpe pieken — vaak op dagen waarop iemand per ongeluk een oude chat op een andere machine opende “voor één vraag.” Dat is geen magie. Dat is prompt-cache hit-rate.
Dit is een praktische veldnotitie uit het werken met Grok-achtige agents op echte infrastructuur: multisite, API’s, ops. Dezelfde economie geldt voor elke assistent die inputtokens rekent en een gecachte prefix aanbiedt.
Waar je echt voor betaalt
Elke modelbeurt is grofweg twee hopen tokens:
- Prefix — systeeminstructies, tooldefinities, skills, projectregels en eerdere beurten die de provider als stabiel blok kan behandelen.
- Suffix — je laatste bericht, verse toolresultaten, nieuwe file-dumps.
Heeft de provider die prefix recent identiek gezien, dan kan het grootste deel als cache read worden afgerekend in plaats van volle inputprijs. Wijzigt de prefix — of is de cache koud — dan betaal je de hele prompt opnieuw.
Lage kosten betekenen dus niet “het model is gratis.” Ze betekenen cache_read ≫ uncached input vanaf beurt twee. Hit-rate is de knop die lang agentwerk betaalbaar houdt.
De eenheid is de sessie, niet het label “API’s”
Mensen horen “zelfde vakgebied” en denken aan een magische emmer API’s of WordPress. Caching werkt niet op labels. Het werkt op byte-stabiele continuïteit:
- zelfde conversatielijn (dezelfde sessie hervatten),
- zelfde model,
- zelfde werkmap en projectregels,
- zelfde tools/skills voor die run.
Blijf in één langlevende sessie terwijl je eerst de ene API aanpast en daarna een verwante service, en je profiteert nog steeds. Systeemprompt, tools en eerdere beurten blijven een warme prefix; alleen het nieuwe werk zit in de suffix. Start voor elke microservice een gloednieuwe sessie omdat “het allebei API’s zijn,” en je gooit die warmte elke keer weg.
Waarom oude sessies op een andere workstation pijn doen
- Andere machine en directory — andere checkout, andere rules, andere session store. Andere prefix.
- Koude provider-cache — na idle time moet je opnieuw opwarmen, vaak tegen volle prijs.
- Fossiele geschiedenis — een weekoude megathread is duur bij cache-miss en ruisig voor de agent.
De fix is saai: benoem een paar duurzame sessies per workstream, hervat die op de host waar het werk hoort, en begin fris als de oude thread niet meer de klus is.
Wat de prefix stabiel houdt
| Doen | Waarom |
|---|---|
| Eén lange sessie per workstream | Prefix groeit; latere beurten zijn vooral cache read. |
| Hervatten op id of duidelijke titel | Voorkomt per ongeluk koude zombies. |
| Zelfde host en projectdirectory | Rules en session-grouping blijven gelijk. |
| Zelfde model in de thread | Modelwissel = nieuwe cache-namespace. |
| Stabiele skills / MCP / projectregels | Geknoei herschrijft de prefix. |
| Korte follow-ups in dezelfde thread | Kleine suffix, dikke gecachte prefix. |
Wat de cache (en het budget) breekt
- Nieuwe sessie voor elk klein verzoek (zeker headless zonder resume).
- Modelhoppen mid-thread.
- Elk uur MCP’s en skills aan/uit.
- Elke beurt hele files plakken terwijl een pad volstaat.
- Subagents voor werk dat in één zoekactie past — elk kind is vaak een koude prefix.
- Sesies forken voor een zijvraag.
Compaction is niet de vijand — sessiehoppen wel
Lange threads raken de contextlimiet. Compaction kapt geschiedenis bij zodat de agent kan doorgaan. Dat verandert de prefix, dus de cache moet opnieuw warmen. Dat is meestal nog goedkoper dan de klus verlaten voor een willekeurige oude chat op een laptop, of opnieuw beginnen zonder de beslissingen die je al hebt betaald.
Compact wanneer de thread lang is maar nog dezelfde klus. Nieuwe sessie wanneer het onderwerp echt nieuw is. Niet elke beurt compacten “om te sparen”; dan forceer je alleen herhaald opwarmen.
Een simpel team-playbook
- Sessies benoemen — bijvoorbeeld fleet-wordpress, bank-api, content.
- Werkplek vastzetten — infrastructuurcode waar de bron van waarheid staat; laptop voor lichte of persoonlijke threads.
- Automations moeten resumeren — headless jobs met stabiel session-id, geen cold start per cron.
- Meten — uncached input versus cache read; na een paar beurten moet cache read domineren.
- Brief met continuïteit — “ga door,” “zelfde PR,” “volgende endpoint” slaat het hele ontwerpdocument opnieuw plakken.
Hoe dit in echt werk uitpakt
In een productfamilie — compute, wallets, marketplaces, civic tools — kruist één middag vaak meerdere repo’s die wél één operationeel verhaal delen. Eerst een API-wijziging op de ene service, daarna iets verwants op de andere: precies het patroon dat continue sessies belonen. Gedeelde tooling en eerdere context blijven gecacht; alleen nieuwe diffs en tooltraces zijn nieuw.
Omgekeerd: “ik opende de chat van vorige maand over ads omdat de TUI al open stond” is hoe je een full-price prefix koopt voor een vraag van twee regels.
Prijscheck: Kimi K3 vs Grok 4.5 bij hoge cache hit-rate
Lijstprijzen vertellen het halve verhaal. Bij agentic coding is het grootste deel van een lange sessie herhaalde prefix — systeemprompt, tools, projectregels, eerdere beurten. Zowel Moonshot’s Kimi K3-host als xAI’s Grok 4.5 verkopen die hergebruik goedkoop als cache-read tokens. Het relevante getal is de effectieve inputprijs zodra je hit-rate hoog is.
Cijfers hieronder zijn publieke list rates medio 2026 (USD per 1M tokens). Check altijd live console-docs; acties en long-context tiers schuiven. Voor Grok 4.5 gebruiken we short-context (<200k prompt).
| Model (hosted API) | Input miss | Cache hit / cached input | Output | Context |
|---|---|---|---|---|
| Kimi K3 (Moonshot-host) | $3,00 | $0,30 | $15,00 | ~1M |
| Grok 4.5 (xAI, short context) | $2,00 | $0,30 | $6,00 | 500k (long-context tier is duurder) |
Moonshot noemt publiek >90% cache hit-rate op coding/programming-workloads wanneer prefixes stabiel blijven — precies de lange-sessie-discipline hierboven. Bij 90% hit-rate is de gemengde input per miljoen tokens:
- Kimi K3: 0,9 × $0,30 + 0,1 × $3,00 = $0,57 / 1M inputtokens
- Grok 4.5: 0,9 × $0,30 + 0,1 × $2,00 = $0,48 / 1M inputtokens
Bij dezelfde hoge hit-rate is Grok 4.5’s effectieve input op dit lijstje iets goedkoper, en de output is veel goedkoper ($6 vs $15 per 1M). Agents die veel toolcalls en proza streamen betalen hard op output — dat gat domineert de rekening vaak meer dan een paar cent op blended input.
Kelder de hit-rate (nieuwe sessie per prompt, koude zombie-chat, prefix-thrash), dan schieten beide terug richting volle miss-prijzen: K3 $3 en Grok $2 op input, plus volle output. De operationele les is op beide hosts hetzelfde: bescherm de prefix, meet cache_read, en behandel 90% hit-rate als een target dat je ontwerpt — niet als cadeau van de prijstabel alleen.
K3’s grotere context kan winnen op specifieke jobs (enorme single-shot repo’s). Grok 4.5’s mix van lagere miss-input, gelijke cache-hit-tarief en veel lagere output verklaart waarom een goed gerunde lange Grok-coding-sessie “relatief erg goedkoop” voelt — zolang je in één warme sessie blijft.
Kortom
Zelfde onderwerp, langere stukken, dezelfde levende sessie houdt AI-codingkosten vlak. De discipline is geen mystieke zuinigheid. Het is de cache key beschermen: sessie, model, directory en rules. Zet nieuwigheid in het laatste bericht. Laat de prefix met rust.
Doe dat consequent en dure pieken worden zeldzaam — meestal een koude sessie, een verkeerde host, of een eenmalige vraag die een korte nieuwe thread had moeten zijn in plaats van een fossiel.
3DN gebruikt coding-agents als onderdeel van bouwen en bedrijven van software. Mechanismen hierboven zijn algemeen; productnamen verschillen per leverancier, de economie van prefix-caching niet.
Geef een reactie