IA: non è il “grazie” a costare, ma la conversazione che si allunga

Il costo nascosto del semplice “grazie”

Dire “grazie” a un’intelligenza artificiale sembra un gesto di cortesia a costo quasi nullo. Tuttavia, il vero peso economico non è il token “grazie” ma l’intero filone di conversazione che viene rinviato al modello ad ogni scambio. Un post recente su LinkedIn ha illustrato, con ironia, il potenziale impatto: partendo da 120 milioni di utenti, con una media di otto “grazie” al giorno, si arriverebbe a circa 350 miliardi di espressioni di cortesia all’anno.

Inserendo questi volumi in un calcolatore online, si ottengono risultati sorprendenti. Un singolo “grazie” inviato a un modello grande come Claude Sonnet 5.5 richiederebbe circa 23 GWh all’anno; con un modello più piccolo, meno di 1 GWh. La scelta del modello pesa quindi trent’volte più della mera cortesia.

Perché il “grazie” costa di più di quanto sembri

Un modello di linguaggio non possiede memoria permanente tra due messaggi. Per “ricordare” la conversazione, l’applicazione gli restituisce, ad ogni turno, l’intero storico o una sua parte consistente: i messaggi dell’utente, le risposte dell’IA, le istruzioni di progetto e i documenti allegati. Così, un “grazie” inviato al termine di uno scambio lungo comprende non solo il token di cortesia, ma migliaia di token di contesto.

Nel medesimo scenario, se il “grazie” è accompagnato da 5 000 token di storico, l’energia stimata si moltiplica per dieci e il costo API passa da circa 100 milioni a 3,6 miliardi di dollari all’anno.

Il costo di una conversazione non cresce linearmente con la sua lunghezza, ma più velocemente. Quando l’intero storico viene rinviato, ogni nuovo scambio rielabora tutti i precedenti: al centesimo messaggio si paga nuovamente per i novantanove precedenti. Consideriamo un progetto di 60 scambi, con messaggi di 200 token, risposte di 300 token e 1 500 token di istruzioni e file di progetto: il modello elabora quasi un milione di token in totale.

Il ruolo del cache

I fornitori hanno una risposta: il cache. Un storico già processato può essere riletto a costi inferiori. Ad Anthropic, la lettura in cache è fatturata da 10 a 40 volte meno di un token di ingresso, a seconda del modello (20 volte per Sonnet 5.5 e Opus 5.5, 40 volte per Fable 5.1, 10 volte per Haiku 5.5). L’estimazione energetica del repository open source claude‑carbon indica che il cache rappresenta circa l’8 % di un token di ingresso. Le applicazioni consumer hanno tutti i motivi per sfruttare il cache, anche se i loro meccanismi interni non sono pubblici. Il cache alleggerisce la bolletta, ma non risolve il problema fondamentale della crescita esponenziale dei costi.

Conversazioni più lunghe, risultati peggiori

Una conversazione più estesa non solo costa di più, ma produce risultati di qualità inferiore. Già nel 2023, ricercatori guidati da Nelson Liu di Stanford hanno dimostrato che i modelli gestiscono male le informazioni collocate al centro di un contesto esteso. Il fenomeno è persistito nelle generazioni successive.

Nel luglio 2025, la società Chroma ha testato 18 modelli, tra cui o3, Claude 4 e Gemini 2.5, con e senza modalità di ragionamento, su compiti deliberatamente semplici e controllati: la loro affidabilità diminuisce al crescere della lunghezza dell’input. Sebbene questi compiti non siano conversazioni ordinarie, l’effetto rispecchia quello osservato dagli utenti.

Il semplice aumento del livello di ragionamento non è sufficiente. Sempre da Chroma, la modalità “riflessione” migliora nettamente i punteggi, ma il divario tra la versione corta e quella lunga di una stessa attività persiste. Il benchmark NoLiMa, presentato da Adobe Research e dall’Università LMU di Monaco alla conferenza ICML 2025, evidenzia un risultato ancora più netto: su un sotto‑insieme di 10 domande tra le più difficili, il modello di ragionamento o1 di OpenAI risponde correttamente al 92 % con 4 000 token di contesto, al 78 % con 8 000 token e al 31 % con 32 000 token.

Una pre‑pubblicazione del 2026, “Reasoning Shift”, dimostra infine che uno storico di conversazione riduce il tempo di ragionamento dei modelli e la loro capacità di verificare il proprio lavoro, anche per un modello impostato su sforzo molto elevato. Nessuno di questi studi ha testato i modelli più recenti di Anthropic o OpenAI in modalità di sforzo massimo, ma non vi è alcuna indicazione che tale configurazione compensi un contesto sovraccarico.

