Hvad er Jev? TypeSafes System One Model forklaret

TL;DR

Jev er en beslutningsmodel udviklet af TypeSafe AI. TypeSafe introducerede Jev den 15. september 2026 som deres første System One model, designet til at returnere strukturerede beslutninger og sandsynligheder, som software kan bruge direkte. Denne guide bygger primært på TypeSafes officielle dokumentation, Quick Start-guide, modelreference og virksomhedens officielle annoncering af Jev.

Jev skriver ikke prosa, genererer ikke kode og fører ikke en samtale. Den evaluerer en tekstbaseret tilstand op mod typebestemte spørgsmål og returnerer strukturerede svar, som en applikation kan bruge direkte.

Skellet er vigtigt for software-workflows. En konventionel stor sprogmodel producerer tokens, også når en applikation kun har brug for en kategori, en score eller en ja/nej-vurdering. Jev er designet omkring selve beslutningen. Dens interface accepterer en tilstand og et eller flere spørgsmål og returnerer derefter typebestemte værdier og sandsynlighedsfordelinger. Choice- og Score-svar inkluderer også en konfidensværdi.

Jev er tænkt til klassifikation, routing, scoring, verifikation, guardrails og andre afgrænsede beslutninger. Den er ikke en generel erstatning for GPT, Claude, Gemini eller andre generative modeller. I en AI-agent kan en generativ model planlægge eller skabe indhold, mens Jev håndterer hyppige beslutninger som at vælge en rute, kontrollere risiko eller afgøre, om et resultat kræver gennemgang.

Key Takeaways

• Jev er udviklet af TypeSafe og præsenteres aktuelt som deres flagskibs-System One model.
• Modellen accepterer tekstbaseret tilstand plus typebestemte spørgsmål. Den returnerer strukturerede beslutninger frem for genereret prosa.
• Jev understøtter tre spørgsmålstyper: Choice, Score og Noul.
• Flere spørgsmål kan evalueres uafhængigt og parallelt på samme tilstand i én forespørgsel.
• TypeSafe træner Jev med Reinforcement Learning for Calibrated Decisions, eller RLCD.
• Den nuværende officielle modelside angiver Jev 1.13 med en forespørgselsgrænse på 64.000 tokens og kun tekstinput.
• Officiel pris er $0.042 per million input-tokens. Output-tokens er opført som gratis.
• Typesikkert output forhindrer skemauoverensstemmelser. Det garanterer ikke, at enhver forretningsbeslutning er korrekt.
• TypeSafe rapporterer latenser på 70 til 500 millisekunder og store gevinster på egne workflow-evalueringer. Disse tal er leverandør-rapporterede og gælder for System One-formede opgaver.

What Is Jev?

Jev er en beslutningsmodel bygget af TypeSafe AI. Den officielle dokumentation beskriver den som virksomhedens flagskibsmodel og den første System One model. Dens input har to hoveddele.

Den første del er tilstanden. Tilstand er den information, Jev skal inspicere, såsom en kundebesked, en hændelsesrapport, en samling poster eller et JSON-objekt, der indeholder applikationskontekst.

Den anden del er et sæt typebestemte spørgsmål. Hvert spørgsmål definerer den dom, der skal træffes, og den tilladte form af svaret. Jev evaluerer spørgsmålene mod tilstanden og returnerer resultater, som kode kan forgrene på, sortere, score eller rute.

Overvej en supportanmodning, der rapporterer, at en betalingsintegration har fejlet i tre dage. Et supportsystem behøver måske ikke et afsnit, der beskriver situationen. Det kan i stedet have brug for tre snævre beslutninger:

• Hvilket team skal modtage ticketten?
• Hvor frustreret virker kunden?
• Kræver beskeden øjeblikkelig opmærksomhed?

Jev kan repræsentere disse som et Choice-, et Score- og et Noul-spørgsmål i én forespørgsel. Svaret indeholder den valgte kategori eller score, den relevante sandsynlighedsfordeling og konfidens, hvor det understøttes. Applikationen beslutter derefter, hvad der skal gøres med disse værdier.

