Prompting para Claude Fable 5.1

Para conocer las capacidades del modelo, los cambios en la API, los precios y la disponibilidad, consulta Novedades en Claude Fable 5.1. Para técnicas que se aplican a todos los modelos Claude, consulta Mejores prácticas de prompting.

Tus prompts existentes de Claude Fable 5 deberían funcionar bien en Claude Fable 5.1 sin cambios, pero vale la pena conocer algunas diferencias de comportamiento. Comienza con la sección que coincida con lo que observas:

• No estás seguro de qué nivel de esfuerzo usar, o la latencia y el costo son más altos de lo que la tarea justifica: Considera todos los niveles de esfuerzo
• Poco o ningún texto entre llamadas a herramientas: Pide actualizaciones de progreso orientadas al usuario
• Una llamada a herramienta por turno en bucles de agente: Agrupa las llamadas a herramientas independientes en bucles de agente
• Las solicitudes fallan con bound to a different conversation, o tu harness edita turnos anteriores entre solicitudes: Mantén el historial de conversación en modo append-only (solo anexar)
• La prosa resulta larga y densa: Densidad de la escritura
• Las respuestas de chat tienen menos estructura de la que el contenido necesita: Formato en el chat
• Los resúmenes reproducen la redacción de la fuente sin marcarla como cita: Citar fuentes recuperadas
• El turno termina antes de que el trabajo esté hecho, o el modelo pide permiso para trabajo que ya solicitaste: Termina toda la tarea
• Los resúmenes de compactación del lado del cliente omiten restricciones, decisiones o detalles exactos: Dile al modelo qué preservar en los resúmenes de compactación
• Correcciones o extensiones no solicitadas, o más archivos de prueba confirmados (committed) de los que la tarea requería: Limita los cambios y las pruebas a lo que pide la tarea
• Responde de memoria en lugar de buscar con esfuerzo bajo: Activación de búsquedas con esfuerzo bajo
• Las solicitudes de programación benignas devuelven stop_reason: "refusal": Reduce los falsos positivos de las salvaguardas
• Archivos completos reescritos para cambios pequeños: Prefiere ediciones específicas en lugar de reescrituras de archivos completos
• Los entregables largos con esfuerzo xhigh o max tardan mucho o alcanzan max_tokens: Deja espacio para salidas largas con esfuerzo xhigh y max
• El agente principal queda inactivo mientras se ejecutan los subagentes: Deja que el agente principal siga trabajando mientras se ejecutan los subagentes
• Las respuestas sobre gráficos e imágenes densas pierden detalles: Proporciona al trabajo de visión herramientas para recortar y ampliar

Considera todos los niveles de esfuerzo

Comienza en el nivel de effort (esfuerzo) predeterminado, high, y luego prueba los demás niveles (low, medium, xhigh y max) con tus propias evaluaciones. El esfuerzo es el control principal para equilibrar inteligencia, latencia y costo en Claude Fable 5.1. Vuelve a ejecutar el barrido incluso si ya ejecutaste uno en Claude Fable 5: los nombres de los niveles de esfuerzo no corresponden a la misma cantidad de pensamiento entre modelos.

Las ganancias de capacidad de Claude Fable 5.1 sobre Claude Fable 5 aparecen en todos los niveles de esfuerzo y son mayores en los ajustes más altos. En medium, los resultados coinciden aproximadamente con Claude Fable 5 a un costo menor, así que baja a medium o low donde tus evaluaciones muestren que la calidad se mantiene. En low, Claude Fable 5.1 a menudo es competitivo con los modelos Claude Opus y Claude Sonnet en costo por tarea mientras obtiene puntuaciones más altas, así que inclúyelo en la comparación dondequiera que de otro modo ejecutarías un modelo más pequeño con un nivel de esfuerzo más alto.

Dos comportamientos específicos del esfuerzo tienen sus propias secciones: en low, Claude Fable 5.1 llama a las herramientas de búsqueda y recuperación con menos frecuencia (consulta Activación de búsquedas con esfuerzo bajo), y en xhigh y max puede pensar durante más tiempo antes de escribir un entregable largo (consulta Deja espacio para salidas largas con esfuerzo xhigh y max).

