Jev: Wat het is en waarom het belangrijk is

Jev is een AI-model van TypeSafe AI dat besluiten neemt in plaats van tekst genereert. Het is het eerste publieke System One-model: je stuurt het een state en een set getypeerde vragen, en je krijgt keuzes, scores en kansen terug waar je code direct op kan handelen. Daarmee is het bruikbaar als een snelle, goedkope beslislaag binnen AI-agents en andere geautomatiseerde software.

Drie dingen zijn het belangrijkst:

• Jev is geen goedkopere LLM. Het is een andere vorm van output: begrensde, getypeerde antwoorden met kansen die TypeSafe gekalibreerd noemt, en geen enkel vermogen om tekst te schrijven.
• Waar het echt om draait, is het confidence-getal. Daarmee bepaalt je code wanneer het systeem zelf mag handelen en wanneer het doorzet naar een mens. Dat is precies het besluit dat nu in de meeste agentarchitecturen in een prompt verstopt zit.
• De claims zijn groot en het bewijs komt van TypeSafe zelf. Er zijn geen publieke benchmarkscores, bewust niet, dus elk team dat dit serieus overweegt moet zelf een evaluatie draaien.

Wat is Jev?

Jev is het eerste publieke System One-model van TypeSafe AI, uitgebracht op 15 september 2026 na twee jaar in stealth. TypeSafe omschrijft de categorie op de eigen homepage als “a new class of AI model built for decisions inside software”. De naam is ontleend aan het onderscheid van Daniel Kahneman tussen snel, intuïtief Systeem 1-denken en traag, bewust Systeem 2-redeneren. Het model zelf is vernoemd naar William Stanley Jevons, van de paradox dat de vraag stijgt zodra iets efficiënter en dus goedkoper wordt.

De praktische definitie is eenvoudiger. Jev geeft besluiten terug in plaats van strings. Je geeft het een state, bijvoorbeeld een supportbericht, een JSON-object of een lijst records, plus een set vragen die je vooraf hebt getypeerd. Het beantwoordt elke vraag binnen de antwoordruimte die jij hebt vastgelegd, en hangt er een kansverdeling en een confidence-score aan. Oprichter Diogo Almeida omschrijft het model in de aankondiging als “a frontier-intelligence function call: unstructured state in, typed probabilistic decisions out”.

TypeSafe moest een nieuwe stack bouwen om die vorm van output te krijgen. Het bedrijf zegt een nieuwe modelarchitectuur te hebben gebouwd, een parallelle sampler en een trainingsmethode die het Reinforcement Learning for Calibrated Decisions noemt, kortweg RLCD. RLCD vervangt de RLHF waarmee de bekende chatmodellen zijn gevormd.

Waarin verschilt Jev van een LLM?

Jev verschilt van een LLM in de taak, niet in de omvang. Een LLM genereert een reeks tokens en jij parst het resultaat. Jev kiest uit opties die jij hebt aangeleverd en geeft je de kansen achter die keuze. TypeSafe zegt het zelf net zo kort op de vraag of Jev een klein taalmodel is: “Jev is neither small nor an LLM”.

	Jev	Klassieke LLM
Hoofdtaak	Beslissen	Genereren
Output	Getypeerde keuzes, scores en kansen	Tekst en tokens
Vrij schrijven	Nee	Ja
Routing en classificatie	Kerntoepassing	Mogelijk, met parsen
Structuur van de output	Vooraf begrensd	Tijdens de aanroep gegenereerd
Beste rol	Beslislaag	Redeneer- en generatielaag

Lees die tabel als Jev plus een LLM, niet als Jev tegen een LLM. TypeSafe claimt nergens dat het model een chatmodel vervangt, en de architectuur die het beschrijft gaat ervan uit dat beide aanwezig zijn. De interessante vraag voor een team is dus niet welke van de twee wint. De vraag is welke van je huidige aanroepen eigenlijk besluiten zijn in de vorm van een zin.

Hier zit ook het verschil met JSON mode en structured outputs, de vergelijking waar de meeste engineers als eerste naar grijpen. Het antwoord van TypeSafe is dat geldige JSON alleen het formaat oplost: “forcing an LLM into that format can leave some of its intelligence on the table”. TypeSafe traint een System One-model vanaf het begin op het gestructureerde besluit, dus het model levert de kansen zelf in plaats van dat een prompt erom moet vragen.

Hoe werkt Jev?

Een Jev-aanroep bestaat uit twee delen: een state en een set vragen. De state is wat je wilt laten beoordelen en mag een string, een JSON-object of een array met tekstwaarden zijn. Jev verwerkt voorlopig alleen tekst, dus beeld, audio en video moet je eerst omzetten. Je typeert de vragen, en Jev beoordeelt ze parallel en geïsoleerd tegen diezelfde state. Een extra vraag kost daardoor nauwelijks tijd.

