Claude Code besteedt driekwart van zijn tokenbudget alleen al aan het lezen van de codebase, volgens een analyse van Red Hat van 219 sessies uit de praktijk. Deze bevinding draait de gebruikelijke aanname om dat AI-gestuurde programmeeragenten tijd verspillen aan het genereren van code, en suggereert dat ontwikkelaars zich moeten richten op het probleem van contextbeheer, en niet alleen op de snelheid van het model.

De data achter de bewering

Red Hat onderzocht 219 interacties met Anthropic's Claude Code en berekende het tokengebruik per beurt. In de steekproef werd bij de mediane beurt 75 % van de tokens toegewezen aan het verwerken van de omliggende code en documentatie, terwijl slechts 25 % naar het produceren van nieuwe regels ging. Omdat de meeste AI-aanbieders input- en outputtokens tegen hetzelfde tarief in rekening brengen, drijft de "lezende" helft van de transactie het grootste deel van de kosten.

Waarom de leeskosten ertoe doen

Optimalisatiestrategie

Veel teams investeren middelen in snellere of grotere modellen, in de hoop dat een snelheidswinst enkele seconden per generatie zal besparen. Als driekwart van het werk simpelweg bestaat uit het ophalen van context, bespaart een sneller model slechts een fractie van de totale tijd. De echte hefboom is hoeveel context het model per beurt moet verwerken.

Kostenbeheersing

Wanneer een AI-assistent bij elke aanvraag dezelfde status van de repository opnieuw leest, lopen de inputtokens enorm op. Projecten met grote contextvensters kunnen te maken krijgen met een dramatische stijging van de facturen, zelfs als de hoeveelheid gegenereerde code bescheiden blijft.

Focus op engineering

Tool-bouwers streven vaak naar een hogere modelkwaliteit, terwijl ze over het oog zien hoe prompts worden geconstrueerd. De analyse suggereert dat "context engineering" – het inkorten, cachen en samenvatten van de code die aan het model wordt gevoerd – een grotere ROI oplevert dan incrementele modelupgrades.

Praktische stappen om de leeskosten te beperken

  • Verwijder irrelevante bestanden – Haal bestanden die de huidige taak niet nodig heeft uit de prompt. Kleinere prompts betekenen minder inputtokens.
  • Cache herhaalde leesacties – Sla de interpretatie van het model van stabiele delen van de codebase op en hergebruik deze in opeenvolgende beurten, in plaats van telkens dezelfde tekst te verzenden.
  • Comprimeer tool-outputs – Wanneer externe tools grote hoeveelheden data teruggeven (bijv. lint-rapporten), vat deze dan samen voordat je ze terug naar Claude stuurt.
  • Gebruik incrementele diffs – Verstuur alleen de wijzigingen sinds de vorige beurt in plaats van de volledige inhoud van het bestand.

Deze tactieken zijn erop gericht te voorkomen dat de AI bij elke interactie dezelfde snapshot van de repository opnieuw leest, wat zowel de latentie als de kosten verlaagt.

Tegenargument: snelheid telt nog steeds

Sommige ontwikkelaars beargumenteren dat een sneller model nog steeds belangrijk is, omdat het de latentie van de 25 % van de tokens die wel worden gegenereerd, vermindert. In latentiegevoelige omgevingen — zoals IDE-plugins die direct moeten reageren — telt elke milliseconde. Het lees-dominante profiel elimineert het voordeel van een sneller model niet; het vermindert simpelweg de relatieve impact ervan.

Waar we op moeten letten

De studie van Red Hat is gebaseerd op een beperkte set sessies, dus een bredere steekproef zou andere tokenverdelingen kunnen laten zien voor andere talen of projectgroottes. Als toekomstige gegevens de 75 % leeswaarde bevestigen, kunnen we een verschuiving zien naar tools die automatisch context inkorten en cachen, of zelfs naar modelarchitecturen die zijn afgestemd op snelle context-inname.

Kernpunt: Voor AI-ondersteund programmeren komt de goedkoopste prestatiewinst voort uit het model minder te voeren, en niet uit het sneller laten schrijven ervan. De cijfers van Red Hat maken een duidelijk punt: kort je prompts in, cache ze en vat ze samen, en je zult tastbare besparingen zien in zowel tijd als geld.