Claude Platform Docs
Bonnes pratiquesIngénierie de prompts

Rédiger des prompts pour Claude Fable 5.1

Différences de comportement et modèles de prompting pour Claude Fable 5.1 et Claude Mythos 5.1, couvrant l'effort, les mises à jour de progression, le regroupement des appels d'outils, l'historique de conversation, le style d'écriture, le formatage, l'achèvement des tâches, les résumés de compaction, la portée et la couverture de tests, le déclenchement de la recherche, les faux positifs des garde-fous, les modifications de fichiers, les sorties longues, les sous-agents et la vision.

Pour les capacités du modèle, les changements d'API, la tarification et la disponibilité, consultez Nouveautés de Claude Fable 5.1. Pour les techniques qui s'appliquent à l'ensemble des modèles Claude, consultez Bonnes pratiques de prompting.

Vos prompts existants pour Claude Fable 5 devraient bien fonctionner sur Claude Fable 5.1 sans modification, mais quelques différences de comportement méritent d'être connues. Commencez par la section qui correspond à ce que vous observez :

Envisagez tous les niveaux d'effort

Commencez au niveau d'effort par défaut, high, puis testez les autres niveaux (low, medium, xhigh et max) sur vos propres évaluations. L'effort est le principal levier pour arbitrer entre intelligence, latence et coût sur Claude Fable 5.1. Relancez le balayage même si vous en avez déjà effectué un sur Claude Fable 5 : les noms des niveaux d'effort ne correspondent pas à la même quantité de réflexion d'un modèle à l'autre.

Les gains de capacité de Claude Fable 5.1 par rapport à Claude Fable 5 apparaissent à tous les niveaux d'effort et sont les plus importants aux réglages les plus élevés. À medium, les résultats correspondent à peu près à ceux de Claude Fable 5 pour un coût inférieur ; descendez donc à medium ou low là où vos évaluations montrent que la qualité se maintient. À low, Claude Fable 5.1 est souvent compétitif avec les modèles Claude Opus et Claude Sonnet en coût par tâche tout en obtenant de meilleurs scores ; incluez-le donc dans la comparaison partout où vous exécuteriez autrement un modèle plus petit à un niveau d'effort plus élevé.

Deux comportements propres à l'effort ont leur propre section : à low, Claude Fable 5.1 appelle moins souvent les outils de recherche et de récupération (voir Déclenchement de la recherche à faible effort), et à xhigh et max, il peut réfléchir plus longtemps avant de rédiger un livrable long (voir Laissez de la place pour les sorties longues aux efforts xhigh et max).

Demandez des mises à jour de progression destinées à l'utilisateur

Le comportement par défaut de Claude Fable 5.1 consiste à écrire moins de mises à jour destinées à l'utilisateur pendant les longs tours d'appels d'outils que ne le fait Claude Fable 5. Cela devient plus marqué à effort élevé et dans les chaînes d'outils plus longues. Les utilisateurs voient l'agent se taire pendant plusieurs minutes d'affilée, ou un message final qui ne couvre que la dernière étape plutôt que la tâche entière.

Tout d'abord, vérifiez que votre client reçoit bien les mises à jour de progression. Les courtes notes du modèle entre les appels d'outils, ce qu'il vient de trouver et ce qu'il fait ensuite, reviennent sous forme de blocs thinking de mise à jour de progression, et ces blocs sont vides avec la valeur par défaut de thinking.display, "omitted". Définissez display: "updates" (bêta, en-tête thinking-display-updates-2026-08-18) et affichez chaque bloc thinking non vide comme une ligne d'état, ou définissez "summarized" pour les recevoir accompagnés d'un raisonnement résumé. Si vous ne les demandez pas, il est possible que les mises à jour du modèle n'atteignent tout simplement pas vos utilisateurs.