Er zijn drie vraagtypen, en daarmee bouw je alles wat Jev aankan:

• Choice beantwoordt “welke van deze opties?” en geeft de gekozen optie, de kansen en een confidence-score terug. Gebruik het om een ticket naar een afdeling te routeren of een document te classificeren. Er passen maximaal 255 opties in.
• Score beoordeelt de state tegen een geordende schaal van twee tot tien niveaus en beantwoordt daarmee “welk niveau?”. Je krijgt het niveau, het bijbehorende label, de kansen en een confidence-score terug. Gebruik het voor de ernst van een bug of de frustratie van een klant.
• Noul beantwoordt “is dit waar?” en geeft één waarde tussen 0 en 1 terug. Gebruik het als de kans zelf het signaal is.

Het confidence-getal komt uit de vorm van de kansverdeling, niet uit het oordeel van het model over zichzelf. Een verdeling die op één uitkomst geconcentreerd is, is een zeker antwoord; een vlakke verdeling niet. Bij drie opties neem je de grootste kans, vermenigvuldig je die met 3, trek je er 1 van af en deel je door 2. De onderbouwing van TypeSafe om dit überhaupt mee te leveren is het citeren waard: “If an intelligent system, whether human or machine, cannot express honest uncertainty, the system cannot be trusted.”

Zo ziet dat eruit op een taak die elk supportteam herkent. Het voorbeeld hieronder is samengesteld, gebaseerd op het soort triagewerk dat we bij meerdere klanten zien en niet op één klant.

Er komt een klantbericht binnen bij een agent. In één aanroep bepaalt Jev welk team het bericht moet krijgen (Choice), scoort het hoe urgent het is (Score) en beantwoordt het of er een mens naar moet kijken voordat er iets uitgaat (Noul). Je code leest de drie antwoorden en de confidence per antwoord, en pas daarna schrijft een LLM het antwoord. De besluiten komen van een model dat geen vierde team kan verzinnen. Het schrijfwerk komt van een model dat echt kan schrijven.

Één ontwerpregel loopt door de hele documentatie heen, en teams overtreden hem makkelijk. Elke vraag moet volgens TypeSafe “a gut-check determination” zijn: “the kind of judgment a highly knowledgeable person could make in a few seconds”. Heeft de vraag een redeneerketen nodig, dan splits je hem op in meerdere vragen en combineer je de antwoorden in code.

Waar past Jev binnen een AI-agent?

In een agent hoort Jev op elke plek waar het systeem nu een taalmodel iets vraagt waar geen tekst voor nodig is. Die plekken zijn heel alledaags, en de agentframeworks hebben ze al benoemd. De middleware-documentatie van LangChain beschrijft hooks die voor en na elke stap in de agentloop draaien. Er zitten ingebouwde varianten in voor tool selection, guardrails, PII-detectie en menselijke tussenkomst. Dat zijn stuk voor stuk begrensde besluiten.

Zes patronen zeggen meer dan een lange lijst mogelijkheden:

• Model routing. Classificeer intentie en moeilijkheid in één aanroep en stuur het makkelijke verkeer naar een klein model en het moeilijke naar een frontier-model. Het intent routing-patroon van TypeSafe vat het zo samen: “the expensive resources only get invoked for the requests that actually need them”. Dat is dezelfde logica als achter een AI gateway.
• Tool selection. Kiezen uit een vaste set tools is een Choice-vraag met een confidence-score, geen alinea redenering gevolgd door een parse.
• Guardrails. Het guardrails-cookbook van TypeSafe screent elk bericht met een reeks Noul-vragen plus een Score voor mogelijke schade, en routeert het resultaat naar doorlaten, beoordelen, blokkeren of crisishulp. In het uitgewerkte voorbeeld scoorde een jailbreak die zich voordeed als een verzoek om medische aanpassing 0,74 op jailbreakdetectie en werd hij geblokkeerd. Dat is een goedkopere vorm van de AI-guardrails die de meeste teams al draaien.
• RAG-evaluatie. In het cookbook over passageclassificatie beoordeelde Jev 72 opgehaalde passages over zes queries op relevantie, bruikbaarheid, tegenspraak en injectiepogingen voordat er iets in de prompt belandde. Een vooraf ingebouwde prompt injection kwam qua cosine similarity als eerste bovendrijven, maar scoorde 0,99 op injectiedetectie. Die passage kwam dus nooit in de context terecht.
• Ticket triage. Jev bepaalt categorie, urgentie, reproduceerbaarheid en frustratie in één request. De routeringslogica houd je in je eigen code, niet in een system prompt.
• Doorzetten naar een mens. Het confidence-gated routing-patroon zet per risico een andere drempel. Boven 0,85 handelt het systeem zelf, tussen 0,6 en 0,85 vraagt het de gebruiker om bevestiging, en onder 0,6 gaat het naar een mens. Voor alles wat destructief is ligt de grens op 0,9. Zoals de documentatie het zegt: “the answer tells you what; confidence tells you whether to act”.

