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" (impegno) e l'architettura per ogni richiesta, il che ti permette di collocare un carico di lavoro quasi ovunque sulla frontiera costo-intelligenza.

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, e architetture multi-modello.

Ogni leva è accompagnata da risultati misurati e dalla regola per capire 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,5 a 3,7 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 dato risultati in due forme, un advisor e un orchestrator.



Inizia 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. Si applicano due avvertenze: l'elaborazione batch scambia la latenza con il suo sconto, e il context editing, 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

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 viene fatturato alla tariffa di lettura dalla cache, un decimo del prezzo di input, e ogni turno paga la tariffa di scrittura in cache di 1,25x solo per ciò che è nuovo.

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

La durata predefinita della cache è di 5 minuti e i turni di un ciclo di agente sono distanti pochi secondi, quindi lo sconto si applica alla maggior parte dei token a ogni turno; le esecuzioni nel grafico hanno raggiunto tassi di hit dall'81% al 90%. 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.

Se il tuo ciclo attende gli umani tra un turno e l'altro, usa la durata della cache di 1 ora. Costa di più in scrittura (2x il prezzo di input invece di 1,25x) ma si ripaga al primo miss evitato, perché un miss reinvia l'intero prefisso a prezzo pieno e lo scrive di nuovo.

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 con 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.
...

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

Tre impostazioni possono invalidare la tua cache durante un'attività. Cambiare effort tra le richieste invalida il prefisso in cache, quindi cambialo solo dove rimetteresti comunque in cache, come a un confine di compaction. Cambiare un task budget a metà percorso fa lo stesso, quindi impostalo una volta, alla prima richiesta. Ogni passaggio di context editing invalida il prefisso dal punto in cui cancella e la richiesta successiva paga per rimettere in cache tutto ciò che segue, quindi cancella in pochi grandi lotti piuttosto che in molti piccoli. Apporta tutte e tre le modifiche in corrispondenza di interruzioni naturali, poi conferma che le letture dalla cache non siano diminuite; 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 trasporta token che non influenzano mai la risposta. Tagliarli non costa nulla in qualità dell'output, anche se non tutte le leve qui hanno fatto risparmiare denaro quando misurate. Due punti in cui 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 visivi, e la ricerca di strumenti con caricamento differito carica le definizioni degli strumenti solo quando necessario. La chiamata programmatica degli strumenti permette a Claude di eseguire diverse chiamate di strumenti dal codice in modo 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 di 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 compaction automatica con la sua soglia impedisce ai cicli lunghi di portarsi dietro l'intera cronologia.

Le leve interagiscono con la cache e tra loro, quindi giudicale in base all'effetto netto, e usa la diagnostica della cache per confermare che il tuo prefisso in cache sopravviva a ogni modifica. Anthropic ha attivato le leve una alla volta per un agente di triage delle issue che lavorava su 20 segnalazioni di bug reali con screenshot da un repository pubblico (e, per il secondo pannello, una variante più lunga dello stesso lavoro):

La cache ha fatto quasi tutto il lavoro, e il taglio ha portato il totale all'88%. Ogni barra è una singola esecuzione, quindi differenze di $0,10 sono rumore; quelle mostrate qui non lo sono. La compaction richiede una sessione abbastanza lunga da attivarla: l'esecuzione da 20 issue non ha mai raggiunto la soglia minima di 50.000 token una volta tagliati i suoi input, ma sulla variante più lunga del secondo pannello si è attivata una volta e ha ridotto la fattura di un ulteriore 38%.

