Che cos'è Jev? Il modello System One di TypeSafe spiegato

TL;DR

Jev è un modello di decisione sviluppato da TypeSafe AI. TypeSafe ha presentato Jev il 15 settembre 2026 come il suo primo modello System One, progettato per restituire decisioni strutturate e probabilità che il software può utilizzare direttamente. Questa guida si basa principalmente sulla documentazione ufficiale di TypeSafe, sulla guida Quick Start, sul riferimento del modello e sull’annuncio ufficiale di Jev dell’azienda.

Jev non scrive prosa, non genera codice e non sostiene una conversazione. Valuta uno stato testuale rispetto a domande tipizzate e restituisce risposte strutturate che un’applicazione può usare direttamente.

La distinzione è importante per i flussi software. Un modello linguistico convenzionale produce token, anche quando un’applicazione ha bisogno solo di una categoria, di un punteggio o di un giudizio sì/no. Jev è progettato attorno alla decisione stessa. La sua interfaccia accetta uno stato e una o più domande, quindi restituisce valori tipizzati e distribuzioni di probabilità. Le risposte di tipo Choice e Score includono anche un valore di confidenza.

Jev è pensato per classificazione, instradamento, scoring, verifica, guardrail e altre decisioni limitate. Non è un sostituto generale di GPT, Claude, Gemini o altri modelli generativi. In un agente AI, un modello generativo può pianificare o creare contenuti mentre Jev gestisce decisioni frequenti come selezionare un percorso, verificare il rischio o decidere se un risultato necessita di revisione.

Punti chiave

• Jev è sviluppato da TypeSafe ed è attualmente presentato come il suo modello di punta System One.
• Il modello accetta uno stato testuale più domande tipizzate. Restituisce decisioni strutturate invece di prosa generata.
• Jev supporta tre tipi di domande denominati Choice, Score e Noul.
• Più domande possono essere valutate in modo indipendente e in parallelo sullo stesso stato in una singola richiesta.
• TypeSafe addestra Jev con Reinforcement Learning for Calibrated Decisions, o RLCD.
• L’attuale pagina ufficiale del modello elenca Jev 1.13 con un limite di 64.000 token per richiesta e input solo testuale.
• Il prezzo ufficiale è di $0,042 per milione di token in input. I token in output sono indicati come gratuiti.
• Un output con sicurezza dei tipi evita incongruenze di schema. Non garantisce che ogni decisione di business sia corretta.
• TypeSafe riporta una latenza tra 70 e 500 millisecondi e grandi guadagni nelle proprie valutazioni di workflow. Queste cifre sono riportate dal fornitore e si applicano a compiti modellati come System One.

Che cos’è Jev?

Jev è un modello di decisione costruito da TypeSafe AI. La documentazione ufficiale lo descrive come il modello di punta dell’azienda e il primo modello System One. Il suo input ha due parti principali.

La prima parte è lo stato. Lo stato è l’informazione che Jev deve ispezionare, come un messaggio di un cliente, un rapporto d’incidente, una raccolta di record o un oggetto JSON contenente il contesto dell’applicazione.

La seconda parte è un insieme di domande tipizzate. Ogni domanda definisce il giudizio da formulare e la forma consentita della risposta. Jev valuta le domande rispetto allo stato e restituisce risultati su cui il codice può diramarsi, ordinare, assegnare punteggi o instradare.

Si consideri una richiesta di assistenza che segnala che un’integrazione di pagamento è fallita da tre giorni. Un sistema di supporto potrebbe non aver bisogno di un paragrafo descrittivo. Potrebbe invece necessitare di tre decisioni ristrette:

• A quale team assegnare il ticket?
• Quanto frustrato appare il cliente?
• Il messaggio richiede attenzione urgente?

Jev può rappresentare queste come una domanda Choice, una Score e una Noul in un’unica richiesta. La risposta contiene la categoria selezionata o il punteggio, la relativa distribuzione di probabilità e la confidenza laddove supportata. L’applicazione decide quindi come utilizzare quei valori.

