Three weeks ago you spent forty minutes with Claude Code figuring out why a database migration kept failing. You found the root cause, fixed it, moved on. Yesterday, in another session, your agent ran into exactly the same problem. It had no idea you’d already solved it — because the transcript from that first debugging session is sitting in a folder on your machine, in a format nothing can search.
That’s the problem ctx came to solve, and it’s a good one.
The stack nobody searches
Every serious coding agent logs absolutely everything it does. Claude Code, Cursor, Codex, Gemini CLI, GitHub Copilot CLI — each one keeps detailed local transcripts of every conversation, every command run, every failed attempt before the fix that worked. None of those logs talk to each other. None are cheap to search. If you want your agent to check “I’ve already solved this” before starting from scratch, today the only real option is to throw raw transcripts at it as context — and that can burn tens of thousands of tokens before the agent does anything useful.
ctx (GitHub - ctxrs/ctx: Search the coding agent history already on your machine · GitHub), launched on July 4th by a small team working under the name ctxrs, cuts straight to the point: it pulls all that scattered history into a single local SQLite database, structured enough to search in milliseconds instead of loading it all in.
Getting it running
It’s a single Rust binary — no daemon, no background service, no API keys.
# Discover and import all session logs from any supported agents
ctx setup
# Search through it all with natural language
ctx search "failed migration"
# Or narrow it down with multiple terms
ctx search --term "failed migration" --term rollback --term "cursor rename"
When you run setup, it scans your machine for local session logs from any supported harness and imports them. At the time of writing, ctx supports Claude Code, Codex, Cursor, Pi, OpenCode, Gemini CLI (via Antigravity), Factory AI Droid, and GitHub Copilot CLI.
A search returns you sessions and events that match, each with its own ID:
ctx show event <ctx-event-id> --window 3
ctx show session <ctx-session-id>
You pass those IDs to your current agent and it can pull exactly the chunk from a past session it needs — not the entire transcript.
What happens under the hood
ctx normalizes the raw transcript format from each harness into a common schema of sessions and events, stored in a plain SQLite file. That’s it — no embeddings, no model calls, no round trips to the cloud in the local version. You can even query the index directly:
ctx sql "SELECT provider, COUNT(*) AS sessions FROM ctx_sessions GROUP BY provider"
The project is Apache 2.0, and at time of writing has 180 stars, 15 forks, and 68 commits — written primarily in Rust, with SDK bindings in TypeScript, Python, Go, JVM, Swift, and .NET for anyone who wants to call ctx search from their own tooling instead of the CLI.
The token count, with a caveat
The project’s own benchmark claims that a real search costing 45,734 tokens via raw transcript drops to 917 tokens using ctx — roughly a 50x reduction. It’s worth noting that this is a self-reported figure from the project, not an independently verified benchmark. That said, the mechanism behind it is straightforward enough — structured search versus loading raw text — that the direction of the claim holds even if we don’t have an independent number to confirm the exact multiplier.
Something to watch: the cloud beta
There’s a private beta cloud version for teams that want to sync history across machines or share it internally. Worth flagging: the creator was direct in the Show HN thread that privacy boundaries here still aren’t settled — transcripts can carry personal details mixed in with technical decisions, and there’s no clear line on what should be shared and what shouldn’t. The local version we covered here doesn’t touch the network at all: no prompts, transcripts, or history leave your machine, and there are no API keys involved.
How the community reacted
The Show HN post hit 64 points and 37 comments in a few hours — well above average for a dev tool launch. What stood out in the thread wasn’t skepticism; several engineers commented they’d already built some version of this in-house, and someone pointed out that context amnesia in agents is becoming one of those problems everyone independently arrives at once they’ve used these tools long enough. That’s a pretty good signal: the gap that ctx is filling is one a lot of people had already noticed on their own.
Is it worth installing?
If you run more than one coding agent, or run the same one long enough to rack up months of sessions, this is practically free to try. It doesn’t change your workflow — it sits underneath, and only gets used when you or your agent explicitly search for something. Installation is one binary, one setup command, and nothing to configure.
Do you already have months of transcripts piling up with no way to search them, or is this a problem you didn’t even know you had until now?