Threadlens - alat open-source untuk mencari, menganalisis, mencadangkan, dan merapikan sesi AI lokal

Halo. Saat memakai beberapa alat AI sekaligus, ada beberapa hal yang terasa merepotkan, jadi saya membuat alat open-source bernama ThreadLens untuk mengatasinya.

Awalnya, pemicunya adalah merapikan thread Codex. Di UI hanya bisa archive, dan kalau benar-benar ingin menghapus, saya harus mencari file lokalnya secara manual. Belakangan saya melihat bahwa di openai/codex juga ada permintaan serupa, yaitu "butuh delete, bukan cuma archive", jadi saya merasa ini bukan ketidaknyamanan yang hanya saya alami sendiri.

Setelah itu, karena saya bergantian memakai beberapa AI seperti Codex dan Claude, muncul masalah lain. Saya jadi sering bertanya, "Percakapan saya dengan AI waktu itu ada di mana?" lalu harus membongkar folder tersembunyi tiap alat atau mencari transcript dengan rg. Log sesi lokal juga terus menumpuk, jadi merapikan kapasitas penyimpanan dan menyiapkan backup ke drive eksternal setiap kali terasa merepotkan jika harus dilakukan manual.

Saya ingin menangani alur seperti ini di satu tempat.

• Mencari sesi lokal Codex, Claude, Gemini, Copilot di satu tempat
• Melihat transcript, path kerja, ukuran file, waktu modifikasi tiap sesi di satu layar
• Merapikan sesi melalui backup batch dan analisis dampak (analisis dampak saat ini masih berfokus pada Codex)
• Memeriksa lewat routing/parser bagaimana struktur sesi tiap provider dibaca dari masing-masing lokasi

Bersifat Local-First, jadi tidak ada akun atau unggahan ke cloud. Strukturnya adalah membaca file sesi yang sudah ada di komputer saya, lalu menampilkannya melalui API lokal, UI web, aplikasi desktop, dan TUI.

Saat mengembangkannya, saya merasa kalau hanya ada "tombol hapus" saja rasanya kurang. Khususnya untuk thread Codex, sebelum menghapus saya ingin lebih dulu melihat, "Apakah benar aman kalau ini dihapus?" Karena itu, untuk analisis dampak saya mengambil sinyal yang bisa dijadikan referensi dari dokumentasi OpenAI/Claude dan issue yang benar-benar ada, lalu bobot skornya saya atur secara konservatif di dalam produk.

Bukan hanya context yang panjang, riwayat yang banyak memakai tool, ada atau tidaknya cwd, dan sesi yang sudah lama, tetapi juga apakah sesi lain secara langsung merujuk thread ini dalam relasi parent/child/fork, atau menyebutkannya di dalam log. Jadi sebelum menghapus, pengguna bisa lebih dulu memeriksa apakah ini kandidat orphan, apakah terhubung dengan sesi lain, dan apakah terlihat aman untuk dihapus.

Saat ini saya sudah menyediakan macOS DMG, Windows exe, Linux AppImage, dan bisa juga dijalankan dari source.
Build desktop-nya masih unsigned, jadi peringatan dari OS mungkin akan muncul. Logika penelusuran per provider dan UX secara keseluruhan masih terus saya perbaiki.

Masukan maupun dukungan kontribusi sangat saya sambut!! Kalau Anda memakai format sesi AI lokal lain, beri tahu juga ya. Itu akan membantu saya menentukan prioritas :)

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

[minhoryang]

Luar biasa! Ini benar-benar yang sedang saya butuhkan!!

[hanityx]

Sampai komentar juga.. justru saya yang lebih berterima kasih! Bahasa Korea juga didukung di UI, ini multibahasa berbasis i18n. Ke depannya saya akan terus mengasahnya lebih giat!

[minhoryang]

@hanityx apakah Anda bisa membuat panduan untuk menambahkan provider lain? (Saya ingin mencoba menambahkan opencode atau yang lain.) Apakah informasi di docs/PROVIDER_SUPPORT.md Anda kumpulkan sendiri secara manual? Apakah perlu menambahkannya langsung di apps/api-ts/src/domains/providers/matrix.ts? Sepertinya akan sedikit lebih mudah jika antarmukanya dipisahkan.

[hanityx]

Strukturnya bukan sekadar menambahkan matrix.ts lalu provider baru langsung terpasang; daftar provider, keamanan path, pencarian sesi, pemrosesan transcript/search, actions, health, pengujian, dan pembuatan dokumentasi juga harus disesuaikan bersama.

docs/PROVIDER_SUPPORT.md bukan dokumen yang diedit langsung, melainkan dibuat otomatis berdasarkan provider registry di shared contracts dan skrip pembuatan dokumentasi. Tujuannya agar cakupan dukungan per provider tidak melenceng dari logika yang benar-benar diimplementasikan.

Kebetulan logika search/transcript di sisi API juga sudah cukup besar sehingga saya memang sedang melihat pekerjaan pemisahan/perapian. Kali ini saya juga akan merapikan adapter internal beserta panduannya agar penambahan provider lebih mudah, dan untuk OpenCode saya akan mulai dengan meninjau dukungan read-only yang aman. Jika Anda meninggalkan path sesi lokal, sampel, dan informasi terkait dalam issue, saya akan lanjut menindaklanjutinya!

[minhoryang]

Kalau Anda memisahkannya saja, saya akan coba mengunggah opencode sesuai CONTRIBUTING.md dan panduannya.