Jev 1.13 förklarad: Varför modellen svarar i {{1}}stället{{/1}} för meningar

Jev 1.13 (typesafe/jev-1.13) är inte en chattmodell, och det snabbaste sättet att förstå den är att sluta läsa dess specifikationsblad som du läser alla andra. TypeSafe släppte den 2026-09-15 som den första medlemmen i en klass som företaget kallar System One-modeller: du ger den en bit tillstånd och en uppsättning namngivna frågor, och den lämnar tillbaka ett typat svar per fråga – en etikett från en lista du angav, en nivå på en skala du definierade, eller ett sant/falskt med en tillhörande sannolikhet. Ingen prosa, ingen kod, ingen förklaring. Det här är ingen lanseringsartikel. Själva modellen är från 2026-09-15, femton dagar gammal och utanför det sjudagarsfönster som den här bloggen skriver om, så den förtjänar ingen sida för sin egen lansering. Det som hände inom fönstret är att OrcaRouter lade till typesafe/jev-1.13 i sin egen 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 Jev går att anropa via en tredjepartsgateway i stället för bara via TypeSafes egen endpoint, och den första live-datan om serving som någon utanför TypeSafe har publicerat om den. Det är förändringen som är värd att läsa om: modellen blev körbar där den inte var det.

Den praktiska formen av den förändringen är liten och specifik. Före 2026-09-24 innebar att införa Jev en andra leverantörsrelation — ett TypeSafe-konto, en TypeSafe-nyckel, en TypeSafe-faktura och en skräddarsydd förfrågningsform att skriva mot. Efter det ligger Jev på samma nyckel som resten av stacken: ett API för 200+ modeller, 0 % påslag (leverantörens listpris förs vidare, så leverantörens prissänkningar är live här samma dag), och modellen nås på typesafe/jev-1.13 via POST /v1/systemone. Du anropar fortfarande den i dess egen form — endpointen är inte OpenAI:s chat-completions-rutt, och att låtsas något annat skulle ge en 404 i stället för ett beslut — men kontraktet du signerar och nyckeln du roterar är desamma som du redan har.

Vilken typ av modell är Jev?

TypeSafe:s lanseringsinlägg säger det i en mening: "Vår första offentliga modell är Jev, tillgänglig i dag i early access." Inlägget beskriver sedan modellen som "ett funktionsanrop för frontier-intelligens: ostrukturerat tillstånd in, typade probabilistiska beslut ut." Det är en rimlig beskrivning av gränssnittet, och en viktig sådan, eftersom nästan varje felaktig förväntan på Jev kommer från att utvärdera den som en liten språkmodell. Den är inte en liten språkmodell. Den är en beslutsmodell med en fast utdatagrammatik, och grammatiken är produkten.

Gränssnittet har exakt två indata. Tillståndet är materialet som ska bedömas: ett e-postmeddelande, ett supportärende, en logglinje, en JSON-post, en array av spelkoordinater. Frågorna är en karta över namngivna poster, där var och en bär en typ, sina egna instruktioner och — för de två strukturerade typerna — sina kriterier. Varje fråga utvärderas mot samma tillstånd, och svaren kommer tillbaka som en enda strukturerad JSON-payload. TypeSafe:s dokumentation beskriver att frågorna körs samtidigt och oberoende av varandra, och gör två påståenden som följer av själva designen snarare än av trimning: att lägga till frågor förändrar knappt svarstiden, och att lägga till frågor skapar inte context rot, eftersom varje fråga bedöms isolerat i stället för nedströms de föregående.

TypeSafe:s egen designvägledning är värd att upprepa eftersom den är det tydligaste uttalandet om vad modellen är till för. Håll varje fråga atomär och väl avgränsad – "den typ av bedömning som en mycket kunnig person skulle kunna göra på några sekunder." Om ett beslut kräver utdraget resonemang eller verkligen kombinerar flera oberoende faktorer, dela upp det i separata frågor och kombinera dem igen i din egen kod. Deras exempel: i stället för en enda "betygsätt den här startup-pitchen"-prompt, fråga separat om marknadsstorlek, teknisk genomförbarhet och differentiering, och tillämpa sedan din egen viktning. Anledningen till att det spelar roll är att viktningen då ligger i en koefficient du kan ändra, i stället för i en prompt du måste skriva om.

