De kostenformule en het kantelpunt van Vibe Coding

Een kostenmodel opzetten met uniforme variabelen voor drie factureringsmethoden: token, API-aanroepen, prompts. Geef formules voor kantelpunten en suggesties voor werkwijzen.

Wednesday, January 07, 2026

Categories:

Opinie

De factureringsmodellen van AI-codeertools zijn te onderscheiden in drie categorieën:

Facturering op tokenbasis: Omvat diverse API’s, Claude Code (Claude Pro), Codex Cli (ChatGPT Plus), Zhipu Lite/Pro, Cursor (nieuwe versie), enzovoort. In wezen zijn het allemaal tokenfactureringen; sommige producten bieden bundelkortingen.
Facturering op basis van API-aanroepen: Bijv. OpenRouter (gratis tegoed), ModelScope, Gemini Code Assistant (1000 gratis per dag), Chutes, enzovoort.
Facturering per prompt: Bijv. Cursor (oude versie, 500 keer), Github Copilot (300 keer), enzovoort.

Deze drie modellen zijn in wezen allemaal betaling voor modelinferentie en contextverwerking; het verschil zit in de factureringsgranulariteit en de vorm van de limieten.

In dit artikel stel ik een uniform kostenmodel op, geef ik operationele variabeledefinities en berekingsformules, en bepaal ik de kantelpunten voor hulpmiddelenkeuze bij verschillende werklasten en werkwijzen. De kostenbeschouwing omvat contante uitgaven, tijdverbruik en risico op herwerk.

Uniforme totale kostenfunctie

Voor een willekeurig hulpmiddel i zijn de totale kosten binnen een factureringscyclus:

$$ \begin{aligned} \mathrm{Total}_i &= \mathrm{Cash}_i + \mathrm{Time}_i + \mathrm{Risk}_i \ \mathrm{Time}_i &= R \cdot \mathrm{Hours}_i \ \mathrm{Risk}_i &= R \cdot \mathrm{ReworkHours}_i \end{aligned} $$

Waarbij R de uurprijs van uw tijd is (in yuan per uur). Als u de tijd niet mee wilt rekenen, stelt u R op 0; de formule herleidt dan tot een zuivere vergelijking van contante kosten.

Variabeleconventies

Om de drie factureringsmodellen te uniformeren, wordt de werklast onderverdeeld in twee niveaus: ‘sessie’ en ‘iteratie’. Het scannen en indexeren bij het starten van een nieuw project is een eenmalige operatie; voortdurende dialoog en codewijzigingen binnen dezelfde context zijn herhaalbare operaties.

Variabelendefinitie:

$S_i$: Vaste kosten van hulpmiddel i (abonnementskosten of maandelijkse minimumconsumptie)
$N_s$: Aantal nieuwe sessies in deze periode (wisselen van project, wissen van context, starten van nieuwe sessie)
$N_{it}$: Aantal effectieve iteraties in deze periode (behoeftenverduidelijking, codewijziging, foutcorrectie, enzovoort)
$R$: Uurprijs van tijd (yuan per uur)
$h0_i$: Koude-starttijd per nieuwe sessie (uren)
$h1_i$: Gemiddelde tijd per iteratie (uren)
$p_{\mathrm{fail},i}$: Kans op falen per iteratie dat herwerk vereist (0 tot 1)
$h_{\mathrm{re},i}$: Gemiddelde tijd voor eenmalige herwerk (uren)

De tijd- en risicocomponenten zijn dan:

$$ \begin{aligned} \mathrm{Hours}i &= N_s \cdot h0_i + N{it} \cdot h1_i \ \mathrm{ReworkHours}i &= N{it} \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i} \end{aligned} $$

Vervolgens hoeven we alleen $Cash_i$ voor de drie factureringsmethoden te definiëren.

Contante kosten voor facturering op tokenbasis

Bij facturering op tokenbasis worden tokens meestal in drie categorieën verdeeld: input, input met cachetreffer, output. Een veelvoorkomende misvatting is dat dezelfde inputtokens herhaaldelijk worden meegeteld in input en cache. Het wordt aanbevolen om eerst de totale inputtokenhoeveelheid te schatten en die vervolgens te splitsen op basis van het cachetrefferpercentage.

Variabelendefinitie:

$Tin0_i$: Totale inputtokens per nieuwe sessie
$r0_i \in [0,1]$: Cachetrefferpercentage voor input bij nieuwe sessie
$Tin1_i$: Totale inputtokens per iteratie
$r1_i \in [0,1]$: Cachetrefferpercentage voor input bij iteratie
$Tout0_i, Tout1_i$: Outputtokens
$Pin_i, Pcache_i, Pout_i$: Prijsparameters (yuan per miljoen tokens)