Denne arbejdsdeling er bevidst. Modellen leverer en usikker dom i et stabilt format. Applikationskoden bevarer kontrollen over tærskler, tilladelser, sideeffekter og fallback-adfærd.

What Is a System One Model?

TypeSafe bruger System One model til en klasse modeller designet til at træffe hurtige, strukturerede beslutninger, som software kan konsumere. Navnet trækker på skellet mellem hurtig og langsom tænkning associeret med Daniel Kahnemans arbejde. Det beskriver modellens tiltænkte rolle, ikke et krav om, at en softwaremodel reproducerer menneskelig kognition.

En System One-opgave har et afgrænset mål. En kyndig reviewer bør kunne træffe dommen hurtigt, når der gives tilstrækkelig kontekst. Eksempler inkluderer at vælge en intent, vurdere hastendegrad på en defineret skala, kontrollere om et udsagn er understøttet eller beslutte, om en anmodning skal eskaleres.

Opgaver, der kræver udstrakt research, flertrins deduktion, lange forklaringer eller indholdsskabelse, passer ikke naturligt. TypeSafe anbefaler at nedbryde brede domme i atomare spørgsmål og kombinere deres resultater i kode.

For eksempel er vurder denne startup-pitch for bred til at producere en inspicerbar beslutning. Markedsstørrelse, teknisk gennemførlighed og differentiering kan i stedet evalueres som separate spørgsmål. Applikationen kan kombinere disse scorer med en eksplicit formel. Hvis forretningsprioriteter ændres, kan vægtene ændres i koden uden at forvandle modelprompten til skjult forretningslogik.

How Does Jev Work?

Jevs operative kontrakt kan skrives som:

State + typebestemte spørgsmål -> typebestemte beslutninger + sandsynligheder

Dette adskiller sig fra den sædvanlige sprogmodel-flow:

Prompt -> genererede tokens -> parsing og validering -> applikationsbeslutning

Skellet handler ikke kun om et andet responsformat. Traditionelt struktureret output beder stadig en generativ model om at producere en sekvens af tokens, der overholder et skema. Jev er designet til at returnere værdier fra svarrum, der er defineret på forhånd.

Den aktuelle API accepterer tilstand som en streng, et JSON-objekt eller et array af tekstværdier. Input er kun tekst. Billeder, lyd, video og binære dokumenter skal konverteres til tekst eller strukturerede felter før indsendelse.

Hvert spørgsmål i en forespørgsel evalueres uafhængigt mod samme tilstand. Ifølge TypeSafes dokumentation ændrer tilføjelse af spørgsmål knap nok svartiden, fordi spørgsmålene evalueres parallelt. Uafhængighed forhindrer også, at ét spørgsmåls svar bliver kontekst for et andet spørgsmål i samme kald.

Den adfærd har en vigtig designkonsekvens. Hvis én beslutning reelt afhænger af en anden, hører afhængigheden hjemme i applikationsworkflowet. Kør den første evaluering, opdater tilstanden eller forgren i kode, og udfør derefter den næste evaluering. En enkelt forespørgsel passer bedst til spørgsmål, der deler evidens, men ikke afhænger af hinandens svar.

The Three Jev Question Types

Jev eksponerer tre primitiver. Hver matcher en anden type softwarebeslutning.

Choice

Et Choice-spørgsmål vælger en mulighed ud fra kriterier defineret af applikationen. Et supportworkflow kan forsyne billing, technical og sales med en beskrivelse for hver kategori. Jev returnerer den valgte mulighed, sandsynligheden for hver mulighed og en konfidensværdi afledt af fordelingens form.

Kategoridesign påvirker resultatets nytte. Overlappende muligheder skaber tvetydighed. Manglende muligheder tvinger modellen mod et svar, der måske ikke passer. Produktionstaksonomier bør inkludere en rute som insufficient_evidence eller human_review, når workflowet skal bevare usikkerhed.

Formuleringen bør også matche den faktiske beslutning. Hvilket team bør undersøge først spørger efter en foreløbig rute. Hvilket team forårsagede fejlen spørger efter en diagnose. De kan bruge samme liste over teams, men spørger ikke om det samme.

