Het probleem van «gebruik GPT-4 en klaar»
De meeste AI-platformen nemen stilzwijgend een besluit voor je: ze kiezen een model dat ze bevalt, hangen alles daaraan en gaan verder. Dat werkt totdat het niet meer werkt — tot het model uitvalt, tot een concurrent iets beters uitbrengt voor een specifieke taak, tot je je eigen API-sleutel wilt meebrengen en de kosten op je eigen account wilt houden, tot je beelden moet genereren en je standaardmodel dat niet kan.
Het gebruikelijke lapmiddel is een keuzelijst. Kies een model, gebruik het overal, zoek zelf uit hoe je met de afwegingen omgaat. Dat is geen routering, dat is delegeren. ToRun doet iets structureel anders.
De capaciteitsgerichte pijplijn
Elk verzoek in ToRun doorloopt vier stappen voordat het een model raakt.
1. De modus bepaalt het productoppervlak. Wanneer je een chatsessie opent of een onderzoekstaak start, kies je een Modus. De modus is niet alleen een interfacelabel: hij draagt een gedefinieerde verzameling vereiste en optionele capaciteiten. Een onderzoekstaak heeft gereedschappen (webzoeken), lange context en gestructureerde uitvoer nodig. Een gewone chatsessie heeft standaard alleen tekstgeneratie nodig.
2. De verzameling capaciteiten wordt een filter. ToRun onderhoudt een modelcatalogus van veel aanbieders — OpenAI, Anthropic/Claude, Google/Gemini, DeepSeek, xAI/Grok, Mistral en anderen. Elke vermelding draagt de vereniging van de capaciteiten die het model werkelijk ondersteunt: zicht, gereedschappen, code-uitvoering, beeldgeneratie, audio in, audio uit, videogeneratie, embeddings, herordening, realtimestreaming, redeneren en meer. De verzameling uit stap één wordt tegen deze catalogus gelegd. Modellen die niet aan alle vereiste capaciteiten voldoen, vallen af.
3. De rangschikking prijs-kwaliteit kiest de winnaar. Onder de modellen die het filter halen, rangschikt ToRun naar wat het verzoek werkelijk is. Een korte, eenvoudige vraag wordt op kosten gerangschikt, dus krijg je een snel en goedkoop antwoord. Een langere of moeilijkere wordt gerangschikt op capaciteit per kosteneenheid, tegen een kwaliteitsondergrens. Een beurt met een afbeelding erbij wordt gerangschikt op hoe goed een model ziet, niet op redeneren per euro. Workflow-uitvoerders schakelen naar kwaliteit eerst, want een geautomatiseerde pijplijn die ongezien draait, hoort het beste resultaat te kiezen en niet de goedkoopste sluiproute. BYOK-gebruikers komen anders in de prijsstelling terecht, omdat het verzoek via hun eigen aanbiedersaccount loopt.
4. Terugvalketens vangen storingen bij aanbieders op. Geeft het gekozen model een servicefout terug, dan draait dezelfde pijplijn opnieuw met dat model uitgesloten. Het op één na beste geschikte model antwoordt. Je ziet geen fout, tenzij alle bruikbare kandidaten uitliggen.
Een concreet voorbeeld: zicht plus gereedschappen
Stel dat je een schermafbeelding plakt en ToRun vraagt op het web context te zoeken over wat erop staat. Dat verzoek raakt twee capaciteiten tegelijk: zicht (het model moet een afbeelding als invoer accepteren) en gereedschappen (het model moet een webzoekfunctie kunnen aanroepen).
Met een aanpak op één model zit je vast: je platform ondersteunt die combinatie of niet. Met capaciteitsgerichte routering kruist ToRun beide eisen. Alleen modellen met bevestigde ondersteuning voor zowel zicht ALS gereedschapsaanroepen overleven het filter. Uit die korte lijst kiest de rangschikking op prijs en kwaliteit het beste voor je huidige modus. Is de eerste kandidaat begrensd of uitgevallen, dan handelt de volgende het verzoek af zonder dat jij iets doet.
Dit doet er in de praktijk toe: de verzameling modellen met zicht is het afgelopen jaar sterk veranderd en zal blijven veranderen. Capaciteitsgerichte routering zorgt dat ToRun nieuw toegevoegde modellen automatisch meeweegt zodra ze gecatalogiseerd zijn, zonder enige update van jouw kant.
Waarom dit het wint van vastzitten
Een platform met één model heeft maar één terugvalstrategie: wachten tot de aanbieder de storing verhelpt. Een capaciteitsgericht platform heeft een catalogus. Heeft OpenAI een incident, dan worden de verzoeken die Anthropic of Gemini kunnen bedienen daar bediend. Biedt een nieuw Mistral-model een betere prijs-kwaliteitverhouding bij gestructureerde uitvoer, dan komt het in de rangschikking van de betreffende modi zonder gedwongen migratie.
Dezelfde logica geldt voor BYOK. Voeg je je eigen API-sleutel voor een aanbieder toe, dan blijft die gegevensdrager binnen de routeringslaag begrensd. Verzoeken die passen bij de geschikte modellen van die aanbieder kunnen jouw sleutel gebruiken in plaats van het ToRun-account, waardoor de kosten naar jouw relatie met de aanbieder verschuiven op het passende factureringsniveau. De routeringspijplijn verandert niet: alleen welke sleutel op het uitvoeringsmoment wordt gebruikt.
De afweging is eerlijkheid: ToRun kan niet garanderen dat het goedkoopste model het slimste is voor jouw taak. De rangschikking is expliciet — je ziet wat er gekozen is en waarom, en je kunt het overrulen. Die transparantie is het doel. Elk verzoek schrijft een factuurregel met het gebruikte model, de prijseenheid die bij uitvoering actief was en de kostenopsplitsing. Je kunt elke aanroep maanden later controleren, ook na tariefwijzigingen bij de aanbieder, omdat de momentopname bevroren is op het moment dat het verzoek draaide.
Eén model dat alles doet, is een comfortabele fictie. Wat je echt wilt, is een platform dat voor elke taak het juiste model vindt en die keuze leesbaar maakt.