"System One" come categoria di modello: dove si colloca Jev 1.13

"System One" è il termine di categoria che TypeSafe usa per la sua divisione tra un modello che decide e un modello che scrive, e Jev 1.13 (typesafe/jev-1.13) è il suo primo membro — un modello che restituisce risposte tipizzate invece di frasi. Non è un nuovo modello. TypeSafe ha rilasciato Jev il 2026-09-15, e questa pagina non è un articolo di lancio: il modello ha quindici giorni ed è fuori dalla finestra di sette giorni a cui questo blog scrive. Quello che è successo dentro la finestra è che OrcaRouter ha aggiunto il modello al suo catalogo il 2026-09-24 e ha aperto la scheda del modello per Jev 1.13 su https://www.orcarouter.ai/models/typesafe/jev-1.13 — la prima volta che è richiamabile attraverso un gateway di terze parti anziché solo attraverso l'endpoint di TypeSafe stesso. L'idea della categoria è la ragione per cui esiste questa pagina; il cambiamento nel serving è la ragione per cui è datata oggi.

La versione semplice della categoria: a un LLM viene posta una domanda e scrive una risposta destinata a una persona. A un modello System One viene posta una domanda e restituisce un valore sul quale un programma può diramarsi. La formula coniata da TypeSafe stessa è che «gli LLM producono parole per le persone» mentre «Jev produce decisioni tipizzate ed è più simile al codice: affidabile, veloce, coerente con sé stesso e type-safe». Quella frase è l'intera categoria compressa in un'unica proposizione, e vale la pena di scomporla con calma, perché i quattro aggettivi fanno una quantità di lavoro diversa e uno di essi ne fa più degli altri.

Che cosa sostiene davvero "più simile al codice"

Prendi le quattro affermazioni in ordine, perché non sono quattro riformulazioni di «è meglio».

• Affidabile — la forma dell'output è fissata in anticipo. Dichiari la domanda; la risposta può tornare solo come uno dei valori che hai consentito. TypeSafe afferma chiaramente che "il modello non commette mai errori di tipo", e nota che questa è l'unica loro affermazione che sia "matematicamente impossibile" da falsificare con un controesempio, perché un valore che non è nell'insieme che hai dichiarato non è un valore che il modello può emettere.

• Veloce — tutte le risposte vengono prodotte in un'unica passata anziché un token dopo l'altro. Il post di lancio di TypeSafe lo descrive così: "Jev produce tutte le probabilità in parallelo invece di generarle in modo autoregressivo token per token". Nella nostra finestra di servizio di sette giorni che termina il 2026-09-30, il tempo mediano al primo token su typesafe/jev-1.13 è di 151 ms e il p95 è di 247 ms.

• Autocoerente — lo stesso stato con le stesse domande tende a produrre le stesse risposte. Un'analogia con la programmazione è ciò che lo rende leggibile, ma è anche il punto in cui l'analogia smette di essere una prova: il determinismo di un compilatore è una proprietà della sua costruzione, mentre questa è un'affermazione su un comportamento. Le nostre stesse misurazioni sono la lettura onesta in merito — il tasso di errore sul traffico del nostro playground nella stessa finestra di sette giorni è dello 0,49%, quindi è autocoerente come lo è una buona funzione, non come lo è l'aritmetica.

• Type-safe — e questa è quella che pesa di più. Type-safe qui non è un aggettivo di qualità; è un'affermazione su dove si colloca il modello rispetto a un type checker. In una pipeline generativa ordinaria il sistema di tipi entra in gioco dopo che il modello ha finito: il modello scrive testo, un parser tira a indovinare la forma, un validatore la controlla e un percorso di errore gestisce i casi in cui l'ipotesi era sbagliata. Un modello System One sposta la dichiarazione di tipo prima della chiamata. Le tre primitive documentate nella nostra scheda sono il sistema di tipi: noul, un giudizio vero/falso restituito con una probabilità calibrata; choice, un'etichetta scelta tra un massimo di 255 opzioni etichettate; e score, una valutazione su una scala ordinata da 2 a 10 livelli. Scegli la primitiva, fornisci le etichette o i criteri, e il valore che ti torna indietro è tratto da quell'insieme.

TypeSafe pubblica effettivamente una differenza tra la propria documentazione e la nostra che vale la pena segnalare anziché risolvere: la documentazione del fornitore mostra un esempio di Score con indicizzazione a partire da zero, mentre la nostra scheda documenta la scala come livelli da 2 a 10. Entrambe descrivono la stessa primitiva. Se stai costruendo una soglia, consulta la pagina del fornitore per l'indicizzazione esatta su cui si basa il tuo SDK.