Wie onze gids over harness engineering heeft gelezen, herkent dit. Betrouwbaarheid komt uit de scaffolding om het model heen, en een beslislaag is scaffolding die je kunt testen.

Voor Nederlandse organisaties zit er nog een kant aan. Artikel 14 van de AI Act vraagt dat hoogrisicosystemen zo worden ontworpen dat mensen er effectief toezicht op kunnen houden, en onze EU AI Act-checklist loopt de rest van de verplichtingen langs. Een expliciete confidence-drempel in code is makkelijker aan een toezichthouder uit te leggen dan een zin in een system prompt, omdat je kunt laten zien wanneer het systeem zelf handelde en wanneer het doorzette. Dat maakt de drempel geen compliancebewijs, maar het scheelt in de onderbouwing.

Wat laten de snelheid, de prijs en de benchmarks van Jev zien?

De snelheidscijfers en de prijs laten een sterk verhaal van de leverancier zien, publieke benchmarkcijfers zijn er helemaal niet, en onafhankelijk bewijs ontbreekt nog. Dat is geen verwijt. Het product is één week oud. Toch moet je het leveranciersverhaal en het bewijs scheiden voordat iemand er een businesscase op bouwt.

Onderdeel	Gepubliceerd cijfer van TypeSafe	Hoe hard het is
Inputprijs	42 dollar per miljard tokens, oftewel 0,042 dollar per miljoen	Gepubliceerde lijstprijs, na te rekenen op je eigen factuur
Outputprijs	Gratis	Gepubliceerde lijstprijs
Responstijd end-to-end	70 ms tot 500 ms	Cijfer van de leverancier uit de aankondiging; TypeSafe meldt dat de evals doorgaans vanaf de eigen laptops aan de Amerikaanse westkust draaien
Snelheid versus frontier-LLM’s	40 tot 200 keer sneller op System One-achtige queries	Meting van de leverancier
Uitgelichte claim	193,6x sneller, 444,6x goedkoper	Eigen workflow-evals; TypeSafe noemt dit zelf “on the higher end of real world gains”
Contextvenster	64k tokens per request, 32k voor state plus de langste vraag	Gedocumenteerde limiet
Doorvoer	250.000 tokens per seconde, 1.200 requests per minuut	Gedocumenteerde limiet, dynamisch bijgesteld
Publieke benchmarkscores	Geen	Bewuste keuze: TypeSafe publiceert geen resultaten op publieke benchmarks

De prijs is het makkelijkst te controleren. Bij 0,042 dollar per miljoen inputtokens en gratis output kost een routingaanroep hier vrijwel niets, terwijl dezelfde aanroep op een frontier-model echt geld kost. Ons artikel over tokens en kosten legt uit waarom die verhouding meer uitmaakt dan het tarief zelf. De homepage van TypeSafe claimt dat de eigen prijs 238 keer lager ligt dan die van één genoemd frontier-model, wat een vergelijkingsprijs van ongeveer 10 dollar per miljoen impliceert. De aankondiging zet de inputprijs van bestaande LLM’s op 0,20 tot 10 dollar per miljoen, dus die impliciete vergelijkingsprijs ligt aan de bovenkant van hun eigen bandbreedte. De vergelijkingsprijs zelf hebben we niet onafhankelijk kunnen verifiëren.

De snelheidsclaims vragen meer voorzichtigheid. De vergelijkingsdemo op de homepage laat een Jev-aanroep zien die in 0,114 seconde klaar is voor 0,000081 dollar, tegenover 8,566 seconde en 0,013880 dollar voor een LLM die hetzelfde doet. Dat is 75 keer sneller en 171 keer goedkoper, wat indrukwekkend is en niet de bron van de cijfers in de kop. Die komen uit een aparte reeks workflow-evals. TypeSafe benoemt de kanttekeningen zelf. Het eigen model capabilities-team maakte de workflows. De referentieantwoorden zijn het gemiddelde van GPT-6 Astra en Fable 5.1, en de concurrerende LLM’s lopen via een wrapper van TypeSafe.

De benchmarkvraag krijgt een ongebruikelijk antwoord. TypeSafe publiceert niets: “We deliberately chose not to publish performance against public benchmarks.” Het standpunt is dat teams geen gewicht aan publieke benchmarks moeten hangen en beter zelf een evaluatie kunnen bouwen, omdat System One-taken makkelijker te evalueren zijn dan vrije generatie. Daar zijn we het mee eens, en precies dat schrijven we zelf in LLM’s evalueren op meer dan de benchmarks. Het betekent ook dat niemand buiten TypeSafe je nu kan vertellen hoe nauwkeurig Jev op jouw werk is.

