Cuando el contexto se llena, aprende a podar

¿Por qué compactar?

Con el tiempo, messages[] se infla: cada read_file devuelve miles de tokens, cada bash devuelve cientos, y el texto de razonamiento del modelo se acumula turno a turno. Tras 50 rondas el contexto puede superar los 100K tokens. Dos consecuencias:

• Límite de ventana: al alcanzar el tamaño máximo el sistema falla, o cada llamada API se encarece linealmente.
• Dilución de atención: la tarea actual queda sepultada bajo tool_results irrelevantes de hace 30 turnos y el modelo empieza a cometer errores.

La estrategia de s06: hacer que el agent olvide activamente el contenido no importante preservando el estado clave. Tres capas, de menor a mayor intervención.

Capa 1 · micro_compact (corre en silencio cada turno)

La capa más barata. Antes de cada llamada LLM, reemplaza los tool_results que superen los 3 últimos con un placeholder:

# A partir del turno 10, la mayoría de tool_results se convierte en:
{
  "type": "tool_result",
  "tool_use_id": "toolu_01A",
  "content": "[Previous: used bash]"   # de miles de chars a unas pocas palabras
}

Excepción: los resultados de read_file nunca se comprimen. ¿Por qué? El output de read es material de referencia; comprimirlo obligaría al modelo a releer el archivo, lo que sería más caro en total.

PRESERVE_RESULT_TOOLS = {"read_file"}  # nunca se comprime

Ve cómo micro_compact envejece los resultados antigios paso a paso

El siguiente simulador muestra 10 rondas de interacción; antes de cada turno se ejecuta micro_compact. Observa cómo los tool_results más antiguos se convierten en [Previous: ...] mientras los 3 más recientes permanecen intactos.

Capa 2 · auto_compact (se activa al superar el umbral)

Aunque micro esté corriendo continuamente, el contexto puede crecer hasta desbordarse. s06 define un umbral de 50 000 tokens:

1. Estima el número de tokens: len(str(messages)) // 4 (aproximación suficiente para este propósito).
2. Si supera el umbral → vuelca el transcript completo a .transcripts/transcript_TIMESTAMP.jsonl (para no perder nada).
3. Pide al LLM que genere un summary de toda la conversación.
4. Reemplaza messages entero por un solo mensaje "[compressed] SUMMARY...".

El coste es obvio — se pierden los detalles de las herramientas y el tono de la conversación, solo queda el esquema. Pero el agent puede continuar trabajando, que es el beneficio fundamental.

Capa 3 · el modelo llama a la herramienta compact

auto_compact lo dispara el harness automáticamente, sin que el modelo lo sepa. La Capa 3 invierte eso: se le da al modelo una herramienta compact para que pida la compresión por iniciativa propia — por ejemplo, cuando considera que la fase de exploración ya terminó y quiere empezar de nuevo.

El modelo la llama así:

tool_use("compact", focus="keep the API design decisions")

Se activa igual que auto, pero con un parámetro focus que guía el resumen. En la práctica es muy útil — el modelo sabe qué partes son «tarea terminada» mejor que ninguna heurística automática.

¿Qué capa aplicar? Casos de decisión

Dado el siguiente escenario, ¿qué capa tiene más sentido activar: micro / auto / manual?