Claude Opus 5: costi, livelli di effort e quando usarlo

Claude Opus 5 è il modello premium di Anthropic per coding complesso, agenti e attività enterprise. È stato lanciato il 24 luglio 2026 con una promessa semplice: offrire gran parte delle capacità di Fable 5 al precedente prezzo di Opus.

Sul fronte del prezzo, il passaggio da Opus 4.8 è immediato. L’adozione in produzione richiede invece più attenzione. Il thinking ora è attivo per impostazione predefinita, l’effort determina quanto lavoro il modello dedica a testo e strumenti, e un vecchio limite di output può interrompere il task prima che il ragionamento sia terminato.

Claude Opus 5 è il modello premium quotidiano, non il limite assoluto

Opus 5 è adatto ai compiti difficili che ricorrono ogni giorno. Sonnet 5 resta preferibile quando contano soprattutto volume e latenza. Fable 5 va riservato ai task che hanno già fallito una valutazione con Opus e per i quali il costo dell’errore supera il sovrapprezzo di 2x per token.

È la stessa gerarchia con cui Anthropic presenta oggi la propria gamma. La sua guida aggiornata ai modelli consiglia agli sviluppatori indecisi di partire da Opus 5 per coding agentico complesso e attività enterprise, passando poi a Fable 5 quando serve la massima capacità disponibile.

Opus 5 dispone di una finestra di contesto da 1 milione di token e di un output sincrono massimo di 128,000 token. La finestra di contesto rappresenta il materiale che il modello può tenere presente in una singola richiesta, ma non garantisce che ogni token riceva la stessa attenzione. Il limite di output comprende sia il thinking nascosto sia la risposta visibile, un dettaglio decisivo durante la migrazione.

L’ID del modello è claude-opus-5. È disponibile tramite Claude API, Amazon Bedrock, Google Cloud e Microsoft Foundry. Nell’app Claude, Anthropic lo ha reso il modello predefinito per il piano Max e il più potente disponibile nel piano Pro.

Non è una classifica destinata a durare per sempre. È una politica di instradamento capace di sopravvivere anche al prossimo lancio, perché ogni cambio di modello dipende dai dati del carico di lavoro e non dalla fedeltà a una fascia di prodotto.

Il benchmark che conta è il costo per task riuscito

Il risultato davvero utile di Opus 5 nei benchmark non è una vittoria assoluta. È la capacità di arrivare spesso allo stesso esito accettato con un’esecuzione meno costosa.

Anthropic pubblica cinque risultati che orientano la scelta:

• Su Frontier-Bench v0.1, Opus 5 più che raddoppia le prestazioni di Opus 4.8 con un costo per task inferiore.
• Su CursorBench 3.2, Opus 5 con effort max chiude a meno dello 0.5% dal miglior risultato di Fable 5, dimezzando il costo per task.
• Su ARC-AGI 3, il suo punteggio è tre volte quello del secondo modello nella comparazione di Anthropic.
• Su Zapier AutomationBench, il tasso di superamento è circa 1.5 volte quello del secondo modello allo stesso costo per task. Anche al livello di effort più basso supera più task di qualsiasi altro modello incluso nel confronto.
• Su OSWorld 2.0, batte il miglior risultato di Fable 5 nell’uso del computer a poco più di un terzo del costo.

Sono risultati di lancio pubblicati dal produttore, non una classifica universale valida per ogni repository, documento di policy o workflow nel browser. Indicano che l’effort può trasformare token aggiuntivi in lavoro accettato. Non dicono quanti tentativi serviranno al proprio agente, con quale frequenza una persona respingerà la risposta o se, per l’obiettivo di servizio, sia meglio un risultato più rapido ma leggermente meno capace.

Il costo per task riuscito include proprio ciò che manca ai benchmark. Bisogna sommare il costo in token di ogni tentativo, gli addebiti per le chiamate agli strumenti, la latenza rilevante per il prodotto e la revisione umana. Il totale va poi diviso per gli output che rispettano il criterio di accettazione.

Per un agente di coding, riuscire può significare superare i test, mantenere la diff entro l’ambito previsto e ottenere l’approvazione del reviewer senza un giro di correzioni. Per un agente operativo, può voler dire aggiornare correttamente il record, richiedere l’autorizzazione appropriata e non compiere azioni non supportate. Prima di confrontare i livelli di effort, la rubrica deve descrivere l’esito atteso.

La metrica non è quanto il modello sembri intelligente. È il risultato accettato a un costo noto.

