DevRevs berättelse om GPT-6.1 Sol handlar egentligen om var GPT-6 Astra inte finns

OpenAI publicerade den här veckan en kundberättelse med titeln "DevRev levererar autonom självbetjäning med GPT-6.1 Sol", och den mest informativa meningen i den handlar inte alls om GPT-6.1 Sol. Det är den där DevRevs säljingenjörer sägs använda GPT-6 Astra för att bygga demos för konferensmontrar. DevRevs teknikchef Ahmed Bashir beskriver ett företag som har delat upp sin modellportfölj i två delar: mellannivåmodellen ansvarar för produktionssupporten, och frontier-modellen ansvarar för det som en potentiell kund tittar på i nittio sekunder. Det är ett mer användbart bevis än något benchmark i inlägget, eftersom det är ett driftsättningsbeslut fattat av någon som har en räkning att betala.

Tajmingen spelar roll. GPT-6.1 Sol släpptes den 29 september 2026 på DevDay, en vecka efter GPT-6 Sol, för 2,00 USD per miljon indatatoken och 10,00 USD per miljon utdatatoken. DevRevs egen artikel om OpenAI-partnerskapet bär en uppdateringsstämpel daterad 2 november 2026, och kundberättelsen är första gången en namngiven produktionstjänst har satt mellannivåmodellen, snarare än flaggskeppet, på den kundvända vägen. Det är inte en lansering. Det är den första jobbreferensen.

Vad DevRev faktiskt kör

DevRev bygger två produkter på samma underliggande plattform. Computer är AI-teammedlemmen som svarar och agerar över affärsdata; Operator är agenten som utför en godkänd åtgärd eller dirigerar en begäran till rätt person. Båda behöver samma tre saker innan en modell tillåts komma nära en kund: företagskontext, behörigheter som matchar en persons roll och åtgärder som kan ångras. Modellen bidrar med resonemang, planering och val av verktyg. DevRev:s harness bidrar med resten, och Agent Studio är där en kund i samtal beskriver hur ett verktyg ska bete sig och sedan låser de delar som inte får variera med fasta regler.

Två egenskaper i berättelsen är värda mer än berömmet. Åtgärder är reversibla. Svar citerar sina källor. Det är de två felsätt som hindrar företag från att låta en agent stänga ett ärende, och DevRev hävdar att båda är produktbeteende snarare än modellbeteende. Om du utvärderar någon självbetjäningsagent är det de frågorna du bör ställa, och ingen resultattavla besvarar dem.

Siffran som kommer att kopplas till den här historien är från juli, och den handlar inte om Sol.

Sök efter rapportering om DevRev och OpenAI och du hittar ett slående par siffror: 48 % mer träffsäker och 4,4 gånger färre tokens per korrekt svar. De är verkliga, de är publicerade och de har ingenting att göra med GPT-6.1 Sol.

De siffrorna kommer från ett släpp den 9 juli 2026 som tillkännagav Enterprise-Bench, ett öppet benchmark för företagsagenter som DevRev byggde tillsammans med Laude Institute och publicerade på Harbor-harnesset. I den jämförelsen fick DevRevs Computer 94,3 % mot 63,6 % på XL-datasetet och använde ungefär 5 598 tokens per korrekt svar mot 24 461. Jämförelsen var uttryckligen harness mot harness, där båda systemen körde samma underliggande modell. DevRev tillskrev gapet sin retrieval- och delade-minnesarkitektur, inte den underliggande modellen. Den benchmarkades också mot Claude Code, inte mot något som OpenAI släppte i september.

OpenAI:s kundberättelse nämner Enterprise-Bench, och Bashir säger att GPT-6.1 Sol presterar bra på det. Det är ett kvalitativt uttalande. Ingen poäng anges, ingen delmängd av data, ingen jämförelse. Den som kopplar julitorna till novemberberättelsen mäter något annat på en annan modell under ett annat kvartal. Den ärliga läsningen är snävare och fortfarande intressant: DevRev har ett benchmark som företaget byggde just för detta beslut, och det valde att inte publicera en Sol-rad på det.

Vad berättelsen inte säger

Det finns ingen lösningsgrad, ingen ärendevolym, ingen latenspercentil, inget tokenantal och inget pris i OpenAI-inlägget. För en kundberättelse om autonom självbetjäning saknas hela resultattavlan.

Den närmaste publicerade siffran är DevRev:s BILL-proof of concept, där BILL rapporterade en AI-lösningsgrad på 70 % för verkliga kundfrågor med hjälp av sin egen utvärdering. DevRev:s material nämner också en tokenminskning på 77 % och en minskning från cirka nio minuter till cirka 1,5 minuter för flerstegsfrågor, mätt mot företagets egen tidigare metod. Dessa är leverantörsrapporterade och inte reproducerade, och ingen av dem är kopplad till den modellgeneration som nu är i produktion. Betrakta dem som påståendets form, inte dess storlek.

Bashirs egen begränsning är den man ska hålla fast vid: "De här sakerna måste kunna köras och slutföra sig själva på sekunder, inte minuter." En supportinteraktion som tar tjugo minuters resonemang är inte självbetjäning, vad den än får för poäng. Den meningen förklarar modellvalet bättre än någon benchmarktabell.

