"System One" som modellkategori: var Jev 1.13 befinner sig i den

"System One" är den kategoriterm som TypeSafe använder för sin uppdelning mellan en modell som beslutar och en modell som skriver, och Jev 1.13 (typesafe/jev-1.13) är dess första medlem – en modell som returnerar typade svar i stället för meningar. Det är inte en ny modell. TypeSafe släppte Jev den 2026-09-15, och den här sidan är inte en lanseringsartikel: modellen är femton dagar gammal och utanför det sjudagarsfönster som den här bloggen skriver till. Det som hände inom fönstret är att OrcaRouter lade till modellen i sin katalog den 2026-09-24 och öppnade modellkortet för Jev 1.13 på https://www.orcarouter.ai/models/typesafe/jev-1.13 — första gången den går att anropa via en tredjepartsgateway i stället för bara via TypeSafes egen endpoint. Kategoriidén är anledningen till att den här sidan finns; serveringsändringen är anledningen till att den är daterad i dag.

Den enkla versionen av kategorin: en LLM får en fråga och skriver ett svar som en person kan läsa. En System One-modell får en fråga och returnerar ett värde som ett program kan förgrena sig utifrån. TypeSafes egen formulering är att "LLM:er producerar ord för människor" medan "Jev producerar typade beslut och är mer som kod: tillförlitlig, snabb, självkonsistent och typsäker." Den meningen är hela kategorin komprimerad till en enda sats, och den är värd att packa upp långsamt, eftersom de fyra adjektiven gör olika mycket arbete och ett av dem gör mer än de andra.

Vad "mer som kod" egentligen hävdar

Ta de fyra påståendena i ordning, eftersom de inte är fyra omformuleringar av ”det är bättre”.

• Tillförlitlig — utdatans form är fastställd i förväg. Du deklarerar frågan; svaret kan bara returneras som ett av de värden du tillät. TypeSafe säger rent ut att "modellen aldrig gör typfel" och konstaterar att detta är det enda av deras påståenden som är "matematiskt omöjligt" att motbevisa med ett motexempel, eftersom ett värde som inte finns i din deklarerade mängd inte är ett värde som modellen kan avge.

• Snabb — alla svar produceras i en enda omgång i stället för en token i taget. TypeSafe:s lanseringsinlägg formulerar det som "Jev matar ut alla sannolikheter parallellt i stället för att autoregressivt generera token för token." Under vårt eget serveringsfönster på sju dagar som avslutades 2026-09-30 är mediantiden till första token för typesafe/jev-1.13 151 ms och p95-värdet är 247 ms.

• Självkonsistent — samma tillstånd med samma frågor tenderar att ge samma svar. En programmeringsanalogi är det som gör detta begripligt, men det är också där analogin slutar vara ett bevis: en kompilators determinism är en egenskap hos dess konstruktion, medan detta är ett påstående om ett beteende. Våra egna mätningar är den ärliga tolkningen av det — felkvoten för trafiken i vår playground under samma sjudagarsfönster är 0,49 %, så den är självkonsistent på samma sätt som en bra funktion är självkonsistent, inte på det sätt som aritmetiken är.

• Typsäker — och detta är den som väger tyngst. Typsäker är inte ett kvalitetsadjektiv här; det är ett påstående om var modellen befinner sig i förhållande till en typkontrollant. I en vanlig generativ pipeline börjar typsystemet efter att modellen är klar: modellen skriver text, en parser gissar formen, en validator kontrollerar den, och en felväg hanterar de fall där gissningen var fel. En System One-modell flyttar typdeklarationen till före anropet. De tre primitiver som vårt kort dokumenterar är typsystemet: noul, en bedömning av sant/falskt som returneras med en kalibrerad sannolikhet; choice, en etikett vald bland upp till 255 märkta alternativ; och score, en värdering på en ordnad skala med 2 till 10 nivåer. Du väljer primitiven, du anger etiketterna eller kriterierna, och värdet som kommer tillbaka hämtas från den mängden.

TypeSafe publicerar faktiskt en skillnad mellan sin egen dokumentation och vår som är värd att nämna snarare än att lösa: leverantörens dokumentation visar ett nollindexerat Score-exempel, medan vårt kort dokumenterar skalan som 2 till 10 nivåer. Båda beskriver samma primitiv. Om du bygger en tröskel, läs leverantörens sida för den exakta indexering som din SDK använder.