A carico fisso, il costo è $9, $22.50 o $45

A parità di distribuzione dei token, Opus 5 si colloca esattamente a metà strada tra il prezzo temporaneo di Sonnet 5 e quello di Fable 5.

Consideriamo 100 task. Ognuno invia 20,000 token in input e riceve 5,000 token in output. Il batch consuma 2 milioni di token in input e 500,000 token in output:

• Sonnet 5, con la tariffa introduttiva di $2 per l’input e $10 per l’output, costa $9.
• Opus 5, a $5 per l’input e $25 per l’output, costa $22.50.
• Fable 5, a $10 per l’input e $50 per l’output, costa $45.

Il calcolo usa i prezzi correnti delle API Anthropic. La tariffa di Sonnet 5 pari a $2/$10 resta valida fino al 31 agosto 2026; in seguito, il prezzo standard passa a $3/$15. Il calcolo esclude prompt caching, sconti batch, ricerca web, esecuzione di codice, nuovi tentativi e qualsiasi variazione nel consumo di token dovuta al modello o al livello di effort.

Su questa scala ridotta, Opus costa $13.50 in più di Sonnet, mentre Fable costa $22.50 in più di Opus. Per giustificare il sovrapprezzo rispetto a Sonnet sull’intero batch, a Opus basta evitare una correzione che valga più di $13.50. Per rendere conveniente il passaggio successivo, Fable deve prevenire più di $22.50 in errori o revisione.

Con 10,000 task della stessa forma, i totali diventano $900, $2,250 e $4,500. Opus supera ora Sonnet di $1,350, mentre Fable aggiunge altri $2,250. Una scelta di routing che sembra irrilevante in fase di prototipo diventa una voce di budget ai volumi di produzione.

Fast mode rende la distinzione ancora più evidente. Esegue Opus 5 circa 2.5 volte più velocemente a $10/$50, il doppio del prezzo normale. L’esempio da 100 task costerebbe $45, lo stesso totale base in token di Fable 5. Ha senso acquistarlo quando il tempo di risposta genera abbastanza valore per il prodotto da giustificare il sovrapprezzo, non come interruttore di velocità predefinito.

Il controllo dell’effort è una policy, non un budget di token

Il punto di partenza è high. È l’impostazione predefinita della Claude API e di Claude Code; Anthropic specifica inoltre che dichiarare high produce lo stesso comportamento dell’omissione del parametro effort.

L’effort controlla quanto lavoro Claude investe nell’intera risposta: testo visibile, thinking, chiamate agli strumenti e argomenti delle funzioni. Ridurlo può limitare l’uso di token e l’attività degli strumenti; aumentarlo può favorire un’esplorazione più profonda. Resta però un segnale comportamentale, non un tetto rigido: una richiesta difficile con effort low può comunque attivare il thinking.

I cinque livelli hanno funzioni diverse:

low è adatto a compiti economici e circoscritti. Si presta a classificazione, estrazione, trasformazioni semplici e task ristretti affidati a subagenti, con risultati facili da verificare. Un agente di triage che decide in quale coda inserire un ticket è un caso migliore rispetto a un agente incaricato di risolverlo.

medium è l’impostazione bilanciata per la produzione. È indicata per il lavoro ordinario assistito da strumenti, quando il percorso è noto ma l’input cambia: riassumere il record di un cliente, preparare una risposta standard o applicare una procedura operativa ben definita. È il primo passo sotto il valore predefinito quando contano costo dei token o latenza.

high è il valore predefinito per il lavoro quotidiano difficile. Va usato per modifiche al codice, analisi con molte sfumature e agenti a più passaggi, quando gli errori hanno un costo sufficiente a giustificare un ragionamento accurato. È il punto di misura iniziale corretto, perché permette di confrontare ogni impostazione superiore o inferiore.

xhigh è pensato per attività di lunga durata. Anthropic lo descrive come il livello per task agentici o di coding che possono protrarsi oltre 30 minuti, con budget di milioni di token. È adatto quando il modello deve esplorare più volte, usare molti strumenti o mantenere un piano durante un’esecuzione lunga.

max è un percorso eccezionale. Rimuove i vincoli sulla spesa di token per puntare alla massima capacità. Un task dovrebbe arrivare qui solo dopo un fallimento con xhigh, oppure quando il valore del risultato rende secondaria l’efficienza nell’uso dei token.

Due errori sono particolarmente comuni.

