Semble - búsqueda de código para agentes que usa 98% menos tokens que grep

• Semble es una biblioteca de búsqueda de código creada para que los agentes encuentren al instante solo los fragmentos de código necesarios mediante consultas en lenguaje natural o código
• En comparación con grep+read, usa aproximadamente 98% menos tokens y devuelve solo los chunks relevantes en lugar de leer archivos completos
• Indexa un repositorio promedio en aproximadamente 250 ms y responde consultas en alrededor de 1.5 ms; funciona en CPU sin claves de API, GPU ni servicios externos
• El benchmark se ejecutó con cerca de 1,250 consultas sobre 63 repositorios en 19 lenguajes, y se presenta que Semble alcanza el 99% de la calidad Hybrid de CodeRankEmbed mientras indexa 218 veces más rápido
• En el benchmark de eficiencia de tokens, Semble usó en promedio 98% menos tokens y alcanzó 94% de recall con solo 2k tokens, mientras que grep+read llegó a 85% de recall con una ventana de contexto de 100k
• Puede usarse como servidor MCP en Claude Code, Cursor, Codex, OpenCode y agentes compatibles con MCP; los repositorios se clonan e indexan cuando es necesario, y el índice se guarda en caché durante la sesión
• También soporta uso basado en Bash, por lo que se pueden incluir flujos de trabajo con semble search y semble find-related en AGENTS.md o CLAUDE.md; este método es necesario para los subagentes de Claude Code y Codex CLI
• El CLI puede recibir tanto rutas locales como URLs Git https://, y si se omite path, usa el directorio actual por defecto
• También puede usarse como biblioteca de Python, por lo que es posible integrar la búsqueda en herramientas personalizadas con SembleIndex.from_path, SembleIndex.from_git, search y find_related
• Internamente, divide los archivos en chunks conscientes del código con tree-sitter, combina embeddings potion-code-16M de Model2Vec con BM25, y luego fusiona las puntuaciones mediante Reciprocal Rank Fusion
• El ranking usa ponderación léxica para consultas simbólicas, impulso a chunks de definición, coincidencia por raíz de identificadores, relevancia dentro del mismo archivo y ajustes a la baja para tests, legacy, ejemplos y .d.ts
• Como usa un modelo de embeddings estático, no hay transformer forward pass al momento de consultar, lo que permite búsquedas en milisegundos sobre CPU
• semble savings estima los tokens ahorrados comparando, en cada búsqueda, el total de caracteres de los archivos únicos a los que pertenecen los chunks devueltos con los caracteres de los snippets devueltos, y guarda las estadísticas en ~/.semble/savings.jsonl
• El paquete puede instalarse desde PyPI como semble, y para usar MCP se emplea la forma uvx --from "semble[mcp]" semble
• La licencia es MIT

[GN⁺]

Comentarios en Hacker News

• Cuando usas herramientas así, ves que la propia IA también se vuelve tonta, igual que los programadores pueden volverse tontos cuando dependen demasiado de herramientas de IA
  Las IA agenticas ya son lo bastante listas como para encontrar rutas bastante optimizadas para explorar o buscar en código, pero cuando les pones una herramienta así tienden a actuar de forma demasiado agresiva porque los resultados de búsqueda casi siempre solo les dan punteros, no todos los detalles completos
  Probé de forma sencilla con Pi, haciéndole rastrear la ruta completa de recolección y búsqueda en un proyecto de cierta complejidad, y codebase-memory-mcp dio 85k/4.4k tokens de entrada/salida, mi configuración normal 67k/3.2k, y sin ninguna herramienta 80k/3.2k
  La calidad del resultado y la cantidad de información fueron las mismas, y esta herramienta no solo no ayudó mucho, sino que incluso empeoró un poco las cosas
  Mi configuración habitual es poner una sola línea en AGENTS.md y CLAUDE.md: “lee primero PROJECT.md”
  En PROJECT.md solo dejo una descripción de 2 o 3 líneas del proyecto, los archivos relevantes con una línea de explicación, advertencias, y una nota para el LLM que dice: “si vale la pena cambiar esto, actualiza este archivo. El propósito de este archivo es dar una idea general del proyecto y, si hace falta, explorar más a partir de ahí”

  • Eso de que “las IA agenticas ya son lo bastante listas como para encontrar rutas altamente optimizadas para explorar o buscar código” no coincide con mi experiencia
    En el trabajo antes usábamos Augment Code, que tenía algo tipo MCP llamado Context Engine que respondía consultas en lenguaje natural sobre código indexado previamente
    Después cambiamos a Claude Code, y curiosamente, aunque tiene una herramienta para leer rangos, intenta leer archivos con sed basándose en los rangos de líneas que recuerda
    No sé si eso de verdad cuenta como una ruta altamente optimizada
  • codebase-memory-mcp y semble no son exactamente lo mismo, pero es una comparación interesante, así que la voy a poner en la lista de cosas por revisar y, si puedo, la agrego a los benchmarks
    Si tienes oportunidad de hacer la misma comparación con semble, sería feedback realmente útil. Este tipo de escenarios “reales” son difíciles de benchmarkear o reproducir

