"System One" als modelcategorie: waar Jev 1.13 daarin past

"System One" is de categorieterm die TypeSafe gebruikt voor de splitsing tussen een model dat beslist en een model dat schrijft, en Jev 1.13 (typesafe/jev-1.13) is het eerste lid — een model dat getypeerde antwoorden teruggeeft in plaats van zinnen. Het is geen nieuw model. TypeSafe heeft Jev op 2026-09-15 uitgebracht, en deze pagina is geen lanceringsartikel: het model is vijftien dagen oud en valt buiten het venster van zeven dagen waarover deze blog schrijft. Wat er binnen het venster gebeurde, is dat OrcaRouter het model op 2026-09-24 aan zijn catalogus toevoegde en de modelkaart voor Jev 1.13 opende op https://www.orcarouter.ai/models/typesafe/jev-1.13 — de eerste keer dat het aanroepbaar is via een gateway van een derde partij in plaats van alleen via het eigen endpoint van TypeSafe. Het idee achter de categorie is de reden dat deze pagina bestaat; de wijziging in de serving is de reden dat deze vandaag gedateerd is.

De eenvoudige versie van de categorie: aan een LLM wordt een vraag gesteld en die schrijft een antwoord dat een persoon kan lezen. Aan een System One-model wordt een vraag gesteld en het retourneert een waarde waarop een programma kan vertakken. TypeSafe's eigen formulering is dat "LLM's woorden voor mensen produceren", terwijl "Jev getypeerde beslissingen produceert en meer op code lijkt: betrouwbaar, snel, zelfconsistent en type-safe." Die zin is de hele categorie samengeperst in één zinsdeel, en het is de moeite waard om die langzaam uit te pakken, want de vier bijvoeglijke naamwoorden verrichten verschillend veel werk en één ervan doet meer dan de andere.

Wat "meer als code" eigenlijk beweert

Neem de vier claims in volgorde, want het zijn geen vier herformuleringen van 'het is beter'.

• Betrouwbaar — de vorm van de output ligt vooraf vast. Je declareert de vraag; het antwoord kan alleen terugkomen als een van de waarden die je hebt toegestaan. TypeSafe stelt ronduit dat "het model nooit typefouten maakt", en merkt op dat dit de enige bewering van hen is die "wiskundig onmogelijk" te weerleggen is met een tegenvoorbeeld, omdat een waarde die niet in je gedeclareerde set zit geen waarde is die het model kan uitsturen.

• Snel — alle antwoorden worden in één enkele doorgang geproduceerd in plaats van het ene token na het andere. De lanceringspost van TypeSafe verwoordt het als: "Jev geeft alle waarschijnlijkheden parallel weer in plaats van autoregressief per token te genereren." In ons eigen zevendaagse serveervenster dat eindigt op 2026-09-30, is de mediane tijd tot het eerste token op typesafe/jev-1.13 151 ms en de p95 is 247 ms.

• Zelfconsistent — dezelfde toestand met dezelfde vragen leidt doorgaans tot dezelfde antwoorden. Een programmeeranalogie is wat dit leesbaar maakt, maar het is ook waar de analogie ophoudt een bewijs te zijn: het determinisme van een compiler is een eigenschap van zijn constructie, terwijl dit een bewering over gedrag is. Onze eigen metingen zijn de eerlijke lezing daarvan — het foutpercentage op ons playground-verkeer over hetzelfde venster van zeven dagen is 0,49%, dus het is zelfconsistent zoals een goede functie zelfconsistent is, niet zoals rekenkunde dat is.

• Typeveilig — en dit is degene die het zwaarst weegt. Typeveilig is hier geen kwaliteitsadjectief; het is een uitspraak over waar het model staat ten opzichte van een typechecker. In een gewone generatieve pipeline begint het typesysteem pas nadat het model klaar is: het model schrijft tekst, een parser raadt de vorm, een validator controleert die, en een faalpad behandelt de gevallen waarin de gok verkeerd was. Een System One-model verplaatst de typedeclaratie naar vóór de aanroep. De drie primitieven die onze kaart documenteert, vormen het typesysteem: noul, een waar/onwaar-oordeel dat met een gekalibreerde waarschijnlijkheid wordt teruggegeven; choice, één label gekozen uit maximaal 255 gelabelde opties; en score, een beoordeling op een geordende schaal van 2 tot 10 niveaus. Je kiest de primitieve, je levert de labels of de criteria, en de waarde die terugkomt, is uit die set afkomstig.

TypeSafe publiceert wel één verschil tussen zijn eigen documentatie en de onze dat het vermelden waard is in plaats van op te lossen: de documentatie van de leverancier toont een Score-voorbeeld met zero-indexering, terwijl onze kaart de schaal documenteert als 2 tot 10 niveaus. Beide beschrijven hetzelfde primitief. Als je een drempelwaarde bouwt, lees dan de pagina van de leverancier voor de exacte indexering die je SDK hanteert.

