Är Jev öppen källkod? Vikterna är stängda, verktygen är det inte

Nej. Jev 1.13 (typesafe/jev-1.13) är inte öppen källkod, det finns inget viktrepositorium att hitta, och hur mycket man än scrollar genom TypeSafes GitHub-organisation kommer man inte att hitta en checkpoint, ett arkitekturdokument eller ett parameterantal. Det som finns är mjukvaran runt modellen: elva offentliga repositorier, vart och ett under MIT eller Apache-2.0, inget av dem innehåller Jev självt. Det är det ärliga enradssvaret — verktygen är öppna, modellen är inte — och det är den halva av historien som en läsare aldrig får enbart från "stängd, hostad, opublicerad". Två datum ramar in det. TypeSafe släppte modellen den 2026-09-15, vilket ligger utanför det sjudagarsfönster som den här bloggen skriver till, så detta är inte ett lanseringsinlägg och inget i det bör läsas som ett. Den daterade händelsen är 2026-09-24, när OrcaRouter lade till typesafe/jev-1.13 i sin egen katalog: första gången Jev har kunnat anropas via en tredjepartsgateway i stället för bara via TypeSafes egen endpoint. Det är undantaget som den här sidan bygger på — en modell som blev körbar där den inte var det.

Vad det förändrar för en läsare är begränsat och praktiskt. Före 2026-09-24 innebar utvärdering av Jev att öppna en andra leverantörsrelation innan du kunde testa ett enda beslut. Efter det ligger Jev på samma nyckel som den generativa halvan av samma arbetsflöde: ett API för 200+ modeller, 0 % påslag (leverantörens listpris förs vidare, så leverantörens prissänkningar slår igenom här samma dag), med modellen nåbar på typesafe/jev-1. Du anropar fortfarande det i sin egen form — POST /v1/systemone, icke-strömmande — eftersom det inte är OpenAI chat-completions-vägen, men kontraktet du tecknar och nyckeln du roterar är desamma som du redan har.

Svaret är två svar, och båda behövs

”Är Jev öppen källkod?” låter som en ja/nej-fråga och beter sig som en tvådelad sådan. Del ett: modellen. Den är stängd. TypeSafe har inte publicerat några vikter, ingen arkitektur, ingen uppgift om beräkningskraft för träning och inget parameterantal för Jev 1.13, och det finns inget repo som är uppkallat efter den. Del två: den omgivande mjukvaran. Den är öppen, aktivt underhållen och verkligen användbar, och det är anledningen till att en läsare som söker efter ett repo inte helt saknar tur.

Att förväxla de två ger felaktig slutsats i båda riktningarna. Anta att det hela är öppet och du kommer att tillbringa en eftermiddag med att leta efter en kontrollpunkt som inte finns. Anta att det hela är stängt och du kommer att missa den del som faktiskt spelar roll om du är orolig för inlåsning — en MIT-licensierad adapter som låter dig bygga mot det typade beslutsgränssnittet och ändra vad som ligger bakom det.

Vad TypeSafe faktiskt publicerar

Avläst den 30 september 2026 har organisationen elva offentliga repositorier. Stjärnantal och pushdatum ändras, så betrakta detta som en ögonblicksbild snarare än en fast egenskap hos projektet. Varje licens är MIT eller Apache-2.0 om inget annat anges.

• skills — MIT, ungefär 2,4k stjärnor, senast pushad 2026-09-12. "Agentfärdigheter för att bygga med TypeSafe's System One API."

• system-one-adapter-python — MIT, 356 stjärnor, senast pushad 2026-09-22. "Drop-in-ersättning för TypeSafeClient som drivs av LLM-API:er."

typesafe-sdk-js — MIT, 257 stjärnor, senast pushad 2026-09-15. Det officiella TypeScript/JavaScript-biblioteket för TypeSafe API.

• typesafe-sdk-python — MIT, 254 stjärnor, senast pushad 2026-09-26. Det officiella Python-biblioteket; v0.7.2 lade till ett `http2`-extra den dagen, och v0.7.1 den 2026-09-21 lade till exempel för användning med AI-gateways.

• daggerverse — Apache-2.0, 23 stjärnor, senast pushad 2026-09-25. En samling Dagger-moduler.

• WorkflowEvals — Apache-2.0, 7 stjärnor, senast pushad 2026-09-29. "evals.typesafe.ai arbetsflödeskod publicerad."

• n8n-nodes-typesafe-ai — MIT, 1 stjärna, senast pushad 2026-09-29.

• typesafe-ai.github.io — ingen licens angiven, 2 stjärnor, senast pushad 2026-06-04.

Ytterligare tre är forks av orelaterade projekt och behandlas nedan: pulumi-clickhouse, LLaDA och vllm.

