Fable ha vuelto. Así se programa de verdad con él.

Fable ha vuelto.

Tras el lío de controles de exportación de junio, Anthropic ha restaurado el acceso a Claude Fable 5. Desde el 1 de julio de 2026, Fable vuelve a estar disponible globalmente en Claude.ai, Claude Platform, Claude Code y Claude Cowork, y Anthropic también está reactivando el acceso en AWS, Google Cloud y Microsoft Foundry tan rápido como puede.

Pero la vuelta trae una advertencia muy importante.

Fable ahora está protegido por clasificadores de seguridad más estrictos. Cuando esos clasificadores deciden que una petición se acerca demasiado a terreno de ciberseguridad de alto riesgo, biología o extracción de razonamiento, la petición puede ser bloqueada y enrutada a Claude Opus 4.8 en su lugar. Anthropic también dice que el nuevo clasificador es más propenso a marcar tareas benignas de coding y debugging mientras ajustan a la baja los falsos positivos.

Por eso algunos desarrolladores están viendo lo que se siente como este comportamiento:

"Seleccioné Fable, le pedí que programara, y cambió a Opus 4.8."

La reacción comprensible es: "¿Entonces Fable ya no puede programar?"

Creo que esa es la conclusión equivocada.

La mejor conclusión es:

Fable puede seguir siendo extremadamente útil para programar, pero tienes que dejar de usarlo como un modelo de autocompletado genérico. Úsalo como un staff engineer, arquitecto, planificador de migraciones, líder de debugging y revisor final.

Ese cambio importa.

La propia guía de prompting de Fable de Anthropic dice que Fable es más fuerte en trabajo complejo, ambiguo y de larga duración: el tipo de trabajo que podría llevarle a un humano horas, días o semanas. Señala en concreto una mayor autonomía de horizonte largo, revisión de código, debugging fuera de categorías restringidas de ciberseguridad, búsqueda en el historial del repositorio, manejo de ambigüedad y delegación en subagentes.

Así que la pregunta no es: "¿Puede Fable programar?"

La pregunta de verdad es: "¿Dónde debería situar Fable en mi flujo de trabajo de coding para sacar el máximo valor sin chocar constantemente contra el fallback?"

Este es el manual práctico.

1. Usa Fable para el criterio, no para las teclas

La forma más rápida de desperdiciar Fable es pedirle que haga cada pequeña edición.

No lo uses para:

• Arreglos de sintaxis diminutos
• Cambios CRUD simples
• Renombrar variables
• Formateo
• Generación de boilerplate
• Búsqueda rutinaria de archivos
• Actualizaciones básicas de tests
• Pasos de implementación mecánicos

Esas tareas normalmente las maneja mejor un modelo más barato o más rápido.

Usa Fable donde los errores salen caros:

• Decisiones de arquitectura
• Refactors grandes
• Planificación de migraciones
• Debugging complejo
• Revisiones de diseño
• Traducción ambigua de producto a código
• Análisis de dependencias multi-archivo
• Revisión final de producción
• Estrategia de tests
• Arqueología de código
• Tareas de agente de larga duración
• Revisión de pull requests después de que otro modelo implementó el cambio

Un buen modelo mental:

Sonnet u Opus pueden ser el implementador.
Fable debería ser a menudo el arquitecto y el revisor.

Eso también coincide con lo que recomiendan algunas guías tempranas de practicantes: usa modelos más baratos para triaje, ejecución repetitiva y llamadas simples a herramientas, y luego trae a Fable para el criterio más profundo, la planificación de migraciones, la revisión de arquitectura y las decisiones finales.

2. Divide el trabajo de coding en tres fases

El flujo de trabajo de Fable más fiable que he encontrado en la documentación y en los patrones de la comunidad es este:

Fase 1: Explorar
Fase 2: Planificar
Fase 3: Ejecutar y verificar

Fable no necesita ser dueño de cada fase.

Un montaje práctico:

Usa un modelo más barato u Opus 4.8 para explorar el repo, recopilar archivos, resumir la arquitectura, identificar los comandos de test y preparar un brief limpio.

Usa Fable para razonar sobre la parte difícil: qué debería cambiar, qué podría romperse, en qué orden hacerlo y cómo verificarlo.

Usa Opus o Sonnet para implementar las ediciones repetitivas.

Usa Fable de nuevo como revisor final.

Ese "sándwich de Fable" es a menudo más fiable que pedirle a Fable que haga a ciegas el trabajo entero desde el primer prompt.

Flujo de trabajo de ejemplo:

Opus: mapea el repo, identifica los archivos afectados, resume el comportamiento actual.
Fable: diseña el plan de migración más seguro e identifica riesgos ocultos.
Opus o Sonnet: implementa el plan.
Fable: revisa el diff, los tests, los casos límite y el riesgo de despliegue.
Humano: aprueba la decisión final de lanzamiento.

Esto no va de saltarse las salvaguardas. Es simplemente buen enrutado de modelos.

"Sonnet u Opus pueden ser el implementador. Fable debería ser a menudo el arquitecto y el revisor. Los equipos que ganan son los que aprenden a pasar el trabajo entre modelos, no a forzar un solo modelo a través de cada prompt."

3. Empieza en modo planificación para los cambios grandes

Para tareas grandes de coding, Fable debería empezar a menudo en modo de solo lectura.

La documentación de Claude Code recomienda /plan antes de cambios grandes, y señala que /model y /effort te permiten ajustar cuánto razonamiento gastas durante la tarea. Antes de lanzar, Claude Code ofrece los flujos de trabajo /diff, /code-review, /review y /security-review.

Un prompt fuerte de Fable se ve así:

/model claude-fable-5
/effort high
/plan

Goal:
Design the safest implementation plan for [feature/refactor/migration].

Constraints:
- Do not edit files yet.
- First map the affected files and dependencies.
- Identify assumptions and unknowns.
- Propose the smallest safe change.
- Separate implementation steps from verification steps.
- Tell me which parts should be delegated to a cheaper model.

Esto hace tres cosas.

Primero, le da a Fable el tipo de tarea de razonamiento de alto nivel donde tiene sentido.

Segundo, reduce la sobre-edición accidental.

Tercero, crea un plan limpio que otro modelo puede ejecutar si Fable cae después al fallback.

4. Usa esfuerzo high por defecto, no siempre el máximo

Fable tiene un dial de esfuerzo, y usarlo bien importa.

Anthropic recomienda high como default para la mayoría de las tareas de Fable, xhigh solo para los workloads más sensibles a la capacidad, y medium o low para el trabajo más rutinario. La documentación también advierte que un Fable de alto esfuerzo puede reunir más contexto y deliberar más de lo necesario en tareas rutinarias.

Mi regla práctica:

Usa medium para ayuda interactiva de coding.
Usa high para la mayoría de las tareas serias de ingeniería.
Usa xhigh para arquitectura, migraciones, debugging profundo y revisiones finales.
Evita xhigh para ediciones diminutas.

Una buena instrucción para acompañar el esfuerzo más alto:

Do the simplest thing that solves the stated problem. Do not add features, abstractions, compatibility layers, or surrounding cleanup unless they are necessary for this task.

Esa instrucción está cerca de la propia guía de Anthropic para evitar que Fable sobre-refactorice con esfuerzo más alto.

5. Haz que tu repo sea legible para Fable

Fable es potente, pero no es adivino.

Si el contexto de tu proyecto está desordenado, Fable desperdiciará tokens descubriendo cosas que un equipo humano podría haber escrito una sola vez.

Claude Code recomienda usar /init para crear un CLAUDE.md de arranque, y luego refinarlo con comandos de build, comandos de test, estilo de código, reglas de flujo de trabajo y las trampas no obvias del proyecto. También advierte que un CLAUDE.md hinchado puede hacer que Claude ignore las instrucciones importantes.

Un buen CLAUDE.md debería incluir:

