Claude Fable 5.2: il costo reale di un agente si misura per task, non per token

Un modello AI può costare meno per milione di token e risultare più caro per consegnare una modifica funzionante. È questa la distinzione che conta quando si usa un agente per lavorare su un repository, non la classifica del giorno. Il lancio di Claude Fable 5.2 e Mythos 5.2 offre un caso concreto: Anthropic annuncia nuove capacità, prezzi differenziati e una modalità più veloce a tariffa maggiorata. Ma il costo di un task dipende anche da tentativi falliti, verifiche e tempo umano necessario per accettare il risultato.

Due nomi, accessi diversi

Nel comunicato ufficiale del 9 novembre 2026, Anthropic presenta Fable 5.2 e Mythos 5.2 come due offerte basate sullo stesso modello sottostante, ma con salvaguardie e condizioni di accesso differenti. Fable è destinato all’accesso ordinario attraverso i canali supportati; Mythos è limitato alle organizzazioni approvate. La distinzione è operativa: non basta leggere un benchmark per assumere che una determinata configurazione sia acquistabile, autorizzata o replicabile nella propria infrastruttura.

Questo punto viene spesso perso nelle comparazioni. Un risultato ottenuto con un programma di accesso controllato non equivale a una funzionalità disponibile per qualunque team di sviluppo. Prima di pianificare una migrazione occorre verificare disponibilità, policy di trattamento dei dati, limiti API e possibilità di riprodurre i test.

Il prezzo per token non è il prezzo per modifica

Per la configurazione annunciata, il listino citato da Anthropic e ripreso da Heise indica 8 dollari per milione di token in input e 40 dollari per milione in output; la modalità fast porta questi valori a 16 e 80 dollari. Sono prezzi di listino da verificare al momento dell’acquisto, non una previsione di spesa per progetto. Il raddoppio del prezzo unitario può avere senso se riduce davvero il tempo sul percorso critico; non lo ha automaticamente se il collo di bottiglia è una suite di test lenta o una review umana.

Un esempio puramente illustrativo: un’esecuzione che consuma 200.000 token in input e 40.000 in output costerebbe 3,20 dollari al prezzo base, prima di eventuali altri addebiti. Se servono tre tentativi, il costo diretto diventa 9,60 dollari; se un modello più costoso conclude correttamente al primo tentativo, il confronto può ribaltarsi. Le cifre dell’esempio non rappresentano un benchmark dei modelli: mostrano perché bisogna misurare l’intero ciclo.

Più ragionamento non significa automaticamente più affidabilità

Simon Willison, presentando il supporto ai nuovi modelli nel proprio plugin llm-anthropic, ha riportato un test SVG in cui il livello di ragionamento max ha consumato 128.000 token senza restituire il risultato atteso, mentre xhigh ha prodotto un’immagine. È un esperimento singolo, non una valutazione statistica delle prestazioni nel coding. Resta però un promemoria utile: alzare indiscriminatamente il budget di ragionamento non è una strategia di qualità.

Per un agente software, l’insuccesso può assumere forme meno evidenti: modifiche che compilano ma rompono casi limite, duplicazione di logica già presente, patch troppo estese, test che non coprono il comportamento richiesto. Contare soltanto le risposte completate produce una metrica ingannevole. Serve definire prima cosa significhi un task riuscito.

Un protocollo di valutazione che abbia senso

La comparazione dovrebbe partire da una selezione di task rappresentativi: correzione di un bug riproducibile, refactoring con test, modifica a un’integrazione, aggiornamento di una query e intervento su codice legacy. Per ciascuno conviene fissare repository e commit iniziale, istruzioni, strumenti disponibili, timeout e criteri di accettazione. Il risultato va poi controllato su una copia isolata, mai direttamente sulla produzione.

• Misurare il costo API complessivo di ogni task, inclusi retry e tool call.
• Registrare durata fino al risultato verificato, non soltanto latenza della prima risposta.
• Contare test superati, regressioni, modifiche superflue e interventi manuali.
• Ripetere più volte i task per osservare variabilità e fallimenti intermittenti.
• Separare il beneficio della modalità fast da quello di un budget di ragionamento maggiore.

Il confronto va fatto sul medesimo perimetro e con un campione sufficiente per evitare conclusioni basate su una demo riuscita. Se il modello genera una patch in due minuti ma richiede quaranta minuti di revisione, il tempo operativo resta quarantadue minuti. Anche la review è un costo, benché non compaia nella fattura del provider.

Il prompt cambia il comportamento, non i permessi

Un dettaglio interessante della documentazione di Anthropic riguarda il modo in cui si descrive la responsabilità sul codice. Nei test interni del produttore su piccoli task, formulare il prompt come se l’agente dovesse continuare a mantenere il repository avrebbe favorito la riduzione di duplicazioni rispetto a istruzioni prive di quel contesto. Sono risultati dichiarati dal produttore, non una garanzia trasferibile a qualsiasi codebase.

La lezione non è attribuire all’agente una proprietà reale del software. È esplicitare l’obiettivo di manutenzione: preferire una soluzione coerente con l’architettura, identificare duplicazioni, giustificare i cambiamenti e proporre test. La responsabilità legale e tecnica, i permessi sul repository e l’approvazione delle modifiche rimangono nelle mani del team. Un prompt non deve mai sostituire controlli di accesso, sandbox e code review.

La scelta utile è quella verificabile

Fable 5.2 e Mythos 5.2 meritano attenzione perché mettono insieme prestazioni dichiarate, condizioni di accesso e un modello economico che distingue velocità e consumo. Non bastano però a decretare un vincitore universale. Per chi costruisce software, la domanda corretta è quale configurazione completi più spesso un lavoro accettabile, con meno correzioni e a un costo prevedibile. La risposta nasce dai propri task, da misure ripetibili e da un processo di verifica: non dal nome del modello.