De twee faalmodi die ophouden te bestaan

De interessante consequentie van "geen proza" is niet esthetisch. Het is dat de twee faalwijzen die productie-generatieve pipelines domineren, in dit ontwerp ontbreken in plaats van erdoor te worden verzacht.

Formaatdrift is het eerste probleem. Een LLM die de opdracht krijgt JSON te retourneren, retourneert meestal JSON, en de rest van de tijd iets dat aan JSON grenst — een commentaar achteraan, een markdown-fence, een veld dat is hernoemd naar een synoniem, een genest object terwijl het schema een string verwachtte. De oplossingen op promptniveau (sterkere instructies, few-shotvoorbeelden, een schema in het systeembericht) zijn allemaal pogingen om een vorm vast te houden die het model vrij staat te verlaten, omdat de vorm een verzoek is, geen beperking. De framing van TypeSafe maakt het contrast expliciet: bij strings worden "mogelijke outputs en structuur" opgevraagd en moeten reacties "worden geparseerd + gevalideerd", met "altijd enig risico dat de AI ontspoort." Wanneer de mogelijke outputs vooraf worden vastgelegd, heeft de drift nergens om naartoe te gaan.

Onparseerbare output is de tweede, en het is echt dezelfde fout op een slechter moment — niet een veld dat er lichtjes naast zat, maar een antwoord dat de parser helemaal niet kan lezen, dat op het meest onhandige moment in een workflow arriveert. Een model dat een getypeerde waarde uitzendt, kent zo'n toestand niet.

Dit is een structureel argument, en het moet als zodanig worden geformuleerd. Het zegt niets over of een individueel antwoord juist is — een keuzevraag kan het verkeerde label kiezen, en een noul kan true retourneren met hoge zekerheid wanneer het eerlijke antwoord onwaar is. Wat verdwijnt, is de categorie van fouten die een parser zou hebben opgevangen. Dat is een echte en nuttige reductie, en het is niet dezelfde bewering als "de antwoorden zijn juist."

Waarom de prijs een vorm is en geen korting

Het model is geprijsd op $0,042 per miljoen inputtokens, waarbij de output tegen nul wordt gefactureerd — en die nul is geen promotietarief, maar een artefact van het ontwerp. Een model dat drie tokens gestructureerd antwoord produceert, heeft geen outputvolume om te meten, dus prijsstelling per outputtoken heeft niets om aan te hechten. De factureringsvorm is een kostenpost per inputtoken en een beslissing. Onze catalogus geeft de lijstprijs van de provider door tegen 0% opslag, dus de $0,042 is het getal van TypeSafe en niet een getal dat wij hebben vastgesteld, en een prijswijziging van een leverancier zou dezelfde dag live zijn.

Zet de twee vormen naast elkaar en het verschil is geen percentage. De kosten van een generatieve pipeline schalen met hoeveel het model zegt: een uitgebreid antwoord kost meer dan een beknopt antwoord voor dezelfde beslissing, en een chain-of-thought-redeneermodel brengt de tokens in rekening die het besteedt aan nadenken voordat het antwoordt, ongeacht of het antwoord er beter van wordt. De kosten van een System One-aanroep schalen met hoeveel je het laat zien — de toestand en de vragen. Stel één vraag bij een lang document en je betaalt voor het document. Stop veertig vragen bij dezelfde toestand (het inputbudget op onze kaart is 65.536 tokens over de gecombineerde toestand en vragen, ruwweg 64K; als je in eerdere OrcaRouter-artikelen een cijfer van "ongeveer 32.000 tokens" hebt gezien, dan is dat het toestandsbudget alleen, niet een concurrerend totaal) en je betaalt één keer voor het document en krijgt veertig beslissingen terug.

Daarom is kosten per beslissing, niet kosten per token, de juiste eenheid voor deze klasse — en daarom loopt de meter precies de andere kant op dan de meeste teams verwachten. De typische zet om kosten te verlagen bij generatieve AI is "laat het model minder zeggen." Hier valt niets minder te zeggen.

TypeSafe's eigen cijfers, die door de leverancier zijn gerapporteerd en niet onafhankelijk zijn gerepliceerd, zijn rechtstreeks gericht op die vergelijking: "193.6x Sneller, 444.6x Goedkoper," met als voetnoot "gebaseerd op workflows voor System One-taken (bewijs)", met een uitgewerkt voorbeeld dat luidt: "TypeSafe AI-kosten $0.000081 Voltooid in 0.114s / LLMs kosten $0.013880 Voltooid in 8.566s." De homepage vermeldt ook "$42 per miljard inputtokens" tegenover "238x lagere inputprijs dan Claude Fable 5.1." Beschouw dit alles als het argument van de leverancier, niet als een gemeten resultaat: de lanceringspost geeft toe dat "onze gepubliceerde evaluaties over het algemeen worden uitgevoerd vanaf onze laptops aan de Westkust" en dat "we niet kunnen 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 omlaag gaat, niet omhoog)." Die twee toegevingen zijn van de leverancier zelf, en ze vormen het juiste kader voor elke vermenigvuldigingsfactor op de pagina.

