Jev vägrar skriva ett enda ord: Vad TypeSafe AI:s Decision Model gör, och vad ingen ännu har verifierat

Jev är den första modellen från TypeSafe AI som en läsare sannolikt möter via en kostnadstabell snarare än en chattruta, eftersom det inte finns någon chattruta. Jev lanserades den 15 september 2026 av Diogo Almeida – en medförfattare till InstructGPT-artikeln, arbetet som fick ChatGPT att bete sig som en assistent – och genererar inte text alls. Den tar en bit tillstånd (ett e-postmeddelande, en logglinje, ett supportärende, en JSON-blob med spelkoordinater) plus en lista med typade frågor och returnerar typade svar: ett val från en uppsättning du själv angett, en poäng enligt en bedömningsmall eller en ja/nej-sannolikhet, där var och en bär sitt eget konfidensvärde. Ingen prosa, ingen kod, ingen förklaring. TypeSafe:s pitch är att den här snävheten är produkten, eftersom den ger en hastighet och ett pris som en generativ modell inte kan matcha – 20 till 200 gånger snabbare och 40 till 400 gånger billigare än "jämförbara LLM:er" i företagets egna lanseringsmaterial, till $0,042 per miljon indatatoken med utdata fakturerad till noll.

Den mest användbara siffran som publicerades under de första 48 timmarna är inte någon av dem. Den kommer från Every, där chefen för utvärderingar körde Jev på 27 publicerade Every-artiklar plus 10 AI-stiliserade motsvarigheter och ställde 21 frågor till alla 37 dokumenten samtidigt: 777 bedömningar på under 0,7 sekunder, för ungefär en fjärdedels cent. Ett andra test, som kördes av vd:n för Every, ställde 12 syntetiska passager – sex rena, sex med avsiktligt inplanterade fel – mot fyra skrivkontroller. Jev svarade med en median på 0,35 sekunder per passage, mot 8,83 sekunder för Claude Fable 5.1 med hög ansträngning: ungefär 25 gånger snabbare till omkring 1/580 av kostnaden. Den fångade sex av de sju inplanterade felen. Claude Fable 5.1 fångade alla sju. Omdömet från Every var "bra men inte perfekt", och det är den ärliga enradiga tolkningen av Jev från det enda oberoende test som någon har publicerat hittills – påståendena om hastighet och kostnad överlever kontakt med en tredje part, påståendet om träffsäkerhet ligger ett snäpp under frontlinjen, och urvalet är tillräckligt litet för att ingen bör dra en produktionsslutsats av det.

En kommentar om vilken typ av bevis den här texten arbetar med, eftersom bevisnivåerna är ovanligt långt ifrån varandra för en modell så här ny. Jev är verklig och anropbar: det finns en dokumenterad endpoint, ett Python-SDK, ett modellalias och ett publicerat pris. Lanseringen är leverantörsannonserad, inte läckt, och ingen gissar om den existerar. Men varje prestandapåstående som TypeSafe först lyfter fram är TypeSafes egna, arkitekturen är opublicerad, vikterna är inte ute, och benchmark-instrumentpanelen bakom rubriken 20-200x är en uppsättning interna arbetsflödesutvärderingar snarare än en offentlig resultattavla. En extern part har testat den. Den här artikeln håller leverantörssiffror, oberoende siffror och öppna frågor synligt åtskilda i stället för att medelvärdesbilda dem till en konsensus som inte finns.

Vad TypeSafe faktiskt levererade

Jev är den första av vad TypeSafe kallar System One-modeller – namnet lånat från Daniel Kahnemans snabba, intuitiva hälft av kognitionen, i motsats till det långsammare deliberativa läge som chattbotar imiterar. Kontrasten som TypeSafe drar är mot det vanliga mönstret att tvinga en textgenerator att avge strukturerad utdata och sedan parsa texten tillbaka till något som kod kan lita på. Jev hoppar över texten helt och hållet. TypeSafes egen dokumentation säger det rakt ut: "Stora språkmodeller (LLM:er) är utformade för att producera text som människor ska läsa. När du behöver en modell för att göra en bedömning som din kod ska konsumera, uppstår en missmatchning."

Utdataytan består av tre primitiver, och det finns inget annat. Varje fråga du ställer måste vara en av dem:

• Val — välj ett alternativ från en lista du anger, och returnera det valda alternativet plus en sannolikhet för varje kandidat och en konfidens. Alternativen är begränsade till 255 per fält; utöver det dokumenterar TypeSafe ett tvåstegsmönster för att poängsätta kandidater oberoende och sedan välja.

• Poängsätt — placera tillståndet på en ordnad bedömningsmatris och returnera nivån, en sannolikhet per nivå samt en konfidens. Kundbortfallsrisk på en 0–1-skala är exemplet i dokumentationen.

• Noul — ett teleskopord av ”no” och ”null” — ett enda ja/nej-påstående, som returnerar den kalibrerade sannolikheten att det är sant.

Den intressanta egenskapen är inte någon enskild primitiv, utan hur de komponeras. Alla tre kan blandas i ett enda API-anrop, och varje fråga utvärderas parallellt mot en gemensam läsning av samma tillstånd. TypeSafe:s dokumentation säger att att lägga till frågor "knappt ändrar svarstiden", och det oberoende testet bekräftar det i praktiken — 21 frågor över 37 dokument landade inom samma 0,7 sekunder. Det är vad som får priset per bedömning att kollapsa: du betalar inte för en längre generering, du betalar för ett enda pass.

Den praktiska omfattningen, enligt dokumentationen och enligt vad tidiga användare rapporterat: en förfrågningsbudget på ungefär 32 000 token, i TypeSafe-dokumentationen beskriven som cirka 150 000 engelska tecken; ingen bild- eller ljudinmatning vid lansering; och en form för förfrågan och svar som inte följer OpenAI:s chat-completions-konvention, så att anropa den kräver en skräddarsydd klient i stället för att byta bas-URL. Åtkomst sker via en väntelista för tidig åtkomst plus en webbläsarbaserad testmiljö, med code>jev-latest/code> som modellalias.

RLCD betyder kalibrerad, inte föredragen

TypeSafe tränar Jev med en metod som företaget kallar RLCD – Reinforcement Learning for Calibrated Decisions, enligt företagets egen dokumentation. Förkortningen är så pass ny att tidig rapportering har expanderat den inkonsekvent, så det är värt att fastställa vad den egentligen betecknar, eftersom distinktionen är hela forskningspåståendet.

RLHF optimerar för mänskligt föredragen output. RLVR optimerar för verifierbar korrekthet, den sort där testfallet passerar. RLCD optimerar för kalibrering: en modell som säger sig vara 70 % säker bör ha rätt ungefär 70 % av gångerna. Det är ett annat mål än att ha rätt, och det är anledningen till att varje Jev-svar levereras med en sannolikhetsfördelning bifogad i stället för bara ett svar. Det avsedda felläget är en modell som vet när den inte vet, så att din kod kan avgöra vad den ska göra åt det.

Vad det ger dig i praktiken är en styryta. Det dokumenterade mönstret är tre konfidensband – agera automatiskt i toppen, flagga eller bekräfta i mitten, skicka vidare till en människa i botten – med tröskelvärdena i din kod snarare än i modellen. Huruvida banden är ärliga är en empirisk fråga om dina data, och det är en fråga som TypeSafe uttryckligen säger att du ska besvara själv, och noterar att konfidenströsklar är specifika för användningsfallet och bör testas mot dina egna märkta exempel. Den instruktionen är den viktigaste meningen i dokumentationen, och anledningen till att nästa avsnitt finns.

Siffrorna, sorterade efter vem som producerade dem

Det här är där de flesta genomgångar av Jev blir slappa, så det är värt att vara tydlig med proveniensen. Här är vad som kommer från leverantören, vad som kom från en oberoende testare, och vad som helt enkelt är okänt.

• Leverantörsrapporterat, ej reproducerat — de framhävda hastighets- och kostnadspåståendena. 70–500 ms end-to-end-latens mot 3–329 sekunder för anrop till frontier-LLM:er; 20–200 gånger snabbare och 40–400 gånger billigare; ett enskilt bästa-fall-arbetsflödesresultat som annonserats som 193,6 gånger snabbare och 444,6 gånger billigare. TypeSafe erkänner att dessa är bästa-fall-siffror snarare än universella.

