Een truc om tokens te besparen, en waarom ik hem meteen weer heb uitgezet

Een vriend stuurde me een linkje. Spotify had een truc gepubliceerd waarmee ze het tokengebruik van hun AI-coding tool met 90% hadden verlaagd: grote, weinig kritieke bestanden niet zelf laten lezen door het dure model, maar even snel laten samenvatten door een goedkoper model. Bij Spotify was dat een andere clouddienst. Ik liet Claude, de AI-agent waarmee ik dagelijks werk, een eigen variant bouwen: wij draaien al een apart model lokaal op onze eigen server, dus routeert onze versie daarnaartoe in plaats van naar weer een andere clouddienst.

Het werkte, uiteindelijk. Onderweg zaten drie bugs die stuk voor stuk op zichzelf al de moeite waard waren om te vinden.

Drie dingen die niet vanzelf bleken

De eerste keer dat ik het testte hing het gewoon, minutenlang, zonder enige foutmelding. Dat een lokaal model koud moet opstarten, twintig gigabyte aan gewichten vanaf schijf, is op zich bekend. Het probleem was dat de API daar met geen woord over repte, dus zag een trage cold start er van buitenaf identiek uit aan een kapotte aanroep. De tweede keer kreeg ik een lege samenvatting terug terwijl alles leek te werken. Pas toen Claude de ruwe data uit de API zelf ging bekijken kwam het boven water, het model had zijn hele tokenbudget opgemaakt aan verborgen redeneerstappen die niemand had gevraagd, en was klaar voordat het aan het echte antwoord toekwam.

De derde was subtieler. De samenvatting begon steevast met een indrukwekkend klinkend getal, “4.194 beats” de ene keer, “1.914 heartbeats” een andere run. Beide compleet verzonnen. De rest van dezelfde samenvatting klopte wel, namen en details controleerbaar terug te vinden in het bronbestand. Alleen dat ene openingsgetal was uit het niets gegrepen en klonk precies zelfverzekerd genoeg om niet op te vallen.

Het moment dat het echt misging

Ik had de werkende versie ingebouwd en was tevreden. Toen liet ik Claude twee regels tekst zien uit een heel ander gesprek dat op datzelfde moment liep. Een andere sessie las precies datzelfde bestand, niet om het snel door te bladeren maar om een concrete bewering woord voor woord te controleren. Geen samenvatting nodig, de exacte tekst.

De automatisering kon dat verschil niet zien. Zelfde bestand, zelfde actie, en toch compleet andere bedoeling. Was hij daar al actief geweest, dan had die sessie stilletjes een parafrase teruggekregen in plaats van de waarheid die hij nodig had, en dat had ik waarschijnlijk pas veel later gemerkt, als ik het al gemerkt had.

Ik heb hem er dezelfde avond weer uitgehaald.

Wat ik ervan meeneem

De oplossing was niet ingewikkeld. In plaats van een automatisme dat elke keer ongevraagd ingrijpt, is het nu een los stukje gereedschap dat ik zelf bewust moet aanroepen, met een harde weigerlijst voor bestanden waarvan de exacte tekst er altijd toe doet. De besparing blijft overeind voor het werk waar hij voor bedoeld is, alleen grijpt hij niet meer in op het moment dat het juist fout gaat.

De les zit niet in de tokenbesparing, die klopte gewoon. De les is dat elke automatisering die je bouwt getest moet worden op het moment dat hij het verkeerd doet, niet alleen op het moment dat hij het goed doet. Een systeem dat 95% van de tijd tijd bespaart en de overige 5% stilletjes een verkeerd antwoord geeft, is geen 95% werkend systeem. Het is een systeem dat je nog niet hebt zien falen.