Wat is TypeSafe AI? Het lab achter Jev 1.13 neemt beslissingen, geen zinnen

TypeSafe AI is een klein lab in San Francisco dat een model verkoopt dat geen zin kan schrijven, en Jev 1.13 (typesafe/jev-1.13) is het model in kwestie. Het neemt een stuk state — een e-mail, een logregel, een supportticket, een JSON-blob — plus een reeks benoemde vragen, en retourneert één getypeerd antwoord per vraag, elk met een eigen confidencewaarde. Geen proza, geen code, geen uitleg en geen chatbox. Het model zelf is gelanceerd op 2026-09-15, dus het is niet nieuw en niets hier is een lanceringsverhaal: deze pagina bestaat vanwege een kleinere, dateerbare verandering. Op 2026-09-24 voegde OrcaRouter typesafe/jev-1.13 toe aan zijn catalogus en opende de modelkaart op zijn eigen adres, wat de eerste keer was dat Jev kon worden aangeroepen via een gateway van een derde partij in plaats van alleen via het eigen endpoint van TypeSafe. Dat is de gebeurtenis; die is zes dagen oud op 2026-09-30, en het is de reden dat een lezer die nog geen TypeSafe-contract heeft nu een System One-model op dezelfde sleutel kan zetten als de generatieve modellen waarnaast het is ontworpen om te staan. Al het andere op deze pagina is achtergrondinformatie over het bedrijf dat het heeft gemaakt.

De eerlijke framing van de timing, want die is van belang voor hoeveel hiervan geverifieerd is: Jev is meer dan twee weken geleden gelanceerd en is algemeen beschikbaar sinds 2026-09-21, toen TypeSafe zijn wachtlijst opheffte. Wat binnen het venster van zeven dagen valt, is de routeringswijziging, niet het model. Als je hierheen kwam in de verwachting een launchreview te lezen: de lancering heeft al plaatsgevonden en een handvol andere artikelen hebben er aandacht aan besteed.

Een bedrijfspagina met een manifest en geen architectuurdiagram.

TypeSafe beschrijft zichzelf, in zijn eigen metabeschrijving, als 'een AI-lab dat machine-native intelligentie-infrastructuur voor automatisering bouwt', met systemen die 'ontworpen zijn om beslissingen binnen software te nemen'. De homepage draagt het stempel Version 0.01 en onderaan staat 'Made in SF.' Er is een manifest dat betoogt dat de kortste weg naar een door AI gevormde economische verschuiving loopt via het composeerbaar maken van intelligentie, zodat software semantisch oordeel kan aanroepen zoals ze een functie aanroept; de eigen samenvatting van het plan door het bedrijf is om de vorm van machine-native composeerbare AI uit te brengen, die vervolgens betrouwbaar genoeg te maken voor echte automatisering, en dan abstracties op hoger niveau aan te bieden die stabiel genoeg zijn om op voort te bouwen. De tagline is 'We bouwen prod, niet God.' De teampagina noemt drie oprichters — Diogo Almeida als CEO, Sasha Sheng als COO en Erik Gafni als CTO. Dat is alles wat het bedrijf over zichzelf zegt: een standpunt, een product, drie namen, en geen cijfers over het bedrijf zelf.

Wat de site niet bevat, is precies het eerste waarnaar een ingenieur die een nieuwe dependency beoordeelt, grijpt. Er is geen architectuurpagina, geen parameteraantal, geen openbaarmaking van trainingscompute en geen modelkaart in academische zin. TypeSafe's eigen benchmarkdashboard staat nog steeds gemarkeerd als in behandeling. Voor een bedrijf waarvan de pitch op betrouwbaarheid rust, is het openbaarmakingsoppervlak dun, en dat is een feit over wat is gepubliceerd, niet een beschuldiging over wat wordt verborgen.

System One: de categorie, en waarom de naam is ontleend

Jev is de eerste van wat TypeSafe System One-modellen noemt. De naam komt van Daniel Kahnemans onderscheid tussen het snelle, intuïtieve Systeem 1-denken en de langzame, weloverwogen Systeem 2-redenering, en de lanceringstekst van het bedrijf zegt dat direct — hij geeft ook toe dat "Systeem 1-denken" een bijklank van foutgevoeligheid heeft gehad, en betoogt dat deze modellen betrouwbaarder kunnen worden gemaakt dan de alternatieven. TypeSafe heeft de term niet bedacht en is er niet de eigenaar van.

