De multimodelstack: hoe startups in 2026 hun AI-programmeerkosten met 85% verlagen

Op 7 juli 2026 plaatste Paul Graham een gedachte-experiment van één regel dat tech-Twitter overnam: "Stel je voor hoe het zal zijn als modellen over 5 jaar evenveel beter zijn geworden dan Fable als Fable beter is dan GPT-3." De quote-tweets splitsten zich zoals altijd: half verwondering, half scepsis. Maar het nuttigste gesprek ging helemaal niet over 2031. Het stond in de reacties, waar werkende developers hun rekeningen deelden.

$200 per dag. $350 per dag. $500 per dag bij zware agent-loops. Geen uitschieters, maar een constante stroom founders en engineers die hetzelfde zeiden: de nieuwste frontier-modellen zijn verbluffend, en je hele ontwikkelworkflow erdoorheen jagen wordt stilletjes een van de grootste posten op het budget van een kleine startup. Diezelfde week ging een tegenpatroon viraal op Reddit en X: de multimodelstack, en de cijfers erachter verdienen de aandacht van elke founder.

Het probleem: topprijzen voor routinewerk

Dit is de ongemakkelijke rekensom. Huidige frontier-modellen kosten op lijstprijs zo'n $10 per miljoen inputtokens en $50 per miljoen outputtokens. Middenklassemodellen van dezelfde labs kosten een vijfde daarvan of minder. En voor een groot deel van wat een ontwikkelworkflow werkelijk doet (variabelen hernoemen, boilerplate schrijven, tests genereren uit een duidelijke spec, lintfouten oplossen, itereren op CSS) levert het middenklassemodel in wezen hetzelfde resultaat.

Als je alles door het frontier-model haalt, betaal je 100% van de tijd de meerprijs voor werk dat die misschien 20% van de tijd nodig heeft. Zo eindigt een solo-founder met een AI-rekening van $6,000/maand nog voordat er één betalende klant is.

Het patroon: plannen → uitvoeren → reviewen

De multimodelstack die deze week viraal ging, heeft drie fasen, die elk worden gerouteerd naar het model dat het best geschikt, en het best geprijsd, is voor die klus:

• Plan met het slimste model. Architectuurbeslissingen, een feature opdelen in stappen, de randgevallen zien waaraan je niet had gedacht: hier verdient frontier-redeneren zijn prijs. De output is een gedetailleerd plan, en dat is kort. Korte output op het dure model is precies de goede volgorde.
• Voer uit met het goedkoopste model dat werkt. Met een goed plan in handen is code genereren vooral overschrijven. Middenklasse- en snelle modellen doen dat tegen 5–10x lagere kosten, en de lange, tokenrijke output komt op de goedkope meter terecht, niet op de dure.
• Review met een ander model. Een tweede model uit een andere familie vangt een ander soort fouten dan het model dat de code schreef, om dezelfde reden waarom menselijke code review werkt. Debug-loops die bij het ene model vastlopen, komen vaak los zodra je de trace aan een ander geeft.

Waarom dit voor startups meer telt dan voor wie dan ook

Een groot bedrijf kan een opgeblazen AI-rekening opvangen. Een pre-seed-startup niet, en belangrijker nog: de gewoonte stapelt zich op. Teams die modelroutering vroeg als een engineeringdiscipline behandelen, houden er drie structurele voordelen aan over:

• Unit economics die schaal overleven. Als je product zelf LLM's aanroept, wordt dezelfde routeringslogica die je in ontwikkeling geld bespaart je margeverhaal in productie. Investeerders vragen in 2026 naar inferentiekosten; "we sturen 80% van de verzoeken naar modellen van een tiende van de prijs" is een goed antwoord.
• Geen afhankelijkheid van één leverancier. Een multimodelworkflow dwingt schone abstracties af rond modelaanroepen. Als prijzen veranderen, en dat deden ze dit jaar maandelijks, pas je een configuratiewaarde aan, geen architectuur.
• Betere output, niet alleen goedkopere. Review door een ander model vangt echt meer bugs. Teams die de stack om kostenredenen invoeren, houden hem om kwaliteitsredenen.

Zo zet je het deze week op

• Meet eerst. Besteed twee dagen aan het loggen van wat je per taaktype werkelijk uitgeeft. De meeste teams ontdekken dat 60–80% van de tokens naar output uit de uitvoeringsfase gaat die nooit frontier-redeneren nodig had.
• Splits je workflow op de grens van het plan. Laat het frontier-model een expliciet, geschreven plan maken: te wijzigen bestanden, te schrijven functies, af te handelen randgevallen. Dat artefact maakt goedkope uitvoering betrouwbaar.
• Kies één goedkope uitvoerder en één reviewer. Bouw op dag één geen orkest van vijf modellen. Eén planner, één uitvoerder en één reviewer uit een andere familie leveren 95% van het voordeel.
• Escaleer bij falen, niet standaard. Faalt het goedkope model twee keer op dezelfde taak, stuur die dan een niveau hoger. Die ene regel houdt de kwaliteit hoog zonder de rekening weer op te blazen.

Het grotere plaatje: Graham heeft waarschijnlijk gelijk, en dat is precies het punt

De kloof tussen GPT-3 en de huidige frontier-modellen is moeilijk te overdrijven, en als de komende vijf jaar die sprong herhalen, zullen de meeste workflowdiscussies van nu ouderwets lijken. Maar die toekomst snijdt aan twee kanten: elk frontier-model uit het verleden werd uiteindelijk een standaardmodel. Het vlaggenschip van vandaag voor $50 per miljoen tokens is de goedkope uitvoerder van volgend jaar. Een multimodelstack is geen gok tegen AI-vooruitgang: het is de architectuur die er automatisch van profiteert, omdat elke nieuwe release in je routeringstabel landt op het niveau dat zijn prijs rechtvaardigt.

De startups die deze cyclus winnen, zijn niet degene die het meest aan tokens uitgaven. Het zijn degene die de discipline opbouwden om precies uit te geven wat elke taak waard is, en daardoor sneller shipten.

Bouw je een AI-product en wil je hulp bij het ontwerpen van een architectuur voor modelroutering die je burn voorspelbaar houdt? Plan een gratis discovery call: dit is precies het soort systeem dat we elke maand voor founders opleveren.

Related Posts

Verticale AI-integratie voor enterprises: de GPU-, model- en applicatielaag in eigen hand in 20267 juli 2026

De verticale SLM-stack: GPU, training en applicatielaag voor domeinspecifieke AI in 20266 juli 2026

Het /loop-commando van Claude Code: zo gebruik je het voor slimmere programmeerworkflows in 20263 juli 2026