Claude Platform Docs
Best practicePrompt engineering

Prompting per Claude Fable 5.1

Differenze comportamentali e pattern di prompting per Claude Fable 5.1 e Claude Mythos 5.1, che coprono effort, aggiornamenti di avanzamento, raggruppamento delle chiamate agli strumenti, cronologia della conversazione, stile di scrittura, formattazione, completamento delle attività, riepiloghi di compattazione, ambito e copertura dei test, attivazione della ricerca, falsi positivi delle protezioni, modifiche ai file, output lunghi, subagenti e visione.

Per le capacità del modello, le modifiche all'API, i prezzi e la disponibilità, consulta Novità di Claude Fable 5.1. Per le tecniche che si applicano a tutti i modelli Claude, consulta Best practice di prompting.

I tuoi prompt esistenti per Claude Fable 5 dovrebbero funzionare bene su Claude Fable 5.1 senza modifiche, ma vale la pena conoscere alcune differenze comportamentali. Inizia dalla sezione che corrisponde a ciò che osservi:

Considera tutti i livelli di effort

Inizia dal livello di effort (impegno) predefinito, high, poi testa gli altri livelli (low, medium, xhigh e max) sulle tue eval. L'effort è il controllo principale per bilanciare intelligenza, latenza e costo su Claude Fable 5.1. Ripeti la scansione anche se ne hai già eseguita una su Claude Fable 5: i nomi dei livelli di effort non corrispondono alla stessa quantità di pensiero tra modelli diversi.

I miglioramenti di capacità di Claude Fable 5.1 rispetto a Claude Fable 5 si manifestano a tutti i livelli di effort e sono maggiori alle impostazioni più alte. A medium, i risultati corrispondono all'incirca a quelli di Claude Fable 5 a un costo inferiore, quindi scendi a medium o low dove le tue eval mostrano che la qualità regge. A low, Claude Fable 5.1 è spesso competitivo con i modelli Claude Opus e Claude Sonnet in termini di costo per attività pur ottenendo punteggi più alti, quindi includilo nel confronto ovunque altrimenti eseguiresti un modello più piccolo a un livello di effort più alto.

Due comportamenti specifici dell'effort hanno sezioni dedicate: a low, Claude Fable 5.1 chiama meno spesso gli strumenti di ricerca e recupero (vedi Attivazione della ricerca a effort basso), e a xhigh e max può pensare più a lungo prima di scrivere un deliverable lungo (vedi Lascia spazio per output lunghi a effort xhigh e max).

Chiedi aggiornamenti di avanzamento rivolti all'utente

Il comportamento predefinito di Claude Fable 5.1 è scrivere meno aggiornamenti rivolti all'utente durante i lunghi turni di chiamate agli strumenti rispetto a Claude Fable 5. Questo diventa più marcato a effort più alto e in catene di strumenti più lunghe. Gli utenti vedono l'agente restare in silenzio per minuti interi, oppure un messaggio finale che copre solo l'ultimo passaggio anziché l'intera attività.

Per prima cosa, verifica che il tuo client riceva effettivamente gli aggiornamenti di avanzamento. Le brevi note del modello tra le chiamate agli strumenti, cosa ha appena trovato e cosa farà dopo, arrivano come blocchi thinking di aggiornamento di avanzamento, e quei blocchi sono vuoti con il valore predefinito di thinking.display pari a "omitted". Imposta display: "updates" (beta, header thinking-display-updates-2026-08-18) e visualizza ogni blocco thinking non vuoto come riga di stato, oppure imposta "summarized" per riceverli insieme al ragionamento riassunto. Se non li stai richiedendo, gli aggiornamenti del modello potrebbero semplicemente non raggiungere i tuoi utenti.

In secondo luogo, controlla il tuo prompt alla ricerca di istruzioni che sopprimono la narrazione. Alcuni modelli precedenti erano propensi a fornire aggiornamenti durante il lavoro, il che ha portato a righe nel prompt di sistema come "conserva tutti i risultati per la risposta finale". Rimuovi righe di questo tipo prima di aggiungere qualsiasi cosa.

Se vuoi comunque più aggiornamenti, ad esempio nel pair programming o in altri lavori con un umano nel ciclo, aggiungi una breve riga al prompt di sistema che indichi quando vuoi testo rivolto all'utente dal modello e cosa deve contenere ogni aggiornamento:

Before you start, say in a line what you're about to do; brief updates while you work help the user follow along. Close with a short recap that stands on its own — what you found, what you did, and what's next — so a reader who only sees the last message has the full picture.

