Il consumo energetico di Claude Code rivela il costo nascosto degli agenti AI
Il consumo energetico di Claude Code ha raggiunto una stima di 170 kilowattora durante l'esperimento di otto settimane di un ricercatore, nonostante i guadagni di efficienza nelle moderne infrastrutture AI.
Lo scienziato del clima Zeke Hausfather ha monitorato 1.138 istruzioni inviate tramite l'agente di coding di Anthropic. Tali istruzioni hanno attivato oltre 14.000 chiamate al modello ed elaborato 3,2 miliardi di token. La sua stima centrale equivale a circa 150 wattora per prompt umano.
Questa stima è circa 600 volte superiore al dato energetico pubblicato per un tipico prompt testuale di Gemini. Il contrasto mette in discussione un'idea rassicurante sull'intelligenza artificiale: che un singolo prompt sia un'unità significativa per misurare i consumi.
Un agente AI non si limita a rispondere e fermarsi. Pianifica, chiama strumenti, legge i risultati, rivede il proprio contesto di lavoro e riprova. Una richiesta può quindi avviare una lunga catena di calcolo che rimane in gran parte invisibile all'utente.
Questo è il vero conflitto dietro l'ultimo dibattito sull'energia dell'AI. Google e altri fornitori hanno reso straordinariamente efficienti le singole risposte. Al tempo stesso, i prodotti agentici stanno trasformando ogni istruzione dell'utente in molte risposte, chiamate di strumenti e letture ripetute del contesto.
Il risultato non dimostra che ogni agente AI sprechi elettricità. È la prova che i consueti confronti per prompt non descrivono più una categoria in crescita del lavoro svolto dall'AI. Sviluppatori, acquirenti aziendali e pianificatori dell'infrastruttura hanno ora bisogno di misurazioni basate sui compiti completati.
Il consumo energetico di Claude Code cambia l'unità di misura
Il cambiamento importante non è il rilascio di un nuovo modello. È l'evidenza che un prompt umano possa nascondere un intero flusso di lavoro computazionale.
Hausfather ha esaminato la sua attività su Claude Code dal 31 maggio al 25 luglio 2026. Claude Code è un sistema di coding agentico, ovvero può pianificare ed eseguire una sequenza di azioni con un intervento umano limitato.
Durante quelle otto settimane, Hausfather ha inserito 1.138 prompt. I suoi log hanno registrato oltre 14.000 chiamate separate al modello, per una media di circa 12 chiamate per ogni prompt digitato.
Le sessioni hanno elaborato 3,2 miliardi di token. I token sono le unità che un modello linguistico legge e genera durante la gestione di testo, codice, istruzioni e contesto memorizzato.
Hausfather ha stimato che il carico di lavoro abbia consumato circa 170 kilowattora di elettricità del data center. Il suo intervallo di incertezza andava da circa 70 a 330 kilowattora, poiché Anthropic non pubblica misurazioni energetiche dirette per ogni chiamata al modello.
La stima centrale risultante era approssimativamente di 150 wattora per prompt umano. L'intervallo plausibile era da 60 a 290 wattora.
Per confronto, Google ha riportato che un prompt testuale mediano di Gemini Apps consumava 0,24 wattora nel suo ambiente di produzione. Tale dato includeva l'energia degli acceleratori, dei sistemi host, della capacità inattiva e dell'overhead del data center.
Le misurazioni di produzione di Google non sono necessariamente in contrasto con i calcoli di Hausfather. Descrivono un tipo diverso di attività.
Un prompt testuale di Gemini può produrre una risposta concisa. Un'istruzione di Claude Code può avviare una sessione che include ricerca, generazione di codice, esecuzione di comandi, debugging e valutazioni ripetute.
Questa distinzione spiega perché Hausfather sostiene che un prompt assomigli a un viaggio piuttosto che a una distanza fissa. Contare i viaggi dice poco a un analista, se non sa anche dove è andato ciascun viaggio.
La sua sessione mediana su Claude Code ha consumato una stima di 0,6 kilowattora. L'intervallo plausibile andava da 0,25 a 1,2 kilowattora. La sua giornata lavorativa media ha raggiunto una stima di 3,0 kilowattora.
Il giorno più intenso ha raggiunto una stima centrale di 11 kilowattora. Quel giorno, diversi agenti paralleli hanno lavorato a una vasta analisi geospaziale.
Queste cifre provengono da un singolo utente insolitamente intenso, non da un campione rappresentativo di tutti i clienti di Claude Code. Hausfather lavora con dati climatici complessi e si descrive come un utente più intensivo della maggior parte delle persone.
Tuttavia, l'esperimento individua un fallimento di misurazione che va oltre un singolo ricercatore. Un utente vede una sola istruzione mentre l'infrastruttura gestisce una serie ramificata di eventi computazionali.
Il cambiamento conta perché le aziende promuovono sempre più gli agenti come sostituti di flussi di lavoro completi. Se la promessa del prodotto riguarda il lavoro completato, anche la sua contabilizzazione delle risorse dovrebbe misurare il lavoro completato.
Perché gli agenti AI consumano più dei chatbot
Gli agenti moltiplicano la domanda energetica attraverso iterazioni, lavoro parallelo ed elaborazione ripetuta del contesto, non tramite una singola risposta straordinaria.
Uno scambio standard con un chatbot segue di solito un percorso semplice. L'utente invia del testo, il modello elabora il suo contesto e il sistema genera una risposta.
Un flusso di lavoro agentico aggiunge un ciclo di controllo. Il modello decide cosa fare, usa uno strumento, osserva il risultato, aggiorna il suo piano e avvia un altro passaggio di inferenza.
L'inferenza è il processo di esecuzione di un modello addestrato per produrre un risultato. Ogni passaggio di inferenza aggiuntivo richiede processori, memoria, rete e apparecchiature di supporto del data center.
Claude Code può cercare in un repository, leggere file, modificare codice, eseguire test, ispezionare errori e rivedere il proprio lavoro. Un compito difficile può comportare decine o centinaia di questi passaggi.
I subagenti paralleli aumentano ulteriormente il conteggio. Possono esplorare approcci separati contemporaneamente, migliorando la copertura mentre consumano capacità di calcolo nello stesso momento.
I log di Hausfather hanno rivelato che l'output visibile rappresentava solo circa lo 0,4% di tutti i token elaborati. Circa il 96% erano letture dalla cache.
Una cache memorizza il contesto del modello elaborato in precedenza, così che il sistema possa riutilizzarlo in modo più efficiente. Leggere il contesto memorizzato nella cache costa meno che elaborare input nuovi, ma consuma comunque risorse.
Il volume diventa importante perché un agente rivisita ripetutamente la propria cronologia di lavoro in crescita. Ogni risultato di uno strumento, estratto di file, istruzione e decisione precedente può rimanere parte delle chiamate successive al modello.
Questo crea un andamento cumulativo. Le sessioni più lunghe generano più contesto e i passaggi successivi potrebbero dover rileggere gran parte di quel contesto prima di produrre un'altra azione.
Hausfather ha ipotizzato che i token memorizzati nella cache consumassero il 10% dell'energia necessaria per un input nuovo. Ha inoltre calcolato scenari inferiori e superiori usando l'1% e il 25%.
Questa ampia fascia mostra perché la stima finale rimane incerta. I prezzi possono fornire indizi sull'uso delle risorse, ma un prezzo scontato per i token non è un contatore diretto dell'elettricità.
Hausfather ha testato tre metodi di stima pubblicati e ha ottenuto risultati compresi nel più ampio intervallo tra 70 e 330 kilowattora. La convergenza supporta la sua conclusione generale senza eliminare l'incertezza.
Il meccanismo chiave emerge anche nella più ampia ricerca sulle emissioni. Un framework di contabilizzazione del 2026 stima che un flusso di lavoro agentico che effettua da 5 a 50 chiamate a modelli di frontiera possa consumare da 50 a 500 wattora.
Lo stesso framework avverte che una singola interazione può sottostimare il calcolo sottostante di un ordine di grandezza o più. Questo avvertimento si applica direttamente agli agenti presentati tramite una semplice interfaccia di chat.
La gestione del contesto diventa quindi una decisione infrastrutturale, non soltanto una funzionalità di usabilità. I team possono ridurre l'elaborazione superflua limitando il contesto irrilevante e indirizzando il recupero delle informazioni verso quelle necessarie per ogni passaggio.
Una base di conoscenza ricercabile mantenuta con cura può aiutare gli ingegneri a recuperare materiale mirato invece di caricare ripetutamente ampie raccolte di documenti. Tuttavia, i risparmi effettivi dipendono dall'architettura dell'agente.
Anche l'instradamento dei modelli è importante. Un sistema può assegnare classificazione, estrazione e modifiche di routine a modelli più piccoli, riservando i modelli di frontiera al ragionamento difficile.
Questo approccio non elimina il costo energetico dell'agente. Allinea la quantità di calcolo al valore e alla difficoltà di ogni operazione.
L'AI efficiente incontra flussi di lavoro agentici in espansione
La tensione centrale è che ogni singola inferenza continua a diventare meno costosa, mentre i prodotti agentici consumano più inferenze per portare a termine ogni incarico.
Il dato di Google di 0,24 wattora offre una forte evidenza che l'ottimizzazione in produzione possa ridurre l'energia per risposta. L'azienda ha misurato un prompt testuale mediano di Gemini nell'intero stack di erogazione, anziché testare un acceleratore isolato.
Google ha inoltre riportato una riduzione di 33 volte dell'energia per prompt mediano nell'arco di un anno. Modifiche ai modelli, miglioramenti software, aggiornamenti hardware e ottimizzazione dell'erogazione hanno contribuito a questo calo.
Questo progresso conta. Le stime statiche basate su chip più vecchi o sistemi di laboratorio poco utilizzati possono sovrastimare in modo sostanziale l'elettricità richiesta da un moderno servizio di produzione.
Il batching consente all'infrastruttura di servire più richieste insieme. La cache evita di ripetere alcuni calcoli. Un utilizzo più elevato distribuisce il consumo delle apparecchiature inattive su un maggior numero di attività utili.
I processori specializzati eseguono inoltre più calcoli per ogni unità di elettricità. Hausfather ha citato stime che mostrano importanti guadagni nell'efficienza dell'hardware per il machine learning dal 2016.
Tuttavia, l'efficienza per operazione non riduce automaticamente il consumo totale. Un calcolo meno costoso può incoraggiare gli sviluppatori a usarne di più.
I prodotti agentici rendono visibile questo effetto di rimbalzo. Quando una chiamata al modello diventa più veloce e meno costosa, i progettisti possono aggiungere passaggi di pianificazione, cicli di verifica, uso di strumenti e agenti paralleli.
Queste aggiunte possono migliorare il risultato. Possono anche consumare il dividendo di efficienza prima che riduca la domanda totale di elettricità.
Si tratta di una versione dell'effetto Jevons, in cui una maggiore efficienza delle risorse può stimolare una domanda nuova sufficiente a compensare i risparmi attesi. L'AI non garantisce tale esito, ma gli incentivi attuali favoriscono più calcolo.
I fornitori di modelli competono sulla capacità di completare compiti, sulle prestazioni nel coding e sull'autonomia. Gli utenti in genere notano se l'agente risolve il problema, non quante chiamate nascoste siano state necessarie.
La analisi dell'utilizzo di Anthropic ha rilevato che il 77% dell'uso aziendale API proprietario campionato seguiva schemi orientati all'automazione. I compiti di coding e d'ufficio erano particolarmente presenti.
Quella ricerca non ha misurato il consumo di elettricità. Mostra però perché i carichi di lavoro agentici meritino attenzione: l'uso aziendale delle API enfatizza già l'esecuzione automatizzata anziché la conversazione isolata.
Gli incentivi economici rafforzano il modello. Anthropic ha riportato una debole sensibilità al prezzo tra i compiti aziendali del suo campione. I compiti più capaci e costosi apparivano più frequentemente di quelli più economici.
Se un agente di coding fa risparmiare diverse ore di lavoro qualificato, un'azienda può accettare un'inferenza sostanzialmente maggiore di quella richiesta da una risposta in chat. L'elettricità per prompt diventa allora meno utile dell'elettricità per problema risolto.
La stessa logica si applica all'analisi scientifica. Il giorno più intenso di Hausfather ha supportato un complesso progetto geospaziale, non una conversazione informale.
Il confronto corretto non è quindi sempre quello tra un agente e un chatbot. Può essere un flusso di lavoro assistito da un agente rispetto ai computer, ai viaggi, al lavoro umano o ai ritardi richiesti dal processo precedente.
Tuttavia, questo confronto più ampio richiede dati reali. I benefici di produttività non possono essere semplicemente presunti e i fornitori non dovrebbero usare potenziali vantaggi per evitare di divulgare il consumo di risorse.
L'efficienza e la crescita dei carichi di lavoro devono essere comunicate insieme. Un dato in calo per token può coesistere con una domanda di elettricità in aumento se l'elaborazione totale di token cresce più rapidamente.
Per questo la stima del consumo energetico di Claude Code funge da avvertimento, non da verdetto definitivo. Rivela quanto facilmente una buona narrazione sull'efficienza possa omettere l'espansione che avviene sopra il livello del modello.
Cosa non può dimostrare la stima su Claude Code
Il confronto di 600 volte è importante dal punto di vista della tendenza, ma non è una misurazione diretta del consumo di elettricità di Anthropic.
Hausfather disponeva di registri di attività insolitamente dettagliati. Registravano identificatori dei modelli, timestamp e categorie di token per singole risposte API.
Questi registri forniscono una solida documentazione dell'attività computazionale. Non rivelano l'effettiva potenza elettrica utilizzata dai server di Anthropic durante ciascuna richiesta.
La stima converte quindi i token in energia tramite metodologie pubblicate. Ogni metodo richiede ipotesi su hardware, utilizzo, batching, gestione della cache e overhead del data center.
Anthropic non ha pubblicato i dati energetici per token o per prompt necessari per sostituire tali ipotesi con misurazioni proprietarie. Anche le località e le fonti di elettricità che servono le sessioni restano riservate.
Il trattamento della cache crea un'altra importante incertezza. Un token memorizzato nella cache evita di ripetere parte del lavoro, ma il risparmio preciso dipende dal sistema di erogazione.
Il caso centrale di Hausfather considerava le letture dalla cache come consumatrici del 10 percento dell'energia dei nuovi input. Una relazione diversa modificherebbe sostanzialmente la stima totale.
Il campione rappresenta inoltre una sola persona nell'arco di otto settimane. Hausfather ha utilizzato numerosi subagenti per grandi attività analitiche, quindi la sua attività è molto distante dalla sessione di programmazione di un utente occasionale.
La sua sessione mediana coinvolgeva circa 10 milioni di token e oltre 100 chiamate. Altre stime pubblicate per le sessioni di Claude Code hanno utilizzato carichi di lavoro inferiori.
Sarebbe quindi fuorviante affermare che ogni prompt di Claude Code consuma 150 wattora. La conclusione corretta è più circoscritta: alcune sessioni agentiche avanzate consumano centinaia di volte più energia rispetto a semplici prompt di chat.
Il confronto con Gemini attraversa inoltre fornitori e tipi di carico di lavoro diversi. Il dato di Google riguarda il prompt testuale mediano su Gemini Apps, mentre la stima di Hausfather copre un'attività intensiva di Claude Code.
Questa differenza è il punto del confronto, ma limita ciò che il rapporto può dimostrare. Non mostra che Claude sia intrinsecamente meno efficiente di Gemini.
Solo test controllati su attività comparabili in entrambi i sistemi potrebbero supportare tale affermazione. Idealmente, i fornitori renderebbero pubbliche misurazioni basate su confini di sistema coerenti.
Il framework di Watershed illustra quanto tali confini influenzino i risultati. Ha rilevato che benchmark isolati possono sovrastimare l'elettricità dell'inferenza in produzione da quattro a 20 volte, perché non considerano batching e caching.
È possibile anche l'errore opposto. Comunicare solo la potenza attiva degli acceleratori può omettere server host, capacità inattiva, raffreddamento, rete e perdite di conversione dell'elettricità.
Le aziende dovrebbero divulgare sia le informazioni sui carichi di lavoro sia quelle sull'infrastruttura. Campi utili includerebbero token, classe di modello, tipo di acceleratore, overhead del data center, ipotesi di utilizzo e fonti regionali di elettricità.
La rendicontazione delle attività completate aggiungerebbe un altro livello essenziale. Un agente potrebbe consumare più energia per tentativo, richiedendo però meno nuovi tentativi umani o completando lavori che sistemi più semplici non riescono a portare a termine.
I tassi di successo contano perché anche le esecuzioni fallite degli agenti consumano elettricità. Un flusso di lavoro che si blocca ripetutamente può avere un pessimo risultato energetico per esito, anche quando ogni singola chiamata sembra efficiente.
Gli acquirenti aziendali dovrebbero chiedere ai fornitori come gestiscono nuovi tentativi, crescita del contesto, errori degli strumenti e instradamento dei modelli. Queste decisioni di progettazione incidono sia sui costi operativi sia sulla rendicontazione ambientale.
La posizione scettica non è che la stima di Hausfather debba essere ignorata. È che una stima trasparente mostra quante informazioni cruciali i fornitori continuino a non divulgare.
La pressione passa dagli utenti agli acquirenti di infrastrutture
Il problema energetico degli agenti sarà deciso più dagli acquisti, dall'architettura software e dalla fornitura di elettricità che dalla moderazione dei singoli prompt.
Hausfather ha annualizzato il suo carico di lavoro di otto settimane a circa 1,1 megawattora di elettricità per data center. Il suo intervallo andava da 0,4 a 2,2 megawattora.
Utilizzando le emissioni medie della rete elettrica statunitense, ha stimato circa 370 chilogrammi di emissioni annue di anidride carbonica equivalente. L'intervallo era compreso tra 150 e 730 chilogrammi.
Si tratta di un valore significativo per un singolo utente software, ma Hausfather non sostiene che il senso di colpa personale offra la soluzione principale. Gli utenti intensivi di agenti rappresentano ancora una porzione limitata della domanda totale di elettricità.
Il rischio maggiore deriva dalla scala. Un'azienda può implementare migliaia di agenti che operano continuamente in programmazione, assistenza clienti, finanza, ricerca e attività amministrative.
Ogni agente può generare una domanda modesta. Carichi di lavoro persistenti moltiplicati in molti reparti possono modificare i requisiti infrastrutturali.
Le previsioni sui data center mostrano già la portata della sfida circostante. L'aggiornamento 2025 del Lawrence Berkeley National Laboratory stima per i data center statunitensi un caso di riferimento al 2030 pari a 649 terawattora.
Questo caso di riferimento equivale all'11,8 percento del consumo totale di elettricità degli Stati Uniti. L'intervallo di incertezza composto del rapporto va da 521 a 843 terawattora.
La previsione copre tutta la domanda dei data center, non solo gli agenti AI. Tuttavia, i server AI e i loro tassi di utilizzo sono incertezze centrali nel modello.
Questo mette sotto pressione tre gruppi.
I fornitori cloud e di modelli devono divulgare informazioni sufficienti affinché i clienti possano confrontare i sistemi. Senza una rendicontazione coerente, l'efficienza diventa un'affermazione di marketing anziché una metrica di approvvigionamento.
Gli sviluppatori di applicazioni devono decidere quando l'autonomia giustifichi chiamate ripetute al modello. Un flusso di lavoro con cinque agenti dovrebbe superare una soglia di valore più elevata rispetto a una singola richiesta a un modello più piccolo.
Gli acquirenti aziendali devono misurare gli esiti. Hanno bisogno di costo, energia, latenza e tasso di successo associati a un'attività completata, non a un prompt medio.
Queste decisioni incidono anche sulla pianificazione della rete. I grandi data center richiedono generazione, trasmissione, sottostazioni, sistemi di raffreddamento e capacità stabile in grado di gestire la domanda di picco.
La localizzazione conta perché lo stesso carico di lavoro può produrre emissioni diverse in sistemi elettrici differenti. La generazione a basse emissioni riduce le emissioni anche quando il calcolo sottostante rimane costante.
La flessibilità del carico di lavoro può aiutare. Alcune attività di addestramento, valutazione e agenti in background possono essere spostate verso ore o regioni con elettricità più pulita o meno vincolata.
Le sessioni di programmazione interattiva offrono minore flessibilità perché gli utenti si aspettano risposte rapide. Tuttavia, la ricerca o i test non urgenti dei subagenti possono tollerare una pianificazione.
I modelli più piccoli offrono un'altra leva. Classificazione di routine, selezione dei file e controlli di sintassi non richiedono sempre il modello più grande disponibile.
Gli sviluppatori possono anche limitare le iterazioni, comprimere il contesto, riutilizzare risultati convalidati e interrompere prima i flussi di lavoro falliti. Questi controlli possono ridurre i costi migliorando al contempo la prevedibilità.
La migliore architettura non utilizzerà sempre la minor quantità di elettricità. Dovrebbe utilizzare il minor calcolo necessario per completare in modo affidabile l'attività di valore.
Questo standard collega le prestazioni ambientali alla disciplina ingegneristica. Nuovi tentativi inutili, contesti sovradimensionati e chiamate non necessarie a modelli frontier sono di solito anche problemi finanziari.
Tre segnali mostreranno se l'AI agentica può scalare responsabilmente
La prossima fase del dibattito sull'energia dell'AI dipende dalla divulgazione dei fornitori, dall'efficienza a livello di attività e dall'elettricità realizzata per i nuovi data center.
Il primo segnale è la rendicontazione energetica diretta da parte di Anthropic e di altri fornitori di modelli. I registri dei token non possono rispondere a domande che richiedono accesso all'hardware di produzione e ai dati di erogazione.
Una divulgazione utile dovrebbe distinguere tra chat semplice, ragionamento, programmazione e flussi di lavoro multi-agente. Dovrebbe coprire l'infrastruttura completa anziché un singolo processore.
Se i fornitori pubblicheranno misurazioni comparabili a livello di attività, la fiducia nelle stime energetiche degli agenti migliorerà. Il silenzio continuo rafforzerà le preoccupazioni secondo cui i clienti non possano valutare i sistemi che implementano.
Il secondo segnale è se l'energia per attività completata diminuisce, non soltanto l'energia per token. Chip e software di erogazione migliori continueranno a ridurre il costo delle singole operazioni.
Gli agenti potrebbero comunque consumare questi guadagni utilizzando contesti più lunghi e più chiamate. I fornitori dovrebbero comunicare il successo delle attività insieme a inferenza totale, nuovi tentativi e latenza.
Un valore in calo a livello di attività mostrerebbe che l'efficienza supera l'espansione dei flussi di lavoro. Un consumo in aumento per esiti simili suggerirebbe che l'autonomia aggiuntiva sta assorbendo i risparmi.
Il terzo segnale è il tipo di elettricità associata alla nuova capacità dei data center. L'efficienza non può determinare le emissioni senza conoscere la fonte di generazione.
Hausfather stima che l'esecuzione dello stesso carico di lavoro con una fornitura elettrica in gran parte pulita potrebbe ridurne le emissioni di circa il 90 percento. La riduzione esatta varia in base alla località e al metodo di approvvigionamento.
Nuova generazione rinnovabile, accumulo, energia nucleare, risorse geotermiche e trasmissione possono ridurre l'intensità di carbonio della domanda aggiuntiva. La generazione dedicata da combustibili fossili muove il sistema nella direzione opposta.
Questi segnali contano più delle discussioni sul fatto che un prompt AI assomigli a diversi secondi di televisione. Quel confronto descrive un'interazione ristretta che gli agenti stanno rapidamente lasciando alle spalle.
Una domanda migliore è se un agente abbia completato un lavoro che valga il suo intero costo computazionale. Rispondere richiede registri trasparenti, misurazioni dei fornitori e un monitoraggio onesto degli esiti.
Gli sviluppatori possono iniziare ora verificando conteggi delle chiamate, crescita del contesto, nuovi tentativi e selezione dei modelli. Gli acquirenti aziendali possono richiedere dati sulle risorse a livello di attività durante l'approvvigionamento, anziché accettare una singola media.
La stima del consumo energetico di Claude Code non risolve la questione se gli agenti offrano valore sufficiente. Stabilisce che la loro vera unità di consumo è il flusso di lavoro.
Man mano che gli agenti assumono incarichi più lunghi, gli utenti dovrebbero chiedersi cosa succede dopo aver premuto Invio. Quanti modelli vengono eseguiti, con quale frequenza rileggono il contesto e quali fonti di elettricità mantengono in movimento quel processo?
