Jev door TypeSafe AI: Wat is er nieuw, hoe het werkt en alternatieven (2026)
De meeste modelintroducties dit jaar gingen over meer doen. Deze gaat over minder doen, met opzet.
TypeSafe AI heeft een model uitgebracht dat niet chat, niet schrijft en zichzelf niet verklaart. Het beantwoordt vragen met getypeerde waarden en waarschijnlijkheden. Dat is het volledige productoppervlak.
Deze gids behandelt wat het model is en hoe de drie vraagtypen werken. Daarnaast komen de prijzen aan bod, waar het volgens de leverancier minder goed in is, en hoe het zich verhoudt tot het werk dat de meeste teams daadwerkelijk hebben.
Wat er is uitgebracht
Jev is het vlaggenschipmodel van TypeSafe. Volgens de officiële documentatie van de leverancier is het ook "het eerste System One-model."
De positionering begint met een klacht over hoe de rest van de categorie werkt. Grote taalmodellen, zo stelt de documentatie, "zijn ontworpen om tekst te produceren die mensen kunnen lezen." Wanneer je een oordeel nodig hebt dat door je code wordt verwerkt, "creëert dat een mismatch."
De documentatie legt de mismatch haarfijn uit. Je bent "een tekstgeneratiesysteem aan het dwingen om gestructureerde beslissingen uit te voeren, om de resultaten vervolgens weer te parsen naar iets waar je code op kan vertrouwen."
Het aangeboden alternatief elimineert deze omweg. Jev "evalueert getypeerde vragen tegenover een status en retourneert direct gestructureerde resultaten. Geen tekstgeneratie, geen parsing."
De eigen site van het bedrijf plaatst Jev aan het einde van een stamboom. Vroege taalmodellen, daarna vooraf getrainde LLM's, vervolgens RLHF-chatmodellen, daarna RLVR-redeneermodellen. Nu RLCD, wat het uitschrijft als "reinforcement learning voor gekalibreerde beslissingen."
Wat een System One-model is
De naam is geleend, en de documentatie zegt dat ook direct. Deze "is afgeleid van het concept dat Daniel Kahneman populair maakte in zijn boek Thinking, Fast and Slow."
System 1 is snel en intuïtief. System 2 is langzamer en weloverwogen. Hier "liegt de nadruk op snelle, gerichte oordelen."
De functionele definitie is nauwer dan de metafoor. Dit is "een klasse van AI-modellen die is gebouwd om snelle, gestructureerde beslissingen te nemen die software direct kan gebruiken." Een dergelijk model "evalueert een status en retourneert getypeerde antwoorden en waarschijnlijkheden."
Eén regel onderscheidt Jev van al het andere op de markt. "Net als een LLM begrijpt een System One-model invoer in natuurlijke taal. Het retourneert getypeerde beslissingen en waarschijnlijkheden in plaats van gegenereerde tekst."
Wat het model niet doet, wordt ook duidelijk door de leverancier vermeld. System One-modellen "schrijven geen antwoorden, produceren geen code en genereren geen verklaringen voor hun redenering."
De drie vraagtypen
Je prompt Jev niet. Je definieert een antwoordruimte, en het model kiest daarbinnen.
Er zijn drie primitieven. De documentatie geeft van elk een voorbeeld.
| Primitief | Vraag | Antwoordruimte | Output |
|---|---|---|---|
| Choice | Welk team moet dit ticket afhandelen? | billing, technical of account | choice: "billing" |
| Score | Hoe gefrustreerd is deze klant? | 0 = rustig, 1 = gefrustreerd, 2 = zeer gefrustreerd | score: 1.4 |
| Noul | Vraagt dit bericht om een terugbetaling? | Waar of onwaar | noul: 0.95 |
Choice selecteert één optie uit een gedefinieerde set. Score beoordeelt tegen geordende, beschrijvende niveaus. Noul retourneert de waarschijnlijkheid dat een ja/nee-vraag waar is.
Het voorbeeld van Score verdient een tweede blik. Het antwoord is 1.4, niet 1. Jev plaatst de situatie tussen twee benoemde niveaus in plaats van naar de dichtstbijzijnde te springen. Dat is een heel andere outputvorm dan wat een tekstmodel retourneert.
Wat het kost en wat het accepteert
De tarievenpagina is ongebruikelijk duidelijk. Dat is niet iets wat je vaak schrijft over de lancering van een model.
Het huidige model is jev-1.13.0. De prijs is $42 per miljard tokens, of $0.042 per miljoen. De documentatie is er expliciet over dat de kosten "per invoertoken" zijn en dat "uitvoertokens gratis zijn."
De rate limits zijn vastgesteld op 250.000 tokens per seconde en 1.200 verzoeken per minuut. De contextlengte is 64k tokens per verzoek. Daarvan is 32k beschikbaar voor de status plus de langste vraag.
Invoer bestaat uitsluitend uit tekst. De documentatie merkt op dat Jev "strings, JSON-objecten en arrays van tekst evalueert." Er wordt aan toegevoegd dat "afbeeldingen, audio en video (nog) niet worden ondersteund."
Alles loopt via een enkel eindpunt, POST /v1/systemone. Een model-veld selecteert welk model de aanroep afhandelt.
| Eigenschap | Waarde |
|---|---|
| Model | jev-1.13.0 |
| Prijs | $42 per miljard tok / $0.042 per miljoen tok, alleen invoer |
| Uitvoertokens | Gratis |
| Rate limits | 250.000 tokens per seconde; 1.200 verzoeken per minuut |
| Context | 64k per verzoek; 32k voor status plus langste vraag |
| Invoertypen | Alleen tekst |
Betrouwbaarheid is het deel om op te letten
De prijsstelling is het nieuws, maar de manier waarop met betrouwbaarheid wordt omgegaan, is de interessantere ontwerpbeslissing.
Elk Choice- en Score-antwoord bevat een probabilities-eigenschap voor de verschillende opties of niveaus. De documentatie legt uit hoe je dit moet interpreteren. Een verdeling die "geconcentreerd is op één uitkomst betekent een betrouwbaar antwoord, een verspreide verdeling betekent een onzeker antwoord."
Een aparte confidence-eigenschap brengt die vorm terug tot een enkel getal van 0 to 1. Het gedocumenteerde doel hiervan is "zodat je er een drempelwaarde op kunt toepassen zonder zelf de berekening te hoeven maken."
De gedachte achter het leveren van dat getal wordt als een principe geformuleerd. "Als een intelligent systeem, of het nu mens of machine is, geen eerlijke onzekerheid kan uiten, kan het systeem niet worden vertrouwd."
Wat dit je oplevert, is eerder een routeringsregel dan een beter antwoord. Hoge betrouwbaarheid gaat direct door. Lage betrouwbaarheid gaat naar een mens. De documentatie formuleert het als beslissen "wanneer te handelen en wanneer te escaleren naar een persoon of een redeneermodel."
Iedereen die weleens een classificatie-pipeline in productie heeft genomen, begrijpt waarom dat belangrijk is. Het escalatiepad, en niet het nauwkeurigheidspercentage, bepaalt of het systeem standhoudt bij contact met echte data.
Waar de leverancier zegt dat het minder goed in is
TypeSafe publiceert een pagina genaamd 'model jaggedness', herzien op 17-09-2026. Hierop staan de foutmodi vermeld die bekend zijn bij het bedrijf. Het publiceren hiervan bij een lancering is zeldzaam, en het bespaart iedereen een hoop giswerk.
De samenvatting is openhartig. Jev 1.13 "is snel, gekalibreerd en goed in oordelen op basis van gezond verstand, maar het is niet perfect."
Er worden direct drie zwakke punten genoemd. Het "kan moeite hebben met taken die extra niveaus van indirectheid vereisen." Het "kan vrij letterlijk zijn in zijn begrip." En het "heeft moeite met taken die numerieke precisie vereisen."
De tabel met foutmodi koppelt elke fout aan een oplossing. Twee daarvan zijn het herhalen waard voor iedereen die een pilot overweegt.
- Voor wiskunde en getallen is het gedocumenteerde advies om "de berekeningen in de code te houden."
- Voor een grote status vol irrelevante details is het advies om "eerst te filteren; stuur alleen wat nodig is voor de vraag."
Beide wijzen op dezelfde ontwerpaanname. Dit is een beoordelingsengine, geen rekenmachine en geen zoekindex. Het werkt het beste wanneer het omringende systeem de vraag al heeft afgebakend.
Hoe dit zich verhoudt tot het werk dat je al hebt liggen
Er schuilt een duidelijke taakverdeling in het eigen voorbeeld van de leverancier. Het benoemen daarvan bepaalt of deze lancering überhaupt relevant voor je is.
De gedocumenteerde workflow voor terugbetalingen bouwt een status op en stelt verschillende onafhankelijke vragen tegelijk. Vervolgens combineert het de antwoorden "met deterministische controles in de code" en stuurt het de case door "voor actie of beoordeling."
Elke stap daarin veronderstelt een ontwikkelaar, een applicatie en een hoog volume aan verzoeken. De kosten per token moeten echt een serieuze kostenpost zijn voordat dit zichzelf terugverdient.
De meeste rapportagewerkzaamheden hebben een andere vorm. Je hebt een bestand in plaats van een stroom aan verzoeken. De oordelen zijn een middel en niet het product. Wat er aan het einde moet liggen, is een document dat door iemand wordt gelezen.
Het classificeren van vienduizend rijen aan klantfeedback is het middendeel van die taak. Het einde is een samenvatting waarin de drie thema's worden genoemd en de uitzonderingen worden gemarkeerd.
Die tweede helft is precies wat een bestand-eerst-werkruimte afhandelt. Je uploadt de export en beschrijft de categorieën in natuurlijke taal. De rijen komen gelabeld terug, en het rapport dat ze verklaart, wordt in dezelfde stap geleverd. Powerdrill Bloom werkt op deze manier, en het gratis pakket dekt al basispresentaties, documenten, spreadsheets en afbeeldingen.
De twee concurreren niet om dezelfde plek. De ene is een API die je in een product integreert. De andere is waar een spreadsheet naartoe gaat wanneer iemand uiterlijk donderdag een antwoord nodig heeft. Als jouw versie van dit probleem als een bestand binnenkomt, probeer dan Powerdrill Bloom.
Voor de spreadsheet-variant van de labeltaak is er een handleiding over het categoriseren van Excel-data. Voor de variant waarbij thema's moeten worden gezocht, is er een overzicht van tools voor de analyse van klantfeedback.
Alternatieven die het vergelijken waard zijn
Drie benaderingen bestrijken hetzelfde gebied. Welke de juiste is, hangt voornamelijk af van het volume.
Modellen voor algemeen gebruik met gestructureerde output. Elke grote aanbieder beperkt antwoorden inmiddels tot een schema. Je krijgt één model voor zowel beoordelen als genereren. Het nadeel is dat je generatieprijzen betaalt voor beoordelingswerk, en dat je zelf de kalibratie moet doen.
Klassieke classifiers. Een gefinetuned klein model of een gradient-boosted tree is nog goedkoper en volledig voorspelbaar. Dat geldt mits je over gelabelde data en een stabiele set labels beschikt. Zo'n model begrijpt echter geen beleid dat in proza is geschreven.
Bestand-eerst-analysewerkruimtes. Deze behandelen beoordeling als één stap binnen het produceren van een eindproduct. Geen API, geen schema, geen budgettering per token. Maar ook geen mogelijkheid om deel uit te maken van een verzoekpad.
| Als je situatie is | Kijk dan naar |
|---|---|
| Miljoenen oordelen binnen een product | Een model dat alleen beslissingen neemt |
| Gemengd beoordelen en opstellen, laag volume | Een algemeen model met gestructureerde output |
| Stabiele labels en voldoende trainingsdata | Een klassieke classifier |
| Een bestand dat een rapport moet worden | Een bestand-eerst-werkruimte |
Er is een gerelateerd overzicht van tools voor het genereren van rapporten dat die laatste categorie behandelt.
Voor wie dit nu interessant is
Teams die grote volumes aan oordelen binnen een product verwerken, hebben de duidelijkste use-case voor Jev. Ticketroutering, moderatiewachtrijen, leadkwalificatie en voorafgaande controles op geschiktheid passen hier allemaal bij. Het patroon is een specifieke vraag die duizenden keren per dag wordt gesteld en een vertakking in de code aanstuurt.
Teams die af en toe classificaties uitvoeren als onderdeel van een analyse, hebben de minst sterke use-case. De economische voordelen die Jev op grote schaal aantrekkelijk maken, zijn onzichtbaar bij een paar duizend rijen. Bovendien heb je daarna nog steeds iets nodig om de samenvatting te schrijven.
Iedereen die hierbuiten valt, kan beter de terminologie overnemen dan de tool zelf te implementeren. Het scheiden van snelle oordelen en langzame synthese is een nuttige manier om naar je eigen pipeline te kijken. Dat blijft nuttig, of je nu wel of niet ooit een verzoek naar deze API stuurt.
Nog een praktische opmerking voor iedereen die een evaluatie uitvoert: lees de pagina over 'jaggedness' (onregelmatigheid) vóór de tarievenpagina. Weten waar een model zwak is, geeft veel meer richting aan de pilot dan weten wat het kost.
Veelgestelde vragen
Wat is een System One-model?
Het is een klasse van modellen die is gebouwd om snelle, gestructureerde beslissingen te nemen die software direct kan gebruiken. Het evalueert een status en retourneert getypeerde antwoorden en waarschijnlijkheden. De naam verwijst naar Kahnemans System 1, de snelle en intuïtieve manier van denken. In tegenstelling tot een chatmodel schrijft het geen antwoorden, produceert het geen code en legt het zijn redenering niet uit.
Hoeveel kost Jev?
De gepubliceerde prijs voor jev-1.13.0 is $42 per miljard tokens, of $0.042 per miljoen. Er worden alleen kosten in rekening gebracht voor invoertokens; uitvoertokens zijn gratis.
Wat kan Jev als invoer aannemen?
Alleen tekst, in de vorm van strings, JSON-objecten of arrays van tekst. De documentatie vermeldt dat afbeeldingen, audio en video nog niet worden ondersteund. De context is 64k tokens per verzoek, waarvan 32k voor de status plus de langste vraag.
Hoe verschilt dit van een LLM om JSON vragen?
Beide begrijpen invoer in natuurlijke taal. Het verschil zit in wat er terugkomt en hoe het model is getraind. Jev retourneert getypeerde beslissingen met een waarschijnlijkheidsverdeling en een betrouwbaarheidswaarde. Kalibratie wordt gemeten over groepen voorspellingen, dus het garandeert niet dat elk individueel antwoord correct is.
Waar is Jev niet goed in?
De 'jaggedness'-pagina van de leverancier vermeldt letterlijk lezen, wiskunde en getallen, en het vergelijken van datums en tijden. Ook worden indirectheid, grote statussen vol irrelevante details, vijandige inhoud (adversarial content) en tegenstrijdige criteria genoemd. Het gedocumenteerde advies voor rekenkundige taken is om de berekeningen in de code te houden.
Bronnen: TypeSafe AI-documentatie — Introduction, System One, Models, Confidence en Jev 1.13 jaggedness, docs.typesafe.ai, stand van zaken op 18 september 2026.