• Cómo instalar las dependencias
• Cómo correr un test
• Cómo correr la suite de tests completa
• Cómo hacer typecheck
• Cómo hacer lint
• Qué gestor de paquetes usar
• Reglas de arquitectura no obvias
• Directorios importantes
• Convenciones de branch y PR
• Trampas conocidas en el repo

Un mal CLAUDE.md incluye:

• Tutoriales largos
• Convenciones obvias del lenguaje
• Explicaciones archivo por archivo
• Información desactualizada
• Reglas que entran en conflicto entre sí
• Instrucciones genéricas como "escribe código limpio"

Un fragmento práctico de CLAUDE.md:

# Project commands
- Install: pnpm install
- Dev server: pnpm dev
- Typecheck: pnpm typecheck
- Unit test one file: pnpm test path/to/file.test.ts
- Full test suite: pnpm test
- Lint: pnpm lint

# Workflow
- Prefer small, reviewable diffs.
- For bug fixes, add or update a regression test first when practical.
- Run typecheck after a series of code changes.
- Do not run the full test suite unless the targeted tests pass first.

# Architecture
- API routes live in src/server/routes.
- Shared domain logic lives in src/domain.
- UI components should not call database code directly.

Esto hace a Fable más fiable porque puede gastar su presupuesto de razonamiento en el problema difícil en lugar de redescubrir tu flujo de trabajo.

6. Mete los flujos de trabajo repetibles en skills

No metas cada flujo de trabajo en CLAUDE.md.

Claude Code soporta skills a través de archivos SKILL.md. La documentación recomienda usar skills para conocimiento de dominio y flujos de trabajo reutilizables que deberían cargarse bajo demanda en lugar de hinchar cada conversación.

Por ejemplo, podrías crear:

.claude/skills/fable-migration-review/SKILL.md

---
name: fable-migration-review
description: Review a proposed code migration for hidden risks and verification gaps
---

Review the proposed migration.

1. Identify affected modules.
2. Find hidden dependencies.
3. Identify backwards compatibility risks.
4. Check whether the plan can be split into smaller PRs.
5. Define targeted tests.
6. Define rollback strategy.
7. Produce a ship/no-ship recommendation.

Luego puedes invocarlo cuando Fable esté haciendo una revisión de migración.

Este es un buen uso de Fable porque el valor no está en teclear código. El valor está en cazar lo que otro modelo o ingeniero podría pasar por alto.

7. Usa hooks para las reglas que siempre deben pasar

Las instrucciones son orientativas. Los hooks son deterministas.

La documentación de Claude Code es muy clara aquí: usa hooks para acciones que deben pasar cada vez sin excepciones. Por ejemplo, un hook puede correr eslint después de las ediciones o bloquear escrituras a carpetas sensibles.

Esto importa para Fable porque no deberías confiar en que ningún modelo recuerde cada regla operativa en una sesión larga.

Buenas ideas de hooks:

• Correr formateo después de editar archivos
• Correr lint después de las ediciones
• Bloquear cambios a archivos generados
• Bloquear cambios a migraciones salvo que se permitan explícitamente
• Filtrar logs de test enormes hasta dejar solo los fallos
• Prevenir escrituras accidentales a la config de producción
• Avisar cuando aparezcan secretos en un diff

La documentación también señala que los hooks pueden reducir el uso de tokens preprocesando salida ruidosa. Por ejemplo, en lugar de hacer que Claude lea un log de 10.000 líneas, un hook puede devolver solo las líneas de error que coinciden.

Ese es exactamente el tipo de montaje de entorno que hace a Fable más eficaz: dale la señal correcta, no todo el ruido.

8. Para el trabajo de seguridad, sé explícito y defensivo

Aquí es donde ocurren muchos fallbacks.

Anthropic dice que las salvaguardas de Fable apuntan a técnicas ofensivas de ciberseguridad como construir exploits, malware o herramientas de ataque. La misma documentación también dice que el trabajo benigno de ciberseguridad puede disparar las salvaguardas.