Il context editing è l'unica leva qui che non è gratuita. Ogni passaggio di cancellazione riscrive la conversazione in cache, il che lavora contro la cache dei prompt; in questa esecuzione, il context editing è costato più di quanto ha fatto risparmiare. Usalo per fare spazio nella finestra di contesto, e cancella in pochi grandi lotti.



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 attraverso un batch ogni richiesta che nessuno sta aspettando, e mantieni il percorso interattivo per il resto. Il batching è la seconda leva gratuita più grande dopo la cache per il lavoro non presidiato degli agenti: 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 ciò che è 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 tipico è 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ù recente le segue alla lettera, producendo round di strumenti extra e scrittura extra, quindi la fattura sale senza alcun 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 singolo 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 segnala ciò che è stato scritto per un modello diverso. Questo estratto abbreviato lo mostra eseguito su un prompt di support desk e codice di richiesta contenente questi 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 ciò che ha deliberatamente lasciato invariato: la finestra di rimborso, il requisito di tono e lo standard 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, rispetto al 92%, un guadagno al di fuori del rumore). Nella 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 di un terzo il costo per ticket di Opus 5, 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 compaiono nelle descrizioni degli strumenti e nelle skill, e vale la pena rimuoverli anche lì.



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 i 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 (il modello di frontiera); la 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 è diverse volte quello di Claude Sonnet 5. Tuttavia paghi per attività completate, quindi confronta i modelli sul costo per attività completata. Un modello più capace termina un'attività con meno lavoro: meno turni, meno ricerche, meno riletture del proprio contesto e meno ritorni sui propri passi. Il sovrapprezzo per token viene abitualmente sopraffatto dal fare meno di tutto.

Anthropic ha misurato questo direttamente su DeepResearch Bench II⁷, un benchmark di report di ricerca abbastanza difficile da separare i modelli:

Il modello di frontiera a effort low è stato più accurato e circa il 10% più economico per attività rispetto al modello di fascia media, nonostante il divario per token. Non vince sempre, però. Sul sottoinsieme di SWE-bench Pro³ di questa pagina, 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 da solo (91,7% rispetto a 91,3%, entro il rumore tra esecuzioni) a circa il 60% del suo costo. Su lavori più difficili, come le attività di DeepResearch Bench II, il vantaggio di Fable riappare.

Per la maggior parte dei carichi di lavoro degli agenti, inizia con Claude Opus 5: per token costa la metà di Fable 5 e 2,5 volte Sonnet 5, e su quel sottoinsieme di coding ha eguagliato l'accuratezza di Fable. 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 un'accuratezza del 63% rispetto al 92% di Opus, ed è rimasto molto più indietro sulle attività di coding lunghe. È adatto a lavori 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 costo 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 costo 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 di WideSearch¹ da 20 problemi, due problemi hanno rappresentato 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.



Regola l'effort

L'effort è il modo più diretto per regolare un modello sulla tua attività. Il parametro effort governa quanto thinking, chiamate di strumenti e auto-verifica il modello esegue, e il valore predefinito (high) è adatto ad attività impegnative. Il costo scala con tutta quell'attività; l'accuratezza scala solo con la parte di cui la tua attività ha bisogno. Al di sotto del tetto del modello, i livelli di effort più alti pagano per una profondità che l'attività non usa mai.

Sui benchmark di ricerca e lavoro di conoscenza (WideSearch¹, DeepWideSearch⁶, BrowseComp⁴ e GDPval², tutti con Claude Fable 5), la curva dell'accuratezza rispetto al costo è quasi piatta: low ha ceduto da 1 a 3 punti per un terzo fino a metà di sconto sul costo per attività, medium ha eguagliato l'accuratezza del valore predefinito al 70%-85% 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 orchestrator con un worker Claude Sonnet 5 a un costo inferiore del 20%: abbassare l'effort ha battuto un cambio di architettura.

Le impostazioni più basse sono anche più veloci, il che conta quando la latenza è il vincolo. In queste esecuzioni, low ha impiegato 4,5 minuti per problema su DeepWideSearch, rispetto a 7,9 minuti al valore predefinito. Sul benchmark del corpus, il cui input non entra in nessuna singola finestra di contesto, Fable 5 ha impiegato 7,9, 9,1 e 11,4 ore per episodio a low, medium e al valore predefinito.

Il coding a lungo orizzonte è l'altra forma. Su SWE-bench Pro³, Claude Opus 5 ha ceduto circa 2 punti a medium per metà del costo e circa 8 punti a low per un quarto di esso: un vero compromesso, che la riesecuzione dei fallimenti a effort più alto trasforma di nuovo in un risparmio. Questo grafico traccia l'accuratezza rispetto al costo per i benchmark di ricerca e lavoro di conoscenza 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 effort inferiore. Secondo, questa curva è la baseline a singolo modello che qualsiasi strategia multi-modello deve battere, quindi il passaggio 2 della misurazione sul tuo carico di lavoro stabilisce la baseline attraverso i livelli di effort.

