Jev weigert ook maar één woord te schrijven: wat het beslissingsmodel van TypeSafe AI doet, en wat nog niemand heeft geverifieerd

Jev is het eerste model van TypeSafe AI dat een lezer waarschijnlijk eerder via een kostentabel dan via een chatbox tegenkomt, omdat er geen chatbox is. Gelanceerd op 15 september 2026 door Diogo Almeida — medeauteur van het InstructGPT-artikel, het werk waardoor ChatGPT zich als een assistent ging gedragen — genereert Jev helemaal geen tekst. Het neemt een stukje toestand (een e-mail, een logregel, een supportticket, een JSON-blob met spelcoördinaten) plus een lijst met getypeerde vragen, en retourneert getypeerde antwoorden: een keuze uit een set die je hebt aangeleverd, een score op een rubric, of een ja/nee-kans, elk met een eigen betrouwbaarheidswaarde. Geen proza, geen code, geen uitleg. De pitch van TypeSafe is dat juist die beperktheid het product is, omdat die snelheid en prijs oplevert die een generatief model niet kan evenaren — 20 tot 200 keer sneller en 40 tot 400 keer goedkoper dan "vergelijkbare LLM's" in de eigen lanceringsmaterialen van het bedrijf, tegen $0,042 per miljoen invoertokens, waarbij output tegen nul wordt gefactureerd.

Het nuttigste getal dat in de eerste 48 uur is gepubliceerd, is niet een van die. Het komt van Every, waar het hoofd evaluaties Jev liet draaien over 27 gepubliceerde Every-artikelen plus 10 tegenhangers in AI-stijl, waarbij 21 vragen aan alle 37 documenten tegelijk werden gesteld: 777 beoordelingen in minder dan 0,7 seconden, voor ongeveer een kwart van een cent. Een tweede test, uitgevoerd door de CEO van Every, zette 12 synthetische passages — zes schone, zes met opzettelijk aangebrachte defecten — tegenover vier schrijfcontroles. Jev kwam uit op een mediaan van 0,35 seconden per passage tegenover 8,83 seconden voor Claude Fable 5.1 bij hoge inspanning: ongeveer 25 keer sneller tegen ongeveer 1/580 van de kosten. Het detecteerde zes van de zeven aangebrachte defecten. Claude Fable 5.1 detecteerde ze alle zeven. Het oordeel van Every was "goed maar niet perfect", en dat is de eerlijke samenvatting in één regel van Jev op basis van de enige onafhankelijke test die iemand tot nu toe heeft gepubliceerd — de beweringen over snelheid en kosten doorstaan contact met een derde partij, de nauwkeurigheidsclaim zit een tandje onder de frontier, en de steekproef is klein genoeg dat niemand er een productieconclusie uit zou moeten trekken.

Een opmerking over met wat voor soort bewijs dit stuk werkt, omdat de niveaus ongewoon ver uit elkaar liggen voor een model dat zo nieuw is. Jev is echt en aanroepbaar: er is een gedocumenteerd endpoint, een Python-SDK, een modelalias en een gepubliceerde prijs. De lancering is door de leverancier aangekondigd, niet uitgelekt, en niemand hoeft te gissen of het bestaat. Maar elke prestatieclaim waarmee TypeSafe uitpakt, is van TypeSafe zelf, de architectuur is niet gepubliceerd, de gewichten zijn niet vrijgegeven, en het benchmarkdashboard achter de 20-200x-kop is een reeks interne workflowevaluaties in plaats van een openbare ranglijst. Eén externe partij heeft het getest. Dit artikel houdt leverancierscijfers, onafhankelijke cijfers en open vragen zichtbaar gescheiden in plaats van ze te middelen tot een consensus die niet bestaat.

Wat TypeSafe daadwerkelijk heeft uitgebracht