Score

Et Score-spørgsmål placerer tilstanden på en ordnet rubric. Kriterierne kan beskrive niveauer som rolig, frustreret og vred eller definere en mere detaljeret forretningsskala. Svaret inkluderer en numerisk score, en legend, der forbinder tal til niveauer, en sandsynlighedsfordeling på disse niveauer og konfidens.

En nyttig Score-rubric beskriver observerbare forskelle. Etiketter uden definitioner lader modellen og menneskelige reviewer fortolke forskellige standarder. En risikoskala bør angive, hvad der adskiller hvert niveau. En kvalitetsskala bør angive, hvilke krav der er til stede eller mangler.

Hvis en score blander uafhængige hensyn, er det bedre at splitte dem. Relevans, faktuel støtte, tone og politikoverholdelse kan være separate spørgsmål. Applikationskode kan beregne en sammensat score ved at bruge vægte, der forbliver synlige og testbare.

Noul

Noul er TypeSafes binære beslutningsprimitive. Den estimerer sandsynligheden for, at et udsagn er sandt, og returnerer et tal fra 0 til 1. En værdi på 0,9 repræsenterer en højere estimeret sandsynlighed for sandhed end en værdi på 0,6.

Noul returnerer ikke det separate confidence-felt, som Choice og Score gør. Dens output er allerede en sandsynlighed for det udsagn, der evalueres. Spørgsmålet bør derfor skrives som et testbart udsagn, såsom beskeden udtrykker hastværk eller svaret er understøttet af den leverede kilde.

Noul er nyttig til verifikation og gating, men tærsklen hører til i applikationen. Et lavrisiko-interfaceforslag kan tolerere en lavere tærskel end en irreversibel finansiel eller administrativ handling.

Atomic Questions and Composed Workflows

Jev fungerer bedst, når hvert spørgsmål spørger om én snæver ting. Dette design gør output lettere at inspicere og lader softwaren eje den endelige politik.

Antag, at en agent skal beslutte, om et værktøjsopkald skal udføres. Et bredt spørgsmål som bør denne handling køre kan kombinere tilladelse, reversibilitet, datasensitivitet, brugerintention og operationel risiko. Et mere inspicerbart workflow evaluerer disse dimensioner separat:

• Er værktøjsopkaldet konsistent med brugerens anmodning?
• Sender det følsomme oplysninger?
• Er handlingen destruktiv eller svær at rulle tilbage?
• Påvirker det en ekstern konto?
• Kræver politikken yderligere bekræftelse?

Harnesset kan derefter kombinere svarene med deterministiske regler. En destruktiv operation kan kræve bekræftelse uanset modellens samlede konfidens. En skrivebeskyttet operation kan følge en mindre restriktiv vej. Denne ordning holder tilladelser i koden og bruger Jev kun til domme, der ikke kan udtrykkes pålideligt som faste regler.

Jev vs Traditional LLMs

Jev og store sprogmodeller tjener forskellige roller.

Jev bør ikke beskrives som en mindre chatbot. TypeSafe har ikke offentliggjort et parameterantal eller tilstrækkelig arkitekturdetalje til at klassificere modellen efter størrelse. Dens offentlige skelnen er baseret på træningsmål, samplingmetode og interface.

Jev erstatter heller ikke deterministisk kode. Faste regler forbliver det rette værktøj, når betingelser er eksplicitte og stabile. En skatteberegning, en tilladelsesliste eller en filstørrelsesgrænse bør ikke blive et probabilistisk modelkald. Jev er nyttig, hvor håndskrevne regler er for skrøbelige, men det ønskede svar stadig kan afgrænses.

Jev vs Structured LLM Output

Struktureret output lader en sprogmodel returnere JSON eller værdier, der overholder et skema. Det er værdifuldt, når et workflow har brug for både generativ ræsonnering og et maskinlæsbart resultat. Jev adresserer et smallere problem.

