Het getal dat AI gratis doet lijken
Bereken één stuk werk op beide manieren. Een supportticket dat door een model wordt getrieerd - lezen, classificeren, routeren, de ontvangstbevestiging opstellen - verbruikt ongeveer 500 tokens in en 50 uit, wat op Haiku 4.5 tegen gepubliceerde tarieven uitkomt op $0.00075. Datzelfde ticket dat door een mens wordt afgehandeld tegen $22 per uur aan volledig belaste kosten, dertig tickets per uur, kost $0.73. Dat is een verschil van ruwweg 978 keer, en elk getal daarin is een aanname die je kunt aanpassen: betaal $30 per uur, handel 20 tickets af, gebruik een groter model, het verschil blijft drie ordes van grootte breed.
| Taak | Kosten / taak |
|---|---|
| AI · Haiku 4.5 | $0,00075 |
| Een mens | $0,73 |
| Mensen vs AI | ~978× |
Wat één taak kost
Tickettriage, gemodelleerd · logaritmische schaal, elke rasterlijn is 10×
Gemodelleerd, niet gemeten: triage op Haiku 4.5 tegen gepubliceerde tarieven (500 tokens in tegen $1 / 1M, 50 uit tegen $5 / 1M = $0.00075) tegenover een mens met $22 per uur aan volledig belaste kosten die 30 tickets per uur afhandelt ($0.73). De schaal is logaritmisch. Het loon, de doorvoer en de tokenaantallen zijn invoerwaarden die je door je eigen cijfers moet vervangen; het verschil overleeft elke realistische set daarvan.
Getallen als deze laten AI aanvoelen als een automatisch ja, en het is precies zo dat ondernemers teleurgesteld raken. Want de prijs per taak is niet de beslissing. Het is het kleinste getal in de kamer.
De echte bepalende factor is de build
Tussen jou en die fracties van een cent staat een vaste kostenpost: iemand moet de functie bouwen. Hem koppelen aan je ticketsysteem, de prompts schrijven en testen, de randgevallen afhandelen, er een controlescherm voor plaatsen, hem uitrollen. Of dat nu een script van $3,000 is of een integratie van $20,000, het hangt af van de omvang, en het gedraagt zich als elke andere kapitaalbeslissing die je bedrijf neemt: het moet worden terugverdiend uit de besparingen, maand na maand. AI heeft die logica niet weggenomen; het maakte alleen de marginale kosten zo klein dat de build vrijwel de hele investering is. Als je dit afweegt tegen het kopen van een kant-en-klare tool, is dat een beslissing op zich, maar de rekensom hieronder werkt in beide gevallen hetzelfde.
De break-evenformule
Het hele model past op één regel: terugverdientijd in maanden = bouwkosten ÷ (taken per maand × besparing per taak), waarbij de besparing per taak is wat een mens kost om het te doen minus wat het model kost. Volledig belaste uurkosten gedeeld door taken per uur geeft de menselijke kant; de tokenberekening geeft de AI-kant. Drie invoerwaarden, één deling, en elk daarvan mag je corrigeren: je lonen, je doorvoer, je offerte.
Dezelfde build bij drie volumes
| Volume | Break-even |
|---|---|
| 10,000 taken / mo | ~5 weken |
| 3,000 taken / mo | ~3,7 mo |
| 300 taken / mo | ~3 yr |
Dezelfde build bij drie volumes
Build $8,000; elke taak: AI ~$0,00075 vs een mens ~$0,73 (gemodelleerd)
Cumulatieve kosten van mensen die de taak doen (drie volumes) tegenover eenmalig bouwen voor $8,000 en draaien op AI. Taakaannames zoals in de grafiek hierboven; AI-verbruik bij deze volumes is $0.23 tot $7.50 per maand, dus de amberkleurige lijn wordt vlak getekend. Break-even ligt op ongeveer 5 weken bij 10,000 taken per maand, 3.6 maanden bij 3,000, en ruwweg 3 jaar bij 300. Vul je eigen loon, doorvoer en bouwofferte in; het gaat om de vorm.
Dit is de grafiek die de meeste wel-of-niet-bouwen discussies beslecht, want het enige dat verandert tussen de drie lijnen is volume. Bij 10,000 taken per maand is de build van $8,000 in ongeveer vijf weken terugverdiend; dezelfde build bij 300 taken per maand sleept zich voort over ruwweg drie jaar, wat in softwaretermen een totaal andere beslissing is. Er veranderde niets aan het model, de prompts of de kwaliteit. Volume alleen verschoof het antwoord van een duidelijk ja naar een waarschijnlijk nee.
De terugverdientabel
Zoek je kolom, zoek je offerte, en je hebt een verdedigbaar eerste antwoord voordat iemand een IDE opent.
| 300 taken / mo | 1,000 / mo | 3,000 / mo | 10,000 / mo | |
|---|---|---|---|---|
| Maandelijkse besparing | $220 | $733 | $2,198 | $7,326 |
| $3,000 build verdient zich terug in | 13.7 mo | 4.1 mo | 1.4 mo | 0.4 mo |
| $8,000 build | 36.4 mo | 10.9 mo | 3.6 mo | 1.1 mo |
| $20,000 build | 91.0 mo | 27.3 mo | 9.1 mo | 2.7 mo |
Twee eerlijke lezingen van die tabel. Van boven naar beneden in een kolom: discipline in de omvang loont, want bij 1,000 taken per maand is het verschil tussen een build van $3,000 en een van $20,000 het verschil tussen vier maanden en twee jaar. Van links naar rechts in een rij: volume is hefboomwerking, want dezelfde build van $8,000 verschuift van een afrondingsfout naar onverdedigbaar, afhankelijk van hoeveel taken je er werkelijk doorheen stuurt. Wanneer een schatting in het grijze midden belandt, is het goedkoopste experiment meestal een kleinere build die de volume-aanname test, niet een grotere build die erop gokt.
Wanneer de tokenprijs wél uitmaakt
Triage is een goedkope taak; niet alles is dat. Een schrijfopdracht die een briefing van 2,000 tokens leest en een document van 1,500 tokens schrijft op Opus 4.8 kost ongeveer $0.05 per taak, en werk met lange context kan daar ruim overheen gaan. Het verhoudt zich nog steeds tot $0.37 voor een enkele minuut menselijke tijd, dus het verschil blijft bestaan, maar bij tienduizenden taken is de marginale lijn geen decoratie meer: het is het verschil tussen tokens die $8 per maand kosten en $500. Daar haken de verborgen vermenigvuldigers uit deel één en de hendels uit deel twee in op dit model: ze veranderen de besparing per taak, wat de terugverdientijd verkort. Ze draaien de bouwbeslissing zelden op eigen kracht om, maar ze bepalen hoe goed een goede beslissing wordt.
Wat dit model buiten beschouwing laat
Eerlijkheid over de envelop. Als een mens nog steeds elke output controleert, is je besparing per taak het verschil in controletijd, niet de volle $0.73, en rekt de terugverdientijd navenant op; het model verdient zijn plek waar het de meeste taken volledig afrondt en de rest escaleert. Fouten hebben een prijs die deze formule niet ziet, dus taken waarbij een verkeerd antwoord duur is, hebben een goedkope controle in de lus nodig voordat de volumeberekening iets betekent. En de build is niet de laatste factuur: prompts verlopen, systemen veranderen, iemand onderhoudt de integratie. Niets daarvan breekt het model; het hoort gewoon thuis in de bouwkolom, en een pilot die is afgestemd om je volume-aanname te testen, is de goedkoopste manier om te ontdekken wat de cijfers werkelijk zijn.