Esperienza pratica

Chiunque abbia sperimentato questi sistemi sa che, superata una certa soglia, il modello dimentica le istruzioni iniziali, mescola versioni di documenti, si ripete. Si ricorre a riformulazioni, rigenerazioni e correzioni. Ogni nuova generazione produce testo, ed è proprio quel testo ad avere il costo più elevato. Con i fattori di claude‑carbon, un token scritto da Claude Sonnet 5.5 consuma circa 21 volte più energia di un token letto.

Il cambio di modello non è una soluzione

Il riflesso più comune aggrava il problema: si avvia una conversazione sul modello più potente e si le affida tutto, dalla strategia alla formattazione di una tabella. Le attività semplici non necessitano di tale potenza, ma cambiarlo a metà conversazione è costoso.

Il motivo è duplice. Prima, il nuovo modello non eredita la “comprensione” del precedente; deve rileggere l’intera conversazione dall’inizio, e il cache non aiuta perché conserva calcoli specifici del modello precedente, inutilizzabili dal nuovo. Seconda, più la conversazione è lunga, più il cambio è oneroso, e il nuovo modello eredita lo stesso storico sovraccarico, con la medesima perdita di precisione. In pratica, si resta sul modello più grande per tutta la durata.

Una nuova organizzazione: la conversazione madre

La soluzione non consiste nel gestire meglio una conversazione lunga, ma nell’organizzarsi prima di cominciare. La “metodologia della conversazione madre” si articola in cinque regole, indipendenti dal provider e applicabili a tutti gli strumenti che consentono di raggruppare le conversazioni per progetto o cartella, sia su OpenAI, Anthropic o altri.

1. Conversazione madre di comando, non di produzione

Per ogni progetto, si crea una conversazione “madre” che funge da postazione di comando: definisce l’obiettivo, suddivide il lavoro in task e mantiene la visione d’insieme. Può operare su un modello avanzato, poiché ragiona sulla struttura del progetto, ma scrive poco: decisioni e briefing, mai i deliverable.

2. Conversazioni figlie per task, avviate da un brief

La madre redige il messaggio di avvio per ogni “figlia”. Il brief contiene quattro elementi, in linea con le raccomandazioni di Anthropic per i sotto‑agenti:

• Obiettivo
• Formato di output atteso
• Fonti da utilizzare
• Limiti della task

Una figlia vive solo per la durata del suo compito, scambia pochi messaggi e poi viene chiusa.

3. Documenti in cartella, non nel filone

I file di riferimento rimangono in una cartella collegata al progetto e vengono richiamati solo quando una figlia ne ha bisogno. Incollare lo stesso PDF tre volte in una conversazione equivale a farlo rileggere ad ogni messaggio, aumentando inutilmente il consumo di token.

4. Sintesi umana che risale, non la conversazione

Al termine di una task, la figlia produce un breve resoconto, che è l’unico elemento a risalire alla madre. Anthropic ha misurato, sul proprio sistema di ricerca, che i sistemi multi‑agente consumano circa 15 volte più token di una chat singola. Sebbene questo dato non misuri la nostra metodologia, ricorda che orchestrare è sobrio solo se si limita ciò che circola. La sintesi è letta, corretta o riscritta dall’utente prima di essere inviata alla madre, restituendo il controllo all’uomo e impedendo al modello di diventare l’ambiente di pensiero.

5. Scelta del modello all’apertura, figlia per figlia

Ogni figlia parte direttamente sul modello più adatto al suo compito: un modello piccolo per formattare, tradurre o riassumere; un modello più potente per analisi complesse; un modello specializzato per critiche o verifiche di ragionamento. La scelta avviene una sola volta, su un contesto breve, senza necessità di rileggerlo.

Benefici della metodologia madre‑figlia

Tre effetti si susseguono e si rinforzano:

• Scelta ottimale del modello senza pagare costi di cambio durante la conversazione.
• Riduzione drastica dei token trasmessi, poiché ogni figlia lavora su un contesto limitato e il cache è più efficace.
• Miglioramento della qualità, grazie a contesti più brevi che i modelli gestiscono con maggiore precisione.

In sintesi, organizzare le interazioni con le IA attraverso una struttura gerarchica di conversazioni consente di contenere i costi energetici e finanziari, di mantenere alta la performance e di preservare il controllo umano sull’intero processo.