Jev è open source? I pesi sono chiusi, gli strumenti no.

No. Jev 1.13 (typesafe/jev-1.13) non è open source, non c'è alcun repository dei pesi da trovare e per quanto si scorra l'organizzazione GitHub di TypeSafe non salterà fuori un checkpoint, un documento di architettura o un numero di parametri. Quello che c'è è il software attorno al modello: undici repository pubblici, ognuno dei quali MIT o Apache-2.0, nessuno dei quali contiene Jev stesso. Questa è la risposta onesta in una riga — il tooling è aperto, il modello no — ed è la metà della storia che un lettore non ricava mai dalla sola dicitura "chiuso, ospitato, non pubblicato". Due date lo inquadrano. TypeSafe ha rilasciato il modello il 2026-09-15, che è fuori dalla finestra di sette giorni di cui si occupa questo blog, quindi questo non è un articolo di lancio e nulla in esso dovrebbe essere letto come tale. L'evento datato è il 2026-09-24, quando OrcaRouter ha aggiunto typesafe/jev-1.13 al proprio catalogo: la prima volta che Jev è stato invocabile attraverso un gateway di terze parti anziché solo tramite l'endpoint di TypeSafe stesso. Questa è l'eccezione su cui si basa questa pagina — un modello che è diventato eseguibile dove non lo era.

Ciò che questo cambia per un lettore è limitato e pratico. Prima del 2026-09-24, valutare Jev significava aprire un secondo rapporto con un fornitore prima di poter testare una singola decisione. Dopo, Jev si trova sulla stessa chiave della metà generativa dello stesso flusso di lavoro: un'unica API per oltre 200 modelli, 0% di ricarico (il prezzo di listino del provider viene passato così com'è, quindi i ribassi di prezzo del fornitore sono attivi qui lo stesso giorno), con il modello raggiungibile su typesafe/jev-1.13. Lo chiami ancora nella sua forma specifica — POST /v1/systemone, non in streaming — perché non è la rotta chat-completions di OpenAI, ma il contratto che firmi e la chiave che ruoti sono quelli che hai già.

La risposta è due risposte, ed entrambe sono necessarie.

"Jev è open source?" suona come una domanda sì/no e si comporta come una domanda in due parti. Prima parte: il modello. È closed source. TypeSafe non ha pubblicato pesi, architettura, dati di calcolo per l'addestramento né numero di parametri per Jev 1.13, e non esiste alcun repository a esso intitolato. Seconda parte: il software circostante. È aperto, attivamente mantenuto e davvero utile, ed è il motivo per cui un lettore che cerca un repository non resta semplicemente a mani vuote.

Confondere le due cose porta alla conclusione sbagliata in entrambe le direzioni. Dai per scontato che tutto sia aperto e passerai un pomeriggio a cercare un checkpoint che non esiste. Dai per scontato che tutto sia chiuso e ti perderai il pezzo che conta davvero, se ti preoccupa il lock-in: un adattatore con licenza MIT che ti consente di costruire sull'interfaccia typed-decision e di cambiare ciò che sta dietro.

Che cosa pubblica davvero TypeSafe

Letto in data 2026-09-30, l'organizzazione dispone di undici repository pubblici. I conteggi delle stelle e le date di push cambiano, quindi trattalo come un'istantanea anziché come una proprietà fissa del progetto. Ogni licenza è MIT o Apache-2.0 salvo diversa indicazione.

• skills — MIT, circa 2,4k stelle, ultimo push 2026-09-12. "Agent skills per costruire con l'API System One di TypeSafe."

• system-one-adapter-python — MIT, 356 stelle, ultimo push il 2026-09-22. "Sostituto drop-in di TypeSafeClient basato sulle API LLM."

• typesafe-sdk-js — MIT, 257 stelle, ultimo push 2026-09-15. La libreria ufficiale TypeScript/JavaScript per l'API TypeSafe.

• typesafe-sdk-python — MIT, 254 stelle, ultimo push il 2026-09-26. La libreria Python ufficiale; v0.7.2 ha aggiunto un extra `http2` quel giorno, e v0.7.1 il 2026-09-21 ha aggiunto esempi per l'uso con gateway AI.

• daggerverse — Apache-2.0, 23 stelle, ultimo push 2026-09-25. Una raccolta di moduli Dagger.

• WorkflowEvals — Apache-2.0, 7 stelle, ultimo push il 2026-09-29. «Codice del workflow di evals.typesafe.ai pubblicato.»

• n8n-nodes-typesafe-ai — MIT, 1 stella, ultimo push 2026-09-29.

• typesafe-ai.github.io — nessuna licenza dichiarata, 2 stelle, ultimo push il 2026-06-04.

Altri tre sono fork di progetti non correlati e vengono trattati di seguito: pulumi-clickhouse, LLaDA e vllm.