Pide actualizaciones de progreso orientadas al usuario

Claude Fable 5.1 puede escribir menos actualizaciones orientadas al usuario durante turnos largos de llamadas a herramientas que Claude Fable 5, especialmente con esfuerzo más alto y en cadenas de herramientas más largas. Los usuarios ven que el agente se queda en silencio durante minutos, o un mensaje final que cubre solo el último paso en lugar de toda la tarea.

Primero, verifica que tu cliente realmente esté recibiendo actualizaciones de progreso. Las notas breves del modelo entre llamadas a herramientas, lo que acaba de encontrar y lo que hará a continuación, se devuelven como bloques thinking de actualización de progreso, y esos bloques están vacíos con el valor predeterminado de thinking.display, que es "omitted". Establece display: "updates" (beta, encabezado thinking-display-updates-2026-08-18) y muestra cada bloque thinking no vacío como una línea de estado, o establece "summarized" para recibirlos junto con el razonamiento resumido. Si no los estás solicitando, es posible que las actualizaciones del modelo simplemente no estén llegando a tus usuarios.

Segundo, revisa tu prompt en busca de instrucciones que supriman la narración. Algunos modelos anteriores eran propensos a dar actualizaciones mientras trabajaban, lo que llevó a líneas en la "system prompt" (indicación del sistema) como "guarda todos los hallazgos para la respuesta final". Elimina líneas como esa antes de agregar cualquier cosa.

Si aún quieres más actualizaciones, por ejemplo al programar en pareja o en otro trabajo con un humano en el ciclo, agrega una línea breve a la indicación del sistema que diga cuándo quieres texto orientado al usuario por parte del modelo y qué debe contener cada actualización:

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 tu producto colapsa u oculta la salida de las herramientas, díselo al modelo. De lo contrario, puede ejecutar comandos para "mostrar" al usuario una salida que tu interfaz nunca muestra. Entrega la nota en un mensaje de sistema con alcance 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.

Agrupa las llamadas a herramientas independientes en bucles de agente

Claude Fable 5.1 normalmente emite llamadas a herramientas en paralelo como se espera: cuando una solicitud nombra varias cosas que obtener, emite esas llamadas en paralelo. La excepción son los bucles de programación y de uso de computadora donde las siguientes llamadas independientes están implícitas en la tarea en lugar de solicitarse explícitamente (agentes de programación personalizados, harnesses de bash y editor, uso de computadora): ahí puede emitirlas una por turno. Esto no afecta la calidad de la respuesta, pero cada turno adicional cuesta tokens, un viaje de ida y vuelta y tiempo de reloj. Un empujón de una oración al final de la solicitud actual lo resuelve:

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 envíes resultados de herramientas de vuelta, anéxalo después de ese mensaje de usuario como un mensaje de sistema con alcance de turno: una entrada role: "system" en messages con clear_at: "next_user_message". Una vez que existe un mensaje de usuario posterior, la API borra las copias anteriores, por lo que el modelo lee solo la más reciente. Los mensajes de sistema con alcance de turno están en beta y requieren el encabezado beta mid-conversation-system-clear-at-2026-08-21. Sin la beta, coloca la oración en un bloque de texto después de los bloques tool_result en el mismo mensaje de usuario.

Anexa una copia nueva en cada turno y deja las copias anteriores donde están, byte por byte. Permanecen en el arreglo, pero una vez borradas el modelo no las ve y no cuestan tokens de entrada. Eliminarlas o reescribirlas es una edición de turnos anteriores: reinicia la caché de prompts desde ese punto e invalida los bloques de pensamiento que vinieron después de ellas (consulta Mantén el historial de conversación en modo append-only (solo anexar)).

