Is Jev open source? De gewichten zijn gesloten, de tooling niet.

Nee. Jev 1.13 (typesafe/jev-1.13) is geen open source, er is geen gewichtenrepository te vinden, en hoeveel je ook door de GitHub-organisatie van TypeSafe scrolt, je zult geen checkpoint, architectuurdocument of parameteraantal tegenkomen. Wat er wel is, is de software rond het model: elf openbare repositories, allemaal onder MIT of Apache-2.0, en geen enkele bevat Jev zelf. Dat is het eerlijke antwoord in één zin — de tooling is open, het model niet — en dat is de helft van het verhaal die een lezer nooit krijgt uit alleen "gesloten, gehost, ongepubliceerd". Twee datums kaderen het. TypeSafe bracht het model uit op 2026-09-15, wat buiten het venster van zeven dagen valt waarover deze blog schrijft, dus dit is geen lanceringsartikel en niets erin mag als zodanig worden gelezen. De gedateerde gebeurtenis is 2026-09-24, toen OrcaRouter typesafe/jev-1.13 aan zijn eigen catalogus toevoegde: de eerste keer dat Jev aanroepbaar is via een gateway van een derde partij in plaats van alleen via het eigen endpoint van TypeSafe. Dat is de uitzondering waarop deze pagina draait — een model dat draaibaar werd waar dat niet zo was.

Wat dat voor een lezer verandert, is beperkt en praktisch. Vóór 2026-09-24 betekende het evalueren van Jev dat je een tweede leveranciersrelatie moest openen voordat je ook maar één beslissing kon testen. Daarna zit Jev op dezelfde sleutel als de generatieve helft van dezelfde workflow: één API voor 200+ modellen, 0% markup (de lijstprijs van de provider wordt doorgegeven, dus prijsverlagingen van leveranciers zijn hier dezelfde dag live), met het model bereikbaar op typesafe/jev-1.13. Je roept het nog steeds aan in zijn eigen vorm — POST /v1/systemone, niet-streaming — omdat dat niet de OpenAI chat-completions-route is, maar het contract dat je ondertekent en de sleutel die je roteert, zijn dezelfde die je al hebt.

Het antwoord is twee antwoorden, en beide zijn nodig.

"Is Jev open source?" leest als een ja/nee-vraag en gedraagt zich als een vraag met twee delen. Deel één: het model. Het is gesloten. TypeSafe heeft geen gewichten, geen architectuur, geen cijfer over de rekenkracht voor de training en geen parameteraantal voor Jev 1.13 gepubliceerd, en er is geen repository die ernaar vernoemd is. Deel twee: de omliggende software. Die is open, wordt actief onderhouden en is oprecht nuttig, en dat is de reden dat een lezer die naar een repository zoekt niet simpelweg pech heeft.

De twee verwarren leidt in beide richtingen tot de verkeerde conclusie. Ga ervan uit dat het hele ding open is en je zult een middag besteden aan het zoeken naar een controlepunt dat niet bestaat. Ga ervan uit dat het hele ding gesloten is en je zult het onderdeel missen dat er echt toe doet als je je zorgen maakt over lock-in — een adapter onder MIT-licentie waarmee je tegen de getypeerde-beslissingsinterface kunt bouwen en kunt veranderen wat erachter zit.

Wat TypeSafe daadwerkelijk publiceert

Gelezen op 2026-09-30, de organisatie heeft elf openbare repositories. Aantallen sterren en pushdatums veranderen, dus behandel dit als een momentopname in plaats van een vast kenmerk van het project. Elke licentie is MIT of Apache-2.0, tenzij anders vermeld.

• skills — MIT, ongeveer 2,4k sterren, laatst gepusht op 2026-09-12. "Agentvaardigheden voor het bouwen met TypeSafe's System One API."

• system-one-adapter-python — MIT, 356 sterren, voor het laatst gepusht op 2026-09-22. "Drop-in vervanging van TypeSafeClient, mogelijk gemaakt door LLM-API's."