Kalibratie is de tweede helft van het idee

Als de categorie alleen "gestructureerde uitvoer" was, zou het functieaanroepen met extra stappen beschrijven. Wat het iets eigens maakt, is dat elk antwoord met een waarschijnlijkheid komt, en die waarschijnlijkheden zijn het trainingsdoel. TypeSafe noemt de methode Reinforcement Learning for Calibrated Decisions (RLCD) — hun term, geen generieke afkorting — en de vergelijkingstabel in het lanceringsbericht zet die naast RLHF en RLVR: RLHF optimaliseert voor wat menselijke beoordelaars verkiezen, RLVR voor uitvoer die programmatisch kan worden gecontroleerd, en RLCD voor "antwoorden met epistemisch eerlijke waarschijnlijkheden bij System One-taken".

Het praktische verschil is waarvoor de waarschijnlijkheid dient. In een generatieve pipeline is de zekerheidsschatting een tweede generatie: je vraagt het model hoe zeker het is en het schrijft een getal, dat zelf proza is met dezelfde faalmodi. Hier komt de waarschijnlijkheid samen met de beslissing terug, in dezelfde pass, en het is datgene waarop je vertakt. TypeSafe's eigen framing van de opbrengst is dat een model dat een taak 95% van de tijd kan uitvoeren maar "niet zegt wanneer het in de 5% zit" niet kan worden gebruikt om de taak te automatiseren; de zekerheid geeft je een plek om de escalatie onder te brengen, bij een persoon of bij een redeneermodel.

De homepage van TypeSafe noemt dit 'Zero Hallucinations', en legt uit dat elke beslissing een vertrouwensschatting bevat, zodat software kan handelen wanneer het vertrouwen hoog is en kan escaleren wanneer dat niet het geval is. Lees dat aandachtig: het is een bewering over vertrouwensschattingen, geen bewering dat geen enkel antwoord ooit fout is. Onze eigen kaart is het tegenwicht — een foutpercentage van 0,49% over de zeven dagen die eindigen op 2026-09-30, op ons verkeer, door ons gemeten. Dat cijfer is een rollend venster, geen vaste testset: het stond een paar dagen eerder op 0,57% in hetzelfde venster, en het zal weer veranderen.

Waar System One naast System Two staat

Het vocabulaire rond snel/langzaam bestaat al veel langer dan TypeSafe. Het is afkomstig uit Kahnemans Thinking, Fast and Slow, en het werd al jaren daarvoor door AI-onderzoekers overgenomen — het label "Systeem 2" werd al lang voordat TypeSafe bestond gekoppeld aan modellen voor chain-of-thought en doelbewust redeneren, en TypeSafe beweert geen van beide termen te hebben bedacht. Wat zij hebben gedaan, is het onderscheid toepassen op een productgrens in plaats van op een promptingmodus.

• Een Systeem Twee-redeneermodel verbruikt meer rekenkracht voordat het antwoordt, en wordt beter in problemen die dat vereisen. De uitvoer is nog steeds proza, en de extra rekenkracht wordt gefactureerd als outputtokens.

• Een System One-model in de zin van TypeSafe denkt niet langer na om beter te antwoorden. Het antwoordt in één pass, en wat het voor de snelheid opoffert, is het vermogen om iets anders dan een getypeerde waarde voort te brengen.

• De twee zijn complementair binnen een workflow, geen rivalen in een vergelijking. Een aanroep van System One behandelt de beslissingen die snel, goedkoop en leesbaar moeten zijn; het redeneermodel krijgt de gevallen die de betrouwbaarheidsscore als onzeker heeft gemarkeerd. De getypeerde uitvoer is wat de overdracht schoon maakt — je geeft een waarde en een waarschijnlijkheid door aan de volgende fase, geen zin om opnieuw te parsen.

Het punt waarop de terminologie glibberig wordt, is dat "System One-model" wordt behandeld als een gevestigde categorie die andere leveranciers hebben overgenomen. Daar is geen bewijs voor, en deze pagina moet niet zo gelezen worden dat ze dat beweert. TypeSafe gebruikt de term voor zijn eigen klasse van modellen; de disclaimer in onze eigen kaart zegt hetzelfde door weglating, door één eindpunttype voor één model te vermelden. Als een ander lab de uitdrukking voor dezelfde architectuur begint te gebruiken, is dat een feit dat het vermelden waard is, en dan zullen ze het in hun eigen woorden moeten melden.