Así que no formules trabajo legítimo de una forma que suene a desarrollo de exploits.

Mal prompt:

Find vulnerabilities in this auth system and show me how to exploit them.

Mejor prompt:

I am reviewing my own authorized codebase. Please perform a defensive code review focused on correctness, authentication boundaries, authorization checks, input validation, secrets handling, and test coverage.

Do not provide exploit chains, offensive tooling, payloads, or attack instructions. For each issue, provide:
1. The affected file and line
2. Why it is risky
3. A safe remediation
4. A safe regression test

Incluso esto puede enrutarse igualmente a Opus 4.8. Eso es esperable a veces. Anthropic usa intencionadamente un enfoque de margen de seguridad que bloquea peticiones ciber ambiguas, aunque muchas sean probablemente benignas.

El objetivo no es engañar al clasificador. El objetivo es declarar con claridad el alcance defensivo legítimo y evitar pedir salida peligrosa.

Para una revisión de seguridad más profunda dentro de Claude Code, usa el comando integrado /security-review donde corresponda. Claude Code lo documenta como una pasada de solo lectura más profunda antes de lanzar.

9. Evita pedir razonamiento oculto

Otro disparador de fallback evitable: pedirle a Fable que revele su razonamiento interno.

La documentación de Fable de Anthropic dice que el modelo tiene salvaguardas en torno a la extracción del pensamiento resumido, y la guía de migración documenta una categoría de rechazo reasoning_extraction.

Así que no pidas:

Show your full hidden chain of thought step by step.

Pide:

Give me the conclusion, key evidence, tradeoffs, risks, and recommended next action.

Para coding, esto suele ser mejor de todos modos. No necesitas una transcripción del razonamiento privado del modelo. Necesitas una decisión de ingeniería que puedas inspeccionar.

10. Usa Fable para revisión de código después de que otro modelo escriba el código

Uno de los mejores patrones es:

Deja que un modelo más barato escriba el diff.
Deja que Fable lo revise.

La página de Fable de Anthropic incluye feedback de un cliente que dice que Fable revisó un PR redactado por Opus e hizo mejoras significativas de una sola pasada. La misma página incluye feedback de que Fable es fuerte en diseño de UI, programación de juegos, comprensión de la intención y en cazar agujeros de diseño complejos.

Un prompt práctico:

/model claude-fable-5
/effort xhigh

Review the current diff as a senior engineer.

Focus on:
- Correctness bugs
- Hidden coupling
- Backwards compatibility
- Missing tests
- Edge cases
- Simpler implementation paths
- Risky assumptions
- Files that should not have changed

Do not rewrite the whole PR. Return only:
1. Must-fix issues
2. Should-fix issues
3. Tests to add or run
4. Ship/no-ship recommendation

Esta es una tarea perfecta para Fable porque el modelo no está solo generando código. Está juzgando si el trabajo es seguro.

11. Usa subagentes, pero no hagas que todos sean Fable

Fable es bueno delegando. Anthropic dice que es más fiable despachando y sosteniendo subagentes en paralelo, y su guía de prompting recomienda usar subagentes con frecuencia para subtareas independientes.

Pero eso no significa que cada subagente deba usar Fable.

La documentación de costes de Claude Code recomienda usar modelos más baratos para los compañeros de equipo, mantener los equipos pequeños, mantener los prompts de arranque enfocados y apagar a los compañeros cuando terminan.

Un mejor patrón:

Fable = orquestador
Sonnet u Opus = agentes de implementación
Haiku o modelos más baratos = agentes simples de escaneo/extracción
Fable = síntesis y decisión final

Montaje de subagentes de ejemplo:

• Agente de investigación: mapea archivos y dependencias
• Agente de tests: encuentra y corre los tests relevantes
• Agente de implementación: hace las ediciones mecánicas
• Agente de revisión: comprueba la calidad del diff
• Orquestador Fable: decide el plan y la recomendación final

