Jev 1.13 spiegato: perché il modello risponde in etichette invece che in frasi

Jev 1.13 (typesafe/jev-1.13) non è un modello di chat, e il modo più rapido per capirlo è smettere di leggere la sua scheda tecnica come si legge quella di qualsiasi altro modello. TypeSafe lo ha rilasciato il 2026-09-15 come primo membro di una classe che l'azienda chiama modelli System One: gli si passa un pezzo di stato e un insieme di domande con nome, e restituisce una risposta tipizzata per ogni domanda — un'etichetta da un elenco che avete fornito voi, un livello su una scala che avete definito voi, oppure un vero/falso con una probabilità associata. Niente prosa, niente codice, niente spiegazioni. Questo non è un articolo di lancio. Il modello in sé è del 2026-09-15, ha quindici giorni ed è fuori dalla finestra di sette giorni entro cui scrive questo blog, quindi non merita una pagina per il suo rilascio. Quello che è accaduto dentro la finestra è che OrcaRouter ha aggiunto typesafe/jev-1.13 al proprio catalogo il 2026-09-24 e ha aperto la scheda del modello Jev 1.13 su https://www.orcarouter.ai/models/typesafe/jev-1.13 — la prima volta che Jev è richiamabile attraverso un gateway di terze parti anziché solo tramite l'endpoint di TypeSafe stesso, e il primo dato di servizio dal vivo che qualcuno al di fuori di TypeSafe abbia pubblicato al riguardo. Questo è il cambiamento che vale la pena leggere: il modello è diventato eseguibile dove prima non lo era.

