Een miljard Token per dag verbranden? De AI-rekening van programmeurs straft de 'luie mensen'

Doelpubliek: Ontwikkelaars die AI-programmeertools (zoals Cursor, Windsurf, trae...) gebruiken, en technische managers die weinig besef hebben van de kosten van AI.

Kernpunt: Token is niet alleen een eenvoudige factureringsunit, maar een 'aandachtsbron' en 'rekenkrachtvaluta'. Het misbruik van de Agent-modus en het negeren van contextbeheer is in feite het verbergen van strategische luiheid (zelf niet nadenken) met tactische ijver (AI maar laten aanrommelen).

Je 'AI-uitgaven' kunnen hoger zijn dan je salaris

Een paar dagen geleden heb ik mijn Token-rekening gecontroleerd. Toen ik dat cijfer zag, schrok ik een beetje: 10 miljoen Token. Let op, dit is niet het verbruik van een maand, maar van één dag.

Ik dacht dat dit extreem was. Later heb ik een korte video over Token-berekeningen gepost.

De reacties lieten me zien wat 'buiten de grenzen' betekent.

De onderstaande afbeelding is een screenshot van het dagelijkse verbruik van 200 miljoen Token door de internetgebruiker '老K的日常':

Aanvankelijk dacht ik dat het een uitzondering was, maar toen veel gebruikers reageerden dat ze dagelijks 100 miljoen verbruikten, begreep ik dat dit een veelvoorkomend fenomeen is.

Wat betekent 100 miljoen Token? Als we uitgaan van de gebruikelijke factureringsniveaus van 'bepaalde mainstream commerciële modellen' (input/output apart gefactureerd, samen ruwweg geschat op $10 / miljoen Token), dan wordt er op één dag $1000 verbrand. 7000 RMB per dag. Het maandsalaris van veel junior programmeurs is mogelijk niet genoeg voor AI om deze ene dag te 'denken'.

(Opmerking: De prijzen verschillen sterk per model/leverancier, en de eenheidsprijzen voor input en output zijn vaak ook niet hetzelfde. Het doel hier is niet om tot achter de komma te rekenen, maar eerst een 'gevoel voor de orde van grootte' te creëren.)

Als je het zelf wilt narekenen, is er meestal deze formule (negeer speciale regels zoals cache/kortingen): kosten ≈ (inputToken / 1.000.000) × prijs_in + (outputToken / 1.000.000) × prijs_out

Dit is zo contra-intuïtief. We denken altijd dat AI goedkoop is, OpenAI gaat zelfs de prijzen verlagen. Maar waarom explodeert het Token-verbruik in de praktijk exponentieel?

Vandaag neem ik je mee in een diepgaande analyse van de logica achter dit 'Token-zwarte gat', en hoe we de schade kunnen beperken.

1. Waarom explodeert Token 'exponentieel'?

Veel broeders hebben helemaal geen idee van de omvang van Token. Ze denken: 'Ach, het is maar een paar regels code sturen, hoeveel kan dat zijn?'

1. Reken een duidelijke rekening uit

Laten we eerst een kwantitatief besef opbouwen dat in de praktijk bruikbaar is. Om het duidelijk te zeggen: Token is niet het aantal woorden, en ook niet het aantal karakters. Het zijn 'coderingsfragmenten' nadat de modeltekst is opgesplitst. Verschillende modellen gebruiken verschillende tokenizers, dus we kunnen alleen een bereik geven, geen 'universele constante'.

Beschouw de volgende cijfers als een 'schattingsliniaal' (het doel is om de orde van grootte te beoordelen, kosten in te schatten en beslissingen te nemen om schade te beperken):

• 1 Chinees karakter: Meestal 1–2 Token (hoogfrequente karakters dichter bij 1, zeldzame karakters/combinaties eerder 2–3)
• 1 Engels woord: Meestal ongeveer 1,2–1,5 Token (voor ruwe schattingen kan 1,3 ook)
• 1 regel code ≈ 10–50 Token (inclusief inspringing, commentaar, type declaraties)
  • Beknopte bedrijfslogica ≈ 12–20 Token
  • Met type annotaties, interface, JSDoc, 4-spaties inspringing ≈ 20–35 Token
  • Met veel import / decorators / commentaar ≈ 30–50+ Token
