Claude Platform Docs
Melhores práticasEngenharia de prompts

Criando prompts para o Claude Fable 5.1

Diferenças de comportamento e padrões de prompting para o Claude Fable 5.1 e o Claude Mythos 5.1, abrangendo esforço, atualizações de progresso, agrupamento de chamadas de ferramentas, histórico da conversa, estilo de escrita, formatação, conclusão de tarefas, resumos de compactação, escopo e cobertura de testes, acionamento de busca, falsos positivos de salvaguardas, edições de arquivos, saídas longas, subagentes e visão.

Para conhecer as capacidades do modelo, mudanças na API, preços e disponibilidade, consulte O que há de novo no Claude Fable 5.1. Para técnicas que se aplicam a todos os modelos Claude, consulte Melhores práticas de prompting.

Seus prompts existentes do Claude Fable 5 devem funcionar bem no Claude Fable 5.1 sem alterações, mas vale a pena conhecer algumas diferenças de comportamento. Comece pela seção que corresponde ao que você observa:

Considere todos os níveis de esforço

Comece no nível de "effort" (esforço) padrão, high, e depois teste os outros níveis (low, medium, xhigh e max) com suas próprias avaliações. Consulte esforço. O esforço é o principal controle para equilibrar inteligência, latência e custo no Claude Fable 5.1. Refaça a varredura mesmo que você já tenha feito uma no Claude Fable 5: os nomes dos níveis de esforço não correspondem à mesma quantidade de pensamento entre modelos.

Os ganhos de capacidade do Claude Fable 5.1 em relação ao Claude Fable 5 aparecem em todos os níveis de esforço e são maiores nas configurações mais altas. Em medium, os resultados correspondem aproximadamente aos do Claude Fable 5 a um custo menor, então desça para medium ou low onde suas avaliações mostrarem que a qualidade se mantém. Em low, o Claude Fable 5.1 costuma ser competitivo com os modelos Claude Opus e Claude Sonnet em custo por tarefa enquanto pontua mais alto, então inclua-o na comparação sempre que você, de outra forma, executaria um modelo menor em um nível de esforço mais alto.

Dois comportamentos específicos de esforço têm suas próprias seções: em low, o Claude Fable 5.1 chama ferramentas de busca e recuperação com menos frequência (consulte Acionamento de busca em esforço baixo), e em xhigh e max ele pode pensar por mais tempo antes de escrever um entregável longo (consulte Deixe espaço para saídas longas em esforço xhigh e max).

Peça atualizações de progresso voltadas ao usuário

O comportamento padrão do Claude Fable 5.1 é escrever menos atualizações voltadas ao usuário durante turnos longos de chamadas de ferramentas do que o Claude Fable 5. Isso se torna mais pronunciado em esforço mais alto e em cadeias de ferramentas mais longas. Os usuários veem o agente ficar em silêncio por minutos seguidos, ou uma mensagem final que cobre apenas a última etapa em vez da tarefa inteira.

Primeiro, verifique se seu cliente recebe atualizações de progresso. As notas curtas do modelo entre chamadas de ferramentas, o que ele acabou de encontrar e o que fará em seguida, retornam como blocos thinking de atualização de progresso, e esses blocos ficam vazios sob o thinking.display padrão de "omitted". Defina display: "updates" (beta, cabeçalho thinking-display-updates-2026-08-18) e renderize cada bloco thinking não vazio como uma linha de status, ou defina "summarized" para recebê-los junto com o raciocínio resumido. Se você não os estiver solicitando, as atualizações do modelo podem simplesmente não estar chegando aos seus usuários.

Segundo, audite seu prompt em busca de instruções que suprimam a narração. Alguns modelos anteriores eram ávidos por dar atualizações enquanto trabalhavam, o que levou a linhas de "system prompt" (prompt do sistema) como "guarde todas as descobertas para a resposta final". Remova linhas assim antes de adicionar qualquer coisa.

Se você ainda quiser mais atualizações, por exemplo em programação em par ou em outros trabalhos com humano no loop, adicione uma linha curta ao prompt do sistema que diga quando você quer texto voltado ao usuário vindo do modelo e o que cada atualização deve conter:

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 seu produto recolhe ou oculta a saída das ferramentas, diga isso ao modelo. Caso contrário, ele pode executar comandos para "mostrar" ao usuário uma saída que sua interface nunca exibe. Entregue a nota em uma mensagem de sistema com escopo de 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.