Jev is de eerste van wat TypeSafe System One-modellen noemt — de naam is ontleend aan de snelle, intuïtieve helft van Daniel Kahnemans cognitie, in tegenstelling tot de langzamere, weloverwogen modus die chatbots nabootsen. Het contrast dat TypeSafe trekt, is met het standaardpatroon waarbij een tekstgenerator wordt gedwongen gestructureerde output te produceren en die tekst vervolgens weer wordt geparseerd naar iets waarop code kan vertrouwen. Jev slaat de tekst volledig over. In de eigen documentatie van TypeSafe staat het onomwonden: "Grote taalmodellen (LLM's) zijn ontworpen om tekst te produceren die mensen kunnen lezen. Wanneer je een model een oordeel wilt laten vellen dat door je code wordt gebruikt, ontstaat er een mismatch."

Het uitvoeroppervlak bestaat uit drie primitieven, en er is niets anders. Elke vraag die je stelt moet een van hen zijn:

• Keuze — kies één optie uit een lijst die u aanlevert, en retourneer de gekozen optie plus een waarschijnlijkheid voor elke kandidaat en een betrouwbaarheid. Opties zijn beperkt tot 255 per veld; daarbuiten documenteert TypeSafe een patroon in twee fasen: eerst worden kandidaten onafhankelijk gescoord en daarna wordt er gekozen.

• Score — plaats de toestand op een geordende rubric, waarbij je het niveau, een waarschijnlijkheid per niveau en een zekerheid teruggeeft. Churnrisico op een schaal van 0-1 is het voorbeeld in de documentatie.

• Noul — een samentrekking van "no" en "null" — een enkele ja/nee-bewering, die de gekalibreerde waarschijnlijkheid teruggeeft dat deze waar is.

De interessante eigenschap is niet een of ander afzonderlijk primitief, maar hoe ze zich samenvoegen. Alle drie kunnen ze in één API-aanroep worden gecombineerd, en elke vraag wordt parallel geëvalueerd tegen één gedeelde uitlezing van dezelfde toestand. Volgens de documentatie van TypeSafe verandert het toevoegen van vragen "nauwelijks de responstijd", en de onafhankelijke test bevestigt dat in de praktijk: 21 vragen over 37 documenten bleven binnen dezelfde 0,7 seconden. Dat is wat de prijs per beoordeling laat instorten: je betaalt niet voor een langere generatie, je betaalt voor één pass.

De praktische grenzen, zoals gedocumenteerd en zoals gerapporteerd door vroege gebruikers: ruwweg een aanvraagbudget van 32.000 tokens, in de documentatie van TypeSafe beschreven als ongeveer 150.000 Engelse tekens; geen beeld- of audio-invoer bij de lancering; en een aanvraag- en antwoordstructuur die niet overeenkomt met de OpenAI chat-completions-conventie, dus voor het aanroepen is een op maat gemaakte client nodig in plaats van een base-URL-omwisseling. Toegang verloopt via een early-access-wachtlijst plus een browser-playground, met code>jev-latest/code> als modelalias.

RLCD betekent gekalibreerd, niet geprefereerd

TypeSafe traint Jev met een methode die het RLCD noemt — Reinforcement Learning for Calibrated Decisions, volgens de eigen documentatie van het bedrijf. Het acroniem is zo nieuw dat vroege berichtgeving het inconsistent heeft uitgeschreven, dus het is de moeite waard om precies vast te stellen wat het eigenlijk benoemt, want dat onderscheid vormt de hele onderzoeksclaim.

RLHF optimaliseert voor door mensen geprefereerde output. RLVR optimaliseert voor verifieerbare correctheid, het soort dat de testcase doorstaat. RLCD optimaliseert voor kalibratie: een model dat zegt dat het 70% zeker is, zou ongeveer 70% van de tijd gelijk moeten hebben. Dat is een ander doel dan gelijk hebben, en het is de reden dat elk Jev-antwoord met een bijgevoegde kansverdeling wordt geleverd in plaats van alleen een antwoord. De beoogde faalmodus is een model dat weet wanneer het iets niet weet, zodat je code kan beslissen wat daaraan te doen.