Ensuite, passez en revue votre prompt à la recherche d'instructions qui suppriment la narration. Certains modèles antérieurs étaient enclins à donner des mises à jour pendant leur travail, ce qui a conduit à des lignes d'invite système telles que « conserve toutes les conclusions pour la réponse finale ». Supprimez ce type de lignes avant d'ajouter quoi que ce soit.

Si vous souhaitez toujours davantage de mises à jour, par exemple en programmation en binôme ou dans d'autres travaux avec un humain dans la boucle, ajoutez une courte ligne d'invite système qui indique quand vous voulez du texte destiné à l'utilisateur de la part du modèle et ce que chaque mise à jour doit contenir :

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.

Si votre produit replie ou masque la sortie des outils, dites-le au modèle. Sinon, il pourrait exécuter des commandes pour « montrer » à l'utilisateur une sortie que votre interface n'affiche jamais. Transmettez la note dans un message système à portée de tour (clear_at: "next_user_message", bêta) :

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.

Regroupez les appels d'outils indépendants dans les boucles d'agent

Claude Fable 5.1 émet généralement des appels d'outils parallèles comme prévu : lorsqu'une requête nomme plusieurs éléments à récupérer, il émet ces appels en parallèle. L'exception concerne les boucles de code et d'utilisation de l'ordinateur où les prochains appels indépendants sont impliqués par la tâche plutôt qu'explicitement demandés (agents de code personnalisés, harnais bash-et-éditeur, utilisation de l'ordinateur) : dans ce cas, il peut les émettre un par tour. Cela n'affecte pas la qualité des réponses, mais chaque tour supplémentaire coûte des tokens, un aller-retour et du temps réel. Une incitation d'une phrase à la fin de la requête en cours y remédie :

First privately list what you need next; then request every item that doesn't depend on another's result in this one response.

Chaque fois que vous renvoyez des résultats d'outils, ajoutez-la après ce message utilisateur sous forme de message système à portée de tour : une entrée role: "system" dans messages avec clear_at: "next_user_message". Dès qu'un message utilisateur ultérieur existe, l'API efface les copies antérieures, de sorte que le modèle ne lit que la plus récente. Les messages système à portée de tour sont en bêta et nécessitent l'en-tête bêta mid-conversation-system-clear-at-2026-08-21. Sans la bêta, placez plutôt la phrase dans un bloc de texte après les blocs tool_result dans le même message utilisateur.

Ajoutez une nouvelle copie à chaque tour et laissez les copies antérieures là où elles sont, octet pour octet. Elles restent dans le tableau, mais une fois effacées, le modèle ne les voit pas et elles ne coûtent aucun token d'entrée. Les supprimer ou les réécrire constitue une modification des tours antérieurs : cela redémarre le cache de prompts à partir de ce point et invalide les blocs de réflexion qui les suivaient (voir Gardez l'historique de conversation en ajout seul).

La boucle suivante illustre ce placement. Chaque tour de l'assistant est renvoyé exactement tel qu'il a été reçu, chaque tour utilisateur ne contient que les résultats d'outils, et une nouvelle copie à portée de tour de l'incitation le suit.

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."
)
# Des fichiers en mémoire remplacent un répertoire de travail pour que l'exemple s'exécute partout.
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,
    )
    # Ajoutez le tour de l'assistant exactement tel que renvoyé, blocs de réflexion inclus.
    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,
                    }
                )
    # Envoyez les résultats d'outils comme tour utilisateur, puis une nouvelle copie de l'incitation en tant que
    # message système limité au tour. Laissez les copies précédentes en place : l'API les efface,
    # de sorte que le modèle ne voit que la plus récente.
    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"), ""))

Gardez l'historique de conversation en ajout seul

