Semble - recherche de code pour agents utilisant 98 % de tokens en moins que grep

• Semble est une bibliothèque de recherche de code conçue pour que les agents trouvent immédiatement uniquement les extraits de code nécessaires via des requêtes en langage naturel ou en code
• Par rapport à grep+read, elle utilise environ 98 % de tokens en moins et renvoie uniquement les chunks pertinents au lieu de lire des fichiers entiers
• Elle indexe un dépôt moyen en environ 250 ms et répond aux requêtes en environ 1,5 ms, tout en fonctionnant sur CPU sans clé API, GPU ni service externe
• Le benchmark a été réalisé sur 63 dépôts dans 19 langages avec environ 1 250 requêtes, et Semble y atteint 99 % de la qualité de CodeRankEmbed Hybrid tout en étant 218 fois plus rapide à l’indexation
• Dans le benchmark d’efficacité des tokens, Semble utilise en moyenne 98 % de tokens en moins et atteint 94 % de rappel avec seulement 2k tokens, tandis que grep+read atteint 85 % de rappel avec une fenêtre de contexte de 100k
• Un serveur MCP permet son utilisation avec Claude Code, Cursor, Codex, OpenCode et les agents compatibles MCP ; les dépôts sont clonés et indexés si nécessaire, et l’index est mis en cache pendant la session
• L’usage via Bash est aussi pris en charge, ce qui permet d’intégrer les workflows semble search et semble find-related dans AGENTS.md ou CLAUDE.md ; cette approche est nécessaire pour les sous-agents de Claude Code et du CLI Codex
• Le CLI accepte à la fois les chemins locaux et les URL Git en https://, et si path est omis, le répertoire courant est utilisé par défaut
• Il peut aussi être utilisé comme bibliothèque Python, avec SembleIndex.from_path, SembleIndex.from_git, search et find_related pour intégrer la recherche à des outils personnalisés
• En interne, tree-sitter découpe les fichiers en chunks conscients de la structure du code, puis combine les embeddings potion-code-16M de Model2Vec avec BM25, avant de fusionner les scores via Reciprocal Rank Fusion
• Le classement exploite une pondération lexicale pour les requêtes symboliques, un boost pour les chunks de définition, la correspondance de racines d’identifiants, la pertinence au sein d’un même fichier, ainsi qu’une pénalisation pour les tests, le legacy, les exemples et les fichiers .d.ts
• Comme il utilise un modèle d’embeddings statique, il n’y a pas de transformer forward pass au moment des requêtes, ce qui permet une recherche en quelques millisecondes sur CPU
• semble savings estime les tokens économisés à chaque recherche en comparant le nombre total de caractères des fichiers uniques auxquels appartiennent les chunks renvoyés avec le nombre de caractères des extraits renvoyés, et enregistre les statistiques dans ~/.semble/savings.jsonl
• Le package peut être installé depuis PyPI via semble, et pour l’usage MCP, la forme uvx --from "semble[mcp]" semble est utilisée
• La licence est MIT

[GN⁺]

Avis sur Hacker News

• En utilisant ce genre d’outil, j’ai l’impression de voir que l’IA elle-même devient plus stupide, un peu comme les développeurs quand ils deviennent trop dépendants des outils d’IA
  Les IA agentiques sont déjà assez intelligentes pour trouver des parcours plutôt optimisés dans l’exploration ou la recherche de code, mais avec ce type d’outil elles ont tendance à agir de façon trop agressive, parce que les résultats de recherche ne donnent presque toujours que des pointeurs plutôt que tous les détails
  J’ai fait un test simple avec Pi en lui demandant de suivre le parcours complet de collecte et de recherche sur un projet d’une complexité moyenne : avec codebase-memory-mcp, on était à 85k/4.4k tokens en entrée/sortie, avec ma config habituelle à 67k/3.2k, et sans aucun outil à 80k/3.2k
  La qualité du résultat et la quantité d’information étaient les mêmes, et cet outil, sans être catastrophique, a plutôt empiré les choses
  Ma configuration habituelle consiste juste à mettre une ligne dans AGENTS.md et CLAUDE.md disant « lis d’abord PROJECT.md »
  Dans PROJECT.md, je mets simplement une description du projet en 2 ou 3 lignes, les fichiers pertinents avec une phrase de description, les points d’attention, puis une consigne destinée au LLM : « si une modification mérite d’être documentée, mets ce fichier à jour. Le but de ce fichier est de donner une idée générale du projet, puis de permettre d’explorer plus loin si nécessaire »

  • L’idée que « les IA agentiques sont déjà assez intelligentes pour trouver des parcours hautement optimisés dans l’exploration ou la recherche de code » ne correspond pas à mon expérience
    Au travail, j’utilisais auparavant Augment Code, qui avait une sorte de Context Engine proche d’un MCP répondant à des requêtes en langage naturel sur du code préindexé
    Ensuite je suis passé à Claude Code, et de façon assez étrange il essaie de lire les fichiers avec sed en se basant sur des plages de lignes dont il se souvient, alors même qu’il dispose d’un outil de lecture par plage
    Je ne suis pas certain qu’on puisse appeler ça un parcours hautement optimisé
  • codebase-memory-mcp et semble ne sont pas exactement la même chose, mais c’est une comparaison intéressante, donc je vais l’ajouter à ma liste de vérifications et essayer de l’inclure dans les benchmarks si possible
    Si tu as l’occasion de faire la même comparaison avec semble, ce serait un retour vraiment utile. Ce genre de scénario « réel » est difficile à benchmarker ou à reproduire

