Claude 5.5: Smetti di pagare per i task falliti

La configurazione Sonnet e Opus che conta davvero: effort, cache, verifica e costo per task completato

Il modello più economico non è quello con il prezzo per token più basso

È quello che porta a termine il lavoro, supera i controlli e non ti costringe a pagare cinque volte lo stesso contesto

Con Sonnet 5.5 e Opus 5.5 questa distinzione diventa cruciale. Uno ha un prezzo pensato per i volumi. L'altro per i lavori più complessi. Entrambi hanno un nuovo comportamento legato all'effort e, all'interno di un loop di agenti ben ottimizzato con la cache, possono rivelarsi sorprendentemente economici

Copia la tua vecchia configurazione su uno dei due modelli e potresti ritrovarti con un risultato più lento, più costoso o con un errore 400

Ecco invece la configurazione che costruirei io

1TASK → SONNET 5.5 → CONTROLLO → OPUS 5.5 SE NECESSARIO → RISULTATO VERIFICATO
2             ↘ effort ↗         ↘ cache + registro utilizzi ↗

Pubblico analisi pratiche su agenti AI, workflow e sistemi in produzione su Substack

Iscriviti alla newsletter qui

Il numero che dovrebbe decidere il tuo stack

Quasi tutti i confronti tra modelli partono dai dollari per milione di token

Il tuo agente non rilascia token. Rilascia task completati

https://x.com/claudeai/status/2102435511222890900

Ripeto: i loro test. La tua architettura ha bisogno dei tuoi numeri

Questo significa che il controllo non può essere un generico "pollice in su" dopo aver letto una risposta convincente. Per il codice, usa il test che bloccherebbe il merge. Per l'estrazione dati, confronta i campi richiesti con un set etichettato. Per la ricerca, verifica se la fonte citata supporta effettivamente ogni affermazione. Includi nel calcolo anche il costo dei task che non vengono mai superati, non solo gli esempi perfetti della tua demo

E analizza separatamente la coda difficile. Se l'impostazione più economica gestisce il 90% delle tue richieste ma brucia metà del budget sul restante 10%, la sua media potrebbe nascondere proprio quella parte del workflow che richiede un modello diverso

Cosa dice davvero il listino prezzi della 5.5

Al 3 ottobre 2026, alle tariffe standard delle API Claude, per milione di token:

1SONNET 5.5
2Input nuovo  $2       Output  $10
3Lettura cache   $0.20    Scrittura cache  $2.50 / 5m, $4 / 1h
4
5OPUS 5.5
6Input nuovo  $4       Output  $20
7Lettura cache   $0.20    Scrittura cache  $5 / 5m, $8 / 1h

Entrambi i modelli hanno una finestra di contesto da 1M di token e un output massimo di 128K token. Questi sono limiti massimi, non un invito a riempirli.

Specifiche e prezzi dei modelli

La riga anomala è quella della lettura della cache

Opus costa il doppio per input e output nuovi, ma un prefisso in cache costa gli stessi $0.20 per milione su entrambi i modelli. Questo non rende un'esecuzione su Opus altrettanto economica: si paga comunque di più per i nuovi input, gli output e le scritture in cache. Significa però che il divario di prezzo tra i modelli può ridursi in una sessione con molte letture

C'è una seconda differenza che molti trascurano. Il "40% in meno rispetto a Opus 5" dichiarato da Anthropic è una stima del tipico \costo di esecuzione\. I prezzi dei token nuovi di Opus 5.5 sono scesi del 20%; il prezzo di lettura della cache è sceso del 60%. Questi numeri sono correlati, ma non intercambiabili

L'effort è una decisione di routing, non un cursore della qualità

Sonnet 5.5 supporta low, medium, high, xhigh e max. Sulle API il valore predefinito è high; nelle app Claude, Anthropic indica medium come predefinito. Opus 5.5 usa medium come predefinito sulle API. Questi livelli non sono calibrati per significare esattamente ciò che le stesse parole indicavano nei modelli precedenti.

La mia mappa di partenza:

• Sonnet low Per richieste mirate e sensibili alla latenza, con un controllo economico
• Sonnet medium Per sviluppo di codice ben specificato e lavori multi-step di routine
• Sonnet high Quando l'esecuzione medium fallisce un controllo reale, o il task presenta un pattern di complessità dimostrato
• Opus medium Per lavori ambigui, cross-file e a lungo raggio, dove Sonnet spreca turni girando intorno al problema
• Xhigh/max Solo se le tue valutazioni mostrano un vantaggio che giustifica tempo e token extra

