Come sto misurando il costo reale di Claude e Codex

Sto cercando di capire quali modifiche a un workflow con Claude o Codex riducano le risorse necessarie per completare un’attività, mantenendo corretto il risultato. Il problema è misurare tutto il lavoro: una risposta più breve può aver richiesto altrettante letture, oppure lasciare più correzioni a chi la controlla.

I token sono le unità in cui il modello elabora il testo. Per decidere se un’ottimizzazione conviene, tengo conto anche del costo, del tempo impiegato e della revisione umana. Ho un prototipo, controlli automatici e alcune esecuzioni circoscritte; manca ancora un confronto sufficiente per dichiarare una percentuale di risparmio. Claude Code: consumi e costi.

Nel workspace esistevano già istruzioni di progetto, skills, ruoli e script. L’audit ha portato in primo piano un problema di misura: ricostruire il consumo del lavoro completo, distinguendo la configurazione richiesta da ciò che era stato effettivamente eseguito. Il prototipo che sto sviluppando usa un runner, cioè un processo che avvia un’attività delimitata e raccoglie i dati disponibili sull’esecuzione.

Il video di Michele Cotti sulle ottimizzazioni di Claude aggiunge spunti utili a questa ricerca: rewind, pianificazione, handoff e gestione del contesto. Mi interessa capire in quali condizioni ciascun intervento riduca il lavoro necessario per arrivare a un risultato accettabile. I comandi e le configurazioni che seguono servono a rendere concrete le varianti da confrontare.

Che cosa entra nel costo di un’attività

La mia unità di confronto è il task con un risultato verificato. Nel perimetro entrano preparazione, chiamate agli strumenti, passaggi a un altro agente, verifiche e correzioni. Fisso prima i criteri di accettazione: una procedura che si ferma senza soddisfarli rimane un tentativo fallito.

Per esempio, una ricerca mirata sulla paginazione potrebbe leggere meno file e ignorare l’ordinamento che produce i duplicati. Se poi deve allargarsi e ripetere il lavoro, voglio contare entrambi i tentativi.

Il contesto è il materiale disponibile per la prossima risposta. I token sono le unità con cui il modello elabora quel materiale e genera l’output. Il consumo si accumula attraverso le richieste, anche quando una parte del contesto rimane uguale.

Un modello didattico chiarisce perché una chat lunga può pesare: se cinque richieste contengono rispettivamente uno, due, tre, quattro e cinque blocchi da 1.000 token, l’input complessivo è 15.000 token, non 5.000. È una somma delle lunghezze, non una crescita esponenziale. Per ricavarne un costo servono anche modello, cache e output.

Con un abbonamento, meno token non si trasformano automaticamente in euro restituiti. Il beneficio può essere più lavoro nella quota disponibile, meno attese o meno extra a pagamento. Con una API key contano invece le tariffe del servizio. Controlla come sei autenticato: Claude Code può usare la fatturazione API quando è configurata una chiave. Piano Pro/Max e fatturazione API.

In Claude Code, /usage mostra utilizzo e limiti disponibili; la cifra locale in dollari è una stima API. Le percentuali attribuite a skill, agenti o integrazioni indicano l’uso interessato e possono sovrapporsi: non sono percentuali di risparmio ottenibile. Guida ufficiale ai costi.

La scheda di confronto deve permettermi di collegare una differenza di consumo a ciò che è successo nel task:

Un dato non rilevabile resta indicato come non disponibile. La scheda serve anche a capire quando due esecuzioni non sono confrontabili.

Da dove parte il carico

Prima di cambiare il workflow mi serve capire che cosa carica il client e quali dati espone. In Claude Code, /context mostra che cosa occupa il contesto; /usage aiuta a leggere utilizzo e componenti coinvolte. Una finestra già occupata prima del task mostra materiale preparato per il modello: non dimostra, da sola, che sia appena avvenuta una chiamata fatturata.

Per la configurazione usa /doctor. È una skill inclusa che esamina il setup e propone correzioni da confermare; i consigli sull’utilizzo recente richiedono Claude Code 2.1.305 o successivo, un piano compatibile e non sono disponibili durante Remote Control. Il comando da terminale claude doctor controlla invece l’installazione. Diagnostica con /doctor.