Modellen är sluten i alla avseenden som har betydelse för en ingenjör som resonerar om risk. Jevs arkitektur, parameterantal, träningsberäkningskraft och vikter är opublicerade. Det finns inget repo för modellvikter i TypeSafe GitHub-organisationen – de elva offentliga reporna där är verktyg, SDK:er, arbetsflöden och tre orelaterade forks, och ingen av dem är modellen.

"Typed" är hela produkten

OrcaRouter-modellkortet publicerar de tre primitiverna och, viktigast av allt, gränserna för var och en. Varje fråga du ställer till Jev är en av exakt tre former:

• noul — en bedömning av sant/falskt, som returneras med en kalibrerad sannolikhet i stället för ett rent booleskt värde, så att "troligen sant" och "säkert sant" är åtskiljbara värden.

• choice — välj ett av upp till 255 märkta alternativ, där varje alternativ har sin egen kriterietext så att modellen vet vad som skiljer dina etiketter åt.

• poängsättning — bedöm på en ordnad skala med 2–10 nivåer, där nivådefinitionerna tillhandahålls som kriterier.

Konsekvensen av den begränsningen är att det inte finns något att parsa ut ur prosa och inget att validera mot ett schema som du hoppades att modellen följde. TypeSafe:s lanseringsinlägg är ovanligt rakt på sak om garantin: siffran "0%" för schemaavvikelse i deras diagram "är inte empirisk. Schemamatchning är garanterad, därför kan vi med säkerhet lägga till 0% i diagrammen." När din svarsrymd är en sluten mängd som du tillhandahållit, är ett returnerat värde antingen i mängden eller så kom det inte från modellen — det finns inget tredje utfall där modellen skrev något rimligt i fel form och din regex tyst accepterade det.

De tre typerna är också anledningen till att en granskare inte kan utvärdera Jev på samma sätt som man utvärderar en chattmodell. Det finns inget MMLU-Pro-resultat att jämföra, inget skrivprov att läsa, inget resonemangsspår att inspektera. Den enda fråga som har någon betydelse är om det typade svaret är rätt och om sannolikheten som är kopplad till det är ärlig. Båda dessa är mätbara, men bara mot dina data och dina etiketter.

En dokumenterad skillnad är värd att flagga snarare än att lösa: TypeSafe:s egen dokumentation visar ett Score-exempel som indexeras från noll, medan OrcaRouter-kortet anger skalan som 2–10 nivåer. Leverantören dokumenterar nivåer; vårt kort anger 2–10. Om du bygger en bedömningsmall ovanpå Score bör du läsa nivådefinitionerna i ditt eget svar i stället för att anta ett index.

Varför det inte finns några utdatatokens att fakturera

Prissättningen är det renaste uttrycket för arkitekturen. Jev kostar $0.042 per miljon indatatokens på OrcaRouter, och priset för utdata är $0.000000 per miljon — inte en rabatt, inte ett lanseringserbjudande, utan frånvaron av en mätbar kvantitet. En generativ modell faktureras för texten den skriver; Jev skriver ingen text. Den returnerar en etikett, en nivå och en sannolikhet. Det finns inget att räkna på utdatasidan, så inget debiteras där.

TypeSafe anger samma siffra från andra hållet på sin startsida – "$42 per miljard indatatoken" – och kopplar ett jämförelsepåstående till den: "238x lägre indatapris än Claude Fable 5.1". Den jämförelsen är, liksom allt annat på startsidan, leverantörens egen och har inte replikerats av någon. Men aritmetiken som den vilar på är lätt för en läsare att kontrollera mot sin egen faktura, vilket är den användbara delen. Volymen i en beslutsarbetsbelastning bestäms nästan helt av hur mycket tillstånd du matar in, och tillstånd är billigt på ett sätt som genererade tokens inte är.