Un effort inferiore costa effettivamente accuratezza sui carichi di lavoro che raggiungono il tetto del modello, dove l'accuratezza scala genuinamente con la profondità del ragionamento. Su DeepResearch Bench II⁷, dove ogni report premia il ragionamento profondo per sottoargomento, ogni gradino di effort ha comprato circa 2,4 punti di punteggio della rubrica; non c'è alcun taglio di costo gratuito su quella curva:

La sola descrizione dell'attività non rivela quale tipo di carico di lavoro hai, quindi esegui uno sweep di 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 a metà sessione invalida la cache (vedi Metti in cache il contesto ripetuto) e distorce il confronto. Per i dettagli del parametro, vedi Effort.



Riesegui i fallimenti a effort più alto

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

Anthropic ha calcolato questa politica attività per attività dalle esecuzioni di effort sul sottoinsieme di SWE-bench Pro³ in Regola l'effort. Con Claude Opus 5 a low, il 16% delle attività è fallito; con quelle rieseguite al valore predefinito, circa il 93% è passato per circa $0,70 ciascuna, contro il 91,7% per $1,39 eseguendo tutto al valore predefinito: lo stesso tasso di successo per metà del costo, contando i tentativi economici falliti. Partire invece da medium ha risolto circa il 94% per circa $0,95. La maggior parte del piccolo incremento è il secondo tentativo (rieseguire i fallimenti del valore predefinito stesso al valore predefinito ottiene circa lo stesso punteggio, per più denaro), quindi usa questa politica per il risparmio, non per l'incremento:

Si applicano due condizioni. Primo, hai bisogno di un segnale di fallimento (qui, i test propri del benchmark); un verificatore che fa passare lavoro scadente lascia passare quei fallimenti. Secondo, ogni fallimento al primo passaggio richiede il tempo reale di due esecuzioni, quindi il risparmio viene pagato in latenza sui fallimenti.



Imposta budget e limiti di output

La maggior parte delle esecuzioni di attività agentiche è economica, ma una minoranza spende molte volte il costo mediano in ricerche, ri-verifiche e test eccessivi. Un "task budget" (budget per attività) prende di mira quella coda. Il modello vede un conto alla rovescia dei token in tempo reale per l'intera attività 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 attività su SWE-bench Pro³ con Claude Fable 5 man mano che il budget si restringeva:

Un budget generoso ha ceduto circa 2,7 punti di tasso di successo per un risparmio di costo del 18%, e il budget più stretto consentito ha ceduto 4,4 punti per un risparmio del 47%. I budget qui hanno comprato efficienza, non accuratezza.

Tre controlli svolgono tre lavori diversi. Un task budget fa risparmiare denaro, perché il modello lo vede. max_tokens è un limite di sicurezza che non fa risparmiare nulla. Su Claude Managed Agents, un budget di sessione è lo stop 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 rete di sicurezza finale.