Un plug-in è un pacchetto di estensioni: può includere skill, cioè procedure per un’attività, e server MCP (Model Context Protocol), che mettono strumenti a disposizione dell’agente. Lo schema descrive che cosa fa uno strumento e quali argomenti accetta; l’output contiene il risultato della chiamata.

Per un plug-in specifico, nel terminale c’è claude plugin details nome-plugin: sostituisci il nome con quello installato. Distingue la stima del carico sempre presente da quello attivato all’uso. Gli schemi MCP risolti a runtime richiedono l’ispezione del contesto. Misurare il costo dei plug-in.

Questi segnali aiutano a scegliere quale variabile mettere alla prova:

Che cosa vale la pena caricare

Una prima variante riguarda il materiale caricato all’avvio. Terrei fissi task e modello, separando dalle istruzioni ricorrenti le procedure occasionali. Nella scheda confronterei il contesto iniziale e le letture successive: un avvio più leggero perde utilità se l’agente deve cercare le regole mancanti o rifare una modifica. CLAUDE.md conserva orientamento, vincoli e comandi essenziali; una procedura lunga usata raramente può stare in una skill o in un riferimento da leggere al bisogno. Suddividere un file in più @import, caricandoli comunque tutti, organizza i documenti ma non alleggerisce il contesto. Le 200 righe consigliate per CLAUDE.md sono un obiettivo di concisione, non un limite che tronca il file. Istruzioni efficaci.

Una skill installata non equivale al suo intero contenuto già caricato: normalmente Claude Code vede le informazioni per selezionarla e legge il corpo quando la usa. Le skill pre-caricate esplicitamente in un subagente fanno eccezione. Conta quindi la qualità del catalogo, oltre al numero di cartelle. Caricamento delle skill.

Per MCP, i client e i modelli compatibili possono rinviare gli schemi dei tool tramite tool search. Un server configurato non implica che ogni sua definizione sia già nel prompt. Restano da controllare gli output: una risposta con migliaia di record può pesare più della descrizione che l’ha resa disponibile. MCP tool search.

Il numero dei plug-in, da solo, mi dice poco sul costo del task. Un plug-in di navigazione del codice, per esempio, può trovare un simbolo evitando varie ricerche e letture di file. Togliere proprio quello per ridurre il numero dei plug-in sarebbe una scelta poco utile. La guida ai costi propone questa possibilità.

Per approfondire il confine fra istruzioni iniziali e procedure richiamate, c’è la guida alle skills per Claude e Codex.

Il costo dei tentativi sulla strada sbagliata

Per i cambiamenti articolati vorrei confrontare il lavoro con e senza una fase esplicita di pianificazione. Il piano aggiunge letture e ragionamento all’inizio; può evitare una strada sbagliata e le correzioni che ne seguono. Nella scheda contano quindi anche i tentativi dopo il piano e il tempo fino all’accettazione. Per una piccola correzione già definita, quella fase potrebbe essere solo lavoro aggiuntivo. In Claude Code la variante si può impostare con /plan o avviando la CLI con claude --permission-mode plan. Quando usare Plan Mode.

Un’altra variante è fornire insieme i criteri dello stesso risultato. “Correggi il problema di paginazione, aggiungi il test sulla pagina finale e mostrami il diff” rende il lavoro completo visibile prima della modifica. Confronterei questa richiesta con un percorso che introduce gli stessi criteri un pezzo alla volta, contando anche le modifiche da riaprire. Il vantaggio atteso si perderebbe se la richiesta unificata fosse tanto ampia da far saltare un controllo. Mantieni invece separate attività indipendenti o passaggi che richiedono una decisione prima di proseguire. Anthropic consiglia di raggruppare le domande correlate.

Se il ramo intrapreso è sbagliato, continuare a scrivere “riprova” può trascinare tutti i tentativi nella conversazione. Nella chat web puoi riformulare il messaggio precedente; in Claude Code /rewind offre il ritorno a un checkpoint. Prima conserva le poche scoperte utili e indica quale approccio evitare.

