De prijs van een AI-appbuilder hangt af van wat als werk telt

Het goedkoopste plan voor 100 promptiteraties per week is meestal het plan dat rond elke prompt het minste werk meetelt. De vermelde maandprijs zegt bijna niets totdat je weet of een retry, een planningsstap, een testrun, een deployment en een agent die op de achtergrond werkt op dezelfde meter terechtkomen.

Ik heb teams abonnementen zien vergelijken door de abonnementsprijs door 100 prompts te delen. Die rekensom is netjes en fout. Een prompt die de tekst op een knop wijzigt en een prompt die een database herstructureert, tellen voor degene die typt allebei als één bericht, maar kunnen heel verschillende rekeningen opleveren. Een eerlijke vergelijking begint met een overzicht van de werklast en past daarna de factureringsregels van elke leverancier toe op datzelfde overzicht.

Dit artikel gebruikt een hypothetische prijscatalogus, geen prijzen van een specifieke leverancier. Het doel is je een berekening te geven die je vóór aankoop kunt vervangen door de werkelijke voorwaarden van een plan.

Hetzelfde aantal prompts kan drie verschillende rekeningen verbergen

Een telling van gebruikersberichten meet het gesprek, niet de rekenkracht of het voltooide werk. Creditplannen meten meestal modelactiviteit, taakplannen meten een door de leverancier bepaalde werkeenheid en vaste plannen verkopen toegang binnen een grens. Die grenzen leveren verschillende totalen op, zelfs als de applicatie en de 100 wekelijkse verzoeken identiek blijven.

Stel dat een oprichter elke week om 70 kleine interfacewijzigingen, 20 wijzigingen die meerdere bestanden raken en 10 build- of deploymentwijzigingen vraagt. Het zichtbare aantal is 100. Op de achtergrond kan de builder de repository inspecteren, een plan maken, meerdere keren een model aanroepen, tests uitvoeren, een mislukte wijziging herstellen, de app opnieuw bouwen en een agent laten doorgaan nadat het chatantwoord is verschenen. Het ene plan kan elke modelaanroep berekenen. Een ander kan de hele reeks als één taak zien. Een abonnement kan het opnemen, begrenzen of een deel als meerverbruik uitsluiten.

Kopers halen dit onderscheid vaak door elkaar: een iteratie is een beslissingscyclus van de gebruiker, terwijl een factureerbare gebeurtenis is wat de verkoper heeft gekozen te meten. Wie ze als synoniemen behandelt, bevoordeelt het plan met de vaagste prijspagina. Het maakt een ogenschijnlijk goedkoop plan ook duur zodra het team zijn applicatie aan het platform heeft verbonden.

Gebruik voor de vergelijking een maandfactor van 4.33 weken in plaats van te doen alsof elke maand vier weken heeft. Honderd wekelijkse iteraties worden 433 maandelijkse iteraties. Die kleine correctie voegt 33 iteraties toe, nog voordat één retry of achtergrondtaak in de berekening komt.

Een goed prijsverzoek vraagt de leverancier om het werk te classificeren, niet alleen om een totaal te schatten. Vraag: Wat start de meter? Wanneer stopt die? Telt een mislukte run mee? Telt een automatische retry mee? Welk werk gaat door nadat de interface zegt dat het antwoord klaar is? Kan ongebruikte capaciteit doorrollen? De antwoorden bepalen de rekening.

Definieer één werklast voordat je de rekenmachine opent

Maak een representatieve week op basis van werk dat je werkelijk verwacht en leg die vast voordat je plannen vergelijkt. Als je de werklast voor elk prijsmodel verandert, test je verkoopteksten in plaats van prijzen.

Voor de uitgewerkte vergelijking gebruik ik deze wekelijkse werklast:

• 70 kleine wijzigingen van elk één crediteenheid
• 20 wijzigingen in meerdere bestanden van elk drie crediteenheden
• 10 build- of deploymentwijzigingen van elk vijf crediteenheden
• 25 retryruns met gemiddeld twee crediteenheden
• 35 achtergrondruns die samen 45 crediteenheden verbruiken