La forma concreta di quel cambiamento è piccola e specifica. Prima del 2026-09-24, adottare Jev significava un secondo rapporto con un fornitore — un account TypeSafe, una chiave TypeSafe, una fattura TypeSafe e una struttura di richiesta su misura da usare nel codice. Dopo, Jev si trova sulla stessa chiave del resto di uno stack: una sola API per oltre 200 modelli, ricarico 0% (il prezzo di listino del provider viene passato così com'è, quindi i ribassi di prezzo del fornitore sono attivi qui lo stesso giorno) e il modello raggiungibile all'indirizzo typesafe/jev-1.13 su POST /v1/systemone. Lo chiami ancora nella sua forma specifica — l'endpoint non è la rotta chat-completions di OpenAI, e fingere il contrario produrrebbe un 404 anziché una decisione — ma il contratto che firmi e la chiave che ruoti sono gli stessi che hai già.

Che tipo di modello è Jev?

Il post di lancio di TypeSafe lo afferma in una frase: "Il nostro primo modello pubblico è Jev, disponibile da oggi in accesso anticipato." Il post inquadra poi il modello come "una chiamata di funzione di intelligenza di frontiera: stato non strutturato in ingresso, decisioni probabilistiche tipizzate in uscita." Questa è una descrizione accurata dell'interfaccia, nonché importante, perché quasi ogni aspettativa errata su Jev deriva dal valutarlo come un piccolo modello linguistico. Non è un piccolo modello linguistico. È un modello decisionale con una grammatica di output fissa, e la grammatica è il prodotto.

L'interfaccia ha esattamente due input. Lo stato è il materiale da giudicare: un'email, un ticket di supporto, una riga di log, un record JSON, un array di coordinate di gioco. Le domande sono una mappa di elementi denominati, ognuno con un tipo, le proprie istruzioni e — per i due tipi strutturati — i propri criteri. Ogni domanda viene valutata rispetto a quello stesso stato, e le risposte tornano come un unico payload JSON strutturato. La documentazione di TypeSafe descrive le domande come eseguite in modo concorrente e indipendente, e formula due affermazioni che derivano da quel design piuttosto che dall'ottimizzazione: aggiungere domande cambia appena il tempo di risposta, e aggiungere domande non crea context rot, perché ogni domanda viene giudicata in isolamento anziché a valle di quelle precedenti.

Le linee guida di progettazione di TypeSafe meritano di essere ripetute perché sono l'affermazione più chiara di a cosa serve il modello. Mantieni ogni domanda atomica e ben circoscritta — "il tipo di giudizio che una persona molto competente potrebbe formulare in pochi secondi." Se una decisione richiede un ragionamento prolungato o combina davvero diversi fattori indipendenti, suddividila in domande separate e ricombinale nel tuo codice. Il loro esempio: invece di un unico prompt "valuta questo pitch di startup", chiedi separatamente informazioni su dimensione del mercato, fattibilità tecnica e differenziazione, poi applica la tua ponderazione. Il motivo per cui questo è importante è che la ponderazione risiede allora in un coefficiente che puoi modificare, invece che in un prompt che devi riscrivere.

Il modello è chiuso in ogni senso che conti per un ingegnere che ragiona sul rischio. L'architettura, il numero di parametri, il calcolo di addestramento e i pesi di Jev non sono pubblicati. Non esiste alcun repository dei pesi nell'organizzazione TypeSafe su GitHub — gli undici repository pubblici presenti sono strumenti, SDK, workflow e tre fork non correlati, e nessuno di essi è il modello.

"Typed" è l'intero prodotto

La model card di OrcaRouter pubblica le tre primitive e, cosa importante, i limiti di ciascuna. Ogni domanda che poni a Jev rientra esattamente in una di tre forme:

• noul — un giudizio vero/falso, restituito con una probabilità calibrata anziché un semplice booleano, così che "probabilmente vero" e "certamente vero" siano valori distinguibili.

• choice — scegli una tra un massimo di 255 opzioni etichettate, ciascuna opzione con il proprio testo dei criteri, così che il modello sappia cosa distingue le tue etichette.

• punteggio — valuta su una scala ordinata di 2–10 livelli, con le definizioni dei livelli fornite come criteri.

La conseguenza di quella restrizione è che non c'è nulla da estrarre dalla prosa e nulla da validare rispetto a uno schema che speravi il modello avesse seguito. Il post di lancio di TypeSafe è insolitamente diretto riguardo alla garanzia: la cifra dello "0%" di mancata corrispondenza dello schema nei suoi grafici «non è empirica. La corrispondenza dello schema è garantita, quindi possiamo inserire con sicurezza lo 0% nei grafici». Quando il tuo spazio di risposta è un insieme chiuso che hai fornito tu, un valore restituito o è nell'insieme oppure non proviene dal modello — non esiste un terzo esito in cui il modello ha scritto qualcosa di plausibile nella forma sbagliata e la tua regex l'ha accettato silenziosamente.

I tre tipi sono anche il motivo per cui un revisore non può valutare Jev allo stesso modo in cui valuta un modello di chat. Non c'è un punteggio MMLU-Pro da confrontare, nessun campione di scrittura da leggere, nessuna traccia di ragionamento da esaminare. L'unica domanda che conti davvero è se la risposta tipizzata è corretta e se la probabilità associata è onesta. Entrambe sono misurabili, ma solo rispetto ai tuoi dati e alle tue etichette.

Una differenza documentata merita di essere segnalata anziché risolta: la documentazione di TypeSafe stessa mostra un esempio di Score indicizzato a partire da zero, mentre la scheda di OrcaRouter pubblica la scala come 2–10 livelli. Il fornitore documenta i livelli; la nostra scheda pubblica 2–10. Se stai costruendo una rubrica basata su Score, leggi le definizioni dei livelli nella tua risposta anziché presumere un indice.

Perché non ci sono token di output da fatturare

Il prezzo è l'espressione più chiara dell'architettura. Jev costa $0,042 per milione di token di input su OrcaRouter, e la tariffa di output è $0,000000 per milione — non uno sconto, non una promozione di lancio, ma l'assenza di una quantità misurabile. Un modello generativo viene fatturato per il testo che scrive; Jev non scrive alcun testo. Restituisce un'etichetta, un livello e una probabilità. Non c'è nulla da contare sul lato output, quindi nulla viene addebitato lì.

TypeSafe dichiara sulla propria homepage lo stesso numero nella direzione opposta — "$42 per miliardo di token di input" — e vi aggiunge un'affermazione comparativa: "prezzo di input 238 volte inferiore rispetto a Claude Fable 5.1". Tale confronto, come tutto il resto sulla homepage, è del fornitore stesso, non replicato da nessuno. Ma l'aritmetica su cui si basa è facile da verificare per un lettore sulla propria fattura, ed è questa la parte utile. Il volume di un carico di lavoro con stato è determinato quasi interamente da quanto stato vi si immette, e lo stato è economico in un modo in cui i token generati non lo sono.

Le cifre di punta del fornitore sono più grandi della riga del prezzo e meritano la stessa etichettatura. TypeSafe pubblicizza «193,6x più veloce, 444,6x più economico» con una nota a piè di pagina che la limita a «flussi di lavoro per attività System One», e vi pubblica sotto un esempio pratico: TypeSafe AI a 0,000081 $ completato in 0,114 s contro gli LLM a 0,013880 $ completati in 8,566 s. Il post di lancio stesso ammette il rischio di inquadramento — si dice che i 193,6x e i 444,6x si collocano probabilmente «all'estremità superiore dei guadagni nel mondo reale» — e osserva che la demo affiancata utilizzava una query «altamente semplificata» con chiavi leggibili dall'uomo scelte dal fornitore per «dipingere il nostro modello in una luce favorevole». Nessuno di questi numeri è stato replicato in modo indipendente, e la scheda di benchmark del fornitore stesso è ancora contrassegnata come in sospeso.

Che cosa significa "calibrato", e che cos'è RLCD

TypeSafe dà essa stessa un nome al proprio metodo di addestramento: "Reinforcement Learning for Calibrated Decisions (RLCD)". RLCD è un termine proprio di TypeSafe, non un acronimo generico di machine learning precedente all'azienda, e il suo obiettivo di ottimizzazione è indicato nella tabella di confronto del post di lancio come "decisioni calibrate: risposte con probabilità epistemicamente oneste su compiti System One". Il contrasto che la stessa tabella traccia è con RLHF, che ottimizza per la preferenza umana — testi e risposte in chat che piacciono ai valutatori — e RLVR, che ottimizza per output verificabili in modo programmatico. RLCD ottimizza per una terza cosa: la probabilità associata al fatto che una risposta sia un'affermazione accurata dell'incertezza del modello stesso.

In pratica, "calibrato" è un'affermazione sui livelli di confidenza, non una garanzia che le risposte siano corrette. Un modello calibrato che dice 0,8 su un insieme di domande dovrebbe essere corretto circa l'80% delle volte su quell'insieme; può comunque sbagliare su una singola domanda. Questa distinzione è il modo onesto di leggere la frase della homepage di TypeSafe "Zero allucinazioni — Ogni decisione di Jev viene fornita con una stima di confidenza, così il tuo software può agire quando la confidenza è alta e attivare l'escalation quando non lo è." È un'affermazione sulle stime di confidenza, non una prova di zero errori, e il contrappeso sono i nostri stessi dati: nei sette giorni che terminano il 2026-09-30, la nostra scheda misura un tasso di errore dello 0,49% sul traffico di Jev attraverso OrcaRouter — un valore che in precedenza, nella stessa finestra, indicava lo 0,57%, perché è calcolato su sette giorni mobili di traffico live del playground anziché su un set di test fisso. Entrambi i fatti appartengono allo stesso paragrafo: i livelli di confidenza sono il punto del modello, e il modello sbaglia comunque circa una chiamata su duecento sul nostro traffico.

La storia della calibrazione spiega anche un comportamento di latenza che altrimenti sembrerebbe un bug. Il post di lancio di TypeSafe dice: "Per scelte a cardinalità più elevata, adottiamo un sistema a 2 fasi: valutazione indipendente e poi scelta esplicita, da cui il rallentamento occasionale." Una scelta a 255 opzioni non è un singolo confronto in avanti; il fornitore valuta e poi sceglie. Se vedi una richiesta su un ampio insieme di etichette richiedere un tempo sensibilmente maggiore rispetto a un noul, quello è il meccanismo documentato, non la congestione.

Come lo chiami oggi?

Su OrcaRouter il modello è typesafe/jev-1.13, denominato "TypeSafe: Jev 1.13" nel catalogo, con un context_length di 65.536 token e esattamente un tipo di endpoint supportato: systemone. Lo si chiama con POST /v1/systemone sulla propria chiave OrcaRouter, inviando un campo model, un campo state (stringa, oggetto o array) e una mappa questions in cui ogni voce porta un tipo (noul, choice o score), le sue istruzioni e i suoi criteri. Le risposte sono un singolo payload JSON strutturato e non sono in streaming — non esiste alcuna modalità streaming da attivare.

La dicitura riportata sulla scheda stessa per il contratto è «testo in ingresso, JSON strutturato in uscita», e i limiti pubblicati sono quelli su cui progettare: non in streaming, fino a circa 64K token di input considerando insieme stato e domande, con le richieste che superano tale limite rifiutate prima di raggiungere il modello. La voce di catalogo indica il prezzo di listino come $0,042 per milione di token di input e mostra la tariffa di completamento pari a zero. Quelli sono i numeri del fornitore riportati invariati — la forma proporzionale di come applichiamo i prezzi: 0% di ricarico sulle tariffe di listino del provider.

Per questo modello circolano due budget di token e non sono in conflitto, quindi teneteli separati. Il valore di 65.536 è il context_length della scheda ed è documentato come circa 64K di input tra stato e domande messi insieme. Il «circa 32.000 token» citato nei precedenti articoli di OrcaRouter è solo il budget dello stato — lo spazio che il vostro materiale riceve prima che le domande prendano la loro parte. Se state pianificando il budget di una richiesta, il budget dello stato è il numero che vincola il payload che costruite; il valore combinato è il tetto dell'intera chiamata.

Ciò che Jev non può fare, detto chiaramente

Non sa scrivere prosa, riassumere, tradurre né conversare. Questa è la scelta progettuale, non un limite di cui scusarsi: il post di lancio dice che Jev «rinuncia alla generazione di stringhe», e la pagina di TypeSafe sulla jaggedness elenca «Generazione» come modalità di guasto con nome proprio, con accanto l'istruzione «Usa un modello generativo». La generazione forzata è lenta e scadente. Se la tua pipeline ha bisogno di un riassunto scritto, Jev è il componente sbagliato, e nessuna abilità nel costruire prompt potrà cambiarlo.

Non è un sostituto di un modello generativo. Il flusso di lavoro a cui appartiene Jev contiene due modelli: uno generativo che legge, scrive e ragiona in testo, e Jev seduto accanto che effettua le chiamate tipizzate in millisecondi. Questa è la descrizione onesta di ogni confronto di costi sulla homepage del fornitore — la colonna "LLMs" non è un concorrente che viene spodestato, è l'altra metà dello stesso sistema, e il motivo per cui l'abbinamento è interessante è che la metà decisionale ora si trova sulla stessa chiave della metà generativa invece che dietro il proprio contratto.

E "calibrato" non significa corretto. Significa che il numero associato a una risposta è pensato per essere leggibile come una probabilità. Un 0,62 su un noul è il modello che ti dice che non è sicuro, che è un'informazione utile che un semplice sì/no avrebbe distrutto — e non è una promessa che il sì sia giusto. La logica di escalation basata sulla confidenza è il pattern previsto; trattare la risposta come verità assoluta non lo è.

Leggere i numeri onestamente

Ogni cifra di serving sulla nostra scheda proviene dal nostro traffico attraverso il playground di OrcaRouter su una finestra mobile di sette giorni, non dal benchmark del fornitore, e la finestra si è spostata mentre scrivevamo questo pezzo — trattala come una lettura, non come una specifica. Per i sette giorni che terminano il 2026-09-30: tempo mediano al primo token 151 ms, p95 247 ms, throughput di output intorno ai 349 token al secondo, tasso di errore 0,49% e 76,2 milioni di token serviti. Il p50 giornaliero lungo la finestra è pari a 175, 170, 163, 161, 170, 147 e 143 ms — una linea in lento miglioramento. Il p95 del 09-28, pari a 2.448 ms, è un autentico outlier di un singolo giorno all'interno di quella serie, e citarlo come norma sarebbe sbagliato esattamente come sarebbe disonesto ometterlo del tutto.

Un'ulteriore precisazione sul dato del traffico: 349 token di output al secondo sembrano il throughput di un modello generativo, finché non si ricorda che Jev non produce alcun testo generato. Il misuratore sta misurando qualunque cosa il nostro playground conti sul lato risposta per un payload strutturato, ed è utile per individuare peggioramenti tra giorni diversi più che per confrontare Jev con un modello di chat.

Quelli sono i nostri numeri. I numeri del fornitore sono il 193,6x, il 444,6x, l'esempio di calcolo da $0,000081 e il confronto di 238x rispetto a Claude Fable 5.1 — tutti di TypeSafe, nessuno replicato in modo indipendente, tutti limitati dalle loro stesse note a piè di pagina specificamente ai flussi di lavoro delle attività di System One. L'unica affermazione sulle prestazioni fatta da TypeSafe che non è affatto un benchmark, e che vale più dei moltiplicatori, è di natura strutturale: poiché le risposte sono tipizzate, l'integrazione non ha alcuna fase di parsing né di validazione dello schema, e questo è un costo che non compare in nessuna tabella di latenza.

Che cosa è aperto, e che cosa no

Verificato il 2026-09-30, l'organizzazione GitHub TypeSafe ha pubblicato undici repository. Nessuno contiene Jev. Quelli che contano per uno sviluppatore che integra il modello sono tutti MIT o Apache-2.0: skills (MIT), system-one-adapter-python (MIT, descritto come un "sostituto drop-in di TypeSafeClient basato su API LLM"), typesafe-sdk-js (MIT), typesafe-sdk-python (MIT), daggerverse (Apache-2.0), WorkflowEvals (Apache-2.0, con codice del workflow pubblicato su evals.typesafe.ai), n8n-nodes-typesafe-ai (MIT), typesafe-ai.github.io e pulumi-clickhouse. I conteggi delle stelle e le date di push cambiano, quindi se lo stai leggendo più tardi, ricontrolla invece di fidarti dell'elenco.

Tre degli undici sono fork di progetti non correlati e non provano nulla su come funziona Jev: una fork di vLLM il cui ultimo push risale a maggio 2025, una fork di LLaDA da giugno 2025 — LLaDA è un rilascio di un modello linguistico a diffusione non correlato — e un provider Pulumi per ClickHouse Cloud. È allettante dedurre l'architettura da un elenco di fork. Non farlo: nulla del design di Jev deriva da quei tre, e in particolare Jev non è un modello a diffusione, per quanto la presenza di una fork di LLaDA possa suggerirlo.

La risposta onesta, in una riga, alla domanda «Jev è open source?» è che il tooling è aperto e il modello no. È una configurazione normale per un modello di frontiera ospitato, ed è la configurazione che dovresti dare per scontata quando pianifichi intorno a Jev: un'API con un prezzo pubblicato, un contratto documentato e un numero di parametri non pubblicato.

Dove il fornitore dice che Jev non è affidabile

TypeSafe pubblica la propria pagina sulla jaggedness per jev-1.13, revisionata l'ultima volta il 2026-09-17, che elenca i punti in cui il modello si rompe. È insolitamente schietta ed è il posto giusto da cui iniziare una sezione sui limiti, perché è l'elenco del fornitore stesso anziché di un concorrente:

• Lettura letterale — interpreta le parole alla lettera. Le parole che delimitano l'ambito, le negazioni e le condizioni implicite non vengono inferite; "risponde alla domanda che hai scritto, non a quella che intendevi." La soluzione del fornitore consiste nello scrivere la condizione esatta e i criteri per ogni opzione.

• Matematica e numeri — non è una calcolatrice e non conta in modo affidabile. Mantieni l'aritmetica nel codice.

• Confronto tra date e orari — le date vengono lette come testo, non come quantità ordinate, quindi ordinamento, lacune e finestre non sono affidabili; peggio con formati misti.

• Indirezione — le doppie negazioni e il ragionamento multi-hop riducono l'accuratezza. Riduci i passaggi e punta allo stato rilevante.

• Uno stato grande e pieno di dettagli irrilevanti — i contenuti non correlati agiscono da distrattori e la precisione diminuisce man mano che lo stato cresce. Filtra prima.

• Contenuto avversariale — lo stato non viene considerato ostile, quindi istruzioni iniettate o inquadramenti fuorvianti possono alterare le risposte.

• Istruzioni e criteri contraddittori — quando i due richiedono cose diverse, il modello "potrebbe confondersi".

• Invarianti strutturali di buon senso — non è garantito che P(noul) e 1 − P(not noul) siano coerenti. Formula ogni decisione in un solo modo e fai rispettare le identità nel codice.

• Generazione — già trattato, e il consiglio del fornitore stesso è di usare un modello generativo.

Due di questi meritano di essere sottolineati. Quello avversariale conta perché l'intera proposta di valore di Jev è valutare materiale non attendibile, e uno stato che contiene istruzioni può influenzare una risposta; se il tuo stato proviene dagli utenti, quella è una superficie di prompt injection con la stessa forma di qualsiasi altra. Quello degli invarianti strutturali conta perché un modello "calibrato" ti invita a fare aritmetica sulle sue probabilità, e il fornitore ti sta dicendo di non dare per scontato che l'aritmetica si chiuda.

A cosa si impegna il post di lancio, e a cosa no

Quasi ogni dichiarazione di fornitore citata in questo articolo risale a una sola pagina: l'annuncio della stessa TypeSafe, archiviato sotto Company News e datato 15 settembre 2026, firmato dal fondatore Diogo Almeida. Vale la pena dedicargli due minuti e leggerlo direttamente, perché la formulazione di una sola riga stabilisce i termini di tutto ciò che è seguito. "Il nostro primo modello pubblico è Jev, disponibile da oggi in accesso anticipato." L'accesso anticipato è la descrizione che il fornitore stesso dà della disponibilità sulla propria piattaforma, ed è un'affermazione più limitata di quanto sembri — impegna TypeSafe a erogare il modello agli utenti approvati, e non dice nulla su chi altri possa erogarlo. È esattamente la lacuna che l'aggiunta al catalogo del 24 settembre 2026 ha colmato, e il motivo per cui la scheda del modello conta più del post per chiunque valuti Jev oggi.

La stessa pagina è altrettanto chiara riguardo ai propri limiti, ed è per questo che sopra viene citata anziché parafrasata. Non pubblica alcun numero di parametri, nessuna descrizione dell'architettura oltre a «una nuova architettura di modello», nessun compute di addestramento e nessun repository di pesi, e non fornisce alcuna data né condizioni per la disponibilità generale. Queste assenze sono i vincoli di pianificazione: da un lato un'API con un prezzo pubblicato, dall'altro uno stack di cui non si possono ispezionare le parti interne. Il post inquadra inoltre il modello con sufficiente onestà da renderlo utile come specifica — «una chiamata di funzione di intelligenza di frontiera: in ingresso stato non strutturato, in uscita decisioni probabilistiche tipizzate» — che è l'unica frase al suo interno a descrivere l'interfaccia anziché l'ambizione.

Domande che questa interfaccia solleva

Cosa succede quando un insieme di scelte supera le 255 opzioni? Viene limitato — 255 opzioni etichettate è il tetto massimo per una domanda a scelta, e l'approccio in due fasi del fornitore, prima il punteggio e poi la scelta, è ciò che fa man mano che la cardinalità cresce, il che è anche la fonte documentata di occasionali rallentamenti su grandi insiemi di etichette. Se la tua tassonomia è più grande di così, la risposta progettuale è scomporla in diverse domande e ricombinarle nel codice, che è lo stesso consiglio che TypeSafe dà per i giudizi composti.

Il contesto di 65.536 token significa 65.536 token di stato? No. Il budget pubblicato è di circa 64K token considerando insieme lo stato e tutte le domande, e il valore di "circa 32.000 token" che compare in articoli più vecchi è il budget del solo stato. Dimensiona il tuo payload in base al valore dello stato, non a quello combinato, e ricorda che le richieste che superano il limite vengono rifiutate prima di raggiungere il modello.

Cosa fare con questo

Jev 1.13 vale la pena dare un'occhiata per un motivo specifico e non per uno generale. Se hai uno step nella tua pipeline che attualmente è un modello di chat a cui viene chiesto di restituire un'etichetta e ci si fida che la restituisca nella forma corretta — un router, un grader, un controllo di policy, un punteggio di rubric applicato a migliaia di record — quello step è ciò che questo modello sostituisce, a $0,042 per milione di token di input senza nulla misurato sul lato output. Se hai uno step che richiede una risposta scritta, Jev non è lo strumento e lo dice il suo stesso fornitore.

La cosa che è cambiata nell'ultima settimana non è il modello. È che provarlo non richiede più un secondo rapporto con un fornitore. Otto giorni fa una valutazione di Jev significava un account separato e un'integrazione separata; oggi è un solo model id su una chiave che già raggiunge oltre 200 modelli, con il prezzo di listino del fornitore trasferito invariato e le risposte digitate che tornano dallo stesso posto di tutto il resto. Per un modello così insolito, la possibilità di testarlo rispetto alle proprie etichette senza impegnarsi in un nuovo contratto è gran parte della decisione.