Il costo per attività di Claude Opus 5.5 è inferiore, ma i prezzi dei token spiegano solo la metà

Anthropic ha ridotto del 20% le tariffe dei token di Claude Opus 5.5, ma il costo stimato per attività di Claude Opus 5.5 può diminuire di più. Le letture dalla cache costano il 60% in meno rispetto a Opus 5, modificando l'economia delle lunghe sessioni di Claude Code.

Claude Devs ha evidenziato la differenza attraverso un'analisi del costo per attività e un calcolatore interattivo pubblicati il 22 settembre 2026. L'analisi invita gli sviluppatori a misurare il lavoro completato, anziché confrontare tariffe token isolate.

Questa distinzione definisce il vero confronto tra Opus 5.5 e Opus 5. Un token meno costoso non garantisce una funzionalità, una migrazione o una sessione di debugging meno costosa. Turni, comportamento della cache, output di ragionamento, tentativi e impostazioni del modello determinano il risultato finale.

Cosa cambia nel costo per attività di Claude Opus 5.5

Anthropic ha ridotto ogni principale categoria di token, ma le letture dalla cache hanno ricevuto il taglio più marcato.

Le tariffe dei token di input e output sono entrambe inferiori del 20% rispetto agli equivalenti di Opus 5. Le letture dalla cache costano il 60% in meno, secondo l'annuncio del modello di Anthropic.

La differenza è importante perché Claude Code invia ripetutamente al modello il materiale delle conversazioni precedenti. Il materiale riutilizzato include spesso istruzioni, file sorgente, risultati degli strumenti e il lavoro completato finora.

Il prompt caching consente al servizio di riconoscere contenuti elaborati in precedenza. Una lettura dalla cache recupera quel contesto riutilizzabile a una tariffa inferiore rispetto alla sua elaborazione come nuovo input.

Anthropic afferma che le letture dalla cache rappresentano la maggior parte del volume di token in molti carichi di lavoro di programmazione e agentici. Questa affermazione descrive la composizione dei token, non necessariamente la voce di costo maggiore in ogni fattura.

L'output può comunque dominare il costo finale perché il ragionamento e il testo generato vengono fatturati come token di output. Una sessione con input modesto ma ragionamento esteso può beneficiare meno delle letture dalla cache più economiche.

L'analisi ufficiale del costo per attività separa questi effetti. Prima confronta i due modelli usando conteggi di token identici, isolando la variazione delle tariffe.

La sua sessione esemplificativa contiene un contesto memorizzato nella cache sostanziale, una parte di nuovo input e una quantità minore di output. Con queste ipotesi fisse, Opus 5.5 costa circa il 31% in meno di Opus 5.

Questo risultato si colloca tra le riduzioni principali. Supera il 20% perché la sessione beneficia delle letture dalla cache meno costose, ma resta sotto il 60% perché contano anche altre categorie di token.

Separatamente, Anthropic stima che i carichi di lavoro tipici costino circa il 40% in meno con le impostazioni predefinite. Questa stima più ampia include sia tariffe inferiori sia l'aspettativa dell'azienda che Opus 5.5 completi il lavoro in modo più efficiente.

Si tratta di affermazioni diverse. Le cifre del 20% e del 60% derivano direttamente dalle variazioni tariffarie pubblicate. L'esempio del 31% dipende da una composizione di token esemplificativa.

La riduzione stimata del 40% aggiunge ipotesi sul comportamento del modello. Gli sviluppatori non dovrebbero applicarla automaticamente a ogni repository, prompt o flusso di lavoro di programmazione.

Opus 5.5 è diventato disponibile il 22 settembre tramite l'API Claude e diverse importanti piattaforme cloud. Il modello è entrato anche in Claude Code e nei prodotti in abbonamento di Anthropic.

La sua panoramica del modello indica una finestra di contesto di un milione di token e un'impostazione predefinita di sforzo medio. Il ragionamento adattivo è sempre attivo.

Questi dettagli influenzano i costi oltre il nuovo listino. Un contesto disponibile più ampio può supportare sessioni più lunghe, mentre il ragionamento adattivo aggiunge output fatturabile in base alla difficoltà dell'attività.