Voor tools zonder cacheprijsstelling kunt u $r0_i=r1_i=0$ of $Pcache_i=Pin_i$ stellen.

Dan:

$$ \begin{aligned} \mathrm{Cash}^{(\mathrm{token})}i &= S_i + \frac{1}{10^6}\Bigl[ N_s \cdot \bigl(Pin_i \cdot (1-r0_i)\cdot Tin0_i + Pcache_i \cdot r0_i\cdot Tin0_i + Pout_i \cdot Tout0_i\bigr) \ &\qquad + N{it} \cdot \bigl(Pin_i \cdot (1-r1_i)\cdot Tin1_i + Pcache_i \cdot r1_i\cdot Tin1_i + Pout_i \cdot Tout1_i\bigr) \Bigr] \end{aligned} $$

Deze formule verklaart direct een ervaringsconclusie: bij immersieve, continue werkzaamheden binnen dezelfde sessie neemt $N_{it}$ toe maar wordt $Tin0_i$ slechts eenmaal betaald, waardoor de gemiddelde kosten per iteratie dalen. Vaak wisselen van project of regelmatig wissen van de context laat $Tin0_i$ herhaaldelijk betalen.

Contante kosten voor facturering op basis van API-aanroepen

Bij facturering op basis van API-aanroepen is het cruciale punt dat ‘één aanroep’ dialoog, toolaanroepen, bestandslezen, zoeken, commando-uitvoering enzovoort omvat. U moet schatten:

$A0_i$: Aantal API-aanroepen per nieuwe sessie
$A1_i$: Aantal API-aanroepen per iteratie
$Ccall_i$: Prijs per aanroep (yuan per keer)

Formule voor contante kosten:

$$ \mathrm{Cash}^{(\mathrm{call})}i = S_i + Ccall_i \cdot (N_s \cdot A0_i + N{it} \cdot A1_i) $$

Als een tool gratis tegoed Q (keer per cyclus) biedt en na overschrijding moet wachten in plaats van betalen, kunt u de wachttijd meerekenen in de tijdskosten en de extra aanroepen omrekenen naar $Hours_i$; gebruik dan nog steeds $Total_i$ voor vergelijking.

Contante kosten voor facturering per prompt

Bij facturering per prompt wordt één ‘prompt’ gelijkgesteld aan één taakindiening. U moet schatten:

$P0_i$: Aantal prompts per nieuwe sessie
$P1_i$: Aantal prompts per iteratie
$Cprompt_i$: Prijs per prompt (yuan per keer)

Formule voor contante kosten:

$$ \mathrm{Cash}^{(\mathrm{prompt})}i = S_i + Cprompt_i \cdot (N_s \cdot P0_i + N{it} \cdot P1_i) $$

Voor producten met ‘abonnement met N keer per maand’ kunt u een schaduwprijs (shadow price) gebruiken als benadering: stel dat het abonnementsbedrag voor de periode $S_i$ is en het quotum $Q_i$, dan is $Cprompt_i \approx S_i / Q_i$. Hoewel dit niet de strikte marginale contante kosten zijn, kan het ‘quota-schaarste’ omzetten in berekenbare opportuniteitskosten.

Kantelpunt: formule voor de scheidingslijn tussen twee tools

De bovenstaande formules kunnen uniform worden geschreven. Voor tool i:

$$ \mathrm{Total}_i = S_i

N_s \cdot (c0_i + R \cdot h0_i)
N_{it} \cdot (c1_i + R \cdot h1_i + R \cdot p_{\mathrm{fail},i} \cdot h_{\mathrm{re},i}) $$

Waarbij $c0_i$ en $c1_i$ respectievelijk de contante kosten zijn voor koude start en per iteratie, overeenkomend met de verschillende uitwerkingen in de drie factureringsmodellen.

Gegeven twee tools A en B, bij vaste $N_s$ en het stellen van $Total_A$ = $Total_B$, kan het kantelpunt voor iteratie-aantal worden opgelost:

$$ N_{it}^{\ast}

\frac{ (S_B - S_A) + N_s \cdot \bigl((c0_B - c0_A) + R \cdot (h0_B - h0_A)\bigr) }{ (c1_A - c1_B) + R \cdot (h1_A - h1_B)

R \cdot \bigl(p_{\mathrm{fail},A} \cdot h_{\mathrm{re},A} - p_{\mathrm{fail},B} \cdot h_{\mathrm{re},B}\bigr) } $$