Med en LLM begrænser skemaet formen af et genereret svar. Med Jev er spørgsmålene og svarrummene modelinterfacet. Jev returnerer sandsynlighedsfordelinger, der er tiltænkt at deltage i applikationslogik, og uafhængige spørgsmål evalueres separat mod delt tilstand.

Matchende JSON-former etablerer ikke matchende adfærd. To systemer kan begge returnere et felt ved navn department, men alligevel afvige i latenser, kalibrering, håndtering af tvetydighed og responsstabilitet. Teams, der sammenligner Jev med struktureret LLM-output, bør holde applikationsskemaet konstant og teste begge systemer på samme mærkede data.

RLCD and Calibrated Decisions

TypeSafe siger, at Jev er trænet med Reinforcement Learning for Calibrated Decisions. RLCD adskiller sig i mål fra RLHF og RLVR.

RLHF optimerer svar ved hjælp af menneskelige præferencesignaler og er blevet udbredt til samtaleassistenter. RLVR bruger verificerbare belønninger og er associeret med opgaver, hvor korrekthed kan kontrolleres programmæssigt. RLCD træner TypeSafes modeller til at returnere beslutninger og kalibrerede sandsynligheder frem for genereret tekst.

Kalibrering vedrører grupper af forudsigelser. Hvis en model er velkalibreret, bør udfald, der tildeles en sandsynlighed nær 0,8, være korrekte omkring 80 procent af tiden på et passende sæt sager. Det garanterer ikke, at en bestemt forudsigelse med sandsynlighed 0,8 er korrekt.

Sandsynlighed og konfidens bør ikke behandles som udskiftelige. Choice og Score eksponerer fulde sandsynlighedsfordelinger. TypeSafe afleder konfidens fra formen af hver fordeling. En fordeling koncentreret om én mulighed producerer højere konfidens; en fladere fordeling signalerer tvetydighed. Teams kan bruge den leverede konfidens eller beregne en anden statistik ud fra sandsynlighederne.

Noul har intet separat konfidensfelt. Dens værdi er den estimerede sandsynlighed for, at udsagnet er sandt.

Jev Model Specifications and Pricing

Følgende detaljer kommer fra TypeSafes officielle modeldokumentation gennemgået den 21. september 2026.

TypeSafe bemærker, at ratelimits justeres dynamisk og kan ændre sig uden varsel. Aktuelle grænser og priser bør kontrolleres før produktion.

Dokumentationen angiver også, at engelsk er det primære træningssprog og aktuelt giver den bedste nøjagtighed. Andre sprog, inklusive CJK-skrifter, understøttes men ikke lige godt. En kinesisk, japansk eller koreansk workload bør evalueres på repræsentative data, før automatiserede beslutninger aktiveres.

TypeSafe siger, at Jev ikke fin-tunes eller LoRA-tilpasses med hver kundes data. De samme modelvægte betjener alle konti. Domeæneadfærd formes gennem tilstand, instruktioner, kriterier og applikationsside-komposition. Virksomheden angiver også, at kunders forespørgsler og svar ikke bruges til at træne Jev. Enterprise-kunder kan konsultere TypeSafes juridiske dokumentation for vilkår om nul dataopbevaring.

How Fast Is Jev?

TypeSafe rapporterer end-to-end svartider mellem 70 og 500 millisekunder. Deres lancering indlæg sammenligner dette interval med 3 til 329 sekunder for udvalgte frontier-modelkald og beskriver Jev som 40 til 200 gange hurtigere ved sammenlignelige intelligenchniveauer på System One-formede forespørgsler.

Virksomheden rapporterer også topgevinster på 193,6 gange i hastighed og 444,6 gange i omkostninger i deres workflow-evalueringer. Disse tal kræver kontekst.

De stammer fra TypeSafes egen evalueringsramme. Workflows sammenligner modeller på strukturerede beslutningsgrafer og bruger gennemsnittet af forudsigelser fra udvalgte high-end eksterne modeller som referencesandsynligheder. TypeSafe angiver, at de rapporterede gevinster sandsynligvis ligger nær den høje ende af forbedringer i den virkelige verden, og anerkender mulig bias, fordi medlemmer af deres modelkapabilitetsteam skabte workflows.