Questa divisione delle responsabilità è deliberata. Il modello fornisce un giudizio incerto in un formato stabile. Il codice dell’applicazione mantiene il controllo su soglie, permessi, effetti collaterali e comportamenti di fallback.

Che cos’è un modello System One?

TypeSafe utilizza il termine modello System One per una classe di modelli progettati per prendere decisioni rapide e strutturate consumabili dal software. Il nome deriva dalla distinzione tra pensiero veloce e lento associata al lavoro di Daniel Kahneman. Descrive il ruolo previsto del modello, non afferma che un modello software riproduca la cognizione umana.

Un compito System One ha un obiettivo limitato. Un revisore esperto dovrebbe poter formulare il giudizio rapidamente quando gli viene fornito un contesto adeguato. Esempi includono scegliere un intento, valutare l’urgenza su una scala definita, verificare se un’affermazione è supportata o decidere se una richiesta deve essere escalata.

I compiti che richiedono ricerca estesa, deduzione multi-step, spiegazione lunga o creazione di contenuti non sono un fit naturale. TypeSafe raccomanda di decomporre giudizi ampi in domande atomiche e di combinare i loro risultati nel codice.

Ad esempio, valutare questo pitch di startup è troppo ampio per produrre una decisione ispezionabile. Dimensione del mercato, fattibilità tecnica e differenziazione possono invece essere valutate come domande separate. L’applicazione può combinare tali punteggi con una formula esplicita. Se le priorità di business cambiano, i pesi possono cambiare nel codice senza trasformare il prompt del modello in logica di business nascosta.

Come funziona Jev?

Il contratto operativo di Jev può essere scritto come:

State + domande tipizzate -> decisioni tipizzate + probabilità

Questo differisce dal flusso usuale dei modelli linguistici:

Prompt -> token generati -> parsing e convalida -> decisione dell’applicazione

La distinzione non è solo un formato di risposta diverso. L’output strutturato tradizionale chiede comunque a un modello generativo di produrre una sequenza di token che conformi a uno schema. Jev è progettato per restituire valori da spazi di risposta definiti in anticipo.

L’API attuale accetta lo stato come stringa, oggetto JSON o array di valori testuali. L’input è solo testuale. Immagini, audio, video e documenti binari devono essere convertiti in testo o campi strutturati prima dell’invio.

Ogni domanda in una richiesta è valutata indipendentemente rispetto allo stesso stato. Secondo la documentazione di TypeSafe, aggiungere domande cambia appena il tempo di risposta perché le domande sono valutate in parallelo. L’indipendenza impedisce anche che la risposta di una domanda diventi contesto per un’altra nella stessa chiamata.

Questo comportamento ha una conseguenza progettuale importante. Se una decisione dipende realmente da un’altra, la dipendenza appartiene al workflow dell’applicazione. Eseguire la prima valutazione, aggiornare lo stato o diramarsi nel codice, quindi effettuare la valutazione successiva. Una singola richiesta è più adatta a domande che condividono evidenze ma non dipendono dalle risposte reciproche.

I tre tipi di domande di Jev

Jev espone tre primitive. Ciascuna corrisponde a un diverso tipo di decisione software.

Choice

Una domanda Choice seleziona un’opzione da criteri definiti dall’applicazione. Un workflow di supporto potrebbe fornire billing, technical e sales, con una descrizione per ciascuna categoria. Jev restituisce l’opzione selezionata, la probabilità assegnata a ogni opzione e un valore di confidenza derivato dalla forma di tale distribuzione.

La progettazione delle categorie influisce sull’utilità del risultato. Opzioni sovrapposte creano ambiguità. Opzioni mancanti forzano il modello verso una risposta che potrebbe non adattarsi. Le tassonomie di produzione dovrebbero includere una rotta come insufficient_evidence o human_review quando il workflow deve preservare l’incertezza.

La formulazione dovrebbe anche corrispondere alla decisione effettiva. Quale team dovrebbe investigare per primo chiede un instradamento provvisorio. Quale team ha causato il guasto chiede una diagnosi. Potrebbero usare la stessa lista di team, ma non pongono la stessa domanda.

