Ottimizzare costo e intelligenza

Quando un carico di lavoro passa dal prototipo alla produzione, il costo diventa un vincolo di progettazione di primo livello. Il modello più capace può essere troppo costoso su larga scala, e il modello meno costoso può non raggiungere la qualità richiesta. Gestire bene il costo significa capire come ogni leva di costo influisce sulla qualità dell'output, perché alcune leve si scambiano con la qualità e altre no. La Claude Platform ti dà il controllo diretto su questo compromesso. Scegli il modello, il livello di "effort" (sforzo) e l'architettura per ogni richiesta, il che ti permette di collocare un carico di lavoro quasi ovunque sulla frontiera costo-intelligenza.

Costo e intelligenza sono di solito rappresentati come una frontiera in cui l'uno compra l'altra. Il primo gruppo di leve in questa pagina sposta un carico di lavoro verso quella frontiera riducendo il costo senza toccare la qualità; solo il secondo gruppo si sposta lungo di essa:

Le leve sono di due tipi:

• Vantaggi gratuiti riducono la spesa senza toccare la qualità: "prompt caching" (cache dei prompt), igiene dei token, un audit dei prompt rispetto al modello che stai eseguendo, elaborazione batch con il 50% di sconto per il lavoro che può attendere fino a 24 ore, e limiti di spesa del workspace come rete di sicurezza.
• Compromessi scambiano costo con intelligenza: scelta del modello, effort, limiti di output e "task budget" (budget per attività), e architetture multi-modello.

Ogni leva è accompagnata da risultati misurati e dalla regola per quando conviene. Nelle misurazioni di Anthropic, la cache dei prompt è stata la leva più grande con ampio margine: ha ridotto il costo del ciclo dell'agente di un fattore da 2,7 a 5,3 sui benchmark di questa guida e ha ridotto la fattura di un piccolo agente di triage dell'83%, o dell'88% con l'aggiunta del taglio dell'input. Le leve multi-modello sono più ristrette; un secondo modello ha ripagato in due forme, un "advisor" (consulente) e un "orchestrator" (orchestratore).

Inizia da qui

Abbina la tua situazione a una riga.

Questi risultati sono interni ad Anthropic (Benchmark citati) e indicativi, non garanzie, quindi misura sul tuo carico di lavoro con il metodo in quattro passaggi.

Riduci la spesa senza perdere qualità

La cache dei prompt, l'igiene dei token, l'elaborazione batch e un audit dei prompt rispetto al tuo modello attuale riducono tutti ciò che paghi senza ridurre la qualità dell'output. Valgono due avvertenze: l'elaborazione batch scambia latenza con il suo sconto, e il "context editing" (modifica del contesto), una leva di igiene dei token, è costato più di quanto ha fatto risparmiare nell'esecuzione misurata in questa sezione.

Metti in cache il contesto ripetuto

Perché la cache viene prima

Attiva la cache dei prompt prima di qualsiasi altra leva, perché ogni turno di un'attività agentica reinvia l'intera conversazione in crescita: prompt di sistema, definizioni degli strumenti e ogni turno precedente. Un'attività di 40 turni invia il suo primo turno 40 volte, quindi il costo dell'attività cresce all'incirca con il quadrato del numero di turni. La cache non ferma il reinvio, ma ogni reinvio costa circa un decimo e viene elaborato più velocemente: il prefisso è fatturato alla tariffa di lettura della cache, un decimo del prezzo di input, e ogni turno paga la tariffa di scrittura della cache di 1,25x solo per ciò che è nuovo.

Come appare un buon risultato. Nell'arco di un'intera giornata di traffico reale, i cicli di agente hanno letto una mediana dell'84% del loro input dalla cache, e il 10% superiore degli harness, di coding o meno, ha letto il 94% o più¹⁷. In profondità in un'attività, un ciclo ben costruito paga il prezzo pieno su meno dell'1% del suo input. Sotto circa l'80%, cerca qualcosa che rompe la cache (vedi Cosa rompe la cache).

Nelle esecuzioni misurate da Anthropic, le letture della cache sono abitualmente la singola componente più grande del costo dell'attività, rendendo la cache più preziosa della maggior parte delle decisioni sulla scelta del modello. Anthropic ha calcolato il prezzo delle esecuzioni di DeepResearch Bench II⁷ con e senza cache:

La durata predefinita della cache è di 5 minuti e i turni di un ciclo di agente sono a distanza di secondi, quindi lo sconto si applica alla maggior parte dei token a ogni turno. Le esecuzioni del grafico sulla cache hanno letto dal 79% al 90% dei loro token di input dalla cache. Il risparmio varia con la profondità dell'episodio, perché i cicli più brevi rileggono meno, ma la cache è rimasta la singola leva più grande su ogni modello e benchmark misurato.

Scegli la durata della cache

Se il tuo ciclo attende una persona tra i turni, usa la durata della cache di 1 ora. Costa di più da scrivere (2x il prezzo di input invece di 1,25x). Un miss su entrambe le durate fattura l'intero prefisso al prezzo di scrittura invece del prezzo di lettura, quindi la durata più lunga ripaga quando alcuni turni per sessione seguono una pausa tra 5 minuti e un'ora.

Per decidere, conta gli intervalli tra richieste consecutive in una conversazione:

• Più di circa 1 intervallo su 20 cade tra 5 minuti e un'ora, e gli intervalli oltre un'ora sono rari: usa la durata di 1 ora.
• I turni arrivano a distanza di secondi: resta sul predefinito di 5 minuti. Quando non c'erano pause, è costato il 15% in meno rispetto all'impostazione di 1 ora su Claude Sonnet 5 e l'11% in meno su Claude Opus 5.
• Gli intervalli oltre un'ora sono comuni: resta sul predefinito. Un intervallo oltre un'ora fa scadere entrambe le durate, e l'impostazione di 1 ora riscrive quindi il prefisso al suo prezzo di scrittura più alto, quindi perde su ciascuno di quegli intervalli. Delle tue pause più lunghe di 5 minuti, se circa il 60% o più supera anche un'ora, resta sul predefinito; la durata di 1 ora ripaga solo quando almeno circa il 40% delle pause lunghe termina entro l'ora.

Anthropic ha misurato il lavoro di triage di Taglia i token di input e di contesto con pause inserite prima di alcuni turni per simulare il ritardo di una persona¹⁶. Su entrambi i modelli misurati, la cache di 1 ora è diventata l'impostazione più economica quando circa 1 turno su 30 seguiva una pausa, quindi la regola di 1 su 20 lascia un margine, e il divario si allarga rapidamente oltre il punto di incrocio perché ogni turno in pausa sull'impostazione di 5 minuti riscrive l'intero prefisso. Ogni modello attuale usa gli stessi moltiplicatori di scrittura della cache, e ogni modello tranne Claude Fable 5.1 e Claude Mythos 5.1 lo stesso prezzo di lettura, quindi il punto di incrocio è nello stesso intervallo sugli altri modelli; Fable 5.1 è il caso trattato di seguito. L'accuratezza è rimasta entro il rumore tra esecuzioni in ogni cella. Il turno dopo una pausa ha mantenuto la sua latenza a cache calda sull'impostazione di 1 ora. Il grafico seguente traccia il costo per sessione rispetto alla quota di turni in pausa su Claude Sonnet 5:

Anthropic ha anche misurato richieste extra che mantengono calda la cache di 5 minuti. Su Claude Sonnet 5 e Claude Opus 5 non hanno fatto risparmiare nulla di misurabile rispetto alla durata di 1 ora a qualsiasi quota di turni in pausa e sono costate di più con una pausa prima di ogni turno, quindi usa invece la durata.

Su Claude Fable 5.1 l'impostazione più economica è diversa. La sua lettura della cache costa 0,025x il prezzo di input ($0,25 per milione di token) mentre le sue scritture della cache mantengono i moltiplicatori standard, quindi una richiesta keep-alive che rilegge il prefisso è economica e il sovrapprezzo di scrittura della durata di 1 ora è la voce più grande. Anthropic ha misurato il lavoro di triage su Claude Fable 5.1 con le stesse tre impostazioni¹⁹. Mantenere calda la cache di 5 minuti è costato dal 13% al 20% in meno per sessione rispetto alla cache di 1 ora ogni volta che le pause duravano minuti; solo con pause vicine ai 45 minuti la cache di 1 ora ha vinto, di circa 12 centesimi a sessione. Su Claude Fable 5.1, mantieni calda la cache di 5 minuti mentre una persona è assente per minuti, e acquista la durata di 1 ora quando le pause si avvicinano a un'ora:

Per mantenere calda la cache, invia di nuovo la richiesta precedente con max_tokens impostato a 0 entro 4 minuti dall'inizio della richiesta precedente, e ogni 4 minuti dopo, rimuovendo stream se era impostato. Conta dall'inizio della richiesta, non dalla fine della sua risposta: la durata di 5 minuti della cache decorre dall'inizio della richiesta che ha scritto o aggiornato la voce, quindi il tempo che la risposta ha impiegato a generare conta contro di essa. Questa è la richiesta di pre-riscaldamento: aggiorna la durata della cache, non genera nulla e fattura solo la lettura della cache. Non cambiare un byte del prefisso, e non usare max_tokens: 1, che campiona un token senza motivo. Reinvia gli header della richiesta oltre al suo body: se le tue richieste portano un header anthropic-beta (per un task budget, ad esempio), la richiesta keep-alive ha bisogno dello stesso header, altrimenti i campi protetti da beta nel body riprodotto vengono rifiutati. Una richiesta max_tokens: 0 viene rifiutata quando la richiesta imposta thinking.type: "enabled" (il pensiero adattivo predefinito su Claude Fable 5.1 va bene), output strutturati o una scelta forzata dello strumento (le sue limitazioni); su quei carichi di lavoro, acquista invece la durata di 1 ora.

# Entro 4 minuti dall'inizio dell'ultima richiesta (il tempo di generazione conta
# per la durata della cache), reinvia quella richiesta con max_tokens impostato a
# 0, rimuovendo stream (una richiesta con max_tokens: 0 non può usare lo streaming). Invia gli stessi
# header della richiesta originale, incluso l'eventuale header anthropic-beta.
jq '.max_tokens = 0 | del(.stream)' last_request.json | \
  curl https://api.anthropic.com/v1/messages \
    -H "x-api-key: $ANTHROPIC_API_KEY" \
    -H "anthropic-version: 2023-06-01" \
    -H "content-type: application/json" \
    --data-binary @-

Attiva la cache

La configurazione richiede poco lavoro. La cache automatica posiziona i breakpoint per te; altrimenti, la skill Claude API fornita con Claude Code può aggiungere la cache a un'integrazione esistente da un solo prompt. Il seguente estratto mostra la skill che la aggiunge all'harness che ha prodotto queste misurazioni:

$ claude
> /claude-api add prompt caching to this integration

Done. Prompt caching is now wired into the harness. Two changes:

- build_system() now adds cache_control: {"type": "ephemeral"} to the
  system block. Since the API renders tools -> system -> messages, this
  one breakpoint caches the entire static prefix -- the full tool array
  plus the system prompt.
- apply_moving_cache_breakpoints() strips any stale markers, then marks
  the last content block of the two most recent user turns. The older
  marker is the read point matching the prefix the previous request
  cached; the newer one extends the cache for the next request.

That's 3 breakpoints total, under the limit of 4.
...

Quei posizionamenti dei breakpoint seguono lo schema standard in Breakpoint di cache espliciti.

Cosa rompe la cache

Diverse cose possono rompere la tua cache durante un'attività. Qualsiasi cosa che cambia per richiesta, come un timestamp o una posizione in coda, posta davanti al prefisso stabile trasforma ogni richiesta in una scrittura completa della cache: nell'esecuzione di triage in Taglia i token di input e di contesto, una riga di stato di 25 token all'inizio del prompt di sistema è costata $4,24 per esecuzione invece di $0,59, più che eseguire con la cache disattivata. Mantieni il testo per richiesta nel turno utente più recente.

La cache è una corrispondenza di prefisso esatta al byte sulla richiesta in ordine (strumenti, poi prompt di sistema, poi messaggi), quindi una modifica in qualsiasi punto invalida tutto ciò che segue. Cambiare effort o la configurazione del thinking tra richieste invalida la cache da quel punto in avanti, e su alcuni modelli anche gli strumenti e il prompt di sistema che lo precedono; qualsiasi modifica al prompt di sistema invalida la cache da quel punto in avanti; impostare o cambiare un formato di output invalida la cache per l'intera conversazione; aggiungere, rimuovere o riordinare una definizione di strumento la invalida tutta. La pagina sulla cache dei prompt elenca questi casi, a parte il formato di output, che è trattato in output strutturati. Sui modelli più recenti, cambia le istruzioni con un messaggio di sistema a metà conversazione, un messaggio {"role": "system"} aggiunto a messages, invece di modificare il campo system di primo livello: il prefisso in cache resta intatto. Controlla quella pagina per quali modelli lo supportano. Sui modelli che lo supportano, anche un cambio di effort per messaggio lascia intatto il prefisso in cache. La posta in gioco è più alta su Claude Fable 5.1 e Claude Mythos 5.1: una rottura riscrive il prefisso a 1,25x il prezzo di input invece di leggerlo a 0,025x, quindi su un prefisso di 100.000 token un turno rotto costa $1,25 invece di $0,03, 50 volte la lettura, contro 12,5 volte ($0,63 invece di $0,05) su Claude Opus 5.

Anthropic ha misurato questo sulle sessioni lunghe dell'agente di triage¹⁸. Un cambio di effort e uno strumento aggiunto a metà sessione hanno riscritto 39.000 e 60.000 token in cache, e quelle sessioni sono costate $0,95 per sessione. Le stesse due modifiche sulla prima richiesta dopo la compattazione sono costate $0,75, e sulla richiesta che ha attivato la compattazione $0,92, perché il passaggio di riepilogo della compattazione ha poi rielaborato il contesto di 81.000 token al prezzo di scrittura della cache: quel passaggio di riepilogo è costato $0,21, contro $0,04 quando le stesse modifiche sono arrivate una richiesta dopo, con accuratezza entro il rumore tra esecuzioni in ogni braccio:

Cambiare un task budget a metà strada invalida qualsiasi prefisso in cache che contiene il valore del budget, quindi impostalo una volta, sulla prima richiesta. Ogni passaggio di context editing invalida il prefisso dal punto che cancella e la richiesta successiva paga per rimettere in cache tutto ciò che segue, quindi cancella in pochi lotti grandi piuttosto che in molti piccoli. Su Claude Fable 5.1 e Claude Mythos 5.1 ciascuno di questi costa 50 volte il prezzo di lettura per token, quindi contano di più lì. Fai ogni modifica che invalida la cache nelle pause naturali, poi conferma che le letture della cache non siano calate; se lo sono, la diagnostica della cache mostra dove il prefisso si è discostato.

Taglia i token di input e di contesto

La maggior parte delle richieste degli agenti porta token che non influenzano mai la risposta. Tagliarli raramente costa qualità dell'output, anche se non ogni leva qui ha fatto risparmiare denaro quando misurata. Due posti dove guardare:

• Taglio dell'input. Il filtraggio dinamico nello strumento web fetch tiene il boilerplate fuori dalle pagine recuperate, il ridimensionamento delle immagini dimensiona correttamente gli input di visione, e la ricerca strumenti con caricamento differito carica le definizioni degli strumenti solo quando necessario (misurato più avanti in questa sezione). La chiamata programmatica degli strumenti permette a Claude di eseguire diverse chiamate di strumenti dal codice così che solo il risultato filtrato entri nel contesto; la sua documentazione riporta il 24% in meno di token di input sui benchmark di ricerca agentica, con un punteggio più alto. Gestisci il contesto degli strumenti confronta ricerca strumenti, chiamata programmatica degli strumenti, cache dei prompt e context editing.
• Ciclo di vita del contesto. Il context editing cancella i risultati degli strumenti obsoleti, e la compattazione automatica con la sua soglia impedisce ai cicli lunghi di portarsi avanti l'intera cronologia.

Le leve interagiscono con la cache e tra loro, quindi giudicale per effetto netto, e usa la diagnostica della cache per confermare che il tuo prefisso in cache sopravviva a ogni modifica. Anthropic le ha misurate su un agente di triage delle issue che lavora su 20 segnalazioni di bug reali con screenshot da un repository pubblico, e su una variante più lunga dello stesso lavoro con 2,6 volte i token. Con la cache attiva, il taglio dell'input (ridimensionamento delle immagini e ricerca strumenti) ha tolto un ulteriore 26% dall'esecuzione breve e il 21% da quella lunga.

Differisci le definizioni degli strumenti non usate

Ogni definizione di strumento allegata a una richiesta è input a ogni turno, e pochi server MCP arrivano a centinaia di esse. Anthropic ha eseguito l'agente di triage con i suoi due strumenti più un catalogo di definizioni di strumenti reali da server MCP pubblici, per un totale fino a 502 strumenti, caricandoli tutti o contrassegnando gli extra con defer_loading dietro la ricerca strumenti:

Con ogni definizione caricata, il costo dell'esecuzione è quasi raddoppiato al crescere del catalogo, seguendo i token dello schema su ogni richiesta. Con la ricerca strumenti è rimasto piatto a ogni dimensione del catalogo, il 45% in meno a 502 strumenti. L'accuratezza è stata da 15 a 18 su 20 in ogni cella in entrambi i casi, e il modello non ha mai chiamato uno strumento sbagliato, quindi a questa scala il catalogo costa denaro, non correttezza. Lo stesso vale per gli strumenti che arrivano tramite il connettore MCP: con un server MCP GitHub pubblico collegato, differire il suo set di strumenti (default_config: {defer_loading: true}) ha ridotto l'esecuzione del 20% alla stessa accuratezza.

Tieni i file di dati fuori dal prompt

Quando il modello deve calcolare su una tabella, caricala con la Files API e lascia che il modello la interroghi con l'esecuzione di codice invece di incollarla. Anthropic ha posto 25 domande aggregate¹⁵ (somme, conteggi filtrati, group-by e un filtro per data) su un CSV pubblico di 1.862 righe, con le risposte calcolate da pandas:

Incollata nel prompt, la tabella è circa 91.000 token di input su ogni richiesta, e Claude Sonnet 5 ha risposto correttamente a 6 domande su 25. Caricata, con l'esecuzione di codice, ha risposto a tutte e 25, e l'esecuzione è costata circa un dodicesimo. Claude Opus 5 ha mostrato lo stesso schema.

Gestisci il ciclo di vita del contesto

Le leve del contesto ripagano solo su una sessione abbastanza lunga da averne bisogno:

