Den dyraste delen av min innehållspipeline är inte skrivandet. Det är beslutsfattandet. Det är exakt det problem TypeSafe Jev byggdes för, vilket är anledningen till att jag ägnade en förmiddag åt en modell som inte kan skriva en enda mening.
Varje artikel som passerar genom den utlöser en rad små bedömningar: är det här ämnet värt att bevaka, är det ett teknik- eller musik-inlägg, är utkastet tillräckligt bra för att passera redaktörsgrinden, motiverar SEO-poängen en omskrivning. Inget av detta kräver prosa. Det kräver ett svar som en switch-sats kan läsa. Och fram till förra veckan var det enda sättet jag hade att få ett sådant svar att hyra en frontier-modell som genererar ett stycke, bäddar in det i JSON och fakturerar mig för båda delarna.
Den 15 september 2026 lanserade ett labb kallat TypeSafe AI en modell som specifikt byggts för att avskaffa det mönstret. TypeSafe Jev är en System One-modell: den genererar inte text alls och kostar 0,042 dollar per miljon input-tokens, medan output har nollpris.
Jag har ännu inte fått använda den själv. Tidig åtkomst är köbaserad. Det här är alltså inget fälttest. Det är den research jag gjorde innan jag bestämde mig för om den skulle in på en roadmap, vilka delar av lanseringen som håller vid granskning, vilka som inte gör det och var den faktiskt skulle passa in i de system jag redan kör.
Vad TypeSafe faktiskt lanserade
TypeSafe AI kom ur ungefär två års stealth med en seed-runda på 40 miljoner dollar ledd av DCVC. Grundarteamet består av Diogo Almeida, Erik Gafni och Sasha Sheng.
Almeidas bakgrund är anledningen till att den här lanseringen fick uppmärksamhet i stället för att scrollas förbi. Han arbetade på OpenAI, var huvudförfattare med lika stort bidrag till InstructGPT-artikeln och bidrog till GPT-4. En del av lanseringsbevakningen förenklade detta till ”meduppfinnare av ChatGPT”, vilket är en överdrift som reducerar en stor kollektiv insats till en person. Den korrekta versionen är fortfarande stark: han hjälpte till att bygga den forskning om instruktionsföljande som fick konversationsassistenter att fungera, och argumenterar nu för att det tillvägagångssättet är fel gränssnitt för automatisering.
Hans inramande fråga är den bra delen: modeller har varit övermänskliga på chatt i flera år, så var finns all automatisering?
TypeSafes svar är att flaskhalsen aldrig var intelligens. Problemet är att en modell som svarar i prosa är svår att bygga programvara ovanpå. Du ställer en fråga, får en sträng, tolkar den, validerar den, hanterar fallet där den vägrade, hanterar fallet där den först skrev tre stycken resonemang och först därefter kan du förgrena flödet. Strukturerade outputs gjorde detta mindre smärtsamt. De ändrade inte det faktum att gränssnittet under huven fortfarande är generativt.
Jev utgår i stället från beslutsrymden. Namngivningen är avsiktlig i båda ändar: ”System One” är en blinkning till Kahnemans snabba, intuitiva System 1-tänkande, och Jev är uppkallad efter William Stanley Jevons, vars paradox säger att fallande kostnader driver stigande konsumtion. TypeSafe talar om för dig vad de förväntar sig ska hända med antalet anrop.
Tre primitiver, och det är hela API:t
Du skickar programtillstånd plus typade frågor. Du får tillbaka typade svar, där varje svar innehåller en kalibrerad sannolikhet. Det finns exakt tre frågetyper.
Choice, Score och Noul
Choice väljer ett alternativ från en deklarerad uppsättning, upp till 255 alternativ, och returnerar en sannolikhetsfördelning över alla alternativ samt ett konfidensvärde.
Score placerar input på ett spektrum med två till tio ordnade nivåer som du beskriver med ord. Den returnerar en kontinuerlig position som kan hamna mellan nivåerna, så 1.035 är ett giltigt svar.
Noul utvärderar ett binärt påstående och returnerar ett enda tal från 0 till 1: sannolikheten att det är sant. Inget separat konfidensfält behövs, eftersom talet redan är övertygelsen.
Så här ser ett riktigt anrop ut
Här är formen som TypeSafes Python SDK dokumenterar:
python from typesafe_sdk import Choice, Noul, Score, TypeSafeClient
client = TypeSafeClient()
response = client.system_one( state={ "ticket": {"subject": "Duplicate charge", "body": "I was charged twice for order A-104."}, "order": {"id": "A-104", "charges": [{"amount_usd": 49}, {"amount_usd": 49}]}, "refund_policy": "Duplicate charges are eligible for a refund.", }, questions={ "department": Choice( instructions="Which team should handle this", criteria={ "billing": "Payment or subscription issues", "technical": "Bugs or integration problems", "other": "Anything else", }, ), "frustration": Score( instructions="How frustrated the customer appears", criteria=["Calm, just stating facts", "Frustrated but civil", "Very angry"], ), "refund_requested": Noul(instructions="The customer is explicitly asking for a refund"), "policy_supports": Noul(instructions="The stated refund policy covers this situation"), }, )
if response.answers["refund_requested"].noul > 0.7 and response.answers["policy_supports"].noul > 0.8: start_refund_flow("A-104")
Fyra bedömningar, en förfrågan, en tur och retur. Modellen står för den semantiska förståelsen. Policyn stannar i koden där jag kan läsa, jämföra och testa den.
Den sista delen är det arkitektoniska argumentet, och det är mer intressant än prissättningen. I stället för att be en modell att ”hantera den här kunden” specificerar du vad som måste förstås och låter det som händer därefter ligga i vanlig versionshantering.
Vad TypeSafe Jev kostar
Det här är siffran som fick folk att reagera.
| Dimension | Jev | Frontier-LLM:er |
|---|---|---|
| --- | --- | --- |
| Inputpris | 0,042 dollar / MTok | 0,20–10 dollar / MTok |
| Outputpris | Gratis | Ungefär 5× input |
| Latens (leverantör) | 70–500 ms | 3–329 s |
| Kontext | 64k state + frågor | Hundratusentals |
| Outputformat | Typat, fast schema | Strängar som du tolkar |
| Konfidens | Kalibrerad, i varje fält | Inkonsekvent vid prompting |
Att output är gratis är ingen kampanj. Det finns ingen autoregressiv dekoderingsloop, så det finns inget att mäta. Om 0,042 dollar är hållbart eller subventionerat av riskkapital går inte att veta just nu, och TypeSafe säger det direkt i sitt eget lanseringsinlägg. De förväntar sig att priset ska sjunka snarare än stiga, vilket bara tiden kan avgöra.
Kontextgränserna fungerar annorlunda än hos en LLM, eftersom state läses in en gång och frågor körs parallellt över det: ungefär 64k tokens för state och alla frågor tillsammans, med cirka 32k för state plus den enskilt längsta frågan. Endast text och strukturerad JSON. Inga bilder, inget ljud, ingen video.
Latenspåståendet och vad någon faktiskt mätte
TypeSafe publicerade 70–500 ms från början till slut. Lanseringsinlägget är ärligt med att körningarna kom från teamets egna laptops på USA:s västkust, vilket är bästa möjliga fall för ett USA-hostat API.
En ingenjör på Classmethod Malaysia utsatte den för en riktig routningsuppgift. De kom förbi väntelistan, anropade POST https://api.typesafe.ai/v1/systemone direkt och använde Choice för att återskapa klassificeraren i NVIDIAs NeMo Switchyard-routningssetup, där konversationer sorterades i fyra nivåer. Fyrtio anrop, tio per nivå.
Alla 40 lyckades. Alla 40 matchade den förväntade nivån. Medianlatensen landade på 0,64–0,67 sekunder. Kostnad per anrop: 0,000025–0,000027 dollar.
Det är ungefär tio gånger långsammare än rubrikens 70 ms, och ändå det mest intressanta resultatet under hela lanseringscykeln. För det som ersattes var en Gemini 3.5 Flash-klassificerare med 2,1 sekunders median, eller en DeepSeek V4 Flash-klassificerare med 7,2 sekunder. Jev var ungefär tre gånger snabbare än det snabba och dyra alternativet och tio gånger snabbare än det billiga och långsamma, samtidigt som den kostade bråkdelar av en cent per anrop.
En detalj från testet är mer värd än hastighetssiffrorna. För de tre entydiga nivåerna kom konfidensen tillbaka på 1,0. För den genuint gränsfallsmässiga ”medium”-nivån sjönk den till 0,57–0,67. Modellen visste vilket anrop som var svårt. Det är en egenskap du inte kan få tillförlitligt från en chattmodell, och det är den som faktiskt förändrar hur du skriver den omgivande koden.
Vad andra säger om TypeSafe Jev
Lanseringen drog till sig en Hacker News-tråd med 256 kommentarer. Det användbara med den är att nästan ingen hävdade att tekniken var falsk. Flera kommentatorer sa att de skulle lansera den. Invändningarna riktades rakt mot marknadsföringen, och det är värt att läsa innan någon bygger en roadmap på detta.
”Frontier-modell” gör mycket av jobbet
Jev kan inte skriva kod, hålla en konversation eller producera en mening. Att placera den i samma formulering som GPT eller Claude lånar trovärdighet som den inte självständigt har förtjänat. En kommentator föreslog en ärligare rubrik: den flyttade fram hastighets- och kostnadsfronten för strukturerade beslut. Det är en verklig bedrift. Det är inte samma mening.
”Kan inte hallucinera” är snävare än det låter
Det stämmer att en modell som aldrig genererar fri text inte kan hitta på en källhänvisning eller ett verktygsnamn, och TypeSafes siffra på 0 % typfel följer av konstruktionen snarare än av mätning. Men en modell som begränsas till tre tillåtna kategorier kan fortfarande självsäkert välja fel kategori. Det som har eliminerats är det felaktigt formaterade svaret, inte den felaktiga bedömningen. TypeSafes egen vd höll direkt med om denna distinktion i tråden.
Hastighetsjämförelsen kanske inte är helt rättvis
Siffran 70 ms mäts mot LLM:er som autoregressivt genererar ett helt strukturerat svar, inklusive schemanamn och formatering, snarare än mot en LLM som begränsas till att generera motsvarande korta beslut. Den metodfrågan är fortfarande olöst.
Evals är egenkonstruerade
TypeSafe byggde ett nytt format för ”workflow eval” i stället för att köra offentliga benchmarks och poängsatte modeller mot genomsnittet av GPT-6 Astra och Fable 5.1 i stället för mot facit. Företaget lyfter självt sina begränsningar: arbetsflödena byggdes av det egna teamet, referensmodellerna snedvrider resultaten mot OpenAI och Anthropic, och konkurrerande LLM:er körs genom TypeSafes egen adapter. Företaget har också sagt att det kommer att avstå från offentliga topplistor, vilket flera personer tolkade som bekvämt.
Det finns ingen arkitekturartikel. RLCD, eller Reinforcement Learning for Calibrated Decisions, är träningsmetoden som hela argumentet vilar på, och den beskrivs men offentliggörs inte i detalj. Ingen reward-funktion, inga kalibreringskurvor, inget som oberoende kan reproduceras. Som Anthony Maio påpekade är reinforcement learning för kalibrering inte heller nytt i sig; tidigare arbete som ”Rewarding Doubt” utforskar samma område. Det som kan vara nytt är paketet, inte nödvändigtvis metoden.
Siffran som de flesta artiklar hoppade över
Begravd i TypeSafes egen utvärdering, över fyra arbetsflöden som täcker hantering av säkerhetsincidenter, observability för agentspår, fakturahantering och kundservice, finns bilden av träffsäkerheten.
| Modell | Överensstämmelse | Kostnad / fall | Latens |
|---|---|---|---|
| --- | --- | --- | --- |
| Jev | 67,8 % | 0,0004 dollar | 0,4 s |
| GPT-5.6 Terra | 67,9 % | 0,0304 dollar | 10,1 s |
| Claude Sonnet 5 | 67,8 % | högre | högre |
| Claude Opus 5 | 73,1 % | ej publicerad | ej publicerad |
| GPT Sol | 74,1 % | ej publicerad | ej publicerad |
Läs det noggrant, eftersom det omformulerar allt. Jev matchar frontier-modeller i mellanklassen till ungefär en sjuttiosjättedel av kostnaden och en tjugofemtedel av latensen. Den matchar inte toppskiktet. För fakturahantering specifikt var gapet störst: Jev på 61,8 % mot Sols 79,1 %.
Den ärliga positioneringen är alltså inte ”frontier-intelligens, billigare”. Den är ”Sonnet-klassad bedömning till ett pris där du kan anropa den vid varje förfrågan i stället för vid vissa”. För en router, en klassificerare eller ett förfilter är den avvägningen utmärkt. För ett beslut där det är dyrt att ha fel är gapet på tolv procentenheter mot Sol hela historien.
Var TypeSafe Jev passar in i min stack
När jag kör detta mot system jag redan driver klarar tre platser testet och två gör det inte.
Artikelgrindar i innehållspipelinen
Koordinatorn som kör den här webbplatsens multi-agent-pipeline gör ett dussin avgränsade bedömningar per körning. Kategoriseringen mellan teknik och musik bygger för närvarande på heuristik för taggfördelning. Redaktörs-, putsnings- och humanizer-stegen svarar alla på en variant av ”är detta redo”. Det är Choice- och Noul-frågor i LLM-kostym. Kalibreringen betyder mer än priset här: ett konfidensvärde låter mig automatiskt godkänna de tydliga fallen och bara skicka de tvetydiga till en större modell.
Apify-aktörerna
En av dem poängsätter befintliga artiklar för SEO-kvalitet, vilket bokstavligen är en poängsättningsuppgift, och det enda som påverkar break-even där är modellkostnaden inne i API:t. En Score-primitiv för 0,000026 dollar per anrop jämfört med en frontier-modell som gör samma jobb är en marginalförändring, inte en optimering. Den skulle jag mäta först och tro på därefter.
Routning av kundfrågor på e-handelssidan
Inkommande FAQ-frågor behöver en kategori, en bedömning av hur brådskande de är och en flagga för ”behöver detta en människa”. Tre parallella frågor, en förfrågan, under en sekund. Det här är det kanoniska användningsfallet och det som lanseringsdemon bygger på.
Där den inte passar
Två platser, och båda är hårda begränsningar snarare än bedömningsfrågor. Mixanalytic är ljudanalys, och Jev tar endast text och JSON, så transkribering eller funktionsutvinning måste ske först, och då är det intressanta arbetet redan gjort. Och allt som skriver: artikelutkast, tweetgenerering, översättningar. Jev lämnar ifrån sig strängar med flit. Det är inte en billigare Claude, utan en annan komponent.
Det är den distinktion jag skulle hålla fast vid. Det här är inte ett modellbyte. Det är ett nytt lager som placeras under LLM-anropen och hanterar de beslut som dessa anrop för närvarande är överkvalificerade för.
Relaterad läsning: mitt arbetsflöde för multi-agent-kodgranskning→ beskriver hur jag strukturerar oberoende agentbedömningar, recensionen av Claude Fable 5.1→ innehåller den frontier-modellprissättning som detta jämförs med, och byggloggen där dessa aktörer lanserades→ ger kontext om vad de gör.
Så kommer du igång med TypeSafe Jev
Åtkomst är köbaserad via console.typesafe.ai, eller genom Vercel AI Gateway. Ingenjören på Classmethod rapporterade att åtkomst erhölls direkt efter registrering, så kön kan vara kort i praktiken.
bash export TYPESAFE_API_KEY="sk-..."
pip install typesafe-sdk # Python 3.10+ npm install @typesafe-ai/sdk # Node 20+
Båda SDK:erna läser TYPESAFE_API_KEY från miljön och använder som standard jev-latest. Det finns en endpoint, POST https://api.typesafe.ai/v1/systemone, om du hellre hoppar över SDK:t helt. Konsolen innehåller en playground med genomarbetade exempel för ticket-routning, CV-granskning och revisioner av supportagenter.
Två saker är värda att känna till före det första anropet, båda från den praktiska guiden som publicerades under de första 48 timmarna. Ställ alla frågor på en gång i stället för att göra ett billigt anrop och följa upp, eftersom frågor utvärderas parallellt, så en tionde fråga kostar tokens men nästan ingen tid, och TypeSafes cookbook rapporterar att batchning är ungefär 12× billigare och 10× snabbare än att fråga en i taget. Och inkludera alltid ett uttryckligt other-alternativ i en Choice, så att modellen kan säga att inget passar i stället för att välja det närmaste felaktiga alternativet.
Omdömet om TypeSafe Jev
Priset är rubriken och arkitekturen är det verkliga argumentet. Skala bort inramningen som ”frontier-modell” och 200×-siffrorna som bygger på egenkonstruerade evals, så återstår fortfarande det mest intressanta jag har läst om AI-infrastruktur det här kvartalet: en komponent som gör avgränsade bedömningar inuti programvara, med ärlig osäkerhet kopplad till dem, medan deterministisk kod behåller kontrollen över exekveringen.
Det jag inte skulle göra är att behandla kalibreringen som bevisad. Varje påstående som spelar roll – att sannolikheterna är ärliga, att träffsäkerheten håller på någon annans område, att något av detta överlever produktionsbelastning – rapporteras för närvarande av ett företag som befinner sig en vecka in i tidig åtkomst, utan artikel och utan reproduktion från tredje part. Hastighet och pris kan du verifiera dag ett. Kalibrering kräver tusentals märkta utfall, och ingen har publicerat sådana ännu.
Alltså: en registrering på väntelistan, en poängsättningsuppgift jag redan kör i volym och en mätning jag gör själv innan något flyttas. Det är rätt mängd entusiasm för en veckogammal modell med en genuint bra idé och inga kvitton som någon utanför företaget har kontrollerat.
Källor
Upplysning: researchad och utarbetad med Claude Opus 5 via min personliga webbplats-MCP den 19 september 2026, utifrån TypeSafes lanseringsinlägg och sex oberoende texter, inklusive en praktisk API-mätning. Jag har ingen tidig åtkomst till Jev och gör inte anspråk på att ha testat den själv. Leverantörsrapporterade siffror är märkta som sådana genomgående; varje siffra här kan hänföras till en källa ovan.