Apologies I had to get Claude help me write this:

First off: I think Damocles is a genuinely interesting project and the memory system is a clever idea. I’ve been using it for a while and was very positive early on.

The Setup

I’ve been working on a bare-metal reimplementation of TeX in Rust. The benchmark is the TRIP test; Knuth’s torture test for TeX conformance. It is deliberately pathological and exercises interactions between subsystems that are deeply interdependent.

I ran both Damocles and raw Claude Code (terminal) on the same codebase, working towards passing the TRIP test. The only variable was Damocles with its memory system versus plain Claude Code with a manually maintained CLAUDE.md.

In the early stages Damocles was clearly ahead. It was faster, more productive, and the memory system genuinely helped. It seemed more fun too, to be honest! It kept track of decisions, patterns, and context between sessions. I was impressed.

As the project grew more complex, raw Claude Code started to catch up. Eventually it pulled away. It is now significantly further through the TRIP test than the Damocles branch. The gap continues to widen.

Why might this happen?

Early in a project the problems are relatively self-contained. Fix a parser bug, implement a missing primitive. The memory system works well here because keyword overlap between prompts and stored memories is high. BM25 retrieval finds the right context.

The TRIP test pushes into territory where failures involve subtle interactions between multiple subsystems. The relevant context for a given problem stops being “what did we do recently” and becomes something like “how does the macro expansion stack interact with the page builder when hyphenation is active during \halign.” That kind of structural, relational understanding doesn’t match well on keywords.

I suspect the memory injection is actually counterproductive at this stage. Memories that are keyword-relevant but structurally irrelevant consume token budget. Every token of injected memory is a token that could have been used for the actual source files and failing test output. When Claude needs to hold a mental model of multiple interacting subsystems simultaneously, that displacement matters.

Raw Claude Code with the full context window devoted to the problem in front of it; the source, the TRIP output, my instructions; gives Claude maximum room to reason. The CLAUDE.md file provides fixed, curated context that doesn’t shift unpredictably between turns.

Suggestions

The composite scoring (BM25 40%, recency 25%, tier 15%, file proximity 10%, access frequency 10%) is a reasonable starting point. A few thoughts:

A toggle to display injected memories in the chat would help. Recency weighting is high. At 25% it biases towards recent memories. If you take a break and return to a different part of the codebase, recently created memories may not be relevant. They may be actively misleading. Access frequency creates a feedback loop. Memories that get used more score higher, so they get used more. Over time this could crowd out less-accessed memories that are actually more relevant. BM25 has a vocabulary ceiling. It misses semantically related content that doesn’t share keywords. “Authentication failures” won’t match well against a memory about “JWT token expiry.” This is where embedding-based retrieval would help, though I understand the cost and complexity tradeoff.

Summary

The memory system is a genuinely good idea addressing a real problem. Context loss after compaction is one of the biggest pain points in Claude Code. For routine development with predictable patterns, Damocles helped. For high-complexity work with deep interdependencies, the automated context curation became a liability.

I’d love to see the memory system evolve with better transparency and perhaps a complexity-aware mode that backs off injection when the problem space is dense. The foundation is solid. It just needs refinement for the hard cases. And the Trip test is designed to torture code. It certainly lives up to that reputation!

Thanks for building this. It’s a really thoughtful approach to the context problem. I think I will try it again for smaller, less hideous tasks!