Se il tuo prodotto comprime o nasconde l'output degli strumenti, dillo al modello. Altrimenti potrebbe eseguire comandi per "mostrare" all'utente un output che la tua UI non visualizza mai. Fornisci la nota in un messaggio di sistema con ambito di turno (clear_at: "next_user_message", beta):

Only you see that command's output — the user's terminal shows at most a few lines of it. If the user needs to read any of it, put it in your reply.

Raggruppa le chiamate indipendenti agli strumenti nei loop degli agenti

Claude Fable 5.1 di solito emette chiamate parallele agli strumenti come previsto: quando una richiesta nomina diverse cose da recuperare, emette quelle chiamate in parallelo. L'eccezione sono i loop di coding e di computer use in cui le successive chiamate indipendenti sono implicite nell'attività anziché richieste esplicitamente (agenti di coding personalizzati, harness bash-e-editor, computer use): lì potrebbe emetterle una per turno. Questo non influisce sulla qualità della risposta, ma ogni turno aggiuntivo costa token, un round trip e tempo reale. Una spinta 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 rimandi indietro i risultati degli strumenti, aggiungila dopo quel messaggio utente come messaggio di sistema con ambito di turno: una voce role: "system" in messages con clear_at: "next_user_message". Una volta che esiste un messaggio utente successivo, l'API cancella le copie precedenti, quindi il modello legge solo la più recente. I messaggi di sistema con ambito di turno sono in beta e richiedono l'header beta mid-conversation-system-clear-at-2026-08-21. Senza la beta, inserisci invece la frase in un blocco di testo dopo i blocchi tool_result nello stesso messaggio utente.

Aggiungi una nuova copia a ogni turno e lascia le copie precedenti dove sono, byte per byte. Restano nell'array, ma una volta cancellate il modello non le vede e non costano token di input. Eliminarle o riscriverle è una modifica ai turni precedenti: riavvia la cache dei prompt da quel punto e invalida i blocchi di pensiero successivi (vedi Mantieni la cronologia della conversazione in sola aggiunta).

Il loop seguente mostra questo posizionamento. Ogni turno dell'assistente viene rimandato esattamente come restituito, ogni turno utente contiene solo i risultati degli strumenti, e una nuova copia con ambito di turno della spinta lo segue.

import anthropic
from anthropic.types.beta import (
    BetaMessageParam,
    BetaToolParam,
    BetaToolResultBlockParam,
)

client = anthropic.Anthropic()

BATCH_NUDGE = (
    "First privately list what you need next; then request every item "
    "that doesn't depend on another's result in this one response."
)
# In-memory files stand in for a working directory so the sample runs anywhere.
FILES = {
    "pyproject.toml": """\
[project]
name = "demo"
version = "0.1.0"
description = "Demo project for the batching example"
""",
    "README.md": """\
# demo

A small demo project. Run `demo --help` for usage.
""",
}
tools: list[BetaToolParam] = [
    {
        "name": "read_file",
        "description": "Read a UTF-8 text file from the working directory.",
        "input_schema": {
            "type": "object",
            "properties": {"path": {"type": "string"}},
            "required": ["path"],
        },
    }
]
messages: list[BetaMessageParam] = [
    {"role": "user", "content": "Summarize pyproject.toml and README.md."}
]

while True:
    response = client.beta.messages.create(
        model="claude-fable-5-1",
        max_tokens=16000,
        betas=["mid-conversation-system-clear-at-2026-08-21"],
        tools=tools,
        messages=messages,
    )
    # Append the assistant turn exactly as returned, thinking blocks included.
    messages.append({"role": "assistant", "content": response.content})
    if response.stop_reason != "tool_use":
        break
    tool_results: list[BetaToolResultBlockParam] = []
    for block in response.content:
        if block.type == "tool_use":
            raw_path = block.input.get("path")
            path = raw_path if isinstance(raw_path, str) else ""
            if path in FILES:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": FILES[path],
                    }
                )
            else:
                tool_results.append(
                    {
                        "type": "tool_result",
                        "tool_use_id": block.id,
                        "content": f"File not found: {path}",
                        "is_error": True,
                    }
                )
    # Send the tool results as the user turn, then a fresh copy of the nudge as a
    # turn-scoped system message. Leave earlier copies in place: the API clears them,
    # so the model sees only the newest one.
    messages.append({"role": "user", "content": tool_results})
    messages.append(
        {"role": "system", "content": BATCH_NUDGE, "clear_at": "next_user_message"}
    )

