XERJ: un buscador local para agentes de código que confiesa sus propias cifras

Es raro encontrar un proyecto cuya característica más interesante sea su propia confesión.

XERJ es un motor de búsqueda en Rust para código y documentos, pensado para agentes de código, con un protocolo de cable compatible con Elasticsearch y licencia Apache-2.0. Tiene una tabla de benchmarks con cifras reales en dólares. También tiene una nota del mantenedor que admite que su número de estrellas en GitHub está inflado unas trece veces por una cohorte sintética, y que pide que no se cite.

Las dos cosas merecen tu tiempo, y están relacionadas.

El problema que ataca

Cuando un agente de código necesita entender un repositorio, el movimiento por defecto es grep. Grep es honesto: encuentra líneas que coinciden con un patrón. Pero un agente que usa grep tiene que leer archivos para saber si la coincidencia importa, y leer archivos es justo lo que llena una ventana de contexto. Un solo archivo grande puede consumir más tokens de los que valía la respuesta.

La alternativa de XERJ es un índice local. Apúntalo a una carpeta y autoindex olfatea los tipos de archivo, infiere datasets, descarta basura y construye un índice separado por dataset. El log de una ejecución real en el repositorio dice así: 593 datasets inferidos, 1.955 archivos basura o saltados en la fase A, luego la fase B indexando 25.329 archivos con ocho workers, terminando en 158,1 segundos con 83.103 registros vivos.

El código se parsea con tree-sitter, conservando símbolos y números de línea en vez de aplanarlo todo a texto. Por eso xerj def <symbol> puede devolver un archivo, una línea y una firma: un salto a la definición en todo el repositorio, que es lo que el agente necesitaba desde el principio.

El benchmark, leído con cuidado

El proyecto ejecutó ocho tareas en cuatro lenguajes, dieciséis pasadas por brazo, y midió el consumo real de tokens de claude -p en lugar de estimarlo. Tres configuraciones: solo memoria, guiado por grep y XERJ.

Solo memoria usó 260.916 tokens de salida, costó 11,18 $ y resolvió 11 de 16. Grep usó 26.477 tokens, costó 3,27 $ y resolvió las 16. XERJ usó 9.982 tokens, costó 1,58 $ y también resolvió las 16.

Es decir: unas 2,7 veces menos tokens de salida que grep, 26 veces menos que confiar en la memoria del modelo, sin cambio en la tasa de acierto. El mejor caso individual —una tarea Java— ahorró 278 veces. Los usuarios reportan aproximadamente 5x de punta a punta.

Ahora la salvedad que hace que este artículo valga la pena. El titular del repositorio afirma “40x menos tokens que grep”. El experimento controlado del cuerpo dice 2,7x. No son la misma afirmación, y la brecha entre ambas es exactamente el patrón que vuelve poco fiable el marketing basado en benchmarks. En su favor, el propio README dice que se prefiera la cifra del cuerpo. Un titular que exagera y una nota al pie que lo corrige es una forma extraña de publicar, pero al menos la corrección está.

La restricción que nadie menciona en los posts de lanzamiento

Aquí está la frase que casi todos los proyectos de “búsqueda para agentes” omiten: el beneficio depende de si el modelo ya conoce el código.

En código privado, interno, de nicho o posterior al corte de entrenamiento, la recuperación ahorra mucho, porque el modelo realmente no puede adivinarlo. En bibliotecas de código abierto populares que el modelo ha visto diez mil veces, el índice es neutro o directamente dañino: gastas tokens recuperando lo que el modelo ya sabía.

Esa única restricción cambia cómo deberías desplegarlo. No es una mejora universal. Es un remedio para un modo de fallo concreto: agentes trabajando sobre código sobre el que nadie ha escrito una entrada de blog.

El flag --insecure es una frontera de confianza real

Ejecutar xerj --insecure desactiva TLS y la autenticación de la API. Cualquiera que alcance el puerto es, en la práctica, superusuario: leer, escribir y borrar todos los índices, incluido todo lo que hay bajo /_memory. Eso está bien en el portátil de un solo desarrollador y es catastrófico en cualquier cosa compartida.