El siguiente bucle muestra esta ubicación. Cada turno del asistente se devuelve exactamente como se recibió, cada turno de usuario lleva solo los resultados de herramientas, y una copia nueva con alcance de turno del empujón lo sigue.

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."
)
# Los archivos en memoria sustituyen a un directorio de trabajo para que el ejemplo se ejecute en cualquier lugar.
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,
    )
    # Agrega el turno del asistente exactamente como se devolvió, incluidos los bloques de pensamiento.
    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":
            path = str(block.input["path"])
            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,
                    }
                )
    # Envía los resultados de herramientas como el turno del usuario, luego una copia nueva del empujón como
    # mensaje de sistema con alcance de turno. Deja las copias anteriores en su lugar: la API las elimina,
    # así que el modelo solo ve la más reciente.
    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"), ""))

Mantén el historial de conversación en modo append-only (solo anexar)

Anexa cada turno del asistente al historial exactamente como lo devolvió la API, incluidos los bloques de pensamiento, y no edites turnos anteriores entre solicitudes. Para las cuentas nuevas creadas a partir del 31 de agosto de 2026, los bloques de pensamiento de Claude Fable 5.1 son válidos solo en la conversación exacta que los produjo: una solicitud que reproduce un bloque de pensamiento después de que su prefijo (la indicación del sistema, la lista de herramientas o cualquier mensaje anterior) haya cambiado devuelve un 400, o descarta los bloques afectados si estableces thinking.block_binding.prefix_mismatch_behavior: "drop_block" (beta, encabezado thinking-binding-controls-2026-08-01). Se espera que los modelos futuros apliquen esta verificación a todas las cuentas, así que adopta el patrón ahora aunque la tuya no lo aplique hoy.

Las ediciones del historial que activan la verificación son las mismas que reinician la caché de prompts: inyectar y eliminar recordatorios por turno, resumir turnos antiguos en su lugar o cambiar la indicación del sistema a mitad de sesión. Envía los recordatorios por turno como mensajes de sistema con alcance de turno, cambia las instrucciones o herramientas con un mensaje de sistema a mitad de conversación en lugar de reescribir system o tools, y deja que la compactación del lado del servidor o la edición de contexto hagan cualquier recorte. Si compactas en el cliente, la forma más simple es reemplazar todo el historial con un mensaje de resumen más el nuevo turno de usuario y no reproducir nada más: ningún bloque de pensamiento se transfiere, así que nada falla, y el modelo piensa de nuevo sobre la conversación compactada (consulta Compactación personalizada en el cliente).

Para encontrar las ediciones que tu harness ya realiza, ejecuta una sesión con prefix_mismatch_behavior: "drop_block" y registra input_transformations, como se describe en Cómo saber si tu integración se ve afectada, o captura las solicitudes exactas que envía durante algunos turnos normales y confirma que las solicitudes consecutivas son idénticas byte por byte hasta los turnos anexados.

Densidad de la escritura

La escritura de Claude Fable 5.1 es en general un avance respecto a los modelos Claude anteriores, con menos frases hechas y menos jerga sin explicar. En algunos casos, sin embargo, su prosa es más densa que la de Claude Fable 5: las oraciones son más largas y hay menos saltos de párrafo. Una instrucción que defina el antipatrón, "mannered prose" (prosa afectada), ayuda. Agrégala a un mensaje de usuario (preferido) o a la indicación del 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.

La versión corta también suele funcionar:

Please remove all mannered prose.

Formato en el chat

Los modelos anteriores abusaban de las viñetas y las negritas en el chat, y muchos prompts contienen reglas antiformato escritas para contener eso. Claude Fable 5.1 se inclina hacia el otro lado: usa menos negritas y es menos propenso a recurrir a encabezados, listas o comillas. Si tu prompt contiene lenguaje antiformato, elimínalo o reemplázalo con una regla que diga cuándo es apropiado un formato específico, como la siguiente:

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.

Citar fuentes recuperadas

Al resumir documentos, Claude Fable 5.1 es más propenso que Claude Fable 5 a reproducir pasajes del texto fuente sin marcarlos como citas. Para abordar esto, agrega un ejemplo completo de una respuesta correcta a la indicación del sistema: la solicitud del usuario, la respuesta y una oración que explique por qué la respuesta es correcta.

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