Wat dat je in de praktijk oplevert, is een bedieningsoppervlak. Het gedocumenteerde patroon bestaat uit drie betrouwbaarheidsbanden — bovenin automatisch handelen, in het midden markeren of bevestigen, onderaan doorverwijzen naar een mens — waarbij de drempels in je code leven in plaats van in het model. Of de banden eerlijk zijn, is een empirische vraag over je data, en het is er een die TypeSafe je expliciet vertelt zelf te beantwoorden, met de opmerking dat betrouwbaarheidsdrempels gebruiksspecifiek zijn en getest moeten worden tegen je eigen gelabelde voorbeelden. Die instructie is de belangrijkste zin in de documentatie, en de reden dat de volgende sectie bestaat.

De nummers, gesorteerd op wie ze heeft geproduceerd

Dit is waar de meeste berichtgeving over Jev vaag wordt, dus het is de moeite waard om expliciet te zijn over de herkomst. Dit is wat van de leverancier komt, wat van een onafhankelijke tester kwam, en wat simpelweg onbekend is.

• Door leverancier gerapporteerd, niet gereproduceerd — de opvallende snelheids- en kostenclaims. 70-500 ms end-to-endlatentie tegenover 3-329 seconden voor frontier-LLM-aanroepen; 20-200x sneller en 40-400x goedkoper; één resultaat van een workflow in het gunstigste geval, aangeprezen als 193,6x sneller en 444,6x goedkoper. TypeSafe erkent dat dit cijfers voor het gunstigste geval zijn en niet universele cijfers.

• Door de leverancier gerapporteerd en controleerbaar op de prijslijst — $0,042 per miljoen inputtokens, wat $42 per miljard is, met gratis output. De reden dat output gratis is, is mechanisch en niet promotioneel: er is geen autoregressieve decoding om te meten, dus er zijn geen outputtokens om te factureren. Ter vergelijking: dezelfde lanceringsmaterialen zetten de typische frontier-inputprijzen op $0,20 tot $10 per miljoen, waarbij output vaak ongeveer vijf keer de inputprijs is.

• Door de leverancier gerapporteerd, afkomstig uit een interne benchmark — het eigen workflowdashboard van TypeSafe, 711 casussen verdeeld over vier taken, met referentieantwoorden die zijn afgeleid van de gemiddelde beoordeling van GPT-6 Astra en Claude Fable 5.1 in plaats van de grondwaarheid. Op dat dashboard komt Jev geaggregeerd uit op 67,8% tegenover 74,1% voor de beste comparator. Uitgesplitst: beveiligingsincidenten 61,7% tegenover 66,2% voor Opus 5; observability van agent-traces 71,6% tegenover 76,6%; factuurverwerking 61,8% tegenover 79,1%; klantenservice 76,0% tegenover 78,3%. Jev wint op die grafiek de kolommen voor kosten en latentie en verliest de kolom voor nauwkeurigheid. Het dashboard zelf vermeldt een mogelijke bias in de testomgeving, en TypeSafe heeft gezegd dat het bewust publieke leaderboards heeft overgeslagen ten gunste van eenmalige evaluaties die aan productupdates zijn gekoppeld.

• Onafhankelijk gemeten, kleine steekproef — de hierboven beschreven Every-tests: 777 beoordelingen in minder dan 0,7 seconden voor ongeveer een kwart cent; 1.709 beoordelingen in 11 experimenten voor in totaal minder dan een cent; ongeveer 25x sneller en 1/580e van de kosten van Claude Fable 5.1 bij een classificatietaak met 12 passages, terwijl het één van de zeven ingebrachte defecten miste die de comparator wel opving. De eigen conclusie van Every was dat het een veel grondiger nauwkeurigheidscontrole zou willen voordat het in productie wordt genomen.