De 100 gevraagde iteraties verbruiken bij de eerste poging 180 hypothetische crediteenheden. Retries voegen er 50 toe. Planning, indexering, tests en deploymentwerk voegen 45 toe. Het wekelijkse totaal is 275 eenheden, oftewel 1,190.75 eenheden in een gemiddelde maand.

Dezelfde activiteit heeft onder taakfacturering een tweede vorm. Elke week ontstaan 100 door gebruikers gestarte taken, 25 gestart door retries en 35 achtergrondtaken. Dat zijn 160 gebeurtenissen per week en 692.8 gebeurtenissen per maand. Of alle 692.8 factureerbaar zijn, hangt af van de definitie van een taak in het contract.

Leg geslaagd en mislukt werk apart vast. Een foutpercentage dat alleen op zichtbare foutmeldingen is gebaseerd, mist stille herstelacties, automatische modelterugvallen en opnieuw uitgevoerde tests. De gebruiksexport van het platform, als die er is, is beter bewijs dan een chatgeschiedenis, omdat de chat meerdere agentruns kan samenvoegen tot één antwoord.

Gebruik een week met gewone rommel: één onduidelijke prompt, één afhankelijkheidsconflict, een test die om een ongerelateerde reden faalt en een deploymentherstel. Een vlekkeloze demoweek levert een budget op dat slechts standhoudt tot de echte ontwikkeling begint.

Blaas de werklast niet op om jezelf te beschermen. Voeg na het berekenen van de waargenomen basislijn een aparte marge voor variatie toe. Door basislijn en marge te scheiden, zie je of een plan duur is door normaal werk of doordat je verzekering hebt gekocht voor een drukke maand.

Creditpakketten rekenen beweging binnen de builder af

Creditpakketten kosten minder wanneer de eenheidsprijzen van het platform laag zijn, ongebruikte credits lang genoeg geldig blijven en de builder weinig herstelpogingen nodig heeft. Ze kosten meer wanneer een eenvoudig verzoek uiteenvalt in meerdere modelaanroepen die de gebruiker niet ziet.

Een credit is geen standaardeenheid. Die kan staan voor tokens, modelaanroepen, agentstappen, seconden of een gewogen combinatie. Een leverancier kan ook verschillende aantallen credits rekenen voor een snel model en een capabeler model. Het aantal credits in twee pakketten vergelijken is zinloos tenzij beide platforms verbruik op dezelfde manier definiëren, en dat doen ze zelden.

Prijs de hypothetische werklast met een pakket van 500 eenheden voor $30. De maandelijkse vraag is 1,190.75 eenheden. Omdat pakketten ondeelbaar zijn, heeft de koper drie pakketten nodig en betaalt die $90. Aan het eind van de maand blijven 309.25 eenheden over als credits niet verlopen. De effectieve prijs van verbruikt werk is ongeveer 7.56 cent per eenheid, hoewel het pakket 6 cent vermeldt, omdat de koper ongebruikte capaciteit moest kopen.

Doorrollen verandert de uitkomst. Als de resterende 309.25 eenheden behouden blijven, kan de aankoop van de volgende maand twee pakketten zijn in plaats van drie. Over meerdere stabiele maanden nadert de gemiddelde prijs de geadverteerde prijs. Als credits maandelijks verlopen, maakt het achtergebleven saldo deel uit van de prijs. Laat het nooit buiten het model.

De modelkeuze kan het verbruik veranderen zonder dat het aantal prompts verandert. Als het platform complexe wijzigingen naar een model met een vermenigvuldigingsfactor van vier stuurt, kunnen de tien moeilijkste verzoeken de rekening domineren. Vraag of die routering automatisch gebeurt, of je die achteraf kunt zien en of je een plafond kunt instellen. Een goedkoper model dat twee keer faalt en opnieuw moet proberen, kan meer kosten dan een capabel model dat één keer slaagt.