• typesafe-sdk-js — MIT, 257 sterren, laatst gepusht op 2026-09-15. De officiële TypeScript/JavaScript-bibliotheek voor de TypeSafe API.

• typesafe-sdk-python — MIT, 254 sterren, laatst gepusht op 2026-09-26. De officiële Python-bibliotheek; v0.7.2 voegde die dag een `http2`-extra toe, en v0.7.1 voegde op 2026-09-21 voorbeelden toe voor gebruik met AI-gateways.

• daggerverse — Apache-2.0, 23 sterren, laatst gepusht op 2026-09-25. Een verzameling Dagger-modules.

• WorkflowEvals — Apache-2.0, 7 sterren, voor het laatst gepusht op 2026-09-29. "evals.typesafe.ai workflowcode gepubliceerd."

• n8n-nodes-typesafe-ai — MIT, 1 ster, laatst gepusht op 2026-09-29.

• typesafe-ai.github.io — geen licentie vermeld, 2 sterren, voor het laatst gepusht op 2026-06-04.

Nog drie zijn forks van niet-gerelateerde projecten en worden hieronder behandeld: pulumi-clickhouse, LLaDA en vllm.

Niets in die lijst is het model. Er is geen Jev-repository, geen weightbestanden, geen tokenizer, geen servingconfiguratie — niets waarmee je een werkende kopie kunt opzetten. De repo's zijn client-side: twee officiële SDK's, een agent-skills-pakket, een CI-modulecollectie, een gepubliceerde eval-suite, een n8n-node, de org-site en de adapter. Dat is een echt en goed onderhouden oppervlak, en het is niet het model.

De enige repository die ertoe doet als je lock-in wilt vermijden

system-one-adapter-python is de vermelding met de meeste gevolgen voor iedereen die een adoptiebeslissing neemt, en de eigen beschrijving verwoordt het punt: een "Drop-in TypeSafeClient-vervanging, aangedreven door LLM-API's."

Lees dat aandachtig, want het doet iets specifieks. Het duurzame bezit in een System One-integratie is de interface, niet het endpoint erachter: je definieert een stukje state en een reeks benoemde vragen, en iets geeft één getypeerd antwoord per vraag terug. Dat contract is waar je codebase uiteindelijk omheen gevormd wordt. De adapter ontkoppelt het contract van de implementatie — je blijft bouwen tegen de getypeerde beslissingsinterface, en hetgeen de beslissingen produceert, is daaronder een verwisselbare LLM API-aanroep.

Twee eerlijke kanttekeningen. Een adapter is niet het model: antwoorden die een algemene LLM via dit pad produceert, zijn niet de gekalibreerde waarschijnlijkheden die Jev teruggeeft, dus het is een manier om de interface overdraagbaar te houden, niet een manier om het gedrag van Jev zonder Jev te krijgen. En het is expliciet een TypeSafe-project — de ontsnappingsmogelijkheid wordt gebouwd door de leverancier waar je misschien aan wilt ontsnappen, wat beter is dan niets en niet hetzelfde als een onafhankelijke.

De twee vorken, en de gevolgtrekking die ze uitnodigen

Drie van de elf repositories zijn forks. pulumi-clickhouse is een Pulumi-provider voor ClickHouse Cloud, Apache-2.0, 3 sterren, laatst gepusht op 2026-07-08. De andere twee zijn degenen die als bewijs worden gelezen, en beide lezingen zijn onjuist.

• vllm — Apache-2.0, 3 sterren, voor het laatst gepusht op 2025-05-23. Een fork van de high-throughput inferentie- en serving-engine.

• LLaDA — MIT, 12 sterren, laatst gepusht op 2025-06-17. Een fork van de officiële PyTorch-implementatie voor "Large Language Diffusion Models."