Disse resultater bør ikke læses som et generelt krav om, at Jev er hundreder af gange hurtigere end enhver LLM på enhver opgave. Jev opgiver tekstgenerering og målretter afgrænsede beslutninger. En fair sammenligning bør bruge opgaver, som begge systemer kan udføre, måle beslutningskvalitet såvel som latenser og inkludere omkostninger ved validering, retries og menneskelig review.

What Is Jev Best for

Jev egner sig bedst til højvolumen-workflows med et defineret svarrum og behov for usikkerhedsvurderinger.

• Customer Support Triage: Klassificér en ticket efter afdeling, hastendegrad, frustration, churn-risiko eller behov for menneskelig review.
• Intent and Model Routing: Identificér anmodningstypen og rut den til det passende værktøj, workflow, agent eller model. Konfidens kan afgøre, om routing er automatisk.
• Agent Tool Risk Checks: Evaluer foreslåede værktøjsopkald for destruktive handlinger, følsomme data eller inkonsistens med brugerens anmodning før udførelse. Applikationskoden forbliver ansvarlig for tilladelser.
• LLM Output Evaluation: Kontroller om et LLM-svar er understøttet af den leverede kontekst, følger det krævede format eller kræver menneskelig review.
• Content Moderation: Brug Choice til politik-kategorier, Score til alvorlighed og Noul til binære regelchecks. Sager med lav konfidens kan sendes til moderatorer.
• High-Volume Data Processing: Behandl logs, emails, anmeldelser, leads, annoncer eller dokumentsegmenter, når hver post kan evalueres uafhængigt, og outputtet er en kategori, score eller sandsynlighed.

Where Jev Fits in an AI Agent

En AI-agent kombinerer typisk en generativ model, værktøjer, applikationstilstand og regler, der styrer udførelse. Jev passer ind i dette system som et struktureret beslutningslag omkring den primære generative model.

Den generative model kan håndtere åbne opgaver som at fortolke en anmodning, planlægge et workflow, skrive indhold eller generere kode. Jev kan håndtere smallere beslutninger, der skal træffes gentagne gange under workflowet:

• Hvilket værktøj eller hvilken model bør bruges?
• Er den foreslåede handling risikabel eller inkonsistent med anmodningen?
• Bør agenten fortsætte, forsøge igen, stoppe eller bede om afklaring?
• Opfylder resultatet et defineret krav?
• Bør opgaven eskaleres til et menneske?

Applikationen forbliver ansvarlig for tilladelser, tærskler og sideeffekter. Jev leverer en beslutning og dens tilhørende sandsynlighed, mens applikationskoden afgør, hvilken handling der følger.

Dette skaber en arbejdsdeling. Generative modeller håndterer åbne ræsonnementer, Jev håndterer afgrænsede evalueringer, deterministisk kode håndhæver politik, og værktøjer udfører eksterne handlinger. Jev fungerer derfor som et supplement til en AI-agent snarere end som en erstatning for dens primære ræsonneringsmodel.

Limitations of Jev

Jev genererer ikke prosa, kode eller åbne forklaringer. Den er designet til fokuserede spørgsmål med definerede svarrum.

Et typesikkert svar kan stadig indeholde en forkert beslutning, så forretningsnøjagtighed skal evalueres med reelle data. Tekst er aktuelt det understøttede inputformat, og engelsk giver den stærkest dokumenterede performance. Andre sprog kræver separat test.

Jevs hastigheds- og omkostningsresultater kommer fra TypeSafes egne evalueringer og bør ikke behandles som universelle performancegarantier.

Jev and CometAPI

På tidspunktet for gennemgangen den 21. september 2026 var Jev ikke opført som en generelt tilgængelig model i CometAPIs offentlige katalog. CometAPI planlægger at evaluere og integrere Jev, når adgang bliver tilgængelig, og den nødvendige forbindelse er åbnet. Udviklere bør tjekke CometAPI model directory for den seneste tilgængelighed.