• Rapporterat av leverantören och kontrollerbart i prislistan — 0,042 USD per miljon indatatoken, vilket är 42 USD per miljard, med gratis utdata. Att utdata är gratis är en mekanisk snarare än marknadsföringsmässig effekt: det finns ingen autoregressiv avkodning att mäta, så det finns inga utdatatoken att fakturera. För att sätta siffrorna i perspektiv anger samma lanseringsmaterial att typisk prissättning för indata hos frontier-modeller ligger på 0,20 till 10 USD per miljon, där utdata ofta kostar omkring fem gånger indatapriset.

• Leverantörsrapporterat, från en intern benchmark — TypeSafe:s egen arbetsflödesdashboard, 711 fall fördelade på fyra uppgifter, med referenssvar härledda från den genomsnittliga bedömningen av GPT-6 Astra och Claude Fable 5.1 snarare än ground truth. På den dashboarden aggregerar Jev 67,8 % mot 74,1 % för den bästa jämföraren. Uppdelat: säkerhetsincidenter 61,7 % mot 66,2 % för Opus 5; observerbarhet för agentspår 71,6 % mot 76,6 %; fakturahantering 61,8 % mot 79,1 %; kundservice 76,0 % mot 78,3 %. Jev vinner kostnads- och latenskolumnerna i det diagrammet och förlorar noggrannhetskolumnen. Dashboarden noterar själv en möjlig bias i utvärderingsramverket, och TypeSafe har sagt att man avsiktligt hoppade över offentliga resultattavlor till förmån för engångsutvärderingar kopplade till produktuppdateringar.

• Oberoende uppmätt, litet stickprov – Every-testerna som beskrivs ovan: 777 bedömningar på under 0,7 sekunder för ungefär en fjärdedels cent; 1 709 bedömningar över 11 experiment för under en cent totalt; ungefär 25 gånger snabbare och 1/580 av kostnaden för Claude Fable 5.1 i en klassificeringsuppgift med 12 passager, samtidigt som den missade en av sju planterade defekter som jämföraren upptäckte. Everys egen slutsats var att den skulle vilja ha en mycket grundligare noggrannhetskontroll innan den sattes i produktion.

• Okänt – arkitekturen. Ingen artikel vid lanseringen, inget parameterantal, ingen redovisning av träningsberäkning, inga vikter. TypeSafe har sagt att detaljerna hålls "hemliga för närvarande", med en artikel möjligen senare.

Mönstret över dessa nivåer är konsekvent, och det är inte mönstret som 200x-rubriken antyder. Varje oberoende siffra och varje leverantörssiffra stämmer överens om att Jev är dramatiskt billigare och dramatiskt snabbare. Ingen siffra någonstans, inklusive TypeSafes egna, visar att den är mer träffsäker än de frontiermodeller den prissätts mot. På leverantörens egen instrumentpanel hamnar den runt nivån för en bra mellanklassmodell. Jämförelsen som står sig är inte "lika smart som en frontiermodell för en hundradel av priset" – det är "nära bedömningen hos en mellanklassmodell till en bråkdel av en cent per anrop, tillräckligt snabb för att kunna köras vid varje enskild tur."

Vad "noll hallucination" betyder och inte betyder

TypeSafe:s lanseringsmaterial innehåller ett diagram som visar en felfrekvens på 0 % för verktygsanrop för Jev, jämfört med en icke-nollfrekvens för jämförelsemodeller, och frasen ”hallucinationsresistent” följer med modellen. Båda är sanna, och båda är snävare än de låter.

Garantin är strukturell. Varje möjligt svar räknas upp innan modellen körs – du angav alternativlistan, bedömningsmallen eller sant/falskt-påståendet – så det finns inget utrymme där ett värde utanför den deklarerade typen kan avges. Ett felaktigt utformat verktygsanrop är inte något Jev kan producera. Det är en genuin ingenjörsegenskap, och för alla som har tillbringat en vecka med att skriva återförsökslogik kring JSON-tolkningsfel är den värd riktiga pengar.

