Waarom token efficiëntie jouw project kan maken of breken
Applicaties bouwen is eenvoudiger geworden. De drempel is verlaagd, de tools zijn krachtiger, en AI doet het zware werk. Maar er is een addertje onder het gras dat niemand je vertelt: je moet ontzettend nieuwsgierig en autodidactisch zijn, anders ga je verliezen in een AI-wereld. Niet omdat je de technologie niet begrijpt, maar omdat je de kostenstructuur niet begrijpt.
Vandaag had ik zo’n moment. Vanuit mijn openclaw systeem kan ik meerdere AI-modellen kiezen, maar het kernmodel waarmee gewerkt wordt is Claude met Opus 4.8. Dit model is niet bijzonder token efficiënt, en dat voelde ik financieel. En als je zoals ik met mega prompts werkt van 3 tot 5 pagina’s per iteratie, dan tikt dat aan.
Dit artikel is mijn evaluatie: wat gebeurt er? Waarom? Wat kun je er aan veranderen? En belangrijker nog – wat als je even wacht met je project?
Wat zijn tokens en waarom rekenen AI-providers er zo veel voor?
Tokens zijn de basiseenheid waarmee taalmodellen tekst verwerken. Eén token komt ruwweg overeen met 4 karakters of ongeveer 0,75 woord in het Nederlands. Het woord “applicatie” kost 2 tot 3 tokens. Een pagina tekst is al snel 500 tokens.
AI-providers rekenen per token, en dat gebeurt in twee richtingen:
- Input tokens: alles wat je naar het model stuurt, inclusief eerdere berichten in het gesprek
- Output tokens: alles wat het model teruggeeft, vaak duurder dan input
Bij premium modellen zoals Opus liggen de kosten per token aanzienlijk hoger dan bij lichtere modellen. Dat is de prijs die je betaalt voor superieure redeneercapaciteit. Maar voor routinematige codeerwerkzaamheden is die capaciteit vaak overkill.
Mega prompts uitgelegd: het dubbelgeslepen zwaard
Een mega prompt is een uitgebreide, gedetailleerde instructie die een compleet beeld geeft van wat je wilt bouwen. Mijn gemiddelde applicatie-prompt bevat:
- Volledige projectstructuur en bestandsorganisatie
- Technische stack specificaties met versies en configuratie
- UI/UX vereisten met gedetailleerde componentbeschrijvingen
- API-integratie details inclusief endpoints en dataformaten
- State management architectuur en dataflow
- Error handling protocollen
- Testing strategie en edge cases
- Deployment instructies en PWA-configuratie
Zo’n prompt van 5 pagina’s bevat snel 2.000 tot 3.000 tokens aan input alleen. En hier is het kritieke inzicht: bij elke volgende iteratie in hetzelfde gesprek worden al die tokens opnieuw meegestuurd en opnieuw in rekening gebracht. Na vijf iteraties heb je 15.000 tokens input verbruikt voordat het model één regel code heeft geschreven.
Voorbeeld: PWA Taakbeheer Applicatie
Stel je bouwt een Progressive Web App voor taakbeheer. Je start met een mega prompt waarin je de volledige architectuur beschrijft: React met Vite, PWA-configuratie met service workers, offline synchronisatie, push notificaties, en een Stripe-integratie voor abonnementen.
De prompt is indrukwekkend. Het model begrijpt precies wat je wilt. Maar bij elke correctie, elke vraag, elke iteratie stuurt het model de volledige context opnieuw door zijn netwerk. Bij Opus-prijzen betekent dit dat een simpele correctie aan je billing code je al snel een substantieel bedrag kost, niet omdat de correctie complex is, maar omdat je de hele applicatiecontext steeds opnieuw betaalt.
Het sterke tegenargument: zijn grote modellen soms goedkoper?
Voordat ik Opus afschilder als de schuldige, moet ik eerlijk zijn over het tegenargument. Grotere, duurdere modellen kunnen soms goedkoper zijn in totale kosten, omdat ze in één iteratie begrijpen wat een lichter model in drie iteraties pas snapt. Als Sonnet drie pogingen nodig heeft om je billing logica correct te implementeren en Opus het in één keer goed doet, dan kan Opus ondanks hogere kosten per token uiteindelijk goedkoper zijn.
Dit is geen theoretisch argument. Het is realiteit. Het probleem is niet per se het model. Het probleem is dat ik niet strategisch schakel tussen modellen op basis van taakcomplexiteit. Ik had de architectuur met Opus moeten doen, de routinematige code met Sonnet, en de iteratieve correcties met Haiku. In plaats daarvan bleef ik op Opus draaien voor alles, en dat is waar het financieel pijn deed.
Wat gebeurde er precies? Een case study
Mijn applicatie was al live en bijna klaar. Eén kritiek probleem: de billing code werkte niet correct met mijn betaalmuur. De oorzaak was een combinatie van prijsstelling en technische complexiteit die ik niet had kunnen oplossen. Het resultaat was dat gebruikers niet konden betalen voor hun abonnement, wat de applicatie volledig waardeloos maakte.
De beslissing leek logisch: terug naar de tekentafel, plan vereenvoudigen, opnieuw uitvoeren. Want dat is toch vaak de essentie: complexiteit reduceren totdat het probleem beheersbaar wordt.
Maar de uitvoering liep mis. Hoge tokenconsumptie sloeg toe en dwong een pauze af. Gelukkig staat automatische bijbetaling uit, anders was dit een vervelend financieel scenario geworden.
Wat ging er mis in de uitvoering?
- De prompt groeide met elke revisie in plaats van te krimpen
- Het model hield vast aan oude complexe structuren in plaats van te vereenvoudigen
- Iteratieve correcties vereisten herhaaldelijk volledige context versturen
- Er was geen strategie voor contextcompressie of modelswitching
Token efficiëntie optimaliseren: concrete strategieën
Model selectie per taak
Gebruik een hiërarchische aanpak in plaats van één model voor alles:
- Opus voor architectuur, complexe redeneerproblemen, en lastige debugging
- Sonnet voor reguliere codeerwerkzaamheden en feature implementatie
- Haiku voor iteratieve correcties, refactoring, en eenvoudige aanpassingen
Dit alleen al kan je tokenuitgaven met 50 tot 70% reduceren zonder kwaliteitsverlies.
Prompt segmentatie in plaats van mega prompts
Splits je mega prompt op in fasen in plaats van alles in één keer te sturen:
- Fase 1: Architectuur en setup
- Fase 2: Core functionaliteit
- Fase 3: UI componenten
- Fase 4: Integratie en testing
Elke fase krijgt een gerichte, kleinere prompt. De totale tokenhuishouding daalt drastisch omdat je niet bij elke iteratie de volledige applicatiecontext meeneemt.
Context compressie
Verwijder voltooide instructies uit je prompt naarmate je vordert. Als fase 1 klaar is, stuur dan alleen een samenvatting van het resultaat mee naar fase 2, niet de volledige originele instructie. Dit vereist discipline maar levert direct besparing op.
Caching en hergebruik
Bewaar werkende code en prompts. Hergebruik bewezen patronen in plaats van alles opnieuw te genereren. Een bibliotheek van werkende componentprompten bespaart niet alleen tokens maar ook tijd.
Moet je wachten op betere model efficiëntie?
Dit is de vraag die ik mezelf stelde toen ik de pauzeknop indrukte. AI-modellen evolueren snel en token efficiëntie verbetert met elke generatie. Wachten lijkt aantrekkelijk.
Het sterke argument tegen wachten: de basisprincipes van token optimalisatie veranderen niet. Modelselectie per taak, prompt segmentatie, en contextcompressie blijven relevant, ongeacht welk model je gebruikt. Als je dit niet nu leert, ga je hetzelfde probleem hebben met de volgende generatie modellen, alleen dan met grotere getallen.
Daarnaast verdwijnt concurrentievoordeel snel. De leercurve van efficiënt AI-ontwikkelen wordt niet kleiner door te wachten. Het wordt alleen minder pijnlijk als je het nu leert met een project zonder deadline, in plaats van later met een klant die op je wacht.
Mijn advies: wacht niet op betere modellen. Pas je strategie aan. Het probleem is niet het model. Het probleem is de methode.
De belangrijkste les: complexiteit is de vijand
De leukste leerles van deze applicatie was niet over tokens. Het was over complexiteit. Een applicatie waardeloos maken kan door één kritiek onderdeel dat niet werkt, in dit geval de billing. En de neiging om complexiteit toe te voegen in plaats van af te nemen is precies wat leidt tot uit de hand lopende tokenconsumptie.
Vereenvoudigen is de essentie. Niet alleen van je applicatie, maar van je prompts, je modelkeuze, en je ontwikkelproces.