De luie gevolgtrekking schrijft zichzelf: ze hebben een repository voor diffusietaalmodellen geforkt, dus Jev moet op diffusie gebaseerd zijn. Dat is niet zo, en de fork zegt je niets over de architectuur van Jev. Een fork is een kopie van andermans code onder andermans licentie, die in een organisatie staat om redenen die de eigen laatste-pushdatum ervan duidelijk maakt — mei en juni 2025, meer dan een jaar voordat Jev publiekelijk werd uitgebracht, en sindsdien onaangeroerd. Geen van beide repositories maakt deel uit van wat TypeSafe in september heeft uitgebracht. Als je wilt weten hoe Jev werkt, heeft TypeSafe dat niet gepubliceerd, en geen enkele fork in de organisatie van TypeSafe vult die leemte.

Wat het sluiten van de gewichten je werkelijk kost

Vier dingen, en ze zijn eerder concreet dan filosofisch.

• Je kunt niet zelf hosten. Er is geen artefact om te draaien, dus een storing bij de leverancier of een wijziging in de toegang kun je niet omzeilen door je eigen kopie op te zetten.

• Je kunt niet auditen. TypeSafe publiceert wel een jaggedness-pagina voor Jev 1.13 — voor het laatst herzien op 2026-09-17 — die benoemt waar het model onbetrouwbaar is: letterlijke lezing van bewoordingen boven intentie, alles wat met rekenen te maken heeft, vergelijking van datum en tijd, indirectie en dubbele ontkenningen, grote states vol irrelevante details, adversariële inhoud in de state, tegenstrijdige instructies en criteria, en structurele invarianten die het niet garandeert, zoals dat een waar/onwaar-antwoord en de equivalente ja/nee-keuze het oneens zijn. Die pagina is ongewoon openhartig, en het blijft toch de leverancier die zijn eigen huiswerk nakijkt. Niemand buiten TypeSafe heeft de gewichten geïnspecteerd.

• Je kunt niet fine-tunen. Er is geen basismodel om aan te passen, dus een beslissingstaak die Jev slecht afhandelt, blijft slecht afgehandeld totdat de leverancier het wijzigt — de eigen remedies van de jaggedness-pagina zijn workarounds in je code, geen trainingsruns.

• Je kunt een versie niet verder vastpinnen dan de alias van de leverancier. typesafe/jev-1.13 is een gehoste naam, dus wat volgende maand een aanroep beantwoordt, is alles wat TypeSafe dan onder die naam serveert.

Niets daarvan is uniek voor Jev en niets ervan is een schandaal; het is de afweging die een gehost beslissingsmodel maakt, en het tegenwicht is dat je nooit een checkpoint, een GPU-rekening of een inferentie-stack draagt. Het is de moeite waard om te weten aan welke kant van de afweging je staat voordat je erop voortbouwt.

Wat Jev is, nu je het kunt bellen

Jev is geen chatmodel en genereert geen proza. Je stuurt een state — het materiaal dat beoordeeld moet worden, als tekst, een object of een array — plus een set benoemde vragen, en het retourneert één gestructureerd antwoord per vraag. Elke vraag is een van drie primitieven:

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

• keuze — kies één van maximaal 255 gelabelde opties.

• score — beoordeel op een geordende schaal van 2 tot 10 niveaus.

De eigen documentatie van TypeSafe toont een voorbeeld van een score met 0 als beginindex; de modelkaart van Jev 1.13 publiceert niveaus van 2–10. Beide zijn eigen materiaal van de leverancier en deze pagina verzint geen verzoening tussen beide.

De trainingsmethode is een door TypeSafe zelf bedachte term: Reinforcement Learning for Calibrated Decisions (RLCD), beschreven in het lanceringsbericht tegenover RLHF en RLVR op de as van gekalibreerde beslissingen met eerlijke waarschijnlijkheden. RLCD is een term van TypeSafe, geen generieke machinelearning-afkorting, en moet worden opgevat als een leveranciersbeschrijving, niet als een onafhankelijk gekarakteriseerde techniek.