Los valores por defecto son mejores que el flag. Un nodo nuevo se enlaza a 127.0.0.1, y un enlace en texto plano a una dirección que no sea loopback se niega a arrancar salvo que establezcas explícitamente server.allow_insecure_network_bind = true. El proyecto también registra que correr inseguro sobre 0.0.0.0 fue una vulnerabilidad real —clientes de la LAN podían escribir sin autorización— y que ya está corregida. Ponerle nombre a tu propia vulnerabilidad pasada es una buena costumbre.

La divulgación que debería ser plantilla

En un commit de instrumentación, el mantenedor escribió que las estrellas y forks del repositorio fueron amplificados unas trece veces por una cohorte sintética, que los datos reales de instalación son escasos —unas 145 descargas de assets de release y unos 28 installs completados— y que Cloudflare RUM dejó de registrar en julio, así que el gráfico de tráfico cero del sitio es un artefacto.

Para un proyecto con una promesa de compatibilidad con Elasticsearch y 1.371 tests de conformidad pasando (cero fallos, tres omitidos), eso es algo notable de publicar. También dice algo del estado actual de las señales de código abierto: el número de estrellas es una superficie de marketing, y cualquiera que corra un bucle de crecimiento puede moverlo. Las únicas cifras que merecen confianza son las que un autor ofrece en contra de su propio interés.

Otras cosas que encontrarás

La instalación es un curl canalizado al shell, que verifica SHA256 y se niega a continuar si no encuentra una herramienta de checksum: una guarda inusualmente sensata para ese patrón. Las builds son musl estático con jemalloc, Linux primero, Windows por instalación manual. Hay un servidor MCP que expone trece herramientas, incluidas xerj_plan y xerj_map, y xerj init conecta Claude Code o Cursor con un solo comando. Se soporta kNN con cuantización scalar8. El despliegue multinodo viene con un chart de Helm y un archivo compose.

La versión es 1.0.0-rc.x, y la CLI todavía se mueve. El CLA está adaptado del de Apache, con una nota del mantenedor de que ningún abogado lo ha revisado y quedan dos campos de relleno. Muchos commits están escritos por agentes de código y etiquetados como tales, lo cual es transparente y también una razón para leer el código del que dependes.

Programar por referencia, el caso de uso que nadie mide

Enterrada en el README está la aplicación más interesante: apuntar el índice al proyecto de código abierto más cercano al problema que estás resolviendo y luego escribir tu propia versión con la referencia en contexto.

Así se hace buena parte de la ingeniería real: encontrar la biblioteca que ya lo resolvió, leerla y luego implementar algo más estrecho. Hacerlo mal significa pegar medio repositorio en un prompt. Hacerlo bien significa poder preguntar “dónde maneja este proyecto la contrapresión” y recibir un archivo, una línea y una firma de función.

También muestra los límites del benchmark anterior. Programar por referencia exige descargar e indexar el repositorio de otro, lo que cuesta tiempo, disco y red. El ahorro llega en la segunda y tercera consulta, no en la primera. Quien lo evalúe debería medir la sesión completa, no una tarea.

La promesa de compatibilidad con Elasticsearch

XERJ habla el protocolo de cable de Elasticsearch, y el proyecto reporta 1.371 tests de conformidad pasando, con cero fallos y tres omitidos. Si eso se sostiene, las herramientas ya escritas contra Elasticsearch pueden apuntarle con cambios mínimos, y los equipos que llevan años pagando un clúster para guardar unos millones de documentos tienen una salida.

La crítica a la licencia SSPL de Elasticsearch es justa: SSPL no es código abierto en el sentido de la OSI, y eso importa a las empresas que quieren lanzar un producto sobre un motor de búsqueda. Pero “compatible” es un espectro. La cobertura del Query DSL, las agregaciones y el comportamiento de los analizadores son donde aparecen las diferencias, y la suite de conformidad es la única forma de saber de qué lado de la línea estás.

¿Deberías usarlo?

Si tus agentes trabajan con código interno, repos privados grandes o logs y documentos que ningún modelo ha visto, el caso es decente: un índice local, Apache-2.0, compatible con ES, con conciencia de símbolos vía tree-sitter y un benchmark honesto. Si tu trabajo es sobre todo con bibliotecas públicas, probablemente encontrarás que grep y una buena configuración de ripgrep son igual de efectivos y hay mucho menos que mantener.

Y si te llevas una sola cosa de este proyecto, llévate el hábito de divulgar en vez del motor de búsqueda. Una herramienta que te dice que sus propias cifras están infladas merece más atención que una que te dice que es cuarenta veces mejor.