Le due modalità di guasto che smettono di esistere

La conseguenza interessante di «niente prosa» non è estetica. È che i due fallimenti che dominano le pipeline generative di produzione sono assenti da questo design piuttosto che mitigati da esso.

La deriva del formato è la prima. Un LLM a cui viene detto di restituire JSON restituisce JSON la maggior parte delle volte, e qualcosa di adiacente a JSON il resto del tempo — un commento in coda, un blocco markdown, un campo rinominato con un sinonimo, un oggetto annidato dove lo schema voleva una stringa. Le correzioni a livello di prompt (istruzioni più forti, esempi few-shot, uno schema nel messaggio di sistema) sono tutti tentativi di mantenere una forma che il modello è libero di abbandonare, perché la forma è una richiesta, non un vincolo. L'impostazione di TypeSafe rende esplicito il contrasto: con le stringhe, "possibili output e struttura" sono richiesti e le risposte "devono essere analizzate + convalidate", con "sempre qualche rischio che l'IA deragli". Quando i possibili output sono dichiarati in anticipo, la deriva non ha dove andare.

L'output non interpretabile è il secondo, e in realtà è lo stesso errore in un momento peggiore — non un campo tornato leggermente sbagliato, ma una risposta che il parser non riesce affatto a leggere, che arriva nel punto meno opportuno di un flusso di lavoro. Un modello che emette un valore tipizzato non ha questo stato.

Questo è un argomento strutturale, e dovrebbe essere presentato come tale. Non dice nulla sul fatto che una singola risposta sia corretta — una domanda a scelta può scegliere l'etichetta sbagliata, e un noul può restituire true con grande sicurezza quando la risposta onesta è falsa. Ciò che scompare è la categoria di errore che un parser avrebbe individuato. Si tratta di una riduzione reale e utile, e non è la stessa affermazione di "le risposte sono giuste".

Perché il prezzo è una forma, non uno sconto

Il modello ha un prezzo di 0,042 $ per milione di token di input, con l'output fatturato a zero — e quello zero non è una tariffa promozionale, è un artefatto del design. Un modello che emette tre token di risposta strutturata non ha alcun volume di output da misurare, quindi il prezzo per token di output non ha nulla a cui agganciarsi. La struttura di fatturazione è un addebito per token di input e una decisione. Il nostro catalogo applica il prezzo di listino del fornitore con uno 0% di ricarico, quindi 0,042 $ è un numero di TypeSafe, non un numero che abbiamo fissato noi, e una variazione di prezzo del fornitore sarebbe attiva lo stesso giorno.

Metti le due forme una accanto all'altra e la differenza non è una percentuale. Il costo di una pipeline generativa cresce in base a quanto dice il modello: una risposta prolissa costa più di una concisa a parità di decisione, e un modello di ragionamento chain-of-thought fa pagare i token che impiega a pensare prima di rispondere, che la risposta migliori o no. Il costo di una chiamata a System One cresce in base a quanto gli mostri: lo stato e le domande. Fai una domanda su un documento lungo e paghi per il documento. Metti quaranta domande sullo stesso stato (il budget di input sulla nostra scheda è di 65.536 token tra stato e domande combinati, circa 64K; se hai visto una cifra di "circa 32.000 token" in articoli precedenti di OrcaRouter, quella è solo il budget dello stato, non un totale concorrente) e paghi per il documento una volta sola e ricevi indietro quaranta decisioni.

Ecco perché il costo per decisione, non il costo per token, è l'unità giusta per questa classe — e perché il contatore gira nella direzione opposta rispetto a ciò che la maggior parte dei team si aspetta. La tipica mossa di riduzione dei costi nel campo generativo è «far dire di meno al modello». Qui non c'è nulla di meno da dire.

I numeri di TypeSafe, che sono riportati dal fornitore e non sono stati replicati in modo indipendente, mirano esattamente a quel confronto: "193,6x più veloce, 444,6x più economico", con nota a piè di pagina "basato sui risultati per le attività di System One (prova)", con un esempio pratico che recita "Costo AI TypeSafe 0,000081 $ Completato in 0,114 s / Costo LLM 0,013880 $ Completato in 8,566 s". La homepage elenca anche "42 $ per miliardo di token di input" contro "prezzo di input inferiore di 238x rispetto a Claude Fable 5.1". Considera tutto ciò come l'argomentazione del fornitore, non come un risultato misurato: il post di lancio ammette che "le nostre valutazioni pubblicate vengono generalmente eseguite dai nostri portatili sulla costa occidentale" e che "non possiamo dimostrare che non sia sovvenzionato; avremo bisogno del lungo periodo per dimostrare la sostenibilità dei nostri prezzi (che ci aspettiamo scendano, non salgano)". Queste due ammissioni sono del fornitore stesso, e rappresentano la giusta chiave di lettura per ogni moltiplicatore presente sulla pagina.

