🎯 Da el porqué + no pidas razonamiento

En el fondo, un LLM es una máquina de predicción del siguiente token. No tiene acceso a lo que tienes en la cabeza; solo al texto del prompt. Un pedido que describe únicamente la tarea («haz X») deja un vacío: por qué importa X, para quién y con qué criterio de calidad. El modelo llena ese vacío con la interpretación estadísticamente más común para ese tipo de pedido, que puede coincidir o no con la tuya.

El costo de esta «suposición» aumenta con la autonomía del modelo. Fable 5 se diseñó para mantener instrucciones en ejecuciones de horizonte largo, a veces durante varios días. Si no se especifica la intención real desde el principio, no detecta el error rápido ni pregunta: ejecuta durante horas en la dirección equivocada, aunque parezca plausible, y solo descubres el desvío cuando ya te costó tiempo y tokens.

Esta es una práctica consolidada de ingeniería de prompts en general, no una cita textual de la documentación oficial de Fable 5 (el video de origen ya incluía el argumento, y la investigación no confirmó una frase textual específica para esta técnica). Tómala como una recomendación sólida, no como una «regla oficial inamovible». La fórmula tiene cuatro partes: tarea mayor (el proyecto en el que encaja), quién (quién depende del resultado), qué habilita la salida (la decisión o acción que viene después) y solo entonces la solicitud concreto.

Fíjate en el orden: primero va el porqué antes del pedido, no como una nota al pie después. Esto importa porque el modelo pondera con más fuerza el contexto que está más cerca (en términos de atención) del pedido final — un «porqué» puesto al final del prompt compite con menos peso frente al pedido en sí.

I'm working on <bigger task, e.g. "security review of the payments API"> for <who, e.g. "the compliance team">.
They need <what the output enables, e.g. "a prioritized list of vulnerabilities with severity, to decide what to fix before release">.
With that: <concrete ask, e.g. "review auth.py and payments.py and list the risks found">.

Estou trabalhando em <tarefa maior, ex.: "revisão de segurança da API de pagamentos"> para <quem, ex.: "o time de compliance">.
Eles precisam de <o que a saída habilita, ex.: "uma lista priorizada de vulnerabilidades com severidade, pra decidir o que corrigir antes do release">.
Com isso: <pedido concreto, ex.: "revise auth.py e payments.py e liste os riscos encontrados">.

❌ BEFORE (what only):
"You are an agent that reviews Pull Requests. Point out bugs and style suggestions."

✅ AFTER (what + why):
"You are an agent that reviews Pull Requests for a team that ships to production 3
times a day and has no dedicated QA. The goal of this review is to catch what would
break production — not style. They need a short, prioritized list (bugs > security >
logic), because long, nitpick-heavy reviews get ignored. With that: review the
attached diff and list only what would block the merge."

❌ ANTES (só o quê):
"Você é um agente que revisa Pull Requests. Aponte bugs e sugestões de estilo."

✅ DEPOIS (quê + porquê):
"Você é um agente que revisa Pull Requests para um time que faz deploy 3x ao dia e
não tem QA dedicado. O objetivo desta revisão é pegar o que quebraria produção — não
estilo. Eles precisam de uma lista curta e priorizada (bugs > segurança > lógica),
porque revisões longas e cheias de nitpick são ignoradas. Com isso: revise o diff
anexado e liste só o que bloquearia o merge."

Modelos más débiles en instruction-following suelen «suavizar» las solicitudes ambiguas con el sentido común aprendido durante el entrenamiento; a veces aciertan accidentalmente con tu intención, aunque no esté explícita. Fable 5 sigue exactamente lo que se pidió. La documentación oficial describe la mejora así: "Instruction-following is improved enough that you can steer most behaviors with a brief instruction rather than enumerating each behavior by name." (fuente: documentación oficial "Prompting Claude Fable 5" — técnica 6, "di menos, no más", desarrollada en el módulo 1.5; traducción: "el seguimiento de instrucciones mejoró lo suficiente como para que puedas guiar la mayoría de los comportamientos con una instrucción breve, en lugar de enumerar cada comportamiento por su nombre.")

