Home
Blog
Por qué los agentes de IA como OpenClaw queman fichas y cómo reducir costes

Por qué los agentes de IA como OpenClaw queman fichas y cómo reducir costes

Engineering

February 28, 2026

Min Yin

Si has pasado algún tiempo con OpenClaw (antes Clawdbot y Moltbot), ya sabes lo bueno que es este agente de IA. Es rápido, local, flexible y capaz de realizar flujos de trabajo sorprendentemente complejos a través de Slack, Discord, tu código base y prácticamente cualquier otra cosa a la que lo conectes. Pero una vez que empiezas a usarlo en serio, surge rápidamente un patrón: el uso de tokens empieza a aumentar.

Esto no es culpa de OpenClaw en concreto, sino de cómo se comportan la mayoría de los agentes de IA hoy en día. Activan una llamada LLM para casi todo: buscar un archivo, planificar una tarea, escribir una nota, ejecutar una herramienta o hacer una pregunta de seguimiento. Y como los tokens son la moneda universal de estas llamadas, cada acción tiene un coste.

Para entender de dónde viene ese coste, tenemos que mirar bajo el capó a dos grandes contribuyentes:

La búsqueda: Las búsquedas mal construidas arrastran cargas de contexto desbordantes: archivos enteros, registros, mensajes y regiones de código que el modelo no necesitaba realmente.
La memoria: El almacenamiento de información sin importancia obliga al agente a releerla y volver a procesarla en futuras llamadas, lo que agrava el uso de tokens a lo largo del tiempo.

Ambos problemas aumentan silenciosamente los costes operativos sin mejorar la capacidad.

Cómo realizan las búsquedas los agentes de IA como OpenClaw, y por qué eso quema tokens

Cuando un agente necesita información de su base de código o biblioteca de documentos, normalmente hace el equivalente a un Ctrl+F en todo el proyecto. Se devuelven todas las líneas coincidentes, sin clasificar, filtrar ni priorizar. Claude Code implementa esto a través de una herramienta Grep dedicada basada en ripgrep. OpenClaw no tiene una herramienta de búsqueda de código base incorporada, pero su herramienta exec permite al modelo subyacente ejecutar cualquier comando, y las habilidades cargadas pueden guiar al agente para utilizar herramientas como rg. En ambos casos, la búsqueda en el código base devuelve coincidencias de palabras clave sin clasificar y sin filtrar.

Este enfoque de fuerza bruta funciona bien en proyectos pequeños. Pero a medida que los repositorios crecen, también lo hace el precio. Las coincidencias irrelevantes se amontonan en la ventana de contexto del LLM, obligando al modelo a leer y procesar miles de tokens que en realidad no necesita. Una sola búsqueda sin ámbito puede arrastrar archivos completos, enormes bloques de comentarios o registros que comparten una palabra clave pero no la intención subyacente. Si se repite este patrón durante una larga sesión de depuración o investigación, la sobrecarga se acumula rápidamente.

Tanto OpenClaw como Claude Code intentan gestionar este crecimiento. OpenClaw depura las salidas de herramientas sobredimensionadas y compacta los largos historiales de conversaciones, mientras que Claude Code limita la salida de lectura de archivos y soporta la compactación de contextos. Estas medidas funcionan, pero sólo después de que se haya ejecutado la consulta. Los resultados de búsqueda sin clasificar siguen consumiendo tokens, y usted sigue pagando por ellos. La gestión del contexto ayuda a los turnos futuros, no a la llamada original que generó el desperdicio.

Cómo funciona la memoria del agente de IA y por qué también cuesta tokens

La búsqueda no es la única fuente de sobrecarga de fichas. Cada fragmento de contexto que un agente recupera de la memoria también debe cargarse en la ventana de contexto del LLM, y eso también cuesta tokens.