Ingenting i den listan är modellen. Det finns inget Jev-repository, inga viktfiler, ingen tokenizer, ingen serveringskonfiguration – ingenting som skulle låta dig sätta upp en fungerande kopia. Repona är klientsidig inredning: två officiella SDK:er, ett agent-skills-paket, en CI-modulsamling, en publicerad eval-svit, en n8n-nod, org-webbplatsen och adaptern. Det är en verklig och välunderhållen yta, och det är inte modellen.

Det enda kodförrådet som spelar roll om du försöker undvika inlåsning

system-one-adapter-python är posten med störst konsekvens för alla som fattar ett införandebeslut, och dess egen beskrivning säger själva poängen: en "Drop-in-ersättare för TypeSafeClient som drivs av LLM-API:er."

Läs det noggrant, för det gör något specifikt. Den varaktiga tillgången i en System One-integration är gränssnittet, inte slutpunkten bakom det: du definierar en bit tillstånd och en uppsättning namngivna frågor, och något returnerar ett typbestämt svar per fråga. Det kontraktet är vad din kodbas i slutändan formas kring. Adaptern frikopplar kontraktet från implementationen — du fortsätter bygga mot det typbestämda beslutsgränssnittet, och det som producerar besluten är ett utbytbart LLM API-anrop under ytan.

Två ärliga förbehåll. En adapter är inte modellen: svar som produceras av en allmän LLM via den här vägen är inte de kalibrerade sannolikheter som Jev returnerar, så det är ett sätt att hålla gränssnittet portabelt, inte ett sätt att få Jevs beteende utan Jev. Och det är uttryckligen ett TypeSafe-projekt – nödutgången byggs av den leverantör du kanske vill fly från, vilket är bättre än inget och inte samma sak som en oberoende sådan.

De två förgreningarna, och den slutledning de inbjuder till

Tre av de elva repon är forks. pulumi-clickhouse är en Pulumi-provider för ClickHouse Cloud, Apache-2.0, 3 stjärnor, senast pushad 2026-07-08. De andra två är de som läses som bevis, och båda tolkningarna är fel.

• vllm — Apache-2.0, 3 stjärnor, senast pushad 2025-05-23. En fork av motorn för inferens och serving med hög genomströmning.

• LLaDA — MIT, 12 stjärnor, senast pushad 2025-06-17. En fork av den officiella PyTorch-implementationen av "Large Language Diffusion Models."

Den lata slutledningen skriver sig själv: de har forkat ett repo för en diffusionsspråkmodell, så Jev måste vara diffusionsbaserat. Det är det inte, och forken säger dig ingenting om Jevs arkitektur. En fork är en kopia av någon annans kod under någon annans licens, som ligger i en organisation av skäl som dess eget senaste push-datum gör uppenbara — maj och juni 2025, mer än ett år innan Jev släpptes offentligt, och orörd sedan dess. Inget av repona är en del av det som TypeSafe släppte i september. Om du vill veta hur Jev fungerar har TypeSafe inte publicerat det, och ingen fork i deras organisation fyller luckan.

Vad det faktiskt kostar dig att stänga vikterna

Fyra saker, och de är konkreta snarare än filosofiska.

• Du kan inte självhosta. Det finns ingen artefakt att köra, så ett leverantörsavbrott eller en åtkomständring är inget du kan kringgå genom att sätta upp en egen kopia.

• Du kan inte granska. TypeSafe publicerar visserligen en sida om ojämnheter för Jev 1.13 – senast granskad 2026-09-17 – som pekar ut var modellen är opålitlig: bokstavlig läsning av ordalydelse framför avsikt, allt som involverar aritmetik, jämförelse av datum och tid, indirektion och dubbla negationer, stora tillstånd fulla av irrelevanta detaljer, adversariellt innehåll i tillståndet, motstridiga instruktioner och kriterier, och strukturella invarianter som den inte garanterar, såsom att ett sant/falskt-svar och dess motsvarande ja/nej-val säger emot varandra. Den sidan är ovanligt uppriktig, och det är fortfarande leverantören som rättar sin egen läxa. Ingen utanför TypeSafe har inspekterat vikterna.

• Du kan inte finjustera. Det finns ingen basmodell att anpassa, så en beslutsuppgift som Jev hanterar dåligt förblir dåligt hanterad tills leverantören ändrar den — sidan om ojämnhetens egna åtgärder är workarounds i din kod, inte träningskörningar.

• Du kan inte låsa en version bortom leverantörens alias. typesafe/jev-1.13 är ett hostat namn, så det som svarar på ett anrop nästa månad är vad TypeSafe än serverar under det namnet då.

Inget av det är unikt för Jev och inget av det är en skandal; det är den avvägning som en hostad beslutsmodell gör, och motvikten är att du aldrig behöver släpa på en checkpoint, en GPU-nota eller en inferensstack. Det är värt att veta vilken sida av avvägningen du står på innan du bygger vidare på den.

