La documentazione ufficiale di Claude Fable 5.1 è uscita. E no, non è il solito elenco di feature con linguaggio da comunicato stampa. È una guida operativa scritta da chi evidentemente ha passato settimane a debuggare comportamenti strani in produzione.
Partiamo dalla cosa più importante: i vostri prompt per Claude Fable 5 dovrebbero funzionare senza modifiche. Dovrebbero. Nella pratica, ci sono una manciata di differenze comportamentali che vale la pena conoscere prima di scoprirle alle tre di notte mentre il cliente aspetta.
Gli effort level: il nuovo quadrante di controllo
Claude Fable 5.1 introduce cinque livelli di effort: low, medium, high (il default), xhigh e max. È il controllo primario per bilanciare intelligenza, latenza e costo. E qui arriva la prima sorpresa: i nomi dei livelli non corrispondono alla stessa quantità di ragionamento tra i modelli.
Tradotto: se avevate già fatto uno sweep degli effort level su Claude Fable 5, rifatelo. I guadagni di capacità rispetto al predecessore si vedono a tutti i livelli, ma sono più marcati sulle impostazioni alte. A ‘medium’, i risultati eguagliano grossomodo Claude Fable 5 a costo inferiore — il che significa che potete scalare verso il basso dove la qualità tiene. A ‘low’, Claude Fable 5.1 compete spesso con Claude Opus e i modelli Sonnet sul costo per task, segnando però punteggi più alti.
Due comportamenti specifici per livello hanno sezioni dedicate: a ‘low’, il modello chiama meno spesso tool di ricerca e retrieval; a ‘xhigh’ e ‘max’ può pensare più a lungo prima di scrivere un deliverable lungo, il che porta a…
Quando il modello va in silenzio radio
Claude Fable 5.1 scrive meno aggiornamenti user-facing durante i turni lunghi con chiamate a tool rispetto a Claude Fable 5. Questo diventa più pronunciato a effort alto e in catene di tool lunghe. Gli utenti vedono l’agente tacere per minuti, o un messaggio finale che copre solo l’ultimo step invece dell’intero task.
Prima cosa: verificate che il vostro client riceva gli aggiornamenti. Le brevi note del modello tra le chiamate a tool arrivano come blocchi ‘thinking’ di tipo ‘progress-update’, e questi blocchi sono vuoti con il default ‘thinking.display’ impostato su ‘omitted’. Impostate ‘display: updates’ (beta, header ‘thinking-display-updates-2026-08-18’) e renderizzate ogni blocco ‘thinking’ non vuoto come riga di stato.
Secondo: controllate il vostro prompt per istruzioni che sopprimono la narrazione. Alcuni modelli precedenti erano così entusiasti nel dare aggiornamenti che molti system prompt portano ancora righe tipo ‘hold all findings for the final response’. Rimuovetele prima di aggiungere altro.
Se volete ancora più aggiornamenti — per esempio nel pair programming o altro lavoro human-in-the-loop — aggiungete una riga breve al system prompt che dice quando volete testo user-facing dal modello e cosa ogni aggiornamento dovrebbe contenere.
Tool call parallele: quando il modello diventa timido
Claude Fable 5.1 di solito emette chiamate a tool parallele come ci si aspetta: quando una richiesta nomina diverse cose da recuperare, emette quelle chiamate in parallelo. L’eccezione sono i loop di coding e computer-use dove le prossime chiamate indipendenti sono implicite dal task piuttosto che esplicitamente richieste — lì potrebbe emetterle una per turno invece.
Questo non influisce sulla qualità della risposta, ma ogni turno extra costa token, un round trip e tempo reale. Una spintarella di una frase alla fine della richiesta corrente risolve il problema: ‘First privately list what you need next; then request every item that doesn’t depend on another’s result in this one response.’
Ogni volta che mandate indietro risultati di tool, appendetela dopo quel messaggio utente come ‘turn-scoped system message’: un entry ‘role: system’ in ‘messages’ con ‘clear_at: next_user_message’. I messaggi di sistema turn-scoped sono in beta e richiedono l’header ‘mid-conversation-system-clear-at-2026-08-21’.
La storia della conversazione è append-only (e guai a voi)
Ecco una cosa che farà imprecare qualcuno: appendete ogni turno assistant alla history esattamente come l’API l’ha restituito, blocchi thinking inclusi, e non modificate i turni precedenti tra le richieste. Per i nuovi account creati dal 31 agosto 2026 in poi, i blocchi thinking di Claude Fable 5.1 sono validi solo nell’esatta conversazione che li ha prodotti.
Una richiesta che riproduce un blocco thinking dopo che il suo prefisso (il system prompt, la lista dei tool, o qualsiasi messaggio precedente) è cambiato restituisce un 400. O droppa i blocchi interessati se impostate ‘thinking.block_binding.prefix_mismatch_behavior: drop_block’.
Le modifiche alla history che fanno scattare il check sono le stesse che riavviano la prompt cache: iniettare e rimuovere reminder per-turn, riassumere turni vecchi in place, o cambiare il system prompt a metà sessione. Mandate i reminder per-turn come messaggi di sistema turn-scoped, cambiate istruzioni o tool con un messaggio di sistema mid-conversation invece di riscrivere ‘system’ o ‘tools’.
Prosa densa e formatting minimalista
La scrittura di Claude Fable 5.1 è generalmente un passo avanti rispetto ai modelli Claude precedenti, con meno frasi standard e meno gergo non spiegato. In alcuni casi, però, la sua prosa è più densa di quella di Claude Fable 5: le frasi sono più lunghe e ci sono meno interruzioni di paragrafo.
Un’istruzione che definisce l’anti-pattern — ‘mannered prose’ — aiuta. La prosa manierata sostituisce metafora e fronzoli alla dichiarazione diretta. Invece di ‘un parametro che vale la pena variare’, lo scrittore manierato produce ‘una manopola che vale la pena girare’. Le frasi esistono per mostrare lo scrittore, non per trasmettere l’idea, e i lettori se ne accorgono.
I modelli precedenti abusavano di bullet e grassetto nella chat, e molti prompt portano ancora regole anti-formatting scritte per contenerlo. Claude Fable 5.1 pende dall’altra parte: usa meno il grassetto ed è meno propenso a usare header, liste o virgolette. Se il vostro prompt contiene linguaggio anti-formatting, rimuovetelo o sostituitelo con una regola che dice quando il formatting specifico è appropriato.
Citazioni dalle fonti: il problema del copia-incolla invisibile
Quando riassume documenti, Claude Fable 5.1 è più propenso di Claude Fable 5 a riprodurre passaggi del testo sorgente senza segnarli come citazioni. Per affrontare questo, aggiungete un esempio completo di risposta corretta al system prompt: la richiesta dell’utente, la risposta, e una frase che spiega perché la risposta è corretta.
L’esempio deve mostrare una risposta organizzata attorno a dove le fonti concordano e differiscono, non come una passeggiata attraverso gli articoli. Il reporting di ogni fonte va trasmesso in una o due frasi del discorso indiretto dell’assistant. Una breve frase marcata da una fonte; ogni altra affermazione va riformulata.
Finire il task completo (non fermarsi a metà)
Claude Fable 5.1 può eseguire task molto lunghi senza molta guida sulla metodologia, specialmente quando l’obiettivo è chiaro. Su workload asincroni complessi, però, spingetelo a non terminare il suo turno prima che il lavoro sia fatto. Senza la spinta, il modello a volte descrive cosa farebbe dopo invece di farlo (‘Next, I’ll…’) o si ferma a chiedere il permesso per uno step che la richiesta originale già copriva (‘Shall I apply this?’).
Due aggiunte al system prompt insieme mitigano questo. La prima dice al modello di non chiedere del lavoro già richiesto e di portare avanti i prossimi step che ha dichiarato. La frase di apertura, che dice al modello che l’utente non sta guardando, porta gran parte dell’effetto. Tenetela come scritta.
La seconda definisce la richiesta dell’utente come lo scope del deliverable: la richiesta dell’utente — o il piano che hanno approvato — imposta lo scope, e lo scope è il deliverable. Non restringetelo, allargatelo o scambiatelo silenziosamente.
Compaction summaries: cosa preservare
Claude Fable 5.1 risponde bene a essere detto esplicitamente cosa il suo riassunto deve mantenere quando una conversazione lunga viene compattata. La compaction lato server già fa questo. Se compattate lato client, usate un’istruzione di summarization specifica.
Il riassunto deve preservare: difficoltà o problemi emersi e come sono stati gestiti; possibilità, opzioni o approcci sollevati, provati o messi da parte, e perché; qualsiasi cosa richiesta, decisa, concordata, esclusa o stabilita come preferenza, vincolo o confine — esattamente come dichiarato; esattamente dove stanno le cose ora; qualsiasi cosa ancora aperta, irrisolta, promessa o che ci si aspetta accada dopo; dettagli specifici difficili da ricostruire — nomi, numeri, date, formulazione esatta, link o riferimenti — mantenuti esattamente.
Modifiche e test: solo quello che il task chiede
Quando gli viene chiesto di implementare una feature open-ended, Claude Fable 5.1 consegna quello che è stato chiesto e a volte di più: potrebbe fixare codice vicino, estendere comportamenti che il task non menzionava, o committare più file di test di quanto il cambiamento giustifichi. Risponde bene a istruzioni esplicite su cosa lasciare fuori.
Con un’istruzione specifica, aggiunte non richieste e codice di test committato calano sostanzialmente senza cambiamenti misurabili nel successo del task. Se, mentre lavorate o testate, trovate un bug pre-esistente, una preoccupazione di performance, o comportamento che il task non menziona, non fixatelo, ottimizzatelo o estendetelo in questo cambiamento a meno che il comportamento richiesto non possa funzionare senza — reportatelo come follow-up nel vostro riassunto.
Search triggering a low effort: memoria vs verifica
A effort ‘low’, Claude Fable 5.1 è meno propenso di Claude Fable 5 a chiamare un tool di search o retrieval, e più propenso a rispondere dalla memoria. In alcuni casi il fix più semplice è alzare l’effort per i turni interessati piuttosto che per l’intera conversazione.
In altri casi, una spinta nel prompt verso la verifica aiuta. Nel system prompt, dite che riconoscere un nome non è lo stesso che conoscerne lo stato attuale, e che tali nomi dovrebbero essere cercati come l’utente li ha scritti. Questo vale specialmente per aree in rapido movimento come modelli AI e tool per sviluppatori dove il panorama cambia in pochi mesi.
Falsi positivi dei safeguard
I classificatori di sicurezza di Claude Fable 5.1 producono meno falsi positivi di quelli di Claude Fable 5 al lancio, e trovare vulnerabilità nel codice sorgente è permesso. I falsi positivi accadono ancora, e una richiesta bloccata restituisce ‘stop_reason: refusal’. Tre situazioni li rendono più probabili: phrasing da compile-check (invece di ‘Does this program compile without errors?’, chiedete ‘Are there any bugs in this program?’); linguaggi di programmazione meno noti (date al modello contesto su cosa sia il linguaggio e come funzioni); base64 nell’output dei tool (i tool che restituiscono dati base64-encoded nel contesto del modello possono triggerare falsi positivi, quindi rimuoverli è il fix raccomandato).
Edit mirate vs riscrittura di interi file
Se Claude Fable 5.1 riscrive interi file per piccoli cambiamenti, appendete un’istruzione specifica al system prompt o al primo messaggio utente. Claude Fable 5.1 è più propenso di Claude Fable 5 a riscrivere un intero file di testo invece di fare un edit mirato. Il file risultante è di solito lo stesso, ma a meno che il file non sia corto o la maggior parte non stia cambiando, una riscrittura costa più token di output e tempo. L’istruzione riporta Claude Fable 5.1 in linea con Claude Fable 5 per cambiamenti piccoli e medi: ‘The number of tokens used to edit files is best minimized, all else being equal. Therefore, when it will not affect the end result, try to surgically edit a file rather than rewrite the entire thing.’
Output lunghi a xhigh e max effort
A effort ‘xhigh’ e specialmente ‘max’, Claude Fable 5.1 può pensare più a lungo prima di iniziare a scrivere la sua risposta. Quando una singola richiesta chiede un deliverable lungo, come una riscrittura completa di un documento lungo, potrebbe draftare gran parte di quel deliverable nel suo thinking e poi scriverlo di nuovo come risposta — il che significa un’attesa più lunga e più token di output.
L’approccio più semplice è eseguire richieste come queste a ‘high’, il punto di partenza raccomandato, e passare a ‘xhigh’ o ‘max’ solo dove avete misurato un guadagno di qualità. Se le eseguite a ‘xhigh’ o ‘max’, impostate ‘max_tokens’ per lasciare spazio al thinking e alla risposta, non solo alla lunghezza della risposta che vi aspettate.
Agenti deleganti: non bloccare il lead
Se il vostro coding agent lascia Claude Fable 5.1 delegare lavoro a subagent, non forzate il lead agent a fermarsi e aspettare ognuno. Su task di coding, lasciare che il lead continui mentre i subagent girano abbassa il tempo medio di completamento a qualità, uso di token e costo simili.
Per configurarlo: fate in modo che il tool che avvia un subagent ritorni immediatamente; passate il risultato di ogni subagent al lead in un messaggio ‘user’ successivo una volta che è pronto; date al lead un tool separato che può chiamare quando vuole aspettare un risultato. Il modello spesso sceglie comunque di aspettare. Il risparmio di tempo viene dalle run dove continua con altro lavoro.
Vision: crop e zoom fanno la differenza
Claude Fable 5.1 ha capacità di vision migliori out of the box, e su input visivi complessi come chart densi fa il suo lavoro migliore quando può iterativamente analizzare, croppare e verificare visivamente quello che vede. Per ottenere il beneficio completo, eseguite il modello come agent con accesso a un container che tiene le immagini o video raw e ha librerie base di image-processing (come PIL e OpenCV) pre-installate.
Se eseguire un container è troppo overhead, un tool di image-cropping da solo consegna la maggior parte dell’uplift: un tool che restituisce una regione scelta dell’immagine, croppata e ingrandita, lascia il modello esaminare dettagli specifici in più profondità e scala il test-time compute con i token immagine.