Il risultato è un costo unitario inferiore abbinato a un totale dipendente dal carico di lavoro. La modifica delle tariffe crea l'opportunità, ma il percorso dell'agente attraverso un'attività decide quanta parte si concretizza.

Perché un'attività di Claude Code costa più del suo contesto finale

Claude Code paga per l'elaborazione ripetuta tra i turni, non solo per la conversazione visibile alla fine.

Un'attività di Claude Code funziona come un ciclo. Il modello legge il contesto, seleziona uno strumento, esamina il risultato, aggiorna il proprio ragionamento e ripete questi passaggi.

Ogni ciclo genera un'altra richiesta. Tale richiesta include gran parte della conversazione accumulata nei turni precedenti.

Si consideri una sessione che inizia con un contesto moderato e cresce mentre Claude legge file, esegue test e riceve output dal terminale. La dimensione del suo contesto finale non equivale al totale dell'input elaborato.

Se l'attività richiede molti turni, il modello incontra ripetutamente il materiale precedente. Il prompt caching rende queste letture ripetute meno costose, ma non le rende gratuite.

Questo meccanismo spiega perché due sessioni che terminano con modifiche di codice simili possono avere costi diversi. Un modello può individuare subito i file pertinenti e concludere dopo un breve ciclo di validazione.

Un altro può ispezionare il sottosistema sbagliato, tentare una correzione, incontrare un errore e ripercorrere i propri passi. La seconda sessione paga per più chiamate agli strumenti, più ragionamento e più contesto ripetuto.

Il numero di turni agisce quindi come un moltiplicatore di costo. Ogni turno superfluo comporta sia il suo nuovo contenuto sia la conversazione già accumulata.

L'esempio di Anthropic parte da un contesto che cresce di sei volte e prosegue per 40 turni. L'input totale elaborato diventa molto più grande della finestra di contesto finale.

Ridurre quell'esempio a 25 turni abbassa sostanzialmente l'input totale. Il risparmio deriva dall'evitare passaggi ripetuti sulla stessa conversazione in crescita.

Ecco perché un comando di test affidabile può ridurre il costo per attività di Claude Code. Il modello riceve un segnale diretto sul fatto che la modifica funzioni.

Senza quel segnale, potrebbe ispezionare più file o ragionare su diverse spiegazioni speculative. Una build, un test unitario o uno script di riproduzione possono abbreviare quella ricerca.

Il batching degli strumenti può produrre un effetto simile. Leggere più file correlati in un solo ciclo può evitare ulteriori richieste, sebbene il recupero indiscriminato possa gonfiare il contesto.

L'obiettivo utile non è il minor numero possibile di token. È il percorso affidabile più breve verso un risultato corretto e verificato.

Questa distinzione conta nel confronto tra Opus 5.5 e Opus 5. Un modello più recente può generare più ragionamento durante un turno ma richiedere meno turni complessivi.

Può accadere anche il contrario. Opus 5.5 utilizza sempre il ragionamento adattivo e Anthropic afferma che può ragionare di più allo stesso livello di sforzo dichiarato.

Uno sviluppatore che confronta soltanto l'output di una richiesta può non cogliere l'intero schema dell'attività. L'unità significativa include esplorazione, modifiche, test, correzioni e report finale.

I tentativi meritano particolare attenzione. Un'esecuzione a sforzo inferiore che fallisce e deve essere ripetuta può costare più di una singola esecuzione riuscita con un'impostazione più alta.

Lo stesso vale per il passaggio a modelli inferiori. Un modello più piccolo può risparmiare token durante una ricerca, ma un risultato errato può mandare l'agente principale su una deviazione costosa.

L'analisi di Anthropic inquadra la questione come costo per attività completata. Questa misura premia il completamento accurato e penalizza le false partenze, anche quando la tariffa dei token sottostante appare conveniente.

Per i team di ingegneria, la lezione è pratica. Contate l'intero ciclo, da una richiesta definita fino a un risultato verificato, non una singola risposta o un'istantanea del contesto.

Le letture dalla cache producono il maggiore ribaltamento dei prezzi