Primo: non bisogna usare l’effort per controllare la lunghezza del testo. La documentazione Anthropic chiarisce che modificare l’effort non accorcia in modo affidabile la risposta visibile di Opus 5. La lunghezza desiderata va indicata nel prompt.

Secondo: non conviene avviare ogni task apparentemente difficile con max. Così non si scoprirà mai se high sarebbe bastato e qualsiasi discussione successiva sui costi resterà ipotetica. Il confronto utile riguarda l’impostazione più bassa che raggiunge il risultato in modo affidabile, non il punteggio più alto che si può comprare.

Chi dovrebbe scegliere Opus 5, Sonnet 5 o Fable 5

Per la maggior parte degli acquirenti, usare lo stesso modello per ogni richiesta non è la scelta giusta. Serve invece un’opzione predefinita con un percorso di escalation ristretto.

Il founder finanziato che sviluppa un prodotto agentico

Sonnet 5 va usato per le interazioni ad alto volume facili da validare; Opus 5 per i passaggi che richiedono pianificazione, riconciliazione di contesti in conflitto o recupero dopo l’errore di uno strumento.

Il rischio per il founder è assegnare Opus a ogni turno perché sembra l’opzione più sicura. Se la maggior parte delle richieste segue un percorso prevedibile, il sovrapprezzo finanzia lavoro che non ne aveva bisogno. La corsia economica deve restare ampia, quella di Opus va riservata ai passaggi decisivi.

L’orchestrazione complessa può partire da Opus con effort high. Una classe notoriamente difficile dovrebbe salire a xhigh solo se il miglioramento nel tasso di accettazione copre il consumo aggiuntivo di token. Fable entra in gioco soltanto dopo il fallimento di Opus su un caso rappresentativo e quando l’impatto sul business giustifica il prezzo unitario di 2x.

Il CTO di un’azienda di medie dimensioni che standardizza il layer dei modelli

Opus 5 può diventare il modello premium predefinito, mentre il routing deve restare esplicito nelle policy. Il responsabile di un carico di lavoro deve poter spiegare perché un task usa Sonnet, Opus o Fable e quale valutazione farebbe cambiare la rotta.

Migrare ogni richiesta da Opus 4.8 cambiando una sola stringa del modello non basta. Il thinking predefinito modifica sia l’output sia il consumo di token. Vanno riesaminati le impostazioni max_tokens esistenti, il modo in cui sono progettate le conversazioni in cache e i prompt di verifica.

L’analisi di Claude Sonnet 5 costituisce il riferimento inferiore: Sonnet vince quando mantiene un output accettabile al prezzo corrente. Fable definisce il limite superiore. Opus occupa lo spazio intermedio finché uno dei due estremi non si dimostra migliore su un carico di lavoro specifico.

Il responsabile senior che automatizza le operazioni aziendali

Opus è indicato quando il lavoro attraversa sistemi o confini di policy. Leggere una richiesta, verificare un account, applicare una regola e decidere se occorre l’approvazione di una persona è più difficile che preparare un riepilogo, perché ogni passaggio cambia le conseguenze del successivo.

medium è adatto a una procedura stabile con strumenti circoscritti. Si passa a high quando eccezioni, record ambigui o testi di policy in conflitto sono frequenti. Le azioni irreversibili devono mantenere l’approvazione umana anche in presenza di benchmark solidi. Un modello migliore riduce la revisione ordinaria, ma non elimina la responsabilità.

Fable diventa sensato solo quando il task è insieme insolitamente difficile e insolitamente prezioso. Se una persona controllerà comunque ogni risultato, migliorare l’interfaccia di revisione potrebbe rendere più del sovrapprezzo del modello.

Lo sviluppatore tecnico indipendente

Durante i cambiamenti nella forma del prodotto, conviene partire da Sonnet 5. Debug complessi, revisioni architetturali e implementazioni che attraversano più file possono passare a Opus 5. La differenza conta soprattutto quando un tentativo fallito impone di ricostruire un contesto costoso, non per una modifica minima.

La scelta più ampia tra fornitori resta separata. GPT-5.6 e Claude Sonnet 5 differiscono anche nei sistemi di esecuzione, non soltanto nella qualità del modello. Opus 5 rafforza l’offerta premium di Anthropic, ma non rende intercambiabili orchestrazione, permessi degli strumenti o osservabilità.

Per tutti e quattro i profili, il punto di svolta è lo stesso: si sale di livello quando il costo misurato di errori e revisione supera il sovrapprezzo del modello. Se nessuno ha misurato quel costo, la scelta aziendale prudente è valutare prima di procedere con l’escalation.