De praktische inhoud van de categorie is een bewuste taakverdeling: een model dat beslist en een model dat schrijft. Het is de bedoeling dat je rekenwerk, datumordening, tellen en tekenreeksvergelijking in gewone code houdt, waar die exact zijn, en het semantische oordeel aan Jev overlaat. Het kan drie soorten vragen beantwoorden:

• noul — een waar/onwaar-oordeel, teruggegeven met een gekalibreerde waarschijnlijkheid

• keuze — kies een van maximaal 255 gelabelde opties

• score — beoordeel op een geordende schaal; onze kaart publiceert 2-10 niveaus, en TypeSafe's eigen documentatie toont een 0-geïndexeerd voorbeeld, dus beschouw de niveaus van de leverancier als de definitie en de 2-10 als wat de kaart publiceert

Elke vraag heeft zijn eigen instructies en, voor keuze en score, zijn eigen criteria. Verzoeken van meer dan ongeveer 64K invoertokens worden afgewezen voordat ze het model bereiken, en antwoorden worden niet gestreamd. De leverancier documenteert het state-budget afzonderlijk — state plus de enkele langste vraag — op 32K tokens, wat een kleiner cijfer is dan de context van 65.536 tokens op de kaart en geen tegenspraak daarmee vormt.

Hun these, in hun eigen woorden.

TypeSafe verwoordt de these beter dan welke samenvatting dan ook, dus hier is die letterlijk: "LLM's produceren woorden voor mensen. Jev produceert getypeerde beslissingen en lijkt meer op code: betrouwbaar, snel, zelfconsistent en typeveilig." De trainingsmethode daarachter is ook van hen, en het is een term die het waard is om nauwkeurig toe te schrijven, juist omdat hij elders is overgenomen alsof het een generieke term was. TypeSafe noemt het Reinforcement Learning for Calibrated Decisions, oftewel RLCD, en zet het tegenover RLHF en RLVR: waar die menselijke voorkeur of programmatisch verifieerbare beloningen optimaliseren, richt RLCD zich, in de bewoordingen van het bedrijf, op "antwoorden met epistemisch eerlijke waarschijnlijkheden op System One-taken." Beschouw RLCD als een eigen term van TypeSafe, niet als een gevestigde afkorting in de literatuur.

De cijfers waarmee ze openen, en wie de werkbelasting heeft gekozen

De homepage opent met "193,6x sneller, 444,6x goedkoper", met een voetnoot die verwijst naar workflows voor System One-taken. Daaronder staat een uitgewerkt voorbeeld: TypeSafe AI met $0,000081 en 0,114 seconden tegenover LLM's met $0,013880 en 8,566 seconden. Verder naar beneden: "$42 per miljard inputtokens. 238x lagere inputprijs dan Claude Fable 5.1." En een sectie met als kop "Nul hallucinaties", die bij nadere beschouwing een bewering over betrouwbaarheidsschattingen is in plaats van een bewijs van nul fouten: elke Jev-beslissing gaat vergezeld van een betrouwbaarheidsschatting, zodat software kan handelen wanneer de betrouwbaarheid hoog is en kan escaleren wanneer dat niet het geval is. Alle vier zijn cijfers van TypeSafe, op workloads die TypeSafe zelf heeft gekozen, en geen ervan is onafhankelijk gerepliceerd. De lanceringspost zelf zegt dat het team verwacht dat zijn 193,6x en 444,6x aan de hoge kant van de winst in de praktijk zullen liggen, en merkt op dat de workflows zijn gebouwd door zijn eigen capabilities-team, met referentieantwoorden die door concurrerende modellen zijn geproduceerd. Onze eigen servingdata over zeven dagen op hetzelfde model zetten het foutpercentage op 0,49%, wat een andere meting op een andere workload is en het eerlijke tegenwicht vormt tegen het lezen van "nul" als een absoluut gegeven.

Wat zij niet hebben gepubliceerd