Toegang is niet langer beperkt: Jev is sinds 2026-09-21 algemeen beschikbaar, en "waitlisted" is niet meer in gebruik. "Early access" is nog steeds TypeSafe's eigen huidige formulering op de homepage, dus het is geen bewering om af te doen — het is simpelweg het label van de leverancier, en de operationele limieten die daarnaast worden gepubliceerd zijn concreet.

De cijfers op onze kaart: een context van 65.536 tokens, waarbij de leverancier ongeveer 64K invoer documenteert voor de gecombineerde state plus vragen. Als je een kleiner cijfer voor Jev hebt zien vermeld, is dat alleen het state-budget en niet een concurrerende meting, en de twee moeten niet als een tegenstrijdigheid worden gepresenteerd. De prijs is $0,042 per miljoen inputtokens, waarbij output tegen nul wordt gefactureerd — er zijn geen outputtokens om te meten, omdat een getypte beslissing geen proza is.

Onze eigen servingdata, afkomstig van ons eigen verkeer in plaats van de benchmark van de leverancier, over de zeven dagen tot 2026-09-30: p50 151 ms, p95 247 ms, ongeveer 349 outputtokens per seconde, een foutpercentage van 0,49% en 76,2 miljoen tokens geserveerd. De dagelijkse p50 in dat venster liep 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, met één echte uitschieter — een p95 van 2.448 ms op 2026-09-28 die in de reeks thuishoort zonder de norm te zijn.

De kopclaims van TypeSafe, aangeduid als die van de leverancier en niet onafhankelijk gerepliceerd: "193,6x sneller, 444,6x goedkoper", met een voetnoot die verwijst naar System One-workflows; een uitgewerkt voorbeeld van $0,000081 in 0,114 s tegenover $0,013880 in 8,566 s voor LLM's; "$42 per miljard inputtokens"; en "nul hallucinaties", wat een claim is over confidence-schattingen in plaats van een bewijs van nul fouten — het foutenpercentage van 0,49% op onze kaart is het eerlijke tegenwicht. TypeSafe zegt ook ronduit dat het niet kan bewijzen dat zijn prijsstelling niet wordt gesubsidieerd, en dat zijn gepubliceerde evaluaties over het algemeen zijn uitgevoerd op laptops aan de westkust, waar de dienst is gevestigd. Zijn eigen benchmarkkaart is nog steeds gemarkeerd als in behandeling.

De repositories van derden bestaan, en wij staan er niet voor in.

Zoekopdrachten naar "jev github" leveren uiteindelijk repositories op die niet van TypeSafe zijn: wrappers, promptcollecties, adapterexperimenten en de bekende "awesome"-lijst die rond elk nieuw model opduikt. Ze maken geen deel uit van wat de leverancier publiceert, ze zijn niet door de leverancier beoordeeld, en hun sterrenaantallen meten nieuwsgierigheid in plaats van correctheid. Ze kunnen nuttig zijn; ze zijn geen documentatie, en niets erin is een uitspraak over hoe Jev werkt.

Wat zou dit antwoord veranderen?

Een release van gewichten, een gepubliceerde architectuur, of een onafhankelijke evaluatie van de beslissingskwaliteit in plaats van de latentie. Elk van de drie zou het eerste woord van deze pagina omdraaien. Tot dan heeft de zoekopdracht een stabiel antwoord, en het deel ervan waarop het de moeite loont om actie te ondernemen is de toolchain: als de getypeerde-beslissingsinterface is waartegen je bouwt, is een MIT-gelicentieerde adapter die het achterliggende model verwisselt het verschil tussen een beslissing die je opnieuw kunt bekijken en een die je niet opnieuw kunt bekijken.

Jev 1.13 staat in onze catalogus onder typesafe/jev-1.13, op dezelfde sleutel als de rest van een stack en gerouteerd via het speciale systemone-endpoint in plaats van de chat-completions-vorm. Het model is gesloten, de tooling is open, en beide helften daarvan zijn nu vanaf één plek bereikbaar.