Reduzca los tokens de OpenClaw Boot en un 43% al reducir el tamaño de la herramienta y los archivos de memoria

Un usuario de r/openclaw redujo el contexto de arranque de su agente de ~9,457 a ~5,400 tokens, una reducción del 43%, al limpiar TOOLS.md y MEMORY.md.
Problemas encontrados
- Inflado de TOOLS.md: Cada herramienta añadía notas de uso, comandos, ejemplos y casos extremos. Útil pero no necesario en cada sesión.
- Crecimiento excesivo de la promoción de memoria: Los candidatos a promoción se añadían directamente a la memoria principal, lo que hacía que
MEMORY.mdcreciera sin límite.
Soluciones aplicadas
- Se cambió
TOOLS.mda un índice (se inyecta automáticamente, por lo que no se puede eliminar). Las notas detalladas se trasladaron atools/; el agente las lee solo cuando se invoca esa herramienta. - Nuevo flujo de memoria:
notas diarias → candidatos a promoción → memoria a largo plazo curada. Los candidatos a promoción van a un archivo separado; la memoria principal solo contiene un puntero. Solo los hechos duraderos necesarios con frecuencia permanecen en la memoria de arranque.
Resultados
Después: el mismo agente, las mismas herramientas, el mismo comportamiento, solo menos carga en cada inicio.
📖 Lee la fuente completa: r/openclaw
👀 Ver también

Auditoría propia de Claude Code encuentra 3GB de residuos en ~/.claude — Así es como limpiarlos
Un usuario le pidió a Claude Code que auditará su propio directorio ~/.claude y encontró 2.6 GB de transcripciones de sesiones obsoletas, 170 MB de registros de reintentos de telemetría fallidos y 153 MB de búferes de deshacer — reduciéndose de 3 GB a menos de 200 MB después de la limpieza.

OpenClaw depura la configuración ESP32+CC1101 de 433 MHz usando HackRF en Raspberry Pi 5
Después de intentos fallidos con GPIO directo y flasheo de ESP32, OpenClaw usó un HackRF para diagnosticar pines Tx/Rx intercambiados en el CC1101, logrando finalmente la captura y repetición autónoma de señales de 433 MHz en una Pi 5.

¿Alto uso de CPU/RAM y reinicios de Gateway en OpenClaw? Desactiva IPv6 para Telegram
Establecer autoSelectFamily: false y dnsResultOrder: 'ipv4first' en la configuración del bot de Telegram detiene los errores ENETUNREACH, corrigiendo alto uso de CPU, congelaciones del bucle de eventos y reinicios de la puerta de enlace.

Cargar silenciosamente cada servidor MCP en cada mensaje destruye el presupuesto de tokens.
Un usuario con 5–6 servidores MCP descubrió que cada prompt cargaba todos los servidores, causando un enorme desperdicio de tokens. Implementar una capa de enrutamiento para cargar solo los servidores relevantes por prompt redujo drásticamente el uso de tokens y mejoró los tiempos de respuesta.