De architectuur, het aantal parameters, de trainingscompute en de gewichten van Jev zijn niet gepubliceerd, en er is geen gewichtenrepository in de GitHub-organisatie van het bedrijf. Gecontroleerd op 2026-09-30: die organisatie heeft elf publieke repositories; de substantiële zijn tooling, allemaal MIT of Apache-2.0 — een agent-skills-repo, een Python-SDK, een TypeScript-SDK, een drop-in clientadapter op basis van andere LLM-API's, een Dagger-modulecollectie, wat gepubliceerde workflow-evalcode, een n8n-node, en de eigen site van de organisatie. Sterrenaantallen en pushdatums veranderen, dus raadpleeg ze op de dag zelf in plaats van vanaf deze pagina.

Drie van de elf zijn forks van ongerelateerde projecten: vLLM, LLaDA en een Pulumi-provider voor ClickHouse Cloud. Het zijn forks van het werk van iemand anders en ze zeggen niets over hoe Jev is gebouwd — in het bijzonder niets over het feit dat Jev diffusiegebaseerd is. Het antwoord in één regel op de vraag of Jev open source is, is dat de tooling open is en het model niet.

Wat zij zichzelf toegeven

Twee bekentenissen uit het lanceringsbericht zijn meer waard dan de meeste kanttekeningen van leveranciers, omdat ze precies benoemen waar het bewijs zwak is. Over de prijs: "We kunnen niet bewijzen dat het niet gesubsidieerd is; we zullen de lange termijn nodig hebben om de duurzaamheid van onze prijsstelling te bewijzen (waarvan we verwachten dat die daalt, niet stijgt)." Over snelheid: "onze gepubliceerde evaluaties worden over het algemeen vanaf onze laptops aan de Westkust uitgevoerd (daar is onze dienst momenteel gevestigd)." Er is een derde, nuttigere bekentenis voor iedereen die erop voortbouwt: voor keuzesets met een hoge cardinaliteit draait Jev een tweefasensysteem dat onafhankelijk scoort en vervolgens een expliciete keuze maakt, "vandaar de incidentele vertraging." Dat is de leverancier die uitlegt waarom de latentie niet constant is over vraagtypes, en dat is iets wat je normaal gesproken uit een supportthread leert.

Waar je het vanaf vandaag daadwerkelijk kunt noemen

Via TypeSafe's eigen API, waar het model algemeen beschikbaar is en de homepage nog steeds de eigen formulering van de leverancier "early access" gebruikt — die bewoording is actueel en het waard om te behouden, terwijl "waitlisted" is afgeschaft: de documentatie publiceert concrete operationele limieten (100K tokens per seconde, 40 verzoeken per seconde, 429 met SDK-backoff bij overschrijding van een van beide) en bevat helemaal geen wachtlijstterminologie. En sinds 2026-09-24, via OrcaRouter.

Wat we aanbieden is het waard om precies te vermelden, omdat de vorm van de aanroep het onderdeel is dat verschilt. De catalogusvermelding is typesafe/jev-1.13, genaamd TypeSafe: Jev 1.13, met ondersteund eindpunttype "systemone" — dus het wordt bereikt via POST /v1/systemone in plaats van de OpenAI chat-completions-vorm, niet-streamend, tekst in en gestructureerde JSON uit, tot ongeveer 64K invoertokens over state en vragen samen. Invoer kost $0,042 per miljoen tokens en uitvoer wordt op nul gefactureerd, omdat er geen uitvoertokens te meten zijn: een getypeerde beslissing is geen proza. Dat is de lijstprijs van de provider die wordt doorgegeven, tegen 0% opslag, op dezelfde sleutel als de andere 200+ modellen in de catalogus — één API voor 200+ modellen, 0% opslag (lijstprijs van de provider doorgegeven, dus prijsverlagingen van leveranciers zijn hier dezelfde dag live). Als de reden dat je over TypeSafe AI leest is dat je wilt ontdekken of Jev's calibratie standhoudt op je eigen data voordat je een productiepad eraan toewijst, dan is het draaien naast een generatief model dat je al vertrouwt de goedkope manier om erachter te komen; overschakelen naar dat model wanneer Jev's vertrouwen laag terugkomt is de goedkope manier om het uit te brengen.