• I task budget sono in beta (header beta task-budgets-2026-03-13) su Claude Opus 5, Claude Fable 5, Claude Opus 4.8 e Claude Opus 4.7, ma non su Claude Sonnet 5; controlla prima la tabella di supporto. Inizia vicino all'utilizzo di token al 90° percentile del tuo ciclo, 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 al rifiuto. Imposta il budget una volta, alla prima richiesta, perché una modifica a metà attività invalida la cache. Il budget è consultivo, guida il modello piuttosto che 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 dello spazio vengono scartati e comunque fatturati. Su un benchmark interno di attività su repository¹², un limite di 16.384 token ha terminato il 15% dei tentativi di Claude Opus 5 e un terzo di quelli di Claude Fable 5, nessuno dei quali risolto. Le esecuzioni limitate hanno speso meno per tentativo ma hanno comprato proporzionalmente meno soluzioni, quindi il costo per attività risolta è stato lo stesso che a 64.000. A quell'impostazione nulla è stato troncato, e Fable ha risolto il 54,6% delle attività invece del 36,6% sui problemi valutati da entrambe le esecuzioni (su un taglio separato del sottoinsieme di SWE-bench Pro³, descritto nel riferimento 12, il 92% invece del 90%). Ritentare i tentativi limitati aggiunge solo costo: allo stesso limite non hanno mai avuto successo, e a uno più alto paghi anche per il tentativo sprecato. Imposta max_tokens a 64.000 per il lavoro agentico (128.000, il massimo, a effort xhigh o max), trasmetti in streaming le risposte così grandi, tratta stop_reason: max_tokens come un fallimento, e risparmia denaro con effort e task budget, che il modello può vedere.
• I budget di sessione su Claude Managed Agents sono lo stop rigido. Un budget di sessione è un limite in dollari su una sessione alle tariffe di listino per token, ricerche e tempo di sessione. Al raggiungimento del limite, la sessione si mette in pausa con stop_reason: budget_reached; aumentare il budget la riprende. È applicato dalla piattaforma, funziona su qualsiasi modello con un prezzo di listino (incluso Claude Sonnet 5) e si combina con il task budget consultivo. I deployment applicano lo stesso campo a ogni esecuzione.

Il primo dei due grafici su max_tokens traccia il costo per tentativo e per attività risolta a ogni limite:

Il secondo traccia la lunghezza dell'output per turno rispetto ai limiti:



Combina i modelli

Le architetture multi-modello si adattano a carichi di lavoro la cui complessità delle attività varia abbastanza da far sì che passaggi 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 passaggi 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 miscela, perché la sua difficoltà è uniforme o è una singola catena dipendente, un singolo modello ben regolato è di solito la scelta migliore. Ogni sezione di strategia 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 ciclo principale:



Strategia advisor: escalare le decisioni difficili

Nella strategia "advisor" (consulente), un modello executor (esecutore) a costo inferiore esegue il ciclo dell'agente e svolge la maggior parte dei turni. Quando incontra una decisione che richiede un giudizio più approfondito, come scegliere un approccio o riprendersi da un fallimento, chiama un modello advisor a intelligenza superiore per ottenere una guida strategica, poi prosegue. La maggior parte dei token viene fatturata alle tariffe dell'executor, 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 singola richiesta /v1/messages: l'executor emette una chiamata a uno strumento, Anthropic esegue l'inferenza dell'advisor e l'executor prosegue con il consiglio ricevuto; non scrivi alcun codice di orchestrazione. Su Claude Managed Agents, assegna un advisor alla sessione aggiungendo una voce advisor al roster multiagent dell'agente; il thread principale della sessione lo consulta allo stesso modo. Anche Claude Code lo supporta; consulta escalare le decisioni difficili con lo strumento advisor.

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

Il primo è il divario tra i modelli. L'advisor può trasferire solo le capacità che mancano all'executor: su GPQA Diamond⁹ un executor Claude Haiku 4.5 ha guadagnato moltissimo da un advisor Claude Opus 5, un executor Claude Sonnet 5 ha guadagnato qualche punto e un executor di frontiera quasi nulla.

Il secondo, quello fragile, è se l'executor chiede effettivamente (il tasso di consultazione). Un executor a basso effort può smettere di accorgersi di essere bloccato: un abbinamento che consulta sulla maggior parte dei compiti all'effort predefinito può scendere a non consultare quasi mai quando l'effort viene abbassato, e a quel punto ottiene punteggi inferiori all'executor da solo. Il tasso varia anche in base al compito: su DeepSWE¹⁰ un executor Sonnet 5 a basso effort ha continuato a chiedere e ha guadagnato 23 punti; su SWE-bench Pro³ lo stesso executor ha smesso. Quando l'executor chiede, arriva quasi fino in fondo. Negli abbinamenti del grafico seguente, l'advisor ha colmato dal 60% al 90% del divario rispetto al modello più forte, mentre quel modello veniva pagato solo per le consultazioni, il che rende possibili i casi di risparmio sui costi:

Il tasso di consultazione risponde al prompting. Con la sola descrizione integrata dello strumento, gli executor chiamano troppo poco, specialmente nel lavoro di programmazione, quindi la documentazione dello strumento advisor fornisce un "system prompt" (prompt di sistema) che richiede una chiamata prima del lavoro sostanziale e una prima di concludere, circa due o tre chiamate per compito. L'abbinamento di programmazione misurato di seguito ha funzionato a quella cadenza, circa due consultazioni per ogni compito. Quella pagina tratta anche come sollecitare un executor che chiama troppo poco e come limitare le chiamate lato client per contenere i costi. Quindi tieni d'occhio il tasso di consultazione: richiedilo nel prompt, misuralo e ripristina l'effort dell'executor 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'executor, quindi la configurazione più conveniente è un advisor di frontiera sopra un executor di fascia media. Un abbinamento può reggere il confronto anche nella parte alta della gamma, perché il consiglio fa risparmiare anche token dell'executor: un executor 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 executor Claude Opus 5 con un advisor Claude Fable 5 è stata la configurazione più accurata misurata: 85,7% dei tentativi risolti per $8,40 per tentativo. Si colloca sopra la linea che attraversa le impostazioni di effort di ciascun modello, ma solo di un punto o due rispetto alla migliore di esse (Opus da solo all'impostazione predefinita, 84,4% per $8,50, e Fable da solo a medium, 83,4% per $8,20), differenza che una singola esecuzione non distingue dal rumore. Fable da solo a effort medium raggiunge circa la stessa accuratezza dell'abbinamento (83,4% rispetto a 85,7%) per circa la stessa spesa ($8,20 rispetto a $8,40 per tentativo):

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, non come un risparmio: nella parte alta della gamma l'advisor compra un po' di accuratezza al prezzo di frontiera, e il caso di risparmio sui costi appartiene agli abbinamenti con un divario di capacità più ampio, come il seguente caso di lettura di grafici. Il costo in latenza sono le consultazioni stesse: circa due chiamate aggiuntive al modello di frontiera per compito su questo benchmark, ciascuna sul percorso critico del compito.

Quando conviene invece di aumentare l'effort. Dove il divario di capacità è più ampio e l'accuratezza di un carico di lavoro risponde all'effort, un executor a basso effort che consulta un advisor può essere un passo avanti più economico rispetto ad aumentare l'effort dell'executor stesso, perché l'advisor viene pagato solo sui compiti che ne hanno bisogno.

Su Chartography¹³, un benchmark pubblico di lettura di grafici eseguito su Claude Managed Agents con il suo advisor, un executor Claude Opus 5 a effort low con un advisor Claude Fable 5 ha ottenuto 67,5 per $0,60 per compito. Questo è sopra la linea che attraversa le impostazioni di effort di ciascun modello (Opus da solo è passato da 49 a 75 tra low e medium per $0,38 a $0,94), sebbene le impostazioni medium e predefinita dell'executor stesso detengano ancora i punteggi più alti, a 1,6 e 3,3 volte il prezzo:

L'executor a basso effort ha consultato l'advisor nell'86% dei compiti, la condizione che l'abbinamento su SWE-bench Pro non è riuscito a soddisfare. Misura il tasso di consultazione nel tuo ciclo dell'agente prima di fare affidamento su questa configurazione.

Qualunque sia l'abbinamento, calcola prima il prezzo del modello dell'advisor da solo a basso effort; 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 multistep. 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 executor è già vicino alla capacità dell'advisor.



Strategia orchestrator: delegare il lavoro di massa

Nella strategia "orchestrator" (orchestratore), il modello di frontiera tiene il ciclo. Scompone il compito, distribuisce i sottocompiti a modelli worker (lavoratori) a costo inferiore e unisce i loro risultati. La trascrizione dell'orchestrator rimane breve perché i worker assorbono l'esplorazione pesante in termini di 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'orchestrator) e un roster di agenti worker, ciascuno con il proprio modello. Per un esempio funzionante completo con un coordinatore Claude Fable 5 e worker Claude Sonnet 5, consulta 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 essere eseguiti in parallelo: sul benchmark del corpus⁸, un episodio ha richiesto poco più di 2 ore con il coordinatore che eseguiva il limite documentato della piattaforma di 25 worker concorrenti, rispetto a 11,4 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 inferiore è stato ogni volta più economico.

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

Anthropic ha misurato questo 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 poco meno della metà di Fable da solo e circa un terzo al 90° percentile ($12 rispetto a $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 orchestrator 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 "context window" (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 ad alta intensità di lettura che rientra comunque in una finestra di contesto è un problema di scelta del modello, non di delega: sul solo costo di lettura, l'orchestrator 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 in solitaria è costato da $720 a $764 per episodio a ogni impostazione di effort, e solo la sua accuratezza è cambiata. La configurazione con coordinatore è costata oltre il 60% in meno rispetto a qualsiasi di quelle impostazioni e ha ottenuto da 2 a 6 punti in meno rispetto a Fable a medium o all'impostazione predefinita, battendo nettamente una baseline Claude Sonnet 5 in solitaria:

La contabilità dei token mostra il perché. Entrambe le fatture sono per lo più lettura del corpus servita dalla cache: la configurazione con coordinatore ha letto circa 570 milioni di token in cache per episodio, quasi tre volte i circa 200 milioni del modello in solitaria, e comunque è costata meno della metà, perché le sue letture sono state fatturate alla tariffa di lettura dalla cache di Claude Sonnet 5 anziché a quella di Claude Fable 5. Fable 5 all'effort predefinito detiene ancora l'accuratezza di picco, a 2,8 volte il costo della configurazione con coordinatore, quindi la delega qui compra la maggior parte dell'accuratezza, non tutta.

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

BrowseComp⁴ mostra il confine all'interno di un singolo benchmark. La delega ha reso sulla porzione di routine e ha perso sull'insieme completo e più difficile, dove il modello di frontiera da solo ha raggiunto l'accuratezza della configurazione con coordinatore a un costo dal 22% al 30% inferiore. Lavori esterni indipendenti riportano lo stesso pattern⁵. Se il lavoro è una catena, rientra in un contesto senza una lunga coda di costi, o un singolo modello a effort inferiore soddisfa già il tuo standard, non costruire un orchestrator.



Scegliere tra le strategie

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

Se non sei sicuro, non costruire ancora nulla:

1. Esegui prima uno sweep dell'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 lo sweep mostra un divario, calcola il prezzo del modello più forte da solo a basso effort. Quello è il numero che un abbinamento advisor deve battere, e gli abbinamenti di questa pagina che lo hanno battuto sono stati quelli il cui executor ha effettivamente consultato.

I risultati multi-modello di questa pagina sono stati giudicati rispetto allo stesso modello a effort inferiore 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 è uno sweep dell'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 risalgono a luglio e agosto 2026, ai prezzi di listino dell'epoca, e si sposteranno man mano che modelli e prezzi cambiano. Anche il tuo tasso di escalation, quanto nettamente i compiti si dividono e la lunghezza delle trascrizioni li spostano. Il metodo rimane lo stesso:

1. Estrai alcuni compiti dai log di produzione, ponderati come il traffico reale, e scrivi controlli di esito per ciascuno: test superati, ticket chiuso, conteggio righe corretto. Registra il costo per compito accanto al punteggio: calcola il prezzo dei quattro conteggi di token in usage di ogni risposta alle rispettive tariffe, 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 singolo modello.
3. Se la curva mostra un divario che l'effort non può colmare, 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 due per un altro modello.
INPUT_PER_MTOK = 5.00  # Claude Opus 5
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
cost = (
    usage.input_tokens * INPUT_PER_MTOK
    # Le scritture in cache costano 1,25x il prezzo di input (cache di 5 minuti); le letture 0,1x.
    + (usage.cache_creation_input_tokens or 0) * INPUT_PER_MTOK * 1.25
    + (usage.cache_read_input_tokens or 0) * INPUT_PER_MTOK * 0.10
    + usage.output_tokens * OUTPUT_PER_MTOK
) / 1_000_000
print(f"Request cost: ${cost:.6f}")

Nei cicli degli agenti il termine di lettura dalla cache è solitamente il più grande dei quattro; se non lo è, verifica 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 citati

Tutte le misurazioni sono esecuzioni interne di Anthropic di questi benchmark. Salvo diversa indicazione, i costi sono in USD ai prezzi di listino di agosto 2026; le cifre di Claude Sonnet 5 usano $2 e $10 per milione di token di input e output. I grafici etichettati "notional USD" calcolano il prezzo dei conteggi di token di ogni richiesta a quelle tariffe anziché riportare le fatture.

1. WideSearch: Wong et al., "WideSearch: Benchmarking Agentic Broad Info-Seeking," arXiv:2508.07999, 2025. Compiti di ricerca web ampia valutati sulla completezza e accuratezza di una tabella a molte righe; 200 problemi, 3 esecuzioni per configurazione. I grafici di cache ed effort provengono da esecuzioni separate, quindi i costi per problema differiscono leggermente. Il grafico di concentrazione dei costi è un'esecuzione separata di 20 problemi, 3 esecuzioni per problema, con costi calcolati dai record di fatturazione per richiesta.
2. GDPval: OpenAI, "GDPval: Evaluating AI Model Performance on Real-World Economically Valuable Tasks," 2025. Deliverable di lavoro di conoscenza valutati rispetto a rubriche dei compiti; un'esecuzione di 210 compiti del gold set rilasciato, un tentativo per compito. Un modello Claude valuta, 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. Le cifre di escalation provengono compito per compito 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,70; prima medium, dal 93,8% al 94,2% per circa $0,95; il predefinito rieseguito sui propri fallimenti, 94,0% per $1,58; tutto al predefinito, dal 90,9% al 92,5% per $1,39. Gli abbinamenti con executor Claude Sonnet 5 nel grafico advisor provengono dalla stessa serie di agosto 2026 su questo sottoinsieme: l'abbinamento Sonnet-più-Opus è stato eseguito due volte (un'esecuzione e una replica esatta) e l'abbinamento a basso effort una volta; le cifre del budget del compito sono un'esecuzione per budget sullo stesso sottoinsieme. La cifra di Claude Fable 5 in Confronta i modelli è una singola esecuzione di luglio 2026, anche baseline senza budget del grafico del budget del compito; ogni esecuzione con budget ha completato tutti i 482 problemi senza errori dell'harness.
4. BrowseComp: Wei et al., "BrowseComp: A Simple Yet Challenging Benchmark for Browsing Agents," OpenAI, 2025. Le cifre di effort usano un taglio di 500 problemi, da una a tre esecuzioni per impostazione. Il grafico dell'assicurazione sui costi usa 10 problemi risolti in modo affidabile da una porzione di 26 problemi, 50 esecuzioni delegate e 70 in solitaria ($6,45 rispetto a $11,99 per esecuzione in valore atteso); le cifre delegate 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 a molte righe con il recupero multi-hop; misurato sull'insieme di righe permanente del benchmark, 3 esecuzioni per configurazione.
7. DeepResearch Bench II: Li et al., "DeepResearch Bench II: Diagnosing Deep Research Agents via Rubrics from Expert Report," arXiv:2601.08536, 2026. I suoi 132 compiti di ricerca in 22 domini sono valutati rispetto a rubriche binarie derivate da esperti; misurato su un sottoinsieme di 50 compiti stratificato su tutti i temi, un tentativo per compito, 3 esecuzioni, con punteggio sui compiti che nessuna configurazione ha rifiutato. 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. Le esecuzioni precedono Claude Opus 5, da cui la sua assenza dal grafico Confronta i modelli. Il costo di Sonnet 5 differisce leggermente tra il grafico della cache (costo di inferenza, con e senza cache) e quel grafico (costo complessivo, cache attiva); entrambi provengono dalle stesse esecuzioni.
8. Sweep dei difetti del corpus: Interno ad Anthropic, per lavoro più grande di una finestra di contesto: un corpus di 21,6 milioni di token da 14 sorgenti di pacchetti Python pubblici 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 di team nel grafico è un'esecuzione di agosto 2026 in cui il coordinatore Claude Fable 5 ha eseguito l'intero sweep all'interno della piattaforma al suo limite documentato di 25 worker Claude Sonnet 5 concorrenti; i suoi tre episodi hanno ottenuto F1 0,842, 0,805 e 0,810 per $263, $299 e $261. Le configurazioni in solitaria sono esecuzioni di luglio 2026 sulla stessa build del corpus. 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, misurato ad agosto 2026, due esecuzioni per configurazione, valutato dal modello rispetto a risposte di riferimento, token dell'advisor misurati per richiesta. Un controllo di sicurezza della piattaforma ha rifiutato due domande di biologia sugli executor 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. Misurato ad agosto 2026: 113 compiti originali in cinque linguaggi con verificatori basati su programmi. Gli abbinamenti sono due esecuzioni ciascuno con token dell'advisor misurati per richiesta, e hanno usato un ciclo advisor lato client anziché lo strumento advisor, con contabilità identica. Gli sweep di effort a modello singolo sono esecuzioni singole con prezzo calcolato dai conteggi di token, un'approssimazione che tiene conto della cache. I costi per compito sono i totali dell'esecuzione divisi per 113.
11. Benchmark interno di programmazione agentica: Interno ad Anthropic: 370 compiti su repository valutati dai test dei repository stessi. Le cifre API (Opus 5 da solo, Fable 5 da solo e l'abbinamento) sono state misurate ad agosto 2026 all'effort predefinito con un limite di output di 128.000 token, un'esecuzione per configurazione: cinque tentativi per compito alle impostazioni predefinite e per l'abbinamento, uno a low e medium; l'abbinamento ha avuto in media circa due consultazioni dell'advisor per tentativo; i costi sono per tentativo. Le cifre di Claude Code sono esecuzioni di luglio 2026 degli stessi compiti, un'esecuzione per configurazione, costi approssimativi.
12. Benchmark interno di compiti su repository (misurazione del limite): Un insieme separato interno ad Anthropic di circa 130 compiti su repository, eseguito ad agosto 2026 con un semplice ciclo di agente API, un tentativo per compito. Le cifre a 16.384 token sono la media di due esecuzioni per modello; le cifre a 64.000 token sono esecuzioni singole (124 compiti valutati per Opus 5; 108 per Claude Fable 5, poiché l'ambiente aveva saltato il resto prima che il modello venisse eseguito). Circa metà dei tentativi di Fable che il limite di 16.384 aveva interrotto sono risultati risolti a 64.000; un'ulteriore esecuzione di Fable a 128.000 ha ottenuto il 56,1%, entro il rumore dell'esecuzione a 64.000. Le cifre del limite su SWE-bench Pro sono un'esecuzione di Claude Fable 5 per limite all'effort predefinito su un sottoinsieme di 100 problemi stratificato dall'insieme di 482 problemi del riferimento 3, non confrontabile con i suoi punteggi. Le distribuzioni per turno del grafico provengono dall'esecuzione di Opus a 64.000 e dall'esecuzione di Fable a 128.000, quindi nessuna delle due è troncata dal proprio limite.
13. Chartography: Surge AI, "Chartography," 2026. L'insieme completo rilasciato di 100 domande, misurato ad 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 le configurazioni qui ma non con la classifica pubblicata. Due esecuzioni per configurazione, aggregate; le variazioni tra esecuzioni sono state da 4 a 10 punti. I costi escludono il tempo di sandbox, che ha aggiunto meno dell'1%. Il confronto del tasso di consultazione proviene dalla riesecuzione delle stesse configurazioni sulla Messages API con un set di strumenti container.
14. Valutazione dell'audit dei prompt per support desk: Un insieme costruito da Anthropic di 44 ticket di supporto con valutazione deterministica, eseguito ad 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 precedente, modello più recente sullo stesso prompt, modello più recente dopo l'audit) mediato sui sei prompt e 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 sono entro il rumore.



Prossimi passi