• 1 bronbestand (400–600 regels, modern TS/Java project) ≈ 4.000–24.000 Token komt vaak voor (mediaan ≈ 12.000–18.000)
• 1 middelgroot project (100–200 bronbestanden, alleen src/, exclusief node_modules/ / gegenereerde code)
  • Alleen al het 'doorlezen' van de kernbroncode begint vaak bij een miljoen Token
  • Als je ook tests, configuratie, scripts, afhankelijkheidsverklaringen, logs erbij stopt, is het niet vreemd om miljoenen Tokens te bereiken

Moderne front-end projecten zijn in TypeScript, vol met complexe Interface definities; of in Java, met tientallen regels Import. Deze 'sjablooncode' zijn eigenlijk Token-killers. In een middelgroot project met 100 bestanden kan alleen al het 'laten lezen' van de code door AI 1 miljoen Token kosten.

2. Het 'sneeuwbaleffect' van token

Het engste aan Token-verbruik is niet een enkel gesprek, maar de contextaccumulatie in meerdere gespreksronden.

Het mechanisme van LLM is stateless. Om ervoor te zorgen dat AI zich herinnert wat je eerder zei, stuurt het systeem meestal 'systeemprompts + gespreksgeschiedenis + door jou geciteerde bestanden/codefragmenten + tool-uitvoer (zoals zoekresultaten, foutlogs)' samen naar het model. Je denkt dat je maar één vraag stelde, maar in feite betaal je steeds voor het 'hele contextpakket'.

• Ronde 1: Verzend 10.000 Token, AI antwoordt met 1.000.
• Ronde 2: Verzend (10.000 + 1.000 + nieuwe vraag), AI antwoordt...
• Ronde 10: Je Context is mogelijk al opgeblazen tot 200.000 Token.

Op dat moment, zelfs als je alleen maar vraagt 'help me een variabelenaam te veranderen', kost dat 200.000 Token. Daarom heb je het gevoel dat je niets doet, terwijl de rekening omhoogschiet.

Wat nog erger is: De Agent-modus 'leest actief bestanden'. Bij een opdracht als 'help me de gebruikersmodule te optimaliseren', kan het eerst de relevante directory scannen, dan naar afhankelijkheden gaan, dan naar configuratie, dan naar tests... Het is niet lui, het is 'zijn plicht doen volgens het standaardbeleid', en het standaardbeleid is vaak: veel lezen, veel proberen, veel itereren.

2. Twee soorten 'luiheid' die je technische vaardigheden vernietigen

Na analyse van de reacties van die 'honderdmiljoenen-broeders', ontdekte ik dat de oorzaak van de Token-explosie niet alleen ligt in het verbruiksmechanisme van AI, maar ook sterk samenhangt met menselijke luiheid.

Hier zijn twee typische 'denkluiheden'.

Luiheid één: De afstandelijke baas

Herken je deze houding ook:

• 'Dit oude project is te rommelig, ik heb geen zin om de logica te bekijken, ik gooi het gewoon naar AI.'
• 'Cursor heeft een Agent-modus, geweldig, laat het zelf de Bug maar fixen.'

Dus gooi je de hele src map naar de Agent, met een vage instructie: 'Help me de gebruikersmodule te optimaliseren.' De Agent gaat aan het werk:

• Het leest 50 bestanden (verbruikt 500.000).
• Het ontdekt verwijzingen naar utils, en leest de hulpfuncties (verbruikt 200.000).
• Het probeert aanpassingen, krijgt een foutmelding, leest de foutlog (verbruikt 100.000).
• Het probeert te repareren, krijgt weer een foutmelding...

Het probeert als een gek, verbruikt als een gek Token. En jij? Je zit op je telefoon, denkend dat je zo efficiënt bent. De waarheid is: je ruilt geld voor 'schijnefficiëntie', en produceert een hoop code die je later niet kunt onderhouden.

Meer professioneel gezegd zijn er twee soorten verlies:

• Kostenlaag: Input Token wordt groter, iteraties nemen toe, kosten stapelen lineair op
• Technische laag: Je verliest context en beslissingsbevoegdheid, en houdt alleen een oncontroleerbaar systeem over dat 'maar werkt'

