ctx has reached major stable version 1.0. It's an open-source local CLI for searching your coding agent history.
1.0 brings several big changes:
- switched from sqlite to Tantivy, resulting in ~16x performance improvement
- introduced "lineage", so the CLI can understand how to trace deep subagents and forked sessions to where they came from
- introduced "ctx blame", which is like git blame but for agent sessions.
The performance changes are really significant: if you have a lot of agent history (I sure do) then a previously 40 minute ingestion now takes 2.5 minutes. And new activity is so cheap that it can finally run as a lite background process instead of on-demand.
Interestingly, I got the inspiration to try "source-backed indexing" here on HN from @malandin (of SereneDB) on our last post. So yes, HN is working as intended. (See: https://news.ycombinator.com/item?id=48763462#48778744 )
And I'm very excited about "ctx blame" which is what we decided to pursue for our paid add-on rather than a cloud service (it's fully local like ctx search). It works like git blame: you start with a line, commit, file, or PR and then it returns the exact agent session event and transcript that produced it.
It's really useful for digging up the previous context for why the code was implemented the way it was. Which tests were run at the time, what user conversation was had at the time, etc.
Happy to answer any questions or implement changes based on your feedback!
I made something similar using Tauri but there were visual inconsistencies between platforms thanks to webkit. At the time I remember thinking I wish I had used electron to buy cross platform parity.
And I experimented with gpui from zed, that was even harder to work with.
Of course they could chase performance, but ultimately time to market is the #1 factor right now, and coding agents still aren't good enough to just immediately realize an entire GPUI app from scratch with nothing more than a figma design. Still requires a ton of oversight.
It's all in the skill / instruction that you give to the agent. The agent should treat the history as anthropology - a record of what happened, not necessarily the ground truth.
Creating ground truth is an orthogonal problem - I try to work hard to put it into specs and docs and regularly update those.
Searching history is closer to "super git blame" or like looking through logs. We should expect a lot of stuff went wrong in there.
We considered this, but the main thing you gain from this tradeoff is some disk space and cleaner retention semantics from not having to duplicate all of the searchable text.
But you still have to do the parsing and ingestion work to build the index in the first place, so CPU time does not go away.
And you still have to store the indexes and enough metadata to map results back to the raw session files, which bounds the benefit of not duplicating the data.
The main downside is flexibility (you would lose the ability to do arbitrary SQL queries, semantic search on top of structured corpus, etc)
But I would love to see if I can be proven wrong on this!
We've been working on remote search indexing in our project and it works pretty good. since we are building a Postgres-compatible database, everything is pure SQL. I'd say we could join forces if you're up for it.
semantic search has been pretty good, it usually finds what it's looking for!
a couple of times I was certain that there was a session that contained some word but in reality it was in my personal claude.ai web account, so needed to add the import functionality there.
my favorite piece is the `corrections` command which surfaces all my frustrations/corrections in the last week for example... and I can then figure out if missing context would improve those scenarios going forward
Nice, yea I typically spend about 1/3 of my sessions on finding ways to improve the agents' SDLC. Lots of random audits and things.
And yea on the import thing, there are quite a few instances when session records can live on other machines, like cloud agents, dev boxes, etc.
Do you have any interest in sharing some transcripts with team members? I'm trying to figure out the shape of this solution because often times people I work with want to see what I did or fork one of my sessions, but I also don't necessarily just want unlimited dumping because I'm sure I have personal details in there too.
We have a private beta for a secure cloud version of the service, although its more geared towards teams/enterprise who want to share their work internally, rather than donating to open model developers. But interesting idea! I'm not very knowledgeable about crypto things, but I believe this is what people have considered "microtransactions" to be useful for.
This is true, maybe we could reword it to be less absolute.
The bigger point is that when they do go spelunking in the old session logs, it is extremely token inefficient, and you can often fill up an entire context window and force a compaction just by trying to put together a transcript or summary.
The goal here is less of doing something previously impossible, but doing it in a way that makes it so efficient and cheap that you can have agents do it very often, like before they start on every single task.
