AI-kosten per seat: wat Ubers $1.500 zegt over mkb-CRM

Vorige week donderdag, 16:00 Amsterdam, kreeg de ops manager van een uitzendbureau van 40 man (een klant van ons) een Slack-melding van haar CRM-agent. Eén sales rep had die week 1,2 miljoen tokens verbruikt. Ze wist niet wat 1,2 miljoen tokens kostten, wat ze opleverden, of ze zich zorgen moest maken. Die rep was haar topomzetter. Hij had drie deals gesloten. Toen ze het narekende, kwam ze uit op €38.

Diezelfde week liet Uber zijn engineers weten dat hun interne AI-tools afgetopt waren op $1.500 per maand per seat. Het internet vond dat getal opvallend. Het is een nuttig signaal, maar niet om de reden waarop de meeste commentaren aansloegen.

Het getal achter de krantenkop

Ubers cap geldt voor engineers die coding agents inzetten aan het zware uiteinde van de curve. Lange autonome taken, parallelle agents, grote repo's uitlezen. De grens van $1.500 ligt boven wat de meeste teams in de praktijk uitgeven, maar onder de echt extreme uitschieters. Het is het punt waarop een poweruser het model acht uur per dag op echt werk pusht, en daarboven draai je waarschijnlijk een script of verstook je tokens per ongeluk.

Voor een mkb-bedrijf met een CRM-agent over acht sales reps is de vraag niet of jouw seats $1.500 kosten. Vrijwel zeker niet. De vraag is hoe jouw gebruikscurve eruitziet, en waar de failure modes zitten.

Wat een sales seat echt verstookt

Een CRM-agent die inbox triage, gespreksamenvattingen, lead enrichment en concept-antwoorden voor één sales rep afhandelt, eet tokens in voorspelbare patronen. Grofweg:

• Een samenvatting van een gesprek van 30 minuten: ongeveer 8k input, 1k output.
• Een concept-vervolgmail met context uit de laatste drie contactmomenten: ongeveer 5k input, 400 output.
• Een lead enrichment-pass die het CRM-record leest en vervolgstappen voorstelt: ongeveer 12k input, 800 output.

Vermenigvuldig met een drukke dag (5 gesprekken, 30 follow-ups, 20 enrichments) en het rekensommetje landt op ongeveer:

input:  5 × 8k  + 30 × 5k   + 20 × 12k  = 430k tokens
output: 5 × 1k  + 30 × 0.4k + 20 × 0.8k =  33k tokens

Tegen de huidige Anthropic Claude Sonnet-prijzen (rond $3 per miljoen input, $15 per miljoen output) is dat zo'n $1,79 per dag, oftewel ongeveer €40 per maand per actieve seat. Maal acht reps en je zit op €320 per maand voor het hele team.

Dat is het happy path. Kijk nu naar de edge cases.

Waar de rekening echt scheef loopt

De kostenoverschrijdingen die we over veertien productie-agents heen zagen, kwamen telkens uit hetzelfde handjevol patronen.

Een retry-loop die niemand zag: een agent die een wankele API aanroept, opnieuw probeert met exponential backoff, elke retry met de volledige conversation context erbij. Eén bug die we live brachten probeerde 47 keer opnieuw voordat de timeout 'm ving. Elke retry kostte ongeveer evenveel als de originele call.

Een rep die ontdekte dat de agent prospects kon "researchen". Hij liet 'm bij iedere lead een LinkedIn-export, het laatste kwartaalverslag van het bedrijf en een Glassdoor-review uitlezen. De kosten van zijn ene seat gingen van €40 naar €290 per maand voordat iemand het door had.

Een long-running RAG-retrieval die de verkeerde chunk size uit de production config oppikte. De agent las voor elke conceptmail 60k tokens context in plaats van 5k. De output zag er normaal uit. De rekening verdubbelde geruisloos. Het stuk van Anthropic over contextual retrieval hint waarom dit soort regressie zo makkelijk te missen is: de kosten van één 'slim' agent-antwoord lopen sterk uiteen, en die variantie stapelt zich over een team heen op.

Geen van deze zijn rare misbruikgevallen. Het zijn de saaie failure modes van elk systeem waar het verbruik meeschaalt met een model-call.

Caps die veilig falen

Als wij per-seat-limieten in CRM-agents zetten, doen we dat niet op de mediaan. We zetten ze op zo'n 3x de mediaan, met twee afkapwaarden.

Een soft cap op 2x de mediaan: de agent stuurt een dagelijkse samenvatting naar de Slack-DM van de rep. "Gisteren heb je 280k tokens gebruikt, twee keer zoveel als gewoonlijk. Vooral enrichment-calls op het Acme Corp-record." Verder niets. Geen blokkade, alleen een zin waar de rep iets mee kan.

Een hard cap op 5x de mediaan: de agent valt dicht. Nieuwe requests krijgen een nette weigering en een link naar de ops manager.

De soft cap is degene die het echte werk doet. Die vangt het LinkedIn-research-patroon binnen 24 uur. Die vangt de retry-loop-bug binnen een uur, mits je de alert aan de afgeleide hangt. De hard cap is gewoon de gordel.

Dit komt dichter bij hoe je Ubers getal moet lezen, als je je ogen samenknijpt. Ze kozen geen $1.500 omdat engineers $1.500 kosten. Ze kozen het omdat ergens boven die lijn de mens niet meer in de loop zit.

De vorm van een eerlijk model

Veel post-Uber-analyses gingen over de vraag of per-seat AI-pricing een vendor-strategie zou moeten worden. Dat is een vendor-vraag. De koperskant ligt anders. Weet jij wat één van je seats daadwerkelijk verbruikt, en biedt je contract of je in-house build een schone manier om dat af te toppen?

Als je een CRM koopt met een ingebouwde AI-agent en de vendor adverteert met 'unlimited AI', dan is dat geen feature. Dat is een weddenschap die ze sluiten op een vlakke gebruikscurve. Is die curve niet vlak, dan verdubbelt de prijs bij verlenging.

Voor het uitzendbureau kwamen we uit op dit:

budget per active seat: €60/month soft, €150/month hard
alert:    daily Slack summary if 24h spend > 2 × 7-day median
fallback: hard cap returns cached "we're at capacity, ping ops" reply
billing:  ops manager sees per-rep dashboard, not raw token counts

De ops manager hoeft niet te weten wat 1,2 miljoen tokens betekent. Ze moet weten dat haar top-rep op dag 18 op 70% van zijn maandelijkse soft cap zit, en dat niemand anders boven de 40% komt. Met die zin kan ze iets.

Toen wij de inbox-triage- en CRM-agent-stack voor dat uitzendbureau bouwden, liepen we precies tegen deze kloof aan tussen token-rekensommen en operator-taal. We hebben dat opgelost door de rekening te vertalen in de eenheid die de koper al gebruikt: deals behandeld, follow-ups verstuurd, meetings ingepland. De AI-agent veranderde niet; het dashboard eromheen wel.

Als je deze week één ding doet: trek de laatste 30 dagen aan API-logs uit de agent die je al draait, sorteer op gebruiker en kijk naar de top 10% van de verdeling. Die ene sortering beantwoordt de meeste vragen uit dit stuk.