• Onbekend — de architectuur. Geen paper bij de lancering, geen parameteraantal, geen openbaarmaking van de rekenkracht die bij de training is gebruikt, geen gewichten. TypeSafe heeft gezegd dat de details "voorlopig nog even onder de pet worden gehouden", met mogelijk later een paper.

Het patroon over die niveaus is consistent, en het is niet het patroon dat de 200x-kop suggereert. Elk onafhankelijk cijfer en elk leverancierscijfer is het erover eens dat Jev dramatisch goedkoper en dramatisch sneller is. Geen enkel cijfer, waar dan ook, inclusief dat van TypeSafe zelf, toont aan dat het nauwkeuriger is dan de frontiermodellen waarmee het qua prijs wordt vergeleken. Op het dashboard van de leverancier zelf komt het uit rond het niveau van een goed model uit de middenklasse. De vergelijking die standhoudt is niet "net zo slim als een frontiermodel voor een honderdste van de prijs" — het is "dicht bij het beoordelingsvermogen van een model uit de middenklasse voor een fractie van een cent per aanroep, snel genoeg om bij elke afzonderlijke beurt te draaien."

Wat "zero hallucination" wel en niet betekent

Het lanceringsmateriaal van TypeSafe bevat een grafiek die een foutpercentage van 0% bij tool-aanroepen voor Jev laat zien, tegenover een niet-nulpercentage voor vergelijkingsmodellen, en de formulering "hallucinatiebestendig" reist mee met het model. Beide zijn waar en beide zijn beperkter dan ze lijken.

De garantie is structureel. Elk mogelijk antwoord wordt opgesomd voordat het model draait — jij hebt de keuzelijst, de rubric of de waar/onwaar-bewering aangeleverd — dus er is geen ruimte om een waarde buiten het gedeclareerde type te produceren. Een misvormde tool-aanroep is niet iets wat Jev kan produceren. Dat is een echte engineering-eigenschap, en voor iedereen die een week heeft besteed aan het schrijven van retry-logica rond JSON-parsefouten, is het echt geld waard.

Het is geen bewering over correct zijn. Een schema-valide antwoord kan nog steeds fout zijn: Jev kan een factuurklacht vol vertrouwen naar de technische wachtrij sturen, en de output zal perfect welgevormd zijn terwijl die nutteloos is. Almeida heeft dat zelf gezegd, en erkende dat het mogelijk is om vol vertrouwen fout te zijn. De nuttige manier om beide feiten te hanteren is dat Jev de categorie fouten elimineert die voortkomt uit de opmaak van de output, en helemaal niets doet aan de categorie die voortkomt uit het oordeel. Wat betekent dat de nauwkeurigheidsvraag volledig een kalibratievraag is, en kalibratie is precies het ding dat je zelf moet meten.

Hoe je de kalibratieclaim op je eigen data kunt testen

Calibratie is een van de weinige modeleigenschappen die je goed kunt controleren met een paar honderd voorbeelden en zonder ML-infrastructuur, en het is de enige test die ertoe doet voordat Jev een productiepad aanraakt. De procedure is kort.

Neem een paar honderd gevallen waarvoor je al labels hebt. Stel Jev de vraag die ertoe doet — de routeringsbeslissing, de risicoscore, de defectcontrole — en verdeel de antwoorden in buckets op basis van het gerapporteerde vertrouwen. Controleer vervolgens of de bucket met 0,9 vertrouwen ongeveer 90% van de tijd gelijk heeft, de bucket met 0,7 ongeveer 70%, enzovoort. Een goed gekalibreerd model volgt een diagonale lijn. Een model dat louter zelfverzekerd is, clustert alles boven 0,9 en heeft 70% van de tijd gelijk, en dat is de vorm die een geautomatiseerde pijplijn stilletjes kapotmaakt.