Reemplaza las dos líneas [web_search: ...] con el nombre de tu propia herramienta, para que el modelo las lea como salida de herramienta con plantilla en lugar de texto literal que debe emitir.

Termina toda la tarea

Claude Fable 5.1 puede ejecutar tareas muy largas sin mucha orientación sobre la metodología, especialmente cuando el objetivo es claro. En cargas de trabajo asíncronas complejas, sin embargo, empújalo a no terminar su turno antes de que el trabajo esté hecho. Sin el empujón, el modelo a veces describe lo que haría a continuación en lugar de hacerlo ("A continuación, voy a…") o se detiene a pedir permiso para un paso que la solicitud original ya cubría ("¿Aplico esto?"). Los usuarios tienen que responder "continúa" o "adelante", lo cual es adecuado para la programación en pareja y otro trabajo con un humano en el ciclo, pero no aprovecha toda la capacidad de largo horizonte del modelo.

Dos adiciones a la indicación del sistema juntas mitigan esto. Aplica ambas. Si necesitas limitar la longitud del prompt, usa solo la primera, que conserva la mayor parte del efecto. La primera le dice al modelo que no pregunte sobre trabajo ya solicitado y que lleve a cabo los siguientes pasos que ha indicado:

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 oración inicial, que le dice al modelo que el usuario no está observando, aporta gran parte del efecto. Mantenla tal como está escrita. Si tu producto necesita que el modelo se detenga para confirmaciones específicas, agrega una oración después de ella que las enumere. Este bloque también puede hacer que el modelo sea menos propenso a preguntar sobre solicitudes ambiguas, así que verifica ese equilibrio en tus propias tareas.

La segunda define la solicitud del usuario como el alcance del entregable:

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

Dile al modelo qué preservar en los resúmenes de compactación

Claude Fable 5.1 responde bien cuando se le dice explícitamente qué debe retener su resumen cuando se compacta una conversación larga. La compactación del lado del servidor ya hace esto. Si compactas del lado del cliente, usa la siguiente instrucción de resumen:

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 los cambios y las pruebas a lo que pide la tarea

Cuando se le pide implementar una funcionalidad abierta, Claude Fable 5.1 entrega lo que se pide y a veces más: puede corregir código cercano, extender comportamiento que la tarea no mencionaba o confirmar (commit) más archivos de prueba de los que el cambio justifica. Responde bien a instrucciones explícitas sobre qué dejar fuera. Con la siguiente instrucción, las adiciones no solicitadas y el código de prueba confirmado disminuyen sustancialmente sin ningún cambio medible en el éxito de la tarea:

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.

Activación de búsquedas con esfuerzo bajo

Con esfuerzo low, Claude Fable 5.1 es menos propenso que Claude Fable 5 a llamar a una herramienta de búsqueda o recuperación, y más propenso a responder de memoria. En algunos casos, la solución más simple es aumentar el esfuerzo para los turnos afectados en lugar de toda la conversación. Consulta Cambiar el esfuerzo a mitad de conversación.

En otros casos, un empujón en el prompt hacia la verificación ayuda. En la indicación del sistema, di que reconocer un nombre no es lo mismo que conocer su estado actual, y que esos nombres deben buscarse tal como el usuario los escribió:

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.

Reduce los falsos positivos de las salvaguardas

Los clasificadores de seguridad de Claude Fable 5.1 producen menos falsos positivos que los de Claude Fable 5 en su lanzamiento, y encontrar vulnerabilidades en código fuente está permitido. Los falsos positivos aún ocurren, y una solicitud bloqueada devuelve stop_reason: "refusal" (consulta Rechazos, fallback y facturación). Tres situaciones los hacen más probables:

• Redacción de verificación de compilación: En lugar de "¿Este programa compila sin errores?", pregunta "¿Hay algún error en este programa?"
• Lenguajes de programación menos conocidos: Dale al modelo contexto sobre qué es el lenguaje y cómo funciona, por ejemplo dándole acceso a la documentación del lenguaje.
• Base64 en la salida de herramientas: Las herramientas que devuelven datos codificados en base64 al contexto del modelo pueden activar falsos positivos, por lo que eliminarlas es la solución recomendada.