Score

Una domanda Score colloca lo stato su una rubrica ordinata. I criteri possono descrivere livelli come calmo, frustrato e arrabbiato, o definire una scala di business più dettagliata. La risposta include un punteggio numerico, una legenda che collega i numeri ai livelli, una distribuzione di probabilità tra quei livelli e la confidenza.

Una rubrica Score utile descrive differenze osservabili. Etichette senza definizioni lasciano al modello e ai revisori umani il compito di inferire standard diversi. Una scala di rischio dovrebbe indicare cosa separa ciascun livello. Una scala di qualità dovrebbe indicare quali requisiti sono presenti o mancanti.

Se un punteggio mescola preoccupazioni indipendenti, è meglio dividerle. Rilevanza, supporto fattuale, tono e conformità alle policy possono essere domande separate. Il codice dell’applicazione può calcolare un punteggio composito usando pesi che rimangono visibili e verificabili.

Noul

Noul è la primitiva di decisione binaria di TypeSafe. Stima la probabilità che un’affermazione sia vera e restituisce un numero da 0 a 1. Un valore di 0,9 rappresenta una probabilità stimata di verità più alta rispetto a un valore di 0,6.

Noul non restituisce il campo separato confidence usato da Choice e Score. Il suo output è già una probabilità per l’affermazione valutata. La domanda dovrebbe quindi essere scritta come un’affermazione verificabile, come il messaggio trasmette urgenza o la risposta è supportata dalla fonte fornita.

Noul è utile per verifica e gating, ma la soglia appartiene all’applicazione. Un suggerimento a basso rischio per l’interfaccia può tollerare una soglia inferiore rispetto a un’azione finanziaria o amministrativa irreversibile.

Domande atomiche e workflow composti

Jev funziona meglio quando ogni domanda chiede una sola cosa ristretta. Questo design rende l’output più facile da ispezionare e consente al software di possedere la policy finale.

Si supponga che un agente debba decidere se eseguire una chiamata di uno strumento. Una domanda ampia come questa azione dovrebbe essere eseguita può combinare permesso, reversibilità, sensibilità dei dati, intento dell’utente e rischio operativo. Un workflow più ispezionabile valuta separatamente tali dimensioni:

• La chiamata dello strumento è coerente con la richiesta dell’utente?
• Trasmette informazioni sensibili?
• L’azione è distruttiva o difficile da invertire?
• Influisce su un account esterno?
• È richiesta un’ulteriore conferma dalla policy?

L’harness può quindi combinare le risposte con regole deterministiche. Un’operazione distruttiva può richiedere conferma indipendentemente dalla confidenza complessiva del modello. Un’operazione in sola lettura può seguire un percorso meno restrittivo. Questa disposizione mantiene i permessi nel codice e utilizza Jev solo per giudizi che non possono essere espressi in modo affidabile come regole fisse.

Jev vs LLM tradizionali

Jev e i large language model servono ruoli diversi.

Jev non dovrebbe essere descritto come un chatbot più piccolo. TypeSafe non ha pubblicato un conteggio di parametri né dettagli architetturali sufficienti per classificare il modello per dimensione. La sua distinzione pubblica si basa sull’obiettivo di training, sul metodo di campionamento e sull’interfaccia.

Jev non sostituisce nemmeno il codice deterministico. Le regole fisse rimangono lo strumento giusto quando le condizioni sono esplicite e stabili. Un calcolo fiscale, una lista di permessi o un limite di dimensione file non dovrebbero diventare una chiamata a un modello probabilistico. Jev è utile dove le regole scritte a mano sono troppo fragili ma la risposta desiderata può comunque essere delimitata.

Jev vs output strutturato degli LLM

L’output strutturato consente a un modello linguistico di restituire JSON o valori conformi a uno schema. È prezioso quando un workflow necessita sia di ragionamento generativo sia di un risultato leggibile dalla macchina. Jev affronta un problema più ristretto.

