Configuración Heartbeat en OpenClaw: Gestión Inteligente de Contexto

Cada vez que tu agente OpenClaw envía un mensaje al LLM, incluye el historial completo de la conversación como contexto. A medida que la conversación crece, el número de tokens enviados crece linealmente.

Una conversación de 100 intercambios puede consumir 20.000-30.000 tokens solo en contexto, sin contar la respuesta del modelo. Con modelos como Claude ($3/1M tokens input), eso es mucho dinero tirado a la basura en mensajes antiguos que probablemente no son relevantes.

El heartbeat resuelve esto con un mecanismo simple: cuando el historial supera un umbral de tokens, automáticamente resume los mensajes antiguos en un párrafo compacto y mantiene solo los mensajes recientes sin comprimir.

El proceso del heartbeat tiene 4 fases:

1. Monitoreo: Después de cada intercambio, OpenClaw cuenta los tokens totales del historial.

2. Activación: Cuando el conteo supera el threshold, se activa el heartbeat.

3. Compresión: Los mensajes más antiguos (excepto los últimos N definidos por keep_recent) se envían a un modelo de resumen (idealmente barato, como GLM-4 Flash) que genera un resumen compacto.

4. Reemplazo: El historial se reemplaza por: [resumen compacto] + [últimos N mensajes].

Diagrama del flujo:

Mensaje nuevo → Contar tokens → ¿Supera threshold?
  → NO: enviar historial normal al LLM
  → SÍ: resumir mensajes antiguos → reemplazar → enviar al LLM

El resultado: el contexto nunca crece sin control, y el agente mantiene memoria funcional de toda la conversación.

En tu archivo config.yaml de OpenClaw, añade o modifica la sección memory.heartbeat:

memory:
  heartbeat:
    enabled: true

    # Número de tokens que activan la compresión
    threshold: 4000

    # Modelo usado para generar el resumen (usa uno barato)
    summary_model: glm-4-flash

    # Mensajes recientes que se mantienen sin comprimir
    keep_recent: 5

    # Longitud máxima del resumen generado (en tokens)
    max_summary_length: 500

    # Incluir system prompt en el resumen
    include_system_context: true

Explicación de cada parámetro:

• threshold (4000): cuántos tokens debe tener el historial antes de activar la compresión. Valores más bajos comprimen más agresivamente.- summary_model: el modelo que genera el resumen. Usa el más barato posible — GLM-4 Flash es ideal.- keep_recent (5): los últimos 5 mensajes se mantienen íntegros. Esto preserva el contexto inmediato de la conversación.- max_summary_length (500): límite de tokens para el resumen. Evita que el resumen crezca tanto como el original.

EscenarioSin heartbeatCon heartbeatAhorro100 conversaciones/día, 20 msgs cada una4M tokens/día1.2M tokens/día70%500 conversaciones/día, 10 msgs cada una5M tokens/día2M tokens/día60%1000 conversaciones/día, 50 msgs cada una50M tokens/día12M tokens/día76% En dinero real (con DeepSeek V3 a $0.27/1M input):

• Escenario 1: ahorro de $0.76/día → $23/mes- Escenario 2: ahorro de $0.81/día → $24/mes- Escenario 3: ahorro de $10.26/día → $308/mes Para volúmenes altos, el heartbeat se paga solo en horas.

1. Threshold demasiado bajo: Si comprimes con menos de 2000 tokens, el resumen puede perder información crítica. Mantén el threshold por encima de 3000.

2. Usar el modelo principal para resumir: No gastes tokens caros en generar resúmenes. Usa siempre un modelo barato como GLM-4 Flash para esta tarea.

3. keep_recent = 0: Si no mantienes ningún mensaje reciente sin comprimir, el agente pierde contexto inmediato y las respuestas se vuelven genéricas.

4. No monitorear la calidad del resumen: Activa logs para los resúmenes generados y revísalos periódicamente. Un resumen malo puede hacer que el agente "olvide" información importante.

# Activar logs de heartbeat
memory:
  heartbeat:
    debug: true  # Muestra el resumen generado en logs