Uitleg:

Wanneer de noemer positief is, is A voordeliger als $N_{it} > N_{it}^{\ast}$ en B voordeliger als $N_{it} < N_{it}^{\ast}$. Wanneer de noemer negatief is, zijn de ongelijkheden omgekeerd. Wanneer de noemer dicht bij 0 ligt, betekent dit dat de marginale kosten per iteratie bijna gelijk zijn; de keuze hangt dan voornamelijk af van vaste kosten en koude-startkosten.

U kunt deze formule gebruiken om drie typische kantelpunten te berekenen, namelijk tokenfacturering versus promptfacturering, tokenfacturering versus API-aanroepfacturering, en API-aanroepfacturering versus promptfacturering. U hoeft alleen de $c0, c1$ voor elk model uit te werken tot tokens, aanroepen of prompts.

Praktische strategie: methoden om kosten te verlagen

1. Immerseive ontwikkeling: optimalisatie voor tokenfacturering

Voor tools die op tokenbasis worden gefactureerd (zoals Codex Cli) is de kernstrategie het behoud van een stabiele werkcontext.

Principe: Vermijd herhaalde betaling van $Tin0_i$. Door continu te werken binnen hetzelfde project worden de initiële kosten voor het laden van context afgeschreven, en stijgt de cachetrefferpercentage, wat de reactiesnelheid aanzienlijk verhoogt.

Praktijk: Vermijd frequente projectwisseling of het wissen van context. Als u slechts één bug hoeft te herstellen en het project daarna afsluit, wordt de waarde van de aanvankelijke bestandslezing niet volledig benut.

2. Behoeften samenvoegen: optimalisatie voor API-aanroepfacturering

Voor tools die op basis van API-aanroepen worden gefactureerd (zoals Gemini Code Assistant) is de kernstrategie het volledig benutten van de ‘context opbouwen’-aanroepen.

Principe: Verspreid de kosten van $A0_i$. Toolaanroepen, bestandslezing en andere operaties tellen allemaal mee in het aantal aanroepen.

Praktijk: Behandel meerdere gerelateerde behoeften binnen één sessie, verhoog de waarde-intensiteit van de initiële bestandslezing. Vermijd het direct verbreken van de verbinding na het voltooien van een kleine taak.

3. Grote taken: optimalisatie voor promptfacturering

Voor tools die op basis van prompt-aantal worden gefactureerd (zoals de oude versie van Cursor) zijn geschikt voor het verwerken van grote taken of koude-startonderhoud.

Principe: Beperk de marginale kosten. Ongeacht de lengte van de context zijn de kosten voor één prompt vast.

Praktijk: ‘Grote taak’ verwijst naar enorme tokenconsumptie (veel bestandslezing, zeer lange context) met beperkte output, of taken die kwalitatief hoogwaardige modelbeheersing vereisen. Dergelijke taken zijn het meest kosteneffectief met tools die op basis van het aantal keer worden gefactureerd. Kleine taken zijn met dergelijke tools minder kosteneffectief.

Een berekenbare keuzestroom

De onderstaande stroomdiagram kaart de variabelen af op de keuzelogica. Na het schatten van de omvang van $N_s$ en $N_{it}$ kunt u de kantelpuntsformule invullen om de optimale oplossing te bepalen.

flowchart TD
    A[Definieer werklast voor deze periode] --> B[Schat N_s: aantal nieuwe sessies]
    B --> C[Schat N_it: aantal iteraties per sessie]
    C --> D[Schat c0, c1 voor elk type tool]
    D --> E[Vul de N_it* formule in]
    E --> F{Hoofdwerklast?}
    F -->|N_s groot, N_it klein| G[Prioriteit: prompt of API-aanroepfacturering]
    F -->|N_s klein, N_it groot| H[Prioriteit: tokenfacturering]
    F -->|Beide groot| I[Werkstroom splitsen: koude start met prompt/aanroep, diepgaande fase met token]

    classDef in fill:#2c3e50,stroke:#ecf0f1,stroke-width:2px,color:#ecf0f1
    classDef calc fill:#3498db,stroke:#2980b9,stroke-width:2px,color:#fff
    classDef decide fill:#f39c12,stroke:#d35400,stroke-width:2px,color:#fff
    classDef out fill:#27ae60,stroke:#229954,stroke-width:2px,color:#fff

    class A,B,C in
    class D,E calc
    class F decide
    class G,H,I out