Leverantörens rubriksiffror är större än prisraden och förtjänar samma märkning. TypeSafe annonserar "193,6x snabbare, 444,6x billigare" med en fotnot som begränsar det till "arbetsflöden för System One-uppgifter", och publicerar ett uträknat exempel under det: TypeSafe AI till $0,000081 slutfört på 0,114s mot LLM:er till $0,013880 slutfört på 8,566s. Själva lanseringsinlägget medger risken med inramningen — 193,6x och 444,6x beskrivs som att de sannolikt ligger "i den högre ändan av verkliga vinster" — och noterar att sida-vid-sida-demon använde en "högst förenklad" fråga med människoläsbara nycklar valda av leverantören för att "måla upp vår modell i en fördelaktig dager." Ingen av dessa siffror har oberoende replikerats, och leverantörens eget benchmark-kort är fortfarande markerat som väntande.

Vad ”calibrated” betyder, och vad RLCD är

TypeSafe namnger själva sin träningsmetod: "Reinforcement Learning for Calibrated Decisions (RLCD)". RLCD är TypeSafes egen term, inte en allmän maskininlärningsakronym som är äldre än företaget, och dess optimeringsmål anges i lanseringsinläggets jämförelsetabell som "kalibrerade beslut: svar med epistemiskt ärliga sannolikheter på System One-uppgifter." Kontrasten som samma tabell drar är mot RLHF, som optimerar för mänsklig preferens – skrivna svar och chattsvar som bedömare gillar – och RLVR, som optimerar för utdata som kan verifieras programmatiskt. RLCD optimerar för en tredje sak: sannolikheten som knyts till att ett svar är ett korrekt påstående om modellens egen osäkerhet.

I praktiken är "kalibrerad" ett påstående om konfidensvärdena, inte en garanti för att svaren är korrekta. En kalibrerad modell som säger 0,8 på en uppsättning frågor bör ha rätt ungefär 80 % av gångerna över den uppsättningen; den kan fortfarande ha fel på en enskild fråga. Den åtskillnaden är det ärliga sättet att läsa TypeSafe:s rad på startsidan: "Noll hallucinationer — Varje Jev-beslut kommer med en konfidensuppskattning, så din programvara kan agera när konfidensen är hög och eskalera när den inte är det." Det är ett påstående om en konfidensuppskattning, inte ett bevis på noll fel, och motvikten är våra egna data: under de sju dagar som slutade 2026-09-30 mäter vårt kort en felfrekvens på 0,49 % på Jev-trafik genom OrcaRouter — en siffra som låg på 0,57 % tidigare i samma fönster, eftersom den beräknas över rullande sju dagar av livetrafik från playground snarare än en fast testuppsättning. Båda fakta hör hemma i samma stycke: konfidensvärdena är själva poängen med modellen, och modellen misslyckas fortfarande med ungefär ett anrop av tvåhundra i vår trafik.

Kalibreringshistorien förklarar också ett latensbeteende som annars skulle se ut som en bugg. TypeSafe skriver i sitt lanseringsinlägg: "För val med högre kardinalitet använder vi ett tvåstegssystem där vi poängsätter oberoende och sedan gör ett uttryckligt val, därav den ibland förekommande fördröjningen." Ett val med 255 alternativ är inte en enda framåtriktad jämförelse; leverantören poängsätter och väljer sedan. Om du ser att en begäran mot en stor etikettuppsättning tar märkbart längre tid än en noul, är det den dokumenterade mekanismen, inte överbelastning.

Vad kallar du det idag

På OrcaRouter är modellen typesafe/jev-1.13, med namnet "TypeSafe: Jev 1.13" i katalogen, med en context_length på 65 536 tokens och exakt en enda ändpunktstyp som stöds: systemone. Du anropar den med POST /v1/systemone med din OrcaRouter-nyckel, och skickar ett model-fält, ett state-fält (sträng, objekt eller array) samt en questions-map där varje post har en type (noul, choice eller score), dess instructions och dess criteria. Svar är en enda strukturerad JSON-payload och streamas inte — det finns inget streamingläge att välja.

