I feel like so many of these memory solutions are incredibly over-engineered too.
You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track them too in a way that survives compaction.
- `FEATURE_IMPL_PLAN.md` (master plan; or `NEXT_FEATURES_LIST.md` or somesuch)
- `FEATURE_IMPL_PROMPT_TEMPLATE.md` (where I replace placeholders with next feature to be implemented; prompt includes various points about being thorough, making sure to validate and loop until full test pipeline works, to git version tag upon user confirmation, etc.)
- `feature-impl-plans/` directory where Claude is to keep per-feature detailed docs (with current status) up to date - this is esp. useful for complex features which may require multiple sessions for example
- also instruct it to keep main impl plan doc up to date, but that one is limited in size/depth/scope on purpose, not to overwhelm it
- CLAUDE.md has summary of important code references (paths / modules / classes etc.) for lookup, but is also restricted in size. But it includes full (up-to-date) inventory of all doc files, for itself
- If I end up expanding CLAUDE.md for some reason or temporarily (before I offload some content to separate docs), I will say as part of prompt template to "make sure to read in the whole @CLAUDE.md without skipping any content"
Great advise. For large plans I tell the agent to write to an “implementation_log.md” and make note of it during compaction. Additionally the agent can also just reference the original session logs.
The model is usually so confused after a /compact I also prefer a /clear.
I set up my directives to maintain a work log for all work that I do. I instruct Claude Code to maintain a full log of the conversation, all commands executed including results, all failures as well as successes, all learnings and discoveries, as well as a plan/task list including details of what's next. When context is getting full, I do a /clear and start the new session by re-reading the work log and it is able to jump right back into action without confusion.
Work logs are great because the context becomes portable - you can share it between different tools or engineers and can persist the context for reuse later if needed.
The trick is to parametrize the /compact. Something like "/compact focus on the XZY, the next steps will be FOOBAR, and keep a high level summary of BARFOO"
That makes the compaction summary a lot more focused and useful.
I think both /compact and /clear are valuable / have their own use cases.
my small mental mode:
- really quick fix / need to go over board with context -> just /compact + continue pushing
- next phase -> ask for handover document or update worklog, and then send fresh one to new phase.
I wonder how many thousands of hours I have put into this wonderful collection. My kids play them too.
There's some jank relating to fractional scaling on Wayland unfortunately, but I keep one monitor without scaling so when I want to play I just launch the puzzles on that.
I generally find with Nix and NixOS that I'm able to just use a dev shell to create little custom environments at runtime as needed. Another option is `mkOutOfStoreSymlink` if you want some dynamic config for some GUI you are running.
Suppose your dev shell contains app Foo v1 which uses lib Bar v2. It links directly against the full nix store path. So loading a different version of lib Bar (say v3) into your dev shell, which puts it on your PATH, doesn't affect Foo - the Foo executable will still link against Bar v2. That's by design and a very good thing! It assures reproducibility and fixes the version incompatibility issue that dynamic linking typically suffers from.
However, what if I want to swap it out for whatever reason? Right now I have to modify the package definition and rebuild it. That's needlessly slow and resource intensive for some one off monkey patch. It also might not be feasible at all on my hardware - most people's rigs aren't cut out to build chromium or llvm, for example.
The UX is also absolutely terrible. Have you ever tried to patch a nixpkgs provided definition? I actually gave up on using nix as my primary build tool over this.
My expectation going in was a neat and tidy collection of independent, standalone package definitions that imported one another to satisfy dependencies as necessary. The reality was a massive monolith containing all packages at once making extracting just one to patch it rather complicated in some cases.
I believe flakes were supposed to address this exact dependency modification UX issue somewhat, but they caused my code to break in other ways and I decided I was done sinking time into tinkering with tooling rather than building software.
They say you shouldn't host status pages on the same infrastructure that it is monitoring, but in a way that makes it much more accurate and responsive in outages!
It seems really straightforward to suggest that the better way to solve this is with standard protocols and self-hosting, but I do realise that's quite hand wavy and often not very accessible.
SMTP is an example of this succeeding, as problematic as that protocol is.
You can work around a lot of the memory issues for large and complex tasks just by making the agent keep work logs. Critical context to keep throughout large pieces of work include decisions, conversations, investigations, plans and implementations - a normal developer should be tracking these and it's sensible to have the agent track them too in a way that survives compaction.