Las APIs del LLM en las que confían la mayoría de los agentes son apátridas: La API de mensajes de Anthropic requiere el historial completo de conversaciones en cada petición, y la API de finalización de chat de OpenAI funciona del mismo modo. Incluso la nueva API de respuestas de OpenAI, que gestiona el estado de la conversación en el servidor, sigue exigiendo la ventana de contexto completa en cada llamada. La memoria cargada en el contexto cuesta tokens, independientemente de cómo llegue a él.

Para evitarlo, los marcos de agentes escriben notas en archivos de disco y vuelven a cargar las notas relevantes en la ventana de contexto cuando el agente las necesita. Por ejemplo, OpenClaw almacena notas curadas en MEMORY.md y añade registros diarios a archivos Markdown con marca de tiempo, luego los indexa con BM25 híbrido y búsqueda vectorial para que el agente pueda recuperar el contexto relevante bajo demanda.

El diseño de la memoria de OpenClaw funciona bien, pero requiere todo el ecosistema de OpenClaw: el proceso Gateway, las conexiones de la plataforma de mensajería y el resto de la pila. Lo mismo ocurre con la memoria de Claude Code, que está vinculada a su CLI. Si estás construyendo un agente personalizado fuera de estas plataformas, necesitas una solución independiente. La siguiente sección cubre las herramientas disponibles para ambos problemas.

Cómo evitar que OpenClaw consuma tokens

Si quieres reducir la cantidad de tokens que consume OpenClaw, puedes utilizar dos palancas.

La primera es mejorar la recuperación, sustituyendo los volcados de palabras clave al estilo grep por herramientas de búsqueda clasificadas y basadas en la relevancia, de modo que el modelo sólo vea la información que realmente importa.
La segunda es mejorar la memoria: pasar de un almacenamiento opaco y dependiente del marco de trabajo a algo que se pueda comprender, inspeccionar y controlar.

Sustituir grep por una mejor recuperación: index1, QMD y Milvus

Muchos agentes de codificación de IA buscan en bases de código con grep o ripgrep. Claude Code tiene una herramienta Grep dedicada basada en ripgrep. OpenClaw no tiene una herramienta de búsqueda de bases de código incorporada, pero su herramienta exec permite al modelo subyacente ejecutar cualquier comando, y se pueden cargar habilidades como ripgrep o QMD para guiar cómo busca el agente. Sin una habilidad centrada en la recuperación, el agente recurre al enfoque que elija el modelo subyacente. El problema central es el mismo en todos los agentes: sin una recuperación clasificada, las coincidencias de palabras clave entran en la ventana contextual sin filtrar.

Esto funciona cuando un proyecto es lo suficientemente pequeño como para que todas las coincidencias quepan cómodamente en la ventana de contexto. El problema empieza cuando una base de código o una biblioteca de documentos crece hasta el punto de que una palabra clave devuelve docenas o cientos de resultados y el agente tiene que cargarlos todos en la ventana de contexto. A esa escala, se necesitan resultados ordenados por relevancia, no sólo filtrados por coincidencia.

La solución estándar es la búsqueda híbrida, que combina dos métodos de clasificación complementarios:

BM25 puntúa cada resultado en función de la frecuencia y la singularidad con que aparece un término en un documento determinado. Un archivo específico que menciona "autenticación" 15 veces tiene una clasificación más alta que un archivo extenso que lo menciona una vez.
La búsqueda vectorial convierte el texto en representaciones numéricas del significado, de modo que "autenticación" puede coincidir con "flujo de inicio de sesión" o "gestión de sesión" aunque no compartan ninguna palabra clave.

Ninguno de los dos métodos es suficiente por sí solo: El BM25 pasa por alto términos parafraseados, y la búsqueda vectorial, términos exactos como códigos de error. La combinación de ambos métodos y la fusión de las listas clasificadas mediante un algoritmo de fusión cubre ambas lagunas.

Las herramientas que se describen a continuación aplican este patrón a diferentes escalas. Grep es la base con la que todo el mundo empieza. index1, QMD y Milvus añaden cada una una búsqueda híbrida con capacidad creciente.

index1: búsqueda híbrida rápida en una sola máquina

