Vad är TypeSafe AI? Labbet bakom Jev 1.13 fattar beslut, inte meningar

TypeSafe AI är ett litet labb i San Francisco som säljer en modell som inte kan skriva en mening, och Jev 1.13 (typesafe/jev-1.13) är modellen i fråga. Den tar ett stycke state – ett e-postmeddelande, en logglinje, ett supportärende, en JSON-blob – plus en uppsättning namngivna frågor, och returnerar ett typat svar per fråga, vart och ett med sitt eget konfidensvärde. Ingen prosa, ingen kod, ingen förklaring och ingen chattruta. Modellen själv lanserades 2026-09-15, så den är inte ny och inget här är en lanseringshistoria: den här sidan finns på grund av en mindre, daterbar förändring. Den 2026-09-24 lade OrcaRouter till typesafe/jev-1.13 i sin katalog och öppnade modellkortet på sin egen adress, vilket var första gången Jev kunde anropas via en tredjepartsgateway i stället för bara via TypeSafe:s egen endpoint. Det är händelsen, den är sex dagar gammal den 2026-09-30, och det är anledningen till att en läsare som inte redan har ett avtal med TypeSafe nu kan sätta en System One-modell på samma nyckel som de generativa modeller som den är utformad att sitta bredvid. Allt annat på den här sidan är bakgrund om företaget som gjorde den.

Den ärliga inramningen av tidpunkten, eftersom den har betydelse för hur mycket av detta som är verifierat: Jev lanserades för mer än två veckor sedan och har varit allmänt tillgängligt sedan 2026-09-21, då TypeSafe tog bort sin väntelista. Det som ligger inom sjudagarsfönstret är routningsändringen, inte modellen. Om du kom hit i förväntan på en lanseringsrecension har lanseringen redan ägt rum och en handfull andra artiklar tog upp den.

En företagssida med ett manifest och inget arkitekturdiagram

TypeSafe beskriver sig självt, i sin egen metabeskrivning, som "ett AI-labb som bygger maskinnativ intelligensinfrastruktur för automation", med system "utformade för att fatta beslut i mjukvara". Dess startsida är stämplad Version 0.01 och har sidfoten "Made in SF". Det finns ett manifest som argumenterar för att den kortaste vägen till ett AI-format ekonomiskt skifte går genom att göra intelligens komponerbar, så att mjukvara kan anropa semantisk bedömning på samma sätt som den anropar en funktion; företagets egen sammanfattning av sin plan är att leverera formen av maskinnativ komponerbar AI, sedan göra den tillräckligt pålitlig för verklig automation och därefter erbjuda abstraktioner på högre nivå som är tillräckligt stabila att bygga vidare på. Dess slogan är "Vi bygger prod, inte Gud." Teamsidan namnger tre grundare – Diogo Almeida som CEO, Sasha Sheng som COO och Erik Gafni som CTO. Det är allt företaget säger om sig självt: en position, en produkt, tre namn och inga siffror om företaget självt.

Det som webbplatsen inte erbjuder är det som en ingenjör som utvärderar ett nytt beroende först letar efter. Det finns ingen arkitektursida, inget parameterantal, ingen redovisning av beräkningsresurser för träning och inget modellkort i akademisk mening. TypeSafe:s egen benchmark-dashboard är fortfarande markerad som väntande. För ett företag vars säljargument vilar på tillförlitlighet är öppenheten tunn, och det är ett faktum om vad som har publicerats snarare än en anklagelse om vad som döljs.

System One: kategorin, och varför namnet är lånat

Jev är den första av vad TypeSafe kallar System One-modeller. Namnet kommer från Daniel Kahnemans uppdelning mellan snabbt, intuitivt System 1-tänkande och långsamt, överlagt System 2-resonemang, och företagets lanseringsinlägg säger det direkt — det medger också att "System 1-tänkande" har haft en underton av att vara felbenäget, och hävdar att dessa modeller kan göras mer tillförlitliga än alternativen. TypeSafe myntade inte termen och äger den inte.

Det praktiska innehållet i kategorin är en medveten arbetsdelning: en modell som beslutar och en modell som skriver. Du förväntas hålla aritmetik, datumordning, räkning och strängjämförelse i vanlig kod, där de är exakta, och överlämna den semantiska bedömningen till Jev. Tre frågetyper är vad den kan besvara:

• 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 — gradera på en ordnad skala; vårt kort publicerar 2-10 nivåer, och TypeSafes egen dokumentation visar ett 0-indexerat exempel, så behandla leverantörens nivåer som definitionen och 2-10 som vad kortet publicerar

Varje fråga har sina egna instruktioner och, för val och poäng, sina egna kriterier. Förfrågningar över ungefär 64K indatatokens avvisas innan de når modellen, och svar streamas inte. Leverantören dokumenterar separat tillståndsbudgeten – tillståndet plus den enskilt längsta frågan – vid 32K tokens, vilket är en snävare siffra än kontexten på 65 536 tokens på kortet och inte motsäger den.

