Una sola sesión agéntica puede consumir 78.2 millones de tokens y costar 99.26 dólares, casi el 90% del gasto diario en un solo loop. Más contexto no equivale a mejor resultado: a veces produce peor salida y una cuenta más alta. Si trabajas con modelos de contexto largo, entender qué cabe dentro de ese millón de tokens y cómo se queman es la diferencia entre escalar y reventar el presupuesto.

¿Qué cabe realmente en un millón de tokens de contexto?

El millón de tokens es un espacio compartido, no un conjunto de contadores separados. Ahí entra todo junto: system prompt, definiciones de herramientas, historial completo y output del modelo.

El output tiene su propio techo de 128.000 tokens por respuesta, e incluye el thinking, que siempre está activo. Para trabajo agéntico, el punto de partida recomendado es 64.000 tokens de max_tokens.

¿Cuánto cuesta una sesión agéntica de contexto largo? Una sesión documentada consumió 78.2 millones de tokens y costó 99.26 dólares, casi el 90% del gasto de todo un día en un único loop.

¿Cómo afecta el nuevo tokenizer a tus prompts existentes?

El mismo texto que en un modelo anterior ocupaba 700.000 tokens puede subir a 945.000 en Fable 5. Un prompt que creías seguro a 800.000 puede cruzar el millón bajo el nuevo tokenizer y disparar errores.

La verificación es obligatoria. Usa el endpoint gratuito count_tokens sobre tus prompts reales antes de asumir que entran. [00:53]

¿Cuándo usar contexto largo y cuándo memoria persistente?

El criterio de decisión es simple: ¿la información necesita sobrevivir a la sesión actual? El contexto largo funciona como una pizarra en una sala de reuniones. Todo lo escrito ahí es visible ahora, pero cuando la sesión termina, desaparece.

Si tu tarea es procesar un codebase completo de una sola vez, el contexto largo basta. Si la tarea se repite o requiere que el modelo lleve correcciones hacia adelante, necesitas otra cosa.

¿Cómo se construye un sistema de memoria persistente basado en archivos?

Es elegantemente simple: un directorio, por ejemplo memory/lessons/, con un archivo por lección aprendida. Cada archivo tiene una primera línea con un resumen de una oración, y un cuerpo que explica qué pasó, por qué importó y la corrección o enfoque confirmado. [01:49]

Las reglas de qué guardar son claras:

• Guarda correcciones y enfoques confirmados.
• No guardes nada que ya exista en el repositorio o el historial.
• Si una nota resulta incorrecta, elimínala.
• Si necesita actualización, actualízala en lugar de crear otra.

El ciclo que hace funcionar esto es fallar, investigar, verificar, destilar y consultar. En el turno 119 de una tarea agéntica larga, un modelo recordó desde memoria que el usuario prefería walkthroughs con Playwright scripted en vez de clicks directos. Sin memoria externa, esa preferencia se habría perdido en el turno tres. [02:42]

¿Cuáles son los tres modos de fallo en tareas agénticas extendidas?

Aquí es donde se quema dinero real sin que nadie se entere. Reconocerlos a tiempo te ahorra cuentas absurdas.

¿Qué es overplanning y cómo se mitiga?

En effort alto, Fable 5 tiende a reexaminar decisiones ya tomadas, listar opciones que nunca seguirá y repetir razonamiento previo. Quema tokens sin producir avance.

La mitigación va en el system prompt: indícale que actúe cuando tenga suficiente información, que no rederive hechos establecidos y que no narre opciones que no va a seguir. [03:11]

¿Qué es fabricated-progress?

¿Qué significa que un modelo fabrique progreso? El modelo reporta algo como hecho cuando no lo verificó. En un caso real, ejecutó checks estáticos y dijo que el cambio estaba verificado end-to-end; al correrlo, falló en runtime. Nunca ejecutó un flow run real.

La mitigación es forzar al modelo a auditar cada claim contra un tool result de esa sesión antes de reportar progreso. [03:37]

¿Qué es early-stopping por ansiedad de contexto?

El modelo se detiene prematuramente creyendo que se queda sin espacio cuando no es cierto. Un caso documentado muestra un modelo con 2.43 millones de tokens disponibles que hizo una sola búsqueda y se detuvo habiendo usado 3.637. [04:04]

La solución es doble: deja de mostrarle countdowns de tokens e instrúyele explícitamente que tiene contexto amplio y que no se detenga.

¿Por qué tus prompts legacy ya no funcionan igual?

Aquí viene lo contraintuitivo. El scaffolding paso a paso que ayudaba a modelos más débiles ahora actúa como una restricción sobre un modelo más capaz. Es como darle a un constructor experimentado un checklist escrito para un aprendiz: empieza a seguirlo mecánicamente y pierde cosas que normalmente atraparía solo.

Los síntomas son concretos:

• Cualquier instrucción tipo muestra tu razonamiento activa el clasificador de reasoning extraction y produce un refusal.
• Listas rígidas de pasos hacen que los outputs se sientan restringidos.
• Aumentan los declines a mitad de generación, y esos tokens ya consumidos se cobran igual.

¿Cómo migrar un prompt legacy sin perder calidad?

Corre un test A/B sobre tu prompt heredado. Quita los pasos enumerados, declara el objetivo y las restricciones de forma llana, y compara midiendo éxito de tarea y costo por tarea resuelta. [05:11]

Si tienes system prompts con instrucciones detalladas paso a paso heredadas de Sonnet u Opus, ese es tu primer candidato para este experimento. Cuéntame en los comentarios cuántos tokens estás quemando hoy en overplanning sin saberlo.