Creditpakketten werken goed voor onregelmatige projecten, omdat je betaalt wanneer het werk gebeurt, mits de credits bruikbaar blijven. Ze zijn lastiger te begroten voor een team dat vrij experimenteert. De meter kan gedrag veranderen: mensen voegen ongerelateerde verzoeken samen tot te grote prompts, vermijden tests of accepteren zwakke output om credits te besparen. Die keuzes verlagen de factuur ten koste van de applicatie.

De lastige vraag is of achtergrondwerk credits moet verbruiken. Het kost middelen, dus daarvoor rekenen is verdedigbaar. Het probleem ontstaat wanneer de koper het niet kan voorspellen of stoppen. Een eerlijke beoordeling controleert of de interface elke achtergrondkostenpost toont en of een bestedingslimiet nieuw werk stopt voordat het saldo nul bereikt.

Taakfacturering hangt af van waar een taak begint en eindigt

Taakgebaseerde facturering kan het goedkoopste model zijn wanneer één prijs de hele poging dekt, inclusief planning, modelaanroepen, tests en herstelwerk. Het wordt het duurst wanneer elke interne actie een nieuwe taak wordt.

Pas een hypothetisch tarief van $0.14 toe op elke gestarte gebeurtenis in het overzicht. Bij 692.8 maandelijkse gebeurtenissen zijn de kosten na afronding op centen $96.99. Dat is hoger dan de $90 voor creditpakketten, ook al klinkt veertien cent klein op een prijspagina.

Verander nu één zin in het contract: reken alleen voor de 433 door de gebruiker gevraagde iteraties en neem retries en achtergrondwerk op binnen elke taak. De maandelijkse kosten dalen naar $60.62. Aan de applicatie is niets veranderd. De taakgrens is veranderd en die grens verplaatste $36.37.

Facturering per voltooide taak heeft nog een definitie nodig. Als een run bestanden wijzigt maar de deployment mislukt, heeft het platform de taak dan voltooid? Als de gebruiker het resultaat afwijst en om een correctie vraagt, is dat dan een nieuwe taak of een voortzetting? Leveranciers hebben regels nodig om onbeperkt werk voor één prijs te voorkomen, maar kopers hebben regels nodig die ze uit een activiteitenlog kunnen herhalen.

Het populaire advies om de kosten per geslaagde prompt te vergelijken, is onjuist als succes door de gebruiker zelf wordt gemeld. Gebruikers accepteren deelresultaten, splitsen grote verzoeken op en corrigeren output handmatig. Lage kosten per geregistreerd succes kunnen uren opruimwerk verbergen. Vergelijk liever de kosten per geaccepteerde wijziging, op het moment waarop het team het resultaat zou mergen, deployen of anderszins behouden.

Taakprijzen hebben een voordeel voor budgettering wanneer de eenheid aansluit bij iets dat een mens herkent. Een team kan 400 geaccepteerde wijzigingen met meer vertrouwen schatten dan miljoenen tokens. Dat voordeel verdwijnt als het product indexering, planning, testen en deployment als losse taken aanduidt. Lees de gebeurtenisnamen op een echte factuur of in een gebruiksexport voordat je de eenheid als stabiel ziet.

Vraag ook hoe gelijktijdigheid werkt. Twee agents die tegelijk draaien, kunnen de doorlooptijd verkorten en tegelijk het aantal gestarte taken verdubbelen. Een achtergrondherstel dat een testagent start, kan één, twee of geen enkele keer meetellen. De factuur volgt de meter, niet de klok.

Vaste abonnementen winnen alleen binnen hun inbegrepen grens

Een vast abonnement kost voor deze werklast het minst wanneer de maandprijs alle 433 gebruikersiteraties, 108.25 retrystarts en 151.55 achtergrondstarts omvat. Als een categorie buiten het abonnement valt, tel die dan mee voordat je het vaste plan goedkoper noemt.