Ajoutez chaque tour de l'assistant à l'historique exactement tel que l'API l'a renvoyé, blocs de réflexion compris, et ne modifiez pas les tours antérieurs entre les requêtes. Pour les nouveaux comptes créés à partir du 31 août 2026, les blocs de réflexion de Claude Fable 5.1 ne sont valides que dans la conversation exacte qui les a produits : une requête qui rejoue un bloc de réflexion après que son préfixe (l'invite système, la liste d'outils ou tout message antérieur) a changé renvoie une erreur 400, ou supprime les blocs concernés si vous définissez thinking.block_binding.prefix_mismatch_behavior: "drop_block" (bêta, en-tête thinking-binding-controls-2026-08-01). Les futurs modèles devraient appliquer cette vérification à tous les comptes ; adoptez donc ce modèle dès maintenant, même si elle n'est pas appliquée au vôtre aujourd'hui.

Les modifications d'historique qui déclenchent la vérification sont les mêmes que celles qui redémarrent le cache de prompts : injecter et retirer des rappels par tour, résumer sur place des tours plus anciens, ou changer l'invite système en cours de session. Envoyez les rappels par tour sous forme de messages système à portée de tour, modifiez les instructions ou les outils avec un message système en cours de conversation au lieu de réécrire system ou tools, et laissez la compaction côté serveur ou l'édition de contexte effectuer tout élagage. Si vous compactez côté client, la forme la plus simple consiste à remplacer tout l'historique par un seul message de résumé plus le nouveau tour utilisateur et à ne rien rejouer d'autre : aucun bloc de réflexion n'est reporté, donc rien n'échoue, et le modèle réfléchit à nouveau sur la conversation compactée (voir Compaction personnalisée côté client). Comme les lectures de cache sont désormais moins chères (voir Tarification), compacter tôt pour réduire les coûts n'est peut-être plus le bon compromis coût-intelligence sur Claude Fable 5.1 ; expérimentez donc avec des points de compaction plus tardifs.

Pour repérer les modifications que votre harnais effectue déjà, exécutez une session avec prefix_mismatch_behavior: "drop_block" et journalisez input_transformations, comme décrit dans Comment savoir si votre intégration est concernée, ou capturez les requêtes exactes qu'il envoie sur quelques tours normaux et confirmez que les requêtes consécutives sont identiques octet pour octet jusqu'aux tours ajoutés.

Densité de l'écriture

L'écriture de Claude Fable 5.1 est généralement un cran au-dessus de celle des modèles Claude antérieurs, avec moins de formules toutes faites et moins de jargon inexpliqué. Dans certains cas, cependant, sa prose est plus dense que celle de Claude Fable 5 : les phrases sont plus longues et il y a moins de sauts de paragraphe. Une instruction qui définit l'anti-modèle, la prose maniérée, aide. Ajoutez-la à un message utilisateur (de préférence) ou à l'invite système :

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.

La version courte tend également à fonctionner :

Please remove all mannered prose.

Formatage en chat

Les modèles antérieurs abusaient des puces et du gras en chat, et de nombreux prompts comportent des règles anti-formatage écrites pour contenir cela. Claude Fable 5.1 penche dans l'autre sens : il utilise moins le gras et est moins enclin à recourir aux titres, aux listes ou aux guillemets. Si votre prompt contient des formulations anti-formatage, supprimez-les ou remplacez-les par une règle qui indique quand un formatage spécifique est approprié, comme la suivante :

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.

Citation des sources récupérées

Lorsqu'il résume des documents, Claude Fable 5.1 est plus susceptible que Claude Fable 5 de reproduire des passages du texte source sans les signaler comme citations. Pour y remédier, ajoutez à l'invite système un exemple complet de réponse correcte : la requête de l'utilisateur, la réponse, et une phrase expliquant pourquoi la réponse est correcte.

<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>

Remplacez les deux lignes [web_search: ...] par le nom de votre propre outil, afin que le modèle les lise comme une sortie d'outil modélisée plutôt que comme du texte littéral à émettre.

Terminez la tâche entière

