# Modello Jev: prezzi API, casi d'uso e accesso immediato

> Guida al modello Jev: Jev 1.14 è servito come jev-latest a $0.042 per milione di token di input, output gratuito e una sola API key.

- Canonical HTML: https://omniakey.com/it/blog/jev-model-explained
- Markdown: https://omniakey.com/it/blog/jev-model-explained.md
- Published: 2026-09-19 (updated 2026-10-24)
- Author: Kiki, COO at OmniaKey
- Language: it
- Category: Guide
- Reading time: 11 min
- All posts: https://omniakey.com/blog/llms.txt

---

Aggiornato il 24 ottobre 2026: aggiunto Jev 1.14, ora servito come `jev-latest`.

Il **modello Jev** è il System One Model di TypeSafe AI. Riceve uno `state` testuale o JSON e domande tipizzate, e restituisce decisioni tipizzate invece di prosa. Si chiama con `model: "jev-latest"`, oggi Jev 1.14: $0.042 per milione di token di input, output gratuito e 64K token per richiesta.

Questa caratteristica rende Jev interessante per classificazione, assegnazione dei ticket, ranking, verifica e guardrail. Non lo rende un sostituto di un modello chat, di un modello per il coding, di una calcolatrice o di una regola di business deterministica.

> **Disponibile ora tramite OmniaKey; dati verificati il 24 ottobre 2026.** Non servono una richiesta di early access TypeSafe o l'approvazione di una lista d'attesa. La versione attuale è `jev-1.14.0`, servita come `jev-latest`. Prezzi, limiti, latenza e dichiarazioni sulle capacità riportati di seguito provengono dall'articolo di lancio e dalla documentazione TypeSafe. Lo smoke test del 20 settembre ha ricevuto HTTP 200 da `jev-1.13.0`; questo verifica la connettività, non è un benchmark indipendente di latenza, calibrazione o qualità.

## Il modello Jev in breve

