Il 15 settembre 2026 TypeSafe AI ha presentato Jev, un modello che in un mercato ossessionato dalla generazione di testo fa una cosa sola: prende decisioni. Niente parole, niente frasi, nemmeno una motivazione scritta. Gli dai lo stato di un processo e una lista di domande, e ti restituisce le risposte con le probabilità associate.
In sintesi: Jev è il primo modello della categoria che TypeSafe chiama System One, non autoregressiva, cioè che non costruisce la risposta un token alla volta ma la produce tutta insieme in una passata parallela. Nel benchmark pubblicato dall’azienda decide in 0,4 secondi a 0,0004 dollari a caso, contro i 23,3 secondi e 0,0836 dollari di GPT-5.6 Sol, con un’accuratezza del 67,8% contro il 74,1%. Più veloce e molto più economico, misurabilmente meno preciso del miglior modello linguistico sullo stesso compito.
📌 Punti chiave di questo articolo
- Jev non genera testo: restituisce decisioni tipizzate con probabilità calibrate, in una sola chiamata parallela.
- Tre tipi di domanda: scelta tra opzioni (fino a 255), punteggio su una scala, e una domanda con risposta sì/no espressa come probabilità.
- Prezzo: 0,042 dollari per milione di token in input, output gratuiti, circa 0,0004 dollari a decisione.
- Accuratezza dichiarata dal produttore: 67,8% contro il 74,1% del miglior modello linguistico testato. Il risparmio si paga in precisione.
- Zero errori di formato (0% sia su output strutturato sia su chiamate a strumenti), dove Claude Haiku 4.5 sbaglia formato nel 45,5% dei casi.
- Limite principale: non scrive una riga, quindi non sostituisce un LLM, lo affianca nei punti dove il software deve solo decidere.
Cos’è un modello System One, e perché il nome non è marketing
Il nome arriva dalla distinzione di Daniel Kahneman tra pensiero veloce e pensiero lento. System 1 è la decisione immediata, automatica, quella che prendi senza costruire un ragionamento: questo messaggio è urgente, questa pratica è incompleta, questo utente va passato a un umano. System 2 è il ragionamento disteso, quello che produce un’analisi o un testo.
Quasi tutta l’AI dentro i software oggi è System 2 usata per fare System 1. Chiedi a un modello linguistico di scrivere un JSON con tre campi, il modello lo compone parola per parola, tu lo leggi, lo validi e ogni tanto rifai la chiamata perché il formato è venuto storto. Paghi un motore capace di scrivere un saggio per ottenere la parola “urgente”.
TypeSafe ha passato due anni in stealth a costruire l’alternativa. Il fondatore è Diogo Almeida, che in OpenAI ha lavorato all’apprendimento per rinforzo da feedback umano, la tecnica dietro ChatGPT. Qui l’ha girata: invece di ottimizzare il modello sulle preferenze delle persone (RLHF), lo ottimizza su decisioni calibrate rispetto agli esiti reali, un metodo che l’azienda chiama Reinforcement Learning for Calibrated Decisions. L’obiettivo non è piacere a chi legge, è che quando il modello dice 90% abbia ragione nove volte su dieci.
Come funziona Jev: stato, domande, risposte
L’interfaccia è un solo endpoint. Mandi due cose: lo stato, cioè il materiale grezzo su cui decidere, e le domande, cioè lo schema delle decisioni che il tuo software deve prendere. Le domande vengono valutate tutte in parallelo sullo stesso stato.
POST https://api.typesafe.ai/v1/systemone
{
“model”: “jev-latest”,
“state”: “Buongiorno, mi avete addebitato l’abbonamento due volte questo mese.”,
“questions”: {
“categoria”: { “type”: “choice”, “options”: [“fatturazione”, “tecnico”, “commerciale”] },
“urgenza”: { “type”: “score”, “min”: 0, “max”: 100 },
“a_umano”: { “type”: “noul” }
}
}
La risposta arriva nella stessa forma: categoria: “fatturazione”, urgenza: 87, a_umano: 0.92, ognuna con la sua distribuzione di probabilità e un punteggio di confidenza. I tipi di domanda disponibili sono tre: choice (una scelta tra opzioni che definisci tu, fino a 255), score (una posizione su una scala) e noul (una domanda sì/no, restituita come probabilità tra 0 e 1).
La parte interessante per chi costruisce software è la confidenza. Non è un numero decorativo: serve a scrivere la regola di instradamento. Sopra una certa soglia il sistema agisce da solo, in mezzo passa a un LLM che ragiona, sotto va a una persona. È l’autonomia graduata degli agenti resa esplicita da un numero, invece che affidata a un prompt che dice “se non sei sicuro chiedi conferma”.
Jev accetta solo testo: stringhe, oggetti JSON e array di testo. Niente immagini, niente audio, niente PDF letti come pagina. Se il documento va prima trasformato in testo, quel pezzo resta a carico tuo.
I numeri: velocità, costo e il dato di accuratezza che TypeSafe non nasconde
Questa è la tabella che conta, ed è la stessa pubblicata da TypeSafe su un benchmark di quattro flussi di lavoro costruiti dal suo team. Sono numeri del produttore, quindi vanno letti come tali, ma hanno il pregio di includere il dato scomodo.
| Modello | Accuratezza | Costo per decisione | Tempo |
|---|---|---|---|
| Jev | Accuratezza: 67,8% | Costo: 0,0004 $ | Tempo: 0,4 s |
| GPT-5.6 Terra | Accuratezza: 67,9% | Costo: 0,0304 $ | Tempo: 10,1 s |
| GPT-5.6 Sol | Accuratezza: 74,1% | Costo: 0,0836 $ | Tempo: 23,3 s |
| Claude Opus 5 | Accuratezza: 73,1% | Costo: 0,1761 $ | Tempo: 37,8 s |
Benchmark a quattro flussi di lavoro pubblicato da TypeSafe AI, settembre 2026. Dati del produttore.
Tradotto in una riga: Jev è alla pari con GPT-5.6 Terra come accuratezza, costando 76 volte meno e rispondendo 25 volte più in fretta. Contro il modello migliore del confronto perde poco più di sei punti di accuratezza, e su quei sei punti si gioca tutta la decisione di adottarlo o no.
C’è un secondo dato, meno citato e per chi costruisce software forse più importante: l’affidabilità del formato. Jev riporta 0% di errori sull’output strutturato e 0% sulle chiamate a strumenti, per costruzione, perché la risposta non può uscire dallo schema. Nello stesso confronto Claude Haiku 4.5 sbaglia il formato nel 45,5% dei casi e GPT-5.6 Sol sbaglia una chiamata a strumento su sei. Chiunque abbia messo in produzione una pipeline che parsa JSON generato da un LLM sa quanto codice difensivo sparisce con quel numero a zero.
Attenzione a cosa significa davvero “zero allucinazioni”, perché è il punto su cui la comunicazione di TypeSafe è più scivolosa. La garanzia è sulla forma: se le opzioni sono tre, la risposta è una di quelle tre. Nel merito il modello può sbagliare, e infatti sbaglia in circa un caso su tre. Il ticket classificato come tecnico può essere di fatturazione.
I numeri di marketing e quelli dei test indipendenti
Il titolo che gira ovunque è “194 volte più veloce e 445 volte più economico”. Viene dalle demo registrate da TypeSafe (0,114 secondi a 0,000081 dollari contro 8,566 secondi a 0,013880 dollari) ed è il valore di picco, non la media. L’azienda stessa scrive che questi guadagni stanno nella fascia alta dei casi reali, e che il confronto usa come riferimento modelli OpenAI e Anthropic scelti da loro.
Le misure di terze parti, per ora poche, vanno nella stessa direzione con numeri diversi:
- Every, su compiti di estrazione dati, ha misurato circa 25 volte più veloce e circa 580 volte più economico rispetto a un modello di frontiera, definendo il risultato buono ma non perfetto.
- Vercel, che lo distribuisce sul suo AI Gateway, riporta l’adozione più rapida mai vista sulla piattaforma: quasi il 13% dei team a pagamento lo stava usando entro 24 ore dal lancio.
- LangChain ha pubblicato una propria valutazione su un agente costruito attorno a Jev, coerente con le rivendicazioni su quella categoria di compiti.
Quello che ancora non esiste è un benchmark indipendente completo, compito per compito, che confronti Jev sia con gli LLM sia con i classificatori tradizionali. Finché non c’è, l’unico numero che conta davvero è quello che misuri sui tuoi dati.
Dove conviene davvero in azienda
La regola pratica è semplice: Jev conviene dove le decisioni sono tante, ripetitive e con risposte note in anticipo. Nei progetti che seguiamo, questi sono i punti dove il conto torna quasi sempre.
| Caso d’uso | Decisione richiesta | Perché conviene |
|---|---|---|
| Smistamento ticket ed email | Decisione: Categoria, urgenza, se serve una persona | Perché: Volumi alti, risposte note, la latenza si sente in chat |
| Estrazione campi da documenti | Decisione: Tipo di documento, campi presenti, completezza | Perché: Zero errori di formato, niente validazione difensiva |
| Priorità e punteggi | Decisione: Rischio, qualità di un lead, probabilità di abbandono | Perché: Probabilità calibrate, confrontabili tra loro |
| Guardrail su un altro modello | Decisione: Questa risposta si può mandare al cliente? | Perché: Costa quasi nulla, quindi puoi controllarle tutte |
| Passi di un agente | Decisione: Quale strumento usare, se continuare o fermarsi | Perché: Toglie secondi a ogni passo di un ciclo lungo |
Cinque punti in cui un modello di decisione sostituisce una chiamata a un LLM senza perdere nulla di utile.
Un conto concreto, perché è quello che cambia le priorità di un budget. Un servizio clienti che smista 100.000 messaggi al mese spende circa 40 dollari con Jev, 3.040 con GPT-5.6 Terra e 8.360 con GPT-5.6 Sol, ai prezzi del benchmark. La differenza tra 40 e 8.360 dollari al mese non è un’ottimizzazione: è la soglia sotto la quale diventa sensato classificare tutto, anche quello che prima non valeva la pena analizzare. Storici di ticket, archivi di email, anni di documenti fermi in una cartella.
È lo stesso spostamento che abbiamo visto arrivare con i modelli che leggono l’intero contesto aziendale: quando il costo unitario crolla di due ordini di grandezza, non fai la stessa cosa risparmiando, fai cose che prima non facevi.
Limiti, rischi e le domande da fare prima di metterlo in produzione
Il limite più ovvio è quello dichiarato: Jev non scrive. Nessuna email, nessun riassunto, nessun codice, e nemmeno una spiegazione della decisione presa. Se ti serve capire perché un ticket è stato classificato in un certo modo, quella motivazione devi ricostruirla tu dalle probabilità, oppure chiederla a un LLM, che nel frattempo ti costa di nuovo quanto costava prima.
Gli altri punti aperti, in ordine di quanto pesano su un progetto reale:
- Sei punti di accuratezza in meno rispetto al modello migliore. Su uno smistamento è accettabile, su una decisione che tocca soldi o persone va misurato caso per caso, sui propri dati, prima di spostare qualcosa.
- Modello chiuso e giovane. I pesi non sono pubblici, non esiste installazione sui propri server, l’accesso è via API in early access con lista d’attesa (oppure tramite l’AI Gateway di Vercel). L’azienda ha 40 milioni di dollari raccolti e pochi giorni di vita pubblica.
- Dove finiscono i dati. Prima di mandare messaggi di clienti a un endpoint americano vanno chiariti trattamento e conservazione, come per qualsiasi altro fornitore. È lo stesso ragionamento che facciamo sulla sicurezza dei dati con i modelli generativi: la pseudonimizzazione prima della chiamata resta la difesa più semplice.
- Prezzi non ancora stabili. Token di output gratuiti e input a 0,042 dollari per milione sono numeri da lancio, in un momento in cui nessuno sa quanto di quel prezzo sia sostenibile. Un progetto che regge solo a quel costo è un progetto fragile.
- Un nuovo punto di dipendenza. Vale la regola di sempre: se il valore del sistema sta nelle decisioni, quelle decisioni vanno definite in casa, in modo che cambiare fornitore costi una settimana e non un trimestre.
Cosa fare adesso, in pratica
Il passaggio più utile non riguarda il modello. Per usare Jev devi scrivere prima l’elenco delle decisioni che il tuo software prende, con le risposte possibili di ognuna. Nelle aziende con cui lavoriamo quella lista non esiste quasi mai: chiedi con quale regola un ticket diventa urgente e arrivano tre risposte da tre persone diverse.
Quel lavoro ha valore anche se poi Jev non lo adotti. È la stessa disciplina che serve per costruire un agente affidabile, e ha il vantaggio di essere verificabile: una lista di decisioni si può discutere con chi fa quel lavoro tutti i giorni, un prompt lungo due pagine no.
Un percorso ragionevole in quattro passi:
- Prendi 200 casi storici già decisi da persone (ticket, email, pratiche) e usali come metro di paragone.
- Scrivi le domande: categoria, urgenza, se serve un umano. Massimo tre o quattro per iniziare.
- Misura l’accuratezza sui tuoi dati, non sui benchmark, e guarda quanto costa un errore in ciascuna direzione.
- Fissa la soglia di confidenza sopra la quale il sistema decide da solo, e scrivi nero su bianco chi risponde quando sbaglia.
L’ultimo punto è quello che in genere fa fallire i progetti, e non ha niente di tecnico. Un modello che restituisce 92% sposta una decisione di rischio dalle spalle del modello a quelle dell’organizzazione: qualcuno deve stabilire se 92 basta. È lo stesso nodo che incontriamo in ogni progetto di automazione seria, e nessun modello, per quanto calibrato, lo risolve al posto tuo.
Per anni l’unità di misura dell’AI nei software è stata il token generato. Jev propone un’altra unità: la decisione presa, a quattro decimi di centesimo l’una. Se quel prezzo regge, la domanda per chi costruisce software cambia di conseguenza: non più quanto testo ci serve, ma quante delle decisioni che prendiamo ogni giorno siamo in grado di scrivere per esteso.