Den 25 september 2026 tillkännagav TypeSafe AI Jev, den första modellen i vad den kallar kategorin "System One": inte en chatbot, och inte bara en större språkmodell, utan vad företaget beskriver som en beslutsmodell - något byggt för att svara på en avgränsad fråga med ett maskinskrivet, kalibrerat svar snarare än ett stycke prosa. Tillkännagivandet är tätt med specifika siffror, så det här stycket går igenom det precis som påstås, markerar tydligt vad vi kunde och inte kunde verifiera, och tittar på varför den underliggande idén, att besluta istället för att generera, är värd att ta på allvar för säkerhetsprogramvara i synnerhet.
Vad TypeSafe faktiskt tillkännagav
TypeSafe AI grundas av Diogo Almeida, som skriver i tillkännagivandet att "På OpenAI hjälpte jag till att bygga metoderna som gjorde språkmodeller användbara för att följa instruktioner och prata med människor." Jev, som kallas företagets "första offentliga modell", är ett helt annat jobb: att producera vad TypeSafe kallar typsäkra strukturerade värden med kalibrerade sannolikheter och konfidenspoäng, genererade genom vad den kallar en parallell sampler snarare än den vanliga token-by-token-avkodningen, och tränad med en metod som företaget kallar för Learnciision eller RL förstärkning.
- TypeSafe rapporterar en end-to-end-svarstid på "70ms-500ms", mot vad den mätte som "3 till 329 sekunder" för de gränsspråksmodeller den jämförde Jev med.
- TypeSafe prissätter inmatningstoken till "0,042 $ / MTok", med utdatatokens listade som gratis.
- På sina egna arbetsflödesutvärderingar rapporterar TypeSafe att Jev kör "193,6x snabbare, 444,6x billigare" än de policyer den mättes mot.
- TypeSafe beskriver ett typfel i Jevs utdata som, med dess ord, "matematiskt omöjligt."
- Jev är i tidig tillgång; TypeSafe säger att det tar utvecklare "från väntelistan så snabbt vi kan."
Generation kontra beslut
En stor del av det som kallas "AI i produktion" är tyst inte en skrivuppgift alls. Tillåt eller blockera en anslutning. Eskalera eller stäng en biljett. Flagga eller rensa en transaktion. Dirigera ett meddelande till en eller annan kö. Den önskade produktionen är inte prosa, det är en etikett hämtad från en kort, fast lista, ibland med ett partitur bifogat. Att köra den typen av frågor genom en modell byggd för att producera flytande stycken är en missmatchning: en JSON-klump kommer tillbaka som måste analyseras och hoppas på giltighet, och varje uttalad förtroende tenderar att betyda lite speciellt, eftersom ingenting tvingade den att spåra modellens verkliga felfrekvens.
Två påståenden är värda att skilja på här, eftersom de inte är samma sak: maskinskrivna och kalibrerade. En maskinskriven utdata begränsar svarets form — en "val"-fråga returnerar ett av alternativen på listan, en "poäng" returnerar en siffra inom ett deklarerat intervall, aldrig en herrelös mening eller ett påhittat fält. Kalibrering är en mycket äldre och helt separat idé. Det är en statistisk egenskap, inte en stilistisk: det betyder att när systemet anger en sannolikhet på 0,62, så stämmer det ofta över många förutsägelser som det, så ett nedströmsprogram kan faktiskt tröskelsätta det numret istället för att behandla det som dekoration.
TypeSafes egna namngivning lånar sitt ordförråd från psykologi snarare än statistik. Daniel Kahneman, som fick Nobels minnespris i ekonomiska vetenskaper 2002 "för att ha integrerat insikter från psykologisk forskning i ekonomisk vetenskap, särskilt angående mänskligt omdöme och beslutsfattande under osäkerhet," populariserade termerna i Tänkande, snabbt och långsamt: "System 1" är "snabbt, automatiskt, frekvent, känslomässigt, stereotypt, oregelbundet, oavsiktligt, oavsiktligt, oavsiktligt, oregelbundet", medan logisk, beräknande, medveten." Metaforen är suggestiv, men den beskriver mänsklig kognition, inte en garanti om en mjukvara. En modell kan vara snabb som System 1 är snabb, utan att dess uttalade förtroende betyder något alls - kalibrering måste förtjänas och mätas, inte underförstått av ett namn.
Det som "inte kan hallucinera" kan och kan inte betyda
TypeSafes påstående att ett typfel är "matematiskt omöjligt" beskriver begränsad avkodning, en teknik som redan finns någon annanstans. OpenAIs egen guide för strukturerade utgångar ger en liknande garanti: funktionen, står det, "säkerställer att modellen alltid kommer att generera svar som följer ditt medföljande JSON-schema, så du behöver inte oroa dig för att modellen utelämnar en nödvändig nyckel eller hallucinerar ett ogiltigt enumvärde." Den garantin är verklig och användbar. Det är också smalare än det låter: det begränsar svarets form, inte om svaret är rätt. En "valfråga" med tre alternativ kommer alltid att returnera en av de tre — inklusive, om modellen har missbedömt inmatningen, ett säkert, giltigt skrivet, felaktigt svar.
Kalibrering är den del som måste kontrolleras, inte hävdas. Standardverktyget är ett tillförlitlighetsdiagram: bucket-förutsägelser utifrån deras angivna förtroende, och för varje bucket-diagram hur ofta dessa förutsägelser faktiskt visade sig vara rätt; gapet mellan diagonalen och den observerade linjen sammanfattas vanligtvis som förväntat kalibreringsfel. Det här är ingen ny fråga för maskininlärning — Guo et al.s 2017 artikel "On Calibration of Modern Neural Networks" fann att "moderna neurala nätverk... är dåligt kalibrerade" som standard, och att en enkel korrigering med en enda parameter kallad temperaturskalning var "överraskande effektiv" för att reparera den. Lektionen generaliserar förbi det ena papper: kalibrering är inte en egenskap som en modell får tillkännage om sig själv. Det är något du kontrollerar, på din egen märkta data, eftersom det tenderar att försämras precis där du behöver det som mest — på ingångar som inte ser ut som vad modellen än har ställts in på.
En minimal eval sele (mall)
Innan du dirigerar ett verkligt beslut genom någon beslutsmodell, Jev eller på annat sätt, är tre frågor viktigare än någon leverantörssiffra: analyserar det inskrivna svaret mot ditt schema varje gång, spårar ett uttalat förtroende sin verkliga träfffrekvens på ett märkt urval av din egen data, och överlever den kalibreringen på indata som skiljer sig från vad modellen redan har sett. Skissen nedan är en mall som är byggd kring förfrågningsformen som visas i TypeSafes egen snabbstartsdokumentation. Det gör inga anspråk på vad det skulle visa att köra det mot Jev - vi har inte kört det, och detta är illustrativ pseudokod, inte en rapport.
# Illustrative pseudo-code. Mirrors the request shape shown in TypeSafe's own
# quickstart docs (POST /v1/systemone with state, model, and typed questions).
# Not run against Jev or any live API; no results are claimed here.
import requests
def ask(state: str, question_id: str, question: dict) -> dict:
resp = requests.post(
"https://api.typesafe.ai/v1/systemone",
headers={"Authorization": f"Bearer {API_KEY}"},
json={"state": state, "model": "jev-latest", "questions": {question_id: question}},
)
return resp.json()["answers"][question_id]
# 1. Shape check: does every response parse against the declared type, on your
# own edge cases, not just a vendor demo set?
# 2. Calibration check: bucket the stated confidence and compare it to the
# true label rate, on data the model has never seen.
buckets = {i: {"n": 0, "correct": 0} for i in range(10)}
for state, true_label in labeled_sample: # your own traffic, labeled by hand
answer = ask(state, "decision", {"type": "noul", "instructions": "Should this be allowed?"})
bucket = min(int(answer["noul"] * 10), 9)
buckets[bucket]["n"] += 1
buckets[bucket]["correct"] += int(round(answer["noul"]) == true_label)
for b, s in buckets.items():
if s["n"]:
stated = (b + 0.5) / 10
observed = s["correct"] / s["n"]
print(f"stated~{stated:.2f} observed={observed:.2f} n={s['n']}") # the gap here is your calibration error- Huruvida det inskrivna svaret alltid analyserar, på ingångar som ditt eget system producerar, inte bara en leverantörs demo-set.
- Huruvida en angiven 0,9 är rätt ungefär nio gånger av tio på din egen märkta trafik, inte på någon annans eval set.
- Huruvida den kalibreringen håller på ingångar som inte liknar något den har sett tidigare: en ny app, ett nytt protokoll, en avsändare som har läst samma meddelande som du just läste.
- Vad den som ringer gör vid en timeout eller ett avbrott, eftersom ett beslutssystem behöver en säker standard när beslutsmodellen inte går att nå.
Varför detta är viktigt för säkerhetsverktyg
En brandvägg, ett skräppostfilter, en bedrägerikontroll, en triagekö: var och en av dessa är ett beslutssystem som svarar på samma form av fråga om och om igen - givet denna input, tillåt eller blockera den, med hur mycket tillförsikt och var tröskeln ligger. TypeSafes egen evals-sida hämtar sina exempel från exakt detta territorium: att bedöma om man ska stänga en säkerhetsvarning, eskalera den till en person eller omedelbart innehålla den är ett triagebeslut, inte en skrivuppgift, och det är den typ av samtal som ett säkerhetsverktyg gör konstant, i en volym som ingen analytiker skulle kunna granska för hand.
| Generativt LLM-svar | Skrivet beslut (Jev-stil) | |
|---|---|---|
| Produktion | Ett stycke som förklarar kopplingen till en okänd adress på en ovanlig port "kan vara värt att granska" | { tillåt: falskt, konfidens: 0,81 } |
| Parsing | Regex, eller ett andra modellsamtal, för att dra en handling ur prosa | Matchar garanterat det deklarerade schemat |
| Tröskelvärde | Inget numeriskt förtroende att jämföra med en policy | Ett konfidensvärde som en uppringare kan tröskelsätta för direkt |
| Felläge | Flytande, plausibelt klingande och ibland helt enkelt fel | Fel med ett nummer bifogat, vilket en kalibreringskontroll åtminstone kan fånga i genomsnitt |
Sekretessavvägningen, ärligt talat
Jev, som TypeSafe beskriver det, är ett värd-API: en begäran bär "tillstånd", vilket betyder vilken data frågan än handlar om, till TypeSafes servrar över internet. För säkerhetsincidenten och triageexemplen som TypeSafe själv lyfter fram, är det tillståndet exakt den typ av information som många människor helst inte vill lämna till en tredje part som standard - vilken app pratar med vilken adress, hur ofta, från vilken enhet. Att skicka det till vilken molnmodell som helst, hur snabbt eller billigt det än är, innebär att data lämnar maskinen den kom ifrån.
FireAI, HisnLabs egen macOS-brandvägg, gjorde det motsatta valet för den exakta kategorin av beslut som denna artikel handlar om. FireAI körs på macOS 14 eller senare på Apple silicon, för en engångskostnad på 49 €, och är uttryckligen inte ett antivirus och inte ett VPN. När en app som du inte har sett tidigare försöker nå nätverket, kan FireAI köra en liten modell på själva enheten – en valfri nedladdning på 1,5 GB – för att granska den anslutningen och uppmana dig att bifoga ett vanligt språkskäl; trafiken som granskas skickas aldrig någonstans. Vart och ett av dessa AI-assisterade beslut blir en synlig regel, knuten till appens kodsignatur, som du kan se och ångra, som sitter bredvid hotflöden som appliceras lokalt istället för att frågas mot en fjärrserver.
Vi hävdar inte att FireAI:s enhetsmodell matchar Jev, eller någon annan system-ett-modell, i rå korrekthet, hastighet eller pris – vi har inte kört den jämförelsen och har inga egna evaler att publicera här. Vad det här tillkännagivandet stöder är en designriktning: att ett säkerhetsbeslut betjänas väl av en liten, snabb, avgränsad modell som kör nära data, snarare än genom att dirigera den genom en chatbot för allmänt bruk någon annanstans. TypeSafe gör det här fallet från API-sidan; FireAI bygger redan på det från enhetens sida, och av en annan anledning — för specifikt för en brandvägg borde data i fråga inte behöva lämna maskinen för att bedömas alls.
Öppna frågor
- Oberoende utvärderingar: ingen utomstående part har ännu publicerat en reproduktion av hastighets- eller kostnadsmultiplarna i TypeSafes tillkännagivande, på data som TypeSafe inte valde.
- Kalibrering under distributionsskifte – det exakta scenariot som Guo et al.s papper handlar om, och det som är viktigast mot en motståndare som anpassar sig när en försvarsmetod är offentlig.
- Huruvida prissättningen håller vid verklig produktionsvolym och om den angivna latensen håller under ihållande belastning snarare än en enda demonstrerad begäran.
- Hur modellen beter sig på motstridiga eller genuint tvetydiga indata, där ett säkert skrivet svar kan vara mindre ärligt än ett svar som säger "otydligt".
- När tidig åtkomst öppnas bortom väntelistan, till vem och under vilka villkor för data som skickas som "tillstånd".
För nu är Jev en uppsättning anspråk från ett team med riktiga referenser och ingen extern verifiering ännu. Kategorin man försöker nämna, beslutsmodeller snarare än generationsmodeller, pekar på en reell lucka i hur säkerhetsprogramvaran har fåtts att använda AI hittills. Oavsett om Jev själv klarar sig under oberoende tester eller inte, är det en användbar påminnelse om att den intressanta frågan för en brandvägg, ett bedrägerifilter eller en triagekö aldrig var "kan den skriva en övertygande mening" utan "kan den fatta ett beslut den kan stå bakom, tillräckligt snabbt för att spela roll." Det är frågan vi ställer om enhetens modell inuti FireAI varje gång vi ändrar den — och det är därför, för oss, svaret stannar kvar på enheten snarare än att bli en begäran till någon annans API.
Var FireAI och HisnLabs kommer in
We have not tested Jev and make no claim it works as described or that FireAI matches it in any way — but the idea that a security decision deserves a small, bounded, fast model instead of a paragraph from a chatbot is one we built FireAI around a year before TypeSafe wrote a blog post about it.
FireAI är HisnLabs eget verktyg: en AI-brandvägg som körs direkt på din Mac. Den visar varje anslutning dina appar gör, på klarspråk, och låter dig avgöra vad som lämnar din Mac — AI:n körs lokalt, så din trafik skickas aldrig till oss eller någon annan. HisnLabs säkerhetsforskningsteam är de som håller de bedömningarna tillförlitliga: de katalogiserar vilka domäner som är vanlig telemetri och vilka som är en riktig tjänst, spårar land och nätverk bakom en anslutning och tränar den lokala modellen (Autopilot-funktionen) på verkliga trafikmönster — utan att något av det lämnar din Mac.
Du kan läsa om de tekniska besluten bakom, eller prova FireAI i 17 dagar, på FireAI, från HisnLabs.