print(next((block.text for block in response.content if block.type == "text"), ""))

Mantieni la cronologia della conversazione in sola aggiunta

Aggiungi ogni turno dell'assistente alla cronologia esattamente come l'API lo ha restituito, blocchi di pensiero inclusi, e non modificare i turni precedenti tra una richiesta e l'altra. Per i nuovi account creati a partire dal 31 agosto 2026, i blocchi di pensiero di Claude Fable 5.1 sono validi solo nell'esatta conversazione che li ha prodotti: una richiesta che ripropone un blocco di pensiero dopo che il suo prefisso (il prompt di sistema, l'elenco degli strumenti o qualsiasi messaggio precedente) è cambiato restituisce un 400, oppure scarta i blocchi interessati se imposti thinking.block_binding.prefix_mismatch_behavior: "drop_block" (beta, header thinking-binding-controls-2026-08-01). Si prevede che i modelli futuri applichino questo controllo a tutti gli account, quindi adotta il pattern ora anche se per il tuo account non è ancora applicato.

Le modifiche alla cronologia che fanno scattare il controllo sono le stesse che riavviano la cache dei prompt: inserire e rimuovere promemoria per turno, riassumere sul posto i turni più vecchi o cambiare il prompt di sistema a metà sessione. Invia i promemoria per turno come messaggi di sistema con ambito di turno, cambia istruzioni o strumenti con un messaggio di sistema a metà conversazione invece di riscrivere system o tools, e lascia che la compattazione lato server o la modifica del contesto si occupino di eventuali tagli. Se compatti sul client, la forma più semplice è sostituire l'intera cronologia con un unico messaggio di riepilogo più il nuovo turno utente e non riproporre nient'altro: nessun blocco di pensiero viene trasferito, quindi nulla fallisce, e il modello pensa da capo sulla conversazione compattata (vedi Compattazione personalizzata sul client). Poiché le letture dalla cache sono ora più economiche (vedi Prezzi), compattare presto per risparmiare sui costi potrebbe non essere più il giusto compromesso costo-intelligenza su Claude Fable 5.1, quindi sperimenta con punti di compattazione più tardivi.

Per trovare le modifiche che il tuo harness già effettua, esegui una sessione con prefix_mismatch_behavior: "drop_block" e registra input_transformations, come descritto in Come capire se la tua integrazione è interessata, oppure cattura le richieste esatte che invia nel corso di alcuni turni normali e conferma che le richieste consecutive siano identiche byte per byte fino ai turni aggiunti.

Densità della scrittura

La scrittura di Claude Fable 5.1 è generalmente un passo avanti rispetto ai modelli Claude precedenti, con meno frasi fatte 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, la prosa manierata, aiuta. Aggiungila a un messaggio utente (preferibile) o al prompt di sistema:

Mannered prose substitutes metaphor and flourish for direct statement. Instead of "a parameter worth varying," the mannered writer produces "a dial worth turning." Instead of "this point still matters," they write "this point earns its keep." The phrases exist to display the writer, not to convey the idea, and readers can tell. That is why mannered prose irritates: it makes the reader work harder so the writer can perform. It is also imprecise. Metaphors drag in connotations the writer did not choose and cannot control. The fix is to say what you mean. When a literal phrase is available, use it.

Anche la versione breve tende a funzionare:

Please remove all mannered prose.

Formattazione in chat

I modelli precedenti abusavano di elenchi puntati e grassetto in chat, e molti prompt contengono regole anti-formattazione scritte per contenerli. Claude Fable 5.1 tende nella direzione opposta: usa meno il grassetto ed è meno propenso a ricorrere a intestazioni, elenchi o virgolette. Se il tuo prompt contiene linguaggio anti-formattazione, rimuovilo o sostituiscilo con una regola che indichi quando una formattazione specifica è appropriata, come la seguente:

Use lists and bullet points when asked to, or when the content is multifaceted enough that they help with clarity. If the person explicitly requests minimal formatting, always format your responses without bullet points, headers, lists, or bold emphasis, as requested. In conversational, personal, or emotional exchanges, keep to plain prose.

Citare le fonti recuperate

Quando riassume documenti, Claude Fable 5.1 è più propenso di Claude Fable 5 a riprodurre passaggi del testo sorgente senza contrassegnarli come citazioni. Per risolvere il problema, aggiungi al prompt di sistema un esempio completo di risposta corretta: la richiesta dell'utente, la risposta e una frase che spiega perché la risposta è corretta.

<example>
<user>look up how the Riverton Ledger and the Coast Dispatch each covered the Harbor Bridge closure and compare their reporting</user>
<response>
[web_search: Harbor Bridge closure Riverton Ledger]
[web_search: Harbor Bridge closure Coast Dispatch]
Both outlets agree on the basics: the bridge closed on March 3 after inspectors found cracked welds, and the state expects repairs to take about eight months. Where they differ is emphasis. The Ledger treats it as a local-economy story. The Dispatch frames it as a funding failure; its editorial calls the closure "entirely foreseeable." Read together, the Ledger explains who is affected now and the Dispatch explains how it came to this — neither account alone gives the whole picture.
</response>
<rationale>CORRECT: The response is organized around where the two outlets agree and differ, not as a walk through either article. Each outlet's reporting is conveyed in one or two sentences of the assistant's own indirect speech. One short marked phrase from one source; every other claim is reworded. The response is still specific and complete.</rationale>
</example>

Sostituisci le due righe [web_search: ...] con il nome del tuo strumento, in modo che il modello le legga come output di strumento basato su template anziché come testo letterale da emettere.

Completa l'intera attività

Claude Fable 5.1 può eseguire attività molto lunghe senza molte indicazioni sulla metodologia, soprattutto quando l'obiettivo è chiaro. Su carichi di lavoro asincroni complessi, però, spingilo a non terminare il turno prima che il lavoro sia finito. Senza la spinta, il modello a volte descrive cosa farebbe dopo invece di farlo ("Ora procederò a …") oppure si ferma a chiedere il permesso per un passaggio già coperto dalla richiesta originale ("Devo applicarlo?"). Gli utenti devono rispondere "continua" o "procedi", il che va bene per il pair programming e altri lavori con un umano nel ciclo ma non sfrutta appieno la capacità del modello su orizzonti lunghi.

Due aggiunte al prompt di sistema insieme mitigano questo comportamento. Applicale entrambe. Se devi limitare la lunghezza del prompt, usa solo la prima, che mantiene la maggior parte dell'effetto. La prima dice al modello di non chiedere conferma per lavoro già richiesto e di eseguire i passaggi successivi che ha dichiarato:

You are operating autonomously. The user is not watching in real time and cannot answer questions mid-task, so asking 'Want me to…?' or 'Shall I…?' will block the work. For reversible actions that follow from the original request, proceed without asking. Stop only for destructive actions or genuine scope changes the user must decide. Offering follow-ups after the task is done is fine; asking permission before doing the work is not.

Exception: when the user is describing a problem, asking a question, or thinking out loud rather than requesting a change, the deliverable is your assessment. Report your findings and stop. Don't apply a fix until they ask for one.

Before ending your turn, check your last paragraph. If it is a plan, an analysis, a question, a list of next steps, or a promise about work you have not done ('I'll…', 'let me know when…'), do that work now with tool calls. That includes retrying after errors and gathering missing information yourself. Do not stop because the context or session is long. End your turn only when the task is complete or you are blocked on input only the user can provide.

Before running a command that changes system state (such as restarts, deletes, or config edits), check that the evidence actually supports that specific action. A signal that pattern-matches to a known failure may have a different cause.

La frase di apertura, che dice al modello che l'utente non sta guardando, porta gran parte dell'effetto. Mantienila così com'è scritta. Se il tuo prodotto richiede che il modello si fermi per conferme specifiche, aggiungi dopo di essa una frase che le elenchi. Questo blocco può anche rendere il modello meno propenso a chiedere chiarimenti su richieste ambigue, quindi verifica questo compromesso sulle tue attività.

La seconda definisce la richiesta dell'utente come ambito del deliverable:

# Delivering work
The user's request — or the plan they approved — sets the scope, and the scope is the deliverable: don't quietly narrow, widen, or swap it. Read ambiguity the way a careful colleague would: make routine judgment calls yourself, and check in only when different readings would lead to materially different work. If you see a real problem with the task as specified, say so in a sentence or two and keep building under stated assumptions; if the user hears the concern and reaffirms, that is their decision, so deliver the full request.

If a question comes up partway, first do everything that doesn't depend on the answer; then state the assumption you made, or — when going ahead on a wrong guess would be unsafe or would make the work useless — put the question at the end of a turn that also delivers that progress. If one part turns out to be blocked, complete every other part in full and say exactly what you left out and why — the whole task is the deliverable, and scaling it down is the user's call, not yours. A step you have decided on is something to run, not to announce: describing the next step and ending the turn leaves it undone until the user replies.

Keep changes to what the request needs. Something else you notice worth doing — cleanup or documentation the task didn't call for, a change to a file the task didn't require — is a suggestion to make at the end, not a change to make; actions clearly beyond what the ask implies, and risky or destructive ones, still need the user's go-ahead.

Indica al modello cosa preservare nei riepiloghi di compattazione

Claude Fable 5.1 risponde bene quando gli viene detto esplicitamente cosa il suo riepilogo deve conservare quando una lunga conversazione viene compattata. La compattazione lato server lo fa già. Se compatti lato client, usa la seguente istruzione di riepilogo:

Summarize the transcript inside <summary></summary> tags. Include relevant information in the summary such that this conversation will be continued by a new context window without needing to redo work or be reprovided with relevant constraints or context. Be sure to preserve: (1) any difficulties or problems that came up, and how they were handled or resolved; (2) any possibilities, options, or approaches that were raised, tried, or set aside, and why; (3) anything that was asked for, decided, agreed, ruled out, or established as a preference, constraint, or boundary — stated exactly; (4) exactly where things stand now — what has been covered, settled, or completed so far; (5) anything still open, unresolved, promised, or expected to happen next; (6) specific details that would be hard to reconstruct — names, numbers, dates, exact wording, links or references — kept exactly. Be complete on these even at the cost of length; keep everything else concise. Weight the two voices differently: keep what the user said, asked for, shared, or established carefully and close to their own words; your own explanations and reasoning can be condensed much further, to what they concluded or produced — as long as nothing in the six items above is dropped.

Limita modifiche e test a ciò che l'attività richiede

Quando gli viene chiesto di implementare una funzionalità aperta, Claude Fable 5.1 consegna ciò che è richiesto e a volte di più: potrebbe correggere codice vicino, estendere comportamenti che l'attività non menzionava o committare più file di test di quanto la modifica giustifichi. Risponde bene a istruzioni esplicite su cosa tralasciare. Con la seguente istruzione, le aggiunte non richieste e il codice di test committato diminuiscono sostanzialmente senza alcuna variazione misurabile nel successo dell'attività:

If, while working or testing, you find a pre-existing bug, a performance concern, or behavior the task doesn't mention, don't fix, optimize or extend it in this change unless the requested behavior cannot work without it; report it as a follow-up in your summary. Where the task is ambiguous, implement the reading its wording and the surrounding code most directly support, state that assumption in your summary, and don't build for the other readings as well. Verify your work however you like; scratch scripts and quick checks need not be kept. Commit tests only where the task asks for them or this repository already keeps tests for this kind of change, sized like the neighboring test files — roughly one focused test per stated behavior — and don't turn scratch checks into additional permanent test files. This is about extras only: implement every behavior the task asks for, completely.

Attivazione della ricerca a effort basso

A effort low, Claude Fable 5.1 è meno propenso di Claude Fable 5 a chiamare uno strumento di ricerca o recupero, e più propenso a rispondere a memoria. In alcuni casi la soluzione più semplice è aumentare l'effort per i turni interessati anziché per l'intera conversazione. Consulta Cambiare l'effort a metà conversazione.

In altri casi, aiuta una spinta nel prompt verso la verifica. Nel prompt di sistema, indica che riconoscere un nome non equivale a conoscerne lo stato attuale, e che tali nomi vanno cercati così come l'utente li ha scritti:

When a query centers on a name you do not confidently recognize, or recognize from a fast-moving area like AI models and developer tools where the landscape shifts within months, the name itself is the thing to verify: search before answering, and include the name as the user wrote it in at least one query alongside any reformulations. This holds even when you have some background on it — partial background is exactly what makes an out-of-date answer sound authoritative, so familiarity is not a reason to skip the search.

Riduci i falsi positivi delle protezioni

I classificatori di sicurezza di Claude Fable 5.1 producono meno falsi positivi di quanto facessero quelli di Claude Fable 5 al lancio, e trovare vulnerabilità nel codice sorgente è consentito. I falsi positivi si verificano ancora, e una richiesta bloccata restituisce stop_reason: "refusal" (vedi Rifiuti, fallback e fatturazione). Tre situazioni li rendono più probabili:

  • Formulazione da verifica di compilazione: Invece di "Questo programma compila senza errori?", chiedi "Ci sono bug in questo programma?"
  • Linguaggi di programmazione meno noti: Fornisci al modello contesto su cos'è il linguaggio e come funziona, ad esempio dandogli accesso alla documentazione del linguaggio.
  • Base64 nell'output degli strumenti: Gli strumenti che restituiscono dati codificati in base64 nel contesto del modello possono attivare falsi positivi, quindi rimuoverli è la soluzione consigliata.

Preferisci modifiche mirate alle riscritture dell'intero file

Se Claude Fable 5.1 riscrive file interi per piccole modifiche, aggiungi la seguente istruzione al prompt di sistema o al primo messaggio utente. Claude Fable 5.1 è più propenso di Claude Fable 5 a riscrivere un intero file di testo anziché effettuare una modifica mirata. Il file risultante è di solito lo stesso, ma a meno che il file sia breve o che la maggior parte di esso stia cambiando, una riscrittura costa più token di output e più tempo. L'istruzione riporta Claude Fable 5.1 in linea con Claude Fable 5 per modifiche piccole e medie.

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.

Lascia spazio per output lunghi a effort xhigh e max

A effort xhigh e soprattutto max, Claude Fable 5.1 può pensare più a lungo prima di iniziare a scrivere la risposta. Quando una singola richiesta chiede un deliverable lungo, come la riscrittura completa di un documento lungo, potrebbe abbozzare gran parte di quel deliverable nel suo pensiero e poi riscriverlo 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 consigliato, e passare a xhigh o max solo dove hai misurato un guadagno di qualità (vedi Considera tutti i livelli di effort). Se le esegui comunque a xhigh o max:

  • Imposta max_tokens in modo da lasciare spazio per il pensiero e la risposta, non solo per la lunghezza della risposta che ti aspetti.
  • Aggiungi la seguente nota alla fine del messaggio utente. Rende il pensiero molto più breve nelle richieste di prosa e codice. Sostituisci [max_tokens] con il valore effettivo di max_tokens della richiesta, ad esempio 64.000.
Everything produced in one reply, including any reasoning or drafting it does before the reply, counts toward a single limit of about [max_tokens] tokens. If that limit is reached before the reply is finished, the person receives a cut-off response and has to start over. Composing an entire output or deliverable in full as reasoning and then again as a reply would double the length of the turn without improving the result, so don't do that.

Instead, when the person has asked for a long or effort-intensive deliverable such as a multi-section document, a large table or dataset, or a complete code file, spend extra effort on understanding the request, checking the inputs the answer depends on, settling the structure and other difficult decisions, and otherwise using the reasoning space to reason and the output space to write an output. Usually it is not needed to draft an output multiple times.

Lascia che l'agente principale continui a lavorare mentre i subagenti sono in esecuzione

Se il tuo agente di coding consente a Claude Fable 5.1 di delegare lavoro ai subagenti, non forzare l'agente principale a fermarsi e attendere ciascuno di essi. Nelle attività di coding, lasciare che il principale continui mentre i subagenti sono in esecuzione riduce il tempo medio di completamento a parità di qualità, utilizzo di token e costo. Per configurarlo:

  • Fai in modo che lo strumento che avvia un subagente ritorni immediatamente.
  • Passa il risultato di ogni subagente al principale in un successivo messaggio user una volta pronto.
  • Fornisci al principale uno strumento separato che può chiamare quando vuole attendere un risultato.

Il modello sceglie comunque spesso di attendere. Il risparmio di tempo deriva dalle esecuzioni in cui prosegue con altro lavoro.

Fornisci al lavoro di visione strumenti per ritagliare e ingrandire

Claude Fable 5.1 ha migliori capacità di visione già pronte all'uso, e su input visivi complessi come grafici densi lavora al meglio quando può analizzare, ritagliare e verificare visivamente in modo iterativo ciò che vede. Per ottenere il massimo beneficio, esegui il modello come agente con accesso a un container che contenga le immagini o i video grezzi e abbia librerie di base per l'elaborazione delle immagini (come PIL e OpenCV) preinstallate. Se eseguire un container comporta troppo overhead, uno strumento di ritaglio delle immagini da solo fornisce la maggior parte del miglioramento: uno strumento che restituisce una regione scelta dell'immagine, ritagliata e ingrandita, consente al modello di esaminare dettagli specifici in maggiore profondità e scala il calcolo in fase di test con i token immagine. La ricetta dello strumento di ritaglio contiene una definizione funzionante.

Was this page helpful?