Threadlens - un outil open source pour rechercher, analyser, sauvegarder et organiser les sessions d’IA locales

Bonjour. En utilisant plusieurs outils d’IA en parallèle, je me suis dit qu’il fallait résoudre certains points pénibles, et je développe donc un outil open source appelé ThreadLens.

Le point de départ a été le rangement des threads Codex. Dans l’UI, on ne peut que les archiver, et pour les supprimer réellement, il fallait aller chercher directement les fichiers locaux. Plus tard, j’ai vu qu’une demande similaire avait aussi été publiée dans openai/codex, du type « il faut une option delete, pas seulement archive », donc je me suis dit que je n’étais sans doute pas le seul à rencontrer cette gêne.

Ensuite, à force d’alterner entre plusieurs IA comme Codex et Claude, un autre problème est apparu. Je me retrouvais souvent à me demander « où était donc cette conversation avec l’IA ? », à fouiller les dossiers cachés de chaque outil ou à chercher les transcripts avec rg. En plus, les logs de sessions locales s’accumulent en permanence, si bien que gérer l’espace disque et faire des sauvegardes externes à chaque fois devenait fastidieux.

L’objectif est de gérer tout ce flux au même endroit.

• rechercher au même endroit les sessions locales de Codex, Claude, Gemini, Copilot
• afficher sur un seul écran, pour chaque session, le transcript, le chemin de travail, la taille des fichiers et l’horodatage de modification
• faire du backup groupé et de l’analyse d’impact avant le nettoyage (pour l’instant, l’analyse d’impact est surtout centrée sur Codex)
• vérifier, via le routing/parser, où et comment la structure des sessions est lue selon chaque provider

Approche local-first : il n’y a ni compte ni envoi vers le cloud. Le principe consiste à lire les fichiers de session déjà présents sur la machine, puis à les afficher via une API locale, une UI web, une application desktop et une TUI.

En le développant, je me suis dit qu’un simple « bouton supprimer » ne suffisait pas. Pour les threads Codex en particulier, je voulais d’abord pouvoir répondre à la question : « est-ce vraiment sans risque de supprimer celui-ci ? ». J’ai donc construit l’analyse d’impact à partir de signaux observables dans la documentation OpenAI/Claude et dans de vrais issues, avec des pondérations volontairement conservatrices dans le produit.

Au-delà du contexte long, de l’historique riche en outils, de la présence ou non du cwd, ou encore de l’ancienneté de la session, l’outil regarde aussi si d’autres sessions référencent directement ce thread comme parent/enfant/fork, ou s’il est mentionné dans les logs. Avant suppression, cela permet donc de vérifier si c’est un candidat orphelin, s’il est relié à d’autres sessions, et s’il semble acceptable de le supprimer.

Pour le moment, des builds macOS DMG, Windows exe et Linux AppImage sont disponibles, et il est aussi possible de l’exécuter depuis le code source.
Les builds desktop ne sont pas encore signés, donc le système d’exploitation peut afficher un avertissement. La logique d’exploration par provider ainsi que l’UX globale sont encore en cours d’amélioration.

Tous les retours et les contributions sont les bienvenus !! Si vous utilisez d’autres formats de sessions d’IA locales, n’hésitez pas à me le dire aussi. Cela m’aidera à définir les priorités :)

GitHub: https://github.com/hanityx/threadlens

[minhoryang]

C’est génial ! C’est exactement ce dont j’avais besoin en ce moment !!

[hanityx]

Même les commentaires… c’est moi qui vous remercie davantage ! L’interface prend aussi en charge le français ; c’est du multilingue basé sur l’i18n. Je vais continuer à peaufiner tout ça avec encore plus d’ardeur !

[minhoryang]

@hanityx Pourriez-vous éventuellement créer un guide expliquant comment ajouter d'autres providers ? (J’aimerais essayer d’ajouter opencode ou d’autres.) Les informations de docs/PROVIDER_SUPPORT.md, vous les avez compilées vous-même ? Faut-il les ajouter directement dans apps/api-ts/src/domains/providers/matrix.ts ? Je me dis que ce serait un peu plus pratique si l’interface était séparée.

[hanityx]

La structure ne consiste pas simplement à ajouter matrix.ts pour qu’un nouveau provider soit pris en charge ; il faut aussi aligner la liste des providers, la sécurité des chemins, la découverte des sessions, le traitement de transcript/search, les actions, l’état de santé, les tests et la génération de la documentation.

docs/PROVIDER_SUPPORT.md n’est pas un document à modifier manuellement : il est généré automatiquement à partir du registre des providers des contrats partagés et du script de génération de documentation. Le but est d’éviter tout décalage entre le périmètre de prise en charge par provider et la logique réellement implémentée.

De toute façon, la logique search/transcript côté API a déjà pas mal grossi, donc j’étais en train d’examiner un travail de séparation/réorganisation. Cette fois, je vais aussi remettre au propre l’adapter interne et le guide pour faciliter l’ajout de providers, et examiner si OpenCode peut au moins être pris en charge en lecture seule de façon sûre pour commencer. Si vous laissez dans l’issue le chemin de la session locale, des exemples et les informations associées, je poursuivrai l’examen à partir de là !

[minhoryang]

Si vous pouvez simplement le séparer, je mettrai en ligne opencode en suivant CONTRIBUTING.md et le guide.