Claude Fable 5.1 peut exécuter des tâches très longues sans beaucoup d'indications méthodologiques, surtout lorsque l'objectif est clair. Sur des charges de travail asynchrones complexes, cependant, incitez-le à ne pas terminer son tour avant que le travail ne soit achevé. Sans cette incitation, le modèle décrit parfois ce qu'il ferait ensuite au lieu de le faire (« Ensuite, je vais… ») ou s'arrête pour demander la permission d'effectuer une étape que la requête initiale couvrait déjà (« Dois-je appliquer ceci ? »). Les utilisateurs doivent répondre « continue » ou « vas-y », ce qui convient à la programmation en binôme et à d'autres travaux avec un humain dans la boucle, mais n'exploite pas toute la capacité à long horizon du modèle.

Deux ajouts à l'invite système atténuent ensemble ce problème. Appliquez les deux. Si vous devez limiter la longueur du prompt, n'utilisez que le premier, qui conserve l'essentiel de l'effet. Le premier indique au modèle de ne pas poser de questions sur un travail déjà demandé et d'exécuter les prochaines étapes qu'il a énoncées :

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 phrase d'ouverture, qui indique au modèle que l'utilisateur ne regarde pas, porte une grande partie de l'effet. Conservez-la telle qu'elle est écrite. Si votre produit a besoin que le modèle s'arrête pour des confirmations spécifiques, ajoutez après elle une phrase qui les énumère. Ce bloc peut également rendre le modèle moins enclin à poser des questions sur des requêtes ambiguës ; vérifiez donc ce compromis sur vos propres tâches.

Le second définit la requête de l'utilisateur comme la portée du livrable :

# 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.

Indiquez au modèle ce qu'il doit préserver dans les résumés de compaction

Claude Fable 5.1 réagit bien lorsqu'on lui indique explicitement ce que son résumé doit conserver lorsqu'une longue conversation est compactée. La compaction côté serveur le fait déjà. Si vous compactez côté client, utilisez l'instruction de résumé suivante :

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.

Limitez les modifications et les tests à ce que la tâche demande

Lorsqu'on lui demande d'implémenter une fonctionnalité ouverte, Claude Fable 5.1 livre ce qui est demandé et parfois davantage : il peut corriger du code voisin, étendre un comportement que la tâche ne mentionnait pas, ou valider plus de fichiers de test que la modification ne le justifie. Il réagit bien aux instructions explicites sur ce qu'il faut laisser de côté. Avec l'instruction suivante, les ajouts non demandés et le code de test validé diminuent considérablement sans changement mesurable du taux de réussite des tâches :

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.

Déclenchement de la recherche à faible effort

À l'effort low, Claude Fable 5.1 est moins susceptible que Claude Fable 5 d'appeler un outil de recherche ou de récupération, et plus susceptible de répondre de mémoire. Dans certains cas, la solution la plus simple consiste à augmenter l'effort pour les tours concernés plutôt que pour toute la conversation. Consultez Changer l'effort en cours de conversation.

Dans d'autres cas, une incitation du prompt vers la vérification aide. Dans l'invite système, indiquez que reconnaître un nom n'est pas la même chose que connaître son état actuel, et que ces noms doivent être recherchés tels que l'utilisateur les a écrits :

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.

Réduisez les faux positifs des garde-fous

Les classificateurs de sécurité de Claude Fable 5.1 produisent moins de faux positifs que ceux de Claude Fable 5 à son lancement, et la recherche de vulnérabilités dans le code source est autorisée. Des faux positifs se produisent encore, et une requête bloquée renvoie stop_reason: "refusal" (voir Refus, repli et facturation). Trois situations les rendent plus probables :

  • Formulation de type vérification de compilation : Au lieu de « Ce programme compile-t-il sans erreurs ? », demandez « Y a-t-il des bugs dans ce programme ? ».
  • Langages de programmation moins connus : Donnez au modèle du contexte sur ce qu'est le langage et son fonctionnement, par exemple en lui donnant accès à la documentation du langage.
  • Base64 dans la sortie des outils : Les outils qui renvoient des données encodées en base64 dans le contexte du modèle peuvent déclencher des faux positifs ; les supprimer est donc la solution recommandée.