Gebruik een hypothetisch maandplan van $79 met maximaal 600 interactieve en retryruns plus 200 achtergrondruns. Het voorbeeld levert 541.25 interactieve en retryruns en 151.55 achtergrondruns per maand op. Beide totalen passen binnen de limiet, dus de kosten blijven $79. Onder deze aannames verslaat een vaste prijs de creditpakketten van $90 en het plan van $96.99 per gestarte taak.

Het woord onbeperkt heeft geen waarde in een spreadsheet. Vervang het door de echte fair-usegrens, gelijktijdigheidslimiet, modelbeperking of vertragingsregel. Als de leverancier geen grens wil noemen, modelleer dan een laag en hoog scenario. Een plan dat alleen goedkoop lijkt onder een onbegrensde interpretatie heeft je geen betrouwbare prijs gegeven.

Vaste plannen creëren ook stapkosten. Bij 599 inbegrepen runs kost één extra run mogelijk niets. Bij 600 kan de volgende run meerverbruik veroorzaken of een hoger niveau afdwingen. Breng minstens drie werklastniveaus in kaart: een rustige maand, de verwachte maand en een releasemaand. Alleen het verwachte geval verbergt het punt waarop het abonnement omhoog springt.

Stoelen zijn belangrijk wanneer de facturering gebruikers volgt in plaats van werk. Een plan van $79 voor één persoon kost $316 voor vier verplichte stoelen, zelfs als het team dezelfde 433 iteraties deelt. Neem niet aan dat accountdeling is toegestaan. Prijs de mensen die prompts moeten beoordelen, deployments moeten goedkeuren of gebruik moeten inspecteren.

Een vaste prijs kan gezond experimenteren stimuleren omdat elk mislukt idee geen zichtbare microkosten oplevert. Ze kan ook verspilling verbergen totdat het platform het account afremt. Zicht op gebruik blijft belangrijk. Je moet weten of agents in lussen terechtkomen en of een releasemaand de inbegrepen grens overschrijdt.

Jaarlijkse kortingen horen als laatste in de berekening. Bepaal eerst het goedkoopste model onder maandvoorwaarden. Pas daarna de korting en de kosten van de verplichting toe. Tien maanden betalen voor een tool die je na drie maanden verlaat, is geen besparing.

Retries horen in de basislijn, niet in een voetnoot

Retries zijn normaal ontwikkelwerk, dus een prijsvergelijking die uitgaat van perfecte output bij de eerste poging is ongeschikt voor een aankoopbeslissing. Het bruikbare getal is retryversterking: alle pogingen gedeeld door de gevraagde iteraties.

Het voorbeeld heeft 125 interactieve pogingen voor 100 gevraagde iteraties, wat een retryversterking van 1.25 geeft. Dat betekent niet dat 25 procent van de prompts simpelweg mislukt. Sommige verzoeken hebben verduidelijking nodig, sommige wijzigingen doorstaan codecontroles maar missen de bedoeling en sommige fouten komen door tools of afhankelijkheden. Het factureringseffect is hetzelfde wanneer het plan een nieuwe poging meet.

Meet retries met een regel die twee mensen consequent kunnen toepassen. Tel een retry wanneer de gebruiker dezelfde bedoelde uitkomst opnieuw vraagt na het afwijzen of herstellen van de vorige output. Tel een werkelijk nieuwe eis niet als retry. Label automatische retries apart, want een gebruiker ziet ze mogelijk nooit.

Een kleine pilot moet de taken bevatten die je moeilijk verwacht. Als je alleen landingspaginakopie en kleurwijzigingen test, zegt het retrypercentage weinig over databasemigraties, authenticatie, statusbeheer of mobiele builds. Laat bij elke kandidaat minstens één risicovolle wijziging uitvoeren en bekijk het activiteitenoverzicht.