La riduzione più profonda di Opus 5.5 si applica alla categoria di token più usata dalle lunghe sessioni degli agenti.

Opus 5 addebitava le letture dalla cache a un decimo della propria tariffa standard di input. Opus 5.5 riduce tale rapporto a un ventesimo.

Combinato con la tariffa di input più bassa, ciò produce la riduzione del 60% delle letture dalla cache. Nuovo input e output ricevono la riduzione minore del 20%.

Una quota elevata di cache spinge quindi un'attività verso un risparmio maggiore. Una richiesta breve con poco contesto riutilizzato resta più vicina alla riduzione base della tariffa dei token.

Il calcolatore di Anthropic consente ai lettori di modificare l'input totale, la parte memorizzata nella cache, l'output, il volume giornaliero delle attività e un'ipotesi di efficienza. L'ultimo controllo rappresenta il minor numero di token usati da Opus 5.5.

Lasciare quell'ipotesi di efficienza a zero isola il prezzo. Qualsiasi riduzione aggiuntiva rappresenta un'ipotesi su come il comportamento del modello cambi l'attività.

Questa separazione è importante. Un listino è verificabile esternamente, mentre l'efficienza di un modello dipende dal repository e dal lavoro richiesto.

Le prestazioni della cache dipendono anche dal comportamento della sessione. Prefissi di prompt stabili e lavoro continuo aiutano il servizio a riutilizzare contenuti elaborati in precedenza.

Diverse azioni possono interrompere questo schema. Cambiare modello fa sì che la prima richiesta sul nuovo modello elabori la conversazione in una cache diversa.

Anche la modifica di alcune impostazioni tramite un provider cloud o un gateway può ridurre il riutilizzo. Collegare un nuovo server di strumenti durante una sessione può alterare la struttura del prompt.

Pause prolungate possono consentire al materiale memorizzato nella cache di scadere. L'effetto esatto dipende dalla durata della cache e dal modo in cui vengono instradate le richieste.

Le scritture nella cache aggiungono un'altra precisazione. Scrivere nuovo materiale nella cache costa più che leggerlo in seguito.

Il calcolatore esclude intenzionalmente le scritture nella cache dal confronto semplificato. Ciò rende lo strumento utile per comprendere le principali variabili, ma non un simulatore completo di fatture.

Il primo passaggio su un grande repository può quindi restare costoso. I risparmi si accumulano quando i turni successivi riutilizzano ciò che il modello ha già elaborato.

La compattazione introduce un altro compromesso. Sostituisce il materiale delle conversazioni più vecchie con un riepilogo più breve, riducendo il contesto rinviato nelle richieste successive.

Tuttavia, la compattazione crea anche un nuovo stato del prompt. La richiesta immediata deve elaborare quel riepilogo e parte del contesto dettagliato potrebbe dover essere recuperata di nuovo.

Cancellare una sessione tra attività non correlate può evitare che un vecchio contesto segua un lavoro che non ne ha più bisogno. Cancellare durante un'unica attività coerente può eliminare un contesto memorizzato nella cache utile.

Un cambio di modello crea un confine simile. Anthropic consiglia di cambiare in un punto naturale, quando il costo della ricostruzione del contesto ha meno probabilità di annullare il vantaggio del modello.

I subagenti complicano ulteriormente il conto. Ogni subagente possiede una finestra di contesto separata e restituisce un riepilogo alla conversazione principale.

Questa separazione può mantenere le ricerche voluminose nei file fuori dal contesto primario. Tuttavia, ogni subagente consuma comunque token ed eredita un modello, salvo diversa configurazione.

La riduzione della cache premia sessioni lunghe e coerenti, ma non rende ottimali le conversazioni infinite. Vecchie istruzioni e risultati di strumenti irrilevanti possono aumentare ogni richiesta successiva.

I team dovrebbero esaminare sia la quota di cache sia l'input totale. Un'alta percentuale di cache è utile, ma una conversazione sovradimensionata può comunque elaborare troppo materiale.

Una sessione ben gestita mantiene caldo il contesto riutilizzabile rimuovendo al contempo il lavoro non correlato. Questo equilibrio conta più nei flussi di lavoro agentici che nelle chat a risposta singola.

