Claude Opus 4.8: novità, prezzi e cambio del modello

Documentazione di riferimento Ailoot: ailoot.ai/docs/.

Cosa è stato lanciato in Claude Code il 28 maggio#

Il 28 maggio Anthropic ha lanciato Opus 4.8, appena 41 giorni dopo Opus 4.7. Claude Code v2.1.154 e il post del blog “Introducing dynamic workflows in Claude Code” sono usciti lo stesso giorno. Il giorno seguente, la versione v2.1.156 ha corretto un bug relativo ai blocchi di ragionamento che causava errori API con Opus 4.8.

Quattro cambiamenti che riguardano chiunque programmi con Claude Code:

1. Il nuovo modello Opus 4.8 — stessi prezzi ($5/$25 per milione di token), ma benchmark migliori e una probabilità 4 volte inferiore di non rilevare bug nel proprio codice.
2. Dynamic Workflows — Claude scrive uno script JS che può avviare fino a 1000 subagenti nell’esecuzione, con non più di 16 attivi contemporaneamente. La parola workflow nel prompt funge da attivatore.
3. Livello di effort xhigh — un nuovo livello di ragionamento. Il valore predefinito di Opus 4.8 è ora high; per le attività impegnative si può passare a xhigh.
4. Fast Mode è diventato 3 volte meno costoso — prima costava 6× il prezzo standard; ora costa 2× ed è 2,5× più veloce.

Anthropic descrive questo rilascio con cautela:

In questa guida mostrerò esattamente cosa è cambiato, quanto costa nell’uso pratico e se conviene passare subito alla nuova versione o aspettare.

In cosa Opus 4.8 è diverso da 4.7?#

Cosa è migliorato nei numeri

Anthropic ha pubblicato i benchmark nell’annuncio ufficiale e nella documentazione Claude API. Ecco la tabella riepilogativa:

⚠️ Sono dati pubblicati dal fornitore: numeri di Anthropic, non misurazioni indipendenti.

La promessa principale: “4× meno probabilità di non rilevare i bug”

Anthropic sostiene:

Sembra ottimo, ma c’è una sfumatura da considerare: secondo il System Card di Anthropic, Claude Opus 4.8 ha avuto il tasso più basso di risposte errate tra sei modelli in ogni benchmark, perché si astiene quando è incerto.

Tradotto dal linguaggio del System Card a quello di chi fa vibe coding: il modello non è diventato 4 volte più intelligente. È diventato più propenso a dire “Non ne sono sicuro, controlla” invece di produrre un’allucinazione plausibile. Più onestà invece di un aumento del QI: ecco come si è evoluto.

In pratica, nelle stesse attività in cui Claude prima mentiva con sicurezza, ora dirà: “Non ne sono sicuro”. Questo riduce il rischio, ma non aumenta la copertura.

Cosa è rimasto invariato

• Prezzo standard ($5 per milione di token in ingresso, $25 per milione di token in uscita): invariato.
• Data limite delle conoscenze: gennaio 2026, come per 4.7.
• Contesto predefinito: 1 milione di token su Anthropic API, AWS Bedrock e GCP Vertex AI. Su Microsoft Foundry: 200K.
• Output massimo: 128K token.
• Parametri di campionamento (temperature, top_p, top_k): ancora non supportati; restituiscono un errore 400.

Dove Opus 4.8 è carente

A essere sinceri, in Terminal-Bench 2.1 Opus 4.8 ottiene il 74,6%: un risultato discreto, ma non è il migliore della categoria. Se svolgi la maggior parte del lavoro nel terminale, tienilo presente: Codex è spesso un po’ più forte nelle attività puramente da terminale. Opus 4.8 è avanti negli altri benchmark, ma questa differenza è reale.

Un secondo punto da dire chiaramente: nelle pipeline agentiche complesse con input non verificati (analisi di siti web, lettura di RSS), la protezione contro la prompt injection non è garantita in Opus 4.8. Se stai creando automazioni che leggono documenti di altre persone, mantieni un sanitizzatore separato per gli input.

Quanto costa Opus 4.8 nel 2026?#

Fasce di prezzo