Il menu distingue ripristino della conversazione, dei file o di entrambi. Ripristinare soltanto la chat può lasciare nel working tree le modifiche già fatte. Inoltre i checkpoint non annullano tutte le operazioni di shell o su servizi esterni: un deploy o una modifica al database richiedono il proprio ripristino. Come funziona il checkpointing.

La continuità del lavoro e il costo della compattazione

La compattazione è una delle leve che voglio confrontare sul lavoro completo. Un riepilogo utile deve permettere alla sessione successiva di proseguire senza rifare l’esplorazione o perdere il requisito.

/compact sintetizza la storia per continuare lo stesso lavoro. Una nuova chat, o /clear, è più adatta quando cambia l’obiettivo o vuoi ripartire da uno stato selezionato. La sintesi richiede lavoro al modello e può far rileggere materiale utile: compattare continuamente ha un costo.

Prima della ripresa conserva il requisito, le decisioni che lo vincolano, i file coinvolti, i controlli già eseguiti e il prossimo passo. Per esempio:

Task: correggere la paginazione dell'elenco ordini.
Vincolo: mantenere stabile l'ordinamento quando due ordini hanno la stessa data.
Stato: query modificata; test sulla pagina finale ancora da aggiungere.
Riferimenti: issue del task, commit corrente, file della query e relativi test.
Prossimo passo: verificare duplicazioni e righe saltate fra due pagine consecutive.

È uno schema di handoff, non il nome di un comando preinstallato. Una skill può produrlo in modo ripetibile; /handoff o /sessionoff hanno senso solo se hai installato procedure con quei nomi. La ripresa deve anche verificare lo stato dei file. Il percorso completo è nell’articolo su memoria e handoff.

La compattazione non risolve istruzioni iniziali sovradimensionate: alcune vengono reinserite nel contesto successivo. E la cache è un meccanismo diverso: riutilizza una parte iniziale della richiesta rimasta invariata, chiamata prefisso, con condizioni e durata proprie. Cambiare la storia o il modello può modificare quel riuso; conservare una chat enorme solo per la cache può invece trattenere molto materiale inutile. Contesto dopo la compattazione, prompt caching.

Se lavori ancora nella sessione e la cache è calda, la richiesta che produce la sintesi può riusare il prefisso. Se torni dopo una pausa più lunga della durata della cache, deve rielaborare quella storia: compattare al rientro può costare proprio la lettura che volevi evitare. A un’interruzione naturale scegli se sintetizzare prima di fermarti oppure conservare un handoff per la nuova sessione. In /usage, Prompt cache (main) mostra lo stato della cache principale dalla versione 2.1.251, dopo una prima risposta; esclude i subagenti. Compattazione e cache.

Anche i Projects e le istruzioni personali di Claude web aiutano a riutilizzare informazioni senza riallegarle o riscriverle ogni volta. Non trasformano i documenti in input gratuito permanente: la guida all’utilizzo distingue riuso, cache e limiti. Nel repository, il corrispettivo operativo è organizzare istruzioni e riferimenti pertinenti; le impostazioni della chat web non sono una configurazione universale di tutti i client.

La soglia automatica come variante

Per isolare l’effetto della soglia, confronterei il comportamento predefinito con una soglia esplicita, mantenendo task, modello e istruzioni. Registrerei il contesto prima e dopo la sintesi, il suo consumo e le letture necessarie per riprendere. Un contesto più piccolo accompagnato da nuova esplorazione o perdita del requisito sarebbe un motivo per rivedere quella scelta.

Il comando richiede Claude Code 2.1.221 o successivo. Nella sessione controlla che Auto-compact sia attivo in /config: impostare una soglia non abilita un automatismo disattivato. Anche DISABLE_AUTO_COMPACT o DISABLE_COMPACT possono impedirlo; se dipendono da una policy aziendale, la modifica va concordata con chi la gestisce. Variabili della compattazione.

Per provare una finestra di 200.000 token in un solo avvio, dal terminale nella cartella del progetto:

claude --version
claude --autocompact 200k

Dentro la sessione, /autocompact mostra l’impostazione e /context il contesto. Per salvare la scelta per il modello corrente usa /autocompact 200k; con /autocompact auto torni al comportamento previsto dal prodotto. Nelle versioni precedenti alla 2.1.288, il salvataggio non era per modello.

