Abonnement of per token?

Bij een abonnement is de marginale kosten van nog een poging nul. Je laat de agent gerust twintig keer iets proberen, want het staat los van je rekening. Dat is goed voor experimenteren en slecht voor discipline.

Bij afrekenen per gebruik voel je elke poging. Dat maakt je scherper in wat je vraagt, maar het maakt je ook voorzichtiger op momenten dat doorzetten juist het goede antwoord was. Beide modellen sturen je gedrag; het is nuttig om te weten welke kant op.

Dat effect is sterker dan de meeste mensen verwachten. Onderzoek naar prijsprikkels laat steeds hetzelfde zien: niet de hoogte van het bedrag stuurt gedrag, maar de zichtbaarheid ervan. Een meter die meeloopt verandert wat je durft te proberen, ook als het bedrag klein is. Dat kan gunstig uitpakken, want het dwingt je scherper te formuleren. Het kan ook betekenen dat je een goede richting laat vallen omdat je de derde poging niet aandurft.

Het omgekeerde geldt net zo goed. Bij een abonnement verdwijnt de rem volledig, en dat is precies waarom mensen bij een vast bedrag vaak méér verspillen zonder het te merken. Niet in geld, maar in tijd: uren waarin een agent iets probeerde dat je bij nadenken vooraf had kunnen uitsluiten.

De prijs per eenheid rekenwerk daalt al een paar jaar gestaag, en tegelijk stijgt wat een model per opdracht verbruikt, omdat modellen meer stappen zetten voordat ze antwoorden. Die twee bewegingen heffen elkaar deels op. Wat dat betekent voor jouw rekening is niet te voorspellen, en dat is precies waarom je geen langetermijnbegroting op de prijs van vandaag moet bouwen.

Wat wel voorspelbaar is: het aandeel van je kosten dat naar modellen gaat, groeit naarmate je meer functies erop bouwt. Wie vandaag één AI-functie heeft, betaalt een verwaarloosbaar bedrag. Wie er over een jaar vijf heeft die allemaal bij elk gebruik aangeroepen worden, heeft een kostenpost die om aandacht vraagt.

De praktische conclusie is saai maar houdbaar: bouw je product zo dat je per functie kunt zien wat hij verbruikt en zo dat je een functie kunt uitzetten zonder de rest te slopen. Dan is een prijsverandering een keuze in plaats van een probleem.

De meeste mensen denken dat ze betalen per vraag. Je betaalt in de praktijk per hoeveelheid tekst die heen en weer gaat, en dat is bijna altijd context en niet je eigen vraag. Een opdracht van twee zinnen waarin je vijftig bestanden meestuurt, is vele malen duurder dan een opdracht van twee alinea's met drie bestanden.

Daar komt bij dat een gesprek meegroeit. Elke volgende beurt neemt de hele voorgaande conversatie mee. Een sessie die een uur duurt, wordt aan het eind per beurt duurder dan aan het begin, zonder dat je iets anders bent gaan doen. Wie dat weet, sluit een gesprek af zodra een taak klaar is en begint schoon aan de volgende.

De derde post die mensen missen zijn de stappen die je niet ziet: een agent die een bestand leest, een test draait, de uitvoer terugleest en opnieuw probeert. Eén opdracht van jou kan tien interne rondes zijn. Dat is precies waar de winst zit als het goed gaat, en waar de rekening zit als hij in een lus belandt.

Als we een dag met iemand bouwen en het verbruik loopt op, is de oorzaak vrijwel nooit dat er te veel gedaan werd. Het is bijna altijd dat de opdracht onduidelijk was en de agent bleef proberen te raden wat er bedoeld werd. Verbruik is daarmee een verrassend eerlijke maat voor hoe scherp jouw denken was.

Wat helpt is een korte pauze op het moment dat je merkt dat de derde poging niet dichterbij komt. Niet nog een prompt, maar even opschrijven wat er precies moet gebeuren en waaraan je het afleest. Die vijf minuten verdien je terug.

Wat ook helpt: doe het dure werk vroeg op de dag. Aan het eind van de middag zijn de gesprekken lang, de context zwaar en je eigen oordeel het minst scherp. Dat is de combinatie waarin het geld wegloopt.

Wij kijken naar het soort werk. Voor een bouwdag met scherp afgebakende taken werkt afrekenen per gebruik prima en is het vaak zuiniger. Voor verkennend werk waarin je veel doodlopende wegen inloopt, is een vast bedrag rustiger: dan wil je niet dat de meter meekijkt terwijl je nadenkt.

Wie een AI-functie in zijn eigen app bouwt, erft dit vraagstuk. Je betaalt zelf per gebruik aan een modelaanbieder, maar je klant betaalt jou waarschijnlijk per maand. Dat gat is precies waar marges verdwijnen: één klant die je functie tien keer zo intensief gebruikt als de rest, eet de winst van twintig anderen op.

Er zijn drie manieren om dat op te vangen, en ze zijn allemaal saai. Een limiet per klant, een tarief dat meebeweegt met gebruik, of een functie die zo is ontworpen dat intensief gebruik technisch niet mogelijk is. Wat niet werkt is hopen dat het gemiddelde standhoudt, want bij dit soort functies is het gemiddelde zelden representatief.

Denk hier vroeg over na, want het raakt je ontwerp. Een functie die per klik een model aanroept, is fundamenteel anders te begroten dan een functie die één keer per dag iets samenvat. Dat is een productkeuze, geen boekhoudkundige.