La migrazione da Opus 4.8 introduce due cambiamenti incompatibili

Sostituire claude-opus-4-8 con claude-opus-5 mantiene invariato il prezzo unitario di $5/$25, ma non lo stesso comportamento in esecuzione.

Il primo cambiamento riguarda il thinking predefinito. Opus 4.8 poteva funzionare senza thinking, a meno che la richiesta non lo attivasse. Opus 5 decide per impostazione predefinita quando e quanto ragionare. Poiché max_tokens limita insieme thinking e risposta visibile, un valore che conteneva agevolmente l’output di Opus 4.8 può troncare un agente Opus 5 prima della conclusione.

Il secondo riguarda il rapporto tra thinking ed effort. Se una richiesta disattiva il thinking e imposta xhigh o max, l’API restituisce HTTP 400. Quando il thinking deve restare disattivato, l’effort va mantenuto a high o a un livello inferiore; in alternativa, ai livelli più alti va rimosso il campo che disabilita il thinking.

Anthropic avverte inoltre che, disattivando il thinking, Opus 5 può occasionalmente scrivere una chiamata a uno strumento nel testo normale o esporre tag XML interni invece di emettere un blocco tool_use corretto. Quando possibile, è preferibile lasciare attivo il thinking e controllare la spesa tramite l’effort.

Questa è una richiesta Python valida per un task prolungato di coding o per un agente:

import anthropic

client = anthropic.Anthropic()

response = client.messages.create(
    model="claude-opus-5",
    max_tokens=64000,
    output_config={"effort": "xhigh"},
    messages=[
        {
            "role": "user",
            "content": (
                "Review this repository migration plan. Identify unsafe "
                "assumptions, propose the smallest sound change, and verify "
                "the final plan against the stated acceptance criteria."
            ),
        }
    ],
)

for block in response.content:
    if block.type == "text":
        print(block.text)

Il limite di 64,000 token è il punto di partenza suggerito da Anthropic per xhigh o max, non un requisito per ogni richiesta. Dopo aver osservato l’uso effettivo e il comportamento al completamento, può essere ridotto.

Ci sono anche differenze qualitative da mettere in conto. Secondo Anthropic, Opus 5 tende a produrre elaborati più lunghi, descrivere più spesso i progressi durante le sessioni agentiche, delegare più facilmente ai subagenti e verificare il proprio lavoro senza istruzioni dedicate. Sono comportamenti potenzialmente utili, ma un’interfaccia per agenti, una pipeline di log o un layer di orchestrazione progettati per il comportamento più discreto di Opus 4.8 potrebbero richiedere modifiche.

Tre dettagli di produzione determinano il costo

Effort, caching e velocità interagiscono tra loro. Ottimizzarne uno isolatamente può peggiorare gli altri due.

Mantenere costante l’effort in una conversazione in cache

Cambiare output_config.effort tra una richiesta e l’altra modifica il prompt renderizzato da Anthropic, quindi la richiesta successiva non conserva il prefisso in cache. Un sistema che alza e abbassa l’effort nella stessa lunga conversazione rischia di perdere proprio il risparmio della cache su cui faceva affidamento.

Il livello di effort va scelto all’inizio di una sessione dipendente dalla cache e poi mantenuto. Se il lavoro successivo ne richiede uno diverso, può essere instradato in una nuova conversazione; altrimenti, il cache miss va incluso nel costo dell’escalation.

Con Opus 5, la lunghezza minima di un prompt memorizzabile in cache scende dai 1,024 token di Opus 4.8 a 512 token. Il caching diventa quindi accessibile anche a istruzioni ripetute più brevi, purché il prefisso del prompt e l’effort restino stabili.

Acquistare Fast mode per la latenza, non per la capacità

Fast mode è circa 2.5 volte più veloce della modalità normale e costa $10/$50 per milione di token. Non trasforma Opus in Fable. Nell’esempio a carico fisso da 100 task, porta il totale di Opus da $22.50 a $45 prima di caching o nuovi tentativi.

Fast mode è una research preview nella Claude API. Al momento non è disponibile su Amazon Bedrock, Google Cloud o Microsoft Foundry. Un’architettura multi-cloud non può presumere che l’impostazione di velocità accompagni il modello su ogni piattaforma.

Considerare beta i nuovi controlli beta

Le modifiche agli strumenti a metà conversazione consentono a un’applicazione di aggiungerli o rimuoverli tra un turno e l’altro, preservando la cache del prompt. La funzione usa l’header beta mid-conversation-tool-changes-2026-07-01.