Con un LLM, lo schema vincola la forma di una risposta generata. Con Jev, le domande e gli spazi delle risposte sono l’interfaccia del modello. Jev restituisce distribuzioni di probabilità destinate a partecipare alla logica applicativa, e le domande indipendenti sono valutate separatamente rispetto allo stato condiviso.

Forme JSON che combaciano non implicano comportamenti che combaciano. Due sistemi possono restituire entrambi un campo denominato department, ma differire in latenza, calibrazione, gestione dell’ambiguità e stabilità delle risposte. I team che confrontano Jev con l’output strutturato di un LLM dovrebbero mantenere costante lo schema dell’applicazione e testare entrambi i sistemi sugli stessi dati etichettati.

RLCD e decisioni calibrate

TypeSafe afferma che Jev è addestrato con Reinforcement Learning for Calibrated Decisions. RLCD differisce nell’obiettivo da RLHF e RLVR.

RLHF ottimizza le risposte utilizzando segnali di preferenza umana ed è stato ampiamente utilizzato per assistenti conversazionali. RLVR utilizza ricompense verificabili ed è associato a compiti in cui la correttezza può essere controllata programmaticamente. RLCD addestra i modelli di TypeSafe a restituire decisioni e probabilità calibrate invece di testo generato.

La calibrazione riguarda gruppi di previsioni. Se un modello è ben calibrato, gli esiti a cui è assegnata una probabilità intorno a 0,8 dovrebbero essere corretti circa l’80 percento delle volte su un insieme adeguato di casi. Non garantisce che una particolare previsione con probabilità 0,8 sia corretta.

Probabilità e confidenza non dovrebbero essere trattate come intercambiabili. Choice e Score espongono distribuzioni di probabilità complete. TypeSafe deriva la confidenza dalla forma di ciascuna distribuzione. Una distribuzione concentrata su un’opzione produce confidenza più alta; una distribuzione più piatta segnala ambiguità. I team possono utilizzare la confidenza fornita o calcolare un’altra statistica dalle probabilità.

Noul non ha un campo di confidenza separato. Il suo valore è la probabilità stimata che l’affermazione sia vera.

Specifiche del modello Jev e prezzi

I dettagli seguenti provengono dalla documentazione ufficiale del modello di TypeSafe, esaminata il 21 settembre 2026.

TypeSafe osserva che i limiti di velocità si stanno adeguando dinamicamente e possono cambiare senza preavviso. Limiti e prezzi correnti dovrebbero essere verificati prima della messa in produzione.

La documentazione afferma inoltre che l’inglese è la lingua principale di training e attualmente fornisce la migliore accuratezza. Altre lingue, incluse le scritture CJK, sono supportate ma non allo stesso livello. Un carico di lavoro in cinese, giapponese o coreano dovrebbe essere valutato su dati rappresentativi prima di abilitare decisioni automatizzate.

TypeSafe afferma che Jev non è fine-tuned o adattato con LoRA per i dati di ciascun cliente. Gli stessi pesi del modello servono ogni account. Il comportamento di dominio è modellato tramite stato, istruzioni, criteri e composizione lato applicazione. L’azienda afferma inoltre che le richieste e le risposte dei clienti non sono utilizzate per addestrare Jev. I clienti enterprise possono consultare la documentazione legale di TypeSafe per termini di zero data retention.

Quanto è veloce Jev?

TypeSafe riporta tempi di risposta end-to-end tra 70 e 500 millisecondi. Il post di lancio confronta questo intervallo con 3–329 secondi per chiamate selezionate a modelli di frontiera e descrive Jev come 40–200 volte più veloce a livelli di intelligenza comparabili su query modellate come System One.

L’azienda riporta anche guadagni di picco di 193,6 volte in velocità e 444,6 volte in costo nelle sue valutazioni di workflow. Queste cifre richiedono contesto.

Provengono dal framework di valutazione di TypeSafe. I workflow confrontano i modelli su grafi decisionali strutturati e utilizzano le previsioni medie di modelli esterni di fascia alta selezionati come probabilità di riferimento. TypeSafe afferma che i guadagni riportati sono probabilmente vicini al limite superiore dei miglioramenti nel mondo reale e riconosce un possibile bias perché i membri del suo team di capacità del modello hanno creato i workflow.