Aritmetiken som en supportavdelning kan kontrollera

Ta ett rutinärende: 20 000 indatatokens av hämtad kontext, 2 000 utdatatokens inklusive resonemang. Enligt GPT-6.1 Sols listpris är det $0,04 för indata och $0,02 för utdata, alltså ungefär sex cent. Samma förfrågan på GPT-6 Astra, med $10,00 för indata och $50,00 för utdata, kostar $0,20 plus $0,10, eller ungefär trettio cent. Samma uppgift, fem gånger kostnaden.

Sex cent är ett golv snarare än en prognos. Resonemangstokens faktureras som utdata, omförsök faktureras dubbelt, och varje verktygsslinga multiplicerar båda. Men förhållandet är poängen, och det står sig trots alla tre förbehållen. OpenAIs egna leverantörsrapporterade kostnadssiffror pekar i samma riktning: på Terminal-Bench Science 0.1 satte OpenAI GPT-6.1 Sol till 5,47 dollar per uppgift mot 23,80 dollar för GPT-6 Astra och 23,21 dollar för Claude Opus 5.5, medan Sol fick 57,02 % vid maximal ansträngning mot Astras 68,1 %. Du köper elva poäng kapacitet för fyra gånger pengarna, och i en supportkö är den elfte poängen vanligtvis en bättre omskrivning, inte ett löst supportärende.

Detta är beräkningen som OrcaRouter-prismodellen bygger på: leverantörslistpris som förs vidare utan påslag, så en taxa som $2.00 och $10.00 är summan du betalar, och en leverantörsprisändring slår igenom samma dag i stället för vid nästa avtalsförnyelse. Båda modellerna ligger bakom en och samma nyckel, vilket innebär att den uppdelning DevRev har gjort i sin arkitektur – billig modell på volymvägen, dyr modell där svaret är produkten – är ett routingbeslut i stället för en andra upphandling. För de steg där ett felaktigt verktygsanrop är dyrt är redundansväxling till en starkare modell per begäran skillnaden mellan en dålig eftermiddag och en dålig vecka.

Varför mellannivåmodellen får produktionsvägen

Instinkten är att läsa det här som en kostnadshistoria. Det är delvis en latenshistoria. GPT-6.1 Sol körs med resonemang alltid påslaget över fem ansträngningsnivåer, från låg till max, med medium som standard, och det accepterar inte temperature eller top_p alls. Det tar bort inställningsratten som de flesta team griper efter när en agent känns långsam, och lämnar ansträngningsnivån som gaspedalen. Mellan låg och max mäts skillnaden i tid till en första svarstoken i minuter, inte millisekunder.

De oberoende siffrorna ligger där man skulle förvänta sig för en modell i den här klassen. På Artificial Analysis Intelligence Index v5.0.1 får GPT-6.1 Sol 55 vid maximal ansträngning, med 56 token per sekund, 1,27 USD per slutförd indexuppgift och 63,7 miljoner utdatatoken under hela körningen. I vår egen sjudagars-telemetri uppvisar den en median på 937 ms till första token, en felfrekvens på 5,7 % och 39,5 utdatatoken per sekund, vilket är den typ av profil som ett supportflöde kan byggas på: inte den snabbaste modellen som finns, men tillräckligt förutsägbar för att en kö ska kunna dimensioneras efter den.

Kontextfönstret är den andra halvan av valet. Vid 1 050 000 tokens med ett utdatatak på 128 000 tokens får en ärendefil, dess historik och den hämtade kunskapen plats i en och samma förfrågan. Det är det som gör en agent som resonerar "över livedata" möjlig utan ett invecklat chunkningslager – och det är den del av specifikationsbladet som en lösningsgrad på 70 % faktiskt är beroende av.

Vad skulle göra det här till en fallstudie?

Tre saker skulle flytta detta från en logotyp på en sida till bevis du kan planera utifrån. En publicerad lösningsgrad för Operator, på en namngiven datamängd, med andelen eskaleringar till människa bredvid. En latensfördelning i stället för ett genomsnitt, eftersom p95 är där självbetjäningen brister. Och en ablation mellan Sol och Astra på Enterprise-Bench, eftersom DevRev redan äger testriggen och redan har visat att man publicerar resultat när de gynnar deras arkitektur.

Bashir pekar på två saker han vill ha härnäst: Decisions API, för de små bedömningsbeslut som är dyra att koda som regler men inte kräver djup resonemang, och Ultrafast, OpenAIs 6×-hastighetsnivå till $12.00 för indata och $60.00 för utdata per miljon tokens, köpbar sedan 8 oktober. Båda är försök att köpa latens utan att köpa intelligens, vilket är rätt instinkt för en supportkö och motsatsen till vad de flesta agentfärdplaner strävar efter.

Mönstret att hålla ögonen på är inte specifikt DevRev. Det är att den första namngivna produktionsdriftsättningen av GPT-6.1 Sol placerade den billiga modellen där kunderna finns och den dyra modellen där prospekterna finns. Om det blir den normala formen för en företagsagentstack – en arbetshäst på volymvägen, en flaggskeppsmodell för demon – slutar den intressanta frågan för varje leverantör att vara vilken modell som är smartast och börjar bli hur smidigt du kan flytta en förfrågan mellan dem.