Claude Fable 5.2 vs Opus 5.5: codice e attività agente

Su queste quattro piccole attività di codice e strumenti il sovrapprezzo di Fable 5.2 non conviene: Claude Fable 5.2 e Claude Opus 5.5 hanno superato tutte le 29 verifiche di codice, e la stima a tariffa standard è stata di $0,031 per Opus sull'intero set contro $0,146 per Fable. Valutate Fable per ragionamenti più difficili o esecuzioni agente lunghe, quando Opus con effort più alto non basta.

Fable 5.2 e Opus 5.5 in sintesi

Fable 5.2 è più recente, ma i due modelli condividono la stessa finestra di contesto da 1M token e lo stesso output da 128K token. La differenza pratica in questo test è stato il consumo di token, non la correttezza del codice.

Le pagine modello di Anthropic per Fable 5.2 e Opus 5.5 li elencano entrambi come attivi, con input testo e immagini. Fable è uscito il 9 novembre 2026, Opus il 22 settembre 2026. I livelli di effort predefiniti sono diversi, quindi impostate medium su entrambi quando confrontate.

La panoramica dei modelli di Anthropic raccomanda Opus 5.5 per la maggior parte delle attività. Colloca Fable 5.2 su ragionamento impegnativo e lavoro agente di lungo periodo, o sui casi in cui le valutazioni di Opus 5.5 con effort più alto restano sotto. È il posizionamento del fornitore; questo test copre quattro attività piccole.

Per i cambiamenti di versione leggete cosa è cambiato in Fable 5.2. Per l'analisi di un solo modello c'è la recensione di Opus 5.5.

Quanto costano le quattro attività

La pagina prezzi ufficiale di Anthropic indica $8 di input e $40 di output per milione di token per Fable 5.2, contro $4 e $20 di Opus 5.5 (verificata il 12 nov 2026). Batch dimezza entrambe le coppie, la modalità fast le raddoppia.

Sulle quattro attività valutate Fable ha consumato 3.439 token di input e 2.954 di output. Opus ne ha consumati 2.421 e 1.065. A tariffa standard il conto è:

• Fable: (3.439 × $8 + 2.954 × $40) ÷ 1.000.000 = $0,1457
• Opus: (2.421 × $4 + 1.065 × $20) ÷ 1.000.000 = $0,0310

Sono stime a tariffa standard calcolate sui token osservati, non fatture né importi OmniaKey. La risposta di Opus dichiarava velocità fast, quella di Fable standard; Anthropic elenca input e output in fast al doppio della tariffa standard. Qui normalizziamo entrambi alla tariffa standard, quindi questi numeri non sono un confronto controllato di tempi o di fatturazione.

Stime a tariffa standard, in dollari statunitensi:

In media sulle quattro attività testate Fable è costato $0,0364 e Opus $0,0077; la stima a tariffa standard di Fable è stata superiore di $0,1147 sul set. La regola pratica è il costo per attività utilizzabile: spesa API più tempo di nuovi tentativi e revisione. Salite di modello quando casi reali falliti giustificano quella spesa extra; queste quattro attività piccole non lo fanno.

I totali a orologio sono stati 27,8 s per Fable e 43,6 s per Opus. Le risposte di Fable dichiaravano velocità standard, quelle di Opus fast, e non abbiamo impostato la velocità; leggeteli come osservazioni, non come una classifica di velocità.

Due correzioni in Python: 22/22 verifiche su entrambi

Le due correzioni sono brevi, e entrambi i modelli hanno restituito funzioni che funzionano. Vale la pena riusare questi fallimenti perché mettono alla prova la gestione delle revisioni e i casi limite della paginazione, non la conoscenza di una libreria.

Totali di utilizzo: un fallimento nuovo deve cancellare un successo vecchio

La funzione vecchia sommava tutti gli eventi complete. Ignorava revision e status, quindi un nuovo tentativo contava i token due volte e una revisione failed più recente non poteva annullare una complete precedente.

La regola centrale nel prompt:

Keep only the highest revision for each event_id, and on equal revisions keep the last occurrence in the input. A newer failed revision supersedes an older complete one and contributes nothing.

La riproduzione minima è l'evento x in revisione 1, complete, 10 token, seguito da x in revisione 2, failed, 10 token. Il totale corretto è zero; la funzione vecchia restituisce 10.

Entrambi i modelli hanno tenuto la revisione più alta, usato l'ordine di input per le revisioni uguali, saltato i vincitori failed, conservato gli utenti a zero token e lasciato intatto l'input. Risultato: 8/8 verifiche ciascuno, con funzioni equivalenti.

Paginazione a cursore: i pareggi non devono ripetere né saltare