Opus 5.5 vs Opus 5 è un test del carico di lavoro

I risparmi stimati da Anthropic restano una proiezione del fornitore finché i team non li riproducono sulle proprie attività.

L'azienda afferma che Opus 5.5 richiede meno capacità di calcolo per essere servito e genera output oltre il 30% più velocemente rispetto a Opus 5. Riporta inoltre risultati più forti in diversi benchmark interni.

Questi risultati sostengono l'ipotesi di una migliore efficienza dei costi. Non stabiliscono una riduzione universale per le basi di codice in produzione.

I benchmark offrono confronti controllati, mentre i repository reali contengono test incompleti, dipendenze insolite, convenzioni interne e requisiti variabili. Questi fattori modificano il percorso di un agente.

La variabile più incerta è il numero di token necessario per completare un lavoro equivalente. Opus 5.5 può evitare false partenze, ma il ragionamento adattivo può aumentare l'output per alcuni prompt.

Il suo livello di effort predefinito è medium, mentre Opus 5 usava high. Un confronto che accetta entrambe le impostazioni predefinite cambia più della sola versione del modello.

La guida alla migrazione raccomanda esplicitamente di ricalibrare l’effort. Mantenere una vecchia impostazione può produrre risultati fuorvianti.

Il modello introduce inoltre modifiche comportamentali e di integrazione. Thinking non può essere disabilitato e diversi schemi di utilizzo degli strumenti richiedono aggiornamenti.

Le applicazioni che utilizzano una precedente interfaccia computer-use nella Claude API o in Google Cloud devono passare al set di strumenti più recente. Alcune configurazioni di scelta forzata degli strumenti ora restituiscono errori.

Il testo di avanzamento tra le chiamate agli strumenti può arrivare anche attraverso blocchi thinking. Un’interfaccia che non gestisce tali blocchi può sembrare silenziosa durante l’esecuzione.

Questi cambiamenti non sono semplici dettagli di migrazione. Richieste fallite, strumenti non funzionanti o indicatori di avanzamento mancanti possono generare nuovi tentativi e aumentare il costo operativo dell’adozione.

Un test corretto tra Opus 5.5 e Opus 5 dovrebbe quindi mantenere invariata l’attività, registrando al contempo le impostazioni. Entrambe le esecuzioni richiedono lo stesso stato del repository, criteri di accettazione e comando di convalida.

Gli sviluppatori dovrebbero testare elementi reali del backlog anziché prompt giocattolo. Una piccola modifica sintattica rivela poco sui cicli degli agenti, sul riutilizzo della cache o sul recupero da un approccio errato.

Tra i candidati utili figurano un bug con una riproduzione affidabile, una funzionalità che coinvolge più file o una migrazione con una suite di test definita.

Una sola esecuzione non basta. Lo stato del repository, la latenza degli strumenti e il comportamento non deterministico del modello possono modificare il percorso seguito per completare un’attività.

Tre o quattro attività abbinate forniscono un campione iniziale più credibile. I team più grandi dovrebbero raggruppare i risultati per tipologia di attività, invece di riportare un’unica media aggregata.

I team devono inoltre definire il successo in modo coerente. Un’esecuzione che produce codice plausibile ma non supera i test non dovrebbe essere conteggiata come un completamento più economico.

Il tempo di revisione umana rientra nell’analisi operativa, anche quando non compare nella ricevuta dei token. Una patch confusa può assorbire tempo tecnico dopo la fine della generazione.

Il report finale di Claude Code può aiutare i revisori a comprendere le esecuzioni più lunghe. Anthropic presenta report conclusivi più chiari come un’altra potenziale fonte di efficienza.

Il vantaggio è plausibile, ma dipende dal carico di lavoro. I team dovrebbero misurare se i revisori necessitano di meno prompt di follow-up o dedicano meno tempo a ricostruire le azioni dell’agente.

Le evidenze pubbliche indipendenti restano limitate, poiché Opus 5.5 è stato lanciato solo quattro giorni prima di questa analisi. Le prime segnalazioni degli utenti non possono ancora stabilire una media stabile a livello di settore.

