I've been exploring the internals of Claude Code and Codex via the transcripts they generate locally (these serve as the only record of your interactions with the products)[1].
Given the stance of the article, just the transcript formats reveals what might be a surprisingly complex system once you dig in.
For Claude Code, beyond the basic user/assistant loop, there's uuid/parentUuid threading for conversation chains, queue-operation records for handling messages sent during tool execution, file-history-snapshots at every file modification, and subagent sidechains (agent-*.jsonl files) when the Task tool spawns parallel workers.
So "200 lines" captures the concept but not the production reality of what is involved. It is particularly notable that Codex has yet to ship queuing, as that product is getting plenty of attention and still highly capable.
I have been building Contextify (https://contextify.sh), a macOS app that monitors Claude Code and Codex CLI transcripts in real-time and provides a CLI and skill called Total Recall to query your entire conversational history across both providers.
I'm about to release a Linux version and would love any feedback.
[1] With the exception of Claude Code Web, which does expose "sessions" or shared transcripts between local and hosted execution environments.
Nice, I have something similar [1], a super-fast Rust/Tantivy-based full-text search across Claude Code + Codex-CLI session JSONL logs, with a TUI (for humans) and a CLI/JSONL mode for agents.
For example there’s a session-search skill and corresponding agent that can do:
aichat search —json [search params]
So you can ask Claude Code to use the searcher agent to recover arbitrary context of prior work from any of your sessions, and build on that work in a new session.
This has enabled me to completely avoid compaction.
That is a cool tool. Also one can set "cleanupPeriodDays": in ~/.claude/settings.json to extend cleanup. There is so much information these tools keep around we could use.
IMO these articles are akin to "Twitter in 200 lines of code!" and "Why does Uber need 1000 engineers?" type articles.
They're cool demos/POCs of real-world things, (and indeed are informative to people who haven't built AI tools). The very first version of Claude Code probably even looked a lot like this 200 line loop, but things have evolved significantly from there
> IMO these articles are akin to "Twitter in 200 lines of code!"
I don't think it serves the same purpose. Many people understand the difference between a 200 lines twitter prototype and the real deal.
But many of those may not understand what the LLM client tool does and how it relates to the LLM server. It is generally consumed as one magic black box.
This post isn't to tell us how everyone can build a production grade claude-code; it tells us what part is done by the CLI and what part is done by the LLM's which I think is a rather important ingredient in understanding the tools we are using, and how to use them.
This is very interesting, especially if you could then use an llm across that search to figure out what has and maybe has not been completed, and then reinject those findings into a new Claude code session
I haven't written the entry yet but it is pretty incredible what you can get when letting a frontier model RAG your complete CLI convo history.
You can find out not just what you did and did not do but why. It is possible to identify unexpectedly incomplete work streams, build a histogram of the times of day you get most irritated with the AI, etc.
I think it is very cool and I have a major release coming. I'd be very appreciative of any feedback.
For that you'd be better off having the LLM write TODO stubs in the codebase and search for that. In fact, most of the recent models just do this, even without prompting.
I think it is interesting. Is there any other company in a position today that could put together endorsement quotes from such high ranking people across tech?
That's because of financial links. They are so intertwined propping up the same bubble they are absolutely going to share quotes instantly. FWIW just skimmed through and the TL;DR sounds to me like "Look at the cool kid, we play together, we are cool too!" without obviously any information, anything meaningful or insightful, just boring marketing BS>
> They are so intertwined propping up the same bubble they are absolutely going to share quotes instantly.
Reading this line, I had a funny image form of some NVidia PR newbie reflexively reaching out to Lisa Su for a supporting quote and Lisa actually considering it for a few seconds. The AI bubble really has reached a level of "We must all hang together or we'll surely hang separately".
It could be an indicator that Apple is not as leveraged up on NVIDIA as to provide a quote. Cook did make a special one of a kind product for the current POTUS, so he is nothing if not pragmatic.
The premise of the steps you've listed is flawed in two ways.
This is more what agentic-assisted dev looks like:
1. Get a feature request / bug
2. Enrich the request / bug description with additional details
3. Send AI agents to handle request
4a. In some situations, manually QA results, possibly return to 2.
4b. Otherwise, agents will babysit the code through merge.
The second is that the above steps are performed in parallel across X worktrees. So, the stats are based on the above steps proceeding a handful of times per hour--in some cases completely unassisted.
---
With enough automation, the engineer is only dealing with steps 2 and 4a. You get notified when you are needed, so your attention can focus on finding the next todo or enriching a current todo as per step 2.
---
Babysitting the code through merge means it handles review comments and CI failures automatically.
---
I find communication / consensus with stakeholders, and retooling take the most time.
I have been looking at this problem space, including beads recently.
I wasn't able to find something AI-native that supported subissues, and worked across projects. I require git worktrees on my programming work now, and I want it to be able to handle integration with systems like Linear or even GH issues (which was my preferred ticketing system before CLIs emerged)
The idea is in part, ~I have 15 minutes right now, what is the most important thing to put attention to? Be routed to the project and go immediately to work with a CLI.
I'm using Claude Code and codex for programming and administrative chores now. For example, managing the process of finding and selecting an arborist.
My main personal project, focuses on making Claude Code and Codex conversations useful (https://Contextify.sh). I use uses pure markdown (TODOS.md) for issue management and it is at its limit.
I'm less concerned about the DB's storage location. I don't think it needs to be stored with each project, but each project does need to be able to access it.
I was into playing the mods for the original and played some of 2142 on PC.
Has the official multiplayer gameplay held up? I did try a release around the time of RDR2 on Xbox and it had seemed like pay to play may have messed with it at some point.
Curious if the mod support seems like a jailbreak from the official multiplayer.
Building Contextify - a MacOS application that consumes Claude Code and Codex transcripts, stores them in a local sql db.
The main window uses Apple’s local LLM to summarize your conversation in realtime, with some swoopty UI like QUEUED state on Claude Code.
I’ve just added macOS Sequoia support and a really cool CLI with Claude Code skill allowing seamless integration of information from your conversational history into aI’s responses to questions about your development history.
The CLI interface contract was designed to mutual agreement between Claude code and codex with the goal of satisfying their preferences for RAG.
This new query feature and pre-Tahoe support should be out this week, but you can download the app now on the App Store or as a DMG.
I’m very excited about this App and I would love to get any feedback from people here on HN!
That’s an interesting direction. I haven’t thought of this in multiplayer sense.
Would you see this as something that is sort of turn-key, where a central database is hosted and secured to your group?
Or would you require something more DIY like a local network storage device?
And similarly would you be open to having the summaries generated by a frontier model? Or would you again need it to be something that you hosted locally?
A central service. Hosted, secure, frontier model is fine. I’m thinking this through it’s probably something GitHub or an addon should provide.
But maybe it starts local with an app like yours anyway. I do a lot of solo hacking I don’t want to share with the team too. Then there is some sort of way to push up subsets of data.
I can see github providing this, but it would still be at the git-operation level.
What I've found using this contextify-query cli in talking to my project(s) CLI AI history is substantial detail and context that represents the journey of a feature (or lack thereof).
In high velocity agentic coding, git practices seem to almost be cast aside by many. The reason I say that is Claude Code's esc-esc has a file reversion behavior that doesn't presume "responsible" use of git at all!
What I find interesting is that neither Anthropic nor OpenAI have seized on this, it is somewhat meta to the mainline interpreting requests correctly. That said, insights into what you've done and why can save a ton of unnecessary implementation cycles (and wasted tokens ta-boot).
Any thoughts on the above?
If you're open to giving the app a try, and enable updates on the DMG, the query service + CC skill should drop here in a few days. It's pretty dope.
Anyhow, this is really cool feedback and I appreciate the exchange you provided here. Thank you. If you have any further thoughts you want to share I'll keep an eye on this thread or can be reached at rob@contextify.sh
Given the stance of the article, just the transcript formats reveals what might be a surprisingly complex system once you dig in.
For Claude Code, beyond the basic user/assistant loop, there's uuid/parentUuid threading for conversation chains, queue-operation records for handling messages sent during tool execution, file-history-snapshots at every file modification, and subagent sidechains (agent-*.jsonl files) when the Task tool spawns parallel workers.
So "200 lines" captures the concept but not the production reality of what is involved. It is particularly notable that Codex has yet to ship queuing, as that product is getting plenty of attention and still highly capable.
I have been building Contextify (https://contextify.sh), a macOS app that monitors Claude Code and Codex CLI transcripts in real-time and provides a CLI and skill called Total Recall to query your entire conversational history across both providers.
I'm about to release a Linux version and would love any feedback.
[1] With the exception of Claude Code Web, which does expose "sessions" or shared transcripts between local and hosted execution environments.
reply