Waarom harnesses cruciaal zijn voor energie-efficiëntie

Belangrijkste bevindingen

• Harnesses cachen verschillend: We zagen tussen de 1,6% en 11,1% niet-gecachede input bij verschillende clients. "Gecached" is het aandeel input-tokens dat uit de prompt-cache wordt geserveerd in plaats van opnieuw te worden berekend. Bij 92% caching zijn 8 van de 100 tokens niet-gecached, tegenover 3 bij 97%: dit betekent ongeveer 2,7 keer zoveel prefill-werk.
• Een cache-miss verdubbelt ongeveer het energieverbruik van een verzoek: Een "miss" betekent hier een verzoek waarbij weinig tot niets van de prompt is gecached (onder de 10%). Op GLM-5.3 is dit verbruik ongeveer 2,5 keer zo hoog.
• Diepe sessies maken misses kostbaar: Een herlezing betekent dat dat deel van de prompt vanaf nul opnieuw moet worden berekend. Boven de 128k tokens kost één beurt die meer dan de helft van de prompt herleest, qua prefill evenveel als ongeveer 600 normale beurten op diezelfde diepte.
• Het meeste is oplosbaar: Elke cache-break in onze laboratoriumtests werd veroorzaakt door een harness die bewerkte wat er al was verzonden, waardoor een herlezing vanaf het eerste verschil werd afgedwongen.

De rol van de client-harness

Bij Neuralwatt kunnen we zien hoe de agent-harness die een model aanroept, het energieverbruik beïnvloedt. Uit analyse van een maand aan verkeer op onze cloud blijkt dat de harness een verrassend groot aandeel heeft in de hoeveelheid werk die onze GPU's moeten verrichten. Meestal praten we over inference-efficiëntie in termen van het model (aantal actieve parameters, attention-mechanisme) of de hardware (H200 vs B200 vs B300). De client verdient echter ook een nadere blik.

Bijna al ons verkeer is "agentic", waarbij er veel meer input dan output is. Een typische beurt van een coding-agent verzendt 100k tokens of meer aan conversatie en ontvangt een paar honderd tokens terug. Het grootste deel van die input is de prompt van de vorige beurt met een kleine toevoeging aan het einde. Als de eerdere tekst ongewijzigd blijft, heeft de server al zijn key-value (KV) cache en hoeft hij alleen het nieuwe deel te verwerken. Dit is prompt-caching, onze grootste bron van efficiëntie. Het serveren van een gecached token is veel goedkoper dan het opnieuw berekenen ervan.

Caching vereist een exact prefix. Een cache-break treedt op wanneer de harness iets wijzigt dat al is verzonden. We moeten dan alles opnieuw berekenen vanaf het eerste verschil. Een wijziging aan het begin, zelfs een tijdstempel, betekent dat bijna de hele prompt opnieuw moet worden berekend. Een wijziging aan het einde kost weinig. De harness controleert hoe de prompt wordt opgebouwd.

Zelfde model, zelfde prijs, verschillende cache-percentages

Elk verzoek vertelt ons welke client het heeft verzonden. In de periode van 8 september tot 7 oktober 2026 zagen we honderden verschillende clients, waaronder open-source coding-agents zoals OpenCode, Oh My Pi (omp) en Pi, evenals editor-integraties, de OpenAI SDK's en custom apps. OpenCode alleen al wordt gebruikt door ongeveer een kwart van onze klanten.

Voor de meest gebruikte clients is dit het aandeel input-tokens dat we niet uit de cache konden serveren:

(Referentie naar Figuur 1: Niet-gecachede input per client)

Hoewel elke client het overgrote deel van de input cached, tellen de kleine verschillen: een client met 97% caching verzendt drie niet-gecachede tokens per honderd; een client met 92% verzendt er acht. Dat is 2,7 keer zoveel prefill-werk voor dezelfde conversatie.

De hit-rate hangt ook af van de workload, niet alleen van de harness. Langere sessies scoren hoger, omdat de nieuwe tekst van elke beurt een kleiner aandeel van de prompt is. Een zuiverdere maatstaf voor de harness is hoe vaak een beurt de cache doorbreekt: ongeveer 1 op de 100 beurten voor deepseek-harness, tegenover ongeveer 3 op de 100 voor OpenCode en Pi.

De energiekosten van een cache-miss