De två felmoder som upphör att existera

Den intressanta konsekvensen av "ingen prosa" är inte estetisk. Det är att de två fel som dominerar generativa produktionspipelines är frånvarande i den här designen snarare än att de mildras av den.

Formatglidning är den första. En LLM som får instruktionen att returnera JSON returnerar JSON för det mesta, och något angränsande till JSON resten av tiden — en avslutande kommentar, ett markdown-staket, ett fält som döpts om till en synonym, ett nästlat objekt där schemat ville ha en sträng. Åtgärderna på promptnivå (starkare instruktioner, few-shot-exempel, ett schema i systemmeddelandet) är alla försök att hålla en form som modellen är fri att överge, eftersom formen är en begäran, inte en begränsning. TypeSafes inramning gör kontrasten explicit: med strängar efterfrågas "möjliga utdata och struktur" och svar "måste parsas + valideras", med "alltid en viss risk att AI:n spårar ur." När de möjliga utdata deklareras i förväg har glidningen ingenstans att ta vägen.

Otolkbar utdata är den andra, och det är egentligen samma fel vid ett värre tillfälle – inte ett fält som kom tillbaka lite fel, utan ett svar som parsern inte kan läsa alls, och som anländer vid den minst lägliga punkten i ett arbetsflöde. En modell som avger ett typat värde har inget sådant tillstånd.

Detta är ett strukturellt argument, och det bör framställas som ett sådant. Det säger ingenting om huruvida ett enskilt svar är korrekt — en flervalsfråga kan välja fel etikett, och en noul kan returnera sant med hög konfidens när det ärliga svaret är falskt. Det som försvinner är den felkategori som en parser skulle ha fångat. Det är en verklig och användbar reduktion, och det är inte samma påstående som "svaren är rätt."

Varför priset är en form, inte en rabatt

Modellen är prissatt till $0,042 per miljon indatatoken, medan utdata faktureras till noll — och den nollan är inte en kampanjpris, den är en artefakt av designen. En modell som skickar ut tre token av strukturerat svar har ingen utdatavolym att mäta, så prissättning per utdatatoken har inget att fästa vid. Faktureringsformen är en avgift per indatatoken och ett beslut. Vår katalog för vidare förleverantörens listpris med 0 % påslag, så $0,042 är TypeSafe:s siffra snarare än en siffra vi satt, och en ändring av leverantörens pris skulle slå igenom samma dag.

Ställ de två formerna sida vid sida och skillnaden är inte en procent. Kostnaden för en generativ pipeline skalar med hur mycket modellen säger: ett ordrikt svar kostar mer än ett kortfattat för samma beslut, och en chain-of-thought-resonemangsmodell debiterar för de tokens den lägger på att tänka innan den svarar, oavsett om svaret blir bättre. Kostnaden för ett System One-anrop skalar med hur mycket du visar det – tillståndet och frågorna. Ställ en fråga mot ett långt dokument och du betalar för dokumentet. Packa fyrtio frågor mot samma tillstånd (indatabudgeten på vårt kort är 65 536 tokens för det kombinerade tillståndet och frågorna, ungefär 64K; om du har sett en siffra på "ungefär 32 000 tokens" i tidigare OrcaRouter-artiklar är det enbart tillståndsbudgeten, inte en konkurrerande totalsumma) och du betalar för dokumentet en gång och får fyrtio beslut tillbaka.

Det är därför kostnad per beslut, inte kostnad per token, är rätt enhet för den här klassen – och därför mätaren går åt motsatt håll mot vad de flesta team förväntar sig. Det typiska generativa kostnadsreducerande draget är att "få modellen att säga mindre". Här finns det inget att säga mindre av.

TypeSafes egna siffror, som är leverantörsrapporterade och inte har replikerats oberoende, är direkt inriktade på den jämförelsen: "193,6x snabbare, 444,6x billigare", med fotnoten "baserat på arbetsflöden för System One-uppgifter (bevis)", med ett räkneexempel som lyder "TypeSafe AI kostnad 0,000081 USD slutfört på 0,114 s / LLM:er kostnad 0,013880 USD slutfört på 8,566 s." Hemsidan listar också "$42 per miljard indatatoken" mot "238x lägre indatapris än Claude Fable 5.1." Behandla allt som leverantörens argument, inte som ett uppmätt resultat: lanseringsinlägget medger att "våra publicerade utvärderingar i allmänhet körs från våra bärbara datorer på västkusten" och att "vi kan inte bevisa att det inte är subventionerat; vi behöver det långsiktiga för att bevisa hållbarheten i vår prissättning (som vi förväntar oss ska gå ner, inte upp)." Dessa två medgivanden är leverantörens egna, och de är rätt ram för varje multiplikator på sidan.