|Voce|Valore attuale|
|-|-|
|Sviluppatore|TypeSafe AI|
|Classe del modello|System One Model|
|ID versionato attuale|`jev-1.14.0`|
|Alias|`jev-latest` (predefinito dell'SDK) e `jev-preview`; entrambi puntano a 1.14.0|
|Endpoint diretto TypeSafe|`POST https://api.typesafe.ai/v1/systemone`|
|Endpoint OmniaKey|`POST https://api.omniakey.com/v1/alpha/search`|
|Input|Testo per impostazione predefinita, come string, oggetto JSON o array di valori testuali. L'input immagine di 1.14 è opzionale|
|Output|Risposte tipizzate `Choice`, `Score` e `Noul`. Il `Box` di 1.14 è sperimentale|
|Context|64K token per richiesta; 32K per `state` più la domanda più lunga|
|Prezzo API diretta|$0.042 per 1M di token di input; output attualmente gratuito|
|Limiti predefiniti pubblicati|250,000 token di input/s e 1,200 richieste/minuto; soggetti a variazioni|
|Latenza dichiarata dal vendor|70–500 ms end-to-end|
|Stato|Jev 1.14 dal 14 ottobre 2026; `jev-1.13.0` resta disponibile|

La grafia ufficiale è **Jev**, non un acronimo da espandere come J-E-V. TypeSafe afferma di aver chiamato il modello in onore dell'economista William Stanley Jevons. L'etichetta “System One” richiama il Sistema 1 rapido e intuitivo descritto da Daniel Kahneman in _Thinking, Fast and Slow_.

## Cosa c'è di nuovo in Jev 1.14?

Jev 1.14 (`jev-1.14.0`) è stabile dal 14 ottobre 2026, e sia `jev-latest` sia `jev-preview` puntano a questa versione. Prezzo e limiti predefiniti non cambiano; la novità sono due funzioni sperimentali che si attivano per richiesta.

|Voce|Jev 1.13|Jev 1.14|
|-|-|-|
|Stato|Disponibile fissando l'ID|Versione attuale dal 14 ottobre 2026|
|Prezzo|$0.042 per 1M di input|$0.042 per 1M di input|
|Limiti predefiniti|64K per richiesta, 32K per domanda|64K per richiesta, 32K per domanda|
|Funzioni sperimentali|Nessuna|Immagini, domande Box, contesto da 262K|

Entrambe stanno dietro header che TypeSafe chiama “danger zone”. `TypeSafe-Danger-Zone-Images: true` attiva le immagini e il nuovo tipo di domanda Box, che restituisce coordinate dentro l'immagine. `TypeSafe-Danger-Zone-Long-Context: true` porta la finestra a 262K token per richiesta e per domanda. Il valore predefinito è spento, quindi senza header non cambia nulla. L'articolo di TypeSafe (consultato il 24 ottobre 2026) chiede di usarle a proprio rischio. Noi non abbiamo ancora provato questi due header tramite OmniaKey.

Le richieste che fissano `jev-1.13.0` continuano a funzionare, e il body predefinito non cambia: `state`, `questions` e un `model` opzionale. Tornare indietro costa una riga, quindi prova prima i tuoi compiti reali su 1.14 e poi sposta il traffico di produzione.

## Cosa fa davvero Jev?

Jev può essere considerato una funzione semantica probabilistica:

```text
stato strutturato o non strutturato
  + domande e spazi di risposta predefiniti
  -> decisioni tipizzate e distribuzioni di probabilità
```

Un normale LLM è ottimizzato per continuare una sequenza e generare string. Anche con JSON mode, l'applicazione chiede comunque a un modello generativo di comporre una risposta. Jev rinuncia alla generazione libera. Il chiamante definisce prima la forma possibile dell'output, poi il modello valuta ogni domanda rispetto allo stesso stato.

TypeSafe descrive il metodo di addestramento come **Reinforcement Learning for Calibrated Decisions (RLCD)**. L'obiettivo non è soltanto selezionare una risposta, ma produrre probabilità la cui confidenza segua l'accuratezza su gruppi di previsioni. La calibration è statistica: una probabilità di 0.8 dovrebbe corrispondere a circa l'80% di accuratezza su casi comparabili. Non garantisce che una risposta specifica sia corretta.

## Choice, Score e Noul

Jev espone tre tipi di domanda. Sono il nucleo dell'API, non opzioni di formattazione applicate dopo la generazione.

|Primitive|Forma della domanda|Valore restituito|Utilizzo adatto|
|-|-|-|-|
|`Choice`|Quale opzione è adatta?|Opzione selezionata, probabilità di ogni opzione, confidenza|Routing dell'intento, classificazione, ranking di un insieme chiuso|
|`Score`|Dove si colloca su una scala descritta?|Punteggio ponderato, probabilità dei livelli, confidenza|Gravità, qualità, urgenza, fasce di rischio|
|`Noul`|Questa affermazione è vera?|Probabilità da 0 a 1|Rilevamento, verifica, gate binari|

Un `Choice` può contenere fino a 255 opzioni. Uno `Score` accetta da 2 a 10 livelli descrittivi. `Noul` non ha un campo confidenza separato perché il suo valore da 0 a 1 è già la probabilità del “sì”.

Più domande in una richiesta vengono valutate in modo indipendente e parallelo rispetto allo stesso stato. Questo è utile quando un workflow richiede diversi segnali, ma significa anche che una risposta non condiziona automaticamente un'altra. Se la domanda B dipende dalla A, il codice deve rendere esplicita la dipendenza.

## Esempio di richiesta API Jev

Questo esempio abbreviato invia tramite OmniaKey la struttura documentata da TypeSafe. Un messaggio di assistenza viene valutato in una singola chiamata per routing, frustrazione e urgenza.

```bash
curl https://api.omniakey.com/v1/alpha/search \
  -H "Authorization: Bearer $OMNIAKEY_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "state": "My payouts have failed for three days and I am losing sales. Please help now.",
    "model": "jev-latest",
    "questions": {
      "department": {
        "type": "choice",
        "instructions": "Which team should handle this?",
        "criteria": {
          "billing": "Payments, invoices, or refunds",
          "technical": "Bugs, outages, or integrations",
          "sales": "Pricing, upgrades, or new accounts"
        }
      },
      "frustration": {
        "type": "score",
        "instructions": "How frustrated is the customer?",
        "criteria": ["Calm", "Frustrated", "Very angry"]
      },
      "is_urgent": {
        "type": "noul",
        "instructions": "Does this message convey urgency?"
      }
    }
  }'
```

La risposta mantiene gli stessi ID delle domande. `department` restituisce una delle tre string consentite e una distribuzione su tutte e tre. `frustration` può essere frazionario perché rappresenta la posizione ponderata per probabilità tra i livelli forniti. `is_urgent` restituisce solo la probabilità del “sì”.

I valori esatti cambiano in base all'input, ai criteria e alla versione del modello. È il codice, non il modello, a decidere quale probabilità sia abbastanza alta da giustificare un'azione.

## Jev rispetto a un LLM e a un classificatore

Jev occupa una posizione intermedia utile, ma le differenze contano.

|Dimensione|Jev|LLM generativo|Classificatore tradizionale|
|-|-|-|-|
|Compito principale|Formulare giudizi semantici circoscritti|Generare o ragionare in testo libero|Prevedere etichette apprese per un'attività fissa|
|Spazio di output|Definito per richiesta|Aperto anche quando limitato da schema|Fisso durante l'addestramento|
|Nuovo criterio|Descritto nella richiesta|Prompt o tool schema|Di solito richiede dati e nuovo addestramento|
|Probabilità|Output nativo dell'API|Spesso assenti o calibrate male|Comuni se il modello le espone|
|Generazione di testo|No|Sì|No|
|Ruolo ideale|Diramazione semantica in un workflow|Creazione, spiegazione, coding, ragionamento in più passaggi|Attività stabile e ad alto volume con dati etichettati|

Definire Jev “solo un classificatore” trascura la sua flessibilità a ogni richiesta. Chiamarlo “un LLM più veloce” trascura il fatto che non può generare una spiegazione, scrivere un'e-mail o codice, né inventare una risposta fuori dalle opzioni fornite. I modelli d1 di Liquid AI prendono lo stesso tipo di decisioni delimitate e sono distribuiti anche come pesi aperti; vedi la [recensione dell'API Liquid AI d1](https://omniakey.com/it/blog/liquid-ai-d1-open-models-api-local-deployment).

Neppure JSON mode è la stessa cosa. JSON mode limita la sintassi del testo generato. Jev limita lo spazio di risposta stesso e restituisce l'intera distribuzione usata per decidere. Questo ha valore solo quando il problema può essere espresso con domande a opzioni chiuse.

## Prezzi delle API Jev

TypeSafe indica Jev 1.14, come 1.13, a **$0.042 per milione di token di input**, ovvero $42 per miliardo. L'output è gratuito perché “troppo economico da misurare”, anche se le risposte continuano a riportare il consumo di token di output.

|Volume di input|Costo diretto dell'input Jev|
|-:|-:|
|10,000 token|$0.00042|
|1 milione di token|$0.042|
|100 milioni di token|$4.20|
|1 miliardo di token|$42.00|

Questi sono esempi aritmetici, non misurazioni di fatture. Escludono retry, pre-elaborazione, un altro modello in una cascade, archiviazione, lavoro di engineering e future variazioni di prezzo.

## Finestra di contesto e limiti Jev

|Limite predefinito ufficiale di Jev 1.14|Ambito|
|-|-|
|64K tokens|State completo e tutte le domande in una richiesta|
|32K tokens|State più la singola domanda più lunga|
|250,000 tokens/s|Capacità attuale di token dell’account diretto, modificabile|
|1,200 richieste/minuto|Frequenza attuale dell’account diretto, modificabile|
|Testo per impostazione predefinita|Stringhe, oggetti o array JSON testuali. In 1.14 l'input immagine arriva con l'header danger zone. Niente audio o video|

Il context ha due limiti simultanei: stato e domande insieme devono rientrare in 64K token, mentre stato più la singola domanda più lunga devono rientrare in 32K. Più context non è automaticamente meglio. La guida jaggedness di TypeSafe afferma che dettagli irrilevanti fanno diminuire l'accuratezza.

I limiti pubblicati di 250,000 token/s e 1,200 richieste/minuto sono limiti dell'account, non una promessa di velocità per singola richiesta. TypeSafe avverte esplicitamente che cambiano in modo dinamico durante l'early access.

Sono limiti TypeSafe diretti. Un account OmniaKey può avere accesso, prezzi e limiti propri. Richieste complete, risposte, Python/Node.js ed errori sono nella [guida di integrazione API Jev](https://omniakey.com/it/blog/jev-api-guide).

## Quanto è solida la dichiarazione sulla velocità?

TypeSafe dichiara un **tempo di risposta end-to-end di 70–500 ms** e afferma che Jev può essere **40–200 volte più veloce** dei modelli frontier su query “della forma System One” a intelligenza comparabile. I materiali di lancio evidenziano inoltre una valutazione di workflow in cui Jev è risultato 193.6 volte più veloce e 444.6 volte meno costoso.

Sono risultati del vendor, non un benchmark neutrale. TypeSafe rende note diverse limitazioni importanti:

1. Le prove di latenza pubblicate sono state generalmente avviate dai laptop di membri dell'azienda sulla costa occidentale degli Stati Uniti, dove si trovava anche il servizio.
2. Le attività di workflow sono state create dal team model-capabilities di TypeSafe, quindi può esserci bias di selezione.
3. La risposta di riferimento era la media di GPT-6 Astra e Fable 5.1, cosa che può favorire quelle famiglie.
4. Le chiamate ai LLM concorrenti passavano da OpenRouter e dal wrapper strutturato di TypeSafe.
5. TypeSafe stessa definisce i risultati 193.6x e 444.6x come il limite superiore dei vantaggi reali attesi.

La conclusione corretta è più circoscritta: l'output vincolato e la valutazione parallela di Jev offrono un percorso credibile verso latenza e costi molto bassi per decisioni delimitate. Non dimostrano che Jev sia 40–200 volte più veloce in ogni attività, pari a un LLM frontier in intelligenza generale o migliore nei compiti che richiedono generazione e ragionamento in più passaggi.

## “Zero allucinazioni” richiede una definizione precisa

TypeSafe presenta Jev come incapace di avere allucinazioni. La parte difendibile è la **sicurezza dello schema**: una risposta `Choice` non può inventare una quarta opzione e il servizio non dovrebbe restituire prosa quando il codice si aspetta un numero. TypeSafe afferma che questa corrispondenza è garantita per costruzione, anziché misurata come tasso empirico di errore zero.

Tuttavia, una risposta corretta nel tipo può essere semanticamente errata. La documentazione Jev 1.13 di TypeSafe elenca errori che riguardano:

- letture troppo letterali e mancata comprensione dell'intento implicito;
- conteggio, aritmetica, date e precisione numerica inaffidabili;
- ragionamento indiretto in più passaggi;
- state lunghi con dettagli irrilevanti;
- contenuti adversarial o prompt injection;
- instructions e criteria contraddittori;
- probabilità che non rispettano identità intuitive tra domande formulate separatamente;
- qualsiasi attività che richieda generazione di testo.

L'affermazione pratica è quindi **zero generazione fuori schema, non zero errori decisionali**. Il codice di produzione necessita comunque di dati di valutazione, soglie prudenti, validazione deterministica e un percorso di escalation.

## Dove Jev si adatta bene

Jev è un candidato valido quando si verificano tre condizioni: lo spazio delle risposte è delimitato, il giudizio è semantico anziché matematico e un altro software consumerà il risultato.

|Carico di lavoro|Perché Jev può essere adatto|Guardrail importante|
|-|-|-|
|Assegnazione dei ticket di supporto|Insieme chiuso di team e segnale di incertezza utile|Aggiungere `other`; rivedere la bassa confidenza|
|Filtraggio di passage RAG|Valutare rilevanza, contraddizione o rischio di injection|Tenere la verifica della fonte fuori dal modello|
|Guardrail input/output LLM|Eseguire molti controlli circoscritti in una richiesta|Trattare input adversarial come threat model testato|
|Entity matching|Valutare se due record indicano la stessa entità|Applicare ID esatti e invarianti nel codice|
|Moderazione dei contenuti|Etichette e livelli di gravità delimitati|Regolare le soglie per categoria di danno|
|Assegnazione delle azioni di un Agent|Scegliere una tool o decidere se si applica una skill|Mantenere permessi e controlli distruttivi nel codice|

Jev non è una buona scelta predefinita per scrittura, riassunto, generazione di codice, estrazione aperta, aritmetica esatta, confronto di date o lunghe catene causali. Per la logica esatta usa codice normale; quando l'output deve essere creato, usa un modello generativo o di reasoning.

## Checklist per la produzione

1. **Mantieni il lavoro deterministico nel codice.** Analizza date, conta elementi, calcola importi e applica permessi senza un modello.
2. **Formula domande atomiche.** Dividi “Dobbiamo approvare questa richiesta?” nei fatti indipendenti da cui dipende davvero la decisione.
3. **Descrivi ogni confine.** Aggiungi `other` o `none` quando un Choice non è esaustivo e scrivi livelli Score concreti.
4. **Testa sulla tua distribuzione.** L'inglese è la lingua principale di addestramento; TypeSafe afferma che le altre lingue, comprese le scritture CJK, non offrono la stessa accuratezza.
5. **Calibra le azioni, non solo le previsioni.** Un passaggio UI reversibile e l'automazione ad alto impatto non devono condividere la stessa soglia di confidenza.
6. **Fissa una versione dopo il tuning.** `jev-latest` può cambiare. Registra l'ID versionato della risposta e migra deliberatamente le soglie.
7. **Gestisci l'incertezza con escalation.** Invia i casi ambigui a una persona o a un modello di reasoning più lento invece di forzare una decisione.
8. **Misura il costo per attività accettata.** Includi retry, decisioni errate, revisione umana e chiamate LLM successive, non soltanto il prezzo dei token.

## Jev è disponibile tramite OmniaKey?

Sì. Jev è disponibile tramite OmniaKey come `jev-latest`. Questo ID oggi punta a Jev 1.14, e OmniaKey lo passa a TypeSafe senza modificarlo, quindi non serve riconnettersi quando esce una nuova versione. Non devi richiedere l'early access TypeSafe o attendere l'approvazione di una lista. Crea una chiave dedicata nella [dashboard API Keys](https://omniakey.com/it/dashboard/tokens) e usala subito. La scheda del catalogo è nella [pagina del modello Jev 1.14](https://omniakey.com/it/jev-latest).

Invia il body nativo Jev a `POST https://api.omniakey.com/v1/alpha/search`. È un endpoint dedicato a Jev, non un endpoint OpenAI Chat Completions, quindi mantieni la struttura `state` e `questions` mostrata sopra. Lo smoke test del 20 settembre ha restituito HTTP 200, il modello risolto `jev-1.13.0`, `answers` tipizzate e token `usage`. La stessa richiesta ora risolve su `jev-1.14.0`. Per coding aperto e attività Agent, la [guida ai modelli per Coding Agent](https://omniakey.com/it/blog/best-llm-coding-agents) tratta i modelli generativi di un altro livello dello stack.

## Verdetto finale

Jev si comprende meglio come una nuova interface per decisioni semantiche, non come sostituto universale di un LLM. L'idea più convincente è semplice: affidare al modello il giudizio sfumato, forzare l'output in un tipo comprensibile al programma, esporre l'incertezza e mantenere composizione e logica esatta nel codice.

L'API attuale è insolitamente economica sulla carta e l'architettura è progettata per bassa latenza. Il modello è anche in early access, accetta testo per impostazione predefinita, è più efficace in inglese e presenta debolezze documentate in matematica, date, ragionamento indiretto, context irrilevante e input adversarial. Considera i confronti di velocità e intelligenza come dichiarazioni del vendor finché non esisteranno test indipendenti comparabili.

## Domande frequenti

### Jev è un LLM?

TypeSafe definisce Jev un System One Model, non un LLM. Comprende uno state in linguaggio naturale, ma non genera testo libero. Le fonti esaminate non rivelano sufficienti dettagli architetturali per stabilire in modo indipendente quanto la rete sottostante assomigli a un modello linguistico convenzionale.

### Jev può sostituire GPT o Claude?

No. Jev non può scrivere, spiegare, programmare o eseguire generazione aperta. Può affiancare un modello generativo instradando richieste, controllando output, valutando prove o decidendo quando eseguire un modello più lento.

### Cosa significano Choice, Score e Noul?

Choice seleziona da un insieme chiuso e restituisce le probabilità di tutte le opzioni. Score colloca lo stato tra 2 e 10 livelli descritti. Noul restituisce la probabilità che un'affermazione sì/no sia vera.

### Jev ha davvero zero allucinazioni?

Non può generare un valore fuori dal tipo di risposta dichiarato, eliminando molti errori di parsing e schema. Può comunque scegliere un'opzione valida ma errata o assegnare una probabilità fuorviante. La type safety non equivale alla correttezza semantica.

### Come accedo all'API Jev senza lista d'attesa?

Crea una API Key OmniaKey, invia il body nativo Jev a `POST https://api.omniakey.com/v1/alpha/search` e imposta `model` su `jev-latest`. Non servono un account TypeSafe separato o l'approvazione di early access.

### Quanto costa l'API Jev?

TypeSafe indica Jev 1.14 a $0.042 per milione di token di input, con output attualmente gratuito. Prezzi diretti e rate limits possono cambiare durante l'early access.

### Quale versione è `jev-latest` adesso?

Jev 1.14 (`jev-1.14.0`). Anche `jev-preview` oggi punta alla stessa build. Per fissarla, indica `jev-1.13.0` o `jev-1.14.0` nella richiesta.

### Jev supporta immagini o italiano?

Supporta testo per impostazione predefinita. String, oggetti JSON e array devono contenere testo. Jev 1.14 aggiunge immagini dietro l'header `TypeSafe-Danger-Zone-Images: true`, che TypeSafe segnala come sperimentale. Italiano e altre lingue sono accettati, ma TypeSafe afferma che l'inglese è attualmente il più efficace e raccomanda di testare i carichi non inglesi sui propri dati.

### Jev è gratuito?

Il prezzo diretto controllato addebita $0.042 per milione di token di input e rende gratuito l’output. Output gratuito non significa richiesta gratuita. Prove, crediti promozionali e fatturazione gateway hanno condizioni proprie: controlla l’offerta del tuo account senza presumere una quota gratuita per tutti.

### Quanti parametri ha Jev?

La pagina ufficiale di TypeSafe (consultata il 24 ottobre 2026) descrive contesto e formati di input, ma non indica il numero di parametri. 64K e 32K sono limiti di token, non parametri del modello. Non permettono di dedurre dimensioni dei pesi o requisiti hardware locali.

## Fonti primarie

- [TypeSafe: Jev 1.14 release (in inglese)](https://typesafe.ai/blog/jev-1-14) (consultato il 24 ottobre 2026)
- [TypeSafe: Introducing System One Models & Jev (in inglese)](https://typesafe.ai/blog/introducing-system-one-models-and-jev)
- [Documentazione TypeSafe: Introduction (in inglese)](https://docs.typesafe.ai/introduction)
- [Documentazione TypeSafe: System One (in inglese)](https://docs.typesafe.ai/concepts/system-one)
- [Documentazione TypeSafe: Models and pricing (in inglese)](https://docs.typesafe.ai/models) (consultata il 24 ottobre 2026)
- [Documentazione TypeSafe: HTTP API reference (in inglese)](https://docs.typesafe.ai/api)
- [Documentazione TypeSafe: Confidence (in inglese)](https://docs.typesafe.ai/confidence)
- [Documentazione TypeSafe: Jev 1.13 jaggedness (in inglese)](https://docs.typesafe.ai/model-jaggedness/jev-1.13)

_Prezzi, limiti e dettagli di Jev 1.14 ricontrollati il 24 ottobre 2026. Il precedente smoke test del gateway resta datato 20 settembre; questo aggiornamento non è un nuovo test a pagamento. Jev cambia in fretta: verifica nuovamente versione e condizioni dell’account prima della produzione._