Esa capacidad se convierte en un riesgo precisamente cuando falta el porqué: sin él, Fable 5 no va a «adivinar bien» por accidente, como a veces lo hace un modelo más débil; va a cumplir literalmente lo que se le pide, aunque eso haga que pierda de vista el objetivo real. Cuanto más capaz es un modelo de seguir instrucciones, más costosa resulta una solicitud mal especificada.

Hay una ironía directa con el resto de este módulo: pedirle al modelo explicar por qué hizo algo dentro del propio texto de respuesta es la forma equivocada de conseguir transparencia. Los prompts, las skills y las instrucciones del harness que le piden al modelo repetir, transcribir o narrar su razonamiento interno como parte de la respuesta entran en una categoría de seguridad específica, y eso es específico de Fable 5, no un comportamiento genérico de cualquier Claude.

Esto suele venir de skills migradas de modelos antiguos, donde "muestra tu razonamiento paso a paso" era una técnica válida de prompting. En Fable 5, el canal adecuado para eso ya existe: los thinking blocks — y pedir que esto se duplique en la respuesta en texto es precisamente el detonante del riesgo (ver los apartados 5 y 6).

La documentación oficial sobre rechazos y alternativas define cuatro categorías posibles en stop_details.category: cyber, bio, frontier_llm y la que interesa aquí, reasoning_extraction. Es exactamente el disparador del tema anterior.

Cuando esto se activa, ocurre el rechazo antes de cualquier resultado y no se cobra. Hay tres formas de configurar un fallback automático para Claude Opus 4.8 cuando esto ocurre: fallback del lado del servidor (Claude API / Claude Platform on AWS, mediante un encabezado beta), middleware del SDK (BetaRefusalFallbackMiddleware) o retry manual con "fallback credit". En los tres casos, si no auditas tus skills/prompts, el fallback se convierte en una fuga silenciosa de calidad y costo: la app "funciona", pero con un modelo distinto del que crees estar usando.

Don't instruct Claude to reproduce its reasoning in the response. Prompts, skills, or
harness instructions that tell the model to echo, transcribe, or explain its internal
reasoning as response text can trigger the reasoning_extraction refusal category on
Claude Fable 5, causing elevated fallbacks to Claude Opus 4.8. Audit existing skills
and system prompts for reflection or show-your-thinking instructions when migrating.
If your application needs reasoning visibility, read the structured thinking blocks
from adaptive thinking instead.

Não instrua o Claude a reproduzir o raciocínio dele na resposta. Prompts, skills ou
instruções de harness que pedem pro modelo ecoar, transcrever ou explicar o raciocínio
interno como texto de resposta podem disparar a categoria de recusa reasoning_extraction
no Claude Fable 5, causando fallbacks mais frequentes pro Claude Opus 4.8. Ao migrar,
audite skills e system prompts existentes em busca de instruções de reflexão ou
"mostre seu raciocínio". Se sua aplicação precisa de visibilidade do raciocínio, leia os
blocos estruturados de thinking do adaptive thinking em vez disso.

Si tu aplicación necesita visibilidad real del razonamiento —para depuración, auditoría o registro—, lo correcto no es pedirle al modelo que reescriba el razonamiento dentro del texto que ve el usuario. Es leer los thinking blocks estructurados que adaptive thinking ya produce, en un canal separado de la respuesta final. Esto preserva ambas cosas al mismo tiempo: el modelo piensa lo que necesita y tú tienes visibilidad — sin activar el tema 5.

En la práctica, esto es un cambio de dónde la instrucción indica: en vez de "explica tu razonamiento en la respuesta", la instrucción (o el código de tu harness) pasa a ser "lee el razonamiento en el bloque de thinking". Consulta la documentación oficial de adaptive thinking para ver la configuración exacta de la API.

{
  "content": [
    { "type": "thinking", "thinking": "...raciocínio interno estruturado..." },
    { "type": "text", "text": "...resposta final que o usuário vê..." }
  ]
}

Cómo comprobar: si tu aplicación necesita auditar decisiones, lee los bloques con type === "thinking" en tu código, en lugar de indicar «explica tu razonamiento» en el prompt. Confirma que el type === "text" el resultado final sigue limpio, directo y sin narrar lo que ocurre entre bastidores — y la tasa de fallback a Opus 4.8 (tema 5) no aumenta.