Questa è un'ipotesi di partenza, non una gerarchia universale. Nei risultati FrontierCode riportati da Anthropic per Sonnet 5.5, xhigh ha ottenuto un punteggio superiore a max. Più effort non è la garanzia di un risultato migliore

La nota a piè di pagina di Anthropic spiega questo risultato controintuitivo: con max, il modello avviava più spesso operazioni aggiuntive di code review. In due casi esaminati, questo ha portato a un timeout o a modifiche fuori dallo scope del task.

Il punto debole non era "il modello non ha ragionato abbastanza". Era lo sforzo sprecato nel posto sbagliato. Se il tuo agente supera già i suoi controlli, i turni di revisione extra possono diventare un costo e una fonte di nuovi errori

https://x.com/edwinarbus/status/2104675431853248816

Inoltre, non impostare max_tokens su un valore basso pensando di aver ottimizzato tutto. Il limite copre sia il ragionamento sia l'output visibile. Se lo interrompi a metà task, invece di risparmiare potresti ritrovarti con una risposta troncata e una seconda esecuzione

https://x.com/claudeai/status/2104633115620823187

È un'affermazione di lancio molto convincente. Ma una configurazione in produzione deve comunque battere il tuo baseline

Fai un piccolo sweep prima di inventarti un model router

Prendi 10-30 task che ti interessano davvero. Includi lavori semplici, lavori ambigui e quegli errori fastidiosi che trovi nei log. Assegna a ogni task un verificatore: test, un confronto strutturato, una risposta nota o una griglia di valutazione umana definita prima dell'esecuzione

Ecco il probe API più semplice e utile. Logga i campi di utilizzo che ti servono. Eseguilo su ogni modello e livello di effort contro lo stesso task, poi aggiungi il tuo controllo pass/fail. Non è un benchmark completo per agenti

1import anthropic
2
3client = anthropic.Anthropic()
4response = client.messages.create(
5    model="claude-sonnet-5-5",  # ripeti con claude-opus-5-5
6    max_tokens=8192,
7    output_config={"effort": "medium"},  # ripeti con high
8    messages=[{"role": "user", "content": "Sostituisci questo testo con un task reale."}],
9)
10
11answer = "".join(b.text for b in response.content if b.type == "text")
12usage = response.usage
13print(answer)
14print("nuovi", usage.input_tokens, "output", usage.output_tokens)
15print("lettura cache", usage.cache_read_input_tokens)
16print("scrittura cache", usage.cache_creation_input_tokens)

Questo presuppone il pacchetto Python ufficiale di Anthropic e una variabile d'ambiente ANTHROPIC_API_KEY. È una singola chiamata isolata senza cache attiva, quindi ci si aspetta zero letture e scritture in cache. La prossima sezione mostra cosa cambia le cose

Per un agente reale, somma l'utilizzo di tutte le chiamate API sotto un singolo ID task, inclusi tentativi e chiamate agli strumenti. Conta un successo solo quando il verificatore conferma che il lavoro è finito

Confronta il costo totale in dollari per ogni successo prima di scegliere il tuo default

Mantieni il test onesto:

• Blocca il set di task e il verificatore prima di confrontare le configurazioni
• Usa gli stessi strumenti, permessi, contesto e requisiti di output per ogni candidato
• Registra il tasso di successo, la spesa totale, il costo per successo, la latenza e i fallimenti più lunghi o costosi
• Considera stop_reason: "max_tokens" come un tentativo incompleto, non come un successo a basso costo

Il breve esempio di codice sopra usa un limite di output di 8K per un probe a turno singolo. Non copiare quel limite in un agente di coding a lungo raggio.

Anthropic raccomanda molto più margine per il lavoro agentico, perché il ragionamento nascosto rientra nello stesso limite.

Imposta il limite in base al lavoro, poi controlla la spesa tramite effort, cache e un budget per task, invece di forzare l'interruzione della risposta a metà opera

Metti in cache la parte stabile del lavoro

Gli agenti inviano ripetutamente le stesse istruzioni di sistema, definizioni degli strumenti, mappe del repository e conversazioni precedenti. Se quel prefisso è stabile, il prompt caching cambia le regole del gioco molto più di una piccola riscrittura del prompt