Claude Code te permite crear subagentes personalizados con /agents, elegir sus herramientas, elegir su modelo y restringirlos a herramientas de solo lectura cuando corresponda.

Así es como consigues más salida de calidad Fable sin quemar tokens de Fable en cada paso repetitivo.

12. Usa worktrees para experimentos en paralelo

Si quieres probar múltiples enfoques, aíslalos.

Claude Code soporta git worktrees con claude --worktree, creando directorios de trabajo y branches separados para que las ediciones en una sesión no toquen archivos de otra.

Esto funciona bien con Fable:

Pídele a Fable que proponga dos o tres estrategias de implementación viables.
Corre cada estrategia en un worktree separado con agentes de implementación más baratos.
Trae los diffs de vuelta a Fable para comparar.
Pídele a Fable cuál es el más seguro de lanzar.

Prompt:

Compare these three worktree diffs.

Evaluate:
- Smallest safe change
- Test coverage
- Maintainability
- Regression risk
- Compatibility with current architecture
- Rollback simplicity

Pick one. Explain why. Do not merge anything.

De nuevo, Fable está haciendo lo que mejor sabe: síntesis, criterio y análisis de riesgo.

13. Pídele a Fable que verifique contra resultados de herramientas, no contra intuiciones

Fable es potente, pero aun así deberías hacerle probar su trabajo.

Anthropic recomienda instruir a Fable para que ancle las afirmaciones de progreso en resultados reales de herramientas, y dice que esto casi eliminó los informes de estado fabricados en sus pruebas.

Usa prompts como:

Before reporting success, audit each claim against actual tool output from this session.

Only say something is complete if:
- The code was changed
- The relevant tests were run
- You can cite the command output
- Any skipped verification is explicitly marked as skipped

Para tareas de implementación:

After making changes:
1. Show the files changed.
2. Run targeted tests first.
3. Run typecheck.
4. If tests fail, stop and report the failure honestly.
5. Do not claim success unless verification passed.

Esto es especialmente útil en sesiones largas donde el modelo podría, si no, dar un resumen demasiado confiado.

14. Mantén el contexto pequeño e intencional

Fable tiene una ventana de contexto grande, pero un contexto grande no es gratis.

La documentación de costes de Claude Code dice que los costes de tokens escalan con el tamaño del contexto y recomienda limpiar entre tareas no relacionadas, usar /compact con instrucciones de compactación personalizadas, elegir el modelo adecuado, desactivar los servidores MCP no usados, instalar plugins de inteligencia de código y usar hooks o skills para reducir lecturas de archivos innecesarias.

Reglas prácticas:

• Usa /clear al cambiar de tarea.
• Usa /context para ver qué está consumiendo espacio.
• Usa /compact Focus on test output, decisions, changed files, and unresolved risks.
• No mantengas historial de debugging no relacionado a mano.
• No pegues logs gigantes cuando basta con un resumen de error filtrado.
• Prefiere referencias @file a descripciones vagas.
• Usa herramientas CLI como gh, aws, gcloud o sentry-cli donde corresponda porque Claude Code dice que las herramientas CLI son a menudo más eficientes en contexto que las alternativas de API o MCP.

Fable funciona mejor cuando el contexto es rico, no hinchado.

15. Diagnostica el fallback de forma sistemática

Cuando Fable cambia a Opus 4.8, no te limites a reintentar el mismo prompt.

Pregúntate qué categoría probablemente tocaste.

• ¿La tarea iba de vulnerabilidades, exploits, auth, malware, payloads o rutas de ataque?
• ¿Pedía pasos de reproducción en lugar de remediación?
• ¿Pedía razonamiento oculto?
• ¿Tu CLAUDE.md o un hook estaba inyectando lenguaje sospechoso?
• ¿El prompt de un subagente estaba formulado de forma demasiado amplia?
• ¿La tarea encajaba en realidad mejor con /security-review o con Opus 4.8?

La guía de migración de la Claude API dice que los rechazos de Fable devuelven stop_reason: "refusal" como una respuesta HTTP 200 exitosa, con valores de stop_details.category como cyber, bio o reasoning_extraction. También describe el manejo de fallback de la API para volver a correr las peticiones rechazadas en otro modelo.

