Cómo Optimizar el Consumo de Tokens en OpenClaw

Si tu agente OpenClaw usa un LLM vía API, cada token que envías o recibes tiene un coste. Y la mayoría de configuraciones por defecto desperdician entre un 30% y un 50% de tokens en información innecesaria.

¿Dónde se desperdician tokens?

• System prompts demasiado largos: instrucciones detalladas que se envían en cada petición- Historial de conversación sin comprimir: mensajes antiguos que ya no son relevantes- Respuestas verbosas: el modelo genera texto innecesario sin instrucciones de brevedad- Sin model routing: usar un modelo caro para tareas que un modelo barato resolvería igual Un agente OpenClaw bien optimizado puede reducir su factura de tokens un 70% sin pérdida perceptible de calidad.

El system prompt se envía en cada petición al modelo. Un prompt de 2.000 tokens que se envía 1.000 veces al día son 2 millones de tokens solo en instrucciones.

Antes (verbose, ~800 tokens):

Eres un asistente de atención al cliente para la empresa XYZ.
Tu objetivo es ayudar a los usuarios con sus consultas de manera
amable y profesional. Debes responder siempre en español.
Si no sabes la respuesta, indica al usuario que contacte
con soporte humano. No inventes información...

Después (compacto, ~200 tokens):

Rol: soporte XYZ. Idioma: ES. Si no sabes → "contacta soporte".
No inventar. Respuestas ≤3 frases salvo que se pida más.

Ahorro: 600 tokens × 1.000 peticiones/día = 600.000 tokens/día menos. Con DeepSeek V3, eso son ~$0.16/día o ~$5/mes solo por comprimir el system prompt.

OpenClaw incluye una función llamada heartbeat que comprime automáticamente el historial de conversación cuando supera un umbral de tokens.

En vez de enviar los últimos 50 mensajes completos, heartbeat los resume en un resumen compacto que mantiene el contexto esencial.

# config.yaml
memory:
  heartbeat:
    enabled: true
    threshold: 4000  # tokens antes de comprimir
    summary_model: glm-4-flash  # modelo barato para resumir
    keep_recent: 5  # mantener últimos 5 mensajes sin comprimir

Resultado: una conversación de 100 mensajes que normalmente consumiría 20.000 tokens se comprime a ~3.000 tokens de resumen + los últimos 5 mensajes.

Para una guía detallada de heartbeat, lee nuestro artículo específico sobre configuración heartbeat en OpenClaw.

No todas las tareas necesitan el mismo modelo. Model routing asigna cada tarea al modelo más económico capaz de resolverla.

# config.yaml
routing:
  default: glm-4-flash  # $0.007/1M tokens
  rules:
    - condition: task.complexity > 0.7
      model: deepseek-v3  # $0.27/1M tokens
    - condition: task.type == "code"
      model: deepseek-v3
    - condition: task.type == "classify"
      model: glm-4-flash

Impacto real: un equipo que procesaba 5M tokens/día con DeepSeek V3 ($1.35/día) migró el 75% del tráfico a GLM-4 Flash. Nuevo coste: $0.37/día. Ahorro del 73%.

No puedes optimizar lo que no mides. OpenClaw incluye métricas de consumo de tokens integradas:

# Activar métricas detalladas
metrics:
  enabled: true
  token_tracking: true
  export: prometheus  # o json, csv
  dashboard_port: 9090

Con las métricas activadas, puedes ver:

• Tokens consumidos por modelo, por hora, por tipo de tarea- Ratio input/output (importante para estimar costes)- Peticiones que superan umbrales de tokens- Eficiencia del heartbeat (tokens ahorrados por compresión) Tip: revisa las métricas semanalmente y ajusta los umbrales de routing y heartbeat según los patrones reales de uso.