Agrupe chamadas de ferramentas independentes em loops de agente

O Claude Fable 5.1 geralmente emite chamadas de ferramentas paralelas como esperado: quando uma requisição nomeia várias coisas a buscar, ele emite essas chamadas em paralelo. A exceção são os loops de código e de uso de computador em que as próximas chamadas independentes estão implícitas na tarefa em vez de explicitamente solicitadas (agentes de código personalizados, harnesses de bash e editor, uso de computador): ali ele pode emiti-las uma por turno. Isso não afeta a qualidade da resposta, mas cada turno extra custa tokens, uma ida e volta e tempo de relógio. Um lembrete de uma frase no final da requisição atual resolve isso:

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

Cada vez que você enviar resultados de ferramentas de volta, acrescente-o após essa mensagem do usuário como uma mensagem de sistema com escopo de turno: uma entrada role: "system" em messages com clear_at: "next_user_message". Assim que existir uma mensagem de usuário posterior, a API limpa as cópias anteriores, de modo que o modelo lê apenas a mais recente. As mensagens de sistema com escopo de turno estão em beta e exigem o cabeçalho beta mid-conversation-system-clear-at-2026-08-21. Sem o beta, coloque a frase em um bloco de texto após os blocos tool_result na mesma mensagem do usuário.

Acrescente uma cópia nova a cada turno e deixe as cópias anteriores onde estão, byte a byte. Elas permanecem no array, mas, uma vez limpas, o modelo não as vê e elas não custam tokens de entrada. Excluí-las ou reescrevê-las é uma edição em turnos anteriores: isso reinicia o cache de prompt a partir daquele ponto e invalida os blocos de pensamento que vieram depois delas (consulte Mantenha o histórico da conversa somente com acréscimos).

O loop a seguir mostra esse posicionamento. Cada turno do assistente volta exatamente como foi retornado, cada turno do usuário carrega apenas os resultados das ferramentas, e uma cópia nova do lembrete com escopo de turno vem em seguida.

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"), ""))

Mantenha o histórico da conversa somente com acréscimos

Acrescente cada turno do assistente ao histórico exatamente como a API o retornou, incluindo os "thinking blocks" (blocos de pensamento), e não edite turnos anteriores entre requisições. Para novas contas criadas em ou após 31 de agosto de 2026, os blocos de pensamento do Claude Fable 5.1 são válidos apenas na conversa exata que os produziu: uma requisição que reenvia um bloco de pensamento depois que seu prefixo (o prompt do sistema, a lista de ferramentas ou qualquer mensagem anterior) mudou retorna um 400, ou descarta os blocos afetados se você definir thinking.block_binding.prefix_mismatch_behavior: "drop_block" (beta, cabeçalho thinking-binding-controls-2026-08-01). Espera-se que modelos futuros apliquem essa verificação a todas as contas, então adote o padrão agora mesmo que a sua não seja verificada hoje.

As edições de histórico que acionam a verificação são as mesmas que reiniciam o cache de prompt: injetar e remover lembretes por turno, resumir turnos antigos no lugar ou alterar o prompt do sistema no meio da sessão. Envie lembretes por turno como mensagens de sistema com escopo de turno, altere instruções ou ferramentas com uma mensagem de sistema no meio da conversa em vez de reescrever system ou tools, e deixe a compactação no lado do servidor ou a edição de contexto fazerem qualquer corte. Se você compactar no cliente, a forma mais simples é substituir todo o histórico por uma mensagem de resumo mais o novo turno do usuário e não reenviar mais nada: nenhum bloco de pensamento é carregado, então nada falha, e o modelo pensa do zero sobre a conversa compactada (consulte Compactação personalizada no cliente). Como as leituras de cache agora são mais baratas (consulte Preços), compactar cedo para economizar custo pode não ser mais o equilíbrio certo entre custo e inteligência no Claude Fable 5.1, então experimente pontos de compactação mais tardios.

Para encontrar edições que seu harness já faz, execute uma sessão com prefix_mismatch_behavior: "drop_block" e registre input_transformations, conforme descrito em Como saber se sua integração é afetada, ou capture as requisições exatas que ele envia ao longo de alguns turnos normais e confirme que requisições consecutivas são idênticas byte a byte até os turnos acrescentados.

Densidade da escrita