Para Claude Code en concreto, la documentación del CLI menciona claude --safe-mode como útil para comprobar si una personalización es lo que dispara el fallback automático desde Fable 5.

Ese es un truco práctico de debugging: si Fable se comporta distinto en modo seguro, tu configuración local puede ser parte del problema.

16. Usa este mapa de tareas

Este es el mapa de enrutado práctico más simple.

Grandes tareas para Fable:

• Revisión de arquitectura
• Planificación de migraciones
• Diagnóstico de bugs complejos
• Refactors multi-archivo
• Revisión final de PR
• Requisitos de producto ambiguos
• Estrategia de tests
• Análisis de dependencias en todo el repositorio
• Revisión de UI desde capturas de pantalla
• Orquestación de agentes de larga duración
• Comparar múltiples enfoques de implementación
• Análisis de "¿por qué es frágil este sistema?"

Buenas pero vigila el coste:

• Escribir tests
• Generar planes de implementación
• Producir documentación a partir del código
• Planes de profiling de rendimiento
• Diseño de API
• Revisión de modelo de datos
• Análisis de fallos de CI
• Planificación de releases
• Onboarding en un codebase grande

Normalmente no vale la pena Fable:

• Arreglos diminutos
• Boilerplate
• Ediciones simples de archivos
• Formateo
• Reescrituras de una sola función
• Subidas de versión de dependencias
• Limpieza básica de documentación
• Comandos de shell rutinarios
• Trabajo simple de buscar y reemplazar

Probable fallback o que requiere un encuadre defensivo cuidadoso:

• Revisión de vulnerabilidades de seguridad
• Revisión de autenticación y autorización
• Debugging cercano a exploits
• Análisis de comportamiento tipo malware
• Peticiones que involucran payloads o bypasses
• Peticiones de razonamiento oculto
• Flujos de trabajo de biología o química

No uses Fable para:

• Desarrollo ofensivo de exploits
• Malware
• Robo de credenciales
• Instrucciones de bypass
• Herramientas de ataque
• Intentos de jailbreak
• Cualquier cosa cuyo objetivo sea evadir las salvaguardas

17. Una biblioteca práctica de prompts de coding para Fable

Usa estos como puntos de partida.

El prompt de arquitectura

Use Fable as a senior staff engineer.

Goal:
Evaluate the architecture for [change].

Please:
1. Map the relevant modules.
2. Identify hidden coupling.
3. Identify the smallest safe implementation path.
4. List risks and tradeoffs.
5. Define verification steps.
6. Recommend whether this should be one PR or multiple PRs.

Do not edit files yet.

El prompt de traspaso de implementación

Turn this plan into an implementation brief for a cheaper coding model.

Include:
- Files to edit
- Exact behavioral changes
- Tests to add
- Commands to run
- Things not to change
- Acceptance criteria

El prompt de revisión final

Review the current diff as a senior engineer.

Return:
1. Must-fix issues
2. Should-fix issues
3. Missing tests
4. Regression risks
5. Ship/no-ship recommendation

Ground every claim in the actual diff or test output.

El prompt de seguridad defensiva

I am reviewing my own authorized codebase.

Perform a defensive review focused on:
- Authentication boundaries
- Authorization checks
- Input validation
- Secrets handling
- Unsafe data exposure
- Test coverage

Do not provide exploit chains, payloads, offensive tooling, or attack instructions.

For each finding, provide:
- File and line
- Risk
- Safe remediation
- Safe regression test

El prompt de diagnóstico de fallback

Analyze why this request may have triggered fallback.

Do not try to bypass safeguards. Instead:
1. Identify ambiguous or risky wording.
2. Rewrite the task with a clearly defensive, authorized scope.
3. Remove requests for exploit reproduction or hidden reasoning.
4. Suggest whether this belongs in Fable, Opus, /security-review, or a human review.