AIDiveIntro: un hint, non un risparmio
Jev non renderà Claude Code più economico, e lo dice il benchmark del gateway stesso. Questo articolo legge il codice di jev-gateway e il suo repository di benchmark, poi mette un proxy di logging davanti a una sessione reale di Claude Code per vedere cosa riceverebbe un router.
Jev è il decision model di TypeSafe: una probabilità restituita in millisecondi, collegata a Claude Code da sei video in una settimana. Il messaggio è "il loop agentico di coding più economico". I numeri dello stesso gateway mostrano Opus 5 fare il 47% di richieste in più e impiegare l'83% di tempo in più su un task di feature con il routing attivo.
Come fa un router che risponde in millisecondi a rendere Claude Code più lento? Tutto si riduce a una riga di codice. Dentro Claude Code, Jev riceve esattamente due frasi, e una sessione normale gli passa 40 tool a ogni chiamata.
Cos'è Jev, e cosa vende l'onda
Jev è un decision model di TypeSafe. Non genera testo: gli si fa una domanda tipizzata e risponde con una scelta, un punteggio o una probabilità sì/no. I numeri del vendor:
| Dato | Valore |
|---|---|
| Prezzo input | $0.04 per milione di token |
| Prezzo output | gratuito ("troppo economico per essere misurato") |
| Latenza | da 70 a 500 ms |
| Titolo in home page | 194× più veloce, 445× più economico |
Il post del blog sotto quel titolo dice che i due moltiplicatori sono l'estremo superiore dei guadagni reali, misurati contro la media di due modelli frontier, un confronto che gli stessi autori ammettono essere sbilanciato a favore di quei modelli.
Sei video in cinque giorni hanno collegato Jev a Claude Code. Il più visto è a 139.000 visualizzazioni e lo definisce il loop agentico di coding più economico finora. Due repository portano avanti l'onda: jev-gateway, un proxy locale per Claude Code e Codex creato cinque giorni prima con 181 stelle, e fast-jev-compaction, un plugin di compaction creato il giorno prima, a 6.400 stelle. Il gateway è dove Claude Code si collega, quindi è da lì che parte la lettura.
Una variabile, una riga: modalità hint
jev-gateway si posiziona tra Claude Code e l'API Anthropic. Lancia Claude Code con una sola variabile d'ambiente, ANTHROPIC_BASE_URL, puntata su una porta locale. Nient'altro cambia; un commento nel sorgente dice che non esiste una credenziale del gateway, quindi un login Pro o Max continua a funzionare così com'è.
Dentro l'adapter (src/adapters/messages.ts, riga 99), una riga decide cosa può fare Jev:
steer: thinking || cached ? "hint" : "tool_choice"
Con extended thinking attivo, o una conversazione in cache, il gateway può solo suggerire (hint). Altrimenti forza il tool. Il commento sopra la riga spiega perché: l'API rifiuta un tool forzato mentre l'extended thinking è attivo, e cambiare tool_choice invalida la conversazione in cache che Claude Code rilegge a ogni turno.
Per verificare come si presenta una richiesta reale, un proxy di logging di 60 righe ha preso il posto del gateway sullo stesso tipo di porta, con Claude Code lanciato attraverso di esso e una richiesta inviata su un repository reale. La richiesta porta thinking: adaptive e tre marker di cache; tool_choice è assente; 24 tool viaggiano insieme su un'installazione pulita. Applicando la riga del gateway a quella richiesta, il percorso forzato non scatta mai. Ogni chiamata di Claude Code finisce in modalità hint. Il README lo dice esplicitamente: aspettati scelte di tool migliori su liste di tool grandi, non costo o latenza inferiori.
Il hint: due frasi, e dove non atterra
Cosa può fare Jev dentro Claude Code? Due frasi aggiunte all'ultimo messaggio: "a routing model suggests this tool is the most relevant move now. Ignore this if it doesn't fit" ("un modello di routing suggerisce che questo tool è la mossa più rilevante ora. Ignora questo suggerimento se non è adatto"). Questa è tutta l'intervento. Il modello è libero di ignorarlo, e tool_choice resta su auto.
Forzare un tool non è un'opzione, secondo la documentazione di Anthropic: un tool forzato restituisce un errore 400 su Opus 5.5 e Fable 5.1, e genera errori con il thinking manuale sugli altri modelli. Anche cambiare tool_choice è escluso: la documentazione sul prompt caching dice che invalida la cache dei messaggi, la parte più grande di una sessione lunga. Modificare la descrizione di un tool invalida l'intera cache: tool, system e messaggi.
| Modifica alla richiesta | Effetto sulla cache del prompt |
|---|---|
| Aggiungere un hint all'ultimo messaggio utente | prefisso in cache invariato |
Cambiare tool_choice |
cache dei messaggi invalidata |
| Modificare la definizione di un tool | tool, system e messaggi invalidati |
Il commento del gateway spiega perché l'hint va in fondo: il prefisso in cache resta identico byte per byte a quello che Claude Code reinvia al turno successivo. Davanti a tutto questo c'è una guardia: quando l'ultimo messaggio non è dell'utente, la richiesta passa intatta. Entrambe le richieste catturate finivano su un blocco system che Claude Code aggiunge da solo, un promemoria d'ambiente in una e l'output di un hook nell'altra. Su questa forma, l'hint non ha dove atterrare. Atterra sugli altri turni, perché i risultati dei tool tornano come messaggi utente, e il benchmark conta Jev che guida da un terzo a metà delle richieste di Claude Code.
Il benchmark che nessuno cita
Il benchmark dello stesso gateway, jev-gateway-bench, risponde alla domanda iniziale. Ha eseguito 120 sessioni, cinque run per cella, sullo stesso Claude Code e la stessa sottoscrizione che usa chiunque, senza server MCP, plugin o skill. Due task su un piccolo motore scacchistico: una caccia ai bug con cinque bug iniettati, e una feature, l'aggiunta della notazione algebrica.
| Modello, task | Routing acceso vs spento |
|---|---|
| Opus 5, feature | +61% token in input, +47% richieste, +83% tempo (ha comunque risolto 5/5) |
| Sonnet 5, feature | +16% token in input, +37% tempo |
| Sonnet 5, caccia ai bug | −48% token in input, −25% tempo |
Il debugging è dove il routing paga, nelle parole degli autori. La loro spiegazione è la risposta alla domanda: il gateway suggerisce soltanto con i modelli Claude, quindi un hint che non si adatta costa una deviazione invece di essere ignorato gratis.
Codex riceve la versione forzata. Jev ha deciso dal 76 al 100% delle richieste di Codex, contro un terzo-metà di quelle di Claude Code. Un modello nell'altro harness è diventato più economico e sbagliato, tre soluzioni su cinque invece di cinque. Più economico e sbagliato non è un risparmio.
I limiti sono reali: cinque run per cella è un campione piccolo, è un solo motore giocattolo, e nessuno l'ha rieseguito. Anche l'input è per lo più in cache, quindi un risparmio sull'input vale meno di un risparmio sull'output.
Cosa passa la mia sessione: 24 tool puliti, 40 completi
Cosa passa a un router una normale sessione di Claude Code a ogni chiamata? Il log del proxy risponde: 40 tool. Stesso repository, stesso prompt di una parola, due configurazioni: un'installazione pulita con una configurazione vuota e nessun server MCP, e una configurazione normale con i suoi server e plugin.
| Installazione pulita | Configurazione normale | |
|---|---|---|
| Tool nella richiesta | 24 | 40 (16 da server MCP e plugin) |
| Token di prefisso fatturati | 47.411 | 57.277 |
| Token in output | 4 | 4 |
| Costo equivalente API di un "ok" | $0.07 | $1.15 |
La lista dei tool è il conto. Le definizioni più pesanti sono integrate: il tool shell da solo è 12.000 caratteri, il tool agent quasi 9.000.
La nota a piè di pagina del benchmark ha visto sei tool e 7.000 token su un'installazione pulita, e 285 tool su una configurazione caricata. Il Claude Code pulito di oggi spedisce molti più tool integrati, e il caso caricato è più raro: la maggior parte dei tool MCP sta dietro un tool di ricerca, differita, quindi la lista che vede un router resta piccola. Qualunque sia la sua dimensione, il gateway invia quella lista a Jev a ogni richiesta; una issue aperta sul repository dice che il costo pieno viene pagato prima che la maggior parte delle risposte venga scartata. Niente di tutto questo è colpa di Jev, e niente di tutto questo spetta a Jev risolvere.
Verdetto per caso d'uso
Routing dentro Claude Code: no. È un hint che il modello può ignorare, ha reso il lavoro sulle feature più lento su entrambi i modelli Claude, e l'unica vittoria è sul debugging. L'eccezione è una giornata di caccia ai bug su una lista di tool molto grande, il caso che il README stesso indica.
Il plugin di compaction, fast-jev-compaction: non ancora. Richiede un flag di accesso anticipato, le sue issue aperte dicono che gli hook non si registrano su alcune build, e dopo una compaction il modello ha scritto nove report che dichiaravano il lavoro completato, tutti inventati. I professionisti ci sono arrivati prima: il thread più votato sul plugin ha 491 punti, e la sua obiezione principale non è la velocità ma i termini di servizio sull'invio delle trascrizioni a terze parti.
Codex: quello è il bersaglio reale. Lì il gateway forza il tool, Jev ha guidato fino a ogni richiesta, e la caccia ai bug è girata con il 57% di token in output in meno.
| Caso d'uso | Verdetto |
|---|---|
| Routing in Claude Code | No, tranne le cacce ai bug su una lista di tool molto grande |
| fast-jev-compaction | Non ancora |
| Codex | Sì |
Una cosa che l'onda ha azzeccato: il login della sottoscrizione non si muove mai, il gateway cambia solo un URL. I limiti di questa lettura: cinque run per cella, un solo motore scacchistico, un repository di benchmark che nessuno ha rieseguito, e nessuna sessione routed mia. Ho misurato la lista dei tool e la richiesta, non Jev. Jev in sé è economico. La deviazione no.