Uso 200.000 come valore illustrativo della configurazione, senza indicarlo come soglia ottimale. Il valore è limitato dalla finestra del modello; la documentazione accetta impostazioni fra 100K e 1M token. Controlla gli override: CLAUDE_CODE_AUTO_COMPACT_WINDOW può prevalere sulla scelta. La percentuale della statusline si riferisce alla finestra del modello e non coincide necessariamente con la soglia configurata. Configurazione dell’auto-compattazione.

Quando una Mod aggiunge qualcosa

Le Mods ufficiali di Claude Code sono plug-in JavaScript o TypeScript che reagiscono agli eventi della sessione. Una Mod può leggere $.session.usage() e richiedere $.session.compact({ instructions }), per esempio per collegare la compattazione a un checkpoint del lavoro. Per la sola soglia in token, l’impostazione nativa è più semplice. Reference delle Mods.

La variante successiva aggiungerebbe una compattazione anticipata legata a un checkpoint, mantenendo la configurazione nativa come fallback. Il confronto dovrebbe mostrare se scegliere un momento in cui stato del task e prossimo passo sono già registrati riduce la ricostruzione del lavoro dopo la sintesi. Una politica aggiuntiva può quindi anticipare la soglia nativa solo quando hai confermato quel checkpoint. Un comando della Mod può raccogliere questa conferma. Se la soglia anticipata è superata durante una diagnosi ancora aperta, la Mod avvisa e aspetta; l’automatismo nativo resta attivo come protezione al proprio limite. Il modulo deve consumare o invalidare la conferma quando lo stato cambia: il numero di token non rivela se il lavoro è pronto per essere sintetizzato.

La richiesta di compattazione va gestita tra i turni, evitando chiamate concorrenti e tentativi infiniti se viene rifiutata. Un evento che aggiorna il consumo non significa sempre che l’agente sia fermo.

Per rendere implementabile questa variante, la procedura ufficiale per creare una Mod parte da Claude Code 2.1.287 o successivo e dalla skill inclusa /plugin-authoring. Il prompt seguente descrive la politica proposta, da trasformare in codice prima di poterla mettere alla prova:

Create a Claude Code mod using the types generated by my installed version.
Keep native auto-compaction enabled as the fallback.
Add a /context-ready command for this mod: I use it to confirm that the
current task state and next step have been recorded.
After a turn ends, check the observed context tokens. Above a configurable
early threshold, compact only if that explicit checkpoint is still valid.
Otherwise show a reminder and leave native compaction in control.
Consume the checkpoint after compaction and invalidate it on new work.
Preserve task, decisions, file references and open checks in the summary.
Handle missing measurements, concurrent calls and vetoes without retry loops.
Explain loading, tests and how to disable the mod before I approve running it.

Claude genera codice da esaminare e approvare. La guida ufficiale spiega caricamento, validazione e test; non basta nominare la soglia nel prompt per ottenere una politica affidabile. Nel confronto terrei separati il costo delle esecuzioni e il lavoro per scrivere, verificare e mantenere la Mod. Se il riepilogo perdesse informazioni, le letture e le correzioni necessarie per riprendere potrebbero annullare il risparmio atteso nelle richieste successive alla compattazione.

Modelli e deleghe nel conto finale

Sto trattando modello, effort e delega come variabili separate. Cambiarli insieme alle istruzioni renderebbe difficile attribuire il risultato a una scelta precisa.

Per il modello distinguerei due effetti: cambiare il prezzo per token e cambiare il lavoro necessario per risolvere il task. Un modello meno costoso può richiedere più tentativi; uno più capace o un effort più alto, cioè un maggiore sforzo di ragionamento richiesto, possono evitare correzioni su una decisione difficile. Nella scheda confronterei configurazione osservata, consumo e accettazione per la stessa classe di task. La scelta dipende dal costo di tutti i tentativi, non soltanto dalla tariffa della prima richiesta.

I subagenti isolano ricerche e risultati voluminosi dalla conversazione principale, ma eseguono richieste proprie. Per una ricerca delimitata confronterei un agente solo con una delega: consumo aggregato, tempo trascorso e lavoro per leggere e verificare i rapporti. È possibile guadagnare tempo aumentando il consumo; far rileggere lo stesso repository a cinque agenti può invece aggiungere preparazione e coordinamento senza migliorare il risultato. Contesto dei subagenti.