Det är inte ett påstående om att ha rätt. Ett schemagiltigt svar kan fortfarande vara fel: Jev kan med stor säkerhet routa ett faktureringsklagomål till den tekniska kön, och utdata kommer att vara perfekt välformad samtidigt som den är oanvändbar. Almeida har själv sagt just detta och medgett att det är möjligt att vara övertygad men ha fel. Ett användbart sätt att hålla båda fakta i huvudet är att Jev eliminerar den felklass som kommer från utdataformatering och inte gör något alls åt den klass som kommer från omdöme. Vilket innebär att frågan om träffsäkerhet helt och hållet är en kalibreringsfråga, och kalibrering är precis det du måste mäta själv.

Så testar du kalibreringspåståendet på dina egna data

Kalibrering är en av de få modellegenskaper du kan kontrollera ordentligt med några hundra exempel och ingen ML-infrastruktur, och det är det enda testet som spelar roll innan Jev rör en produktionsväg. Proceduren är kort.

Ta några hundra fall som du redan har etiketter för. Ställ Jev frågan som spelar roll — routingbeslutet, riskpoängen, defektkontrollen — och gruppera svaren efter den konfidens den rapporterade. Kontrollera sedan om gruppen med 0,9 i konfidens har rätt ungefär 90 % av gångerna, gruppen med 0,7 ungefär 70 %, och så vidare. En välkalibrerad modell följer en diagonal linje. En modell som bara är självsäker klumpar ihop allt över 0,9 och har rätt 70 % av gångerna, och det är formen som tyst bryter en automatiserad pipeline.

Samma test talar om för dig vilka tröskelvärden du ska använda. Om 0,9-hinken verkligen är 90 % träffsäker på dina data kan du automatisera den. Om ditt mellersta band är gröt dirigerar du det till en människa eller lämnar det till en generativ modell och låter den dyra vägen hantera oklarheten. Den uppdelningen – billig modell på den säkra majoriteten, dyr modell på den osäkra återstoden – är den faktiska arkitektur Jev argumenterar för, och det är anledningen till att modellen bäst förstås som en komponent snarare än en ersättning.

Vad det kostar, genomräknat

Prissättningen är tillräckligt enkel att resonera kring, vilket är sällsynt. Indata kostar 0,042 USD per miljon tokens. Utdata är gratis. Vid den dokumenterade förfrågningsbudgeten på ungefär 150 000 tecken kostar ett enda anrop av maximal storlek långt under en cent.

Två rapporterade siffror ger en känsla för skalan. En tidig användare körde cirka 5 000 förfrågningar för ungefär 2 dollar. Doom-demonstrationen — där Jev styrde en bot med hjälp av en textbeskrivning av spelets tillstånd istället för råa pixlar — körde i ungefär 10 anrop per sekund för omkring 7 dollar per timme. Och Everys 777 bedömningar över 37 dokument landade på ungefär en fjärdedels cent, vilket är siffran som gör det intressanta användningsfallet begripligt: till det priset slutar det att vara ett kostnadsbeslut att kontrollera varje enskilt steg i en agentloop och blir en standard.

Det är det verkliga argumentet för Jev. En verifieringsgenomgång per tur – motsade det här verktygsanropet det föregående, stämmer den här utdatan med användarens angivna avsikt, borde detta flaggas – har alltid varit tekniskt möjlig med en frontiermodell och ekonomiskt absurd i skala. Till priset 0,042 USD per miljon tokens utan utdataavgift blir samma genomgång överkomlig vid varje tur. Värdet här ligger inte i att Jev tänker bättre än en frontiermodell, för det gör Jev inte. Värdet ligger i att Jev tänker tillräckligt billigt och snabbt för att kunna rådfrågas ständigt.

Värt att säga rakt ut, eftersom det är den uppenbara nästa frågan: OrcaRouter serverar inte Jev. TypeSafes modell är early-access, har väntelista och talar sitt eget förfrågningsformat, så den som testar den går via TypeSafe direkt. Där ett routningslager faktiskt passar in är i den andra halvan av arbetsflödet. Mönstret som Jev är utformat för är två modeller, inte en – Jev fattar det typade beslutet, och en generativ modell hanterar delen som behöver prosa, kod eller en förklaring. Den generativa halvan är den del som OrcaRouter täcker: 197 modeller hos 15 leverantörer bakom en enda OpenAI-kompatibel nyckel, till leverantörens listpris som vidarebefordras med 0 % påslag, så en leverantörs prissänkning landar på vår sida samma dag som den släpps. Båda halvorna i ett Jev-format arbetsflöde går att testa utan ett andra avtal, och när beslutskomponenten är obeprövad är failover-vägen det som hindrar ett dåligt kalibreringsresultat från att bli en produktionsincident.

