Codex: 5 mosse per spendere meno token

RTK, CodeGraph, Caveman e tre agenti mirati: cinque mosse pratiche per ridurre il rumore nel contesto di Codex e misurare il risultato.

Filtra l’output con RTK, interroga il codice con CodeGraph, usa Caveman per risposte brevi e assegna agli agenti solo obiettivi precisi. Misura sempre i risultati.

Un terminale verboso, ricerche ripetute nel repository e risposte troppo lunghe consumano contesto. Ecco cinque interventi concreti per dare a Codex meno rumore e più informazioni utili. Misura sempre sul tuo progetto: nessuno strumento garantisce da solo più quota disponibile.

1. RTK: comprimi l’output dei comandi

RTK (Rust Token Killer) è un proxy CLI scritto in Rust. Filtra output di git, rg, test e altri comandi prima che arrivino al modello. Un singolo binario limita anche il costo locale di CPU e memoria, ma il vantaggio da misurare qui sono i token dell’output.

rtk init -g --codex
rtk git status
rtk test npm test
rtk gain

Installa il binario dalle release ufficiali, poi esegui l’inizializzazione. Per Codex questa aggiunge istruzioni in AGENTS.md e RTK.md: non intercetta automaticamente ogni comando. Su Windows nativo usa esplicitamente il prefisso rtk.

Nello screenshot qui sotto, rtk gain mostra 261,6 milioni di token di output dei comandi risparmiati (85%) su 57.837 comandi nello scope globale. È una stima dell’output filtrato da RTK, non l’85% dei limiti complessivi di Codex.

2. CodeGraph: trova il codice giusto senza aprire tutto

CodeGraph indicizza simboli, chiamate e dipendenze del repository e li espone a Codex via MCP. La versione recente usa un kernel di parsing in Rust e un runtime incluso. Una ricerca strutturale può sostituire molte letture esplorative di file; il risparmio reale dipende però dal progetto e dalle domande.

npm i -g @colbymchenry/codegraph
codegraph install
cd tuo-progetto
codegraph init
codegraph status

install collega l’agente; init costruisce l’indice per il progetto. Per vedere l’impatto senza uno screenshot di “token salvati”, assegna la stessa domanda a due sessioni pulite, con e senza CodeGraph. Esempio: «Dove parte il flusso di autenticazione e quali funzioni lo chiamano?». Confronta chiamate agli strumenti e token di sessione con /status. L’indice ha un costo iniziale: misuralo su più task.

3. Caveman: meno parole, stessa precisione

Cerca Caveman nel marketplace ufficiale dei plugin di ChatGPT/Codex. Il progetto è di Julius Brussee. Chiedigli di comprimere la prosa delle risposte: «diagnosi, modifica, verifica, rischio» in poche righe. Mantieni integri codice, comandi, percorsi, errori e avvisi di sicurezza.

Per esempio: «Il componente si aggiorna perché riceve un nuovo oggetto a ogni render. Stabilizza la prop con useMemo». La forma è corta, ma la causa e l’azione restano verificabili. Usa questa modalità nelle risposte frequenti; per una decisione complessa chiedi il dettaglio necessario.

4. Tre agenti, un obiettivo preciso

Metti un file per agente in ~/.codex/agents/: Astra pianifica e dà criteri chiari, Luna implementa, Sol scrive ed esegue i test seguendo quei criteri. Un agente aggiunge anche contesto e chiamate: usali per obiettivi delimitati, non per ogni domanda.

# astra.toml
name = "astra"
description = "Plan scoped goals and guide implementation and tests."
model = "gpt-6-astra"
developer_instructions = "Define scope, acceptance criteria and handoffs for Luna and Sol. Be concise."

# luna.toml
name = "luna"
description = "Implement code for an approved scoped goal."
model = "gpt-6-luna"
developer_instructions = "Implement Astra's plan; keep changes focused. Prefer RTK for supported noisy commands."

# sol.toml
name = "sol"
description = "Write and run tests for Luna's changes."
model = "gpt-6-sol"
developer_instructions = "Use Astra's acceptance criteria. Write meaningful tests, run focused checks and report failures. Prefer RTK."

Prompt d’esempio: «Obiettivo: correggi il login. Astra definisce file e criteri; Luna modifica il codice; Sol scrive i test. Restituisci solo esito e rischi». I file TOML degli agenti richiedono name, description e developer_instructions.

5. Istruzioni globali corte e in inglese

Inserisci le preferenze persistenti in ~/.codex/AGENTS.md. È il file di istruzioni globali letto da Codex, non un vero system prompt. Scrivilo in inglese e tienilo breve: meno testo viene riletto a ogni avvio. L’inglese può essere più compatto, ma verifica i token invece di presumere un risparmio fisso.

# Global Codex instructions
- Keep answers brief and precise; report result, evidence and risks.
- Prefer RTK for supported noisy commands, including in agents.
- Use Caveman for concise prose; preserve code, paths, errors and warnings.
- For explicit, scoped goals only: Astra plans; Luna codes; Sol writes tests using Astra's criteria.
- If tools, agents or plugins fail, inspect ~/.codex/config.toml and the active plugin list.

Un’istruzione guida il comportamento, non forza l’esecuzione di RTK. Verifica nei log quali comandi sono stati davvero usati. Se un agente ignora le regole, controlla anche le istruzioni di progetto che possono prevalere su quelle globali.

Extra: controlla i plugin attivi

Dopo un aggiornamento dei modelli, rivedi i plugin abilitati. Un plugin obsoleto o con istruzioni in conflitto può aggiungere contesto e ostacolare il lavoro. Disattiva solo quello sospetto, riprova lo stesso task e confronta il risultato; se il problema persiste, controlla ~/.codex/config.toml.