Ad esempio, 200K token in cache letti 50 volte equivalgono a 10M di token letti dalla cache. A $0.20 per milione, le letture costano $2 su qualsiasi modello 5.5.

Su Opus 5.5, inviare quegli stessi 10M di token come input nuovo costerebbe $40. La prima scrittura in cache di cinque minuti per 200K token aggiunge un altro dollaro.

Questa è un'illustrazione dei soli costi del prefisso: input nuovi, output, altre scritture, scadenza del TTL e mancati hit effettivi della cache si aggiungono al conto

Le regole pratiche:

• Sulle API Claude, attiva il prompt caching con cache_control={"type": "ephemeral"} al livello superiore o con breakpoint di cache espliciti. Il probe precedente non fa nessuna delle due cose, quindi i suoi contatori della cache rimarranno normalmente a zero
• Inserisci le istruzioni e gli strumenti stabili prima della richiesta utente variabile
• Mantieni il prefisso condiviso identico tra i turni; verifica i cache_read_input_tokens effettivi
• Tratta il cambio di modello come un nuovo budget di conversazione, non come una continuazione gratuita. La cache è specifica per modello: una richiesta Opus non può leggere il prefisso appena messo in cache da Sonnet
• Evita di cambiare l'effort di primo livello a ogni turno; questo modifica il prompt renderizzato e invalida i prefissi in cache

Sui modelli supportati, una modifica dell'effort per singolo messaggio può preservare la cache precedente, ma richiede l'header beta di Anthropic e non equivale a modificare l'output_config di primo livello.

Sonnet 5.5 ha anche una limitazione between_tools: in quella modalità l'effort non può cambiare a metà conversazione.

Documentazione sul prompt caching

Non dedurre un hit della cache da una risposta veloce. Leggi l'oggetto usage. Separa input nuovi, creazione della cache e letture della cache

Entrambi i modelli 5.5 richiedono almeno 512 token in un prefisso memorizzabile nella cache. Un system prompt minuscolo non produrrà i risparmi dell'esempio precedente. La durata predefinita della cache è di cinque minuti, perfetta per un loop di strumenti rapido.

Una scrittura da un'ora costa di più e ha senso solo quando le sessioni reali si mettono spesso in pausa abbastanza a lungo da superare la finestra di cinque minuti. Misura queste pause prima di pagare per un TTL più lungo

Fai escalation basandoti sui dati, non sull'ansia

La maggior parte dei team costruisce il router al contrario: classifica un task come "difficile", lo invia al modello costoso e non scopre mai se il percorso più economico avrebbe funzionato

Usa il verificatore come segnale di routing

11  Sonnet 5.5 · effort scelto  → esegui il task
22  Verificatore                    → accetta se supera il controllo
33  Opus 5.5 · medium           → ritenta solo con prove del fallimento
44  Verificatore                    → accetta o passa la mano allegando le prove

Il controllo può essere una suite di test, la validazione di uno schema, una risposta nota o un revisore. Dovrebbe spiegare cosa ha fallito.

"La risposta mi sembra debole" è un pessimo segnale di escalation; "l'endpoint modificato fallisce due test di integrazione" è utile

Non ripetere ciecamente un prompt identico. Fornisci al tentativo successivo il controllo fallito, gli artefatti rilevanti e un'istruzione specifica per colmare la lacuna. Metti un tetto alla scala, così un agente non potrà bruciare il suo budget cercando di risolvere un task che richiede una decisione umana

Puoi testare un retry con Sonnet high nel tuo sweep offline. Mantienilo nel percorso live solo se abbassa il costo per task verificato. Non c'è motivo di far pagare a ogni fallimento due esecuzioni Sonnet prima di passare a Opus

Il cambio di modello stesso può interrompere un prefisso in cache. Tienilo presente quando confronti il percorso di recupero con una strategia Opus-first

Il punto di pareggio è facile da trascurare. Supponiamo che un tentativo con Sonnet costi $0.06 e superi l'80% dei tuoi task.

Se ogni task fallito costa poi $0.20 per essere completato su Opus, la tua media esemplificativa è di $0.10 per task completato: $0.06 più un recupero da $0.20 su un task ogni cinque. Meglio che pagare $0.20 per Opus su ogni task. Ma se Sonnet costa $0.14 e ne supera solo la metà, la stessa scala costa $0.24, ancora prima di calcolare il prezzo del cambio modello. Con quel carico di lavoro, Opus-first è più economico e veloce