Retries raken de modellen op verschillende manieren:

• Creditfacturering rekent meestal de middelen die elke poging verbruikt.
• Facturering per gestarte taak rekent meestal elke poging als de retry een gebeurtenis creëert.
• Facturering per voltooiing kan mislukte pogingen opnemen, afhankelijk van de voltooiingsregel.
• Vaste facturering neemt retries op totdat ze een inbegrepen limiet of fair-usecontrole raken.

Accepteer gratis retries niet als volledig antwoord. Vraag of de retry hetzelfde model gebruikt, of automatische terugval een aparte limiet verbruikt en hoe lang het venster voor gratis retries openblijft. Een correctie die de volgende ochtend wordt ingediend, kan een nieuwe taak worden, ook als het duidelijk om hetzelfde werk gaat.

Er zijn ook menselijke retrykosten. Een plan kan goedkoop zijn in dollars en duur in aandacht als gebruikers elk herstel moeten begeleiden. Houd tijdens de pilot het aantal minuten beoordeling per geaccepteerde wijziging bij. Dwing die tijd niet in de platformfactuur, maar zet hem naast de factuur zodat een lage prijs geen slechte werkwijze kan verbergen.

Achtergrondagents zijn de onzichtbare vermenigvuldiger

Werk van achtergrondagents moet als eigen rij verschijnen omdat het kan doorgaan nadat de gebruiker een antwoord ziet. Repository-indexering, planning, afhankelijkheidscontroles, tests, buildmonitoring, deployment en herstelagents kunnen allemaal budget verbruiken zonder nog een chatbericht toe te voegen.

Ons voorbeeld kent 35 achtergrondruns en 45 crediteenheden per week toe. Die getallen zijn bewust zichtbare aannames. Vervang ze door gebruiksgegevens uit een pilot. Als een leverancier slechts één gecombineerd totaal toont, voer dezelfde prompt dan één keer uit met optionele automatisering uitgeschakeld en één keer met die ingeschakeld. Het verschil is een schatting, geen bewijs, maar beter dan het werk als gratis behandelen.

De planningsmodus verdient extra aandacht. Een plan kan dure mislukte implementaties voorkomen door conflicten vroeg te vinden, of vóór elke triviale wijziging een betaalde stap toevoegen. Test die apart op kleine en grote wijzigingen. Het juiste beleid kan zijn planning te gebruiken voor schemawijzigingen en werk in meerdere bestanden, en deze over te slaan voor tekstwijzigingen.

Indexering heeft een ander kostenpatroon. De eerste doorgang door een repository kan duur zijn, terwijl latere incrementele updates weinig kosten. Een pilot van één week kan de structurele kosten overdrijven als die initiële indexering bevat, of onderschatten als de productierepository veel groter is. Scheid opstartverbruik van terugkerend verbruik.

Tests en deployment zijn geen optionele verspilling. Ze uitschakelen om binnen een creditlimiet te blijven, verplaatst foutdetectie naar gebruikers. Prijs de veilige werkwijze die je wilt hanteren, inclusief de controles die haar beschermen. Een vergelijking met uitgeschakelde tests beantwoordt de verkeerde zakelijke vraag.

Koder.ai ondersteunt planningsmodus, deployment en hosting, snapshots en rollback, en broncode-export. Een pilot kan deze delen van de werkwijze dus observeren in plaats van alleen chatberichten te prijzen. De plannamen en prijzen moeten nog steeds in de huidige productinterface worden gecontroleerd, omdat de sitecontext hier niveaus beschrijft, geen huidige limieten.

Stel een achtergrondbudget in als het product dat toestaat, maar verwar een limiet niet met voorspelbaarheid. Een limiet voorkomt extra uitgaven door werk te stoppen. De applicatie kan nog steeds een release missen terwijl een agent op meer capaciteit wacht. Leg zowel de financiële limiet als het operationele gevolg vast.

Laat elke kandidaat door hetzelfde overzicht lopen