Questi risultati non dovrebbero essere letti come un’affermazione generale che Jev è centinaia di volte più veloce di ogni LLM su ogni compito. Jev rinuncia alla generazione di testo e si concentra su decisioni limitate. Un confronto equo dovrebbe usare compiti che entrambi i sistemi possono svolgere, misurare la qualità della decisione oltre alla latenza e includere il costo di convalida, retry e revisione umana.

Per cosa è più adatto Jev

Jev è più adatto a workflow ad alto volume con uno spazio di risposta definito e la necessità di stime di incertezza.

• Customer Support Triage: classificare un ticket per reparto, urgenza, frustrazione, rischio di churn o necessità di revisione umana.
• Intent and Model Routing: identificare il tipo di richiesta e instradarla allo strumento, workflow, agente o modello appropriato. La confidenza può determinare se l’instradamento è automatico.
• Agent Tool Risk Checks: valutare le chiamate agli strumenti proposte per azioni distruttive, dati sensibili o incoerenza con la richiesta dell’utente prima dell’esecuzione. Il codice dell’applicazione rimane responsabile dei permessi.
• LLM Output Evaluation: verificare se una risposta di un LLM è supportata dal contesto fornito, segue il formato richiesto o necessita di revisione umana.
• Content Moderation: usare Choice per le categorie di policy, Score per la severità e Noul per controlli binari di regole. I casi a bassa confidenza possono essere inviati ai moderatori.
• High-Volume Data Processing: elaborare log, email, recensioni, lead, annunci o segmenti di documenti quando ogni record può essere valutato in modo indipendente e l’output è una categoria, un punteggio o una probabilità.

Dove si inserisce Jev in un agente AI

Un agente AI tipicamente combina un modello generativo, strumenti, stato dell’applicazione e regole che controllano l’esecuzione. Jev si inserisce in questo sistema come livello decisionale strutturato attorno al principale modello generativo.

Il modello generativo può gestire compiti aperti come interpretare una richiesta, pianificare un workflow, scrivere contenuti o generare codice. Jev può gestire decisioni più ristrette che devono accadere ripetutamente durante il workflow:

• Quale strumento o modello dovrebbe essere usato?
• L’azione proposta è rischiosa o incoerente con la richiesta?
• L’agente dovrebbe continuare, riprovare, fermarsi o chiedere chiarimenti?
• Il risultato soddisfa un requisito definito?
• Il compito dovrebbe essere escalato a un umano?

L’applicazione rimane responsabile di permessi, soglie ed effetti collaterali. Jev fornisce una decisione e la sua probabilità associata, mentre il codice dell’applicazione determina quale azione segue.

Questo crea una divisione delle responsabilità. I modelli generativi gestiscono il ragionamento aperto, Jev gestisce valutazioni limitate, il codice deterministico applica la policy e gli strumenti eseguono azioni esterne. Jev funziona quindi come complemento a un agente AI piuttosto che come sostituto del suo principale modello di ragionamento.

Limitazioni di Jev

Jev non genera prosa, codice o spiegazioni aperte. È progettato per domande focalizzate con spazi di risposta definiti.

Un output con sicurezza dei tipi può comunque contenere una decisione errata, quindi l’accuratezza di business deve essere valutata con dati reali. Attualmente il formato di input supportato è il testo e l’inglese offre la performance documentata più forte. Altre lingue richiedono test separati.

I risultati di velocità e costo di Jev derivano dalle valutazioni di TypeSafe e non dovrebbero essere trattati come garanzie di performance universali.

Jev e CometAPI

Al momento della revisione, il 21 settembre 2026, Jev non era elencato come modello generalmente disponibile nel catalogo pubblico di CometAPI. CometAPI prevede di valutare e integrare Jev non appena l’accesso diventerà disponibile e la connessione richiesta sarà aperta. Gli sviluppatori dovrebbero controllare la directory dei modelli di CometAPI per la disponibilità più recente.