Onze kaart noemt karteligheid ook als onderdeel van de eerlijke grens in plaats van als een verrassing: negen benoemde faalmodi. De items over letterlijke lezing en indirectie zijn degenen die rechtstreeks voortkomen uit de 'meer zoals code'-analogie — een model dat de vraag beantwoordt die je hebt geschreven in plaats van de vraag die je bedoelde, gedraagt zich als een functie die precies deed wat de code zei. Het item over tellen doet dat niet. Een model dat 'de vorm van een antwoord herkent in plaats van te turven' is helemaal niet code-achtig, en daarom is de eigen aanbeveling van TypeSafe om in code te tellen en, waar een echte beoordeling nodig is, één vraag per item te stellen en de antwoorden zelf op te tellen.

Twee beperkingen die het ontwerp vormgeven, niet de score

Beide komen van dezelfde plek: geen strings betekent niets om te streamen en niets om in stukjes te verzenden.

• Niet-streamend — de eerste output is het voltooide antwoord, dus een System One-aanroep is één enkele respons, geen stream. De vraag is niet of het kan streamen, maar wat er gestreamd zou worden.

• Eén requestvorm — het model wordt via POST /v1/systemone in onze catalogus aangeboden in plaats van de chat-completions-vorm, en dat is de eerlijke versie van een oudere bewering dat het "zijn eigen requestvorm spreekt." Het is een echt verschil in hoe je het aanroept: een state-object en een map met benoemde vragen gaan erin; een gestructureerd antwoord per vraag komt eruit. Je zult er een mapper voor schrijven, en omdat de uitvoer getypeerd is, is de mapper de hele integratie — eronder ligt geen defensieve parseerlaag.

De moeite waard om te weten voordat je een loadtest uitvoert: latentie is niet gelijkmatig over vraagtypen. TypeSafe legt uit waarom, in hun eigen woorden — "Voor keuzes met een hogere cardinaliteit gebruiken we een tweestapssysteem waarbij we onafhankelijk scoren en daarna een expliciete keuze maken, vandaar de occasionele vertraging." Een routeringsbeslissing met 4 opties en een classificatie met 200 opties zijn op papier hetzelfde primitief en in de praktijk verschillende hoeveelheden werk. Onze dagelijkse medianen over de zeven dagen die eindigen op 2026-09-30 zijn 175, 170, 163, 161, 170, 147, 143 ms. Eén dag in die reeks, 2026-09-28, had een p95 van 2.448 ms — een echte eendaagse uitschieter die eerlijk in de reeks staat, maar niet de vorm van de dienst is.

Het andere dat je vóór een eerste integratie moet weten, is waarmee je verbinding maakt. De tooling rond Jev is open source onder MIT- en Apache-2.0-licenties — de Python- en JavaScript-SDK's, een adapter die dezelfde client aanbiedt op basis van gewone LLM-API's, de workflow-evals-code, en een reeks agent-skills, allemaal in de openbare repositories van TypeSafe, met sterrenaantallen en pushdatums die nog zo recent als 2026-09-26 en 2026-09-29 zijn gewijzigd. Voor het model geldt dat niet. Er is geen weights-repository: de architectuur van Jev, het parameteraantal, de trainingscompute en de gewichten zijn niet gepubliceerd, en een lezer die dat nagaat, mag niet op het verkeerde been worden gezet door de drie repositories in die organisatie die forks van niet-gerelateerde projecten zijn — een vLLM-fork, een release van een diffusion-language-model uit 2025, en een Pulumi-provider. Geen ervan zegt iets over hoe Jev is gebouwd. Het antwoord in één regel is dat de tooling open is en het model niet.

Het vandaag uitvoeren, en wat er voor een lezer verandert

Jev 1.13 staat op OrcaRouter als typesafe/jev-1.13, bereikbaar met dezelfde key als 200+ andere modellen, met de lijstprijs van de provider doorberekend tegen 0% opslag. De praktische waarde daarvan op een pagina over een categorie is beperkt en het is de moeite waard om die precies te benoemen: een System One-model uitproberen vereist niet langer een apart account, een aparte key en een aparte factuur voor een model waarvan je misschien nog niet weet dat je het wilt. Het staat naast de generatieve helft van dezelfde workflow — de classifier en de writer op één credential, op één plek, met de tellingen van wat je daadwerkelijk hebt aangeroepen.

Niets hier verandert wat het model is. Het is gelanceerd op 2026-09-15 en TypeSafe beschrijft het nog steeds als early access; wat het is, is sindsdien niet veranderd. Wat op 2026-09-24 is veranderd, is dat een lezer nu kan nagaan wat het hen in de praktijk kost zonder zich eerst aan een tweede leveranciersrelatie te verbinden. Als je hebt gewacht om te zien of de categorie een prototype waard is, is dat wat er is veranderd.