Per una domanda laterale breve, Claude Code ha /btw domanda: usa il contesto disponibile senza aggiungere lo scambio alla cronologia principale e senza usare strumenti. La risposta richiede comunque una chiamata al modello. Se il risultato cambia il task, riportalo nel lavoro principale. Domande laterali con /btw.

Una statusline può rendere visibile l’occupazione del contesto. Per organizzare il lavoro, guarda anche i reset delle quote: una finestra breve che si rinnova non elimina un limite settimanale ancora esaurito. Pianifica i task utili rispetto a entrambi; riempire la quota solo perché sta per rinnovarsi non migliora il risultato.

Le stesse ipotesi, nel client Codex

Questi riferimenti riguardano la CLI: app e integrazioni possono esporre funzioni diverse. Non trasferire un comando soltanto perché i prodotti risolvono problemi simili. Un fork separa la conversazione, senza annullare le modifiche ai file o ai servizi esterni; anche una chat laterale comporta consumo.

Fonti: comandi della sessione, diagnostica CLI, skills, MCP.

Per la compattazione automatica, in ~/.codex/config.toml puoi aggiungere o modificare le chiavi top-level, prima delle sezioni fra parentesi quadre, senza duplicarle:

model_auto_compact_token_limit = 200000
model_auto_compact_token_limit_scope = "total"

È una configurazione illustrativa in token, da usare con una finestra del modello adeguata alla soglia scelta. total conta tutto il contesto attivo. Senza una soglia esplicita si applicano i valori del modello. La reference Codex documenta anche il limite dell’output dei tool: riduci il rumore conservando diagnostiche ed errori necessari. Avvia un nuovo processo dopo la modifica; /debug-config aiuta a controllare livelli e override, mentre /status mostra modello e consumo. Profili, configurazione di progetto e opzioni CLI possono prevalere sul file personale. Per annullare la modifica ripristina i valori precedenti; se le chiavi non c’erano, rimuovile.

In Codex userei la stessa scheda, conservando il significato dei contatori esposti dal client. Prima confronterei la variante con il comportamento di partenza nello stesso ambiente. La domanda rimane quanto lavoro occorre per arrivare all’accettazione: una skill evita esplorazione, un riepilogo permette di ripartire, una delega riduce le attese? Le regole di prezzo e utilizzo distinguono piano ChatGPT e API: il listino API non converte automaticamente la quota residua dell’abbonamento.

Il confronto che voglio fare

Per il primo confronto partirei da una correzione della paginazione: stesso stato iniziale, stesso requisito e stesso test sulla pagina finale. Una variante legge un ambito ampio; l’altra restringe la ricerca. Se la seconda salta un file importante e deve ricominciare, voglio che quel tentativo rimanga nel conto.

Cambierei una sola variabile per volta, registrando prima e dopo lo stesso indicatore e la sua unità: token consumati, percentuale di quota usata o residua, oppure importo stimato. Nel confronto entrano anche il tempo trascorso, le verifiche e le correzioni umane fino all’accettazione. Se il reset cade durante la prova, va annotato: sottrarre due percentuali ai lati del reset non misura il consumo. Sessioni e agenti devono rientrare nel perimetro senza sommare due volte lo stesso totale.

Quando il costo monetario è osservabile, la misura che propongo è:

costo per task accettato = costo di tutti i tentativi / numero di task accettati

Nel numeratore entrano anche i tentativi scartati e i retry. Se nessun task viene accettato, il rapporto non è definito: riporterei il costo sostenuto e zero task accettati. Voglio leggere quel valore insieme al tasso di successo e al tempo di revisione; il listino API, da solo, non misura il costo del mio abbonamento.

Questo confronto mi serve anche per scegliere dove intervenire dopo. Se una ricerca mirata riduce le letture ma aumenta i tentativi, proverei prima a migliorarne i criteri. Se invece il lavoro si ripete a ogni ripresa, guarderei l’handoff e la compattazione. Per la paginazione dell’esempio, il dato che voglio ottenere è quanto costa consegnare una correzione che supera il controllo finale, compresi i tentativi necessari per arrivarci.