ThreadLens - herramienta de código abierto para buscar, analizar, respaldar y organizar sesiones locales de IA

Hola. Mientras usaba varias herramientas de IA al mismo tiempo, empecé a crear una herramienta de código abierto llamada ThreadLens para resolver varias incomodidades que tenía.

Todo empezó al intentar organizar hilos de Codex. En la UI solo se podían archivar, y si realmente quería borrarlos, tenía que encontrar los archivos locales manualmente. Después vi que en openai/codex también había una solicitud similar diciendo que “hace falta delete además de archive”, así que pensé que no era una molestia que solo me pasara a mí.

Luego, al ir alternando entre varias IAs como Codex y Claude, apareció otro problema. Muy seguido me encontraba pensando “¿dónde está esa conversación que tuve con la IA en ese momento?” y terminaba revisando las carpetas ocultas de cada herramienta o buscando transcripts con rg. Además, los logs de sesiones locales seguían acumulándose, así que era engorroso encargarse manualmente cada vez de liberar espacio y hacer respaldos externos.

La idea es manejar todo ese flujo en un solo lugar.

• Buscar en un solo lugar las sesiones locales de Codex, Claude, Gemini y Copilot
• Ver en una sola pantalla el transcript, la ruta de trabajo, el tamaño del archivo y la hora de modificación de cada sesión
• Organizar tras pasar por respaldo por lotes y análisis de impacto (por ahora, el análisis de impacto está centrado en Codex)
• Ver mediante routing/parser dónde y cómo se lee la estructura de sesiones de cada provider

Es Local-First: no hay cuentas ni subidas a la nube. La estructura consiste en leer los archivos de sesión que ya están en tu computadora y mostrarlos a través de una API local, una web UI, una app de escritorio y una TUI.

Mientras lo desarrollaba, sentí que tener solo un “botón de borrar” no era suficiente. En especial con los hilos de Codex, antes de borrarlos quería poder ver primero si “de verdad está bien borrar esto”. Por eso, para el análisis de impacto tomo señales de referencia de la documentación de OpenAI/Claude y de issues reales, y los pesos de puntuación dentro del producto están definidos de forma conservadora.

No solo revisa contextos largos, historiales con mucho uso de herramientas, presencia o ausencia de cwd y sesiones antiguas, sino también si otras sesiones hacen referencia directa a ese hilo en relaciones de padre/hijo/fork o si lo mencionan dentro de los logs. Así, antes de borrar algo, permite verificar primero si podría quedar huérfano, si está conectado con otras sesiones y si parece seguro eliminarlo.

Por ahora ya publiqué macOS DMG, Windows exe y Linux AppImage, y también se puede ejecutar desde el código fuente.
Las builds de escritorio todavía están unsigned, así que es posible que el sistema operativo muestre advertencias. La lógica de exploración por provider y la UX general siguen en mejora continua.

¡¡Se agradecen tanto el feedback como el apoyo con contribuciones!! Si usas otros formatos de sesiones locales de IA, también cuéntamelo. Creo que eso ayudaría a definir prioridades :)

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

[minhoryang]

¡Está buenísimo! ¡Era justo lo que necesitaba ahora mismo!

[hanityx]

Hasta los comentarios... ¡yo soy quien está más agradecido! También funciona en coreano en la UI; es multilingüe basado en i18n. ¡A partir de ahora seguiré puliéndolo con más ganas!

[minhoryang]

@hanityx ¿podrías crear una guía para agregar otros providers? (quiero probar agregando opencode u otros). ¿La información de docs/PROVIDER_SUPPORT.md la recopilaste directamente tú? ¿Hay que agregarlo manualmente en apps/api-ts/src/domains/providers/matrix.ts? Creo que sería un poco más cómodo si se separara la interfaz.

[hanityx]

La estructura no es simplemente agregar matrix.ts para conectar un proveedor nuevo; también hay que ajustar en conjunto la lista de proveedores, la seguridad de rutas, la detección de sesiones, el procesamiento de transcript/search, actions, health, las pruebas y la generación de documentación.

docs/PROVIDER_SUPPORT.md no es un documento que se edite manualmente, sino que se genera automáticamente con base en el provider registry de los shared contracts y en el script de generación de documentación. El objetivo es evitar que el alcance de soporte por proveedor se desalineé con la lógica real.

De hecho, como la lógica de search/transcript del lado del API ya creció bastante, estaba revisando un trabajo de separación/ordenamiento; esta vez también voy a organizar el adapter interno y la guía para que sea más fácil agregar proveedores, y revisaré primero si OpenCode puede tener soporte seguro al menos en modo read-only. Si dejan la ruta de las sesiones locales, ejemplos e información relacionada en un issue, le seguiré dando continuidad.

[minhoryang]

Si solo lo separan, yo intentaré subir opencode siguiendo CONTRIBUTING.md y la guía.