Kortets egen formulering av kontraktet är "text in, strukturerad JSON ut", och de publicerade gränserna är de man ska designa mot: icke-strömmande, upp till ungefär 64K indatatoken över det kombinerade tillståndet och frågorna, där förfrågningar över den gränsen avvisas innan de når modellen. Katalogposten anger listpriset till 0,042 USD per miljon indatatoken och visar slutförandefrekvensen som noll. Det är leverantörens siffror som återges oförändrade – den proportionella formen av hur vi prissätter: 0 % påslag på leverantörens listpriser.

Två tokenbudgetar cirkulerar för den här modellen och de står inte i konflikt med varandra, så håll dem åtskilda. Siffran 65 536 är kortets context_length och dokumenteras som ungefär 64K indata sammanlagt över tillstånd plus frågor. De ”ungefär 32 000 tokens” som tidigare OrcaRouter-artiklar anger är enbart tillståndsbudgeten – utrymmet som ditt material får innan frågorna tar sin del. Om du budgeterar en förfrågan är tillståndsbudgeten det tal som begränsar den nyttolast du bygger; den sammanlagda siffran är taket för hela anropet.

Vad Jev inte kan göra, sagt rakt ut

Den kan inte skriva prosa, sammanfatta, översätta eller föra samtal. Det är själva designen, inte en begränsning att be om ursäkt för: lanseringsinlägget säger att Jev "avstår från stränggenerering", och TypeSafes egen sida om taggighet listar "Generering" som ett namngivet felläge med instruktionen "Använd en generativ modell" bredvid. Påtvingad generering är långsam och dålig. Om din pipeline behöver en skriven sammanfattning är Jev fel komponent, och ingen mängd promptkonst förändrar det.

Det är inte en ersättning för en generativ modell. Arbetsflödet som Jev tillhör innehåller två modeller: en generativ som läser, skriver och resonerar i text, och Jev som sitter bredvid och gör de typade anropen på millisekunder. Det är det ärliga sättet att beskriva varje kostnadsjämförelse på leverantörens startsida – kolumnen "LLMs" är inte en konkurrent som trängs undan, den är den andra halvan av samma system, och anledningen till att parkopplingen är intressant är att beslutsdelen nu ligger på samma nyckel som den generativa delen i stället för bakom sitt eget avtal.

Och "kalibrerad" betyder inte korrekt. Det betyder att siffran som är kopplad till ett svar är avsedd att kunna läsas som en sannolikhet. En 0,62 på en noul är modellens sätt att säga att den inte är säker, vilket är användbar information som ett enkelt ja/nej skulle ha förstört — och det är inte ett löfte om att jaet är rätt. Eskaleringslogik byggd på konfidensen är det avsedda mönstret; att behandla svaret som facit är det inte.

Att läsa siffrorna ärligt

Varje prestandasiffra på vårt kort kommer från vår egen trafik genom OrcaRouters playground under ett rullande sjudagarsfönster, inte från leverantörens benchmark, och fönstret försköts medan den här texten skrevs – behandla det som en avläsning, inte en specifikation. För de sju dagarna som slutade 2026-09-30: mediantid till första token 151 ms, p95 247 ms, utdatagenomströmning på omkring 349 tokens per sekund, felfrekvens 0,49 % och 76,2 miljoner serverade tokens. Daglig p50 över fönstret ligger på 175, 170, 163, 161, 170, 147 och 143 ms – en linje som långsamt förbättras. p95 för 09-28 på 2 448 ms är en äkta avvikelse för en enskild dag som ligger i den serien, och att citera den som normen skulle vara fel på samma sätt som att helt utesluta den skulle vara oärligt.

Ytterligare en varning om trafiksiffran: 349 utdatatoken per sekund låter som genomströmningen hos en generativ modell, tills man kommer ihåg att Jev inte producerar någon genererad text. Mätaren mäter vad vår playground än räknar på svarsidan för en strukturerad nyttolast, och den är användbar för att upptäcka försämring mellan dagar snarare än för att jämföra Jev med en chattmodell.