La conclusione difendibile è più circoscritta. Opus 5.5 ha tariffe pubblicate inferiori e le attività ad alto utilizzo della cache ricevono un vantaggio strutturale maggiore.

Se la riduzione del costo dell’attività completata si avvicinerà alla stima di Anthropic dipende da turni, output, comportamento della cache, nuovi tentativi e qualità della migrazione.

Come misurare il costo delle tue attività in Claude Code

Il comando `/usage` trasforma l’affermazione sui prezzi in un test ripetibile basato sulle tue sessioni effettive.

Esegui /usage quando si conclude un’attività coerente. /cost offre la stessa visualizzazione all’interno di Claude Code.

Il blocco della sessione riporta input, output, input memorizzato nella cache e un costo stimato basato sulle tariffe di listino. Gli utenti in abbonamento dovrebbero considerare tale stima come un indicatore del lavoro svolto.

Non si tratta di un’ulteriore fattura di abbonamento. I limiti del piano e l’utilizzo dell’API fatturato a token rappresentano accordi di fatturazione diversi.

Inizia registrando il modello e l’impostazione dell’effort. Senza questi dettagli, le ricevute di due sessioni possono sembrare confrontabili pur rappresentando modalità operative diverse.

Poi registra la definizione dell’attività e il test di accettazione. Una condizione di completamento chiara evita che un’esecuzione si interrompa prima di un’altra.

Successivamente, esamina la quota di cache. Una sessione lunga dovrebbe in genere riutilizzare una parte consistente del proprio input.

Una quota di cache bassa può indicare pause, cambi di modello, cambi di effort o modifiche al prompt. Può anche riflettere un’attività naturalmente breve o frammentata.

Confronta l’input totale con il contesto massimo osservato. Se l’input totale è molte volte superiore, la sessione ha probabilmente utilizzato numerosi turni.

Questa differenza non rappresenta automaticamente uno spreco. Il lavoro di ingegneria in più fasi richiede naturalmente varie richieste, soprattutto quando i test rivelano nuove informazioni.

Tuttavia, l’ispezione ripetuta degli stessi file può identificare un ciclo evitabile. Esamina la trascrizione attorno a tali ripetizioni per individuare istruzioni mancanti o strumenti di convalida assenti.

L’output merita un controllo separato perché include il ragionamento interno. Un output elevato per una piccola modifica meccanica può indicare effort eccessivo o ragionamenti ripetuti.

Per un test abbinato, ripristina il repository allo stesso stato iniziale. Esegui l’attività con Opus 5 e poi con Opus 5.5, alternando l’ordine nei test successivi.

Registra turni, input nuovo, letture dalla cache, output, tempo trascorso, risultati dei test e correzioni umane necessarie. Questi campi spiegano il risultato meglio di un solo totale.

Usa il calcolatore solo dopo aver raccolto queste misurazioni. L’inserimento di quantità reali di token produce un utile confronto tra tariffe.

Mantieni il relativo controllo di efficienza a zero per il primo calcolo. Questo mostra come le variazioni delle tariffe pubblicate incidono sullo stesso carico di token.

Poi calcola la differenza osservata nei token dalle esecuzioni abbinate. Questa seconda visualizzazione combina i prezzi con il comportamento effettivo del modello.

Non presumere che tutte le attività future corrisponderanno a quel campione. Separa debugging, sviluppo di funzionalità, revisione del codice, ricerca nel repository ed esecuzioni non supervisionate degli agenti.

Anche l’effort dovrebbe essere testato per categoria di attività. Medium può adattarsi al lavoro quotidiano ben delimitato, mentre errori difficili possono giustificare high effort.

Low effort può essere adatto a modifiche deterministiche, ma solo quando la verifica rende gli errori economici da rilevare. Un tentativo a basso effort fallito indebolisce qualsiasi risparmio apparente.

I team che usano gateway necessitano di un controllo aggiuntivo. Il gateway deve preservare i campi relativi a prompt-caching e utilizzo, altrimenti i report interni possono rappresentare in modo errato l’economia della sessione.