La calibrazione è la seconda metà dell'idea

Se la categoria fosse soltanto "output strutturato", descriverebbe il function calling con qualche passaggio in più. La parte che la rende una cosa a sé stante è che ogni risposta arriva con una probabilità, e le probabilità sono l'obiettivo di addestramento. TypeSafe chiama il metodo Reinforcement Learning for Calibrated Decisions (RLCD) — un loro termine, non un acronimo generico — e la tabella di confronto nel post di lancio lo affianca a RLHF e RLVR: RLHF ottimizza per ciò che preferiscono i valutatori umani, RLVR per output verificabili a livello programmatico, e RLCD per "risposte con probabilità epistemicamente oneste su compiti di Sistema Uno".

La differenza pratica sta a cosa serve la probabilità. In una pipeline generativa la stima di confidenza è una seconda generazione: chiedi al modello quanto è sicuro e questo scrive un numero, che è a sua volta prosa con gli stessi modi di fallire. Qui la probabilità viene restituita insieme alla decisione, nello stesso passaggio, ed è l'elemento su cui si basa la diramazione. La stessa descrizione che TypeSafe dà del vantaggio è che un modello che riesce a svolgere un compito il 95% delle volte ma "non dice quando è nel 5%" non può essere usato per automatizzare il compito; la confidenza ti dà un punto in cui collocare l'escalation, verso una persona o verso un modello di ragionamento.

La homepage di TypeSafe lo presenta come "Zero allucinazioni", spiegando che ogni decisione comporta una stima di confidenza, così che il software possa "agire quando la confidenza è alta ed escalare quando non lo è". Leggetelo con attenzione: è un'affermazione sulle stime di confidenza, non un'affermazione che nessuna risposta sia mai sbagliata. La nostra scheda è il contrappeso: un tasso di errore dello 0,49% nei sette giorni che terminano il 30 settembre 2026, sul nostro traffico, misurato da noi. Quel dato è una finestra mobile, non un set di test fisso: indicava lo 0,57% pochi giorni prima sulla stessa finestra, e si muoverà di nuovo.

Dove System One si trova accanto a System Two

Il vocabolario veloce/lento precede di gran lunga TypeSafe. Deriva dall'opera di Kahneman, Pensieri lenti e veloci, ed è stato preso in prestito dai ricercatori di IA per anni prima di ciò — l'etichetta "Sistema 2" era stata associata a modelli di catena di pensiero e di ragionamento deliberato ben prima che TypeSafe esistesse, e TypeSafe non sostiene di aver coniato nessuno dei due termini. Ciò che hanno fatto è applicare la distinzione a un confine di prodotto anziché a una modalità di prompting.

• Un modello di ragionamento Sistema Due spende più calcolo prima di rispondere e migliora sui problemi che lo richiedono. Il suo output è comunque prosa, e il calcolo extra viene fatturato come token di output.

• Un modello System One nel senso di TypeSafe non pensa più a lungo per rispondere meglio. Risponde in un'unica passata, e ciò a cui rinuncia in cambio della velocità è la capacità di produrre qualsiasi cosa tranne un valore tipizzato.

• I due sono complementari in un flusso di lavoro, non rivali in un confronto. Una chiamata di Sistema Uno gestisce le decisioni che devono essere rapide, economiche e leggibili; il modello di ragionamento riceve i casi che il punteggio di confidenza ha segnalato come incerti. L'output tipizzato è ciò che rende pulito il passaggio di consegne — stai passando un valore e una probabilità alla fase successiva, non una frase da ri-analizzare.

Dove il vocabolario diventa scivoloso è nel trattare "System One model" come una categoria consolidata che altri fornitori hanno adottato. Non ci sono prove di ciò, e questa pagina non dovrebbe essere letta come se lo affermasse. TypeSafe usa il termine per la propria classe di modelli; il disclaimer nella nostra stessa scheda dice la stessa cosa per omissione, elencando un singolo tipo di endpoint per un singolo modello. Se un altro laboratorio inizia a usare l'espressione per la stessa architettura, sarà un fatto degno di essere riportato e avrà bisogno delle proprie parole per riportarlo.