Det där är våra siffror. Leverantörens siffror är 193,6x, 444,6x, det genomräknade exemplet på $0,000081 och 238x-jämförelsen mot Claude Fable 5.1 – alla är TypeSafes egna, ingen av dem har replikerats oberoende, och alla begränsas av deras egna fotnoter specifikt till System One-arbetsflöden. Det enda prestandapåståendet som TypeSafe gör som inte alls är ett benchmark, och som är värt mer än multiplikatorerna, är ett strukturellt sådant: eftersom svaren är typade har integrationen inget parsningssteg och inget schemavalideringssteg, och det är en kostnad som inte syns i någon latens-tabell.

Vad är öppet, och vad är inte det?

Vid kontroll 2026-09-30 hade TypeSafe GitHub-organisationen publicerat elva repositorier. Inget av dem innehåller Jev. De som är viktiga för en utvecklare som integrerar modellen är alla MIT eller Apache-2.0: skills (MIT), system-one-adapter-python (MIT, beskrivet som en "drop-in-ersättning för TypeSafeClient som drivs av LLM-API:er"), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, med arbetsflödeskod publicerad på evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io och pulumi-clickhouse. Stjärnantal och push-datum ändras, så om du läser detta senare bör du kontrollera igen i stället för att lita på listan.

Tre av de elva är forks av orelaterade projekt och bevisar ingenting om hur Jev fungerar: en vLLM-fork som senast pushades i maj 2025, en LLaDA-fork från juni 2025 – LLaDA är ett orelaterat släpp av en diffusionsspråkmodell – och en Pulumi-provider för ClickHouse Cloud. Det är frestande att läsa ut arkitektur ur en fork-lista. Gör inte det: ingenting om Jevs design följer av de tre, och i synnerhet är Jev inte en diffusionsmodell, hur mycket närvaron av en LLaDA-fork än kan antyda det.

Det ärliga enradssvaret på frågan ”är Jev öppen källkod” är att verktygen är öppna och modellen inte är det. Det är ett normalt upplägg för en hostad frontiermodell, och det är upplägget du bör utgå från när du planerar kring Jev: ett API med ett publicerat pris, ett dokumenterat kontrakt och ett opublicerat antal parametrar.

Där leverantören säger att Jev är opålitlig

TypeSafe publicerar sin egen jaggedness-sida för jev-1.13, senast granskad 2026-09-17, som namnger var modellen brister. Den är ovanligt uppriktig och det är rätt plats att börja ett avsnitt om begränsningar, eftersom det är leverantörens egen lista snarare än en konkurrents:

• Bokstavlig tolkning – den tar ordalydelsen bokstavligt. Man drar inga slutsatser om avgränsande ord, negationer och underförstådda villkor; den "svarar på frågan du skrev, inte den du menade." Leverantörens lösning är att skriva det exakta villkoret och kriterierna för varje alternativ.

• Matematik och tal — det är inte en miniräknare, och det räknar inte tillförlitligt. Håll aritmetiken i kod.

• Jämförelse av datum och tid — datum läses som text, inte som ordnade kvantiteter, så ordning, luckor och fönster är opålitliga, värre med blandade format.

• Indirektion — dubbla negationer och flerledsresonemang minskar noggrannheten. Minska antalet led och peka på relevant tillstånd.

• Ett stort tillstånd fullt av irrelevanta detaljer — orelaterat innehåll fungerar som en distraktor och noggrannheten sjunker när tillståndet växer. Filtrera först.

• Adversariellt innehåll — tillståndet behandlas inte som fientligt, så injicerade instruktioner eller vilseledande inramning kan ändra svar.

• Motstridiga instruktioner och kriterier — när de två ber om olika saker kan modellen ”kan bli förvirrad”.

• Strukturella invarianter för sunt förnuft — P(noul) och 1 − P(inte noul) garanteras inte vara konsistenta. Fråga varje beslut åt ett håll och upprätthåll identiteter i kod.

• Generering — redan avhandlat, och leverantörens egen rekommendation är att använda en generativ modell.

Två av dessa förtjänar att framhållas. Den adversariella är viktig eftersom Jevs hela värdeerbjudande är att bedöma otillförlitligt material, och ett tillstånd som innehåller instruktioner kan förändra ett svar; om ditt tillstånd kommer från användare är det en yta för prompt-injektion med samma form som vilken annan som helst. Den om strukturella invarianter är viktig eftersom en "kalibrerad" modell inbjuder dig att räkna på dess sannolikheter, och leverantören säger åt dig att inte anta att aritmetiken går ihop.