Kalibrering är den andra halvan av idén

Om kategorin vore "strukturerad utdata" skulle den beskriva funktionsanrop med extra steg. Det som gör den till något eget är att varje svar kommer med en sannolikhet, och sannolikheterna är träningsmålet. TypeSafe kallar metoden Reinforcement Learning for Calibrated Decisions (RLCD) – deras term, inte en generisk akronym – och jämförelsetabellen i lanseringen ställer den bredvid RLHF och RLVR: RLHF optimerar för vad mänskliga bedömare föredrar, RLVR för utdata som kan kontrolleras programmatiskt, och RLCD för "svar med epistemiskt ärliga sannolikheter på System One-uppgifter."

Den praktiska skillnaden ligger i vad sannolikheten är till för. I en generativ pipeline är konfidensskattningen en andra generering: du frågar modellen hur säker den är och den skriver ett tal, vilket i sig är prosa med samma felmoder. Här kommer sannolikheten tillbaka tillsammans med beslutet, i samma körning, och det är den man förgrenar på. TypeSafe:s egen formulering av nyttan är att en modell som kan utföra en uppgift 95 % av gångerna men ”inte säger till när den är i de 5 %” inte kan användas för att automatisera uppgiften; konfidensen ger dig en plats att lägga eskaleringen på, till en människa eller till en resonemangsmodell.

TypeSafe:s startsida anger detta som ”Noll hallucinationer” och förklarar att varje beslut bär en konfidensuppskattning så att mjukvara kan ”agera när konfidensen är hög och eskalera när den inte är det”. Läs det noga: det är ett påstående om konfidensuppskattningar, inte ett påstående att inget svar någonsin är fel. Vårt eget kort är motvikten — en felfrekvens på 0,49 % under de sju dagarna som slutade 2026-09-30, på vår trafik, mätt av oss. Den siffran är ett rullande fönster, inte en fast testmängd: den visade 0,57 % några dagar tidigare i samma fönster, och den kommer att röra sig igen.

Där System One sitter bredvid System Two

Vokabulären snabb/långsam är mycket äldre än TypeSafe. Den kommer från Kahnemans Tänka, snabbt och långsamt, och den har lånats av AI-forskare i många år före detta — etiketten "System 2" kopplades till chain-of-thought och modeller för överlagt resonemang långt innan TypeSafe existerade, och TypeSafe gör inte anspråk på att ha myntat någon av termerna. Vad de har gjort är att tillämpa distinktionen på en produktgräns snarare än på ett promptläge.

• En System Two-resonemangsmodell använder mer beräkningskraft innan den svarar och blir bättre på problem som kräver det. Dess utdata är fortfarande prosa, och den extra beräkningskraften faktureras som output-tokens.

• En System One-modell i TypeSafes bemärkelse tänker inte längre för att svara bättre. Den svarar i ett enda pass, och det den ger upp för hastighetens skull är förmågan att producera något annat än ett typat värde.

• De två är komplement i ett arbetsflöde, inte rivaler i en jämförelse. Ett System One-anrop hanterar de beslut som måste vara snabba, billiga och begripliga; resonemangsmodellen får de fall som konfidenspoängen flaggade som osäkra. Den typade utdatan är det som gör överlämningen ren — du skickar ett värde och en sannolikhet till nästa steg, inte en mening som måste tolkas på nytt.

Det är när man behandlar ”System One-modellen” som en etablerad kategori som andra leverantörer har anammat som vokabulären blir halkig. Det finns inga belägg för det, och den här sidan bör inte läsas som att den påstår det. TypeSafe använder termen för sin egen modellklass; ansvarsfriskrivningen i vårt eget kort säger samma sak genom utelämnande, eftersom den listar en enda endpoint-typ för en enda modell. Om ett annat labb börjar använda frasen för samma arkitektur kommer det att vara ett faktum värt att rapportera, och det kommer att behöva deras egna ord för att rapportera det.