Vad Jev är, nu när du kan anropa det

Jev är inte en chattmodell och genererar inte prosa. Du skickar ett tillstånd — materialet som ska bedömas, som text, ett objekt eller en array — plus en uppsättning namngivna frågor, och det returnerar ett strukturerat svar per fråga. Varje fråga är en av tre primitiver:

• noul — en sann/falsk bedömning som returneras med en kalibrerad sannolikhet.

• val — välj ett av upp till 255 märkta alternativ.

• poäng — betygsätt på en ordnad skala med 2 till 10 nivåer.

TypeSafe:s egen dokumentation visar ett exempel på 0-indexerad poäng; Jev 1.13-modellkortet publicerar 2–10 nivåer. Båda är leverantörens eget material och den här sidan hittar inte på någon sammanjämkning mellan dem.

Träningsmetoden är TypeSafes egen nybildning: Reinforcement Learning for Calibrated Decisions (RLCD), som beskrivs i lanseringsinlägget gentemot RLHF och RLVR på axeln kalibrerade beslut med ärliga sannolikheter. RLCD är TypeSafes term, inte en generisk maskininlärningsförkortning, och den bör läsas som en leverantörsbeskrivning snarare än en oberoende karaktäriserad teknik.

Åtkomst är inte längre begränsad: Jev har varit allmänt tillgängligt sedan 2026-09-21, och ”waitlisted” har tagits ur bruk. ”Early access” är fortfarande TypeSafes egen nuvarande formulering på deras startsida, så det är inte ett påstående som bör avfärdas – det är helt enkelt leverantörens etikett, och de driftsbegränsningar som publiceras tillsammans med den är konkreta.

Siffrorna på vårt kort: en kontext på 65 536 token, där leverantören dokumenterar ungefär 64K input över det kombinerade tillståndet plus frågor. Om du har sett en mindre siffra angiven för Jev, är det enbart tillståndsbudgeten och inte en konkurrerande mätning, och de två bör inte presenteras som en motsägelse. Priset är 0,042 USD per miljon input-token, med output som faktureras till noll – det finns inga output-token att mäta, eftersom ett skrivet beslut inte är prosa.

Vår egen serveringsdata, från vår trafik i stället för leverantörens benchmark, under de sju dagarna fram till 2026-09-30: p50 151 ms, p95 247 ms, cirka 349 uttoken per sekund, en felfrekvens på 0,49 % och 76,2 M token serverade. Daglig p50 över det fönstret löpte 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, med en verklig avvikelse – en p95 på 2 448 ms den 2026-09-28 som hör till serien utan att vara normen.

TypeSafe:s rubrikpåståenden, märkta som leverantörens egna och inte oberoende replikerade: "193,6 gånger snabbare, 444,6 gånger billigare", med fotnot kopplad till System One-arbetsflöden; ett genomräknat exempel på 0,000081 dollar på 0,114 s mot 0,013880 dollar på 8,566 s för LLM:er; "42 dollar per miljard indatatokens"; och "Noll hallucinationer", vilket är ett påstående om konfidensuppskattningar snarare än ett bevis för noll fel – vårt korts felkvot på 0,49 % är den ärliga motvikten. TypeSafe säger också tydligt att det inte kan bevisa att prissättningen inte är subventionerad, och att deras publicerade utvärderingar i allmänhet kördes från bärbara datorer på västkusten, där tjänsten är baserad. Deras eget benchmark-kort är fortfarande markerat som väntande.

Tredjepartsförråden finns, och vi går inte i god för dem

Sökningar på "jev github" leder till slut till repositorier som inte tillhör TypeSafe: wrappers, promptsamlingar, adapterexperiment och den välbekanta "awesome"-listan som dyker upp kring varje ny modell. De är inte en del av det leverantören publicerar, de har ingen leverantörsgranskning, och deras stjärnantal mäter nyfikenhet snarare än korrekthet. De kan vara användbara; de är inte dokumentation, och inget i dem är ett uttalande om hur Jev fungerar.

Vad skulle ändra det här svaret?

Ett släpp av vikter, en publicerad arkitektur eller en oberoende utvärdering av beslutskvaliteten snarare än latensen. Vilken som helst av de tre skulle ändra det första ordet på den här sidan. Fram till dess har sökningen ett stabilt svar, och den del av det som är värd att agera på är verktygskedjan: om det typade beslutsgränssnittet är vad du bygger mot, är en MIT-licensierad adapter som byter ut den bakomliggande modellen skillnaden mellan ett beslut du kan återkomma till och ett du inte kan.

Jev 1.13 finns i vår katalog under typesafe/jev-1.13, på samma nyckel som resten av en stack och dirigeras via den dedikerade systemone-slutpunkten i stället för chat-completions-formen. Modellen är sluten, verktygen är öppna, och båda halvorna av detta är nu nåbara från en och samma plats.