• Intéressant. Je travaille aussi dans ce domaine, mais avec une approche différente
  Au lieu de construire un index, j’ai fait un grep plus intelligent avec classement et compréhension de la structure du code sur l’ensemble du codebase et du texte brut, et comme j’ai passé la majeure partie du temps à traiter les problèmes de performances, c’est très rapide
  Il faudrait l’ajouter à la comparaison avec https://github.com/boyter/cs pour voir ce que les LLM préfèrent sur le type de questions que je pose
  Ça fournit aussi un MCP, mais sans créer d’index de recherche. Comme ça utilise des variantes sémantiques du code plutôt que du BM25 classique, je suis curieux de voir comment le classement ressortirait
  Cet outil semble mieux adapté à des requêtes du type « comment fonctionne l’authentification ? », alors que cs fait un authenticate --only-declarations, puis pondère les résultats selon le contenu du fichier, c’est-à-dire si l’occurrence se trouve dans du code ou dans un commentaire, ainsi que selon la complexité globale du fichier
  J’ai mis une étoile et je vais suivre ça

• Je sais que cet outil est pensé pour l’IA, mais je suis encore plus intéressé par le fait de l’utiliser directement pour explorer un nouveau codebase ou mon propre codebase
  Ça semble utile quand on veut voir la vue d’ensemble de ce qu’il faut modifier pour refactorer quelque chose
  Les LSP font déjà ce genre de travail, mais cet outil a l’air de pouvoir aller un cran plus loin

• J’ai fait quelques évaluations avec Pi et GPT 5.5
  J’ai testé RTK activé / headroom activé / les deux activés / les deux désactivés, avec dans tous les cas les instructions système standard de Pi, et sans AGENTS.md
  J’ai oublié quels étaient exactement les tests, mais c’étaient quelques évaluations standard d’agents utilisées par les gens, avec un projet Python et un projet TypeScript, les langages que j’utilise
  Je ne prétends pas que c’était un test rigoureux ni même un bon test. J’aurais peut-être obtenu de meilleurs résultats après une journée à ajuster AGENTS.md ainsi que les prompts système et instructions d’outils de Pi. Une chose que j’ai apprise en lançant ces évaluations, c’est que ce genre de différence subtile peut beaucoup changer les résultats
  Mais le cas avec les deux désactivés était clairement meilleur, au point que ça a suffi pour arrêter les tests au bout de 3 tours
  Le problème, c’est que l’usage du contexte baissait parfois, mais que le nombre de tours jusqu’à la complétion augmentait, donc le coût total de la conversation finissait par être plus élevé
  Voir autant de gens partager ce genre d’outil me fait surtout prendre conscience qu’il n’y a souvent aucune évaluation, ou alors qu’elle est extrêmement difficile à reproduire, ou encore que, comme ici malgré de nombreux benchmarks, on mesure la mauvaise chose
  Oui, cet outil utilise moins de tokens que grep, et les benchmarks le prouvent, mais ce n’est pas ça qui compte. Ce qui compte, c’est de savoir si l’agent peut faire le même travail, à qualité égale, plus vite et à moindre coût grâce à cet outil

  • En ce moment, il y a un vrai manque de tests dans toute l’industrie de l’IA
    Ce n’est pas un problème propre à cet outil, c’est le problème de tout ce qui consiste à brancher de l’IA sur un codebase ou sur un flux de développement
    Même avant l’IA, on n’avait pas de tests pour mesurer « à quelle vitesse et avec quelle qualité ceci a été développé », et on n’en a toujours pas ajouté aujourd’hui
  • Dans l’IA, on risque très souvent de tomber dans le « on l’a fait parce qu’on pouvait, sans se demander s’il fallait le faire »

