HN user
We’re working on adding native support for Shelley!
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
Very cool! Do you have any of it OSS? Or drop me an email: luca@ctx.rs
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.
Thanks and this is a very interesting idea!
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!
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.
Lol fair enough! Great project btw. Interesting choice to trigger incremental refresh on SessionStart hook, that's nice.
How have you enjoyed the semantic search?
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.
This is likely true, but ultimately this tool is just SQL, which I believe Claude and others must be heavily RL'd on. We try to not do anything "special" and make it boringly SQL representation of past sessions.
Yes this is how we started as well!
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").
Building this made it obvious that there should be a standard format / specification for agent transcripts and logs (similar to ACP for runtime events). If you're interested in discussing this, please reach out!
Hi HN, OP here. We posted here back in April and the most common request was to make the source code public.
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.
Dupe
There are some interesting concepts in the repo if you dig in, happy to answer any questions about it. For example Pretext for rendering virtualization or the elastic containers with AVF.
I’ll be posting soon about the decision to make ctx open source
Welcome to the folks at the Atlantic who are apparently brand new to “the hard problem”. Please start with reading Daniel Dennett and Donald Hoffman before writing articles about how you’ve cracked it.
Truly fantastic bridge from the original, this deserves an award
I’ve had lots of inconsistent app reviews from Apple. Just appeal and/or re-word your language and you’ll be ok. Plan on it taking a few weeks to fully sort out.
OpenRouter has lots of free model providers (you pay by letting them train on it) if you actually wanted to do something like this but legally.
This piqued my interest but I learned this is actually a myth.
RE: monolithic, single-file implementations
We have a lint that caps source code files at 650 LOC and it works really well.
Congrats Zed! GPUI has been a huge inspiration.
Whenever I think to myself “yikes that sounds too hard”, my next thought is “well, Zed team could probably do it”.
The plan is for the app itself to remain free, no account, fully local, bring-your-own agents/endpoints/tokens, etc.
We will add paid options for Team/Enterprise when we exit our beta which include features for policy enforcement, collaboration, etc.
Yes, it’s free for individual local use, and you don’t need an account.
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.
Ah I missed that, my mistake. It is fixed now. To confirm, it is not open source.
Yes, we allow fully local without github/PR involved.
For worktree creation, we support both git and jj.
It is for issues reporting, similar to Claude Code.
I think your concerns are valid and echo a lot of what I've heard from others experiencing the same uncertainties.
--- RE: Sandboxing and Permissions ---
First, make sure you know the Lethal Trifecta: https://simonwillison.net/2025/Jun/16/the-lethal-trifecta/
If you run a coding agent with full yolo permissions on your machine, there are two major problems: 1. unrestricted internet access is a vector for prompt injection and code/data exfiltration 2. other stuff on your machine that you don't want your agent to access or modify
Most coding agent harnesses went for the "low friction" sandboxing approach and used Seatbelt on Mac. This doesn't really work well in practice because you can't allowlist certain safe domains (so its either all internet or no internet) and it's really tricky to allowlist certain locations on disk (agents ideally need to be able to install system packages, work with mobile simulators, etc and a lot of that stuff is on disk outside of your workspace).
So our solution to this looks a lot like yours: give your agents a container and a network policy and then let them yolo. Per your container policy, they won't be able to access anything unsafe on your disk or internet, except what you narrowly allow.
This is not only a cleaner sandbox model, but it allows you to give them more autonomy instead of letting them pause on each command to run.
Your VM solution is definitely doing the right idea as well. The difference with ctx is that we automatically manage a lot of the VM complexity including elastic memory.
--- RE: Worktrees, Multi-Agent, Collaboration ---
Yes, worktree support is common now. The thing you mention about multi-agent support and collaboration across team members is spot on. All of your agent transcripts are stored in a unified format locally, so your conversations with Claude Code look exactly like your conversations with Gemini. So if your teammate uses one and you use another, the idea is that they can see your work equivalently.
Another interesting concept is that multi-agent support is agent harness agnostic. So you can have a Claude Code primary agent invoke a Gemini subagent.
--- RE: Local Models ---
We don't set anything up specifically for this, but any agent harness that already works with local models will work the same in ctx. I think Codex or OpenCode are both fairly easy to use with local models, whereas Gemini and Claude Code are harder to set up this way. But if you try it, I'd be interested to hear how it goes for you.
Glad it helped!
Thank you for flagging, I am fixing now and will update this thread when it's ready.