Dezelfde test vertelt je welke drempels je moet gebruiken. Als de 0,9-bucket echt 90% nauwkeurig is op jouw data, kun je die automatiseren. Als je middelste band pap is, stuur je die naar een mens of geef je die aan een generatief model, en laat je het dure pad de ambiguïteit afhandelen. Die splitsing — goedkoop model op de zelfverzekerde meerderheid, duur model op de onzekere rest — is de eigenlijke architectuur waar Jev voor pleit, en het is de reden dat het model het beste kan worden begrepen als een component in plaats van als een vervanging.

Wat het kost, uitgewerkt

De prijsstelling is eenvoudig genoeg om te doorgronden, wat zeldzaam is. Invoer kost $ 0,042 per miljoen tokens. Uitvoer is gratis. Bij het gedocumenteerde aanvraagbudget van ongeveer 150.000 tekens kost één enkele aanroep van maximale grootte ruim minder dan een cent.

Twee gerapporteerde cijfers geven een idee van de schaal. Een vroege gebruiker voerde ongeveer 5.000 requests uit voor ongeveer $2. De Doom-demonstratie — waarbij Jev een bot aanstuurde met een tekstbeschrijving van de spelstatus in plaats van met ruwe pixels — draaide op ongeveer 10 calls per seconde voor ongeveer $7 per uur. En de 777 beoordelingen van Every over 37 documenten kwamen uit op ongeveer een kwart cent, en dat is het getal dat het interessante gebruiksscenario inzichtelijk maakt: tegen die prijs houdt het controleren van elke afzonderlijke beurt van een agent-loop op een kostenbeslissing te zijn en wordt het de standaard.

Dat is het echte argument voor Jev. Een verificatieronde per beurt – sprak deze toolaanroep de vorige tegen, is deze uitvoer consistent met de door de gebruiker aangegeven intentie, zou dit een waarschuwing moeten opleveren – is technisch altijd mogelijk geweest met een frontier-model en economisch absurd op schaal. Bij $0,042 per miljoen tokens zonder kosten voor uitvoer wordt dezelfde ronde bij elke beurt betaalbaar. De waarde hier is niet dat Jev beter denkt dan een frontier-model, want dat doet het niet. De waarde is dat het goedkoop en snel genoeg denkt om voortdurend geraadpleegd te worden.

Het is de moeite waard dit ronduit te zeggen, want het is de voor de hand liggende volgende vraag: OrcaRouter bedient Jev niet. Het model van TypeSafe is in early access, met een wachtlijst, en hanteert zijn eigen requestvorm, dus iedereen die het test, gaat rechtstreeks via TypeSafe. Waar een routeringslaag wél past, is de andere helft van de workflow. Het patroon waarvoor Jev is ontworpen, bestaat uit twee modellen, niet één — Jev neemt de getypeerde beslissing, en een generatief model behandelt het deel dat proza, code of een uitleg nodig heeft. Die generatieve helft is het deel dat OrcaRouter dekt: 197 modellen bij 15 providers achter één OpenAI-compatibele sleutel, tegen de lijstprijs van de provider, met 0% opslag doorgegeven, zodat een prijsverlaging van een leverancier dezelfde dag dat die ingaat aan onze kant terechtkomt. Beide helften van een Jev-vormige workflow zijn testbaar zonder een tweede contract, en wanneer de beslissingscomponent onbewezen is, is het failover-pad wat voorkomt dat een slecht kalibratieresultaat een productie-incident wordt.

Waar Jev niet past

De beperkingen worden opvallend duidelijk door de leverancier vermeld, waardoor deze sectie gemakkelijk eerlijk te schrijven is. Jev kan geen vrije tekst genereren. Het kan geen code schrijven. Het kan geen gesprek voeren. Het heeft geen chatinterface, geen beeldinvoer, en een contextbudget van ongeveer 32.000 tokens — een orde van grootte minder dan de long-contextmodellen waarmee het qua prijs wordt vergeleken. Keuzevelden zijn beperkt tot 255 opties. En de "geen hallucinatie"-eigenschap, zoals hierboven, gaat over het uitvoerformaat en niet over waarheid.