Omdat wij factureren op basis van gemeten energie, kunnen we de kosten direct zien. In de week van 1 tot 7 oktober 2026 vergeleken we verzoeken op hetzelfde model met dezelfde promptgrootte (ongeveer 50k tokens) en vergelijkbare outputlengte.

(Referentie naar Figuur 2: Extra energie door een cache-miss)

Een verzoek dat grotendeels niet-gecached is, verbruikt ongeveer twee keer zoveel energie als een gecached verzoek van dezelfde grootte. Op GLM-5.3 ligt dit dichter bij tweeënhalf keer. Bovendien concurreert prefill met generatie om dezelfde GPU's, waardoor verspilde prefill de reactietijden voor alle andere gebruikers op die server vertraagt.

Cache-missen worden duur in diepe sessies

We volgden individuele sessies beurt voor beurt op onze drie drukste modellen in de week van 6 tot 13 oktober 2026. We keken naar elke beurt die binnen vijf minuten na de vorige op dezelfde server landde, waar de cache "warm" zou moeten zijn. De meeste cache-breaks waren klein: een paar duizend tokens aan het einde van de prompt werden opnieuw berekend.

Echter, boven de 128k tokens context herleest ongeveer 3 op de 1.000 beurten meer dan de helft van de prompt vanaf nul. Deze weinige beurten zijn verantwoordelijk voor 75% van alle herlezings-tokens op die diepte. Gemiddeld wordt er per beurt zo'n 230k tokens herlezen. Een normale beurt op die diepte voegt mediaan ongeveer 370 nieuwe tokens toe. Eén enkele cache-break kost dus qua prefill evenveel als ongeveer 600 normale beurten.

Ook de vertraging is merkbaar.

(Referentie naar Figuur 3: Tijd tot het eerste token in een diepe sessie)

Ik besteed meer aandacht aan hoe diep in een sessie de cache breekt dan aan hoe vaak dit gebeurt. Een wijziging aan het begin van de prompt kost in het begin weinig. Doe je dit echter bij beurt 200 van een lange sessie, dan resulteert dit in een grote, zichtbare pauze en hoge energiekosten.

Wat veroorzaakt een cache-break?

Ik heb gezocht naar de oorzaken in het laboratorium (waar we elk token kunnen zien) en in productie (waar we alleen metadata zien).

In het laboratorium

We testten vier populaire open-source agents (OpenCode, Pi, omp en Kilo Code) tegen DeepSeek V4.1 Flash en GLM-5.3. Van de 539 verzoeken die volgden op een eerdere beurt in dezelfde conversatie, waren 88% pure toevoegingen (appends). De overige 65 braken de cache. Elke break werd veroorzaakt door de harness die iets wijzigde dat al was verzonden.

Twee oorzaken breken de cache zonder actie van de gebruiker:

1. OpenCode's planningsmodus-herinnering: Na gebruik van de planningsmodus voegt OpenCode een herinnering toe aan elk nieuw gebruikersbericht, om deze in de volgende beurt weer te verwijderen. Hierdoor wordt elke beurt de hele vorige beurt herlezen. OpenCode 2.x lost dit op door de herinnering in een eigen bericht te houden.
2. omp's opschonen van herlezen bestanden: Wanneer een bestand voor de tweede keer wordt gelezen, vervangt omp de eerdere kopie in de geschiedenis door de tekst [Superseded by a newer read of this file]. Dit dwingt een herlezing af vanaf het punt van de wijziging.

Andere oorzaken zijn afhankelijk van het gedrag van de gebruiker:

• Wijzigen van de 'reasoning effort': De templates schrijven het effort-niveau in de eerste paar tokens van de prompt. Een wijziging hierin betekent dat alles opnieuw gelezen moet worden.
• Verbinden of ontkoppelen van een MCP-server: OpenCode 1.x en Kilo Code voegen nieuwe tools alfabetisch toe in het midden van de lijst, wat een cache-break veroorzaakt. OpenCode 2.x voegt alleen een notitie toe aan het einde.
• Toevoegen van een skill: Alle vier de agents listen skills op in de system-prompt, wat leidt tot een herlezing vanaf het punt van de lijst.
• Datumwijzigingen: Clients die de datum in de system-prompt overschrijven, veroorzaken bij het passeren van middernacht een bijna volledige herlezing.
• Compactering: Elke harness doet dit anders. Sommigen herschrijven de samenvatting aan het begin van de prompt, waardoor het grootste deel opnieuw gelezen moet worden.

In productie