Prefiere ediciones específicas en lugar de reescrituras de archivos completos

Si Claude Fable 5.1 reescribe archivos completos para cambios pequeños, anexa la siguiente instrucción a la indicación del sistema o al primer mensaje de usuario. Claude Fable 5.1 es más propenso que Claude Fable 5 a reescribir un archivo de texto completo en lugar de hacer una edición específica. El archivo resultante suele ser el mismo, pero a menos que el archivo sea corto o la mayor parte esté cambiando, una reescritura cuesta más tokens de salida y tiempo. La instrucción vuelve a alinear a Claude Fable 5.1 con Claude Fable 5 para cambios pequeños y medianos.

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.

Deja espacio para salidas largas con esfuerzo xhigh y max

Con esfuerzo xhigh y especialmente max, Claude Fable 5.1 puede pensar durante más tiempo antes de empezar a escribir su respuesta. Cuando una sola solicitud pide un entregable largo, como una reescritura completa de un documento largo, puede redactar gran parte de ese entregable en su pensamiento y luego escribirlo de nuevo como respuesta, lo que significa una espera más larga y más tokens de salida. El enfoque más simple es ejecutar solicitudes como estas en high, el punto de partida recomendado, y pasar a xhigh o max solo donde hayas medido una mejora de calidad (consulta Considera todos los niveles de esfuerzo). Si las ejecutas en xhigh o max:

• Establece max_tokens para dejar espacio para el pensamiento y la respuesta, no solo para la longitud de respuesta que esperas.
• Anexa la siguiente nota al final del mensaje de usuario. Hace que el pensamiento sea mucho más corto en solicitudes de prosa y código. Reemplaza [max_tokens] con el valor real de max_tokens de la solicitud, por ejemplo 64,000.

Everything Claude produces 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 Claude doesn'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, Claude spends extra effort on understanding the request, checking the inputs Claude's 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. If Claude plans well then it should not need to draft its output multiple times (and Claude is pretty good at planning, so this should not be an issue).

Deja que el agente principal siga trabajando mientras se ejecutan los subagentes

Si tu agente de programación permite que Claude Fable 5.1 delegue trabajo a subagentes, no obligues al agente principal a detenerse y esperar a cada uno. En tareas de programación, dejar que el principal continúe mientras se ejecutan los subagentes reduce el tiempo promedio de finalización con calidad, uso de tokens y costo similares. Para configurarlo:

• Haz que la herramienta que inicia un subagente retorne de inmediato.
• Pasa el resultado de cada subagente de vuelta al principal en un mensaje user posterior una vez que esté listo.
• Dale al principal una herramienta separada que pueda llamar cuando quiera esperar un resultado.

El modelo aún elige esperar con frecuencia. El ahorro de tiempo proviene de las ejecuciones en las que continúa con otro trabajo.

Proporciona al trabajo de visión herramientas para recortar y ampliar

Claude Fable 5.1 tiene mejores capacidades de visión de forma predeterminada, y en entradas visuales complejas como gráficos densos hace su mejor trabajo cuando puede analizar, recortar y verificar visualmente de forma iterativa lo que ve. Para obtener todo el beneficio, ejecuta el modelo como un agente con acceso a un contenedor que contenga las imágenes o videos sin procesar y tenga bibliotecas básicas de procesamiento de imágenes (como PIL y OpenCV) preinstaladas. Si ejecutar un contenedor supone demasiada sobrecarga, una herramienta de recorte de imágenes por sí sola aporta la mayor parte de la mejora: una herramienta que devuelve una región elegida de la imagen, recortada y ampliada, permite al modelo examinar detalles específicos con más profundidad y escala el "test-time compute" (cómputo en tiempo de prueba) con los tokens de imagen. La receta de la herramienta de recorte tiene una definición funcional.