• J’aimerais voir de vrais benchmarks d’agents. Par exemple en retirant grep de Claude Code ou de Copilot CLI pour le remplacer par cet outil
  J’ai regardé RTK et plusieurs implémentations LSP, et les modèles sont tellement renforcés à utiliser grep qu’ils ne font pas confiance à d’autres formes de résultats et réessaient ou relisent sans cesse
  Du coup, comme le modèle ne fait pas confiance aux résultats de l’autre outil, tout le gain de tokens disparaît

  • J’ai mis dans mon CLAUDE.md global (sous ~/.Claude) qu’il fallait utiliser le LSP au lieu de grep, et depuis je n’ai plus ce problème
  • Codex CLI fait plutôt bien tourner RTK. En tout cas, c’était le cas avec GPT 5.5 xhigh
    En revanche, quand certaines options CLI précises de find ne sont pas prises en charge, il affiche un message d’erreur au lieu de renvoyer la sortie complète de la commande, ce qui m’agace
    L’agent gaspille alors des tokens à réessayer, ou pire, il est tellement intimidé par le prompt disant qu’il ne faut pas exécuter la commande sans RTK qu’il n’essaie même pas
  • Nous aussi, ce type de benchmark nous intéresse, et c’est sur la roadmap avec l’optimisation des prompts et des descriptions pour que les modèles l’utilisent plus facilement
    C’est anecdotique, mais nous utilisons évidemment nous-mêmes cet outil, et jusqu’ici il fonctionne plutôt bien
    Les modèles d’Anthropic semblent appeler cet outil et faire confiance à ses résultats
  • Les économies de tokens deviennent de plus en plus importantes, mais il est aussi important de voir si l’agent fait confiance au résultat et arrête de chercher
    Il ne faut pas mesurer seulement la sortie de recherche, mais la boucle complète de l’agent
  • Au moins, Codex écoute quand on lui dit d’utiliser rg parce que grep est souvent trop lent, mais si on ajoute RTK il se remet à utiliser grep via RTK, ce qui est un peu agaçant

