Threadlens - ferramenta open source para buscar, analisar, fazer backup e organizar sessões locais de IA

Olá. Estou criando uma ferramenta open source chamada ThreadLens para resolver alguns incômodos que eu tinha ao usar várias ferramentas de IA ao mesmo tempo.

O ponto de partida foi organizar threads do Codex. Na UI só dava para arquivar, e para realmente apagar era preciso encontrar os arquivos locais manualmente. Depois vi que no openai/codex também havia um pedido parecido, de que "além de arquivar, é preciso poder apagar", então pensei que não era um incômodo só meu.

Depois, alternando entre várias IAs como Codex e Claude, surgiu outro problema. Eu frequentemente me pegava pensando "onde está aquela conversa que tive com a IA naquela vez?", tendo que vasculhar as pastas ocultas de cada ferramenta ou procurar transcripts com rg. E, como os logs de sessões locais continuavam se acumulando, também era trabalhoso cuidar manualmente da limpeza de espaço e do backup externo toda vez.

Quero reunir esse fluxo em um só lugar.

• Buscar em um só lugar as sessões locais de Codex, Claude, Gemini e Copilot
• Ver em uma única tela, por sessão, transcript, caminho de trabalho, tamanho do arquivo e horário de modificação
• Organizar após backup em lote e análise de impacto (a análise de impacto ainda é focada no Codex)
• Ver, por provider, onde e como a estrutura das sessões é lida por meio de routing/parser

É Local-First, sem conta nem upload para a nuvem. A estrutura lê os arquivos de sessão que já estão no meu computador e os exibe em API local, web UI, app de desktop e TUI.

Enquanto desenvolvia, senti que ter só um "botão de apagar" não era muito interessante. Principalmente no caso das threads do Codex, eu queria primeiro ver "será que posso apagar isso sem problema?". Então, na análise de impacto, trouxe sinais que podem ser usados como referência a partir da documentação da OpenAI/Claude e de issues reais, e mantive os pesos das pontuações conservadores dentro do produto.

Além de contexto longo, histórico com uso intenso de ferramentas, presença ou ausência de cwd e sessões antigas, também verifico se outras sessões referenciam diretamente essa thread em relações de pai/filho/fork ou se ela é mencionada nos logs. Assim, antes de apagar, dá para confirmar primeiro se é candidata a órfã, se está conectada a outras sessões e se parece seguro removê-la.

No momento, já disponibilizei macOS DMG, Windows exe e Linux AppImage, e também é possível executar a partir do código-fonte.
As builds de desktop ainda são unsigned, então o sistema operacional pode exibir avisos. A lógica de exploração por provider e a UX geral ainda estão sendo aprimoradas.

Feedback, contribuições e apoio são todos muito bem-vindos!! Se você usa outros formatos de sessão local de IA, me avise também. Isso deve ajudar a definir prioridades :)

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

[minhoryang]

É excelente! Era exatamente isso que eu precisava agora!!

[hanityx]

Até nos comentários... eu é que agradeço ainda mais! A interface também suporta português/coreano; é multilíngue com base em i18n. Daqui para frente, vou continuar lapidando isso com ainda mais dedicação!

[minhoryang]

@hanityx será que você poderia criar um guia para adicionar outros providers? (quero tentar colocar opencode ou outros também) As informações em docs/PROVIDER_SUPPORT.md foram levantadas por você manualmente? Também é preciso adicionar diretamente em apps/api-ts/src/domains/providers/matrix.ts? Acho que, se a interface fosse separada, ficaria um pouco mais fácil.

[hanityx]

A estrutura não é do tipo em que basta adicionar matrix.ts para conectar um novo provider; também é preciso ajustar em conjunto a lista de providers, a segurança de caminhos, a localização de sessões, o tratamento de transcript/search, actions, health, testes e geração de documentação.

docs/PROVIDER_SUPPORT.md não é um documento editado manualmente; ele é gerado automaticamente com base no provider registry dos shared contracts e no script de geração de documentação. O objetivo é evitar divergências entre o escopo de suporte por provider e a lógica real.

Por coincidência, eu já estava olhando um trabalho de separação/organização, porque a lógica de search/transcript do lado da API cresceu bastante. Desta vez, também vou organizar os adapters internos e o guia para facilitar a adição de providers, e no OpenCode vou começar avaliando um suporte seguro primeiro em modo read-only. Se você deixar em uma issue o caminho das sessões locais, exemplos e informações relacionadas, continuo analisando por aí!

[minhoryang]

Se você apenas separar, eu vou tentar publicar o opencode seguindo o CONTRIBUTING.md e o guia.