Queste cifre sono esempi, non risultati misurati su Claude. Servono a rendere falsificabile la regola di routing. La scala si giustifica solo se le chiamate Opus risparmiate superano i tentativi Sonnet falliti, i mancati hit della cache e la latenza aggiunta

Esiste anche una via di mezzo: lo strumento beta advisor tool di Anthropic. Sonnet può continuare a eseguire il task e chiedere aiuto a Opus per una decisione difficile, invece di affidargli l'intero lavoro.

Questo non è automaticamente più economico. Traccia quante volte Sonnet consulta effettivamente l'advisor, quanto costano quelle chiamate e se migliorano il tasso di successo finale. Se l'esecutore chiede raramente aiuto, l'advisor è solo una funzione inutilizzata.

Con questi modelli 5.5, il consiglio stesso viene restituito criptato al client, quindi valuta il lavoro risultante invece di illuderti di poter controllare il testo privato del consiglio

Quattro falle che fanno lievitare il conto prima ancora che la scelta del modello conti

Non ogni problema di costi richiede un nuovo router

Controlla prima questi aspetti:

• Output che continua a crescere Su entrambi i modelli 5.5, i token di output costano cinque volte i token di input nuovi. In una conversazione, una risposta lunga può tornare come contesto nei turni successivi. Chiedi l'artefatto e una breve nota di completamento, non la trascrizione commentata di ogni passaggio. Anche il ragionamento nascosto viene fatturato come output, quindi una risposta finale sintetica da sola non risolverà un problema di effort. Non eliminare le prove che ti servono per verificare il risultato
• Immagini più grandi del necessarioSonnet 5.5 può elaborare immagini a risoluzione più alta rispetto alle versioni precedenti di Sonnet, il che può aumentare il conteggio dei token immagine. Se all'agente serve solo l'etichetta di un pulsante o un paragrafo, ritaglia o ridimensiona prima. Se ha bisogno di un grafico denso o di piccoli dettagli dell'interfaccia, mantieni la risoluzione e misura il costo invece di ridurla ciecamente
• Contesto che nessuno usaDefinizioni degli strumenti, log obsoleti, vecchi risultati di ricerca e un CLAUDE.md dispersivo possono accompagnare ogni richiesta. Inserisci le regole permanenti in un breve prefisso stabile; mantieni le prove temporanee vicino al task che le richiede. Ridurre il contesto non deve cancellare i fatti che servono al modello per completare correttamente il lavoro
• Tariffe interattive per lavori che nessuno sta aspettandoL'API Message Batches offre uno sconto del 50% su input e output per entrambi i modelli. È utile per valutazioni offline, backfill di documenti e altri job asincroni. Non sostituisce un loop di strumenti live in cui qualcuno ha subito bisogno del passaggio successivo

Il principio è lo stesso per tutti e quattro: elimina il lavoro inutile per il task prima di comprare più intelligenza o di abbassare l'effort fino a compromettere la qualità

Le trappole di migrazione che trasformano un risparmio in un errore 400

I vecchi corpi delle richieste sono un pessimo punto di partenza per la famiglia 5.5.

In particolare:

• Il thinking di Opus 5.5 è sempre attivo Rimuovi thinking: {"type": "disabled"} e le vecchie impostazioni fisse di budget_tokens; controlla la profondità con output_config.effort
• La scelta forzata dello strumento fallisce su entrambi i modelli 5.5

I valori any e tool di tool_choice restituiscono un 400. Usa auto, specifica quando lo strumento dovrebbe essere utilizzato e valida il risultato nel tuo codice

• I blocchi di thinking non sono blocchi di testo Leggi il contenuto per type, non per content [0]. Nei loop degli strumenti, restituisci i blocchi di thinking invariati con il turno dell'assistente
• La tua UI potrebbe sembrare muta Su Opus 5.5, i progressi tra un tool e l'altro possono arrivare in blocchi di thinking vuoti con le impostazioni di visualizzazione predefinite. Se prima mostravi quelle note agli utenti, richiedi una modalità di visualizzazione del thinking supportata e renderizza i blocchi per type. Altrimenti l'agente potrebbe lavorare mentre l'interfaccia sembra bloccata
• Le vecchie versioni del computer-use tool possono fallire Controlla la versione attuale dello strumento prima di migrare un agente browser/computer
• Un limite max_tokens più basso può interrompere il lavoro