Il prezzo standard è rimasto uguale a quello di 4.7 e 4.6. È raro: le nuove generazioni di solito costano di più. Fast Mode è diventato 3 volte meno costoso: con 4.6 e 4.7 la modalità veloce costava 6× il prezzo standard. Con 4.8 costa 2×.

Cosa significa per ogni ora di lavoro

Un’ora di programmazione attiva in Claude Code con Opus 4.8 corrisponde a circa 1–2 milioni di token in ingresso e 100–300 mila token in uscita. Ai prezzi standard, sono $5–10 per l’input e $2,5–7,5 per l’output. Arrotondando, si spendono $8–15 all’ora solo per l’API.

Con i piani in abbonamento:

• Pro ($20/mese) — sufficiente per 1–2 ore di lavoro attivo al giorno. Un singolo prompt impegnativo con Dynamic Workflow esaurisce il limite.
• Max 5x ($100/mese) — 4–6 ore al giorno in modo costante. Il punto ideale per la maggior parte di chi fa vibe coding.
• Max 20x ($200/mese) — un’intera giornata lavorativa senza preoccuparsi del limite. Ha senso se avvii molti workflow o lavori con Agent SDK.

Altri dettagli nelle guide come non esaurire i limiti di Claude Code e dove vanno a finire i token.

⚠️ Un dettaglio importante fornito da Anthropic: un workflow con 1000 agenti consuma “molti più token di una sessione tipica”. Un’esecuzione grande può consumare molta quota pur con non più di 16 agenti contemporanei. Prima dell’avvio controlla la capacità disponibile e imposta un budget: la sola concorrenza non determina il costo totale.

⚠️ Fast Mode non è incluso nei piani Pro / Max / Team / Enterprise. È necessario abilitare i crediti di utilizzo e viene addebitato separatamente a $10/$50 per milione di token, oltre all’abbonamento. Se hai Max e attivi Fast Mode senza crediti, riceverai un messaggio che ti chiede di ricaricare il saldo. Spesso questo dettaglio sfugge leggendo la documentazione.

Cosa sono i Dynamic Workflows in Claude Code?#

Differenze tra workflow, subagenti e skill

Prima, tutto ciò che Claude Code faceva autonomamente si basava su un’orchestrazione turno per turno. A ogni turno Claude decideva quale strumento chiamare e i risultati intermedi restavano nel suo contesto. Questo funziona con un massimo di 4–5 subagenti; oltre quel numero il contesto trabocca.

Dynamic Workflow cambia il modello. Claude scrive uno script JavaScript che orchestra direttamente gli agenti. I risultati intermedi restano nelle variabili dello script, non nel contesto di Claude. Solo il risultato finale torna nel contesto. Ci sono tre effetti:

1. Puoi avviare fino a 16 agenti in parallelo, fino a 1000 in totale per esecuzione.
2. Il contesto di Claude non trabocca: ogni subagente lavora nella propria sandbox.
3. Lo script è riutilizzabile: dopo un’esecuzione riuscita, premi s in /workflows per salvarlo come comando slash.

La documentazione Anthropic sui workflow lo spiega così:

Limiti di runtime

Tre modi per attivare un workflow

1. La parola workflow nel prompt. “Avvia un workflow per controllare tutti gli endpoint API in src/routes/ alla ricerca di controlli di autenticazione mancanti”. Claude riconosce il trigger, scrive uno script e lo avvia.
2. /effort ultracode — combina il ragionamento xhigh con l’orchestrazione automatica dei workflow. Si applica a tutte le attività sostanziali della sessione. La documentazione dice:

3. /deep-research [question] — workflow integrato per la ricerca con ricerca web e verifica incrociata delle fonti.

Esempio: Bun su 750.000 righe di Rust in 11 giorni

Il team di Bun ha usato Dynamic Workflows per un esperimento: portare Bun da Zig a Rust. Secondo il blog di Anthropic:

• Generati ~750.000 righe di Rust.
• 11 giorni dal primo commit al merge.
• Superato il 99,8% dei test della suite esistente.
• ~300 regole per tradurre Zig → Rust.

