XERJ es un buscador local para agentes de código: indexa una carpeta (código, documentación, logs, PDF) y deja que el agente recupere pasajes en lugar de leer archivos enteros. El repositorio ronda las 5,6k estrellas según su página de GitHub (consultada el 16 de octubre de 2026) y aparece en el Trending diario, lo que lo convierte en uno de los proyectos del momento para quien trabaja con agentes.
Qué es
Es un único binario estático escrito en Rust, sin JVM ni dependencias, con versiones para Linux, macOS y Windows en x86-64 y arm64. Su gancho es que implementa la API REST de Elasticsearch, así que los clientes que ya hablan con Elasticsearch pueden apuntar a XERJ sin cambios. La licencia es Apache-2.0.
Por dentro, el comando autoindex detecta los tipos de fichero y crea un índice por conjunto de datos inferido. El código se analiza con tree-sitter para conservar símbolos y números de línea. La búsqueda combina texto completo (BM25), vectorial (kNN) e híbrida con la sintaxis de consulta de Elasticsearch. Para los agentes expone un servidor MCP por stdio (xerj mcp) con 13 herramientas, entre ellas búsqueda, memoria (guardar y recuperar) y un pipeline de búsqueda de código. El embedder por defecto es léxico y funciona sin conexión; uno neuronal exige preparar ficheros de modelo aparte.
Cómo se usa
Según el README, la instalación es un script y el uso mínimo cuatro comandos:
curl -fsSL https://xerj.org/get | sh
xerj --insecure --data-dir ./data &
xerj autoindex ~/my-project
xerj search "how do we rotate the WAL segment"También se puede consultar con la API clásica:
curl "localhost:9200/ax-*/_search?q=checkout+error"Dos advertencias prácticas. Primero, curl | sh es una práctica que no recomiendo sin leer el script antes. Segundo, --insecure desactiva TLS y autenticación: el README dice que el nodo escucha solo en 127.0.0.1, pero es un modo de desarrollo para un solo usuario. En un host compartido hay que activar la autenticación.
Lo que me convence y lo que no
Me convence la idea de reutilizar un contrato conocido (la API de Elasticsearch) y el despliegue en un solo binario: para un SRE, algo que no necesita un clúster ni una JVM baja mucho la fricción de probarlo. Que el servidor MCP venga de serie también ayuda a integrarlo con agentes de código.
Lo que me frena: el propio README admite límites. El scroll es una instantánea acotada y las consultas que superan la ventana devuelven un 400 en lugar de truncar; se recomienda search_after. La conformidad con Elasticsearch es de 1366 de 1369 casos, y en latencia p99 de lectura con un escritor concurrente a alto ritmo reconoce perder frente a Elasticsearch 8.13.4. La calidad del reranking con el modelo real aparece como no verificada, y el reranker opcional externo (Jev) envía texto de los resultados fuera del nodo, aunque está desactivado por defecto.
Además, las cifras de ahorro de tokens no son consistentes dentro de la propia página: el texto de presentación habla de "40x menos tokens que grep" y el caso de estudio del cuerpo, de 2,7x menos tokens de salida. El README añade que el beneficio depende de que el modelo no haya memorizado ya el código, y que es neutro o incluso perjudicial con librerías públicas populares. Yo me quedaría con el 2,7x como orden de magnitud y lo mediría en mi propio repositorio antes de adoptarlo.
Como alternativa conviene recordar que ripgrep más un buen índice de símbolos cubre buena parte de los casos sin servicio extra; XERJ compensa cuando el corpus incluye logs, PDF y documentación mezclados con el código.
XERJ frente a Graphify
La comparación con Graphify surge en cuanto se busca estructurar contexto para agentes, pero atacan el problema desde frentes distintos: búsqueda documental híbrida frente a modelado relacional en grafo.
XERJ trata el repositorio como un corpus de texto heterogéneo: trocea código mediante tree-sitter, pero lo almacena junto a logs, Markdown y PDFs para responder a consultas léxicas (BM25) y vectoriales (kNN). Su meta es entregar pasajes concretos y líneas de código exactas sin obligar al agente a cargar ficheros completos en su ventana de contexto. No modela ni resuelve las relaciones de software entre módulos.
Graphify, en cambio, procesa el código para generar un grafo de conocimiento y dependencias (nodos para archivos, clases o funciones vinculados por aristas como CALLS, IMPORTS o herencia) que suele exportarse a motores como Neo4j o NetworkX. Está pensado para resolver dudas topológicas y de impacto: qué dependencias se rompen al alterar una interfaz, qué camino de ejecución sigue una llamada o qué grado de acoplamiento existe entre paquetes.
En la práctica resultan complementarios: Graphify ayuda al agente a razonar sobre la arquitectura y la jerarquía de dependencias del proyecto, mientras que XERJ resuelve la recuperación rápida de fragmentos de código, documentación y trazas de error sin levantar bases de datos de grafos ni infraestructura adicional.
Fuentes
- Repositorio de XERJ en GitHub (README, licencia y estrellas), consultado el 16 de octubre de 2026.