Een overzicht maakt de vergelijking reproduceerbaar en legt onduidelijkheid in het contract bloot voordat die een factuurgeschil wordt. Eén rij moet één gemeten gebeurtenis beschrijven, met genoeg context om deze aan credits, taken en abonnementslimieten te koppelen.

Kopieer deze CSV-header en gebruik hem tijdens een pilot:

week,event_id,requested_iteration,event_type,outcome,retry_of,background_kind,credit_units,task_events,flat_bucket,notes
2026-W01,001,1,user_edit,accepted,,,1,1,interactive,copy change
2026-W01,002,2,user_edit,rejected,,,3,1,interactive,multi file edit
2026-W01,003,2,retry,accepted,002,,2,1,interactive,repair after failed test
2026-W01,004,2,background,completed,,test,1,1,background,automatic test run

Houd gebeurtenistype en uitkomst apart. Een achtergrondtest kan met succes voltooid zijn terwijl de gevraagde wijziging nog steeds niet wordt geaccepteerd. Als je die feiten samenvoegt in één status, kun je de regel van een leverancier voor voltooide taken niet toetsen.

Bereken aan het eind van de week vier waarden:

monthly_iterations = weekly_requested_iterations * 4.33
monthly_credits = weekly_credit_units * 4.33
monthly_task_events = weekly_task_events * 4.33
retry_amplification = (user_attempts + retry_attempts) / requested_iterations

Pas daarna de planvoorwaarden toe zonder de rijen te wijzigen. Voor de hypothetische catalogus luidt de berekening:

credit_cost = ceil(1190.75 / 500) * $30 = $90.00
started_task_cost = 692.8 * $0.14 = $96.99
flat_cost = $79.00, because 541.25 interactive runs < 600
             and 151.55 background runs < 200

Een spreadsheet moet ook achtergebleven credits, resterende inbegrepen capaciteit en de volgende prijsgrens tonen. Het winnende plan in het voorbeeld heeft 58.75 interactieve runs en 48.45 achtergrondruns over. Die marge is niet groot genoeg voor een releasemaand die het deploymentwerk verdubbelt, dus het team moet dat geval berekenen voordat het zich vastlegt.

Vraag de leverancier één geanonimiseerde overzichtspagina te beoordelen. Vraag niet welk plan het goedkoopst is, maar hoe elke rij wordt geclassificeerd. Een schriftelijke classificatie is nuttiger dan een verkoopinschatting omdat je die met de eerste factuur kunt vergelijken.

Variatie is belangrijker dan de prijs op het etiket

De uitkomst van het voorbeeld is een vast abonnement van $79, creditpakketten van $90 en facturering per gestarte taak van $96.99. Die rangorde geldt alleen voor de vermelde catalogus en werklast. Een kleine verandering in de behandeling van retries of inbegrepen achtergrondwerk kan deze omkeren.

Bereken voor elk paar een omslagpunt. Het vaste plan van $79 verslaat creditpakketten van $30 wanneer de maandelijkse vraag drie of meer pakketten vereist, aangenomen dat ongebruikte credits geen toekomstige waarde hebben. Als doorrollen de koper elke eenheid laat gebruiken, staat $79 gelijk aan ongeveer 1,316.7 crediteenheden van zes cent per stuk. Onder dat gebruik kosten volledig verbruikte credits minder.

Tegenover gestarte taken van $0.14 staat $79 gelijk aan ongeveer 564.3 gebeurtenissen. De verwachte 692.8 gebeurtenissen overschrijden dat punt. Als het taakplan echter alleen 433 gevraagde iteraties berekent, kost het $60.62 en wint het. Eén definitie is opnieuw belangrijker dan het basistarief.