index1 es una herramienta CLI que empaqueta la búsqueda híbrida en un único archivo de base de datos SQLite. FTS5 se encarga de BM25, sqlite-vec de la similitud vectorial y RRF de fusionar las listas clasificadas. Las incrustaciones son generadas localmente por Ollama, por lo que nada sale de su máquina.

index1 divide el código por estructura, no por número de líneas: Los archivos Markdown se dividen por encabezados, los archivos Python por AST, JavaScript y TypeScript por patrones regex. Esto significa que los resultados de la búsqueda devuelven unidades coherentes, como una función completa o una sección completa de la documentación, y no intervalos arbitrarios de líneas que se cortan a mitad de bloque. El tiempo de respuesta es de 40 a 180 ms para consultas híbridas. Sin Ollama, se vuelve a BM25-only, que sigue clasificando los resultados en lugar de volcar todas las coincidencias en la ventana contextual.

index1 también incluye un módulo de memoria episódica para almacenar las lecciones aprendidas, las causas de los errores y las decisiones arquitectónicas. Estas memorias viven dentro de la misma base de datos SQLite que el índice de código, en lugar de como archivos independientes.

Nota: index1 es un proyecto en fase inicial (0 estrellas, 4 commits en febrero de 2026). Evalúelo con su propio código base antes de comprometerse.

Lo mejor para: desarrolladores en solitario o equipos pequeños con una base de código que quepa en una máquina, que busquen una mejora rápida sobre grep.
Supéralo cuando: necesites acceso multiusuario al mismo índice, o tus datos excedan lo que un único archivo SQLite maneja cómodamente.

QMD: mayor precisión gracias a la reclasificación LLM local

QMD (Query Markup Documents), creado por el fundador de Shopify Tobi Lütke, añade una tercera etapa: La reclasificación LLM. Después de que BM25 y la búsqueda vectorial devuelvan candidatos, un modelo lingüístico local relee los primeros resultados y los reordena según su relevancia real para la consulta. De este modo se detectan los casos en que tanto las coincidencias de palabras clave como las semánticas arrojan resultados plausibles pero erróneos.

QMD se ejecuta íntegramente en su equipo y utiliza tres modelos GGUF que suman alrededor de 2 GB: un modelo de incrustación (embeddinggemma-300M), un reranker de codificación cruzada (Qwen3-Reranker-0.6B) y un modelo de expansión de consultas (qmd-query-expansion-1.7B). Los tres se descargan automáticamente en la primera ejecución. Sin llamadas a la API en la nube, sin claves API.

La contrapartida es el tiempo de arranque en frío: la carga de los tres modelos desde el disco tarda aproximadamente entre 15 y 16 segundos. QMD admite un modo de servidor persistente (qmd mcp) que mantiene los modelos en memoria entre solicitudes, eliminando la penalización por arranque en frío en caso de consultas repetidas.

Lo mejor para: entornos de privacidad crítica en los que ningún dato puede salir de su máquina y en los que la precisión de la recuperación es más importante que el tiempo de respuesta.
Supérelo cuando: necesite respuestas por debajo del segundo, acceso compartido en equipo o su conjunto de datos supere la capacidad de una sola máquina.

Milvus: búsqueda híbrida a escala de equipo y de empresa

Las herramientas monomáquina anteriores funcionan bien para desarrolladores individuales, pero alcanzan sus límites cuando varias personas o agentes necesitan acceder a la misma base de conocimientos.

Milvus es una base de datos vectorial de código abierto creada para la siguiente fase: distribuida, multiusuario y capaz de gestionar miles de millones de vectores.

Su característica clave para este caso de uso es Sparse-BM25 incorporado, disponible desde Milvus 2.5 y significativamente más rápido en 2.6. Usted proporciona el texto en bruto, y Milvus lo tokeniza internamente utilizando un analizador construido sobre tantivy, luego convierte el resultado en vectores dispersos que son precalculados y almacenados en el momento del índice.