Op basis van metadata zagen we dat het wijzigen van de tool-lijst of het effort-niveau de kans op een cache-break meer dan 20 keer zo groot maakt. Hoewel tool-lijstwijzigingen slechts op 0,5% van de beurten voorkomen, zijn ze verantwoordelijk voor 19% van alle herlezings-tokens op deze modellen.

Hoe deepseek-harness de cache intact houdt

In onze tests waren alle vervolgverzoeken van deepseek-harness pure toevoegingen. De volgende praktijken vallen op:

• Append-only sessielog: Verzoeken worden opgebouwd uit een logboek waar alleen aan toegevoegd kan worden.
• Minimale system-prompt: De system-prompt is gefixeerd en bevat geen datum, git-status of OS-informatie.
• Statuswijzigingen aan het einde: Wijzigingen in beleid of skills worden toegevoegd als een korte snapshot aan het einde, waardoor de eerdere tekst intact blijft.
• Stabiele tool-lijst: De lijst blijft gesorteerd en identiek in elke modus.
• Late compactering: De aanroep voor samenvatting hergebruikt het bestaande prefix.
• Impact-reviews: Elk pakket in de repo bevat een sectie over het effect op de KV-cache.

Wat u kunt doen

Als u een harness bouwt of configureert:

• Houd het begin van de prompt bij elke beurt identiek. Voeg nieuwe berichten en tool-resultaten toe aan het einde.
• Plaats geen datum, git-status of andere variabele gegevens in de system-prompt.
• Houd de tool-lijst stabiel en gesorteerd; voeg nieuwe tools toe aan het einde.
• Compacteer pas laat en zorg dat de summarizer-call het exacte prefix van de conversatie hergebruikt.
• Verstuur een stabiele sessie-ID (bij Neuralwatt maakt X-NW-Conversation-ID dit mogelijk).

Als u een harness gebruikt:

• Kies één 'reasoning effort' per sessie in plaats van deze halverwege te wijzigen.
• Voor omp: overweeg compaction.supersedeReads: false.
• Stel instellingen zoals effort, MCP-servers en skills vast voordat de sessie lang wordt.

Inzicht in uw eigen sessies

In het Neuralwatt-dashboard kunnen gebruikers via Session Insights per beurt zien hoeveel van de prompt uit de cache kwam, hoeveel koud berekend moest worden, de tijd tot het eerste token, en de gemeten energie en kosten. Dit stelt ontwikkelaars in staat om harnesses te vergelijken en te controleren of wijzigingen de cache daadwerkelijk "warm" houden.

Onze aanpak bij Neuralwatt

Wij routeren elke sessie terug naar de server die de cache bevat. Bij onze drukste modellen houdt dit al 88–96% van de tokens op de thuisserver. Wanneer een sessie moet verhuizen, zorgt onze gedeelde KV-cache pool ervoor dat de nieuwe server het prefix kan laden in plaats van het opnieuw te berekenen.

Onze volgende stappen zijn het doorgeven van fixes en voorgestelde defaults aan de open-source harnesses die onze klanten het meest gebruiken. Daarnaast onderzoeken we manieren voor de server om gecached werk te hergebruiken na een kleine wijziging aan het begin van de prompt.

Waarom dit meten waardevol is

Een cache-break verschijnt niet als een foutmelding. U krijgt nog steeds uw antwoord, alleen later en met meer energieverbruik. Door de energie per verzoek te meten, zagen we hoeveel deze verspilling oploopt. Het meeste is oplosbaar met een simpele instelling of een kleine aanpassing in de prompt-opbouw.

AI draait op energie. Hoe meer we kunnen inzien, hoe meer we kunnen stoppen met verspillen—of het nu gaat om de sessie van één ontwikkelaar of het volgende datacenter van de industrie.

***

Methodologie: Clients worden geïdentificeerd via de User-Agent header. Energie wordt gemeten als GPU-energie toegerekend aan elk verzoek. Cache-rates zijn berekend over alle modellen van 8 september tot 7 oktober 2026. Analyse van diepe sessies en oorzaken beslaat 6 oktober tot 13 oktober 2026 op DeepSeek V4.1 Flash, GLM-5.3 en GLM-5.3 Flash.

Over de auteur: Chad Gibson is de co-founder en CEO van Neuralwatt. Hij werkte meer dan 20 jaar bij Microsoft voordat hij investeerde in early-stage startups en in 2024 Neuralwatt oprichtte.