Jev kan i øjeblikket tilgås via TypeSafe-konsollen og dets officielle API. TypeSafe leverer også officielle Python- og JavaScript-SDK’er. Den nuværende API bruger state og typebestemte questions, med jev-latest som stabil modelalias.

Når Jev bliver tilgængelig via CometAPI, vil udviklere kunne finde dens model-ID, understøttede endpoint, priser og forespørgselsformat i CometAPI API-dokumentation og modelkatalog.

Frequently Asked Questions

What is Jev AI?

Jev er TypeSafes flagskibsmodel og deres første System One model. Den evaluerer tekstbaseret tilstand mod typebestemte spørgsmål og returnerer strukturerede beslutninger og sandsynligheder i stedet for genereret tekst.

Is Jev a large language model?

TypeSafe præsenterer ikke Jev som en traditionel LLM. De kalder Jev en System One model bygget til strukturerede beslutninger. Virksomheden har ikke offentliggjort modelparametre, så modellen bør ikke klassificeres som stor eller lille baseret på offentlige oplysninger.

What are Choice, Score, and Noul?

Choice vælger en mulighed fra et defineret sæt og returnerer sandsynligheder plus konfidens. Score placerer tilstand på en ordnet rubric og returnerer også sandsynligheder plus konfidens. Noul returnerer en værdi fra 0 til 1, der repræsenterer sandsynligheden for, at et udsagn er sandt.

Does Jev generate text or code?

Nej. Jev returnerer begrænsede beslutninger. En generativ model kræves, når et workflow har brug for prosa, dialog, kildekode eller en åben forklaring.

Can Jev replace GPT, Claude, or Gemini?

Nej. Jev adresserer afgrænsede beslutningsopgaver, mens generelle LLM’er håndterer generering og udvidet ræsonnering. Et produktionssystem kan bruge begge modeltyper til forskellige faser af samme workflow.

Does Jev support images, audio, or video?

Ikke direkte. Den aktuelle model accepterer tekst som en streng, et JSON-objekt eller et array af tekstværdier. Ikke-tekstinput skal først konverteres til tekst eller strukturerede felter.

Does type-safe output guarantee a correct decision?

Nej. Typesikkerhed garanterer, at output overholder den understøttede struktur. Jev kan stadig vælge en forkert gyldig mulighed eller tildele en unøjagtig sandsynlighed. Forretningsnøjagtighed skal måles med repræsentative data.

Is Jev open source?

TypeSafe har ikke offentliggjort Jevs modelvægte. Virksomheden udgiver dokumentation, SDK’er, eksempler og relateret integrationskode, men disse ressourcer gør ikke modellen open weight.

Conclusion

Jev introducerer et modelinterface bygget omkring beslutninger snarere end sprogproduktion. Den accepterer delt tilstand og atomare, typebestemte spørgsmål og returnerer derefter kategorier, scorer, binære sandsynligheder og usikkerhedsmål, som software kan bruge direkte.

Dens mest troværdige rolle er ikke at erstatte generelle LLM’er. Det er at håndtere hyppige, afgrænsede domme omkring dem. Kundesupport-routing, modelvalg, værktøjsrisikokontrol, outputverifikation, moderation og workflow-klassifikation passer alle i det mønster, når svarrummet er defineret på forhånd.

Produktionsværdi afhænger af mere end lav latens eller et gyldigt skema. Teams har brug for repræsentative evalueringer, kalibrerede tærskler, eksplicitte tilladelsesregler, modelversionskontrol og veje til menneskelig review. TypeSafes publicerede hastigheds- og omkostningstal gør Jev værd at teste til beslutningstunge workloads, men påstandene er bundet til virksomhedens evalueringsmetode og bør verificeres på reelle applikationsdata.

For teams, der allerede bruger flere generative modeller via CometAPI, illustrerer Jev en bredere arkitektur, hvor generering, probabilistisk dom, deterministisk politik og værktøjsudførelse er separate komponenter. Denne adskillelse gør hver del lettere at teste og giver applikationskoden den endelige kontrol over, hvad der sker næste gang.