La procedura tecnica consisteva in tre workflow consecutivi:

1. Workflow #1 mappa il lifetime Rust corretto per ogni campo di ogni struct della codebase Zig.
2. Workflow #2 scrive ogni file .rs come port equivalente nel comportamento del corrispondente file .zig. Centinaia di attività sui file sono distribuite in gruppi, con al massimo 16 agenti concorrenti e due revisori per file.
3. Workflow #3 è un ciclo di correzione: esegue build e test finché tutto non passa.

La trappola principale: i workflow consumano il limite anche con attività piccole

Consiglio pratico: se un’attività può essere gestita con 1–2 semplici subagenti, non usare un workflow; avvia i subagenti manualmente. I workflow sono utili per oltre 50 file, non per 5.

Dynamic Workflow è il passo successivo nell’ingegneria del contesto. Un workflow può distribuire il lavoro fino a 1000 avvii totali, programmandone non più di 16 contemporanei. Senza contesto condiviso, gli errori possono accumularsi tra i gruppi perché ogni agente vede solo la propria parte.

Quando conviene abilitare l’effort xhigh?#

Nelle note di rilascio di Claude Code v2.1.154 Anthropic dichiara esplicitamente che Opus 4.8 usa effort=high per impostazione predefinita: è il nuovo standard dopo il rilascio. Prima lo standard era inferiore. Il nuovo livello xhigh è disponibile per le attività più impegnative, nelle quali il modello spende più token di ragionamento a ogni turno.

Quando usare xhigh:

• Migrazioni (nuovo modello architetturale → oltre 50 file).
• Audit di sicurezza (revisione della sicurezza di oltre 200 endpoint).
• Refactoring pianificati con controlli degli invarianti.
• Sessioni di debug complesse e lunghe, quando il modello deve ricordare l’intero percorso.

Quando NON usarlo:

• Modifiche di routine in un file (scrivere un test, rinominare un metodo).
• Prompt semplici e ben strutturati.
• Documentazione e commenti: xhigh costa di più per questi contenuti.

In Claude Code v2.1.154 il selettore di effort è stato rinominato da “Speed/Intelligence” a “Faster/Smarter”. Il valore predefinito /effort high ora viene applicato automaticamente; non devi impostarlo esplicitamente.

Quando conviene usare Fast Mode?#

Prezzi:

Quando usarlo:

• Attività interattive in cui la velocità della risposta conta più dell’accuratezza (revisione del codice in diretta durante una trasmissione).
• Modifiche rapide e verifica di ipotesi.
• Demo o presentazione a un cliente.

Quando NON usarlo:

• Attività agentiche di lunga durata: il prezzo 2× su un contesto da 1M peggiora l’economia.
• Un Dynamic Workflow ampio: Fast Mode raddoppia le tariffe applicabili e il consumo si accumula tra tutti gli agenti avviati. Il limite di 1000 avvii totali non è un moltiplicatore fisso di 1000× sul costo dell’attività: calcola il budget dal consumo aggregato effettivo di input e output.
• Sessioni in background in cui la velocità non è fondamentale.

Come passare a Opus 4.8 senza perdere le impostazioni?#

Passaggio 1. Aggiorna Claude Code

Nel terminale:

claude upgrade

Oppure reinstallalo seguendo la documentazione di Anthropic.

⚠️ La versione richiesta è v2.1.156 o successiva. v2.1.154 conteneva un bug: usando Opus 4.8, i blocchi di ragionamento venivano modificati e ciò causava errori API. Il bug è stato corretto in v2.1.156.

Controlla la versione:

claude --version

Passaggio 2. Cambia modello in /config

In Claude Code:

/model claude-opus-4-8

Oppure apri /config → sezione Model → seleziona Opus 4.8 dall’elenco. L’ID del modello sull’endpoint API è claude-opus-4-8.

Passaggio 3. Abilita Dynamic Workflows (piano Pro)

Dynamic Workflows è disabilitato per impostazione predefinita nel piano Pro. Apri /config → sezione Workflows → abilitali. Sono attivi fin dall’inizio nei piani Max, Team e Enterprise personale. In Enterprise con un amministratore potrebbero essere disabilitati dall’amministratore: chiedigli di abilitarli.