• Interesante. Yo también estoy trabajando en este espacio, pero fui por otro camino
  En vez de crear un índice, hice un grep más inteligente para codebases y texto general, con ranking y reconocimiento de estructura de código, y como la mayor parte del tiempo la pasé resolviendo problemas de rendimiento, corre muy rápido
  Voy a agregarlo como comparación con https://github.com/boyter/cs para ver qué prefieren los LLM en el tipo de preguntas que yo hago
  También ofrece MCP, pero no crea un índice de búsqueda. Como usa variaciones semánticas de código en vez de BM25 básico, tengo curiosidad por ver cómo queda el ranking
  Esta herramienta parece encajar mejor para consultas como “¿cómo funciona la autenticación?”, mientras que cs hace authenticate --only-declarations y luego pondera los resultados según el contenido del archivo, o sea si la coincidencia está en código o en comentarios, y según la complejidad general del archivo
  Ya le di estrella y lo voy a seguir

• Sé que esta herramienta es para IA, pero me interesa más usarla yo mismo al explorar un codebase nuevo o uno propio
  Parece útil cuando quieres ver el panorama general de dónde habría que tocar algo para refactorizarlo
  Los LSP ya hacen algo de eso, pero esta herramienta da la impresión de poder ir un paso más allá

• Hice algunas evaluaciones con Pi y GPT 5.5
  Probé RTK activado / headroom activado / ambos activados / ambos desactivados, todos con las instrucciones estándar del sistema de Pi, y sin AGENTS.md
  No recuerdo exactamente qué pruebas eran, pero eran algunas evaluaciones estándar de agentes que usa la gente, una en Python y otra en TypeScript, que son los lenguajes que uso
  No diría que fueron pruebas exhaustivas ni especialmente buenas. Tal vez si hubiera pasado un día ajustando AGENTS.md y las instrucciones del system prompt y de herramientas de Pi, habría obtenido mejores resultados. Una cosa que aprendí al correr evaluaciones es que diferencias sutiles como esa pueden cambiar muchísimo el resultado
  Pero con ambos desactivados salió claramente mejor, lo suficiente como para detener la prueba de inmediato después de 3 rondas
  El problema fue que, aunque a veces bajaba el uso de contexto, aumentaba el número de turnos hasta completar la tarea, así que el costo total de la conversación terminaba siendo mayor
  Esto me hizo muy consciente de que muchísima gente comparte herramientas así, pero o no hay evaluaciones en absoluto, o son sospechosamente difíciles de reproducir, o como en este caso hacen muchos benchmarks pero miden lo equivocado
  Sí, esta herramienta usa menos tokens que grep, y el benchmark lo demuestra, pero eso no es lo importante. Lo importante es si el agente puede hacer trabajo de la misma calidad más rápido y más barato usando esta herramienta

  • Ahora mismo en toda la industria de IA hay una falta de pruebas
    No es un problema exclusivo de esta herramienta, sino de todo lo que intenta acoplar IA a codebases o flujos de desarrollo
    Incluso antes de la IA no había pruebas para medir “qué tan rápido y bien se desarrolló esto”, y ahora tampoco se han añadido
  • En IA parece que pasa muy seguido eso de “pudimos hacerlo, así que no pensamos si debíamos hacerlo”