Como la representación BM25 ya está almacenada, la recuperación no necesita recalcular las puntuaciones sobre la marcha. Estos vectores dispersos conviven con los vectores densos (incrustaciones semánticas) en la misma colección. En el momento de la consulta, se fusionan ambas señales con un clasificador como RRFRanker, que Milvus proporciona de forma inmediata. El mismo patrón de búsqueda híbrida que index1 y QMD, pero ejecutado en una infraestructura que escala horizontalmente.

Milvus también proporciona capacidades que las herramientas de una sola máquina no pueden ofrecer: aislamiento multiusuario (bases de datos o colecciones separadas por equipo), replicación de datos con conmutación por error automática y agrupación de datos en caliente/frío para un almacenamiento rentable. Para los agentes, esto significa que varios desarrolladores o varias instancias de agentes pueden consultar la misma base de conocimientos de forma simultánea sin pisar los datos de los demás.

Lo mejor para: varios desarrolladores o agentes que comparten una base de conocimientos, conjuntos de documentos grandes o en rápido crecimiento, o entornos de producción que necesitan replicación, conmutación por error y control de acceso.

En resumen:

Herramienta	Etapa	Despliegue	Señal de migración
Claude Grep nativo	Creación de prototipos	Integrado, configuración cero	Las facturas suben o las consultas se ralentizan
índice1	Una sola máquina (velocidad)	SQLite local + Ollama	Necesidad de acceso multiusuario o los datos superan a una sola máquina
QMD	Una sola máquina (precisión)	Tres modelos GGUF locales	Necesidad de índices compartidos por el equipo
Milvus	Equipo o producción	Clúster distribuido	Grandes conjuntos de documentos o requisitos multiusuario

Reducción de los costes de tokens del agente de IA proporcionándole memoria persistente y editable con memsearch

La optimización de la búsqueda reduce el gasto de tokens por consulta, pero no ayuda con lo que el agente retiene entre sesiones.

Cada fragmento de contexto que un agente recupera de la memoria tiene que cargarse en el prompt, y eso también cuesta tokens. La cuestión no es si almacenar memoria, sino cómo. El método de almacenamiento determina si puedes ver lo que el agente recuerda, arreglarlo cuando está mal y llevártelo contigo si cambias de herramienta.

La mayoría de los frameworks fallan en los tres aspectos. Mem0 y Zep almacenan todo en una base de datos vectorial, que funciona para la recuperación, pero hace que la memoria:

Opaca. No se puede ver lo que el agente recuerda sin consultar una API.
Difícil de editar. Corregir o eliminar una memoria implica llamadas a la API, no abrir un archivo.
Bloqueada. Cambiar de entorno implica exportar, convertir y volver a importar los datos.

OpenClaw adopta un enfoque diferente. Toda la memoria vive en archivos Markdown en el disco. El agente escribe registros diarios automáticamente, y los humanos pueden abrir y editar cualquier archivo de memoria directamente. Esto resuelve los tres problemas: la memoria es legible, editable y portátil por diseño.

La contrapartida es la sobrecarga de despliegue. Ejecutar la memoria de OpenClaw significa ejecutar todo el ecosistema de OpenClaw: el proceso Gateway, las conexiones de la plataforma de mensajería y el resto de la pila. Para los equipos que ya utilizan OpenClaw, está bien. Para todos los demás, la barrera es demasiado alta. memsearch se construyó para cerrar esta brecha: extrae el patrón de memoria Markdown-first de OpenClaw en una biblioteca independiente que funciona con cualquier agente.

memsearch, creada por Zilliz (el equipo detrás de Milvus), trata los archivos Markdown como la única fuente de verdad. Un MEMORY.md contiene hechos y decisiones a largo plazo que escribes a mano. Los registros diarios (2026-02-26.md) se generan automáticamente a partir de los resúmenes de sesión. El índice vectorial, almacenado en Milvus, es una capa derivada que puede reconstruirse a partir del Markdown en cualquier momento.