Passaggio 4. Esegui un test

In Claude Code, chiedi un’attività semplice con un risultato chiaro per verificare che il modello risponda correttamente:

Scrivi una funzione TypeScript che suddivida un array in blocchi di lunghezza fissa.
Dammi i test in vitest.

Se la risposta è adeguata e all’inizio compare la frase “using claude-opus-4-8”, il passaggio è riuscito. Se ricevi un errore 400, controlla la versione di Claude Code (torna al passaggio 1).

Cosa NON devi migrare

• CLAUDE.md funziona con qualsiasi modello senza modifiche. Altri dettagli nella guida come configurare CLAUDE.md.
• Skills vengono rilevati automaticamente da Opus 4.8. Altri dettagli nella guida Claude Code Skills.
• Server MCP funzionano allo stesso modo. La guida a MCP presenta 7 combinazioni pronte.
• Subagenti e Plan Mode non cambiano. Un riepilogo della scelta tra Skills, Subagents, MCP e Plugins si trova nella guida tematica.

Conviene passare da Sonnet 4.6 o Haiku 4.5?#

Ho già trattato la scelta tra Sonnet e Opus in una guida precedente, ma parlava di 4.7. Con Opus 4.8 le regole cambiano un po’.

Matrice decisionale per il 2026:

Per la maggior parte di chi fa vibe coding, la soluzione ideale è Sonnet 4.6 come modello predefinito, più Opus 4.8 per le attività impegnative tramite il selettore /model. Così spendi meno e gestisci comunque bene i compiti più impegnativi.

Cosa NON funziona in Opus 4.8?#

Secondo le testimonianze pratiche, Opus 4.8 è carente in tre aree:

1. Strategia basata sui dati e roadmap. Le esperienze pratiche indicano che per l’analisi è ancora preferibile 4.7. Se il tuo caso d’uso principale è creare una tabella di metriche e proporre una roadmap, prova prima 4.8; se non funziona, torna a 4.7 con /model claude-opus-4-7.

2. “L’ultimo 10%” nelle codebase esistenti. Il modello lavora molto bene su progetti greenfield (un progetto nuovo da zero), ma fatica quando deve far maturare codice esistente: casi limite e peculiarità specifiche dell’architettura. È una debolezza tipica dei modelli di ragionamento: generano bene, ma sono scarsi nel “rifinire” qualcosa che esiste già.

3. Le allucinazioni persistono. “4× meno probabilità di non rilevare bug” significa che il modello dice più spesso “non lo so”, ma quando il contesto è insufficiente può comunque produrre un’invenzione plausibile. La protezione è il contesto del progetto: più è completo CLAUDE.md, meno spazio resta alle allucinazioni.

Questo non significa “non aggiornare”. Significa comprendere i limiti e tenere Sonnet 4.6 e Opus 4.7 come alternative di riserva.

Cosa arriverà dopo Opus 4.8?#

Nel linguaggio di Anthropic, “nelle prossime settimane” di solito significa 4–8 settimane. In altre parole, è probabile che un modello della classe Mythos esca tra giugno e luglio 2026. Questo cambia la strategia:

• Se i tuoi progetti attuali usano Sonnet 4.6 o Opus 4.7 — passa a 4.8 e prova xhigh e i workflow su attività specifiche. L’aggiornamento non comporta un aumento di prezzo.
• Se avevi pianificato una migrazione ampia con un workflow — non avere fretta. Tra un mese o due potrebbe uscire un modello ancora più capace. Puoi iniziare con un esperimento su un singolo modulo per capire come funziona.
• Se volevi ricostruire l’infrastruttura attorno a Dynamic Workflows — aspetta. Mythos potrebbe cambiare i modelli di riferimento.

Il consiglio principale è tenere conto dell’incertezza e mantenere flessibilità. Opus 4.8 è un buon aggiornamento incrementale. Mythos potrebbe essere un salto in avanti. Non investire in una revisione importante un mese prima della possibile uscita di un nuovo modello.

Continua a esplorare Ailoot su ailoot.ai.