Préférez les modifications ciblées aux réécritures de fichiers entiers

Si Claude Fable 5.1 réécrit des fichiers entiers pour de petites modifications, ajoutez l'instruction suivante à l'invite système ou au premier message utilisateur. Claude Fable 5.1 est plus susceptible que Claude Fable 5 de réécrire un fichier texte entier plutôt que d'effectuer une modification ciblée. Le fichier résultant est généralement le même, mais à moins que le fichier ne soit court ou que la majeure partie ne change, une réécriture coûte plus de tokens de sortie et de temps. L'instruction ramène Claude Fable 5.1 au niveau de Claude Fable 5 pour les modifications petites et moyennes.

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.

Laissez de la place pour les sorties longues aux efforts xhigh et max

À l'effort xhigh et surtout max, Claude Fable 5.1 peut réfléchir plus longtemps avant de commencer à rédiger sa réponse. Lorsqu'une seule requête demande un livrable long, comme la réécriture complète d'un long document, il peut rédiger une grande partie de ce livrable dans sa réflexion puis le réécrire comme réponse, ce qui signifie une attente plus longue et plus de tokens de sortie. L'approche la plus simple consiste à exécuter ce type de requêtes à high, le point de départ recommandé, et à ne passer à xhigh ou max que là où vous avez mesuré un gain de qualité (voir Envisagez tous les niveaux d'effort). Si vous les exécutez tout de même à xhigh ou max :

  • Définissez max_tokens de façon à laisser de la place pour la réflexion et la réponse, et pas seulement pour la longueur de réponse que vous attendez.
  • Ajoutez la note suivante à la fin du message utilisateur. Elle raccourcit considérablement la réflexion sur les requêtes de prose et de code. Remplacez [max_tokens] par la valeur réelle de max_tokens de la requête, par exemple 64 000.
Everything produced in one reply, including any reasoning or drafting done 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.

Laissez l'agent principal continuer à travailler pendant que les sous-agents s'exécutent

Si votre agent de code permet à Claude Fable 5.1 de déléguer du travail à des sous-agents, ne forcez pas l'agent principal à s'arrêter et à attendre chacun d'eux. Sur les tâches de code, laisser l'agent principal continuer pendant que les sous-agents s'exécutent réduit le temps moyen d'achèvement pour une qualité, une consommation de tokens et un coût similaires. Pour mettre cela en place :

  • Faites en sorte que l'outil qui démarre un sous-agent retourne immédiatement.
  • Renvoyez le résultat de chaque sous-agent à l'agent principal dans un message user ultérieur une fois qu'il est prêt.
  • Donnez à l'agent principal un outil distinct qu'il peut appeler lorsqu'il souhaite attendre un résultat.

Le modèle choisit encore souvent d'attendre. Les gains de temps proviennent des exécutions où il poursuit d'autres travaux.

Donnez au travail de vision des outils pour recadrer et zoomer

Claude Fable 5.1 dispose de meilleures capacités de vision dès le départ, et sur des entrées visuelles complexes telles que des graphiques denses, il fournit son meilleur travail lorsqu'il peut analyser, recadrer et vérifier visuellement de manière itérative ce qu'il voit. Pour en tirer pleinement parti, exécutez le modèle en tant qu'agent avec accès à un conteneur qui contient les images ou vidéos brutes et dispose de bibliothèques de traitement d'images de base (telles que PIL et OpenCV) préinstallées. Si l'exécution d'un conteneur représente une charge trop importante, un outil de recadrage d'image seul apporte l'essentiel du gain : un outil qui renvoie une région choisie de l'image, recadrée et agrandie, permet au modèle d'examiner des détails spécifiques plus en profondeur et fait évoluer le calcul au moment du test avec les tokens d'image. La recette de l'outil de recadrage en propose une définition fonctionnelle.

Was this page helpful?