DevRev's GPT-6.1 Sol-verhaal is eigenlijk een verhaal over waar GPT-6 Astra niet is

OpenAI publiceerde deze week een klantverhaal met de titel "DevRev levert autonome selfservice met GPT-6.1 Sol", en de meest informatieve zin erin gaat helemaal niet over GPT-6.1 Sol. Het is de zin waarin staat dat de sales engineers van DevRev GPT-6 Astra gebruiken om demo's voor congresstands te bouwen. Ahmed Bashir, chief technology officer van DevRev, beschrijft een bedrijf dat zijn modellandschap in tweeën heeft gesplitst: het middenklassemodel draagt het productieondersteuningspad, en het frontier-model draagt datgene waar een prospect negentig seconden naar kijkt. Dat is een nuttiger stuk bewijs dan welke benchmark dan ook in het bericht, omdat het een deploymentbeslissing is die is genomen door iemand die een rekening moet betalen.

De timing is van belang. GPT-6.1 Sol is op 29 september 2026 tijdens DevDay uitgebracht, een week na GPT-6 Sol, voor $2,00 per miljoen inputtokens en $10,00 per miljoen outputtokens. DevRevs eigen verslag over het OpenAI-partnerschap bevat een update-stempel van 2 november 2026, en het klantverhaal is de eerste keer dat een bij naam genoemde productieservice het mid-tiermodel, in plaats van het vlaggenschipmodel, op het klantgerichte pad heeft gezet. Het is geen lancering. Het is de eerste referentieopdracht.

Wat DevRev daadwerkelijk draait

DevRev bouwt twee producten op hetzelfde fundament. Computer is de AI-teamlid dat antwoorden geeft en acties uitvoert binnen bedrijfsgegevens; Operator is de agent die een goedgekeurde actie uitvoert of een verzoek naar de juiste persoon doorverwijst. Beide hebben dezelfde drie dingen nodig voordat een model bij een klant in de buurt mag komen: bedrijfscontext, machtigingen die aansluiten bij de rol van een persoon, en acties die ongedaan kunnen worden gemaakt. Het model levert redenering, planning en toolselectie. De harness van DevRev levert de rest, en Agent Studio is waar een klant in een gesprek beschrijft hoe een tool zich moet gedragen en vervolgens de onderdelen die niet mogen variëren vastlegt met vaste regels.

Twee eigenschappen in het verhaal zijn meer waard dan de lof. Acties zijn omkeerbaar. Antwoorden citeren hun bronnen. Dat zijn de twee faalmodi die bedrijven ervan weerhouden een agent een ticket te laten sluiten, en DevRev claimt beide als productgedrag in plaats van modelgedrag. Als je een selfserviceagent evalueert, zijn dat de vragen die je moet stellen, en geen enkel leaderboard geeft daar antwoord op.

Het getal dat aan dit verhaal wordt gekoppeld, is van juli, en het gaat niet over Sol.

Zoek naar berichtgeving over DevRev en OpenAI en je vindt een opvallend paar cijfers: 48% nauwkeuriger, en 4,4 keer minder tokens per correct antwoord. Ze zijn echt, ze zijn gepubliceerd, en ze hebben niets te maken met GPT-6.1 Sol.

Die cijfers komen uit een publicatie van 9 juli 2026 waarin Enterprise-Bench werd aangekondigd, een open enterprise-agent-benchmark die DevRev samen met het Laude Institute heeft gebouwd en die op de Harbor-harness is gepubliceerd. In die vergelijking scoorde DevRev's Computer 94,3% tegen 63,6% op de XL-dataset, en gebruikte ongeveer 5.598 tokens per correct antwoord tegen 24.461. De vergelijking was expliciet harness tegen harness, waarbij beide systemen met hetzelfde onderliggende model draaiden. DevRev schreef het verschil toe aan zijn retrieval- en gedeeld-geheugenarchitectuur, niet aan het onderliggende model. Het werd ook vergeleken met Claude Code, niet met iets dat OpenAI in september uitbracht.

Het OpenAI-klantverhaal noemt Enterprise-Bench, en Bashir zegt dat GPT-6.1 Sol daar goed op presteert. Dat is een kwalitatieve uitspraak. Er wordt geen score gegeven, geen dataset-slice, geen vergelijking. Wie de julicijfers op het novemberverhaal plakt, meet iets anders op een ander model in een ander kwartaal. De eerlijke lezing is smaller en nog steeds interessant: DevRev heeft een benchmark die het precies voor deze beslissing heeft gebouwd, en het heeft nagelaten daar een Sol-rij op te publiceren.

Wat het verhaal niet zegt

Er staat geen oplossingspercentage, geen ticketvolume, geen latentiepercentiel, geen tokenaantal en geen prijs in de OpenAI-post. Voor een klantverhaal over autonome selfservice ontbreekt daarmee het hele scorebord.

Het dichtstbijzijnde gepubliceerde cijfer is het BILL-proof-of-concept van DevRev, waarbij BILL een AI-afhandelingspercentage van 70% rapporteerde voor echte klantvragen op basis van zijn eigen evaluatie. DevRev's materialen noemen ook een tokenreductie van 77% en een daling van ongeveer negen minuten naar ongeveer 1,5 minuut bij meerstapsvragen, gemeten ten opzichte van zijn eigen eerdere aanpak. Deze zijn door de leverancier gerapporteerd en niet gereproduceerd, en geen ervan is gekoppeld aan de modelgeneratie die nu in productie is. Beschouw ze als de vorm van de bewering, niet als de omvang ervan.