Luiheid twee: Het alles-door-elkaar-gooien type

Hoe gooi je een Bug naar AI? Kopieer je gewoon de hele foutconsole met Ctrl+A, of laat je AI zelf zoeken met @Codebase?

Dit heet 'alles door elkaar gooien'. Je hebt geen zin om de kern van het probleem te lokaliseren, of om cruciale codefragmenten te filteren. Je gooit 99% onbruikbare informatie (ruis) en 1% bruikbare informatie (signaal) in één keer naar AI.

AI is als een versterker.

• Geef je het duidelijke logica (signaal), dan versterkt het je wijsheid, gebruikt weinig Token, goed resultaat.
• Geef je het chaos en vaagheid, dan versterkt het je chaos, Token schiet omhoog, produceert rommel.

3. Oplossing: Hoe AI efficiënt te gebruiken en Token-verbruik te verminderen

Om je portemonnee te beschermen, en nog belangrijker, je technische controle te behouden, moeten we de samenwerkingsmodus met AI veranderen.

1. Principe van minimale context

Dit is het eerste principe van AI-programmeren. Geef AI altijd alleen de minimale codeset die nodig is om het huidige probleem op te lossen.

In Cursor, maak goed gebruik van deze operatoren:

• @File: Verwijs alleen naar relevante bestanden, niet de hele map.
• Ctrl+L code selecteren: Stuur alleen de 50 regels code die je met de cursor selecteert naar Chat, niet het hele bestand.
• @Docs: Voor externe bibliotheken, verwijs naar documentatie in plaats van het te laten raden.

Dit is een gestructureerde, herbruikbare SOP die ik vaak gebruik (volg dit en je ziet het Token-verbruik zichtbaar dalen):

De betekenis van deze tekst is: Let bij samenwerking met AI op efficiëntie en precisie. Concreet betekent dit:

• Stel eerst het doel vast: Vertel AI bondig en duidelijk wat het huidige probleem is en wat het gewenste resultaat is, laat het niet zelf raden.
• Vereenvoudig probleemreproductie: Gebruik de eenvoudigste methode om het probleem te reproduceren, plak minimale en cruciale code, gooi niet een hoop irrelevante dingen erbij.
• Geef minimale noodzakelijke informatie: Geef alleen relevante 1-3 bestanden, sleutelfuncties en de eerste paar regels van de foutstack, geen volledige informatie.
• Vraag om wijzigingspunten terug: Laat AI alleen vertellen wat er gewijzigd moet worden en waarom, niet het hele codebestand herschrijven.
• Controleer zelf uiteindelijk: Doe een korte verificatie, zorg dat de wijzigingen elders geen effect hebben.

Kortom, gebruik de minste, meest cruciale informatie om AI te laten werken, en behoud de uiteindelijke controle en beoordelingsbevoegdheid.

2. Ook het belangrijkste: Eerst denken, dan Prompten, eerst plannen, dan handelen

Voordat je op Enter drukt, dwing jezelf om 10 seconden te pauzeren en jezelf drie vragen te stellen:

• Welk probleem los ik op? (Definieer grenzen)
• Welke kernmodules zijn bij dit probleem betrokken? (Filter Context)
• Als ik het zelf zou schrijven, hoe zou ik het dan doen? (Geef ideeën)

Jij bent de 1, AI is de nullen erachter. Als de 1 niet stevig staat, zijn de nullen erachter slechts zinloos verbruik.

Een paar oprechte woorden

Het verhaal van 'honderd miljoen Token per dag' zal misschien niet bij iedereen gebeuren. Maar verspillend Token-gedrag heeft bijna elke programmeur die AI gebruikt wel eens meegemaakt.

AI maakt programmeren weliswaar eenvoudiger, maar er zijn nog steeds drempels. Alleen wie het echt kan gebruiken, krijgt vleugels.

Vroeger kon je slechte code alleen collega's 'irriteren'. Nu wordt je luiheid direct een cijfer op de rekening, en straft je jezelf met stijgende kosten.

Dus, wees geen 'afstandelijke baas'. Wees een diepdenkende, precieze, eerst plannen dan handelende AI-architect. Dat is ook onze grootste onvervangbaarheid in dit tijdperk.