Niente in quell'elenco è il modello. Non esiste un repository Jev, nessun file di pesi, nessun tokenizer, nessuna configurazione di serving — niente che ti permetta di mettere in piedi una copia funzionante. I repo sono arredi lato client: due SDK ufficiali, un pacchetto di competenze per agenti, una raccolta di moduli CI, una suite di valutazione pubblicata, un nodo n8n, il sito dell'organizzazione e l'adapter. Questa è una superficie reale e ben mantenuta, e non è il modello.

L'unico repository che conta se stai cercando di evitare il lock-in

system-one-adapter-python è la voce con le maggiori conseguenze per chiunque debba prendere una decisione di adozione, e la sua stessa descrizione lo chiarisce: un "sostituto drop-in di TypeSafeClient basato su API LLM".

Leggilo con attenzione, perché sta facendo qualcosa di specifico. La risorsa duratura in un'integrazione System One è l'interfaccia, non l'endpoint dietro di essa: definisci una porzione di stato e un insieme di domande con nome, e qualcosa restituisce una risposta tipizzata per ogni domanda. È attorno a quel contratto che il tuo codebase finisce per essere modellato. L'adattatore disaccoppia il contratto dall'implementazione — continui a costruire sull'interfaccia delle decisioni tipizzate, e ciò che produce le decisioni è, sotto, una chiamata API LLM intercambiabile.

Due precisazioni oneste. Un adattatore non è il modello: le risposte prodotte da un LLM generico attraverso questo percorso non sono le probabilità calibrate che Jev restituisce, quindi è un modo per mantenere portabile l'interfaccia, non un modo per ottenere il comportamento di Jev senza Jev. Ed è esplicitamente un progetto TypeSafe — la via di fuga è costruita dal fornitore da cui potresti voler fuggire, il che è meglio di niente e non equivale a una via di fuga indipendente.

I due bivi, e l'inferenza che invitano

Tre degli undici repository sono fork. pulumi-clickhouse è un provider Pulumi per ClickHouse Cloud, Apache-2.0, 3 stelle, ultimo push 2026-07-08. Gli altri due sono quelli che vengono letti come prova, ed entrambe le letture sono sbagliate.

• vllm — Apache-2.0, 3 stelle, ultimo push il 2025-05-23. Un fork del motore di inferenza e serving ad alto throughput.

• LLaDA — MIT, 12 stelle, ultimo push 2025-06-17. Un fork dell'implementazione ufficiale PyTorch per "Large Language Diffusion Models."

L'inferenza pigra si fa da sola: hanno fatto il fork di un repository di un modello linguistico a diffusione, quindi Jev deve essere basato sulla diffusione. Non lo è, e il fork non ti dice nulla sull'architettura di Jev. Un fork è una copia del codice di qualcun altro sotto la licenza di qualcun altro, che sta in un'organizzazione per ragioni che la sua stessa data dell'ultimo push rende ovvie — maggio e giugno 2025, più di un anno prima che Jev fosse distribuito pubblicamente, e da allora non più toccato. Nessuno dei due repository fa parte di ciò che TypeSafe ha rilasciato a settembre. Se vuoi sapere come funziona Jev, TypeSafe non l'ha pubblicato, e nessun fork nella sua organizzazione colma la lacuna.

Quanto ti costa davvero chiudere i pesi

Quattro cose, e sono concrete più che filosofiche.

• Non puoi eseguire il self-hosting. Non c'è alcun artefatto da eseguire, quindi un'interruzione del fornitore o un cambiamento di accesso non è qualcosa che puoi aggirare mettendo in piedi la tua copia.

• Non puoi eseguire un audit. TypeSafe pubblica davvero una pagina sulla jaggedness per Jev 1.13 — ultima revisione 2026-09-17 — che indica dove il modello non è affidabile: lettura letterale della formulazione invece dell'intento, qualsiasi cosa che coinvolga aritmetica, confronto di date e orari, indirezione e doppie negazioni, stati di grandi dimensioni pieni di dettagli irrilevanti, contenuti avversariali nello stato, istruzioni e criteri contraddittori, e invarianti strutturali che non garantisce, come una risposta vero/falso e la sua equivalente scelta sì/no che non concordano. Quella pagina è insolitamente schietta, e resta comunque il fornitore che si dà i voti da solo. Nessuno al di fuori di TypeSafe ha ispezionato i pesi.

• Non puoi eseguire il fine-tuning. Non c'è un modello di base da adattare, quindi un compito decisionale che Jev gestisce male resta gestito male finché il fornitore non lo modifica — i rimedi della pagina sulla jaggedness sono workaround nel tuo codice, non esecuzioni di addestramento.

• Non puoi fissare una versione oltre l'alias del fornitore. typesafe/jev-1.13 è un nome ospitato, quindi ciò che risponderà a una chiamata il mese prossimo è qualunque cosa TypeSafe stia servendo con quel nome in quel momento.

Niente di tutto ciò è esclusivo di Jev e niente di tutto ciò è uno scandalo; è il compromesso che comporta un modello decisionale ospitato, e il contrappeso è che non ti sobbarchi mai un checkpoint, una bolletta per la GPU o uno stack di inferenza. Vale la pena sapere da quale lato del compromesso ti trovi prima di costruirci sopra.