Il thinking viene conteggiato anche quando il testo è nascosto

Questi sono cambiamenti nel comportamento delle API, non trucchi di prompt engineering.

Guida alla migrazione di Opus e guida alla migrazione di Sonnet

Definisci il contratto in Claude Code, non nella tua testa

Le API sono il luogo in cui puoi misurare ogni campo di utilizzo. Claude Code è dove molte persone percepiranno per prime il cambiamento del modello. Vale lo stesso principio: dai all'agente una definizione limitata di "completato", poi fagli mostrare le prove

In Claude Code, /model seleziona il modello e /effort seleziona il livello di effort supportato. Controlla le impostazioni attive prima di confrontare le sessioni. Il default delle API Sonnet non descrive in modo affidabile ciò che la tua app Claude o la tua sessione Claude Code sta effettivamente utilizzando

Ecco un blocco iniziale completo e riutilizzabile per CLAUDE.md. Modifica i comandi per adattarli al tuo progetto

1# Contratto di lavoro
2
3Apporta solo la modifica richiesta. Preserva il lavoro non correlato.
4Esegui i test pertinenti dopo la modifica. Segnala qualsiasi controllo che non riesci a eseguire.
5Fermati quando il lavoro richiesto supera i controlli. Non aggiungere funzionalità extra o loop di revisione.
6Termina con: Modificato / Verificato / Rischio residuo.
7Chiedi prima di compiere azioni distruttive, pubblicare o apportare modifiche esterne a questo repository.

Quel blocco non renderà magicamente economica ogni esecuzione. Renderà visibili successi e fallimenti. Da lì potrai confrontare un workflow Sonnet-first con uno Opus-first sugli stessi task

Il messaggio del task deve comunque essere specifico. Ecco la differenza tra "sistema il codice dei pagamenti" e un lavoro che un agente può davvero portare a termine

1Modifica: migra l'endpoint di pagamento al nuovo client
2Completato: vecchio client rimosso, test dell'endpoint superati, diff limitato a questo percorso
3Stop: chiedi prima di eliminare dati o modificare qualcosa fuori dal repo
4Report: file modificati, controlli esatti eseguiti, rischio residuo

Questo piccolo contratto offre al verificatore qualcosa di concreto da ispezionare. Dà anche al modello un motivo per fermarsi. Un'istruzione aperta come "revisiona finché non è perfetto" può trasformare una modifica valida in un altro loop a pagamento

Per i progetti lunghi, conserva la checklist in un file che sopravviva alla compattazione. Per i subagenti, chiedi all'agente principale di ispezionare le loro prove prima di accettarne i report. E se hai chiesto solo idee, dì a Claude di non iniziare a sviluppare. Questi sono confini del workflow, non prompt per "essere più intelligenti"

La configurazione che rilascerei per prima

• Scegli 10-30 task reali e definisci un controllo per ciascuno
• Fai uno sweep di Sonnet 5.5 a medium e high, poi di Opus 5.5 a medium
• Logga input nuovi, output, scritture in cache, letture della cache, latenza, tentativi e pass/fail per ogni task
• Mantieni il prefisso stabile memorizzabile nella cache e conferma gli hit nell'utilizzo
• Instrada verso l'alto solo i fallimenti, allegandone le prove
• Rivaluta la scala quando cambia il carico di lavoro. Un benchmark salvato non è una verità assoluta

Se il 10% più difficile passa costantemente dal fallimento con Sonnet al successo con Opus, valuta di instradare quella classe riconoscibile di task direttamente a Opus fin dall'inizio. Se Sonnet high supera gli stessi casi spendendo meno, lasciali lì. Un router è una politica misurata, non un'opinione permanente su quale modello sia più intelligente

L'aggiornamento alla 5.5 non significa semplicemente "usa Sonnet per i lavori economici e Opus per quelli difficili"

È l'occasione per smettere di dare un prezzo al modello e iniziare a dare un prezzo al lavoro finito

Se sei arrivato fin qui

-> Iscriviti al mio Substack

-> Unisciti al mio Telegram

-> Salva questo articolo nei preferiti

-> Segui @0xwhrrari