Deras tes, med deras egna ord

TypeSafe formulerar tesen bättre än någon sammanfattning skulle göra, så här kommer den ordagrant: "LLM:er producerar ord för människor. Jev producerar typade beslut och är mer som kod: pålitlig, snabb, självkonsistent och typsäker." Träningsmetoden bakom det är också deras, och det är en term som är värd att tillskriva just eftersom den har plockats upp på andra håll som om den vore generisk. TypeSafe kallar den Reinforcement Learning for Calibrated Decisions, eller RLCD, och kontrasterar den mot RLHF och RLVR: där de optimerar mänskliga preferenser eller programmatiskt verifierbara belöningar, siktar RLCD, med företagets formulering, på "svar med epistemiskt ärliga sannolikheter på System 1-uppgifter." Betrakta RLCD som TypeSafes egen nybildning, inte som en vedertagen akronym i litteraturen.

Siffrorna de inleder med, och vem som valde arbetsbelastningen

Startsidan inleder med ”193,6x snabbare, 444,6x billigare”, med fotnot till arbetsflöden för System One-uppgifter. Under den finns ett genomräknat exempel: TypeSafe AI på 0,000081 $ och 0,114 sekunder mot LLM:er på 0,013880 $ och 8,566 sekunder. Längre ner: ”42 $ per miljard indatatoken. 238x lägre indatapris än Claude Fable 5.1.” Och ett avsnitt med rubriken ”Noll hallucinationer”, som vid närmare granskning är ett påstående om konfidensuppskattningar snarare än ett bevis för noll fel: varje Jev-beslut bär en konfidensuppskattning, så programvara kan agera när konfidensen är hög och eskalera när den inte är det. Alla fyra är TypeSafe-siffror, på arbetsbelastningar som TypeSafe valt, och ingen av dem har replikerats oberoende. Själva lanseringsinlägget säger att teamet förväntar sig att dess 193,6x och 444,6x ska ligga i den högre änden av verkliga vinster, och noterar att arbetsflödena byggdes av dess eget kompetensteam, med referenssvar producerade av konkurrerande modeller. Vår egen sjudagars serveringsdata för samma modell visar en felkvot på 0,49 %, vilket är en annan mätning på en annan arbetsbelastning och är den ärliga motvikten till att läsa ”noll” som absolut.

Vad de inte har beaktat

Jevs arkitektur, parameterantal, träningsberäkningskraft och vikter är opublicerade, och det finns inget viktrepo i företagets GitHub-organisation. Vid kontroll 2026-09-30 hade organisationen elva offentliga repon; de betydande är verktyg, alla MIT eller Apache-2.0 – ett repo för agent-skills, ett Python-SDK, ett TypeScript-SDK, en drop-in-klientadapter som bygger på andra LLM-API:er, en samling Dagger-moduler, en del publicerad workflow-eval-kod, en n8n-nod och organisationens egen webbplats. Antal stjärnor och push-datum ändras, så läs dem samma dag i stället för från den här sidan.

Tre av de elva är forks av orelaterade projekt: vLLM, LLaDA och en Pulumi-provider för ClickHouse Cloud. De är forks av någon annans arbete och säger ingenting om hur Jev är byggt – i synnerhet ingenting om att Jev är diffusionsbaserat. Det korta svaret på om Jev är öppen källkod är att verktygen är öppna och modellen inte.

Vad de själva medger

Två erkännanden i lanseringsinlägget är värda mer än de flesta leverantörsförbehåll, eftersom de pekar ut exakt var bevisningen är svag. Om priset: "Vi kan inte bevisa att det inte är subventionerat; vi behöver det långsiktiga perspektivet för att bevisa hållbarheten i vår prissättning (som vi förväntar oss ska gå ner, inte upp)." Om hastigheten: "våra publicerade utvärderingar körs i allmänhet från våra bärbara datorer på västkusten (det är där vår tjänst för närvarande är baserad)." Det finns ett tredje, mer användbart för alla som bygger på det: för valmängder med hög kardinalitet kör Jev ett tvåstegssystem som poängsätter oberoende och sedan gör ett explicit val, "därav den ibland förekommande fördröjningen." Det är leverantören som förklarar varför latensen inte är konstant mellan olika frågetyper, och det är sådant man vanligtvis får veta i en supporttråd.

Där du faktiskt kan ringa det, från och med idag

Via TypeSafes eget API, där modellen är allmänt tillgänglig och startsidan fortfarande använder leverantörens egen fras ”early access” – den formuleringen är aktuell och värd att behålla, medan ”waitlisted” är utfasad: dokumentationen publicerar konkreta driftgränser (100K tokens per sekund, 40 förfrågningar per sekund, 429 med SDK-backoff om endera överskrids) och innehåller inte alls något språk om väntelista. Och sedan 2026-09-24, via OrcaRouter.