La nostra scheda elenca inoltre la spigolosità come parte del confine onesto anziché come una sorpresa: nove modalità di fallimento denominate. Le voci sulla lettura letterale e sull'indirezione sono quelle che derivano direttamente dall'analogia "più simile al codice" — un modello che risponde alla domanda che hai scritto anziché a quella che intendevi si comporta come una funzione che ha fatto esattamente ciò che diceva il codice. La voce sul conteggio no. Un modello che "riconosce la forma di una risposta anziché contare" non è affatto simile al codice, ed è per questo che la raccomandazione di TypeSafe stessa è di contare nel codice e, dove serve davvero un giudizio, di porre una domanda per elemento e sommare tu stesso le risposte.

Due limiti che plasmano il design, non il punteggio

Entrambi provengono dallo stesso posto: nessuna stringa significa niente da trasmettere in streaming e niente da inviare a pezzi.

• Non-streaming — il primo output è la risposta finita, quindi una chiamata System One è una singola risposta, non uno stream. La domanda non è se possa fare streaming, ma che cosa verrebbe trasmesso in streaming.

• Una sola forma di richiesta — il modello viene servito tramite POST /v1/systemone nel nostro catalogo anziché nella forma chat-completions, e questa è la versione onesta di una vecchia affermazione secondo cui «parla la propria forma di richiesta». È una differenza reale nel modo in cui lo chiami: entrano un oggetto di stato e una mappa di domande denominate; esce una risposta strutturata per ogni domanda. Scriverai un mapper per esso e, poiché l'output è tipizzato, il mapper è l'intera integrazione — non c'è alcun livello di parsing difensivo sotto di esso.

Da sapere prima di eseguire un load test: la latenza non è uniforme tra i vari tipi di domanda. TypeSafe spiega perché, con parole loro: "Per le scelte ad alta cardinalità, adottiamo un sistema a 2 fasi, in cui valutiamo in modo indipendente e poi compiamo una scelta esplicita; da qui il rallentamento occasionale." Una decisione di routing a 4 opzioni e una classificazione a 200 opzioni sono la stessa primitiva sulla carta e quantità di lavoro diverse nella pratica. Le nostre mediane giornaliere nei sette giorni che terminano il 2026-09-30 sono 175, 170, 163, 161, 170, 147, 143 ms. Un giorno di quella serie, il 2026-09-28, ha registrato un p95 di 2.448 ms — un vero outlier di un singolo giorno che si colloca onestamente nella serie, ma non è la forma del servizio.

L'altra cosa da sapere prima di una prima integrazione è a che cosa ti stai connettendo. Gli strumenti attorno a Jev sono open source con licenze MIT e Apache-2.0 — gli SDK Python e JavaScript, un adattatore che presenta lo stesso client basato su normali API LLM, il codice di workflow-evals e una serie di competenze per agenti, tutti nei repository pubblici di TypeSafe, con numero di stelle e date di push che si sono aggiornati di recente, addirittura il 2026-09-26 e il 2026-09-29. Il modello no. Non esiste un repository dei pesi: l'architettura, il numero di parametri, il calcolo di addestramento e i pesi di Jev non sono pubblicati, e un lettore che lo verifica non dovrebbe lasciarsi ingannare dai tre repository in quell'organizzazione che sono fork di progetti non correlati — un fork di vLLM, un rilascio di modello linguistico a diffusione del 2025 e un provider Pulumi. Nessuno di essi dice nulla su come sia costruito Jev. La risposta in una riga è che gli strumenti sono aperti e il modello no.

Eseguirlo oggi, e cosa cambia per chi legge

Jev 1.13 è su OrcaRouter come typesafe/jev-1.13, raggiungibile con la stessa chiave di oltre 200 altri modelli, con il prezzo di listino del provider trasferito senza alcun ricarico. Il valore pratico di ciò in una pagina dedicata a una categoria è limitato e vale la pena dichiararlo con precisione: provare un modello System One non richiede più un account separato, una chiave separata e una fattura separata per un modello che potresti ancora non sapere di volere. Si trova accanto alla metà generativa dello stesso flusso di lavoro — il classificatore e lo scrittore su un'unica credenziale, in un unico posto, con i conteggi di ciò che hai effettivamente chiamato.

Nulla di tutto questo cambia ciò che il modello è. È stato lanciato il 2026-09-15 e TypeSafe lo descrive ancora come accesso anticipato; ciò che è non è cambiato da allora. Ciò che è cambiato il 2026-09-24 è che ora un lettore può scoprire quanto gli costa nella pratica senza doversi prima impegnare in un rapporto con un secondo fornitore. Se stavi aspettando di capire se la categoria merita un prototipo, è questo l'aspetto che è cambiato.