Bashirs eigen beperking is degene om aan vast te houden: "Deze dingen moeten zichzelf in seconden kunnen uitvoeren en afronden, niet in minuten." Een supportinteractie die twintig minuten redeneren kost, is geen selfservice, wat de score ook is. Die zin verklaart de modelkeuze beter dan welke benchmarktabel dan ook.

De berekening die een helpdesk kan controleren

Neem een standaardticket: 20.000 inputtokens aan opgehaalde context, 2.000 outputtokens inclusief redenering. Volgens de lijstprijs van GPT-6.1 Sol is dat $0,04 aan input en $0,02 aan output, dus ongeveer zes cent. Hetzelfde verzoek op GPT-6 Astra, tegen $10,00 input en $50,00 output, kost $0,20 plus $0,10, oftewel ongeveer dertig cent. Zelfde taak, vijf keer de rekening.

Zes cent is een ondergrens, geen voorspelling. Reasoning-tokens worden als output gefactureerd, herkansingen worden dubbel gefactureerd, en elke tool-loop vermenigvuldigt beide. Maar de verhouding is het punt, en die blijft overeind bij alle drie de kanttekeningen. De door OpenAI zelf als leverancier gerapporteerde kostencijfers wijzen dezelfde kant op: op Terminal-Bench Science 0.1 zette OpenAI GPT-6.1 Sol op $5,47 per taak tegenover $23,80 voor GPT-6 Astra en $23,21 voor Claude Opus 5.5, waarbij Sol 57,02% scoorde bij maximale inspanning tegen 68,1% voor Astra. Je koopt elf punten capaciteit voor vier keer het geld, en in een supportqueue is het elfde punt meestal een betere parafrase, geen opgelost ticket.

Dit is de berekening waarop het prijsmodel van OrcaRouter is gebaseerd: de listprijs van de provider wordt zonder opslag doorgegeven, dus een tarief zoals $2,00 en $10,00 is het bedrag dat je betaalt, en een prijswijziging van een leverancier gaat dezelfde dag in in plaats van pas bij de volgende contractverlenging. Beide modellen zitten achter één sleutel, wat betekent dat de splitsing die DevRev in zijn architectuur heeft aangebracht — goedkoop model op het volumepad, duur model waar het antwoord het product is — een routeringsbeslissing is in plaats van een tweede inkooptraject. Voor de stappen waar een verkeerde toolaanroep duur is, is failover naar een sterker model per verzoek het verschil tussen een slechte middag en een slechte week.

Waarom het middenklasse-model het productiepad krijgt

De instinctieve reactie is om dit als een kostenverhaal te lezen. Het is deels een latencyverhaal. GPT-6.1 Sol draait met reasoning altijd aan, over vijf effortniveaus, van low tot max, met medium als standaard, en accepteert temperature of top_p helemaal niet. Daarmee verdwijnt de afstelknop waar de meeste teams naar grijpen wanneer een agent traag aanvoelt, en blijft het effortniveau over als de gashendel. Tussen low en max wordt het verschil in tijd tot het eerste antwoordtoken gemeten in minuten, niet in milliseconden.

De onafhankelijke cijfers liggen waar je ze zou verwachten voor een model in deze categorie. Op de Artificial Analysis Intelligence Index v5.0.1 scoort GPT-6.1 Sol 55 bij maximale inspanning, bij 56 tokens per seconde, $1.27 per voltooide indextaak en 63,7 miljoen outputtokens over de hele run. In onze eigen zeven dagen durende telemetrie laat het een mediane tijd tot eerste token van 937 ms zien, een foutpercentage van 5,7% en 39,5 outputtokens per seconde; dat is het soort profiel waarop een supportflow kan worden gebouwd: niet het snelste beschikbare model, maar voorspelbaar genoeg om een wachtrij erop te dimensioneren.

Het contextvenster is de andere helft van de keuze. Bij 1.050.000 tokens met een uitvoerplafond van 128.000 tokens passen een dossier, de geschiedenis ervan en de opgehaalde kennis allemaal in één verzoek. Dat is wat een agent die "over live gegevens" redeneert mogelijk maakt zonder een uitgebreide chunking-laag — en het is het deel van het specificatieblad waarop een oplossingspercentage van 70% daadwerkelijk berust.

Wat zou hier een case study van maken?

Drie dingen zouden dit veranderen van een logo op een pagina in bewijs waar je op kunt plannen. Een gepubliceerd oplossingspercentage voor Operator, op een benoemde dataset, met het percentage menselijke escalatie ernaast. Een latentieverdeling in plaats van een gemiddelde, omdat p95 is waar selfservice breekt. En een Sol-versus-Astra-ablatie op Enterprise-Bench, aangezien DevRev al over de harness beschikt en al heeft laten zien dat het resultaten publiceert wanneer ze zijn architectuur begunstigen.

Bashir wijst twee dingen aan die hij hierna wil: de Decisions API, voor de kleine afwegingen die duur zijn om als regels te coderen maar geen diepgaand redeneren vereisen, en Ultrafast, OpenAI's 6×-snelheidstarief van $12,00 input en $60,00 output per miljoen tokens, verkrijgbaar sinds 8 oktober. Beide zijn pogingen om latentie te kopen zonder intelligentie te kopen: het juiste instinct voor een supportwachtrij en het tegenovergestelde van wat de meeste agent-roadmaps nastreven.

Het patroon om in de gaten te houden is niet specifiek DevRev. Het is dat de eerste genoemde productie-implementatie van GPT-6.1 Sol het goedkope model plaatste waar klanten zijn en het dure model waar potentiële klanten zijn. Als dat de normale vorm wordt van een enterprise-agentstack — een werkpaard op het volumepad, een vlaggenschip voor de demo — dan is de interessante vraag voor elke leverancier niet langer welk model het slimst is, maar hoe soepel je een verzoek tussen hen kunt verplaatsen.