Per quanto tempo può lavorare un’intelligenza artificiale su un progetto software senza limitarsi a suggerire una funzione o correggere poche righe? Con Claude Fable 5.2, annunciato da Anthropic il 9 novembre 2026, la domanda riguarda ormai cicli di sviluppo prolungati, gruppi di agenti che collaborano e sistemi realizzati partendo da una cartella vuota. Ma accanto alla capacità tecnica emerge un tema altrettanto concreto: quanto costa fare lavorare questi agenti per giorni, e chi garantisce che il risultato sia affidabile?
Lo spunto è un articolo pubblicato da Rivista.AI il 10 novembre 2026, che mette l’accento proprio sul rapporto tra autonomia e costi, evocando nel titolo una spesa superiore a 14.000 dollari. Ho confrontato questa impostazione con l’annuncio di Anthropic e con la documentazione tecnica e tariffaria, distinguendo i risultati dichiarati dal produttore dalle valutazioni economiche che richiedono dati di consumo reali.
Da assistente di programmazione a sistema di agenti
Per anni l’assistenza dell’IA al programmatore è stata descritta soprattutto come completamento del codice: l’utente scrive, il modello suggerisce e la persona verifica. Un agente software è qualcosa di diverso. Può esaminare file, organizzare un piano, eseguire strumenti, scrivere test, correggere gli errori segnalati e ripetere il ciclo. Quando si introducono più agenti, alcuni possono specializzarsi nell’analisi, altri nella generazione del codice, nei test, nella revisione o nell’integrazione.
L’autonomia, però, non nasce soltanto dalla qualità del modello linguistico. Dipende anche dall’harness: l’insieme di strumenti, permessi, stato persistente, controlli, ambienti isolati e regole che permette agli agenti di lavorare senza perdere il filo. Una lunga sequenza di chiamate API non è di per sé un processo di ingegneria del software. Per diventarlo servono obiettivi verificabili, feedback attendibili e criteri di arresto.
Otto giorni e oltre mille subagenti: l’esperimento del sistema operativo
Il risultato più spettacolare comunicato da Anthropic riguarda un esperimento interno: un ingegnere ha assegnato a Fable 5.2 la realizzazione di un prototipo di sistema operativo partendo da una cartella vuota. Il modello ha coordinato oltre 1.000 subagenti nell’arco di otto giorni, impegnati a scrivere, provare e revisionare codice. Secondo l’azienda, il risultato si avvia su un portatile ed è dotato di nucleo del sistema, driver per disco, tastiera e rete, memorizzazione persistente, interfaccia a finestre, schermata di accesso e installatore.
Sono affermazioni notevoli, ma devono essere lette con precisione. Anthropic parla di prototipo sperimentale, non di un sistema operativo validato per un utilizzo generalizzato. Il numero di subagenti indica le istanze coordinate nell’esperimento, non dimostra che fossero tutte attive contemporaneamente. Dalla presentazione pubblica non ricaviamo inoltre un rapporto di collaudo indipendente, il costo dettagliato di questa specifica prova o un giudizio sulla manutenibilità a lungo termine.
La notizia più interessante, per chi sviluppa software, non è soltanto la quantità di codice che un modello può produrre. È la capacità di sostenere una catena di attività interdipendenti abbastanza a lungo da incontrare errori reali, diagnosticarli e cambiare strategia. Far funzionare un prototipo è un traguardo; trasformarlo in software sicuro, documentato, osservabile e sostenibile nel tempo ne costituisce un altro.
Che cosa cambia con Fable 5.2
Fable 5.2 e Claude Mythos 5.2 condividono, secondo Anthropic, lo stesso modello di base, ma differiscono nelle condizioni di accesso e nelle protezioni. Fable integra salvaguardie più restrittive per attività ad alto rischio in ambito cyber e biologico ed è il modello destinato all’uso generale; Mythos è accessibile a organizzazioni e professionisti ammessi a programmi di verifica specifici. Non sono dunque due prodotti da confrontare semplicemente come «versione debole» e «versione forte».
Anthropic dichiara risposte fino al 30% più rapide rispetto alla versione 5.1 e, nel benchmark di programmazione FrontierCode 2.0, un risultato del 49,1% nella configurazione Xhigh. Si tratta di risultati ottenuti in condizioni di prova definite e riportati dal produttore: un incremento di benchmark non si traduce automaticamente in uguale incremento di produttività in un progetto aziendale. Il modello dispone inoltre di una finestra di contesto fino a un milione di token, ma grande capacità di contesto non significa comprensione infallibile di ogni dipendenza di un repository.
C’è anche un dato che suggerisce come usarlo: Anthropic stessa raccomanda di partire da Opus 5.5 per la maggior parte dei lavori ordinari e di passare a Fable quando l’ambiguità, la durata o la difficoltà del compito lo richiedono. In un’architettura multi-agente, un modello più costoso può essere impiegato come orchestratore o consulente per decisioni complesse, lasciando attività ripetitive a modelli meno onerosi.
Il conto economico: perché il prezzo per token non basta
La tariffa API pubblicata al lancio è di 8 dollari per milione di token in ingresso e 40 dollari per milione di token in uscita. Una modalità fast, fino a 2,5 volte più rapida nella generazione secondo Anthropic, raddoppia tali prezzi. Per un lavoro di pochi minuti il costo può essere modesto; in un’esecuzione prolungata, invece, gli agenti rileggono file, scambiano istruzioni, esaminano log, invocano strumenti, generano revisioni e ripetono i test. Il consumo cresce con il numero di interazioni e con la quantità di contesto elaborato.
| Modalità Fable 5.2 | Input, per 1 milione di token | Output, per 1 milione di token |
|---|---|---|
| API standard | 8 $ | 40 $ |
| API fast | 16 $ | 80 $ |
Semplificando, ed escludendo caching, sconti, eventuali altri addebiti e infrastruttura, il solo costo dei token in modalità standard può essere espresso come C = 8 · Tin + 40 · Tout, dove Tin e Tout sono rispettivamente i milioni di token fatturati in ingresso e in uscita.
Un esempio numerico, non il costo dell’esperimento Anthropic
Ipotizziamo, a puro scopo illustrativo, che un sistema di agenti consumi nell’arco di molte sessioni 1 miliardo di token in ingresso e 150 milioni di token generati. Applicando le tariffe standard: 1.000 × 8 = 8.000 dollari per l’ingresso e 150 × 40 = 6.000 dollari per l’uscita. Il totale teorico è 14.000 dollari. Il calcolo mostra come la spesa possa raggiungere quell’ordine di grandezza, ma non descrive i consumi dell’esperimento del sistema operativo, che non sono stati documentati in questo dettaglio.
La cifra superiore a 14.000 dollari riportata nel titolo di Rivista.AI va quindi letta come un riferimento al problema economico, non come un importo ufficialmente verificato per quel prototipo. Cache dei prompt, quantità di esecuzioni, scelta dei modelli, livello di ragionamento, retry, tool e servizi esterni possono alterare sensibilmente il conto reale. Senza log di consumo e report di fatturazione, una stima puntuale rimarrebbe speculativa.
Un precedente con una spesa documentata
Esiste invece un precedente descritto direttamente da Anthropic. Nel febbraio 2026, il ricercatore Nicholas Carlini ha raccontato come 16 agenti basati su Claude Opus 4.6 abbiano costruito in Rust un compilatore C di circa 100.000 righe, capace di compilare anche un kernel Linux. Il progetto, sviluppato in circa due settimane attraverso quasi 2.000 sessioni, ha richiesto poco meno di 20.000 dollari di costi API. Le versioni del modello e le condizioni del test erano differenti: il caso serve a dimostrare la possibilità di spese elevate in progetti agentici, non a stimare per proporzione il costo di Fable 5.2.
L’analisi tecnica del compilatore è forse più istruttiva dei numeri. Anthropic evidenzia problemi di coordinamento tra agenti che modificavano le stesse parti, regressioni e difficoltà nel definire un sistema di test abbastanza forte da guidare il lavoro. La lezione è semplice: aumentare il parallelismo senza governare il processo può generare conflitti e costi, anziché accelerare lo sviluppo.
Qualità: quando una demo diventa un prodotto?
Per valutare un sistema di sviluppo agentico non basterei a contare i file prodotti, i commit o le ore di autonomia. Sono misure di attività, non necessariamente di valore. Un progetto dovrebbe essere giudicato rispetto a criteri più solidi: correttezza funzionale, stabilità delle interfacce, copertura dei test significativi, sicurezza, prestazioni, riproducibilità delle build e facilità di manutenzione.
Immaginiamo la migrazione di un grande applicativo legacy verso una moderna architettura a servizi. Un agente potrebbe estrarre regole di business, proporre API, generare test di caratterizzazione e produrre componenti. Ma se traducesse male una regola contabile o eliminasse un controllo apparentemente superfluo, la compilazione corretta non basterebbe. Occorrono test su dati e casi reali autorizzati, confronti di comportamento e revisioni svolte da persone responsabili del dominio.
Questo punto è particolarmente rilevante nei sistemi informativi della Pubblica Amministrazione, dove possono convivere processi normati, storico applicativo, dati sensibili e dipendenze non completamente documentate. Gli agenti possono accelerare il lavoro di ricognizione e trasformazione, ma non sostituiscono la responsabilità sulle regole, sulla sicurezza e sulla correttezza degli esiti.
Come rendere controllabile un progetto di sviluppo agentico
Un’organizzazione che voglia sperimentare sessioni di molte ore o giornate dovrebbe costruire un perimetro operativo chiaro prima di aumentare l’autonomia. Propongo di partire da alcuni controlli concreti:
| Controllo | Che cosa verificare |
|---|---|
| Obiettivi e perimetro | Requisiti, componenti ammessi, criteri di accettazione e condizioni di arresto. |
| Budget e telemetria | Limiti per run e per agente, costi per fase, alert e registrazione di token e retry. |
| Permessi e dati | Ambienti isolati, segreti protetti, accesso minimo necessario e divieto di modifiche dirette in produzione. |
| Qualità del codice | Test automatici, analisi statica, security scan, review indipendente e tracciamento delle decisioni. |
| Integrazione e rollback | Branch controllati, pipeline CI/CD, checkpoint umani e possibilità di annullare rapidamente gli effetti. |
| Confronto economico | Costo per funzionalità accettata, non soltanto costo per token o numero di righe generate. |
L’indicatore che preferirei osservare è il costo per risultato correttamente accettato: totale dei costi dell’esecuzione diviso per le unità di lavoro che superano gli standard di qualità definiti. È più significativo del costo medio per singola risposta, perché un modello apparentemente economico può richiedere numerose correzioni, mentre un modello più caro potrebbe completare il compito con meno cicli.
Un nuovo ruolo per chi sviluppa software
Se gli agenti riescono davvero a sostenere lavori complessi per giorni, il programmatore non scompare automaticamente: cambia una parte del suo lavoro. Diventano sempre più importanti la progettazione delle verifiche, l’architettura, la conoscenza del dominio, la definizione degli strumenti disponibili agli agenti e la capacità di leggere criticamente ciò che essi producono.
Cambia anche il modo di stimare un progetto. Accanto alle tradizionali grandezze — effort, complessità, competenze, rischi e tempi — compariranno costi di inferenza, strategie di orchestrazione, frequenza delle verifiche umane e probabilità di rilavorazione. La convenienza non dipende dalla sola potenza del modello, ma dall’intero processo che lo circonda.
La vera frontiera non è lasciare un’IA programmare per otto giorni. È sapere, alla fine di quegli otto giorni, che cosa è stato costruito, come è stato verificato e quanto è costato ottenere un risultato affidabile.
Una riflessione finale
L’esperimento di Claude Fable 5.2 segnala un salto nell’orizzonte temporale delle attività affidabili agli agenti. Non è ancora la prova che si possano delegare indistintamente prodotti complessi, né che mille agenti siano più efficienti di una squadra ben organizzata. È però un’indicazione concreta: il software può diventare il risultato di un processo nel quale persone e macchine si dividono la produzione, l’esplorazione e la verifica in modi nuovi.
Il numero evocato da Rivista.AI — 14.000 dollari — porta alla domanda giusta, purché sia trattato con prudenza. La spesa per inferenza non è soltanto un costo tecnico da minimizzare: è una parte del business case, da confrontare con qualità, tempi, rischio e valore del software rilasciato. Su questa capacità di governare insieme ingegneria e costi si misurerà la maturità reale dello sviluppo agentico.
Fonti e approfondimenti
- Rivista.AI — Anthropic presenta Claude Fable 5.2, 10 novembre 2026. Lo spunto editoriale sull’autonomia e il problema economico.
- Anthropic — Claude Fable 5.2 and Mythos 5.2, 9 novembre 2026. Fonte primaria per l’esperimento del sistema operativo, caratteristiche e benchmark.
- Anthropic — Model overview: Claude Fable 5.2. Specifiche tecniche, finestra di contesto, modalità operative.
- Anthropic — Claude Platform Pricing. Tariffe ufficiali per token; i prezzi possono variare con modalità e condizioni d’uso.
- Anthropic Engineering — Building a C compiler with a team of parallel Claudes, 5 febbraio 2026. Esperimento dei 16 agenti e costo di circa 20.000 dollari.
Lascia un commento