Sull'esecuzione di 20 issue non hanno fatto risparmiare nulla, e il context editing è costato il 74% in più. Sull'esecuzione lunga la potatura ha fatto risparmiare il 39% e la compattazione il 32%, mentre il context editing non ha cambiato nulla. La potatura è poche righe che scrivi tu stesso: a ogni confine di attività, sostituisci i risultati degli strumenti grandi e obsoleti con un estratto di una riga. Si mette bene in cache perché le modifiche stanno in coda alla conversazione, dove l'attività successiva aggiunge comunque nuovo contenuto: 89% di letture della cache sulla prima richiesta dopo un confine e 81% sulle richieste tra i confini. Sull'intera esecuzione, la potatura e il context editing si mettono in cache circa ugualmente bene. La potatura è più economica perché il context editing riscrive a metà attività contenuto che la potatura elimina (circa due terzi del divario) e perché mantiene il contesto a circa metà della dimensione (l'altro terzo). Se usi il context editing, cancella in pochi lotti grandi. La potatura, adattata dall'harness:

import re

PRUNED = "[pruned at issue boundary]"


def prune_task_boundary(messages, tool_name_by_id, threshold=2000):
    """Call once per task boundary. Replaces large, stale search results with a one-line extract."""
    for message in messages:
        if message["role"] != "user" or not isinstance(message["content"], list):
            continue
        for block in message["content"]:
            if not (isinstance(block, dict) and block.get("type") == "tool_result"):
                continue
            if tool_name_by_id.get(block.get("tool_use_id")) != "search_issues":
                continue
            result_text = block.get("content")
            if not isinstance(result_text, str) or len(result_text) <= threshold:
                continue
            if result_text.startswith(PRUNED):
                continue  # already pruned on an earlier boundary
            # limita i risultati a riga singola per mantenere breve l'estratto
            first_line = result_text.split("\n", 1)[0].strip()[:200]
            refs = re.findall(r"#(\d+)", result_text)[:5]
            extract = f"{PRUNED} {first_line}"
            if refs:
                extract += " kept refs: " + " ".join("#" + r for r in refs)
            block["content"] = extract

Metti in batch il lavoro che può attendere

La Batch API toglie il 50% da ogni token di una richiesta, inclusi quelli in cache, in cambio di risultati che arrivano in qualsiasi momento entro 24 ore. Instrada ogni richiesta che nessuno sta aspettando attraverso un batch, e mantieni il percorso interattivo per il resto. Il batching è la seconda leva gratuita più grande dopo la cache per il lavoro degli agenti non presidiato: esecuzioni di valutazione, backfill e lavori pianificati come un'esecuzione ricorrente dell'agente di triage delle issue dalla misurazione del taglio dei token. Si combina con tutto in questa pagina tranne l'interattività, ma non è disponibile per le sessioni di Claude Managed Agents, che sono interattive per progettazione (vedi prezzi di Claude Managed Agents).

Verifica i prompt rispetto al modello attuale

Ogni generazione di modelli risponde ai prompt in modo diverso, quindi un prompt accumula testo scritto per un modello che non usi più. Il caso usuale è un'istruzione eccessivamente specifica aggiunta per compensare un modello più vecchio: "verifica due volte", "sii massimamente approfondito", una procedura passo-passo obbligatoria, o uno scratchpad di ragionamento fatto a mano. Un modello più nuovo le segue alla lettera, producendo round di strumenti extra e scrittura extra, quindi la fattura sale senza guadagno in accuratezza. Verificare i prompt rispetto al modello che esegui ora, e di nuovo ogni volta che cambi modello, è un vantaggio gratuito.

L'audit è un solo comando. La skill Claude API fornita con Claude Code ha un comando prompt-audit che legge i prompt e il codice delle richieste di un progetto e riporta cosa è stato scritto per un modello diverso. Questo estratto abbreviato lo mostra eseguito su un prompt di support desk e codice delle richieste contenente quegli schemi:

$ claude
> /claude-api prompt-audit

10 findings. The three that matter most:

1. budget_tokens returns a 400 on Opus 5 (support_agent.py:10). This code
   does not run against its own target model. Everything else here is
   quality; this one is an outage.
2. The prompt contains two live contradictions. Line 15 says confirm before
   every refund, line 17 says process every eligible refund immediately.
   Line 19 asks for a complete recap *and* a three-sentence maximum.
3. The reasoning scaffold and the 6-step script fight the model rather than
   steer it. <scratchpad> + "reason step by step" is now a request
   parameter, not prose; the mandatory 6-step procedure plus "investigate
   fully even when the ticket looks simple" forces four tool calls on a
   "where's my package" ticket.
...
-After any refund or escalation, verify twice before submitting: re-fetch
-the order, re-check every figure in your reply against the fresh lookup,
-and review the reply a second time for errors.
+Before submitting a refund or an escalation, re-fetch the order and confirm
+every figure in your reply matches the fresh lookup.

Il comando propone poi le sue modifiche come diff (un hunk mostrato) ed elenca cosa ha deliberatamente lasciato invariato: la finestra di rimborso, il requisito di tono e la soglia di qualità. Rivedi una patch, non una riscrittura.

L'effetto è misurabile. Su una valutazione di support desk¹⁴, i prompt scritti per Claude Opus 4.8 sono costati il 36% in più per ticket su Claude Opus 5 senza alcun cambiamento in accuratezza. Eseguire l'audit sugli stessi prompt ha reso Opus 5 sia più economico della versione non verificata (del 14%) sia più accurato (97% dei ticket, dal 92%, un guadagno fuori dal rumore). Sulla migrazione da Claude Sonnet 4.6 a Claude Sonnet 5, l'audit ha tolto il 14% alla stessa accuratezza:

I due tipi di testo obsoleto hanno costi diversi. Le istruzioni che il nuovo modello segue troppo letteralmente costano denaro: rimuovere "verifica due volte" ha ridotto il costo per ticket di Opus 5 di un terzo, e rimuovere "sii massimamente approfondito" quasi altrettanto. Il testo che non si adatta più al modello costa invece accuratezza: un'impostazione di thinking ritirata, regole contraddittorie e uno scratchpad fatto a mano che confligge con il thinking proprio del modello hanno ciascuno ripristinato da 7 a 11 punti su Opus 5 quando rimossi:

Gli stessi schemi tendono ad apparire nelle descrizioni degli strumenti e nelle skill, che vale la pena verificare anch'esse.

Scambia costo con intelligenza

Queste leve stabiliscono dove un singolo modello si colloca tra costo e intelligenza: scelta del modello, effort, riesecuzione dei fallimenti a un'impostazione più alta, e i budget e limiti entro cui lavora. Inizia con uno sweep dell'effort sul tuo modello attuale (Regola l'effort). Dal costo e capacità più bassi ai più alti, i modelli attuali sono Claude Haiku 4.5, Claude Sonnet 5, Claude Opus 5 e Claude Fable 5.1 (il modello di frontiera); Panoramica dei modelli ha la gamma completa e i prezzi.

Confronta i modelli sul costo per attività

I listini prezzi sono scritti per token, e per token il modello di frontiera sembra costoso: il prezzo per token di Claude Fable 5.1 è diverse volte quello di Claude Sonnet 5. Paghi però per attività completate, quindi confronta i modelli sul costo per attività completata. Un modello più capace finisce un'attività con meno lavoro: meno turni, meno ricerca, meno rilettura del proprio contesto e meno ritorni sui propri passi. Il sovrapprezzo per token è spesso sopraffatto dal fare meno di tutto.

Anthropic ha misurato questo sul sottoinsieme di SWE-bench Pro³, con prezzo calcolato come viene fatturato a un cliente:

Claude Fable 5.1 a effort low ha risolto l'88,6% delle attività per $0,54 per attività risolta, contro il 77,4% per $0,84 di Claude Sonnet 5 al suo predefinito: 11 punti in più per il 35% in meno per attività risolta, nonostante un prezzo per token cinque volte più alto. Non vince sempre, però. Sullo stesso sottoinsieme, che entrambi i modelli saturano in gran parte e i cui punteggi non sono confrontabili con la classifica pubblica, Claude Opus 5 da solo ha eguagliato Claude Fable 5.1 da solo al predefinito (91,7% rispetto a 92,1%, entro il rumore tra esecuzioni) a circa il 15% in meno per attività risolta ($1,01 contro $1,19), e Opus 5 a low ha risolto l'84,0% per $0,25. E sui lunghi cicli di ricerca il modello di frontiera fa più lavoro, non meno: su DeepResearch Bench II⁷, Fable 5.1 a low ha ottenuto 10 punti sopra Sonnet 5 (66% contro 56%) a circa quattro volte il costo per attività ($4,66 contro $1,20), perché esegue un ciclo di ricerca più lungo su un contesto più grande. Claude Opus 5 al suo predefinito ha ottenuto il 71% sulla stessa base per $6,71 per attività, sopra Fable 5.1 al suo predefinito (65% per $7,12), quindi anche sulla ricerca Fable 5.1 si guadagna il suo prezzo solo a low.

Per la maggior parte dei carichi di lavoro degli agenti, inizia con Claude Fable 5.1 a effort low e aumenta l'effort dove manca. Per token costa il doppio di Claude Opus 5 sull'input non in cache, ma la metà sull'input in cache ($0,25 contro $0,50 per milione), e in un ciclo di agente l'input in cache è il termine più grande. Sul benchmark di coding in Strategia advisor, Fable 5.1 a medium ha eguagliato Opus 5 al suo predefinito per circa un terzo del costo per tentativo ($2,91 contro $8,50). Su Chartography¹³, un benchmark di lettura di grafici, Fable 5.1 a low ha ottenuto 62,5 per $0,15 a grafico, rispetto a 49 per $0,38 di Opus 5 a low. Sul sottoinsieme di SWE-bench Pro, Claude Opus 5 al suo predefinito resta il modo più economico per raggiungere il punteggio massimo, come notato prima. All'altro estremo, Claude Haiku 4.5 ha risposto alle domande di GPQA Diamond⁹ a circa un decimo del costo per domanda di Opus 5, con il 63% di accuratezza rispetto al 92% di Opus, ed è rimasto molto più indietro sulle lunghe attività di coding. Si adatta a lavoro ad alto volume con output verificabili, non a lunghi cicli agentici.

La classifica si inverte in base al carico di lavoro, e nessun listino prezzi ti dice in quale direzione. Calcola il prezzo di ogni candidato in costo per attività completata sul tuo traffico, inclusi Claude Opus 5 e il modello di frontiera a effort ridotto.

Calcola il prezzo della coda del tuo carico di lavoro, non della mediana: confronta i modelli sul decimo più difficile delle tue attività, non su quella tipica. Sull'attività tipica ogni modello sembra simile e il più economico sembra il migliore, ma la fattura è decisa dalle attività che il modello più economico fallisce, perché un'attività fallita fattura comunque i suoi token, poi il nuovo tentativo, poi qualunque cosa il fallimento costi a valle. La coda è anche dove va il denaro anche quando nulla fallisce. Su un'esecuzione WideSearch¹ di 20 problemi, due problemi hanno portato il 43% della spesa:

Le strategie multi-modello esistono per spendere intelligenza di frontiera su quella coda senza pagare tariffe di frontiera per il resto.

Aggiorna il modello

Se sei indietro di un modello o due, la leva più economica è la stringa del modello. Anthropic ha eseguito i recenti modelli Claude Opus, Claude Sonnet e Claude Fable attraverso lo stesso harness sul sottoinsieme di SWE-bench Pro³, ciascuno ai suoi predefiniti di rilascio e con prezzo a tariffe di listino, e ha eseguito di nuovo la linea Opus su Terminal-Bench 3²⁰:

Anthropic applica alla linea Opus lo stesso prezzo per token tra le versioni, quindi qualsiasi differenza deriva da quanto lavoro ogni modello fa per attività: con prezzo calcolato come viene fatturato a un cliente, Claude Opus 4.8 risolve la stessa quota di attività di Claude Opus 4.7 per il 14% in meno per attività risolta, e Claude Opus 5 risolve poi 12 punti in più di attività al 21% in più per attività risolta. Claude Opus 5 a effort low batte il predefinito di Opus 4.8 su questo benchmark per circa il 30% del suo costo per attività risolta, quindi l'aggiornamento più economico è il nuovo modello a un'impostazione più bassa. Il risparmio di Sonnet 5 deriva dal suo prezzo per token più basso, che compensa ampiamente i token extra che usa per attività rispetto a Sonnet 4.6: il 15% in meno per attività risolta per 5 punti in più. Il livello di frontiera ha guadagnato allo stesso modo: Claude Fable 5.1 eguaglia il punteggio di Claude Fable 5 per il 43% in meno per attività risolta, la maggior parte dovuta al prezzo di lettura della cache più basso. Quella direzione non è garantita: su DeepResearch Bench II⁷ lo stesso aggiornamento costa il 41% in più per attività a high (il 79% in più a low) per i suoi 2 o 3 punti extra sulle attività pulite in ogni braccio (riferimento 7), perché il nuovo modello fa più lavoro per attività lì. I prezzi di input e output sono gli stessi e la lettura della cache è 4x più economica, quindi misura l'aggiornamento sul tuo carico di lavoro prima di presumere che faccia risparmiare.

Su lavoro più difficile il divario si allarga. Su Terminal-Bench 3²⁰, dove le attività sono abbastanza difficili che il tasso di successo piuttosto che i token determina la fattura, Claude Opus 4.7, Opus 4.8 e Opus 5 spendono ciascuno da $8 a $15 per attività ma risolvono il 7%, il 15% e il 41% delle attività, quindi il costo per attività risolta scende da $183 a $63 a $28 salendo la scala. Il sovrapprezzo del 21% che Claude Opus 5 porta rispetto a Opus 4.8 sul sottoinsieme di coding saturato diventa un risparmio del 56% su Terminal-Bench 3, dove il modello più vecchio per lo più fallisce: più il tuo carico di lavoro sconfigge il vecchio modello, più l'aggiornamento fa risparmiare per risultato.

Confronta sul costo per attività risolta, non per token: lo stesso testo costa circa il 30% in più di token su Claude Opus 4.7 e successivi, quindi un confronto per token fa sembrare i modelli più nuovi più costosi per costruzione.

Regola l'effort

L'"effort" (impegno) è il modo più diretto per adattare un modello al tuo compito. Il parametro effort governa quanto pensiero, quante chiamate agli strumenti e quanta auto-verifica il modello esegue, e il valore predefinito (high) è adatto ai compiti impegnativi. Il costo cresce con tutta quell'attività; l'accuratezza cresce solo con la parte di cui il tuo compito ha bisogno. Al di sotto del tetto del modello, i livelli di effort più alti pagano per una profondità che il compito non usa mai.

Sui benchmark di ricerca e di lavoro intellettuale (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ e GDPval², tutti con Claude Fable 5), la curva dell'accuratezza rispetto al costo è quasi piatta: low ha rinunciato a 1-3 punti in cambio di una riduzione da un terzo alla metà del costo per compito, medium ha eguagliato l'accuratezza del valore predefinito a circa il 70%-87% del suo costo, e il valore predefinito non ha comprato nulla di misurabile rispetto a medium su nessuno dei quattro. Su DeepWideSearch, low ha anche eguagliato un orchestratore con un worker Claude Sonnet 5 a un costo inferiore del 29%: abbassare l'effort ha battuto un cambio di architettura.

Le impostazioni di effort più basse sono spesso più veloci, il che conta quando il vincolo è la "latency" (latenza). In queste esecuzioni, low ha impiegato 4,5 minuti per problema su DeepWideSearch, contro 7,9 minuti al valore predefinito. Sul benchmark del corpus, il cui input non entra in nessuna singola "context window" (finestra di contesto), Fable 5.1 ha impiegato 15,2, 17,5 e 19,9 ore per episodio a low, medium e high.

La programmazione a lungo orizzonte è dove l'effort compra davvero accuratezza. Su SWE-bench Pro³, Claude Opus 5 ha rinunciato a circa 2 punti a medium per metà del costo e a circa 8 punti a low per un quarto di esso: un vero compromesso, che rieseguire i fallimenti a un effort più alto trasforma di nuovo in un risparmio. Questo grafico traccia l'accuratezza rispetto al costo per i benchmark di ricerca e di lavoro intellettuale e per SWE-bench Pro:

Ne derivano due conseguenze. Primo, traccia questa curva per il tuo carico di lavoro prima di aggiungere un secondo modello: in queste misurazioni interne, una configurazione multi-modello che sembrava più economica del singolo modello predefinito è costata più di quello stesso modello a un effort più basso. Secondo, questa curva è la baseline a modello singolo che qualsiasi strategia multi-modello deve battere, quindi il passo 2 della misurazione sul tuo carico di lavoro stabilisce la baseline su tutti i livelli di effort.

Il lavoro difficile non richiede automaticamente un effort alto. Su DeepResearch Bench II⁷, Claude Fable 5.1 ha ottenuto quasi lo stesso punteggio a low, medium e high mentre il costo per compito saliva da $4,66 a $7,12, quindi alzare l'effort in questo caso non aumenta in modo apprezzabile la qualità dell'output; sui 21 compiti puliti in ogni braccio (riferimento 7), anche Claude Fable 5 è risultato piatto rispetto all'effort, sebbene la base di 33 compiti del grafico, che scarta i tentativi interrotti di ciascun modello, lo mostri in salita. Misura la curva sul modello che distribuisci, non su quello che hai misurato per ultimo:

La sola descrizione del compito non rivela quale tipo di carico di lavoro hai, quindi prova due o tre livelli di effort su un campione del tuo traffico e leggi la risposta dalla curva. Testa ogni livello in una sessione separata: cambiare l'effort di primo livello a metà sessione invalida la cache (vedi Metti in cache il contesto ripetuto) e distorce il confronto. Per i dettagli sul parametro, vedi Effort.

Riesegui i fallimenti a un effort più alto

Quando l'esito di un compito è verificabile, la politica più economica sulla curva dell'effort non è un'impostazione fissa: esegui ogni compito a un'impostazione bassa e riesegui solo i fallimenti a una più alta.

Anthropic ha calcolato questa politica compito per compito a partire dalle esecuzioni di effort sul sottoinsieme di SWE-bench Pro³ in Regola l'effort. Con Claude Opus 5 a low, il 16% dei compiti è fallito; con quelli rieseguiti al valore predefinito, circa il 93% è passato per circa $0,45 ciascuno, contro il 91,7% per $0,93 eseguendo tutto al valore predefinito: lo stesso tasso di successo per metà del costo, contando i tentativi economici falliti. Partendo invece da medium si è risolto circa il 94% per circa $0,61. La maggior parte del piccolo incremento è dovuta al secondo tentativo (rieseguire i fallimenti del valore predefinito al valore predefinito ottiene circa lo stesso punteggio, per più soldi), quindi usa questa politica per il risparmio, non per l'incremento:

Si applicano due condizioni. Primo, ti serve un segnale di fallimento (qui, i test stessi del benchmark); un verificatore che approva lavoro scadente lascia passare quei fallimenti. Secondo, ogni fallimento al primo passaggio richiede il tempo reale di due esecuzioni, quindi il risparmio si paga in latenza sui fallimenti.

Imposta budget e limiti di output

La maggior parte delle esecuzioni di compiti agentici è economica, ma una minoranza spende molte volte il costo mediano in ricerche, ri-verifiche e test eccessivi. Un task budget (budget del compito) prende di mira quella coda. Il modello vede un conto alla rovescia dei token in tempo reale per l'intero compito e si autoregola, tagliando le ricerche di scarso valore, saltando le verifiche ridondanti e concludendo invece di entrare in una spirale.

Anthropic ha misurato il tasso di successo e il costo per compito su SWE-bench Pro³ con Claude Fable 5.1 man mano che il budget si restringeva:

Un budget generoso ha ridotto il costo per compito del 44% per circa 3 punti di tasso di successo, al limite del rumore tra un'esecuzione e l'altra, e il budget più stretto consentito lo ha ridotto del 58% per 6 punti. Qui i budget hanno comprato efficienza, a un prezzo in tasso di successo che cresce man mano che il budget si restringe.

Tre controlli svolgono tre lavori diversi. Un task budget fa risparmiare denaro, perché il modello lo vede. max_tokens è un limite di sicurezza: abbassarlo ha ridotto il costo per tentativo senza ridurre il costo per compito risolto. Su Claude Managed Agents, un budget di sessione è il blocco rigido in dollari dietro entrambi. Imposta tutti e tre: un task budget, un max_tokens alto e un limite di sessione per l'esecuzione che non vuoi mai vedere in fattura, con un limite di spesa del workspace come ultima rete di sicurezza.

• I task budget sono in beta (header beta task-budgets-2026-03-13) sui modelli più recenti; controlla la tabella di supporto per sapere quali. Parti vicino al 90° percentile di utilizzo dei token del tuo loop, poi restringi (Scegliere un budget mostra come raccogliere quella distribuzione). I budget al di sotto dell'attuale soglia minima di 20.000 token vengono rifiutati, e budget molto stretti possono produrre comportamenti simili a un rifiuto. Imposta il budget una sola volta, alla prima richiesta, perché una modifica a metà compito invalida la cache. Il budget è indicativo, orienta il modello invece di fermarlo, quindi verifica l'aderenza sul tuo carico di lavoro.
• max_tokens limita una singola risposta, in modo invisibile al modello, quindi abbassarlo non fa economizzare il modello. I turni che avevano bisogno di quello spazio vengono scartati e comunque fatturati. Su un benchmark interno di compiti su repository¹², un limite di 16.384 token ha interrotto il 15% dei tentativi di Claude Opus 5 e il 43% di quelli di Claude Fable 5.1 all'effort predefinito, e solo 9 dei 117 tentativi di Fable interrotti sono comunque passati. Le esecuzioni interrotte hanno speso meno per tentativo ma hanno comprato proporzionalmente meno soluzioni, quindi il costo per compito risolto è stato circa lo stesso che a 64.000 ($21 contro $22). A 64.000, 2 di circa 14.000 turni all'effort predefinito sono stati comunque troncati, e Fable 5.1 ha risolto il 58,5% dei compiti invece del 36,3% (su un taglio separato del sottoinsieme di SWE-bench Pro³, descritto nel riferimento 12, nessuna differenza: 94 su 100 con entrambi i limiti). Ritentare i tentativi interrotti raramente aiuta: allo stesso limite la maggior parte fallisce di nuovo, e a uno più alto paghi anche il tentativo sprecato. Imposta max_tokens a 64.000 per il lavoro agentico, o a 128.000, il massimo, quando un singolo tentativo troncato è costoso; a 128.000 Fable 5.1 ha risolto il 60,0% allo stesso costo per compito risolto. Trasmetti in streaming le risposte così grandi, tratta stop_reason: max_tokens come un fallimento, e risparmia con l'effort e i task budget, che il modello può vedere.
• I budget di sessione su Claude Managed Agents sono il blocco rigido. Un budget di sessione è un limite in dollari su una sessione ai prezzi di listino per token, ricerche e tempo di sessione. Al raggiungimento del limite, la sessione va in pausa con stop_reason: budget_reached; alzare il budget la riprende. È applicato dalla piattaforma, funziona su qualsiasi modello con un prezzo di listino, inclusi i modelli in cui i task budget non sono ancora disponibili, e si combina con il task budget indicativo. I deployment applicano lo stesso campo a ogni esecuzione.

Chiedi risposte più brevi. I token di output costano cinque volte i token di input su Claude Sonnet 5, e in un loop agentico ogni token che il modello scrive ritorna come input a ogni turno successivo, quindi paghi una risposta lunga ancora e ancora. Anthropic ha eseguito il lavoro di triage con tre istruzioni per la risposta finale, tre esecuzioni ciascuna, con lo stesso modello e gli stessi strumenti. L'originale chiedeva due righe:

4. Finish with exactly two lines:
LABEL: <one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish>
SUMMARY: <one or two sentences for the engineering team>

La variante più breve ne chiedeva una:

4. Finish with exactly one line in this form:
DECISION | LABEL | REASON
where DECISION is one of: triage-now, needs-info, close-duplicate; LABEL is one of: bug-confirmed, needs-more-info, duplicate-candidate, feature-request, upstream-issue, perf, ui-polish; REASON is one clause under 15 words. Output nothing after that line.

La variante più lunga chiedeva un memo con cinque sezioni intitolate: riepilogo del problema, evidenze, controllo dei duplicati, etichetta consigliata e prossimi passi. Per una issue, un prompt in coda che non viene mai inviato dopo una domanda saltata, le prime due risposte sono state:

LABEL: bug-confirmed
SUMMARY: When a user submits a new prompt instead of answering an agent's pending question, the question is cancelled/skipped but the new prompt remains stuck in "QUEUED" state indefinitely since it's waiting on a response to the now-cancelled question; the queued prompt should be processed immediately after cancellation.

triage-now | bug-confirmed | Clear repro steps show prompt queues indefinitely after cancelled question.

La risposta a una riga ha usato il 39% di token di output in meno rispetto all'originale a due righe ed è costata il 14% in meno per esecuzione. Il memo ha usato sei volte i token di output ed è costato 2,8 volte la risposta a una riga. Tutte e tre hanno ottenuto punteggi entro il rumore tra un'esecuzione e l'altra rispetto alle etichette di riferimento, quindi i formati differiscono in ciò che paghi molto più che in ciò che azzeccano. Chiedi la risposta che leggerai, non quella che sembra esaustiva.

Al limite max_tokens più basso entrambi i modelli spendono meno per tentativo ma risolvono proporzionalmente meno compiti, quindi il costo per compito risolto si muove appena:

Quasi ogni turno termina molto al di sotto di entrambi i limiti. Il raro turno lungo è ciò che il limite più alto compra:

Combina i modelli

Le architetture multi-modello si adattano a carichi di lavoro la cui complessità dei compiti varia abbastanza da far sì che passi diversi siano serviti meglio da modelli diversi. Quando il tuo traffico mescola lavoro di routine che un modello più piccolo gestisce in modo affidabile con passi più difficili che richiedono capacità di frontiera, dividere il lavoro mantiene l'intelligenza di frontiera dove conta mentre la maggior parte dei token viene fatturata alle tariffe del modello più piccolo. Quando un carico di lavoro non ha quella mescolanza, perché la sua difficoltà è uniforme o è una singola catena dipendente, un singolo modello ben regolato è di solito la scelta migliore. Ogni sezione sulle strategie fornisce la regola per distinguere i due casi.

Due strategie coprono la maggior parte dei carichi di lavoro, e differiscono per quale modello tiene il loop principale:

Strategia advisor: scala le decisioni difficili

Nella strategia advisor, un modello esecutore a costo inferiore esegue il loop agentico e svolge la maggior parte dei turni. Quando incontra una decisione che richiede un giudizio più profondo, come scegliere un approccio o riprendersi da un fallimento, chiama un modello advisor a intelligenza superiore per una guida strategica, poi continua. La maggior parte dei token viene fatturata alle tariffe dell'esecutore, e solo le consultazioni occasionali alle tariffe dell'advisor.

Per usarla, aggiungi lo strumento advisor alla tua richiesta. Questa funzionalità beta esegue l'intera strategia lato server in una sola richiesta /v1/messages: l'esecutore emette una chiamata allo strumento, Anthropic esegue l'inferenza dell'advisor, e l'esecutore continua con il consiglio; non scrivi alcun codice di orchestrazione. Su Claude Managed Agents, dai alla sessione un advisor aggiungendo una voce advisor al roster multiagent dell'agente; il thread primario della sessione lo consulta allo stesso modo. Anche Claude Code lo supporta; vedi scalare le decisioni difficili con lo strumento advisor.

Cosa determina il rendimento. L'advisor vede il compito solo attraverso le chiamate dell'esecutore, quindi due cose decidono quanto aiuta.

La prima è il divario tra i modelli. L'advisor può trasferire solo capacità che l'esecutore non ha: su GPQA Diamond⁹ un esecutore Claude Haiku 4.5 ha guadagnato moltissimo da un advisor Claude Opus 5, un esecutore Claude Sonnet 5 ha guadagnato qualche punto, e un esecutore di frontiera quasi nulla.

La seconda, e quella fragile, è se l'esecutore chiede davvero (il tasso di consultazione). Un esecutore a effort basso può smettere di rilevare di essere bloccato: un abbinamento che consulta sulla maggior parte dei compiti all'effort predefinito può scendere a consultare quasi su nessuno quando l'effort viene abbassato, e allora ottiene un punteggio inferiore all'esecutore da solo. Il tasso varia anche per compito: su DeepSWE¹⁰ un esecutore Sonnet 5 a effort basso ha continuato a chiedere e ha guadagnato 23 punti; su SWE-bench Pro³ lo stesso esecutore ha smesso. Quando l'esecutore chiede, recupera gran parte del divario. Tra gli abbinamenti nel grafico seguente il cui esecutore ha continuato a chiedere, l'advisor ha chiuso almeno metà del divario rispetto al modello più forte (l'abbinamento di programmazione ha battuto nettamente il modello più forte), e paghi il modello più forte solo sulle consultazioni, che è ciò che rende possibili i casi di costo:

Il tasso di consultazione risponde al prompting. Con la sola descrizione integrata dello strumento, gli esecutori chiamano troppo poco, specialmente sul lavoro di programmazione, quindi la documentazione dello strumento advisor fornisce un "system prompt" (prompt di sistema) che chiede una chiamata prima del lavoro sostanziale e una prima di finire, circa due o tre chiamate per compito. L'abbinamento di programmazione misurato di seguito ha funzionato a quella cadenza, circa due consultazioni su ogni compito. Quella pagina copre anche come sollecitare un esecutore che chiama troppo poco e come limitare le chiamate lato client per contenere il costo. Quindi tieni d'occhio il tasso di consultazione: sollecitalo con il prompt, misuralo e ripristina l'effort dell'esecutore se crolla.

Quando conviene sul costo. Un advisor fa risparmiare denaro quando poche consultazioni brevi, fatturate alla tariffa dell'advisor, sostituiscono l'esecuzione del modello dell'advisor per l'intero compito. Funziona meglio quando il modello dell'advisor ha un prezzo ben superiore a quello dell'esecutore, quindi la configurazione più conveniente è un advisor di frontiera sopra un esecutore di fascia media. Un abbinamento può reggere anche in cima alla gamma, perché il consiglio fa risparmiare anche token dell'esecutore: un esecutore a cui viene indicato l'approccio giusto esplora meno vicoli ciechi, il che può coprire le consultazioni.

Su un benchmark interno di programmazione agentica¹¹, eseguito con un semplice agente API, un esecutore Claude Opus 5 con un advisor Claude Fable 5.1 è stata la configurazione più accurata misurata, a $7,69 per tentativo. Si colloca sopra la linea che passa per le impostazioni di effort di ciascun modello: 3,5 punti sopra Opus 5 da solo all'impostazione predefinita per leggermente meno denaro, un divario che cinque tentativi per compito separano dal rumore, e circa 2,5 punti sopra il modello dell'advisor da solo per circa la metà in più di denaro:

Una misurazione precedente tramite la modalità advisor di Claude Code ha prodotto lo stesso ordinamento. Leggi questo risultato come una forma da testare sul tuo carico di lavoro: l'advisor compra qualche punto a circa il prezzo dell'esecutore stesso. Un divario di capacità più ampio non garantisce un affare migliore. Il costo in latenza sono le consultazioni stesse: circa due chiamate extra al modello di frontiera per compito su questo benchmark, ciascuna sul percorso critico del compito.

Quando il modello più forte da solo è il passo migliore. Dove l'accuratezza di un carico di lavoro risponde all'effort, confronta l'abbinamento con il modello dell'advisor da solo a un'impostazione ridotta prima di costruirlo: l'advisor viene pagato solo sui compiti che ne hanno bisogno, ma una consultazione che scatta sulla maggior parte dei compiti costa più che eseguire il modello più forte stesso. Su Chartography¹³ lo stesso abbinamento ha eguagliato Claude Fable 5.1 da solo a medium entro il rumore tra un'esecuzione e l'altra (65,0 contro 67,5) a circa 2,6 volte il costo per compito, perché l'advisor è stato consultato su quasi ogni compito. Misura prima il tuo tasso di consultazione: se l'esecutore chiede sulla maggior parte dei suoi compiti, stai pagando tariffe da advisor sull'intero carico di lavoro, ed eseguire il modello dell'advisor stesso è il modo più economico per arrivare allo stesso punteggio.

Qualunque sia l'abbinamento, prima calcola il prezzo del modello dell'advisor da solo a effort basso; quella è la baseline da battere. Ricontrolla a ogni rilascio di modello, perché i rilasci spostano sia il divario di capacità sia il rapporto di prezzo.

Quando è adatta. La strategia advisor si adatta a carichi di lavoro in cui i turni sono per lo più meccanici ma un piano eccellente conta: agenti di programmazione, computer use e pipeline di ricerca multi-passo. Si adatta male quando ogni turno richiede davvero capacità di frontiera, quando non c'è nulla da pianificare (Q&A a turno singolo), o quando il tuo esecutore è già vicino alla capacità dell'advisor.

Strategia orchestratore: delega il lavoro di massa

Nella strategia orchestratore, il modello di frontiera tiene il loop. Scompone il compito, distribuisce i sotto-compiti a modelli worker a costo inferiore e unisce i loro risultati. La trascrizione dell'orchestratore resta breve perché i worker assorbono l'esplorazione pesante in token, quindi la maggior parte dei token viene fatturata alle tariffe dei worker mentre il piano e la sintesi provengono comunque dal modello di frontiera.

Per costruirne uno, usa l'orchestrazione multiagente in Claude Managed Agents: configura un agente coordinatore (l'orchestratore) e un roster di agenti worker, ciascuno con il proprio modello. Per un esempio funzionante completo con un coordinatore di frontiera e worker Claude Sonnet 5, vedi la ricetta del Claude Cookbook Coordinator pattern: big models for planning, small models for execution.

Questo pattern fa risparmiare tempo reale quando i worker possono funzionare in parallelo: sul benchmark del corpus⁸, un episodio ha richiesto circa 2,3 ore con il coordinatore che eseguiva il limite documentato della piattaforma di 25 worker concorrenti, contro 15-20 ore in solitaria. Ha fatto risparmiare denaro solo in due situazioni misurate. Sul lavoro che un singolo modello poteva gestire da solo, lo stesso modello a effort più basso è stato più economico ogni volta.

Caso 1: assicurazione contro la coda dei costi sul lavoro di routine. Un modello di frontiera che funziona da solo occasionalmente entra in una spirale su un problema di routine che normalmente risolverebbe. Poiché non puoi sapere in anticipo quali saranno, poche esecuzioni di questo tipo dominano la fattura. Un coordinatore che passa il lavoro di routine a un worker a costo inferiore limita quella coda, perché qualsiasi spirale ora avviene alle tariffe del worker.

Anthropic lo ha misurato su una porzione deliberatamente facile di BrowseComp⁴ (10 problemi che il modello in solitaria risolve in modo affidabile; 50 esecuzioni delegate e 70 in solitaria). Un coordinatore Claude Fable 5 con un worker Claude Sonnet 5 è costato in media circa la metà di Claude Fable 5 da solo e circa un terzo al 90° percentile ($12 contro $33), e la singola esecuzione più costosa del modello in solitaria, a $84, era anche sbagliata:

La delega ha reso sulla quota di lavoro di routine, normalmente risolvibile, l'opposto dell'intuizione secondo cui i worker servono per i problemi difficili. Sull'insieme completo e più difficile di BrowseComp, l'economia si è invertita. Se il tuo traffico ha una lunga coda di costi sui compiti di routine, questo è il caso orchestratore da misurare per primo.

Caso 2: lavoro più grande di una finestra di contesto. Un modello in solitaria deve elaborare un input così grande in modo seriale, una finestra di contesto alla volta, pagando per rileggere il proprio stato a ogni passaggio. I worker leggono ciascuno la propria partizione, in parallelo e alle tariffe dei worker. Il lavoro pesante in lettura che entra comunque in una finestra di contesto è un problema di scelta del modello, non di delega: sul solo costo di lettura, l'orchestratore risulta vincente solo quando nessun singolo contesto può contenere il lavoro.

Anthropic ha costruito un benchmark per questo caso⁸: un corpus di 21,6 milioni di token di 14 pacchetti Python pubblici con 130 difetti inseriti, troppo grande per qualsiasi finestra di contesto. Abbassare l'effort non può aiutare, perché la fattura è la lettura stessa del corpus: Claude Fable 5.1 in solitaria è costato da $468 a $552 per episodio sulle tre impostazioni di effort, e solo la sua accuratezza si è mossa. La configurazione con coordinatore, un lead Claude Fable 5.1 sopra 25 worker Claude Sonnet 5, è costata circa la metà di quelle impostazioni (dal 47% al 55% in meno) e ha ottenuto da 10 a 12 punti in meno, in circa 2,3 ore per episodio contro 15-20, battendo nettamente una baseline Claude Sonnet 5 in solitaria:

La contabilità dei token mostra la scala della lettura: la configurazione con coordinatore ha letto circa 560 milioni di token in cache per episodio, circa una volta e mezza i circa 365 milioni del modello in solitaria, quasi tutti alla tariffa di lettura dalla cache di Claude Sonnet 5, ed è comunque costata circa la metà nel complesso. Fable 5.1 a effort high detiene ancora l'accuratezza di picco, a circa 2,2 volte il costo della configurazione con coordinatore, quindi qui la delega compra la maggior parte dell'accuratezza, non tutta.

Quando la delega non conviene. Un orchestratore compra qualcosa solo quando c'è massa da passare: molti pezzi indipendenti, idealmente troppi per una finestra di contesto. Quando il lavoro è una singola catena dipendente, o entra in un singolo contesto, l'orchestratore paga per un piano, un passaggio di consegne e un'unione che un singolo modello ottiene gratis. In ogni caso di questo tipo misurato, il modello del coordinatore da solo a effort più basso è risultato vincente.

Il confine è la difficoltà del compito, non il benchmark: sull'insieme completo e più difficile di BrowseComp⁴, Claude Fable 5 da solo ha raggiunto l'accuratezza della configurazione con coordinatore a un costo inferiore dal 22% al 30%. Lavori esterni indipendenti riportano lo stesso pattern⁵. Se il lavoro è una singola catena, entra in un contesto senza una lunga coda di costi, o un singolo modello a effort più basso soddisfa già il tuo standard, non costruire un orchestratore.

Scegli tra le strategie

La maggior parte dei casi si riduce a una domanda: il lavoro si divide in pezzi indipendenti, o è una singola risposta raggiunta attraverso una catena di passi dipendenti? La tabella delle strategie associa le due risposte alle due strategie.

Se non sei sicuro, non costruire ancora nulla:

1. Prova prima diversi livelli di effort sul tuo modello attuale. È l'esperimento più economico di questa pagina, e la maggior parte dei carichi di lavoro si ferma lì.
2. Se la prova mostra un divario, calcola il prezzo del modello più forte da solo a effort basso. Quello è il numero che un abbinamento advisor deve battere, e gli abbinamenti di questa pagina che lo hanno battuto sono stati quelli il cui esecutore ha effettivamente consultato.

I risultati multi-modello di questa pagina sono stati giudicati rispetto allo stesso modello a effort più basso e rispetto al modello immediatamente inferiore eseguito da solo. Quello è il confronto da eseguire sul tuo carico di lavoro, ed è il motivo per cui il primo passo è una prova dei livelli di effort.

Quando aggiungi un advisor, si tratta di una definizione di strumento piuttosto che di una riprogettazione dell'architettura.

Misura sul tuo carico di lavoro

I numeri di questa pagina riflettono i prezzi di listino al momento della misurazione e si sposteranno man mano che modelli e prezzi cambiano. Anche il tuo tasso di escalation, quanto nettamente si dividono i compiti e la lunghezza delle trascrizioni li spostano. Il metodo resta lo stesso:

1. Estrai alcuni compiti dai log di produzione, pesati come il traffico reale, e scrivi controlli di esito per ciascuno: i test passano, il ticket è chiuso, il conteggio delle righe è corretto. Registra il costo per compito accanto al punteggio: calcola il prezzo dei cinque conteggi di token tariffati nello usage di ogni risposta alle rispettive tariffe (input non in cache, scritture in cache da 5 minuti e da 1 ora a 1,25x e 2x il prezzo di input, letture dalla cache e output), sommati su tutte le richieste del compito (la Usage and Cost API riporta l'aggregato).
2. Stabilisci la baseline delle fasce di modello su tutti i livelli di effort, non solo quello predefinito, e traccia il punteggio rispetto alla spesa. Una configurazione multi-modello deve battere l'intera curva del modello singolo.
3. Se la curva mostra un divario che l'effort non può chiudere, aggiungi la strategia multi-modello adatta e riesegui la suite.
4. Esegui il vincitore in shadow su una porzione di traffico prima del passaggio, poi mantieni la suite in esecuzione.

L'esempio seguente calcola il costo del passo 1 di una richiesta ai prezzi di listino di Claude Opus 5:

# Prezzi per milione di token dalla pagina dei prezzi; modifica questi tre per un altro modello.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
# 0,1x il prezzo di input; 0,025x su Claude Fable 5.1 e Claude Mythos 5.1
CACHE_READ_PER_MTOK = 0.50
OUTPUT_PER_MTOK = 25.00

client = anthropic.Anthropic()
response = client.messages.create(
    model="claude-opus-5",
    max_tokens=1024,
    messages=[{"role": "user", "content": "Hello, Claude"}],
)
usage = response.usage
cache_writes = usage.cache_creation
writes_1h = cache_writes.ephemeral_1h_input_tokens if cache_writes else 0
writes_5m = cache_writes.ephemeral_5m_input_tokens if cache_writes else 0
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Le scritture in cache da 1 ora costano 2x il prezzo di input, da 5 minuti 1,25x; le letture al prezzo di lettura cache.
    + writes_1h * INPUT_PER_MTOK * 2.0
    + writes_5m * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * CACHE_READ_PER_MTOK
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

Nei loop agentici il termine di lettura dalla cache è di solito il più grande dei cinque; se non lo è, controlla che la cache sia attiva. Quando lo strumento advisor o la compattazione sono abilitati, alcuni token vengono riportati solo in usage.iterations e non nei totali di primo livello, quindi somma invece su usage.iterations, calcolando il prezzo delle voci advisor_message alle tariffe del modello advisor.

La tabella seguente elenca le leve nell'ordine in cui provarle:

Benchmark di riferimento

Salvo dove un riferimento indichi diversamente, le misurazioni sono esecuzioni interne di Anthropic di questi benchmark. Salvo diversa indicazione, i costi sono in USD ai prezzi di listino in vigore al momento dell'esecuzione di ciascun benchmark; i dati di Claude Sonnet 5 usano $2 e $10 per milione di token di input e di output. I grafici etichettati "notional USD" (USD nozionali) prezzano i conteggi di token di ciascuna richiesta a tali tariffe anziché riportare le fatture.

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. Attività di ricerca web ad ampio raggio valutate sulla completezza e accuratezza di una tabella con molte righe; 200 problemi, 3 esecuzioni per configurazione, eseguite dal 1° al 2 agosto 2026. Il grafico della concentrazione dei costi è un'esecuzione separata di 20 problemi, 3 esecuzioni per problema, eseguita dal 3 al 4 agosto 2026, con costi calcolati dai registri di fatturazione per richiesta.
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. Deliverable di lavoro intellettuale valutati rispetto a rubriche per attività; un'esecuzione di 210 attività del gold set rilasciato, un tentativo per attività, eseguita il 2 agosto 2026. La valutazione è effettuata da un modello Claude, quindi i punteggi assoluti possono differire dai risultati pubblicati.
3. SWE-bench Pro: Scale AI, "SWE-Bench Pro: Can AI Agents Solve Long-Horizon Software Engineering Tasks?", 2025. Un sottoinsieme di 482 problemi selezionato per compatibilità con l'harness di valutazione di Anthropic; i punteggi non sono confrontabili con la classifica pubblica. Claude Opus 5 all'effort predefinito è la media di due esecuzioni; le impostazioni a effort ridotto sono esecuzioni singole; tutte eseguite il 4 agosto 2026. I dati di escalation provengono attività per attività da quelle esecuzioni: prima low, poi il predefinito sui suoi fallimenti, ha risolto dal 92,5% al 93,6% tra gli abbinamenti di esecuzioni per circa $0,45; prima medium, dal 93,8% al 94,2% per circa $0,61; il predefinito rieseguito sui propri fallimenti, 94,0% per $1,06; tutto al predefinito, dal 90,9% al 92,5% per $0,93. I costi su questo sottoinsieme sono prezzati come viene misurata l'organizzazione di un cliente: il prompt precedente di ciascuna richiesta come lettura dalla cache e i suoi nuovi token come scrittura in cache da 5 minuti, dai registri di utilizzo delle esecuzioni stesse, verificati rispetto al registro contabile di un cliente; la misurazione propria dell'organizzazione di valutazione, che fattura la cache in pagine da 8.192 token, ha dato cifre da 1,4 a 1,8 volte superiori. Gli abbinamenti con esecutore Claude Sonnet 5 nel grafico dell'advisor provengono dalla stessa serie di misurazioni su questo sottoinsieme: l'abbinamento Sonnet-più-Opus è stato eseguito due volte (7 agosto e 8 agosto 2026, un'esecuzione e una replica esatta), l'abbinamento a basso effort una volta (8 agosto 2026) e Claude Sonnet 5 da solo due volte (77,4%, la baseline per entrambe le righe Pro). Il punto di Claude Fable 5 in Aggiorna il modello è la media di tre esecuzioni all'effort predefinito, eseguite il 26 agosto 2026, prezzate allo stesso modo. I dati sul task budget di Claude Fable 5.1 sono un'esecuzione per budget (due a 35.000 token) sullo stesso sottoinsieme all'effort predefinito, eseguite il 26 agosto 2026, con un'esecuzione senza budget lo stesso giorno (92,1%, $1,10 per attività) come baseline; un set precedente a effort low, eseguito il 21 agosto 2026, ha ottenuto l'88,6% senza budget a $0,48 per attività. Il confronto Confronta i modelli abbina quella singola esecuzione con le due esecuzioni aggregate di Claude Sonnet 5 dallo stesso sottoinsieme; all'effort predefinito di Fable 5.1 la coppia si legge al contrario, il 41% in più per attività risolta rispetto a Sonnet 5. La scala di aggiornamento è un'esecuzione per modello alle sue impostazioni predefinite di rilascio (due ciascuno per Opus 5 e Sonnet 5, e il punto Fable 5 come descritto sopra), con le esecuzioni Opus e Sonnet nella stessa settimana in un unico harness e un'unica organizzazione.
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. I dati sull'effort usano un taglio di 500 problemi, da una a tre esecuzioni per impostazione, eseguite il 3 agosto 2026, con il punto predefinito che aggrega due esecuzioni dal 26 al 27 luglio 2026. Il grafico dell'assicurazione sui costi usa 10 problemi risolti in modo affidabile da una porzione di 26 problemi, 50 esecuzioni delegate (dal 1° al 2 agosto 2026) e 70 esecuzioni in solitaria (50 dal 2 al 3 agosto 2026; 20 archiviate dal 12 al 13 luglio e dal 1° agosto 2026), $6,45 rispetto a $11,99 per esecuzione in valore atteso; i dati delegati hanno una banda di misurazione di circa il 20%.
5. Scalabilità dell'architettura degli agenti: Kim et al., "Towards a Science of Scaling Agent Systems," arXiv:2512.08296, 2025. Studio esterno indipendente, citato solo per la direzione del risultato su quando la delega non conviene, non per alcuna cifra.
6. DeepWideSearch: "DeepWideSearch: Benchmarking Depth and Width in Agentic Information Seeking," arXiv:2510.20168, 2025. Le 220 domande coprono 15 domini, ciascuna combinando la raccolta di molte righe con il recupero multi-hop; misurato sul set di righe permanente del benchmark, 3 esecuzioni per configurazione, eseguite il 2 agosto 2026 (il punto del team a singolo worker è stato eseguito dal 26 al 27 luglio 2026).
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. Le sue 132 attività di ricerca in 22 domini sono valutate rispetto a rubriche binarie derivate da esperti; misurato su un sottoinsieme di 50 attività stratificato su tutti i temi, un tentativo per attività, 3 esecuzioni per impostazione, su Claude Managed Agents con gli strumenti di ricerca web e fetch propri della piattaforma (dal 26 al 27 agosto 2026); punteggio calcolato sulle 33 attività che nessuna configurazione ha rifiutato, con i tentativi interrotti dai classificatori di sicurezza di produzione rimossi; i costi sono ciò che viene fatturato a un cliente, le richieste della piattaforma più le tariffe di ricerca web. I punteggi sono la media di ciascun modello sulla base delle 33 attività con le proprie attività interrotte rimosse; sulle 21 attività pulite in ogni braccio, Claude Fable 5.1 mantiene un vantaggio di 2-3 punti su Claude Fable 5 a ogni livello di effort ed entrambi i modelli sono piatti al variare dell'effort. Il grafico della cache riprezza le stesse richieste con ogni token di input alla tariffa senza cache. Claude Opus 4.6 giudica secondo il protocollo di rubrica del benchmark; l'originale usa un giudice diverso, e un giudice Anthropic potrebbe favorire lo stile della casa. Claude Opus 5 al suo effort predefinito è stato eseguito sulla stessa superficie e sullo stesso sottoinsieme, tre esecuzioni, il 28 agosto 2026: 68,8% sulle 50 attività grezze, 70,8% sulla base delle 33 attività e 71,1% sul set di 21 attività, a $6,71 per attività ($23,72 senza cache); nessuno dei suoi tentativi è stato interrotto dai classificatori di sicurezza, sotto un deployment di salvaguardie più recente di quello sotto cui sono stati eseguiti gli altri modelli.
8. Scansione dei difetti del corpus: Interno ad Anthropic, per lavori più grandi di una finestra di contesto: un corpus di 21,6 milioni di token da 14 sorgenti pubbliche di pacchetti Python con 130 difetti inseriti e valutazione deterministica; protocollo fissato prima delle esecuzioni e revisionato internamente; tre esecuzioni per configurazione. Ogni configurazione è stata eseguita su Claude Managed Agents. La configurazione del team nel grafico è un'esecuzione in cui il coordinatore Claude Fable 5.1 ha eseguito l'intera scansione all'interno della piattaforma al suo limite documentato di 25 worker Claude Sonnet 5 concorrenti, eseguita il 30 agosto 2026; i suoi tre episodi hanno ottenuto F1 0,764, 0,825 e 0,791 dopo l'audit degli extra (grezzi 0,751, 0,821 e 0,781) per $225, $234 e $283. La configurazione Claude Sonnet 5 in solitaria è stata eseguita dal 3 al 4 agosto 2026; le configurazioni Claude Fable 5.1 in solitaria sono state eseguite dal 24 al 25 agosto 2026, con le impostazioni di serving di lancio della piattaforma, tre seed per impostazione di effort, sulla stessa build del corpus. L'immagine della sandbox conteneva copie installate di parte del corpus, e il passaggio di assemblaggio finale di Claude Fable 5.1 le ha confrontate in 7 episodi su 9; la rivalutazione senza quelle aggiunte ha spostato i seed interessati fino a 3 punti. L'F1 assoluto è specifico di questa build del corpus, non confrontabile tra benchmark; i confronti tra configurazioni sono a parità di condizioni.
9. GPQA Diamond: Rein et al., "GPQA: A Graduate-Level Google-Proof Q&A Benchmark," 2023. Il sottoinsieme Diamond di 198 domande, due esecuzioni per configurazione, eseguite il 7 agosto 2026, valutate da modello rispetto alle risposte di riferimento, token dell'advisor misurati per richiesta. Un controllo di sicurezza della piattaforma ha rifiutato due domande di biologia sugli esecutori Sonnet e Opus; escluderle non cambia alcun confronto di più di un punto.
10. DeepSWE: Datacurve, "DeepSWE: Measuring Frontier Coding Agents on Original, Long-Horizon Engineering Tasks," arXiv:2607.07946, 2026. Il set ha 113 attività originali in cinque linguaggi con verificatori basati su programmi. Gli abbinamenti sono due esecuzioni ciascuno, eseguite il 7 agosto 2026, con token dell'advisor misurati per richiesta, e hanno usato un ciclo advisor lato client anziché lo strumento advisor, con contabilità identica. Le variazioni di effort a modello singolo sono esecuzioni singole prezzate dai conteggi di token, un'approssimazione che tiene conto della cache. I costi per attività sono i totali delle esecuzioni divisi per 113.
11. Benchmark interno di coding agentico: Interno ad Anthropic: 370 attività su repository valutate dai test propri dei repository. I dati API sono stati misurati con un limite di output di 128.000 token, un'esecuzione per configurazione: Opus 5 da solo all'effort predefinito dal 9 al 10 agosto 2026, Claude Fable 5.1 da solo a cinque valori di effort impostati esplicitamente il 20 agosto 2026, e l'abbinamento dal 24 al 25 agosto 2026. Tentativi per attività: cinque per l'abbinamento e il controllo Opus da solo, uno per i punti a modello singolo; l'abbinamento ha avuto in media circa due consultazioni dell'advisor per tentativo; i costi sono per tentativo. I dati di Claude Code sono esecuzioni delle stesse attività dall'8 al 23 luglio 2026, un'esecuzione per configurazione, costi approssimativi.
12. Benchmark interno di attività su repository (misurazione del limite): Un set separato interno ad Anthropic di circa 130 attività su repository, eseguito dall'8 al 10 agosto 2026 (Claude Opus 5) e il 20 agosto 2026 (Claude Fable 5.1), con un semplice ciclo agente API, un tentativo per attività. Le esecuzioni di Claude Fable 5.1 sono 135 attività per limite all'effort predefinito impostato esplicitamente: il dato a 16.384 token è la media di due esecuzioni (36,3% in entrambe); i dati a 64.000 e 128.000 sono esecuzioni singole (58,5% e 60,0%). Sei problemi hanno ricevuto un rifiuto di sicurezza in ogni esecuzione e contano come fallimenti. Il dato di Opus 5 a 16.384 token è la media di due esecuzioni e il suo dato a 64.000 è un'esecuzione singola (124 attività valutate). I dati sul limite di SWE-bench Pro sono un'esecuzione di Claude Fable 5.1 per limite all'effort predefinito, eseguita il 26 agosto 2026, su un sottoinsieme di 100 problemi stratificato dal set di 482 problemi del riferimento 3, non confrontabile con i suoi punteggi; i due limiti hanno ottenuto lo stesso punteggio al predefinito. Le distribuzioni per turno del grafico provengono dall'esecuzione Opus a 64.000 e dall'esecuzione Claude Fable 5.1 a 128.000; nessun turno Opus ha raggiunto il suo limite, e un turno Fable 5.1 ha raggiunto 128.000 (lo 0,46% dei suoi turni ha superato 16.384).
13. Chartography: Surge AI, "Chartography," 2026. Il set completo rilasciato di 100 domande, misurato dall'8 al 10 agosto 2026, con l'implementazione di Anthropic su Claude Managed Agents (sandbox cloud standard; le configurazioni advisor usano l'advisor di Managed Agents). Claude Sonnet 4.6 valuta al posto del giudice di riferimento e il benchmark viene eseguito con strumenti, quindi i punteggi sono confrontabili tra configurazioni qui ma non con la classifica pubblicata. Due esecuzioni per configurazione, aggregate; le variazioni tra esecuzioni erano da 4 a 10 punti. I costi escludono il tempo di sandbox, che ha aggiunto meno dell'1%. Le esecuzioni di Claude Fable 5.1 in solitaria sono del 24 agosto 2026, con le impostazioni di serving di lancio della piattaforma, due esecuzioni per impostazione; sei tentativi hanno raggiunto il limite di sessione di 15 minuti e ottengono 0, e due grafici per esecuzione hanno ricevuto risposta da Claude Opus 5 dopo un rifiuto di sicurezza. L'esecutore Claude Opus 5 a basso effort con un advisor Claude Fable 5.1 è stato eseguito due volte il 30 agosto 2026, con le stesse impostazioni (63,0 e 67,0, media 65,0, a $0,72 per grafico; l'advisor è stato consultato nell'88% delle attività in ciascuna esecuzione, e 4 delle sue 219 risposte sono invece arrivate da Claude Opus 5, ciascuna dopo che un filtro di sicurezza di produzione ha bloccato la risposta propria dell'advisor). Il confronto del tasso di consultazione per gli abbinamenti precedenti proviene dalla riesecuzione delle stesse configurazioni sulla Messages API con un set di strumenti container, dal 10 all'11 agosto 2026.
14. Valutazione di audit dei prompt per support desk: Un set costruito da Anthropic di 44 ticket di supporto con valutazione deterministica, eseguito all'inizio di agosto 2026 e riportato l'8 agosto 2026, con sei prompt di sistema, ciascuno dei quali aggiunge allo stesso prompt pulito un pattern comune nei prompt scritti per Claude Opus 4.8 e Claude Sonnet 4.6. Ogni punto del grafico è uno di tre casi (modello più vecchio, modello più nuovo sullo stesso prompt, modello più nuovo dopo l'audit) mediato sui sei prompt e sui 44 ticket. Il guadagno di accuratezza di Opus 5 ha un intervallo di confidenza al 95% da 3 a 8 punti; le differenze di accuratezza di Sonnet rientrano nel rumore.
15. Set di domande su file di dati: Un set costruito da Anthropic di 25 domande aggregate su una porzione di 1.862 righe di un CSV pubblico di vendite di liquori, con ground truth calcolata da pandas e valutazione a corrispondenza esatta, eseguito su Claude Sonnet 5 e Claude Opus 5 con il thinking disabilitato (il braccio in-context non può completare al predefinito), un limite di output di 4.000 token e nessuna cache dei prompt, tre esecuzioni per configurazione, eseguite il 19 agosto 2026. Il braccio file carica il CSV tramite la Files API e usa lo strumento code_execution_20260120.
16. Misurazione della durata della cache: Il lavoro di triage di 20 issue da Riduci i token di input e di contesto, eseguito il 23 agosto 2026, su Claude Sonnet 5 e Claude Opus 5 sulla Messages API con lo stesso harness, le celle Claude Opus 5 con max_tokens alzato a 4.096, con pause inserite prima di una quota di turni scelta casualmente (nessuna, 5%, 10% e ogni turno a 6 minuti su tutte le 20 issue su entrambi i modelli, più ogni turno a 2 minuti su Claude Sonnet 5; pause di 20 minuti su un sottoinsieme di 5 issue su entrambi i modelli; pause di 45 minuti su un sottoinsieme di 5 issue solo su Claude Sonnet 5). Tre esecuzioni per cella, costo calcolato dai campi usage di ciascuna risposta su un'organizzazione fatturata come cliente ai prezzi di listino, accuratezza rispetto alle stesse etichette gold. Il punto di incrocio è circa il 3,3% dei turni su entrambi i modelli: la mediana della quota di pareggio di ciascuna sessione, calcolata dal modello di costo a partire dalle dimensioni del contesto turno per turno di quella sessione, su tutte le 45 sessioni da venti issue di Claude Sonnet 5 e le 36 di Claude Opus 5 nell'analisi (ogni programma di pause eseguito sul lavoro completo, con tutte e tre le impostazioni di cache, tre esecuzioni ciascuna; le celle da 5 issue non vi sono incluse). La cella al 5% ha pareggiato su Claude Sonnet 5 perché le pause di quell'estrazione sono cadute su prefissi piccoli. La regola di 1 su 20 della pagina si colloca sopra il punto di incrocio misurato. Anthropic ha misurato le richieste keep-alive che rinfrescano la cache da 5 minuti solo come termine di confronto. Al massimo hanno eguagliato l'impostazione da 1 ora e sono costate di più con una pausa prima di ogni turno, quindi non usarle su questi due modelli; su Claude Fable 5.1 l'aritmetica si inverte (riferimento 19).
17. Quota di letture dalla cache in produzione: Utilizzo aggregato first-party della Claude API per i 14 giorni terminati il 23 agosto 2026, solo prodotto API diretto, organizzazioni interne ad Anthropic escluse, nessuna organizzazione identificata. Un giorno-organizzazione conta come ciclo agente quando le sue richieste contengono definizioni di strumenti e risultati di strumenti, i suoi prompt contengono in media 9 o più chiamate di strumenti precedenti, è stata usata la cache e ha effettuato almeno 10 richieste di questo tipo (l'API non ha un identificatore di conversazione, quindi questo fa da sostituto della lunghezza della conversazione): 303.003 giorni-organizzazione su 106.487 organizzazioni, quota mediana di letture dalla cache 84,2% di tutti i token di input, quartile superiore 91,7%. Le etichette di caso d'uso (il caso d'uso dichiarato dall'organizzazione, o altrimenti quello classificato) coprono il 74% di quei giorni-organizzazione e il 99% dei loro token; le organizzazioni di coding forniscono l'87% dei token di input agentici e leggono una mediana dell'88,5% (90,9% a 25 o più chiamate di strumenti precedenti), quartile superiore 93,4%, con circa il 72% dei giorni-organizzazione di coding all'80% o più; gli agenti di supporto, ricerca e dati leggono dall'84% all'85%. Il decile superiore dei giorni-organizzazione legge il 95,9% o più per il coding e dal 94,2% al 94,8% per supporto, ricerca, dati e altri agenti. La suddivisione a livello di richiesta a 25 o più chiamate di strumenti precedenti proviene da un campione di sei ore: coding 92% letture, 7% scritture, meno dell'1% senza cache. Le organizzazioni non etichettate, per lo più piccole, leggono una mediana dell'11%. I giorni-organizzazione senza definizioni di strumenti leggono una mediana del 34,6%. Una query indipendente sulla stessa finestra che ricostruisce conversazioni di 10 o più richieste, anziché valutare i giorni-organizzazione, colloca la mediana al 90,2%; la differenza è di ambito, non di dati.
18. Misurazione della tempistica di compattazione: La variante lunga dell'agente di triage da Riduci i token di input e di contesto, eseguita il 24 agosto 2026, su Claude Sonnet 5 con la cache da 5 minuti, costo dai campi usage ai prezzi di listino, cinque sessioni per braccio: un braccio senza modifiche all'effort predefinito per tutta la durata ($0,81 per sessione), e due bracci che iniziano a basso effort e apportano le stesse due modifiche che invalidano la cache, un passaggio all'effort predefinito e uno strumento aggiunto, o a metà sessione alle richieste 12 e 17 ($0,95) o insieme alla prima richiesta dopo la prima compattazione ($0,75). Un quarto braccio di sei sessioni, eseguito il 25 agosto 2026, ha apportato le stesse due modifiche alla richiesta che ha attivato la prima compattazione ($0,92 per sessione): il passaggio di riepilogo di quella richiesta ha scritto il contesto di 81.000 token nella cache invece di leggerlo, quindi quel passaggio è costato $0,21 contro $0,04 per lo stesso passaggio nel braccio al confine. Le sessioni hanno compattato per la prima volta alla richiesta da 21 a 25 (16 delle 21 sessioni alla richiesta 22), una volta che il prompt ha superato la soglia di compattazione di 80.000 token, e due sessioni senza modifiche hanno compattato una seconda volta verso la fine. Il totale inferiore del braccio al confine rispetto al braccio senza modifiche riflette le sue richieste a basso effort prima della modifica e quelle seconde compattazioni piuttosto che la cache: i costi di riscrittura dei due bracci differiscono di meno di un centesimo. Il braccio a metà sessione ha pagato $0,23 per sessione in riscritture della cache; la differenza tra i bracci a metà sessione e al confine era di $0,20 con un intervallo di confidenza al 95% da $0,11 a $0,29. Una sessione a metà sessione è risultata economica ($0,82) dopo che il suo modello ha chiamato erroneamente lo strumento di ricerca in seguito alla compattazione e ha ottenuto risultati vuoti; è inclusa, e senza di essa il braccio ha una media di $0,98. L'accuratezza è stata in media di 14,2 etichette su 20 in ciascun braccio del 24 agosto e di 14,7 nel braccio del 25 agosto; le letture dalla cache erano il 91% dei token del prompt senza modifiche, l'85% a metà sessione, il 91% al confine e l'86% con le modifiche sulla richiesta di attivazione.
19. Misurazione della durata della cache su Claude Fable 5.1: Lo stesso lavoro di triage di 20 issue e lo stesso harness del riferimento 16, eseguiti il 23 agosto e il 26 agosto 2026, sullo snapshot di lancio di Claude Fable 5.1 ai suoi prezzi di lancio ($10 input, $12,50 scrittura da 5 minuti, $20 scrittura da 1 ora, $0,25 lettura dalla cache, $50 output per milione di token), tre impostazioni per programma: la cache da 5 minuti, la cache da 1 ora e la cache da 5 minuti mantenuta calda da una richiesta max_tokens: 0 sul prefisso invariato ogni 4 minuti di inattività (le esecuzioni del 23 agosto hanno effettuato ping con max_tokens: 1; ogni ping del 26 agosto ha rinfrescato la cache e non ha fatturato output). Programmi: nessuna pausa, 10% dei turni e ogni turno a 6 minuti su tutte le 20 issue, e pause di 45 minuti sul sottoinsieme di 5 issue; tre esecuzioni per cella, costo calcolato dai campi usage di ciascuna risposta ai prezzi di listino, accuratezza rispetto alle stesse etichette gold (da 12 a 17 etichette esatte su 20). Medie per sessione del 26 agosto per le impostazioni da 5 minuti, da 1 ora e keep-alive: nessuna pausa $2,42, $3,09, $2,29; 10% in pausa $4,50, $2,96, $2,36; ogni turno $22,89, $3,01, $2,62; le celle del 23 agosto concordano entro il 6%. I dati a 45 minuti ($1,68, $0,59 e $0,71 per sessione da 5 issue) provengono da una riesecuzione pulita del 26 agosto dopo che un incidente di fatturazione della cache ha compromesso le prime celle di quel giorno; le esecuzioni del 23 agosto hanno dato $1,67, $0,58 e $0,70. Il punto di incrocio tra le impostazioni da 5 minuti e da 1 ora è il 3,1% dei turni, la stessa misura del riferimento 16.
20. Terminal-Bench 3: le 74 attività del benchmark pubblico per agenti da terminale, eseguite su Claude Managed Agents con due strumenti personalizzati, una shell e un editor di file che l'harness di valutazione esegue nel container proprio di ciascuna attività, al posto degli strumenti integrati della piattaforma, e per il resto alle impostazioni predefinite della piattaforma per gli account esterni, due esecuzioni per modello a effort high, dal 27 al 28 agosto 2026. I punteggi sono tassi di superamento grezzi sui 148 tentativi per modello; le singole esecuzioni oscillano da 5 a 11 punti. I costi sono ciò che verrebbe fatturato a un cliente ai prezzi di listino, riprezzati richiesta per richiesta dai registri di utilizzo delle esecuzioni con la durata della cache da 5 minuti. Claude Opus 4.7 ha terminato 11 dei suoi 148 tentativi al suo limite di output.

Prossimi passi