Één ding hebben we niet gedaan: we hebben Jev nog niet op een klantworkload gedraaid. We zouden beginnen met een routingtaak met een bekende antwoordset, daar duizend echte berichten doorheen sturen en vier dingen meten. De eerste meting is latency op het 95e percentiel, niet het gemiddelde. De tweede is de kostprijs per duizend besluiten, afgezet tegen het huidige model. De derde is de mate waarin Jev het eens is met de bestaande oplossing, met een menselijke blik op elke afwijking. De vierde weegt het zwaarst en dat is kalibratie. Als Jev 0,9 confidence teruggeeft, heeft het dan negen van de tien keer gelijk? Een model waarvan de confidence eerlijk is, is meer waard dan een model dat iets nauwkeuriger is en niet weet wanneer het gokt.

Waar vervangt Jev een LLM niet?

Jev kan niet schrijven, en TypeSafe doet ook niet alsof. De pagina met zwakke plekken van versie 1.13 is duidelijk: het model “is not trained to generate text”. Het schrijft geen antwoord, legt zijn redenering niet uit in tekst, produceert geen code en kan niets met echt open output. Dat blijft het werk van het taalmodel.

De gedocumenteerde zwakke plekken zijn het lezen waard voordat je eromheen ontwerpt. Jev “is not a calculator”. Laat het model dus niet tellen of rekenen. Over datums zegt TypeSafe: het model “reads dates as text, not as ordered quantities”. Twee datums vergelijken hoort dus in code. De nauwkeurigheid daalt naarmate de state voller raakt met inhoud die niets met het besluit te maken heeft, dus filteren vóór de aanroep loont. Redeneren in meerdere stappen gaat slechter, en dubbele ontkenningen ook. En het model behandelt data niet standaard als vijandig, dus voor adversarial content heb je expliciete criteria en tests nodig.

De belangrijkste kanttekening is degene waar de marketing niet mee opent. De homepage van TypeSafe zegt “Zero Hallucinations”, en de eigen FAQ legt precies uit wat dat betekent: “Jev guarantees the shape of its answers, not that every decision is correct. If you provide a list of categories, it can’t invent a category outside that list, but it can choose the wrong one.” Begrensde output haalt een hele klasse parsefouten weg. Het haalt niet de noodzaak weg om te controleren of het besluit klopte. TypeSafe is ook eerlijk over de eigen grafiek: de 0 procent die het voor hallucinatie invult “is not empirical”, omdat schema matching gegarandeerd is en niet gemeten.

Nog iets om te weten voordat je tests schrijft: Jev is niet deterministisch. TypeSafe betoogt dat consistentie meer waard is dan determinisme. Het definieert consistentie als vergelijkbare besluiten nemen zolang de betekenis vergelijkbaar blijft, ook als de formulering verandert, en zegt dat Jev daarop ontworpen is.

Moeten AI-teams aandacht besteden aan Jev?

Ja, AI-teams moeten Jev volgen, maar meer om het idee erachter dan om het product zelf. Jev is één week oud en al het bewijs komt van de leverancier. Een verstandig team draait dus eerst een kleine evaluatie voordat het er iets aan toevertrouwt. Dat is allemaal geen reden om het achterliggende argument te negeren.

Dat argument luidt dat genereren en beslissen verschillende taken zijn, en dat één algemeen model allebei laten doen vooral gemak was en geen ontwerpkeuze. Drie jaar lang was het standaardantwoord op “hoe moet mijn software dit beslissen?” om een prompt te schrijven en het resultaat te parsen. Er bestaat nu een modelklasse die het besluit neemt, zijn eigen onzekerheid uitspreekt en bijna niets kost. Dat verandert de vorm van een verstandige AI-architectuur: een LLM om te redeneren en te schrijven, een beslislaag om te vertakken, en gewone code die de twee bij elkaar houdt.

Of TypeSafe het bedrijf is dat die categorie wint, is een andere en nog open vraag. Het idee is groter dan het model. Teams die nu al beginnen met het scheiden van die twee soorten aanroepen staan er beter voor, welke leverancier de beslislaag uiteindelijk ook levert.

Onze AI-consultants brengen in kaart welke besluiten in je stack geen gegenereerde tekst nodig hebben. In dezelfde sessie zetten ze op een rij wat een eerlijke evaluatie van een beslismodel zou moeten meten.

Veelgestelde vragen (FAQ) over Jev

Jev kwam uit op 15 september 2026 en staat op versie 1.13, dus de cijfers in dit artikel zijn vroeg en het loont om ze te controleren voordat je ze citeert.