Den 25. september 2026 annonserte TypeSafe AI Jev, den første modellen i det den kaller "System One"-kategorien: ikke en chatbot, og ikke bare en større språkmodell, men det selskapet beskriver som en beslutningsmodell - noe bygget for å svare på et avgrenset spørsmål med et maskinskrevet, kalibrert svar i stedet for et avsnitt med prosa. Kunngjøringen er tett med spesifikke tall, så dette stykket går gjennom det nøyaktig som påstått, markerer tydelig hva vi kunne og ikke kunne verifisere, og ser på hvorfor den underliggende ideen, å bestemme i stedet for å generere, er verdt å ta seriøst for sikkerhetsprogramvare spesielt.
Hva TypeSafe faktisk annonserte
TypeSafe AI er grunnlagt av Diogo Almeida, som skriver i kunngjøringen at "På OpenAI hjalp jeg med å bygge metodene som gjorde språkmodeller nyttige til å følge instruksjoner og snakke med mennesker." Jev, kalt selskapets «første offentlige modell», er ment som en helt annen jobb: å produsere det TypeSafe kaller typesikre strukturerte verdier med kalibrerte sannsynligheter og konfidensscore, generert gjennom det den kaller en parallell sampler i stedet for den vanlige token-by-token-dekodingen, og trent opp med en metode selskapet kaller for forsterking, br. CD.
- TypeSafe rapporterer en ende-til-ende-responstid på "70ms-500ms," mot hva den målte som "3 til 329 sekunder" for grensespråkmodellene den sammenlignet Jev med.
- TypeSafe priser input tokens til "$0,042 / MTok," med output tokens oppført som gratis.
- På sine egne arbeidsflytevalueringer rapporterer TypeSafe at Jev kjører "193,6x raskere, 444,6x billigere" enn policyene den ble målt mot.
- TypeSafe beskriver en typefeil i Jevs utdata som, med sine ord, "matematisk umulig."
- Jev er i tidlig tilgang; TypeSafe sier at det bringer utviklere "fra ventelisten så raskt vi kan."
Generasjon versus beslutning
En stor del av det som kalles «AI i produksjon» er i det hele tatt ikke en skriveoppgave. Tillat eller blokker en tilkobling. Eskaler eller lukk en billett. Flagg eller slett en transaksjon. Rut en melding til en eller annen kø. Den ønskede produksjonen er ikke prosa, det er en etikett hentet fra en kort, fast liste, noen ganger med et partitur vedlagt. Å kjøre den typen spørsmål gjennom en modell bygget for å produsere flytende avsnitt er et misforhold: en JSON-blob kommer tilbake som må analyseres og håpes til gyldighet, og enhver uttalt tillit har en tendens til å bety spesielt lite, fordi ingenting tvang den til å spore modellens reelle feilrate.
To påstander er verdt å skille her, fordi de ikke er det samme: skrevet og kalibrert. En maskinskrevet utdata begrenser formen på svaret - et "valg"-spørsmål returnerer ett av alternativene på listen, en "score" returnerer et tall innenfor et deklarert område, aldri en bortkommen setning eller et oppfunnet felt. Kalibrering er en mye eldre og helt separat idé. Det er en statistisk egenskap, ikke en stilistisk en: det betyr at når systemet angir en sannsynlighet på 0,62, er det riktig om det ofte på tvers av mange spådommer som det, så et nedstrømsprogram kan faktisk terskel på det tallet i stedet for å behandle det som dekorasjon.
TypeSafes eget navn låner vokabularet fra psykologi i stedet for statistikk. Daniel Kahneman, som mottok Nobels minnepris i økonomiske vitenskaper i 2002 "for å ha integrert innsikt fra psykologisk forskning i økonomisk vitenskap, spesielt angående menneskelig dømmekraft og beslutningstaking under usikkerhet," populariserte begrepene i Tenker, raskt og sakte: "System 1" er "rask, automatisk, hyppig, emosjonell, stereotyp, uregelmessig, uregelmessig, ukonvensjonell, ukonvensjonell, uregelmessig anstrengelse", logisk, beregnende, bevisst." Metaforen er stemningsfull, men den beskriver menneskelig erkjennelse, ikke en garanti om et stykke programvare. En modell kan være rask slik System 1 er rask, uten at dens uttalte tillit betyr noe i det hele tatt - kalibrering må fortjenes og måles, ikke underforstått med et navn.
Det som "ikke kan hallusinere" kan og kan ikke bety
TypeSafes påstand om at en typefeil er "matematisk umulig" beskriver begrenset dekoding, en teknikk som allerede eksisterer andre steder. OpenAIs egen Structured Outputs-guide gir en lignende garanti: funksjonen, står det, "sikrer at modellen alltid vil generere svar som følger med det medfølgende JSON-skjemaet ditt, slik at du ikke trenger å bekymre deg for at modellen utelater en nødvendig nøkkel, eller hallusinerer en ugyldig enum-verdi." Den garantien er ekte og nyttig. Det er også smalere enn det høres ut: det begrenser formen på svaret, ikke om svaret er riktig. Et "valg"-spørsmål med tre alternativer vil alltid returnere ett av de tre - inkludert, hvis modellen har feilvurdert inndataene, et sikkert, gyldig skrevet, feil svar.
Kalibrering er stykket som må kontrolleres, ikke hevdes. Standardverktøyet er et pålitelighetsdiagram: bøtteprediksjoner ut fra deres uttalte konfidens, og for hvert bøtteplott hvor ofte disse spådommene faktisk viste seg å være riktige; gapet mellom diagonalen og den observerte linjen oppsummeres vanligvis som forventet kalibreringsfeil. Dette er ikke et nytt spørsmål for maskinlæring - Guo et al.s 2017-artikkel "On Calibration of Modern Neural Networks" fant at "moderne nevrale nettverk... er dårlig kalibrert" som standard, og at en enkel, enkeltparameter-fiks kalt temperaturskalering var "overraskende effektiv" til å reparere den. Leksjonen generaliserer forbi det ene papiret: kalibrering er ikke en egenskap en modell får kunngjøre om seg selv. Det er noe du sjekker, på dine egne merkede data, fordi det har en tendens til å forringes akkurat der du trenger det mest - på innganger som ikke ser ut som hva enn modellen ble stilt inn på.
En minimal eval sele (mal)
Før du dirigerer en reell avgjørelse gjennom en beslutningsmodell, Jev eller på annen måte, er tre spørsmål viktigere enn noen leverandørfigur: analyserer det innskrevne svaret mot skjemaet ditt hver eneste gang, sporer en uttalt konfidens dens reelle trefffrekvens på et merket utvalg av dine egne data, og overlever denne kalibreringen på input som skiller seg fra hva modellen allerede har sett. Skissen nedenfor er en mal bygget rundt forespørselsformen vist i TypeSafes egen hurtigstartdokumentasjon. Det gjør ingen påstander om hva å kjøre den mot Jev ville vise - vi har ikke kjørt den, og dette er illustrerende pseudokode, ikke 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- Hvorvidt det skrevne svaret alltid analyserer, på innganger ditt eget system produserer, ikke bare en leverandørs demosett.
- Om en oppgitt 0,9 er riktig omtrent ni ganger av ti på din egen merkede trafikk, ikke på andres eval sett.
- Om den kalibreringen holder på innganger ulikt noe den har sett før: en ny app, en ny protokoll, en avsender som har lest den samme kunngjøringen du nettopp leste.
- Hva den som ringer gjør ved en timeout eller et avbrudd, siden et beslutningssystem trenger en sikker standard når beslutningsmodellen er utilgjengelig.
Hvorfor dette er viktig for sikkerhetsverktøy
En brannmur, et spamfilter, en svindelsjekk, en triage-kø: hver og en av disse er et avgjørelsessystem, som svarer på samme form av spørsmål om og om igjen - gitt dette input, tillat eller blokker det, med hvor mye tillit, og hvor terskelen er. TypeSafes egen evals-side henter sine eksempler fra akkurat dette territoriet: Å bedømme om man skal lukke et sikkerhetsvarsel, eskalere det til en person eller inneholde det umiddelbart, er en triage-avgjørelse, ikke en skriveoppgave, og det er den typen samtaler et sikkerhetsverktøy foretar konstant, med et volum ingen analytiker kan gjennomgå for hånd.
| Generativt LLM-svar | Skrivet avgjørelse (Jev-stil) | |
|---|---|---|
| Produksjon | Et avsnitt som forklarer forbindelsen til en ukjent adresse på en uvanlig port "kan være verdt å se på" | { tillat: falsk, konfidens: 0,81 } |
| Parsing | Regex, eller en annen modellanrop, for å trekke en handling ut av prosa | Garantert samsvarer med det deklarerte skjemaet |
| Terskel | Ingen numerisk konfidens å sammenligne med en policy | En konfidensverdi en innringer kan terskel direkte på |
| Feilmodus | Flytende, plausibelt, og noen ganger rett og slett feil | Feil med et tall vedlagt, som en kalibreringssjekk i det minste kan fange opp i gjennomsnitt |
Avveiningen av personvernet, ærlig talt
Jev, som TypeSafe beskriver det, er et vertsbasert API: en forespørsel bærer "state", som betyr uansett hvilken data spørsmålet handler om, til TypeSafes servere over internett. For sikkerhetshendelsen og triage-eksemplene TypeSafe selv fremhever, er denne tilstanden akkurat den typen informasjon mange mennesker helst ikke vil gi til en tredjepart som standard - hvilken app snakker med hvilken adresse, hvor ofte, fra hvilken enhet. Å sende det til en hvilken som helst skymodell, uansett hvor raskt eller billig det er, betyr at data forlater maskinen de kom fra.
FireAI, HisnLabs egen macOS-brannmur, tok det motsatte valget for den eksakte beslutningskategorien denne artikkelen handler om. FireAI kjører på macOS 14 eller nyere på Apple silisium, for en engangspris på €49, og er eksplisitt ikke et antivirus og ikke en VPN. Når en app du ikke har sett før prøver å nå nettverket, kan FireAI kjøre en liten modell på selve enheten – en valgfri nedlasting på 1,5 GB – for å gjennomgå den forbindelsen og be deg om en vanlig grunn vedlagt; trafikken som vurderes sendes aldri noe sted. Hver og en av disse AI-assisterte avgjørelsene blir en synlig regel, knyttet til appens kodesignatur, som du kan se og angre, ved siden av trusselfeeder som brukes lokalt i stedet for å søke mot en ekstern server.
Vi hevder ikke at FireAIs enhetsmodell samsvarer med Jev, eller noen annen system-én-modell, i rå korrekthet, hastighet eller pris – vi har ikke kjørt den sammenligningen og har ingen egne evalueringer å publisere her. Det denne kunngjøringen støtter er en designretning: at en sikkerhetsbeslutning er godt tjent med en liten, rask, avgrenset modell som kjører nær dataene, i stedet for ved å dirigere den gjennom en generell chatbot et annet sted. TypeSafe lager den saken fra API-siden; FireAI bygger allerede på det fra enhetens side, og av en annen grunn - fordi spesifikt for en brannmur skal de aktuelle dataene ikke måtte forlate maskinen for å bli bedømt i det hele tatt.
Åpne spørsmål
- Uavhengige evalueringer: ingen ekstern part har ennå publisert en gjengivelse av hastighets- eller kostnadsmultiplene i TypeSafes kunngjøring, på data TypeSafe ikke valgte.
- Kalibrering under distribusjonsskift - det nøyaktige scenariet Guo et al.s papir handler om, og det som betyr mest mot en motstander som tilpasser seg når en forsvarsmetode er offentlig.
- Om prisene holder seg ved reelt produksjonsvolum, og om den oppgitte ventetiden holder under vedvarende belastning i stedet for en enkelt demonstrert forespørsel.
- Hvordan modellen oppfører seg på motstridende eller genuint tvetydige input, der et selvsikkert skrevet svar kan være mindre ærlig enn et svar som sier «uklart».
- Når tidlig tilgang åpner utover ventelisten, til hvem og under hvilke vilkår for dataene som sendes som "stat".
Foreløpig er Jev et sett med krav fra et team med ekte legitimasjon og ingen ekstern verifisering ennå. Kategorien den prøver å navngi, beslutningsmodeller i stedet for generasjonsmodeller, peker på et reelt gap i hvordan sikkerhetsprogramvare har blitt laget for å bruke AI så langt. Uansett om Jev selv holder stand under uavhengig testing eller ikke, er det en nyttig påminnelse om at det interessante spørsmålet for en brannmur, et svindelfilter eller en triage-kø aldri var "kan den skrive en overbevisende setning", men "kan den ta en avgjørelse den kan stå bak, raskt nok til å ha betydning." Det er spørsmålet vi stiller om enhetsmodellen inne i FireAI hver gang vi endrer den – og det er derfor, for oss, svaret forblir på enheten i stedet for å bli en forespørsel til noen andres API.
Hvor FireAI og HisnLabs kommer inn
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 er HisnLabs’ eget produkt: en KI-brannmur som kjører direkte på Macen. Den viser hver tilkobling appene dine gjør, i klart språk, og lar deg bestemme hva som forlater Macen din — KI-en kjører lokalt, så trafikken din sendes aldri til oss eller noen andre. HisnLabs’ sikkerhetsforskningsteam er de som holder disse vurderingene pålitelige: de katalogiserer hvilke domener som er vanlig telemetri og hvilke som er en ekte tjeneste, sporer landet og nettverket bak en tilkobling, og trener den lokale modellen (Autopilot-funksjonen) på ekte trafikkmønstre — uten at noe av det forlater Macen din.
Du kan lese om de tekniske valgene bak, eller prøve FireAI i 17 dager, på FireAI, fra HisnLabs.