Verwar een net GPT-6-schema niet met een goed besluit
De keuze tussen AI-modellen lijkt vaak een vergelijking van centen per miljoen tokens. Bij OpenAI GPT laat de actuele modelstand zien waarom die vergelijking tekortschiet. De werkelijke rekening ontstaat pas wanneer een antwoord door de controle komt, een agent zijn taak afmaakt en een medewerker niet opnieuw hoeft te beginnen.
Dat maakt de afweging interessanter dan een ranglijst. Waar het hier om draait: Structured Outputs bij GPT-6 beoordelen als technische controlelaag, zonder syntactische zekerheid te verwarren met inhoudelijke juistheid. We zetten de sterkste kans en de belangrijkste tegenwerping naast elkaar, met een rekenvoorbeeld dat laat zien welke benutting de investering rechtvaardigt.
Direct naar een onderdeel van dit artikel
De verandering zit niet alleen in het model
Waarom een lage tokenprijs kan misleiden
Het sterkste argument voor deze route
De kostenkant verdient meer aandacht
Een rekenvoorbeeld voor 2027 tot en met 2029
Van een goede proef naar een houdbaar proces
Wat een bedrijf nu moet vastleggen
De conclusie volgt uit de uitkomst
In het kort
OpenAI positioneert GPT-6 Astra als vlaggenschip, GPT-6.1 Sol als brede middenroute en GPT-6 Luna als goedkope volumelaag. De standaardprijzen lopen uiteen van $0,10 tot $10 per miljoen invoertokens en van $0,50 tot $50 per miljoen uitvoertokens. Alle drie kunnen gestructureerde uitvoer leveren wanneer de toepassing een JSON-schema afdwingt. De kern is: Structured Outputs bij GPT-6 beoordelen als technische controlelaag, zonder syntactische zekerheid te verwarren met inhoudelijke juistheid. De goedkoopste tokenroute is daardoor niet automatisch de goedkoopste bedrijfsroute. De relevante maat is de prijs per gecontroleerde, bruikbare uitkomst.
De verandering zit niet alleen in het model
Structured Outputs helpt voorkomen dat een antwoord een veld mist, een datum op de verkeerde plaats zet of tekst terugstuurt waar software een getal verwacht. Dat verlaagt de technische foutkans tussen model en applicatie. De inhoud van een geldig veld kan echter nog steeds onjuist zijn. Een factuur kan daardoor keurig terugkomen als leverancier, bedrag en vervaldatum, terwijl het model het bedrag uit de verkeerde tabelrij haalt. De software accepteert dan een perfect geldig object met een verkeerde zakelijke uitkomst. Dat maakt dit een lastige afweging. De technische mogelijkheden nemen toe, terwijl de organisatie meer keuzes krijgt over versie, context, snelheid en kosten. Precies daardoor kan een ogenschijnlijk kleine modelinstelling de kwaliteit van een heel werkproces veranderen.
De officiële documentatie is op 24 oktober 2026 gecontroleerd. Zij beschrijft wat de leverancier aanbiedt en rekent, maar niet wat een specifieke Nederlandse organisatie ermee bespaart. Daarvoor zijn eigen taken, eigen foutgrenzen en eigen controletijd nodig. De bron voor deze modelstand is https://developers.openai.com/api/docs/models.
Waarom een lage tokenprijs kan misleiden
Een streng schema haalt herstelwerk uit de technische koppeling. Minder mislukte parsers betekenen minder herhaalverzoeken en minder uitzonderingscode. Daar staat tegenover dat iedere velddefinitie, enum en validatieregel moet worden ontworpen en onderhouden. Wanneer het werkproces verandert, moet het schema mee. Een token is meetbaar en verschijnt direct op de factuur. De tijd van een medewerker die een antwoord moet controleren, een fout moet herstellen of een klant moet terugbellen staat meestal in een ander systeem. Wie alleen de API-rekening bekijkt, ziet dus maar een deel van de kosten.
Een bruikbare vergelijking begint met dezelfde taak en dezelfde kwaliteitsgrens. Tel vervolgens alle invoer, uitvoer, cache, redeneertokens, gereedschappen en herhaalpogingen. Deel dat bedrag door het aantal uitkomsten dat zonder herstel door de controle komt. Pas dan ontstaat een prijs per succesvolle taak die tussen modellen te vergelijken is.
Daar komt beschikbaarheid bij. Een sneller antwoord heeft waarde als een medewerker erop wacht of een klant anders afhaakt. Voor nachtelijke batchverwerking is dezelfde snelheid vaak weinig waard. Batchkorting kan dan aantrekkelijker zijn dan een snellere en duurdere route.
Het sterkste argument voor deze route
Het sterkste argument voor deze aanpak is de voorspelbaarheid. Bij tienduizenden classificaties kan een daling van twee naar een half procent technische uitval al honderden handmatige correcties besparen. Astra hoeft dan niet overal te draaien. Luna of Sol kan eenvoudige velden vullen, terwijl een inhoudelijke controle alleen risicovolle dossiers naar Astra stuurt. Dat scenario verdient serieus aandacht, omdat niet ieder proces dezelfde foutkosten heeft. Een marketingconcept kan snel worden verworpen. Een verkeerde contractclausule of een onjuiste boeking kan veel meer herstelwerk veroorzaken.
De modelkeuze hoeft daarom niet voor de hele organisatie gelijk te zijn. Een smalle routering kan eenvoudige opdrachten naar een goedkoop model sturen en alleen moeilijke of risicovolle gevallen opschalen. Die opzet werkt alleen wanneer de organisatie vooraf meet wat moeilijk en risicovol betekent. Zonder die grens wordt opschalen willekeurig en verdwijnt de beloofde besparing.
De kostenkant verdient meer aandacht
De zwakke plek ligt na de parser. Wie een geldig object automatisch boekt, verwart vorm met bewijs. Een tweede regel moet controleren of bedragen optellen, datums logisch zijn en de bronpassage werkelijk bij het veld hoort. Zonder die controle verplaatst Structured Outputs de fout van de API naar de administratie. Leveranciersbenchmarks blijven nuttig om mogelijkheden te verkennen, maar ze meten zelden de volledige workflow. Een hoge score zegt weinig over de kwaliteit van bronverwijzingen, de stabiliteit van JSON, de omgang met Nederlandse uitzonderingen of de tijd die een reviewer nodig heeft.
Ook cache en lange context vragen om discipline. Hergebruik kan de rekening sterk verlagen, maar alleen wanneer dezelfde context daadwerkelijk terugkomt. Een groot contextvenster voorkomt knipwerk, maar betaalt geen rente op ongebruikte informatie. De beste configuratie is vaak kleiner en voorspelbaarder dan de maximale technische limiet.
Ten slotte moet de economische eigenaar duidelijk zijn. De IT-afdeling ziet tokens en beschikbaarheid, de vakafdeling ziet controletijd en fouten, en finance ziet de totale kasuitgave. Wanneer die drie cijfers niet bij elkaar komen, kan een succesvolle proef alsnog een duur productieproces worden.
Een rekenvoorbeeld voor 2027 tot en met 2029
Het volgende voorbeeld is nadrukkelijk geen voorspelling. Stel dat de invoering €22.000 kost, met €9.000 jaarlijkse beheer- en controlekosten. Een goedgekeurde taak voorkomt gemiddeld €5,40 aan tijd of herstel; de variabele kosten bedragen €0,65. De omgekeerde formule voor het eerste jaar is dan (€22.000 + €9.000) gedeeld door €4,75. De drempel ligt op ongeveer 6.527 goedgekeurde taken.
Voor het lage scenario is uitgegaan van trage ingebruikname en veel menselijke controle. Het middenscenario veronderstelt dat de workflow stabiel wordt en het aantal bruikbare taken jaarlijks groeit. Het hoge scenario veronderstelt meer volume en minder herstel, zonder de foutkosten weg te poetsen. De visual rekent de taakvolumes per scenario om naar nettokasbesparing: volume maal bijdrage per goede taak, min jaarlijkse kosten en in 2027 ook de invoering. Het zijn kaswaarden vóór belasting en financiering.
De beslissende variabele is niet het totale aantal aanvragen, maar het aantal goedgekeurde uitkomsten. Wanneer slechts de helft van de antwoorden bruikbaar blijkt, verdubbelt grofweg het aantal aanvragen dat voor dezelfde zakelijke opbrengst nodig is. Daardoor kan een duurder model met een hogere slaagkans economisch winnen.
Van een goede proef naar een houdbaar proces
Een proef werkt vaak met enthousiaste medewerkers, schone voorbeelden en veel aandacht van ontwikkelaars. Productie is minder vriendelijk. Documenten zijn rommelig, gebruikers formuleren dezelfde opdracht anders en piekbelasting komt precies wanneer de vakafdeling haast heeft. Daarom hoort de evaluatie niet te stoppen na de eerste demonstratie. Meet per maand hoeveel taken zonder herstel slagen, hoeveel minuten controle nodig zijn en welke uitzonderingen telkens terugkomen.
Voor OpenAI GPT is bovendien belangrijk dat modelnamen, prijsroutes en beschikbaarheid kunnen veranderen. Bewaar daarom bij iedere aanvraag de datum, werkelijk gebruikte modelversie, hoeveelheid context, eventuele cachetreffer en gereedschapsaanroepen. Die gegevens maken later zichtbaar of een kostenstijging door meer gebruik, een duurdere route of slechtere kwaliteit kwam. Zonder die uitsplitsing wordt de rekening een totaalbedrag waar niemand meer een besluit uit kan afleiden.
Ook inkoopvoorwaarden tellen mee. Batchkorting, gereserveerde capaciteit of eigen hardware kan een lagere eenheidsprijs geven, maar maakt de organisatie minder flexibel. Een contract is pas goedkoop wanneer het volume werkelijk wordt benut. Een server is pas rendabel wanneer bezetting, energie, beheer en afschrijving samen lager blijven dan de vermeden cloudkosten. Dat is een kasstroomvraag, geen technisch prestigeproject.
Wat een bedrijf nu moet vastleggen
Gebruik het schema als contract tussen model en software en bouw daarnaast zakelijke controles. Meet apart hoeveel aanvragen op syntaxis stranden en hoeveel geldige objecten inhoudelijk worden afgekeurd. Pas daarna is zichtbaar of Astra, Sol of Luna per taak de laagste kosten per goedgekeurd dossier levert. Leg daarnaast de actuele modelversie, prijslaag en peildatum vast. Maak vervolgens een set echte taken met duidelijke acceptatiecriteria. Meet de eerste poging, de herhaalpogingen, de controletijd en eventuele schade door fouten. Doe dit opnieuw wanneer een alias, versie, provider of quantisatie verandert.
Een productiecontract verdient daarnaast een limiet per taak, een log van de werkelijk gebruikte versie en een terugvalroute. Die terugvalroute moet vooraf zijn getest. Een tweede model dat bij een storing voor het eerst wordt aangeroepen, is geen continuïteitsplan maar een experiment op het slechtste moment.
De conclusie volgt uit de uitkomst
GPT-6 volgt het schema maar de beslissing kan nog steeds verkeerd zijn is daarmee geen pleidooi voor de duurste of goedkoopste route. Het is een pleidooi om de economische maat op de goede plaats te zetten. Tokens zijn grondstof; een gecontroleerde beslissing, codewijziging of klantactie is het product.
De overtuiging wordt sterker wanneer dezelfde kwaliteit aantoonbaar met minder herhaalwerk wordt geleverd. Zij wordt zwakker wanneer de beloofde besparing alleen uit leveranciersprijzen komt en de controletijd buiten beeld blijft. Opnieuw kijken wanneer OpenAI prijzen wijzigt, een schemafunctie voor bronverankering toevoegt of eigen metingen laten zien dat de inhoudelijke foutkans van de goedkope route aantoonbaar daalt.
Word abonnee van De Belegger en gebruik code GRAAG voor toegang tot onze analyses.
Opmerkingen