Det vi tillhandahåller är värt att formulera exakt, eftersom anropsformen är den del som skiljer sig. Katalogposten är typesafe/jev-1.13, med namnet TypeSafe: Jev 1.13, med endpointtypen "systemone" som stöds — så den nås via POST /v1/systemone i stället för OpenAI:s chat-completions-form, icke-strömmande, text in och strukturerad JSON ut, upp till cirka 64K indatatoken för state och frågor sammanlagt. Indata kostar $0.042 per miljon token och utdata faktureras till noll, eftersom det inte finns några utdatatoken att mäta: ett typat beslut är inte prosa. Det är leverantörens listpris som förs vidare, med 0 % påslag, på samma nyckel som de andra 200+ modellerna i katalogen — ett API för 200+ modeller, 0 % påslag (leverantörens listpris förs vidare, så leverantörens prissänkningar gäller här samma dag). Om anledningen till att du läser om TypeSafe AI är att du vill ta reda på om Jevs kalibrering håller för dina egna data innan du satsar en produktionsväg på den, så är det billiga sättet att ta reda på det att köra den vid sidan av en generativ modell som du redan litar på; att växla över till den modellen när Jevs konfidens visar sig vara låg är det billiga sättet att driftsätta den.

Våra egna serveringssiffror för sjudagarsfönstret som slutar 2026-09-30, vilka är våra siffror från vår egen trafik snarare än leverantörens benchmark: p50 151 ms, p95 247 ms, cirka 349 utdatatoken per sekund, en felfrekvens på 0,49 % och 76,2 miljoner serverade token. Den dagliga p50:n under det fönstret låg på 175, 170, 163, 161, 170, 147, 143 ms, så medianen har rört sig svagt nedåt. En dag i serien, 09-28, har en p95 på 2 448 ms – ett verkligt extremvärde i data, inte normen, och inte en siffra att planera en latensbudget kring. Dessa uppdateras dagligen; kortet är källan.

Där modellen är svag, enligt TypeSafe

Leverantören publicerar en sida om ojämnhet för Jev 1.13, senast granskad 2026-09-17, som namnger fellägena mer uppriktigt än de flesta lanseringsmaterial. Det är rätt sida att läsa innan man bygger på modellen, och dess egen lista ser ut så här. Jev besvarar frågan du skrev i stället för den du menade, så avgränsande ord, negationer och underförstådda villkor måste uttryckas explicit. Den är inte en miniräknare: den presterar sämre på matematiska än på semantiska frågor. Den läser datum som text snarare än som ordnade kvantiteter, så ordning, luckor och fönstertillhörighet är opålitliga, och ännu värre med blandade format. Dubbla negationer och indirektion i flera steg försämrar noggrannheten. Noggrannheten sjunker när tillståndet växer med irrelevanta detaljer — sidan säger att den "lider av kontextröta" — så att filtrera i kod först är lösningen. Tillstånd behandlas som data, inte som fientligt som standard, så injicerade instruktioner kan påverka svaren. Instruktioner och kriterier som inte matchar förvirrar den. Strukturella invarianter garanteras inte: en noul och en choice-output behöver inte motsvara varandra, och en fråga plus dess negation behöver inte summera till ett, så tröskelvärden bör inte flyttas mellan de två. Och den är inte tränad för att generera text — att tvinga den genom kedjade val "kommer inte att fungera bra och kommer att gå mycket långsamt."

Hur man tolkar TypeSafe AI sex dagar in i routingändringen

Företaget gör ett starkt, specifikt och falsifierbart påstående: att en smal beslutsmodell kan vara snabbare, billigare och mer pålitlig än en generell i den delmängd av arbete där man behöver ett omdöme snarare än ett stycke. Påståendet är rimligt och delvis självbevisande – konfidensuppskattningarna är en verklig designskillnad, priset är verkligt, och latensen vi mäter i vår egen trafik ligger i samma storleksordning som leverantörens. Det som saknas är den del som skulle låta en utomstående kontrollera resten: ingen arkitektur, inga parametrar, inga vikter, ingen oberoende benchmark, och ett pris som företaget självt säger att det inte kan bevisa är hållbart. Fellägena är dokumenterade, vilket är mer än vad de flesta labb gör och är det enskilt bästa skälet att ta modellen på allvar.

Om du funderar på om du ska ägna uppmärksamhet: kör Jev på indata som du redan har etiketterat, med etiketterna dolda, och titta på om dess konfidenssiffror skiljer de fall den får rätt från dem den får fel. Det testet kostar nästan ingenting vid 0,042 dollar per miljon input-tokens och det är det enda som besvarar frågan du faktiskt har. Om du funderar på om du ska lita på företaget: upplysningarna är vad de är, och det ärliga svaret är att bevisningen för närvarande är leverantörens ord plus vad du än genererar själv.