Där Jev inte passar

Begränsningarna anges ovanligt tydligt av leverantören, vilket gör det här avsnittet lätt att skriva ärligt. Jev kan inte generera fritext. Det kan inte skriva kod. Det kan inte föra en konversation. Det har inget chattgränssnitt, ingen bildinmatning och en kontextbudget på omkring 32 000 token – en storleksordning under de långkontextmodeller som det jämförs med prismässigt. Valfält har en gräns på 255 alternativ. Och egenskapen "ingen hallucination" handlar, som ovan, om utdataformat snarare än sanning.

Nätet passar ganska snävt. Bra: klassificering och routning i hög volym, skyddsräcken och verifieringspass, latenskritiska beslut, poängsättning av stora dokumentsamlingar parallellt, överallt där det korrekta svaret verkligen är ett val, ett tal på en skala eller ett booleskt värde. Dåligt: öppen generering av alla slag, resonemang över lång kontext, flertursdialog eller uppgifter där rätt svar är en mening. Om ditt problem inte kan reduceras till en typad fråga är Jev inte ett billigare sätt att lösa det – det är inte ett sätt att lösa det över huvud taget.

Det finns också en berättigad kritik av inramningen som är värd att ta med sig vidare. Att kalla Jev för en frontiermodell lånar trovärdighet som modellen inte har förtjänat: den kan inte koda, chatta eller skriva en mening, och jämförelsediagrammen förlitar sig på frontiermodeller som baslinje medan noggrannhetskolumnen berättar en annan historia. Det mer försvarbara påståendet, och det som bevisen faktiskt stöder, är att TypeSafe har drivit hastighets- och kostnadsfronten för strukturerade beslut mycket långt framåt. Det är en betydande sak att ha gjort. Det är en annan sak än att bygga en modell som kan mäta sig med GPT-6 Astra eller Claude Fable 5.1.

Vad skulle förändra den här bilden?

Tre saker, i ungefärlig ordning efter hur mycket de skulle spela roll.

• En publicerad arkitekturartikel eller öppna vikter. Allt om hur Jev uppnår sin snabbhet är för närvarande en svart låda, och påståendet att parallell utvärdering är mekanismen — den analogi Almeida drar är att ersätta sekventiell beräkning på samma sätt som transformers ersatte recurrenta nätverk — är ett påstående snarare än ett demonstrerat resultat. Tills designen har publicerats är hastigheten ett faktum och förklaringen marknadsföring.

• En andra oberoende utvärdering med ett större urval. Everys tester är det starkaste beviset som finns och de täcker 12 textavsnitt i den avgörande noggrannhetsfrågan. En ytterligare oberoende körning, på några hundra märkta fall, skulle avgöra om att missa en defekt av sju var brus eller den verkliga felfrekvensen.

• En kalibreringsgranskning på realistisk, stökig indata. Allt som publicerats hittills använder rena testriggar. Den öppna frågan för en modell vars hela värdeerbjudande vilar på tillförlitliga konfidenspoäng är vad dessa poäng gör i de genuint tvetydiga fallen – de där en mänsklig granskare också skulle tveka. Det är siffran som avgör om det är säkert att automatisera mot Jev, och ingen har publicerat den.

Fram till dess är den rimliga hållningen specifik snarare än generell. Jev är en verklig, levererad, ovanligt billig modell med en genuin strukturell fördel i utdatatillförlitlighet, en noggrannhetsprofil som ligger kring mellannivån, och ett kalibreringspåstående som är rimligt, uttryckligen rekommenderat för egentestning av dess egen leverantör, och oberoende validerat endast på ett litet urval. Om ditt arbetsflöde har ett steg som reduceras till en typad fråga som ställs tillräckligt ofta för att en frontier-modell skulle vara slöseri, är detta ett av de billigaste sätten att ställa den — och konfidensvärdet den returnerar är den del du bör testa innan du litar på den, inte hastigheten.