Nueve centavos contra setenta y dos centavos. Misma tarea, mismo modelo, mismo endpoint. La única diferencia es un parámetro llamado output_config.effort, la decisión de costo más importante que tomas en cada request a Fable 5 y que la mayoría deja en default sin pensarlo.

La clase anterior dejó claro que el thinking en Fable 5 está siempre activo: no hay switch, el modelo razona antes de responder. Lo que controlas con effort es cuánto razona. Y eso, en producción, define tu factura.

Qué es output_config.effort y por qué importa

Es un campo formal dentro de output_config que acepta cinco valores: low, medium, high, xhigh y max. El default es high, así que si nunca lo tocaste, ya estás pagando ese nivel por defecto.

Aquí va la confusión más común que vale aclarar desde el inicio [0:46].

Effort no es lo mismo que display mode

El display mode que viste antes, con valores omitted o summarized, cambia lo que ves del trabajo. Effort cambia el trabajo que se hace. Dicho simple: display es la ventana por la que miras; effort es el tamaño del motor.

¿Effort y display mode son lo mismo? No. Display mode controla qué porción del razonamiento te muestran. Effort controla cuánto razonamiento ocurre realmente antes de la respuesta.

¿Y no podrías lograr lo mismo escribiendo piensa paso a paso en el prompt? No de forma confiable. Eso es steering suave: el modelo puede ignorarlo. Effort es un parámetro formal de la API, medible, consistente y confiable entre llamadas [1:08].

Cómo se comporta cada nivel de effort en Fable 5

Cada valor activa una intensidad distinta de razonamiento [1:18]:

• low: minimiza el thinking y lo salta en tareas simples. Pensado para alto volumen y subagentes rápidos.
• medium: puede saltarse el thinking en queries triviales y lo activa cuando la tarea lo requiere.
• high: casi siempre piensa. Es el punto de partida recomendado y el default.
• xhigh: siempre piensa con exploración extendida. Útil para coding de largo horizonte o tareas agénticas complejas.
• max: piensa sin restricción, solo para problemas donde la latencia no importa.

Lo contraintuitivo viene aquí. Según la documentación oficial, lower effort en Fable 5 frecuentemente supera el rendimiento de xhigh en modelos anteriores. Fable arranca desde un piso más alto, así que bajar de nivel no significa resultados pobres. Eso desmonta el patrón de poner siempre max por default [1:56].

Cuánto cuesta cada nivel y por qué duele tanto

El spread de costo entre niveles es brutal: siete equis entre low y max sobre la misma tarea [2:10]. Y recuerda que los thinking tokens se facturan siempre, sin importar el display mode.

Hay un detalle extra que multiplica todo. El tokenizer de Fable genera 30% más tokens que Opus 4.8, y el precio por token ya es el doble. El multiplicador compuesto llega a 2.5x [2:33]. Combinado con el spread de 7x entre niveles, elegir effort deja de ser optimización menor y se convierte en control de presupuesto.

¿Por qué Fable 5 sale más caro aunque uses el mismo prompt? Porque su tokenizer produce 30% más tokens que Opus 4.8 y el precio por token es el doble. El efecto compuesto es 2.5x antes de tocar effort.

Cómo usar effort en un flujo real

No todos los pasos necesitan la misma profundidad. El triaje es rápido y repetitivo. La implementación es donde la profundidad paga.

En la API directa, cada llamada a messages.create puede llevar un effort diferente. Tu paso de triaje envía low, tu paso de implementación envía high o xhigh. Mismo modelo, distinta intensidad [3:08].

Cómo configurar effort en Claude Code con subagentes

Cada subagente declara su effort en su frontmatter. Pero ojo con la jerarquía: la variable de entorno CLAUDE_CODE_EFFORT_LEVEL tiene prioridad máxima. Si la seteaste globalmente en low, el frontmatter que dice high no aplica [3:20].

Cómo encontrar el nivel óptimo para cada ruta

Corres un sweep. Tomas cada tipo de tarea (por ejemplo code review, clasificación de tickets y refactor) y la ejecutas contra cada nivel. Colectas cuatro señales:

1. Calidad del resultado.
2. Tokens totales.
3. Thinking tokens.
4. Stop_reason.

La métrica que importa no es costo por request sino costo por tarea completada: costo por intento dividido por tasa de éxito [3:48]. Un modelo barato que falla seguido puede costarte más que uno caro que acierta a la primera.

¿Cuál es la mejor métrica para comparar niveles de effort? Costo por tarea completada, no por request. Divide el costo del intento entre la tasa de éxito y compara entre niveles.

Haz el ejercicio mental con tu ruta más frecuente en producción. ¿Realmente necesita high, o medium la resolvería igual? Cuéntame en los comentarios qué nivel estás usando hoy por default y en qué tipo de tarea sospechas que estás pagando de más.