Het net is een vrij beperkte match. Goed: classificatie en routing op grote schaal, guardrail- en verificatierondes, latency-kritische beslissingen, het parallel scoren van grote documentsets, overal waar het juiste antwoord echt een keuze, een getal op een schaal of een boolean is. Slecht: open-ended generatie van welke aard dan ook, redeneren met lange context, dialoog met meerdere beurten, of elke taak waarvan het juiste antwoord een zin is. Als je probleem niet te herleiden is tot een getypeerde vraag, is Jev geen goedkopere manier om het op te lossen — het is helemaal geen manier om het op te lossen.

Er is ook terechte kritiek op de framing die het waard is om mee te nemen. Jev een frontiermodel noemen leent geloofwaardigheid die het model niet heeft verdiend: het kan niet programmeren, chatten of een zin schrijven, en de vergelijkingsgrafieken leunen op frontiermodellen als baseline, terwijl de nauwkeurigheidskolom een ander verhaal vertelt. De beter verdedigbare bewering, en degene die het bewijs daadwerkelijk ondersteunt, is dat TypeSafe de frontier op het gebied van snelheid en kosten voor gestructureerde beslissingen een heel eind heeft verlegd. Dat is een aanzienlijke prestatie. Het is iets anders dan een model bouwen dat kan wedijveren met GPT-6 Astra of Claude Fable 5.1.

Wat zou deze afbeelding veranderen?

Drie dingen, ruwweg in de volgorde van hoeveel ze zouden uitmaken.

• Een gepubliceerde architectuurpaper of open gewichten. Alles over hoe Jev zijn snelheid bereikt, is momenteel een black box, en de bewering dat parallelle evaluatie het mechanisme is — de analogie die Almeida maakt, is het vervangen van sequentiële berekening zoals transformers recurrente netwerken vervingen — is een bewering en geen aangetoond resultaat. Totdat het ontwerp is gepubliceerd, is de snelheid een feit en de uitleg marketing.

• Een tweede onafhankelijke evaluatie met een grotere steekproef. De tests van Every vormen het sterkste beschikbare bewijs en ze bestrijken 12 passages over de beslissende nauwkeurigheidsvraag. Nog één onafhankelijke run, met een paar honderd gelabelde gevallen, zou beslechten of het missen van één op de zeven defecten ruis was of het werkelijke foutpercentage.

• Een kalibratie-audit op realistische, rommelige input. Alles wat tot nu toe is gepubliceerd, gebruikt schone testomgevingen. De open vraag voor een model waarvan de hele waardepropositie berust op betrouwbare confidence-scores, is wat die scores doen bij de werkelijk dubbelzinnige gevallen — de gevallen waarin een menselijke beoordelaar ook zou aarzelen. Dat is het cijfer dat bepaalt of het veilig is om op Jev te automatiseren, en niemand heeft het gepubliceerd.

Tot dan is de redelijke houding specifiek in plaats van algemeen. Jev is een echt, uitgebracht, ongewoon goedkoop model met een echte structurele voorsprong in de betrouwbaarheid van de output, een nauwkeurigheidsprofiel dat ongeveer in de middenklasse zit, en een calibratieclaim die plausibel is, door de eigen leverancier expliciet wordt aanbevolen voor zelftesten, en onafhankelijk alleen op een kleine steekproef is gevalideerd. Als je workflow een stap bevat die neerkomt op een getypte vraag die vaak genoeg wordt gesteld dat een frontiermodel verspilling zou zijn, is dit een van de goedkoopste manieren om die te stellen — en de confidencewaarde die het retourneert, is het onderdeel dat je moet testen voordat je erop vertrouwt, niet de snelheid.