A escrita do Claude Fable 5.1 é, em geral, um avanço em relação aos modelos Claude anteriores, com menos frases prontas e menos jargão não explicado. Em alguns casos, porém, sua prosa é mais densa que a do Claude Fable 5: as frases ficam mais longas e há menos quebras de parágrafo. Uma instrução que defina o antipadrão, a prosa afetada, ajuda. Adicione-a a uma mensagem do usuário (preferível) ou ao prompt do 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.

A versão curta também tende a funcionar:

Please remove all mannered prose.

Formatação no chat

Modelos anteriores usavam marcadores e negrito em excesso no chat, e muitos prompts carregam regras antiformatação escritas para conter isso. O Claude Fable 5.1 tende para o outro lado: usa menos negrito e é menos propenso a recorrer a cabeçalhos, listas ou aspas. Se seu prompt contém linguagem antiformatação, remova-a ou substitua-a por uma regra que diga quando uma formatação específica é apropriada, como a seguinte:

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.

Citando fontes recuperadas

Ao resumir documentos, o Claude Fable 5.1 é mais propenso que o Claude Fable 5 a reproduzir trechos do texto-fonte sem marcá-los como citações. Para resolver isso, adicione ao prompt do sistema um exemplo completo de uma resposta correta: a solicitação do usuário, a resposta e uma frase explicando por que a resposta está correta.

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

Substitua as duas linhas [web_search: ...] pelo nome da sua própria ferramenta, para que o modelo as leia como saída de ferramenta em template em vez de texto literal a ser emitido.

Conclua a tarefa inteira

O Claude Fable 5.1 consegue executar tarefas muito longas sem muita orientação sobre metodologia, especialmente quando o objetivo é claro. Em cargas de trabalho assíncronas complexas, porém, lembre-o de não encerrar o turno antes de o trabalho estar concluído. Sem o lembrete, o modelo às vezes descreve o que faria em seguida em vez de fazê-lo ("Em seguida, vou …") ou para a fim de pedir permissão para uma etapa que a solicitação original já cobria ("Devo aplicar isso?"). Os usuários precisam responder "continue" ou "vá em frente", o que combina com programação em par e outros trabalhos com humano no loop, mas não usa toda a capacidade de longo horizonte do modelo.

Duas adições ao prompt do sistema, juntas, mitigam isso. Aplique ambas. Se você precisar limitar o tamanho do prompt, use apenas a primeira, que mantém a maior parte do efeito. A primeira diz ao modelo para não perguntar sobre trabalho já solicitado e para executar os próximos passos que ele declarou:

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.

A frase de abertura, que diz ao modelo que o usuário não está observando, carrega grande parte do efeito. Mantenha-a como está escrita. Se seu produto precisa que o modelo pare para confirmações específicas, adicione uma frase depois dela listando-as. Esse bloco também pode tornar o modelo menos propenso a perguntar sobre solicitações ambíguas, então verifique esse trade-off nas suas próprias tarefas.

A segunda define a solicitação do usuário como o escopo do entregável:

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

Diga ao modelo o que preservar nos resumos de compactação

O Claude Fable 5.1 responde bem quando lhe dizem explicitamente o que seu resumo deve reter quando uma conversa longa é compactada. A compactação no lado do servidor já faz isso. Se você compacta no lado do cliente, use a seguinte instrução de resumo:

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.

Limite as alterações e os testes ao que a tarefa pede

Quando solicitado a implementar uma funcionalidade aberta, o Claude Fable 5.1 entrega o que foi pedido e às vezes mais: ele pode corrigir código próximo, estender comportamentos que a tarefa não mencionou ou commitar mais arquivos de teste do que a alteração justifica. Ele responde bem a instruções explícitas sobre o que deixar de fora. Com a instrução a seguir, as adições não solicitadas e o código de teste commitado caem substancialmente, sem mudança mensurável no sucesso da tarefa:

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.

Acionamento de busca em esforço baixo

Em esforço low, o Claude Fable 5.1 é menos propenso que o Claude Fable 5 a chamar uma ferramenta de busca ou recuperação, e mais propenso a responder de memória. Em alguns casos, a correção mais simples é aumentar o esforço nos turnos afetados em vez de na conversa inteira. Consulte Alterar o esforço no meio da conversa.

Em outros casos, um lembrete no prompt em direção à verificação ajuda. No prompt do sistema, diga que reconhecer um nome não é o mesmo que conhecer seu estado atual, e que tais nomes devem ser buscados como o usuário os escreveu:

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.

