01Siamo sempre a corto di token, risparmiamo dove possibile
C’è poco da fare, l’adozione dei tool di AI continua a crescere, soprattuto per chi si occupa di sviluppo software, i modelli offerti sono sempre più intelligenti e performanti ma più diventano smart più cose diamo loro da fare: il side effect è che bruciamo sempre più token ogni giorno che passa.
Per chi come noi non lavora in un'azienda che spinge per usare più token possibile per “dimostrare che stiamo facendo il massimo con l’AI" (cosa folle oltre misura), I limiti che i fornitori di modelli AI impongono sono un peso gravoso.
Più l’agente ha a disposizione tool più token “non progettuali” consuma: che sia per il nuovo serve MCP che ti accende la macchinetta del caffè (idea interessante, devo provarci), per un grep -R troppo largo, un find su mezza codebase o un git diff particolarmente pesante, il numero di token che entrano in gioco sale vertiginosamente: non è che tutto l’output effettivamente serva all’agente generando, tanto di esso è solo “rumore”.
RTK nasce con questo scopo: prendere l’output del terminale prima che arrivi all’agente, lo riduce e restituisce una versione più corta ma semanticamente pertinente. Meno testo in output: meno token nel contesto.
02Cos’è RTK
RTK, Rust Token Killer, è un proxy CLI per comandi da terminale. Si mette tra il comando e l’output che verrebbe letto dall’agente AI: invece di passare al modello tutto l’output raw, RTK applica strategie come filtering, grouping, truncation e deduplication.
Detto in modo pratico: se l’agente lancia un comando molto verboso, RTK prova a trasformare quel blocco in una sintesi più corta, con gruppi e campioni utili.
Qui serve una distinzione. RTK non comprime il ragionamento del modello. Non decide se il fix è giusto. Non garantisce che la risposta finale migliori. Interviene prima, sull’output del terminale, cioè su una parte spesso ignorata del consumo di token.
03Di che numeri parliamo
Sulla carta la riduzione nel numero di token attuata da RTK arriva a raggiungere anche il 90% con specifici comandi come cargo test o npm test e si assesta su un 70 - 80% per comandi più frequenti come cat e grep.
Riporto la tabella comparativa che trovate nella repo.
Da un mio primo test dopo qualche ora di lavoro ci assestiamo su questi valori, comunque di tutto rispetto.
Mi riservo di aggiornare l’articolo se dopo una settimana il rendimento migliorerà o peggiorerà.
04Con quali CLI / Agenti funziona?
Il supporto è abbastanza ampio e copre i provider più blasonati come Codex / GeminiCLI / Claude Code, Cursor e anche Antigravity ed Hermes.
È possibile attivare singolarmente il supporto per i vari servizi tramite i comandi della CLIrtk init -g # Claude Code / Copilot (default)rtk init -g --gemini # Gemini CLIrtk init -g --codex # Codex (OpenAI)rtk init -g --agent cursor # Cursorrtk init --agent windsurf # Windsurfrtk init --agent cline # Cline / Roo Codertk init --agent kilocode # Kilo Codertk init --agent antigravity # Google Antigravityrtk init --agent hermes # Hermes
05Dove può far risparmiare token
Come intuibile, RTK ha senso quando l’agente deve leggere output ripetitivi o molto lunghi.
Un grep su molte occorrenze può buttare nel contesto centinaia di righe simili. Un find su una codebase ampia può diventare una lista di file poco utile. L'output di una test suite può contenere molto contorno intorno al segnale: pass, fail, file coinvolti, errore principale.
In questi casi RTK riduce il materiale che entra nel contesto senza apportare alcun valore al ragionamento dell’agente.
Nella mia prima sessione di test ho notato che i risultati migliori pare darli con test suite, e con sistemi agentici come Hermes / Openclaw che fanno tantissime tool call con comandi bash: rtk sembra riuscire a ripulire per bene l’output senza rimuovere informazioni pertinenti utili all’agente di turno.
06Il gioco vale la candela?
Decisamente sì, ma il vantaggio non è così scontato ed è molto personale.
Ogni “goccia di token” risparmiata può aiutare a contenere i costi ed evitare di dover interrompere il lavoro sul più bello e, soprattutto su larga scala, anche un piccolo risparmio reiterato nel tempo può portare ad un beneficio considerevole.
Viene da sé che questo strumento è più utile quanto il vostro sistema di agenti si occupa di attività di sviluppo, automazione, o computer use: se usate codex o claude per scrivere testi… beh ecco lì non penso otterreste molti benefici da RTK.
Non è spinto come Caveman, di cui parlerò in un altro articolo, ma vale la pena di essere provato.
Eccovi il link alla repository: https://github.com/rtk-ai/rtk
07FAQ
RTK riduce sempre i costi LLM?
Non necessariamente. Riduce il consumo di token del vostro agente AI per tutti i comandi eseguiti da terminale: se disponete di un abbonamento Claude / ChatGPT sarà solo un risparmio per contrastare i limiti di consumo usati dal servizio; se invece utilizza API Key e lavorate a consumo, sì allora comporterà anche un piccolo risparmio.
RTK comprime il reasoning del modello?
No. RTK lavora prima, sull’output dei comandi da terminale. Non comprime il ragionamento interno del modello e non garantisce da solo risposte migliori.
Quando conviene usare l’output raw invece di RTK?
Quando stai facendo debug fine e ti serve ogni riga, soprattutto se l’errore può stare in un dettaglio raro. RTK può sintetizzare, raggruppare o troncare. Questo aiuta quando l’output è enorme, ma può essere rischioso quando il dettaglio grezzo è decisivo.
Pubblicato il 23 mag 2026.