La documentazione sui gateway di Anthropic descrive il tracciamento centralizzato dell’utilizzo, i budget e l’attribuzione delle richieste. Avverte inoltre che gateway obsoleti possono bloccare funzionalità più recenti.

Le organizzazioni più grandi possono utilizzare i report di utilizzo per aggregare i risultati per sviluppatore e modello. I totali per singolo utente restano insufficienti senza gli esiti delle attività.

Una metrica interna utile associa le attività completate al consumo di token. Un’altra tiene traccia dei nuovi tentativi dopo test falliti o rifiuti da parte dei revisori.

I team possono conservare brevi note sperimentali accanto alle decisioni ingegneristiche. Una base di conoscenza tecnica ricercabile può conservare prompt, impostazioni, esiti e risultati della migrazione.

Questa documentazione aiuta a distinguere i cambiamenti del modello dai cambiamenti di processo. Evita inoltre che ogni team ripeta lo stesso benchmark senza una metodologia condivisa.

L’obiettivo non è ottimizzare ogni sessione fino alla ricevuta più bassa possibile. È identificare impostazioni che producano codice accettato con costo e impegno di revisione prevedibili.

Tre segnali mostreranno se i risparmi reggono

Il prossimo test consiste nel verificare se tariffe inferiori si traducano in output stabile e verificato nel normale lavoro di ingegneria.

Il primo segnale sono i dati /usage abbinati provenienti da progetti reali. Riduzioni ripetute in debugging, sviluppo di funzionalità e revisione rafforzerebbero l’argomento del costo per attività.

Tali confronti dovrebbero pubblicare le categorie di token e i criteri di successo. Una percentuale in evidenza senza quota di cache, effort e nuovi tentativi non può spiegare cosa sia cambiato.

Il secondo segnale è la stabilità della cache durante le sessioni lunghe. I team dovrebbero verificare se Opus 5.5 mantiene un elevato riutilizzo della cache tra chiamate agli strumenti, compattazione e transizioni di modello.

Quote di cache costantemente basse indebolirebbero il vantaggio atteso. Suggerirebbero che la progettazione del flusso di lavoro o l’infrastruttura impedisce agli utenti di raggiungere la tariffa di cache favorevole.

Il terzo segnale è la frequenza dei nuovi tentativi dopo la migrazione. Opus 5.5 modifica le impostazioni predefinite dell’effort, il comportamento di thinking e diverse interfacce degli strumenti.

Meno cicli falliti sosterrebbero l’affermazione di Anthropic secondo cui il modello completa il lavoro in modo più efficiente. Più errori di integrazione potrebbero temporaneamente annullare i risparmi pubblicati.

Gli sviluppatori dovrebbero inoltre evitare di ridurre il confronto al solo Opus 5. Modelli Claude più piccoli possono restare più adatti alla ricerca, alla lettura dei log e ai riepiloghi economici.

La decisione rilevante riguarda la distribuzione dei carichi di lavoro. Opus 5.5 può fungere da modello principale per la programmazione supervisionata, mentre modelli più piccoli gestiscono il recupero di informazioni delimitato.

Le attività difficili e non supervisionate possono giustificare un modello più capace se evita fallimenti multipli. Il percorso di successo più economico può iniziare con un modello dal costo più elevato.

Il calcolatore di Anthropic migliora questa discussione rendendo visibili le variabili alla base della stima. Non determina il risultato per un team specifico.

Il costo per attività di Claude Opus 5.5 è inferiore a parità di utilizzo dei token, soprattutto quando le letture dalla cache dominano l’input. La riduzione esatta resta una questione empirica.

Scegli un elemento reale del backlog, definisci il relativo test di superamento ed eseguilo una volta su ciascun modello. Confronta /usage, turni, output, quota di cache e correzioni di revisione.

Ripeti il processo su varie tipologie di attività prima di modificare un’impostazione predefinita a livello di team. Se Opus 5.5 termina con meno nuovi tentativi, la riduzione della tariffa si moltiplica.

Se consuma più ragionamento o compromette un’integrazione, il risparmio in evidenza si ridurrà. Il prossimo mese di misurazioni abbinate in produzione conterà più di qualsiasi singola impostazione predefinita del calcolatore.