• L’idée m’a paru bonne, donc j’ai un peu joué avec
  J’ai fait le test sur le dépôt browsercode (https://github.com/browser-use/browsercode), avec le prompt : « utilise uniquement la CLI semble, et dis quels outils Browsercode fournit à l’agent en plus des outils OpenCode de base. Donne le schéma exact des entrées/sorties de ces outils, et résume brièvement ce qu’ils font et comment ils fonctionnent »
  J’y ai collé l’extrait AGENTS.md de https://github.com/MinishLab/semble#bash-integration
  Pour le test sans Semble, j’ai reformulé la même question en demandant d’utiliser uniquement les CLI rg et fd
  Dans les deux cas, j’ai utilisé Pi et gpt-5.4 medium, avec une configuration très minimale. J’ai aussi vérifié que dans un cas il n’utilisait bien que rg et fd, et dans l’autre uniquement semble
  Sans Semble, le modèle a utilisé 10,9 % du contexte et 0,144 $ de crédits API, contre 9,8 % et 0,172 $ avec Semble
  Les réponses obtenues étaient aussi presque identiques, donc c’était très proche
  J’ai refait un test sur le dépôt OpenCode, avec cette fois la question : « suis le chemin depuis l’endroit où la variable d’environnement OPENCODE_EXPERIMENTAL_EXA est définie à 1 jusqu’au résultat visible dans le prompt système ou les outils fournis à l’agent OpenCode »
  J’ai inclus les mêmes consignes et la même documentation que plus haut
  La version sans Semble était un peu plus détaillée, et expliquait aussi si le chemin d’appel d’outil invoquait Exa selon que Exa ou Parallel était activé comme fournisseur de recherche web, mais les deux versions répondaient correctement à la vraie question
  La version Semble a utilisé 14,7 % de contexte pour un coût API de 0,282 $, contre 19,0 % et 0,352 $ pour la version sans Semble
  En efficacité de contexte, victoire nette pour Semble, mais il faut noter que la version sans Semble s’est terminée environ deux fois plus vite
  Bien sûr, je me suis juste amusé un peu avec, donc les résultats peuvent varier

• Quand on dit « 98 % de tokens en moins que grep », on est censé croire que grep gaspille à ce point et que le modèle lit à chaque fois 98 % de déchets inutiles ?
  J’ai l’impression que soit cette affirmation n’est pas représentative, soit on rate autre chose quand on jette la majeure partie du contexte destiné au modèle

  • Les 98 % ne se comparent pas seulement à la sortie de grep, mais à toute la boucle grep+lecture
    Quand un agent arrive sur un codebase inconnu, il commence souvent par faire cat file ou par lire le fichier entier. En tout cas, c’est mon expérience
    Si tu arrives à faire en sorte qu’un agent s’arrête de façon fiable après un simple grep -C N, je suis vraiment curieux de connaître ta configuration. À mon avis, la qualité du résultat est trop faible pour servir de contexte utile
  • J’ai eu un problème avec Claude qui lisait des centaines de kilo-octets de sortie à cause d’occurrences trouvées dans node_modules
ripgrep aide, donc ajouter une ligne dans un fichier mémoire pour lui dire de l’utiliser a du sens
  • grep affiche toutes les lignes correspondantes
    Quand un LLM fait une recherche, il peut y avoir beaucoup de bruit, et il peut être obligé de faire ce type de recherche faute de pouvoir être plus précis
    Une recherche orientée objectif peut réduire le nombre de tokens
    Cela dit, cette comparaison ressemble à une comparaison entre recevoir uniquement les parties nécessaires et lire l’ensemble du codebase

• Pour donner un retour, codex-cli se bloque quand il appelle ça via MCP
  Le processus semble reste aussi là comme un zombie et se bloque indéfiniment. Je ne sais pas pourquoi, et il n’y a rien non plus dans les logs
  Quand je l’appelle en mode invocation CLI via une skill, GPT 5.5 a tendance à lancer énormément de requêtes de recherche, comme s’il était très habitué à ripgrep
  Je ne sais pas à quel point c’est efficace, et avec la courte documentation sur GitHub et les seules instructions d’agent, il n’est pas clair de savoir ce qui est optimal
  Enfin, à l’installation pour bash, j’ai aussi eu plusieurs erreurs liées aux connexions externes à GitHub. Je ne sais pas si c’est lié au blocage
  En plus, mon agent essaie ensuite aussi d’utiliser ripgrep, ce qui semble redondant. Il se comporte comme s’il y avait un problème de confiance
  Une explication plus détaillée de la skill agent aiderait probablement à orienter l’agent vers le bon mode d’utilisation

  • Merci pour ce retour détaillé
    Pour le bug, ce serait bien d’ouvrir une issue avec les détails de configuration. C’est clairement un point qu’on veut investiguer et corriger
    Le problème des multiples requêtes est aussi un très bon retour, et on va essayer de mettre à jour les prompts et les instructions pour éviter que ça arrive, ainsi que d’ajouter des tests associés
    Les erreurs de connexions externes pendant l’installation viennent sans doute de uv qui récupère les dépendances depuis PyPI, et ne devraient pas être la cause du blocage

• Ça semble être une bonne idée
  Pour évoquer un problème connexe : sur les petits codebases, Claude peut parfois simplement mettre tout le codebase dans le contexte d’un coup et le traiter avec très peu de tokens, et malgré ça il passe beaucoup de temps à chercher quelque chose
  Une parade correcte consiste à injecter tout le répertoire dans le contexte via un hook de démarrage
  Claude évite alors cette phase où il « tâtonne dans le noir » à chaque tâche
  J’ai aussi vu un excellent projet qui donnait au modèle une vue d’ensemble avec des stubs sur les gros dépôts, mais j’ai oublié son nom

  • C’est peut-être aider ? https://aider.chat/2023/10/22/repomap.html
  • C’est vrai. Les agents ont du mal à savoir ce qu’ils sont en train de regarder, par exemple le nombre de fichiers ou la taille des fichiers
    Cela dit, sur un petit codebase, ce qu’on cherche est aussi plus facile à trouver, donc la recherche peut encore aider à réduire les coûts

• Le problème plus général de ces solutions, c’est que la plupart des IA savent déjà très bien utiliser grep et la recherche grâce à leur entraînement
  Si on donne un nouvel outil à une IA, cet outil lui retire une partie de ses capacités cognitives
  Les humains apprendraient sans doute à utiliser ce genre d’outil, mais l’apprentissage des LLM est figé, et ils ont déjà une maîtrise très profonde des outils existants comme grep
  Par exemple, l’IA sait déjà explorer un codebase avec des commandes Linux comme tree, et elle y a aussi été suffisamment entraînée
  Un autre problème est qu’il est facile de créer des exemples montrant l’utilité de ce genre d’outil, mais beaucoup plus difficile de démontrer réellement que, sur des exécutions longues, l’utilité compense les déficits cognitifs provoqués par l’outil
  Mon intuition première est que, sur des exécutions longues, l’intelligence déployable sera en perte nette, et que l’agent fera moins bien qu’avec les outils existants
  Prouver le contraire n’est pas un problème trivial, mais c’est peut-être un défi qui vaut la peine d’être relevé