Reduza falsos positivos de salvaguardas

Os classificadores de segurança do Claude Fable 5.1 produzem menos falsos positivos do que os do Claude Fable 5 produziam no lançamento, e encontrar vulnerabilidades em código-fonte é permitido. Falsos positivos ainda ocorrem, e uma requisição bloqueada retorna stop_reason: "refusal" (consulte Recusas, fallback e cobrança). Três situações os tornam mais prováveis:

  • Formulação de verificação de compilação: Em vez de "Este programa compila sem erros?", pergunte "Há algum bug neste programa?"
  • Linguagens de programação menos conhecidas: Dê ao modelo contexto sobre o que é a linguagem e como ela funciona, por exemplo dando a ele acesso à documentação da linguagem.
  • Base64 na saída de ferramentas: Ferramentas que retornam dados codificados em base64 para o contexto do modelo podem acionar falsos positivos, então removê-las é a correção recomendada.

Prefira edições direcionadas a reescritas de arquivos inteiros

Se o Claude Fable 5.1 reescreve arquivos inteiros para pequenas alterações, acrescente a instrução a seguir ao prompt do sistema ou à primeira mensagem do usuário. O Claude Fable 5.1 é mais propenso que o Claude Fable 5 a reescrever um arquivo de texto inteiro em vez de fazer uma edição direcionada. O arquivo resultante geralmente é o mesmo, mas, a menos que o arquivo seja curto ou que a maior parte dele esteja mudando, uma reescrita custa mais tokens de saída e tempo. A instrução traz o Claude Fable 5.1 de volta ao alinhamento com o Claude Fable 5 para alterações pequenas e médias.

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.

Deixe espaço para saídas longas em esforço xhigh e max

Em esforço xhigh e especialmente max, o Claude Fable 5.1 pode pensar por mais tempo antes de começar a escrever sua resposta. Quando uma única requisição pede um entregável longo, como a reescrita completa de um documento longo, ele pode rascunhar grande parte desse entregável em seu pensamento e depois escrevê-lo novamente como resposta, o que significa uma espera maior e mais tokens de saída. A abordagem mais simples é executar requisições como essas em high, o ponto de partida recomendado, e passar para xhigh ou max apenas onde você mediu um ganho de qualidade (consulte Considere todos os níveis de esforço). Se você as executar em xhigh ou max:

  • Defina max_tokens para deixar espaço para o pensamento e a resposta, não apenas para o tamanho de resposta que você espera.
  • Acrescente a nota a seguir ao final da mensagem do usuário. Ela torna o pensamento muito mais curto em requisições de prosa e código. Substitua [max_tokens] pelo valor real de max_tokens da requisição, por exemplo 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.

Deixe o agente líder continuar trabalhando enquanto os subagentes executam

Se seu agente de código permite que o Claude Fable 5.1 delegue trabalho a subagentes, não force o agente líder a parar e esperar por cada um. Em tarefas de código, deixar o líder continuar enquanto os subagentes executam reduz o tempo médio até a conclusão com qualidade, uso de tokens e custo semelhantes. Para configurar isso:

  • Faça a ferramenta que inicia um subagente retornar imediatamente.
  • Passe o resultado de cada subagente de volta ao líder em uma mensagem user posterior, assim que estiver pronto.
  • Dê ao líder uma ferramenta separada que ele possa chamar quando quiser esperar por um resultado.

O modelo ainda escolhe esperar com frequência. A economia de tempo vem das execuções em que ele segue com outro trabalho.

Dê ao trabalho de visão ferramentas para recortar e ampliar

O Claude Fable 5.1 tem melhores capacidades de visão prontas para uso e, em entradas visuais complexas como gráficos densos, faz seu melhor trabalho quando pode analisar, recortar e verificar visualmente o que vê de forma iterativa. Para obter o benefício completo, execute o modelo como um agente com acesso a um contêiner que contenha as imagens ou vídeos brutos e tenha bibliotecas básicas de processamento de imagem (como PIL e OpenCV) pré-instaladas. Se executar um contêiner for sobrecarga demais, uma ferramenta de recorte de imagem sozinha entrega a maior parte do ganho: uma ferramenta que retorna uma região escolhida da imagem, recortada e ampliada, permite que o modelo examine detalhes específicos com mais profundidade e escala o compute em tempo de teste com tokens de imagem. A receita da ferramenta de recorte tem uma definição funcional.

Was this page helpful?