• Me gustaría ver benchmarks de agentes reales. Por ejemplo, quitar grep de Claude Code o Copilot CLI y poner esta herramienta en su lugar
  Revisé RTK y varias implementaciones de LSP, y los modelos están tan reforzados con grep que no confían en otros tipos de resultados y se la pasan reintentando o volviendo a leer
  Entonces todo el ahorro de tokens desaparece porque el modelo no confía en la salida de otras herramientas

  • Puse en el CLAUDE.md global (bajo ~/.Claude) que usara LSP en vez de grep, y desde entonces no he tenido ese problema
  • Codex CLI maneja RTK bastante bien. Al menos así fue con GPT 5.5 xhigh
    Eso sí, me molesta que cuando no soporta ciertos flags específicos del CLI de find, muestre un mensaje de error en vez de devolver toda la salida del comando
    Entonces el agente desperdicia tokens reintentando o, peor aún, se asusta por el prompt y ni siquiera intenta ejecutar el comando sin RTK
  • A nosotros también nos interesan esos benchmarks, y ya están en el roadmap junto con optimización de prompts y descripciones para que al modelo le resulte más fácil usarlo
    A nivel anecdótico, nosotros también usamos esta herramienta directamente y hasta ahora nos ha funcionado bastante bien
    Los modelos de Anthropic parecen invocarla y confiar en sus resultados
  • El ahorro de tokens es cada vez más importante, pero también importa si el agente confía en los resultados y deja de buscar
    No hay que medir solo la salida de búsqueda, sino el bucle completo del agente
  • Al menos Codex sí hace caso si le dices que grep suele ser demasiado lento y que use rg, pero si le agregas RTK termina usando grep a través de RTK y eso es medio irritante