La versione vecchia ordinava solo per ts, tagliava la prima pagina prima di applicare il cursore, accettava timestamp uguali con <=, non validava mai limit e restituiva sempre un cursore successivo. Con due righe a ts=4 questo ripete o salta un ID.

Le regole centrali nel prompt:

Sort descending by (ts,id). Select rows strictly LESS than the cursor tuple, so tied timestamps neither repeat nor skip IDs. Return next_cursor only if MORE eligible rows remain. Raise ValueError unless limit is an integer from 1 through 100; bool is invalid.

Entrambi hanno corretto tutto: ordinamento per tupla, minore stretto, filtro della lista completa prima del taglio, cursore successivo solo se restano righe e validazione che rifiuta True, False, 0, 101, 1.5, '2' e None. Risultato: 14/14 verifiche ciascuno, compresa una scansione di una riga su timestamp in pareggio.

Il registro asincrono: stessi numeri, JSON diverso

Entrambi i modelli hanno azzeccato la riconciliazione: $0,93 netti riservati, t3 in sospeso, t1 e t5 completate e poll_existing per t3.

Il fixture sintetico fornito usa importi illustrativi, non i prezzi OmniaKey. Le righe chiave:

POST key=a => 201 task=t1 quote=0.40

POST key=a, identical body => 200 task=t1

GET t1 => SUCCEEDED

POST key=b => 201 task=t2 quote=0.40

GET t2 => FAILED

POST key=c => 201 task=t3 quote=0.13

Client stopped polling t3 after 120 seconds; last status PROCESSING

POST key=d => 201 task=t4 quote=0.13

GET t4 => CANCELED

POST key=e => 201 task=t5 quote=0.40

GET t5 => SUCCEEDED

L'aritmetica è 0,40 + 0,13 + 0,40 = 0,93. t2 e t4 sono rimborsate; t1 e t5 consumano; t3 mantiene la prenotazione perché il client ha smesso di interrogare, non perché l'attività è fallita.

Contando solo le attività con ultimo stato osservato SUCCEEDED, entrambi hanno restituito gli stessi valori. Fable ha restituito JSON grezzo. Opus ha avvolto il JSON in un blocco di codice JSON. Il prompt diceva "Return ONLY JSON", quindi un json.loads stretto sulla risposta di Opus fallisce finché il blocco non viene rimosso. È solo una differenza di formato: la richiesta era testo JSON semplice, senza schema JSON e senza modalità di output strutturato. Risultato: i valori passano in entrambi i casi; per l'automazione validate la risposta grezza con un parser stretto o passate all'output strutturato. È stata una differenza osservata, non un pattern generale.

L'attività sul file in due turni: una lettura, una patch

Il vecchio remaining_quota del fixture sottraeva le units di ogni evento. Ignorava l'ultimo stato di ogni id e il limite max(0, ...), quindi le attività failed o canceled consumavano comunque quota e gli eventi ripetuti venivano addebitati due volte.

L'attività:

Use read_file once to inspect quota.py, then return one Python code block containing only a corrected remaining_quota(limit, events) function.

Entrambi i modelli hanno fatto esattamente una chiamata read_file per quota.py. Tornato il fixture, entrambi hanno restituito la stessa logica di patch: tenere l'ultimo evento per id, sommare le units solo per reserved o succeeded e restituire max(0, limit - consumed). Risultato: 7/7 verifiche ciascuno, compresi i casi failed poi reserved e lo sforamento del limite.

Sono due turni e un fixture. Mostra che i modelli chiedono il file giusto e lo correggono; non copre un'esecuzione agente lunga.

Come abbiamo testato

Il 12 nov 2026 abbiamo inviato quattro attività a claude-fable-5-2 e claude-opus-5-5 tramite l'endpoint Messages di OmniaKey. Ogni coppia modello/attività usava una conversazione nuova e una cache fredda, con effort medium, max_tokens 4096 per richiesta, senza system prompt, senza temperature né top_p e un solo tentativo. Abbiamo alternato quale modello partiva per primo in base all'attività.

L'attività agente usava un unico strumento read_file stretto con tool_choice: auto; tutto il resto era un solo messaggio utente. Il valutatore filtrava ogni risposta Python con AST, poi la eseguiva in un processo isolato con timeout di 3 secondi su 8 casi d'uso, 14 di cursore e 7 agente: 29 casi di codice per modello. Ogni richiesta è stata eseguita una volta.

Il primo prompt del registro lasciava aperto se le attività FAILED/CANCELED entrino in completed_task_ids. Quel giro ambiguo l'abbiamo sostituito con una ripetizione chiarita per modello, contando solo le attività con ultimo stato osservato SUCCEEDED; gli output originali restano fuori dai totali delle quattro attività valutate.

