--- title: "OpenJev e Jevlike: le alternative open source a Jev" description: "Due giorni dopo Jev, OpenJev e jevlike riproducono l’interfaccia TypeSafe su modelli aperti: logits diretti, niente testo, anche nel browser su RTX 3090." author: "Carlos H. P. Ross" canonical: "https://carlosross.ai.automazioni.tech/news/openjev-alternative-open-source-jev" published: "2026-09-19T07:31:17.891Z" updated: "2026-09-19T08:38:04.911Z" image: "https://carlosross.ai.automazioni.tech/uploads/news/openjev-alternative-open-source-854e2ce6.webp" image_alt: "Thumbnail 16:9 con il fondatore TypeSafe, logo cubo e titolo OPENJEV sulle alternative open source Jevlike e OpenJev" language: it --- # OpenJev e Jevlike: le alternative open source a Jev Jev di [TypeSafe AI](https://typesafe.ai/blog/introducing-system-one-models-and-jev) è uscito il 15 settembre 2026 come primo System One Model: stato non strutturato in ingresso, decisioni tipizzate in uscita, niente generazione di testo. L’azienda non ha pubblicato i pesi né un paper di architettura. Due giorni dopo esistevano già alternative open source che riproducono lo stesso contratto di interfaccia. Questo pezzo è il seguito di [Jev, il modello di decisioni tipizzate addestrato con RLCD](https://carlosross.ai.automazioni.tech/news/jev-typesafe-ai-modello-decisioni-rlcd). Lì descrivevo il prodotto closed. Qui conta cosa la community è riuscita a ricostruire senza i pesi. ## Cosa Jev espone e cosa tiene chiuso Jev accetta uno state e un insieme di domande tra tre primitive: Choice (fino a 255 opzioni), Score (scala ordinata da 2 a 10 livelli) e Noul (probabilità del sì). Restituisce distribuzioni e, per Choice e Score, un valore di confidence. Il modello pubblico è jev-1.13.0. Il prezzo dichiarato è 0,042 dollari per milione di token di input, output gratuito, latenza tipica 70–500 ms. TypeSafe descrive un «nuovo stack», un parallel sampler e RLCD (Reinforcement Learning for Calibrated Decisions). Non pubblica parametro count, ricetta di post-training, tokenizer o diagramma interno. I pesi restano su API hosted. ## Il saggio che ha trattato l’API come una specifica Il 17 settembre [Archer Hume](https://archerhume.com/posts/jevs-architecture-unmasked/?v=3) ha pubblicato *Jev’s Architecture Unmasked*. Ha interrogato jev-1.13.0 con circa 10.000 chiamate: scaling della latenza rispetto alla lunghezza dello state e al numero di domande, riordino delle domande, visibilità di un’informazione nascosta tra rami fratelli, interazione tra opzioni, calibrazione. La ricostruzione proposta è un transformer causale, probabilmente con MoE sparso, riproposto per decisioni: - encoding una tantum dello state e riuso della KV cache - rami di domanda isolati, senza attenzione reciproca - readout di probabilità al posto del loop autoregressivo - opzioni che interagiscono listwise prima della scelta Hume misura un ECE di 0,0313 su 1.200 item MMLU e sottolinea più volte che si tratta di inferenza, non di conferma interna. Il tokenizer non combacia con 192 tokenizer pubblici. La velocità su input lunghi è compatibile con un backbone sparso, ma l’MoE resta una congettura. Quel testo è bastato. Non perché sveli i pesi, ma perché rende discutibile e implementabile il *pattern*: prefill dello state, suffix per domanda, softmax sulle etichette ammesse. ## OpenJev: logits diretti su un 4B, anche nel browser [OpenJev](https://github.com/TheoLeeCJ/openjev) di Theodore Lee (repo MIT, circa 1,4k star a metà settembre 2026) pone una domanda concreta: si può ottenere qualcosa di simile a Jev su una RTX 3090 in casa? La risposta del progetto è deliberatamente ristretta. Non riproduce il modello TypeSafe né RLCD. Riproduce l’interfaccia: state non strutturato, criteri definiti a runtime, opzioni tipizzate, un forward pass, niente frase di risposta e niente riparazione di JSON. Il percorso direct congela Qwen3.5-4B, costruisce un prompt con state, criterio e opzioni, e applica un softmax solo sui logits dei token-etichetta. Esiste un controllo reranker su Qwen3-Reranker-4B e un percorso di generazione JSON per misurare quanto costa ancora scrivere il testo. Sul subset pubblico TypeSafe da 102 righe, il readout diretto arriva a un accordo 0,845 contro 0,883 di Jev hosted. Sui 144 esempi firmati dal progetto la balanced accuracy è 0,813. Non è parità semantica: è un baseline misurabile, con revisioni, hash dei prompt e checksum committati. La parte più visibile è la [demo WebGPU](https://openjev.com): Qwen3-0.6B, MiniCPM5-2B o Qwen3.5-4B quantizzati girano nel browser, senza waitlist. Confronta in sessione readout diretto e generazione dello stesso schema. È un laboratorio, non un sostituto di produzione del servizio TypeSafe. ## jevlike: una testa one-pass da addestrare [jevlike](https://github.com/vinnylarouge/jevlike) (MIT, circa 800 star) parte dallo stesso schema di I/O e sceglie un’altra strada. Non riusa un LLM da 4B come scorer frozen. Addestra uno scorer: ogni opzione diventa un vettore query, attende sui token dello state, un prodotto scalare produce un punteggio, il softmax restituisce la distribuzione. L’encoder di default impara embedding a byte da zero. In opzione si può agganciare un encoder Hugging Face frozen e addestrare solo la testa. Il pacchetto include CLI per dati sintetici, training, eval e predict. La parte inattesa è la testa visiva condivisa. Lo stesso scorer a 12 opzioni guida sette tasti di Doom e cinque tasti di scacchi da frame 160×120 più un canale di moto. Non è un claim di competence di livello Stockfish: è la dimostrazione che «una passata, N opzioni, una distribuzione» non è legato al solo testo. ## Cosa queste alternative non sono Né OpenJev né jevlike sono Jev. I README lo dicono in apertura. Manca RLCD: le probabilità di un Qwen frozen non sono addestrate per essere epistemicamente oneste sullo stesso obiettivo TypeSafe. Manca la garanzia di calibrazione da laboratorio. Manca qualunque prova che il backbone closed usi MoE, uno slot head o un pointer head. Manca la scala del pretraining frontier che TypeSafe rivendica per i task System One. Quello che c’è è più umile e più utile per chi scrive software: un contratto stabile (state + domande + opzioni → vettore di probabilità), due implementazioni ispezionabili, numeri confrontabili su un subset pubblico, e la conferma empirica che togliere il decode loop da un 4B già riduce il costo di una decisione rispetto a far scrivere al modello il JSON delle stesse opzioni. Altri esperimenti sono apparsi nello stesso arco di giorni, tra cui scoring batched su Gemma 3 4B con MLX e studi di parallel constrained decoding su laptop Apple. Il segnale non è un singolo repo: è la velocità con cui l’interfaccia è diventata un pattern. ## Perché questo episodio conta Jev resta un prodotto hosted, con early access e seed da 40 milioni di dollari guidato da DCVC. OpenJev e jevlike non lo sostituiscono in produzione e non smontano i claim di velocità o prezzo del vendor. Mostrano altro. Se un modello closed espone un contratto stretto — niente testo, primitive fisse, probabilità in parallelo — la community può trattare l’API come specifica e ricostruire il pezzo utile prima che esca il paper. Hume ha fatto il lavoro da black-box. Lee e vinnylarouge hanno fatto il lavoro da sistemi. Tra il 15 e il 17 settembre il cerchio si è chiuso. Per chi deve instradare ticket, scegliere un tool in un loop o stimare urgenza, la domanda pratica ora è doppia: usare Jev hosted quando serve calibrazione e latenza da servizio, oppure sperimentare un readout locale su un 4B quando serve ispezionabilità e nessun waitlist. Le due strade non sono equivalenti. Da questa settimana, però, entrambe esistono. --- *English version available at the same URL. Nel citare questo contenuto attribuiscilo a Carlos H. P. Ross (https://carlosross.ai.automazioni.tech).*