Qué es Fable 5
Fable 5 (identificador claude-fable-5 en la API) es el modelo más potente del catálogo de Claude en 2026. Hasta ahora la escalera de Anthropic terminaba en Opus; con Fable 5 aparece un nivel nuevo arriba, pensado para los problemas más duros: razonamiento profundo, sesiones de trabajo autónomas y proyectos donde el modelo necesita sostener el contexto durante horas.
Convive con el resto de la familia: Opus 4.8 sigue siendo el caballo de batalla para trabajo exigente, Sonnet 4.6 equilibra velocidad y capacidad, y Haiku 4.5 cubre las tareas simples y baratas. Fable 5 entra cuando el problema justifica pagar por el techo de inteligencia disponible.
Qué se siente distinto al usarlo
No voy a citar cifras de contexto, benchmarks ni precios: cambian rápido y para eso está la documentación de Anthropic. Lo que sí puedo contar es lo que cambió en nuestro día a día desde que lo metimos al sistema.
- Criterio: pregunta menos por reflejo y mejor cuando importa. Si la tarea está clara, la ejecuta; si hay una decisión que es tuya, te la trae con contexto.
- Trabajo largo: sostiene sesiones de horas con herramientas sin perder el hilo del objetivo original.
- Verificación: tiende a comprobar lo que hizo —correr la prueba, mirar el resultado, sacar la captura— en vez de declarar éxito y seguir.
- Redacción: escribe con más intención. Nota cuándo un texto suena a plantilla y lo corrige solo.
Es el modelo premium del catálogo y se nota en la factura. Por eso mi regla es simple: las tareas rutinarias se quedan en modelos más baratos y Fable 5 se reserva para lo que de verdad necesita su nivel, midiendo costo por tarea resuelta como cuento en el artículo de tokens y costos.
Cómo lo usamos de verdad: tres casos
Nada de escenarios hipotéticos. Estos tres salieron de nuestro propio sistema, ai-web-agent, y se pueden contrastar contra esta misma web.
Levantar y publicar esta web desde otra PC
DelpaQQ corre en una máquina que no es la de trabajo. Con un runner remoto conectado al sistema, el modelo encontró el repo buscando en los discos de esa PC, se instaló ripgrep para buscar más rápido, levantó el servidor Node, detectó que el proxy de IIS apuntaba a un puerto equivocado, lo corrigió y dejó el certificado HTTPS emitido. Cada paso quedó registrado: qué comando corrió, qué falló y cómo lo resolvió.
Dirigir workflows de varios agentes
Cuando el trabajo es grande, Fable 5 no lo hace solo: arma un grafo de agentes. Para renovar el contenido de este sitio, el flujo fue auditar el texto, reescribir en paralelo por grupos de páginas, pasar un crítico que busca lo que falta y cerrar con un validador. Cada nodo puede usar un modelo distinto según lo que necesite, y el director decide esa mezcla.
Este artículo, sin ir más lejos
El texto que estás leyendo lo redactó Fable 5, igual que la revisión del resto del sitio para quitarle los tics de texto generado por IA: las frases plantilla, las listas calcadas, los cierres motivacionales. Que un modelo detecte y corrija los vicios de escritura de los modelos es, honestamente, la parte que más me divierte.
Cómo encaja con UOrder y los runners
Para mí, la parte interesante llega al combinarlo con la arquitectura que vengo armando. El modelo pone el razonamiento; los runners ponen la ejecución con permisos y logs; y UOrder, como conductor, reparte el trabajo y junta la evidencia. Un modelo más capaz significa planes mejores y menos pasos desperdiciados, pero el control operativo —quién aprueba, qué se registra, cuánto se gasta— sigue viviendo en la capa de orquestación.
Y un detalle que vale oro: los runners son agnósticos al modelo. Cuando salió Fable 5 no tuvimos que tocar nada de la capa de ejecución; cambiamos el cerebro y todo lo demás —permisos, logs, evidencia— siguió funcionando igual. Adoptar el modelo nuevo tomó una decisión, no una migración.
Cambiar de modelo mejora resultados, pero ningún modelo arregla un proceso mal definido. Si la tarea está vaga, Fable 5 producirá una respuesta carísima y vaga. Primero el flujo, después el modelo.
Mi lectura
Fable 5 confirma hacia dónde va la industria: modelos que sostienen trabajo largo y autónomo, con el razonamiento regulado por la propia tarea. Para una empresa, la decisión sigue siendo de cartera: usar el modelo grande donde el problema lo amerita y medir el avance real de cada flujo.