Yes we are actually piloting this now! Could you shoot me an email if you want to chat further about it? luca@ctx.rs
65 karma · joined March 4, 2026
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!
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.
The idea is that even with native recall from Shelley, ctx results are more accurate, ergonomic, and token efficient
For example search can retrieve a specific message and then window for trailing and leading N messages, in just a few hundred tokens
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!
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.
How have you enjoyed the semantic search?
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.
At first I thought the main improvement would be that the search would be faster, but rg is already pretty freakin fast when the fs cache is warm.
What really ended up being the big efficiency improvement is the token efficiency. When you structure all of the transcripts in a SQL table, the agent can retrieve exactly what is needed (such as "print me the lite transcript, without the intermediate messages").
As of today, ctx is now open-source: https://github.com/ctxrs/ctx
ctx is an Agentic Development Environment (ADE), similar to the Codex desktop app, but it works with any agent harness.
I wrote more about why we are open sourcing it here: https://ctx.rs/blog/open-sourcing-ctx
A few things contributed to the decision to do this:
- We fell in love with Pi's extensibility model. In late 2025, we were forking Codex to add and change behaviors, but even small changes required deep surgery and rebuilding. Lately, we've been able to make those same changes with Pi, but it's so much easier. It feels closer to configuring a tool rather than rebuilding its internals. Everything seems to "just work" as an extension/plugin. We realized we wanted our ADE to work like that too. You should be able to have a sensible default desktop app, and then powerful customization options to change how it looks and works.
- The AI ecosystem is rapidly coalescing into a state-adjacent oligopoly. Today, SpaceX announced it will acquire Cursor, and last week the US government shut down Fable/Mythos. This trend is not new, but it has been accelerating lately. It makes the case for an open agent tooling ecosystem much more compelling.
- We realized we cannot build the one perfect ADE for everyone. No amount of predetermined customization options can support the near-infinite creativity that is possible through open source code. This is especially true when everyone has a coding agent that can quickly implement customization on the fly. Maybe this is "Software 3.0" finally starting to show itself.
From here, the roadmap is to make ctx more hackable. Right now it is a fairly involved Rust daemon plus desktop app. It's performant, but customization still requires cloning the repo, changing code, and rebuilding. We want to move toward a Pi-like model with extensions, plugins, and hot-reloading, while keeping the core runtime in Rust.
We'd also like to accelerate development of the mobile app (via a bring-your-own tunnel like ngrok, or hosted tunnel) as well as support for Windows (it is Mac and Linux only right now).
Happy to answer any questions about it.
We have a lint that caps source code files at 650 LOC and it works really well.
Whenever I think to myself “yikes that sounds too hard”, my next thought is “well, Zed team could probably do it”.
We will add paid options for Team/Enterprise when we exit our beta which include features for policy enforcement, collaboration, etc.
The upcoming paid plans will be for team/enterprise and managed services: org policy/security controls, shared history/collaboration, and optional hosted infrastructure like a gateway or managed remote access. These will be available when we exit beta.
For worktree creation, we support both git and jj.