Voer gevoeligheidsscenario's uit in plaats van te doen alsof de schatting exact is. Verander voor deze werklast de retryversterking van 1.10 naar 1.50, achtergrondwerk van 20 naar 60 wekelijkse gebeurtenissen en het verbruik bij complexe wijzigingen met een redelijke, door de leverancier vermelde vermenigvuldigingsfactor. Je hebt geen tientallen scenario's nodig. Je hebt de paar variabelen nodig die de beslissing kunnen veranderen.

Bekijk cashflow en vastlegging los van de eenheidsprijs. Pakketten kunnen flexibiliteit behouden. Een maandelijks abonnement creëert een voorspelbaar plafond zolang je binnen de grens blijft. Een jaarabonnement ruilt flexibiliteit in voor korting. Broncode-export en snapshots kunnen de kosten van het verlaten van een builder verlagen, maar maken migratie niet gratis. De geëxporteerde applicatie heeft nog steeds een werkende build, infrastructuur en iemand nodig die haar kan onderhouden.

Een oprichter met onzeker gebruik kan beter kiezen voor het model waarvan het nadeel zichtbaar is. Dat kunnen pakketten met lang doorrollen zijn, ook als het verwachte maandtotaal iets hoger is. Een team met stabiel, gemeten werk kan een vast plan kopen dat rond het midden van de inbegrepen bandbreedte ligt. Een taakplan past bij werk dat duidelijk aansluit op geaccepteerde uitkomsten en herstelwerk binnen de taak omvat.

Kies niet op basis van de winnaar in het voorbeeld. Kies nadat je elk hypothetisch tarief en elke limiet hebt vervangen door voorwaarden waar je naar kunt verwijzen, en elke aanname over de werklast door een observatie uit een pilot.

Onderwerp het factureringsmodel aan een acceptatietest

Een prijsmodel is klaar voor een beslissing wanneer iemand anders het maandtotaal uit het overzicht en de planvoorwaarden kan reproduceren. Als de berekening afhangt van een verkoper die achteraf een interne taak uitlegt, heeft het model de test niet doorstaan.

Gebruik deze compacte acceptatiechecklist:

1. Leg 100 representatieve gevraagde iteraties vast, of een kleinere steekproef met elk belangrijk type werk.
2. Label retries, automatische retries, plannen, tests, builds, deployments en andere achtergrondruns.
3. Koppel elke gebeurtenis aan de regel van de leverancier voor credits, taken of inbegrepen capaciteit.
4. Bereken totalen voor een verwachte, rustige en releasemaand met dezelfde factor 4.33.
5. Bewaar de planvoorwaarden en vergelijk de eerste echte factuur met de prognose.

Bepaal vóór de pilot een tolerantie. Je kunt bijvoorbeeld elk totaal onderzoeken dat meer dan 10 procent boven de prognose ligt. Het percentage is een managementkeuze, geen industriestandaard. Het dwingt je tot een beoordeling terwijl de gebeurtenisgeschiedenis nog bestaat.

Als het werkelijke gebruik de prognose overschrijdt, zoek dan de rijcategorie die daarvoor verantwoordelijk is. Meer geaccepteerd werk is iets anders dan meer retries. Meer geplande deploymentruns zijn iets anders dan een agentlus. De oplossing kan een groter plan zijn, een strakker agentbeleid, duidelijkere prompts of een facturatiecorrectie. Eén totaal kan niet vertellen welke.

Houd het overzicht de eerste drie factureringscycli naast de factuur, omdat een rustige pilot batchtaken, releasewerk en automatisch herstel kan missen. Het goedkoopste model voor 100 wekelijkse iteraties is dus afhankelijk van de voorwaarden, maar de beslissing hoeft niet vaag te zijn. In het expliciete voorbeeld wint het vaste abonnement van $79. Bij taakfacturering die op succesvol afgeronde taken is gericht, kost hetzelfde werk $60.62 en wint taakfacturering. Creditpakketten winnen bij lager of piekachtig verbruik wanneer doorrollen verspilling voorkomt. Leg vast wat meetelt, meet het verborgen werk en laat de factuur de belofte bewijzen.