I fallback automatici possono instradare una richiesta Opus 5 o Fable 5 segnalata da un classificatore verso un fallback consigliato da Anthropic, invece di bloccarla. Le liste di fallback predefinite ed esplicite usano l’header beta server-side-fallback-2026-07-01.

Entrambi i controlli risolvono problemi operativi, ma cambiano anche ciò che può fare una singola sessione logica e quale modello può rispondere. Prima di abilitarli in un workflow irreversibile vanno testati i cambiamenti dei permessi, la gestione degli errori e la qualità dell’output.

Eseguire un test sui cinque livelli di effort prima del rollout

Una valutazione da 375 esecuzioni basta a trasformare l’effort da opinione a dato di routing: 25 task rappresentativi, cinque livelli e tre ripetizioni per ogni combinazione.

Le ripetizioni contano perché un agente può riuscire una volta per fortuna e fallire al percorso successivo tra gli strumenti. L’insieme dei task conta più delle sue dimensioni: deve comprendere lavoro ordinario, casi limite noti ed errori che in precedenza hanno richiesto una correzione umana.

Se la produzione dipende dal prompt caching, durante il test non bisogna cambiare effort a metà sessione. Ogni livello va provato con una conversazione stabile, altrimenti i cache miss diventano una variabile incontrollata.

Un risultato utile potrebbe mostrare che medium supera il lavoro ordinario sugli account, high è necessario per gestire le eccezioni e xhigh migliora una classe ristretta di debug. Non sarebbe una giustificazione per usare xhigh ovunque, bensì per creare tre route con economie diverse.

Lo stesso processo stabilisce se Fable 5 merita il suo prezzo. Fable va aggiunto soltanto ai task che restano sotto soglia con Opus. Se non aumenta abbastanza l’accettazione da coprire il sovrapprezzo di $22.50 nell’esempio da 100 task, conviene mantenere Opus.

Il perimetro di sicurezza è diverso da quello di Fable 5

Opus 5 impone meno restrizioni di Fable 5 per il lavoro legittimo sulla sicurezza, ma non è un modello cyber senza limiti.

Anthropic dichiara che i suoi classificatori cyber per Opus 5 dovrebbero intervenire circa l’85% in meno rispetto a quelli di Fable 5. Il modello può individuare vulnerabilità nel codice sorgente, mentre le protezioni bloccano la scansione di vulnerabilità basata su file binari, i penetration test e la generazione di exploit. Inoltre, resta dietro Mythos 5 nella cybersicurezza offensiva e nella ricerca biologica.

Questo confine incide sugli agenti di debug e sicurezza. La revisione del sorgente può funzionare, mentre un successivo passaggio di validazione dell’exploit può essere rifiutato o instradato altrove. Il workflow deve trattare il rifiuto come uno stato gestito, non come un errore inatteso del parser.

Il Cyber Verification Program offre alle aziende e ai ricercatori idonei l’accesso a una versione con meno restrizioni di sicurezza. Gli utenti generici non dovrebbero progettare un workflow di produzione intorno a questa possibilità finché l’accesso non è confermato.

Nell’audit comportamentale interno di Anthropic, Opus 5 ottiene un punteggio di 2.3 per il comportamento disallineato complessivo, il più basso tra i modelli recenti dell’azienda. È un dato relativo alla suite di test di Anthropic, non un’autorizzazione a rimuovere approvazioni, sandboxing o accessi agli strumenti basati sul privilegio minimo.

La scelta finale

Claude Opus 5 dovrebbe sostituire Opus 4.8 nei nuovi carichi premium e nella maggior parte di quelli esistenti, dopo una migrazione graduale. Costa uguale, risponde in modo più affidabile all’aumento dell’effort e si avvicina a Fable 5 in diverse valutazioni importanti.

Non dovrebbe sostituire Sonnet 5 su ogni route ad alto volume, né trasformare max nel valore predefinito. Il vantaggio economico nasce dal routing: Sonnet o un effort più basso per il lavoro economico che supera i criteri, Opus high per le attività quotidiane difficili, xhigh per i casi di lunga durata misurati e Fable soltanto quando un fallimento di Opus si dimostra costoso.

Il controllo dell’effort è prezioso perché rende esplicita questa policy. Va trattato come variabile di valutazione, mantenuto stabile quando conta il caching e collegato, a ogni escalation, a un errore ben definito.

Vuoi trasformare anche il prossimo cambio di modello in una decisione concreta per la produzione? Iscriviti alla newsletter.