En la práctica, esto significa que puede abrir cualquier archivo de memsearch en un editor de texto, leer exactamente lo que sabe el agente y cambiarlo. Guarde el archivo, y el vigilante de archivos de memsearch detectará el cambio y lo reindexará automáticamente. Puede gestionar memorias con Git, revisar memorias generadas por la IA a través de pull requests, o trasladarse a una nueva máquina copiando una carpeta. Si se pierde el índice de Milvus, se reconstruye a partir de los archivos. Los archivos nunca corren peligro.

Bajo el capó, memsearch utiliza el mismo patrón de búsqueda híbrido descrito anteriormente: trozos divididos por la estructura de los encabezados y los límites de los párrafos, recuperación BM25 + vectorial, y un comando compacto impulsado por LLM que resume las memorias antiguas cuando los registros crecen.

Lo mejor para: equipos que quieren una visibilidad completa de lo que recuerda el agente, necesitan un control de versiones sobre la memoria o quieren un sistema de memoria que no esté limitado a un único marco de agentes.

En resumen:

Capacidad	Mem0 / Zep	memsearch
Fuente de verdad	Base de datos vectorial (única fuente de datos)	Archivos Markdown (primarios) + Milvus (índice)
Transparencia	Caja negra, requiere API para inspeccionar	Abra cualquier archivo .md para leerlo
Editabilidad	Modificación mediante llamadas a la API	Edición directa en cualquier editor de texto, con reindexación automática
Control de versiones	Requiere un registro de auditoría independiente	Git funciona de forma nativa
Coste de migración	Exportar → convertir formato → reimportar	Copiar la carpeta Markdown
Colaboración entre humanos e IA	La IA escribe, los humanos observan	Los humanos pueden editar, complementar y revisar

Qué configuración se adapta a tu escala

Escenario	Búsqueda	Memoria	Cuándo avanzar
Prototipo inicial	Grep (integrado)	-	Las facturas suben o las consultas se ralentizan
Desarrollador único, sólo búsqueda	index1 (velocidad) o QMD (precisión)	-	Necesidad de acceso multiusuario o los datos superan a una sola máquina
Desarrollador único, ambos	índice1	memsearch	Necesidad de acceso multiusuario o los datos superan una máquina
Equipo o producción, ambos	Milvus	memsearch	-
Integración rápida, sólo memoria	-	Mem0 o Zep	Necesidad de inspeccionar, editar o migrar memorias

Conclusión

Los costes simbólicos que conllevan los agentes de IA siempre activos no son inevitables. Esta guía cubre dos áreas en las que una mejor herramienta puede reducir los residuos: búsqueda y memoria.

Grep funciona a pequeña escala, pero a medida que las bases de código crecen, las coincidencias de palabras clave no clasificadas inundan la ventana de contexto con contenido que el modelo nunca necesitó. index1 y QMD resuelven esto en una sola máquina combinando la puntuación de palabras clave BM25 con la búsqueda vectorial y devolviendo sólo los resultados más relevantes. Para equipos, configuraciones multiagente o cargas de trabajo de producción, Milvus proporciona el mismo patrón de búsqueda híbrida en una infraestructura que escala horizontalmente.

Para la memoria, la mayoría de los frameworks almacenan todo en una base de datos vectorial: opaca, difícil de editar a mano y bloqueada por el framework que la creó. memsearch adopta un enfoque diferente. La memoria vive en archivos Markdown que puedes leer, editar y controlar con Git. Milvus sirve como un índice derivado que puede reconstruirse a partir de esos archivos en cualquier momento. Tú mantienes el control de lo que sabe el agente.

Tanto memsearch como Mil vus son de código abierto. Estamos desarrollando activamente memsearch y nos encantaría recibir comentarios de cualquiera que lo utilice en producción. Abre una incidencia, envía un PR, o simplemente dinos qué funciona y qué no.

Proyectos mencionados en esta guía:

memsearch: Memoria Markdown-first para agentes de IA, respaldada por Milvus.
Milvus: Base de datos vectorial de código abierto para la búsqueda híbrida escalable.
index1: Búsqueda híbrida BM25 + vectorial para agentes de codificación de IA.
QMD: Búsqueda híbrida local con reordenación LLM.