• La idea me pareció buena y la estuve probando un poco
  Hice la prueba en el repositorio browsercode(https://github.com/browser-use/browsercode) y el prompt fue: “usa solo el CLI de semble y responde qué herramientas, aparte de las herramientas base de OpenCode, Browsercode pone a disposición del agente. Incluye el esquema exacto de entrada y salida de la herramienta, y resume brevemente qué hace y cómo funciona”
  A eso le pegué el fragmento de AGENTS.md de https://github.com/MinishLab/semble#bash-integration
  En la prueba sin usar Semble cambié la misma pregunta para que solo usara los CLI de rg y fd
  En ambos casos usé Pi y gpt-5.4 medium, y el resto de la configuración fue muy mínima. También verifiqué que de verdad en un caso usara solo rg y fd, y en el otro solo semble
  Sin Semble usó 10.9% del contexto del modelo y $0.144 de créditos de API, y usando Semble 9.8% y $0.172
  Las respuestas finales fueron casi iguales, así que estuvieron muy parejas
  También hice otra prueba en el repositorio de OpenCode, y la pregunta fue: “rastrea la ruta desde el punto donde la variable de entorno OPENCODE_EXPERIMENTAL_EXA se establece en 1 hasta el efecto que aparece en el system prompt o en las herramientas disponibles para el agente de OpenCode”
  Incluí las mismas instrucciones y documentación que arriba
  La versión sin Semble fue un poco más detallada y también cubrió si la ruta de llamadas a herramientas invocaba Exa dependiendo de si Exa o Parallel estaban habilitados como proveedores de búsqueda web, pero ambas versiones respondieron correctamente la pregunta real
  La versión con Semble usó 14.7% de contexto / $0.282 de costo de API, y la versión sin Semble 19.0% / $0.352
  En eficiencia de contexto, claramente ganó Semble, pero vale la pena notar que la versión sin Semble terminó aproximadamente el doble de rápido
  Claro, solo fue una prueba informal mía, así que los resultados pueden variar

• Cuando dicen que “usa 98% menos tokens que grep”, ¿se supone que debo creer que grep es tan derrochador que el modelo está leyendo 98% de basura inútil cada vez?
  Me parece que esa afirmación no es representativa, o que al descartar la mayor parte del contexto para dárselo al modelo se está perdiendo otra cosa importante

  • El 98% no es solo contra la salida de grep, sino contra el bucle grep+read
    Cuando el agente se enfrenta a un codebase desconocido, normalmente primero hace cat file o lee archivos completos. Al menos esa ha sido mi experiencia
    Si estás logrando que el agente haga de forma consistente solo grep -C N y se detenga ahí, de verdad me interesa tu configuración. Yo pensaría que la calidad de esos resultados es demasiado baja para que sirvan como contexto útil
  • Tuve el problema de que Claude leía cientos de kilobytes de salida por coincidencias dentro de node_modules
    Como ripgrep ayuda, tiene sentido agregar una línea en algún archivo de memoria diciendo que lo use
  • grep imprime todas las líneas coincidentes
    Cuando un LLM hace ciertas búsquedas puede haber mucho ruido, y tal vez necesite hacerlas así porque no puede buscar algo más específico
    La búsqueda orientada a objetivos puede reducir la cantidad de tokens
    Pero esta comparación parece más bien entre recibir solo las partes necesarias y leer el codebase completo

• Como feedback, codex-cli se cuelga cuando invoca esto vía MCP
  El proceso de semble también queda como zombi y se queda colgado para siempre. No sé por qué, y en los logs no aparece nada
  Si lo llamo por CLI mediante una skill, GPT 5.5 intenta lanzar muchísimas búsquedas, como si estuviera muy acostumbrado a ripgrep
  No sé qué tan efectivo sea eso, y con la documentación corta de GitHub y las instrucciones del agente no queda claro qué es lo óptimo
  Por último, al instalarlo para bash también me salieron varias veces errores relacionados con conexiones externas a GitHub. No sé si eso tenga relación con el cuelgue
  Además, mi agente después intenta seguir usando ripgrep, así que parece redundante. Actúa como si hubiera un problema de confianza
  Tener una explicación más detallada de la skill del agente podría ayudar a guiarlo hacia el uso correcto

  • Gracias por el feedback tan detallado
    Si puedes abrir un issue con los detalles de tu configuración por el bug, sería genial. Definitivamente queremos investigarlo y corregirlo
    Lo de lanzar múltiples consultas también es muy buen feedback, y vamos a actualizar prompts e instrucciones para evitar que eso pase, además de agregar pruebas relacionadas
    Los errores de conexión externa durante la instalación probablemente se deben a que uv estaba trayendo dependencias desde PyPI, y no deberían ser la causa del cuelgue

• Parece una buena idea
  Un problema relacionado es que, en codebases pequeños, Claude a veces podría simplemente meter todo el codebase en contexto de una sola vez y procesarlo con muy pocos tokens, pero aun así pasa mucho tiempo buscando cosas
  Un workaround decente es poner todo el directorio en el contexto con un hook de inicio
  Así Claude se salta esa fase de “andar tanteando en la oscuridad” en cada tarea
  También recuerdo haber visto un gran proyecto que, en repositorios más grandes, le daba al modelo una vista general con stubs, pero ya no recuerdo el nombre

  • ¿Tal vez aider? https://aider.chat/2023/10/22/repomap.html
  • Es verdad. Los agentes no saben bien qué están viendo, por ejemplo cuántos archivos hay o qué tamaño tienen
    Aun así, si el codebase es pequeño, también es más fácil encontrar lo que buscas, así que la búsqueda todavía puede ayudar a reducir costos

• El problema mayor con la mayoría de estas soluciones es que casi todas las IA, gracias a su entrenamiento, ya usan muy bien grep y la búsqueda
  Si le das una herramienta nueva a la IA, esa herramienta le quita parte de su capacidad cognitiva
  Los humanos normalmente “aprenderían” a usar estas herramientas, pero el aprendizaje del LLM está congelado y ya tiene una habilidad muy profunda con herramientas existentes como grep
  Por ejemplo, la IA ya sabe explorar codebases con comandos de Linux como tree, y eso también está bastante bien aprendido
  Otro problema es que es fácil crear ejemplos que muestren la utilidad de estas herramientas, pero mucho más difícil demostrar de verdad que, en ejecuciones largas, la utilidad compensa el déficit cognitivo que provocan
  Mi intuición inicial es que, en ejecuciones largas, la inteligencia desplegable neta va a salir perdiendo, y que el agente terminará funcionando peor que usando herramientas existentes
  Probar lo contrario no es algo trivial, pero quizá sí sea un reto que valga la pena intentar