Vad lanseringsinlägget förbinder sig till, och vad det inte gör

Nästan varje leverantörspåstående som citeras i den här artikeln går tillbaka till en enda sida: TypeSafe's eget tillkännagivande, arkiverat under Company News och daterat 2026-09-15, undertecknat av grundaren Diogo Almeida. Att läsa det direkt är värt de två minuterna, eftersom formuleringen av en rad sätter villkoren för allt sedan dess. ”Vår första offentliga modell är Jev, tillgänglig idag i tidig åtkomst.” Tidig åtkomst är leverantörens egen beskrivning av tillgänglighet på leverantörens egen plattform, och det är ett snävare uttalande än det ser ut — det förbinder TypeSafe att tillhandahålla modellen till godkända användare, och säger ingenting om vem andra får tillhandahålla den. Det är precis den lucka som tillägget i katalogen 2026-09-24 stängde, och anledningen till att modellkortet betyder mer än inlägget för alla som utvärderar Jev idag.

Samma sida är lika tydlig om sina egna gränser, vilket är anledningen till att den citeras i stället för att återges med egna ord ovan. Den publicerar inget parameterantal, ingen arkitekturbeskrivning utöver "en ny modellarkitektur", ingen träningsberäkningskapacitet och inget viktrepositorium, och den anger inget datum eller villkor för allmän tillgänglighet. Dessa luckor är planeringsrestriktionerna: ett API med ett publicerat pris på ena sidan, och en stack vars interna delar du inte kan inspektera på den andra. Inlägget beskriver också modellen tillräckligt ärligt för att vara användbart som en specifikation – "ett funktionsanrop för frontier-intelligens: ostrukturerat tillstånd in, typade probabilistiska beslut ut" – vilket är den enda meningen i det som beskriver gränssnittet snarare än ambitionen.

Frågor som detta gränssnitt väcker

Vad händer när en valuppsättning är större än 255 alternativ? Den begränsas – 255 märkta alternativ är taket för en valfråga, och leverantörens tvåstegsmetod med poängsättning följt av val är vad som görs när kardinaliteten ökar, vilket också är den dokumenterade orsaken till tillfälliga fördröjningar vid stora etikettuppsättningar. Om din taxonomi är större än så är svaret i designen att dela upp den i flera frågor och slå samman dem igen i kod, vilket är samma råd som TypeSafe ger för sammansatta bedömningar.

Innebär kontexten på 65 536 token att 65 536 token utgörs av tillstånd? Nej. Den publicerade budgeten är ungefär 64K token sammanlagt för tillståndet och alla frågor, och siffran ”ungefär 32 000 token” som förekommer i äldre rapportering är enbart tillståndsbudgeten. Budgetera din nyttolast mot tillståndssiffran, inte mot den kombinerade, och kom ihåg att förfrågningar över gränsen avvisas innan de når modellen.

Vad ska man göra med detta

Jev 1.13 är värd en titt av en specifik anledning, inte av en allmän. Om du har ett steg i din pipeline som för närvarande är en chattmodell som ombeds returnera en etikett och som man litar på returnerar den i rätt form – en router, en bedömare, en policykontroll, en bedömningspoäng som tillämpas på tusentals poster – är det steget vad den här modellen ersätter, till $0.042 per miljon indatatoken utan något som mäts på utdatasidan. Om du har ett steg som behöver ett skriftligt svar är Jev inte verktyget, och det säger dess egen leverantör.

Det som förändrades den senaste veckan är inte modellen. Det är att det inte längre krävs en andra leverantörsrelation för att testa den. För åtta dagar sedan innebar en Jev-utvärdering ett separat konto och en separat integration; idag är det ett enda modell-id på en nyckel som redan når över 200 modeller, med leverantörens listpris vidarebefordrat oförändrat och de typade svaren som kommer tillbaka från samma ställe som allt annat. För en modell så här ovanlig utgör möjligheten att testa den mot dina egna etiketter utan att binda sig till ett nytt avtal större delen av beslutet.