Jev è attualmente accessibile tramite la console di TypeSafe e la sua API ufficiale. TypeSafe fornisce anche SDK ufficiali per Python e JavaScript. L’API attuale utilizza state e questions tipizzate, con jev-latest come alias stabile del modello.

Una volta che Jev sarà disponibile tramite CometAPI, gli sviluppatori potranno trovare il suo ID modello, l’endpoint supportato, i prezzi e il formato della richiesta nella documentazione API di CometAPI e nella directory dei modelli.

Domande frequenti

Che cos’è Jev AI?

Jev è il modello di punta di TypeSafe e il suo primo modello System One. Valuta uno stato testuale rispetto a domande tipizzate e restituisce decisioni strutturate e probabilità invece di testo generato.

Jev è un modello linguistico di grandi dimensioni (LLM)?

TypeSafe non presenta Jev come un LLM tradizionale. Chiama Jev un modello System One costruito per decisioni strutturate. L’azienda non ha pubblicato il conteggio dei parametri, quindi il modello non dovrebbe essere classificato come grande o piccolo sulla base delle informazioni pubbliche.

Cosa sono Choice, Score e Noul?

Choice seleziona un’opzione da un insieme definito e restituisce probabilità più confidenza. Score valuta lo stato su una rubrica ordinata e restituisce anch’essa probabilità più confidenza. Noul restituisce un valore da 0 a 1 che rappresenta la probabilità che un’affermazione sia vera.

Jev genera testo o codice?

No. Jev restituisce decisioni vincolate. È necessario un modello generativo quando un workflow richiede prosa, dialogo, codice sorgente o una spiegazione aperta.

Jev può sostituire GPT, Claude o Gemini?

No. Jev affronta compiti di decisione limitati, mentre gli LLM generali gestiscono generazione e ragionamento esteso. Un sistema in produzione può utilizzare entrambi i tipi di modelli in fasi diverse dello stesso workflow.

Jev supporta immagini, audio o video?

Non direttamente. Il modello attuale accetta testo come stringa, oggetto JSON o array di valori testuali. Gli input non testuali devono essere prima convertiti in testo o campi strutturati.

L’output type-safe garantisce una decisione corretta?

No. La sicurezza dei tipi garantisce che l’output conformi alla struttura supportata. Jev può comunque scegliere l’opzione valida sbagliata o assegnare una probabilità inaccurata. L’accuratezza di business deve essere misurata con dati rappresentativi.

Jev è open source?

TypeSafe non ha rilasciato pubblicamente i pesi del modello Jev. L’azienda pubblica documentazione, SDK, esempi e codice di integrazione correlato, ma tali risorse non rendono il modello stesso open weight.

Conclusione

Jev introduce un’interfaccia del modello costruita attorno alle decisioni piuttosto che alla generazione linguistica. Accetta uno stato condiviso e domande tipizzate e atomiche, quindi restituisce categorie, punteggi, probabilità binarie e misure di incertezza che il software può utilizzare direttamente.

Il suo ruolo più credibile non è sostituire gli LLM generali, ma gestire giudizi frequenti e limitati attorno ad essi. Instradamento del supporto clienti, selezione del modello, controlli di rischio degli strumenti, verifica dell’output, moderazione e classificazione del workflow si adattano a questo schema quando lo spazio di risposta è definito in anticipo.

Il valore in produzione dipende da più di una bassa latenza o di uno schema valido. I team hanno bisogno di valutazioni rappresentative, soglie calibrate, regole di permesso esplicite, controlli di versione del modello e percorsi di revisione umana. Le cifre pubblicate da TypeSafe su velocità e costo rendono Jev degno di test per carichi di lavoro ricchi di decisioni, ma le affermazioni rimangono legate al metodo di valutazione dell’azienda e dovrebbero essere verificate su dati reali dell’applicazione.

Per i team che utilizzano già diversi modelli generativi tramite CometAPI, Jev illustra un’architettura più ampia in cui generazione, giudizio probabilistico, policy deterministica ed esecuzione degli strumenti sono componenti separati. Questa separazione rende ogni parte più facile da testare e dà al codice dell’applicazione il controllo finale su ciò che accade dopo.