Onze eigen serveercijfers over zeven dagen voor het venster dat eindigt op 2026-09-30 — onze eigen cijfers uit ons eigen verkeer, niet de benchmark van de leverancier: p50 151 ms, p95 247 ms, ongeveer 349 outputtokens per seconde, een foutpercentage van 0,49% en 76,2M geserveerde tokens. De dagelijkse p50 in dat venster liep 175, 170, 163, 161, 170, 147, 143 ms, dus de mediaan is licht gedaald. Eén dag in de reeks, 09-28, heeft een p95 van 2.448 ms — een echte uitschieter in de gegevens, niet de norm, en geen getal om een latencybudget op te baseren. Deze worden dagelijks vernieuwd; de kaart is de bron.

Waar het model zwak is, volgens TypeSafe

De leverancier publiceert een jaggedness-pagina voor Jev 1.13, voor het laatst beoordeeld op 2026-09-17, die de faalmodi openhartiger benoemt dan de meeste lanceringsmaterialen. Het is de juiste pagina om te lezen voordat je op het model voortbouwt, en de lijst erop luidt als volgt. Jev beantwoordt de vraag die je hebt geschreven in plaats van de vraag die je bedoelde, dus woorden die het bereik afbakenen, negaties en impliciete voorwaarden moeten expliciet worden gemaakt. Het is geen rekenmachine: het presteert slechter op wiskundige dan op semantische vragen. Het leest datums als tekst in plaats van als geordende grootheden, dus ordening, hiaten en vensterlidmaatschap zijn onbetrouwbaar, en erger bij gemengde formaten. Dubbele ontkenningen en multi-hop-indirectie gaan ten koste van de nauwkeurigheid. De nauwkeurigheid daalt naarmate de toestand met irrelevante details groeit — de pagina zegt dat het 'aan contextrot lijdt' — dus eerst in code filteren is de oplossing. De toestand wordt als data behandeld, niet standaard als vijandig, dus geïnjecteerde instructies kunnen antwoorden beïnvloeden. Niet-overeenkomende instructies en criteria verwarren het. Structurele invarianten zijn niet gegarandeerd: een noul en een keuze-uitvoer hoeven niet overeen te komen, en een vraag plus de ontkenning ervan hoeven niet samen één te zijn, dus drempelwaarden mogen niet tussen de twee worden overgezet. En het is niet getraind om tekst te genereren — het via geketende keuzes forceren 'zal niet goed werken en zal zeer traag zijn.'

Hoe je TypeSafe AI moet interpreteren zes dagen na de routeringswijziging

Het bedrijf doet een sterke, specifieke, falsifieerbare bewering: dat een smal beslissingsmodel sneller, goedkoper en betrouwbaarder kan zijn dan een algemeen model op de subset van het werk waar je een oordeel nodig hebt in plaats van een paragraaf. De bewering is plausibel en deels zelf onderbouwd — de confidence-schattingen zijn een echt ontwerpverschil, de prijs is echt, en de latentie die we op ons eigen verkeer meten, ligt in dezelfde orde van grootte als die van de leverancier. Wat ontbreekt is het deel waarmee een buitenstaander de rest zou kunnen controleren: geen architectuur, geen parameters, geen gewichten, geen onafhankelijke benchmark, en een prijs waarvan het bedrijf zelf zegt niet te kunnen bewijzen dat die houdbaar is. De faalmodi zijn gedocumenteerd, wat meer is dan de meeste labs doen en de allerbeste reden is om het model serieus te nemen.

Als je beslist of je aandacht moet besteden: laat Jev draaien op invoer die je al hebt gelabeld, met de labels verborgen, en kijk of de betrouwbaarheidscijfers de gevallen die het goed heeft onderscheiden van de gevallen die het fout heeft. Die test kost bijna niets, tegen $0,042 per miljoen invoertokens, en het is de enige die de vraag beantwoordt die je echt hebt. Als je beslist of je het bedrijf moet vertrouwen: de openbaarmakingen zijn wat ze zijn, en het eerlijke antwoord is dat het bewijs momenteel het woord van de leverancier is plus wat je zelf genereert.