Lossy context compaction in Claude Code feels like the same mistake I made last year with Busy4, when I noticed that I was getting slowdowns on huge context windows. My sessions would go for days, and slow to a crawl.
The way I fixed this was by creating a sliding context window, with agent directed vectorization. Claude Sonnet, it turns out was actually very capable of doing this. Initial implementations used variations on SQLite, PSQL, Mongo, and Redis, to get there, but how you store the vectors is unimportant.
The real insight came when I ran the Busy client against Gemini, and noticed how Gemini was doing internal context matching. For example, when you use Gemini, you'll notice that no matter how long the context window runs, it can always remember the beginning of the conversation.
Another quirk, is that Gemini seems to remember context entry ID numbers when you talk to it, which tells me that there are tool calls going on in the background to look up memory within the context of a session.
So what I did was implement this in JavaScript and then in Go, both of which are fairly straightforward to do, and developed a strategy that works universally. Should also work in TypeScript.
Claude models will hallucinate and get confused, if tool calls are handled without clear labeling. That may be why Claude Code falls back on lossy compaction.
But the solution there is labeling (success and failure, with permission to continue).
And that's how you keep the client responsive, and current. Given the constraints of the Claude Code framework.
I would like to see this implemented so we don't have to deal with lossy Cursor-like compression. Claude is amenable to the pattern if it's explained.
My logs around "Panda Protocol" should provide detailed implementation insights going back eighteen months or so.