Cos'è Jev, ora che puoi chiamarlo

Jev non è un modello di chat e non genera prosa. Invii uno stato — il materiale da giudicare, come testo, un oggetto o un array — più una serie di domande denominate, e restituisce una risposta strutturata per ogni domanda. Ogni domanda è una di tre primitive:

• noul — un giudizio vero/falso, restituito con una probabilità calibrata.

• scelta — scegline una tra un massimo di 255 opzioni etichettate.

• punteggio — valuta su una scala ordinata da 2 a 10 livelli.

La documentazione di TypeSafe mostra un esempio di punteggio con indice 0; la scheda del modello Jev 1.13 pubblica livelli da 2 a 10. Entrambi sono materiale dello stesso fornitore e questa pagina non inventa una riconciliazione tra i due.

Il metodo di training è un termine coniato da TypeSafe stessa: Reinforcement Learning for Calibrated Decisions (RLCD), descritto nel post di lancio in contrapposizione a RLHF e RLVR lungo l'asse delle decisioni calibrate con probabilità oneste. RLCD è un termine di TypeSafe, non un acronimo generico di machine learning, e va letto come una descrizione di fornitore anziché come una tecnica caratterizzata in modo indipendente.

L'accesso non è più soggetto a restrizioni: Jev è in disponibilità generale dal 2026-09-21, e "waitlisted" è stato ritirato. "Early access" è ancora la dicitura attuale di TypeSafe sulla sua homepage, quindi non è un'affermazione da liquidare — è semplicemente l'etichetta del fornitore, e i limiti operativi che pubblica insieme a essa sono concreti.

I numeri sulla nostra scheda: un contesto da 65.536 token, con il fornitore che documenta circa 64K di input tra stato combinato e domande. Se hai visto una cifra più piccola citata per Jev, quella è solo il budget dello stato anziché una misurazione concorrente, e le due non dovrebbero essere presentate come una contraddizione. Il prezzo è $0,042 per milione di token di input, con l'output fatturato a zero — non ci sono token di output da misurare, perché una decisione digitata non è prosa.

I nostri dati di serving, dal nostro traffico anziché dal benchmark del fornitore, nei sette giorni fino al 2026-09-30: p50 151 ms, p95 247 ms, circa 349 token di output al secondo, un tasso di errore dello 0,49% e 76,2 M token serviti. Il p50 giornaliero in quella finestra è andato da 175 → 170 → 163 → 161 → 170 → 147 → 143 ms, con un vero outlier — un p95 di 2.448 ms il 2026-09-28 che appartiene alla serie senza esserne la norma.

Le affermazioni di punta di TypeSafe, etichettate come del fornitore e non replicate in modo indipendente: «193,6 volte più veloce, 444,6 volte più economico», con nota a piè di pagina che rimanda ai flussi di lavoro di System One; un esempio svolto di $0,000081 in 0,114 s contro $0,013880 in 8,566 s per gli LLM; «$42 per miliardo di token di input»; e «Zero allucinazioni», che è un'affermazione sulle stime di confidenza piuttosto che una prova di assenza di errori — il tasso di errore dello 0,49% della nostra scheda è l'onesto contrappeso. TypeSafe afferma inoltre chiaramente di non poter dimostrare che i suoi prezzi non siano sovvenzionati, e che le sue valutazioni pubblicate sono state generalmente eseguite da laptop sulla costa occidentale, dove ha sede il servizio. La sua stessa scheda di benchmark è ancora contrassegnata come in sospeso.

I repository di terze parti esistono e non ci facciamo garanti per essi.

Le ricerche di "jev github" finiscono prima o poi per far emergere repository che non sono di TypeSafe: wrapper, raccolte di prompt, esperimenti di adapter e la solita lista "awesome" che compare intorno a qualsiasi nuovo modello. Non fanno parte di ciò che il fornitore pubblica, non hanno alcuna revisione del fornitore, e il loro numero di stelle misura la curiosità più che la correttezza. Possono essere utili; non sono documentazione, e nulla in essi è un'affermazione su come funziona Jev.

Cosa cambierebbe questa risposta?

Un rilascio dei pesi, un'architettura pubblicata o una valutazione indipendente della qualità della decisione anziché della latenza. Uno qualsiasi dei tre ribalterebbe la prima parola di questa pagina. Fino ad allora la ricerca ha una risposta stabile, e la parte su cui vale la pena agire è la toolchain: se l'interfaccia tipizzata delle decisioni è quella su cui stai costruendo, un adattatore con licenza MIT che sostituisce il modello sottostante è la differenza tra una decisione che puoi rivedere e una che non puoi.

Jev 1.13 è nel nostro catalogo sotto typesafe/jev-1.13, sulla stessa chiave del resto di uno stack e instradato attraverso l'endpoint dedicato systemone piuttosto che il formato chat-completions. Il modello è chiuso, il tooling è aperto, e entrambe le metà di ciò sono ora raggiungibili da un unico posto.