Le 12 richieste hanno restituito HTTP 200 con l'ID modello richiesto e sono finite con end_turn, oppure tool_use e poi end_turn, senza troncamenti. Entrambi dichiaravano service tier standard. Fable dichiarava velocità standard e conteggi separati dei token di thinking; Opus dichiarava velocità fast e ometteva il campo dei token di thinking. Non abbiamo impostato la velocità, e i token di output includono già il thinking addebitato, quindi il campo assente di Opus non dice nulla su un thinking nullo.

La stessa stringa di effort è un'impostazione, non un budget di calcolo equiparato. Questa esecuzione tiene l'effort su medium; per il vostro lavoro provate i livelli di effort che la vostra attività richiede. È un test su un piccolo fixture, non un benchmark su un repository intero né su un agente di lunga durata. Non prevede i tassi di successo su altre attività. OmniaKey vende accesso a entrambi i modelli; i prezzi qui sopra sono i listini ufficiali di Anthropic.

Quando valutare Fable

Partite da Opus 5.5 per lavoro breve e ben specificato. Ha eguagliato Fable su tutte le 29 verifiche di codice, e la stima a tariffa standard di Fable valeva 4,7 volte quella di Opus.

Trattate Fable 5.2 come il candidato successivo per ragionamento impegnativo o cicli di strumenti lunghi, dopo che Opus con effort più alto fallisce sui vostri casi reali. È il posizionamento di Anthropic; questa esecuzione copre solo le quattro attività piccole. Testate 10–20 fallimenti reali prima di cambiare.

Il post di lancio di Fable 5.2 di Anthropic aggiunge un dato dichiarato dal fornitore: Fable 5.2 in High ha segnato 45,3 % su FrontierCode 2.0 contro 45,5 % di Opus 5.5 in Max, a circa metà del costo per attività. Il post dice anche che Fable 5.2 in Xhigh arriva a 49,1 %, il punteggio più alto tra i modelli pubblicati testati. Questo accoppia Fable High con Opus Max, un confronto diverso dal nostro test a medium uguale.

Su un progetto reale confrontate la spesa API con il tempo di nuovi tentativi e revisione per attività utilizzabile. Su lavoro piccolo che già passa, Opus è la scelta predefinita più economica.

Per usare uno dei due modelli in Claude Code, la guida alla configurazione di Claude Code indica la base URL e le impostazioni della chiave. Pagine modello: Claude Fable 5.2 e Claude Opus 5.5.

Domande frequenti

Fable 5.2 vale il prezzo più alto rispetto a Opus 5.5?

Valutate Fable dopo che Opus con effort più alto ha fallito sui vostri casi, e verificate che Fable li migliori; questa esecuzione non dà un verdetto sulle attività difficili. Sulle nostre quattro attività piccole entrambi hanno superato 29/29 verifiche di codice; la stima a tariffa standard di Fable è stata $0,1457 contro $0,0310 di Opus.

Fable 5.2 e Opus 5.5 hanno superato gli stessi test di codice?

Sì. Entrambi hanno superato 8/8 casi d'uso, 14/14 casi di cursore e 7/7 casi di patch di file. Anche la risposta del registro era corretta su entrambi, con una differenza di formato: Opus ha aggiunto un blocco di codice JSON.

Quale costa meno per programmare, Fable 5.2 o Opus 5.5?

Ai listini standard di Anthropic, Opus 5.5: $4 di input e $20 di output per milione di token contro $8 e $40. Con i nostri token la stima a tariffa standard di Fable è 4,7 volte quella di Opus: $0,1457 contro $0,0310 su quattro attività.

Fable 5.2 è più veloce di Opus 5.5?

La nostra esecuzione lascia la domanda aperta. I totali osservati sono stati 27,8 s per Fable e 43,6 s per Opus, ma le risposte di Fable dichiaravano velocità standard e quelle di Opus fast, e non abbiamo impostato la velocità. Confrontateli di nuovo con la stessa impostazione di velocità.

Posso usare entrambi i modelli in Claude Code tramite OmniaKey?

Sì. In questa esecuzione abbiamo chiamato entrambi gli ID modello tramite OmniaKey, e la guida alla configurazione di Claude Code mostra la base URL e la chiave. Dopo il collegamento controllate il nome del modello nel vostro client.

Fonti verificate

• Anthropic: Panoramica del modello Claude Fable 5.2
• Anthropic: Introducing Claude Fable 5.2 and Mythos 5.2
• Anthropic: Panoramica del modello Claude Opus 5.5
• Anthropic: Panoramica dei modelli
• Anthropic: Prezzi

Tutte verificate il 12 nov 2026.