Vårt kort listar också ojämnhet som en del av den ärliga gränsen snarare än som en överraskning: nio namngivna felmoder. Posterna för bokstavlig läsning och indirektion är de som följer direkt från analogin "mer som kod" – en modell som svarar på frågan du skrev snarare än den du menade beter sig som en funktion som gjorde exakt vad koden sa. Det gör inte posten för räkning. En modell som "känner igen formen på ett svar snarare än att räkna samman" är inte alls kodlik, vilket är anledningen till att TypeSafe:s egen rekommendation är att räkna i kod och, när en bedömning verkligen behövs, ställa en fråga per objekt och själv lägga ihop svaren.

Två gränser som formar designen, inte poängen

Båda kommer från samma ställe: inga strängar innebär inget att strömma och inget att skicka i bitar.

• Icke-strömmande — den första utdatan är det färdiga svaret, så ett System One-anrop är ett enda svar, inte en ström. Frågan är inte huruvida det kan strömma utan vad som skulle strömma.

• Ett anropsformat – modellen exponeras via POST /v1/systemone i vår katalog i stället för chat-completions-formatet, och det är den ärliga versionen av ett äldre påstående att den "talar sitt eget anropsformat". Det är en verklig skillnad i hur du anropar den: ett tillståndsobjekt och en karta med namngivna frågor matas in; ett strukturerat svar per fråga kommer ut. Du kommer att skriva en mappare för den, och eftersom utdata är typad är mapparen hela integrationen – det finns inget defensivt parsningslager under den.

Värt att veta innan du gör belastningstester: latensen är inte konstant över frågetyper. TypeSafe förklarar varför, i deras egna ord – ”För val med högre kardinalitet använder vi ett tvåstegssystem där vi poängsätter oberoende och sedan fattar ett explicit val, därav den ibland förekommande fördröjningen.” Ett routningsbeslut med 4 alternativ och en klassificering med 200 alternativ är samma primitiv på pappret och olika mycket arbete i praktiken. Våra dagliga medianvärden under de sju dagarna fram till och med 2026-09-30 ligger på 175, 170, 163, 161, 170, 147, 143 ms. En dag i den serien, 2026-09-28, hade en p95 på 2 448 ms – en verklig utliggare för en enskild dag som ärligt ingår i serien, men som inte är representativ för tjänsten.

Det andra att känna till inför en första integration är vad du ansluter till. Verktygen kring Jev är öppen källkod under MIT- och Apache-2.0-licenser – Python- och JavaScript-SDK:erna, en adapter som presenterar samma klient med vanliga LLM-API:er som bakomliggande, koden för workflow-evals och en uppsättning agentfärdigheter, allt i TypeSafes offentliga repositorier, med stjärnantal och push-datum som ändrades så sent som 2026-09-26 och 2026-09-29. Modellen är det inte. Det finns inget viktrepositorium: Jevs arkitektur, parameterantal, träningsberäkning och vikter är opublicerade, och en läsare som kontrollerar detta bör inte vilseledas av de tre repositorierna i den organisationen som är forks av orelaterade projekt – en vLLM-fork, en diffusion-language-model-släpp från 2025 och en Pulumi-provider. Ingen av dem säger något om hur Jev är byggd. Svaret i en rad är att verktygen är öppna och modellen inte.

Att köra det i dag, och vad som förändras för en läsare

Jev 1.13 finns på OrcaRouter som typesafe/jev-1.13, nås med samma nyckel som 200+ andra modeller, med leverantörens listpris vidarebefordrat med 0 % påslag. Det praktiska värdet av det på en sida om en kategori är smalt och värt att säga exakt: att prova en System One-modell kräver inte längre ett separat konto, en separat nyckel och en separat faktura för en modell som du kanske ännu inte vet att du vill ha. Den står bredvid den generativa halvan av samma arbetsflöde – klassificeraren och skribenten på en och samma autentiseringsuppgift, på ett och samma ställe, med antalsuppgifterna för vad du faktiskt anropade.

Ingenting här ändrar vad modellen är. Det lanserades den 15 september 2026 och TypeSafe beskriver det fortfarande som tidig åtkomst; vad det är har inte förändrats sedan dess. Det som förändrades den 24 september 2026 är att en läsare nu kan ta reda på vad det kostar denne i praktiken utan att först binda sig till en relation med en andra leverantör. Om du har väntat på att se om kategorin är värd en prototyp, är det den saken som har förändrats.