Posted by mateenah 2 days ago
I’ll typically have a bunch of short sessions over the course of a day. Anytime I start a task that isn’t going to very directly benefit from the existing context I start fresh.
I don’t find a lot of benefit in explaining the project overall to Claude — I’ve deleted a lot of that explanation from my Claude.md because it didn’t seem to impact much.
I typically start a task by pointing it to 1-2 files and giving it some explanation of what I want done, and it figures it out.
Basically never hit context window limits or compactions, and can’t remember the last time I hit a 5 hour or a weekly limit.
They aren't really "explaining the project" either, but more module- or task-specific preferences, hand reference pointers, or other things like "there are mixed examples of how to do certain things in this project, prefer X to Y." I use a write-everything-twice approach. After I find myself having to correct an implementation because it didn't figure out one of these things on its own from the existing code, I'll add an entry. That also avoids bloating things with "I think this is relevant" compared to "I have noticed that this is necessary."
I keep doing this because it lets me experiment with different approaches to problems without risk of it fixating on things from a previous abandoned attempt, and particularly because sometimes I'm wrong and I haven't found the agent harnesses particularly reliable at taking my word for it from a POV of "yes I know I said we need xyz earlier, but let's please entirely forget about that."
This takes a couple minutes (and I suppose I'm spending tokens each time), but sessions rarely reach compaction length and I like that I'm not trying to keep a whole separate pile of docs in sync.
It basically takes care of itself, or at least as close as it can.
I guess I need to do some claude.md work or find other ways to prime the session so i get the good personality and not the evil twin.
I've been running Claude and GPT in my own agent harness. The main difference I notice is that tasks take about 7x longer to complete if they're run in the official Claude or Codex harness (and cost me 7x more).
You would think this would lead to increased correctness, but that doesn't seem to be the case. Today I tested both side by side. They both resulted in data loss. (I had a backup obviously.)
GPT running in the official harness did a bunch of extra tests and double checking, and ended up with the same result regardless (it permanently deleted a bunch of documentation).
All else being equal, I like getting my data loss 7x faster and cheaper ;)
It's slightly bigger now, but here's a ~50 line version for reference. I added the missing outer while-loop, so it takes user input etc.
https://gist.github.com/a-n-d-a-i/bd50aaa4bdb15f9a4cc8176ee3...
I mostly use it with GLM via their coding plan, I got a year for like $20 when it was on sale. But I also hooked it up to Sonnet, Opus, GPT, etc.
Normally I do it exactly as you say, point at a few files, but if I know these features are involved I point at the corresponding mds instead. Its a shortcut for me to type less.
I have used this same pattern in my own harness and it works well there too. https://github.com/computerex/z
I hooked an instance of my harness up to telegram and now I talk to it from everywhere it and dispatches work out to subagents.
I can’t imagine this being worth optimizing. The issue is never that Claude can’t figure out what the projects is about…
Am I missing something or does this project not solve a problem most regular people have?
A good method seems to be only make a skill or memory when the LLM gets something wrong, or if you actually observe it's always doing the same step and you can get the model to the same place with less tokens.
Even the /handoff skill was written by the model…
I also imagine that varies by model.
It should be a first class feature of the harness, tbh. It kind of is with the /compact [focus] parameter but this is coarse and leaves no record. I find keeping the handoff files in the repo to be useful for historical context and later debugging.
The solution that I've developed is, let the agent figure things out efficiently, without inflating the context. I have what I call a smart repo that better explains this at
https://github.com/gitsense/smart-ripgrep
The basic idea is, when the agent does a ripgrep it gets back files + matching lines + context.
For those where the code is almost entirely a black box and cannot easily recover when something goes wrong. They are much more keen on this context management and planning because recovering from derailments is much harder (and takes longer) because its often a conversation with llm to try to recover to where they were before.
But are they really working instead of making it worse? Are there any tests or real case studies done by users not tool's author? From my experience, removing from context works more often then adding.
There I usually lay out stuff like "this is a personal greenfield project" and "don't bother with multi-user support" etc. Or Claude will default to creating something WEBSCALE for a simple tool that won't run outside of my local LAN-only Proxmox setup. And that'll also skip massive database migration support for a project that's 3 days old - the agent doesn't know that. I'm just dropping it on the project after a full memory wipe.
This means its changes will either be out of alignment with the overall project and its "style" and goals, or it waste tokens re-getting to know the basics about the project each time.
No third case.
I have the LLM at some point in the day while working on the project create that file with all the relevant context. And then I'll periodically have it update that file (often before I compact the context window, or before I switch to a new task). And then I just have the LLM update it whenever I'm done working on the project for the day.
Then no matter what, if I come back that project again a day later, a week later, a month later, whatever – I just literally point a fresh session at the most recent status doc to help both me and the LLM orient ourselves to the work at hand. What's really nice too is having it reference the status docs from previous days to help orient it for creating the new status doc for the current day.
I've been doing this informally for probably over a year now, and have started formalizing it so I do it with every project. It's been a big help to me personally given all the context switching between projects I've been doing more and more since using AI coding tools.
Not sure I’d call that “stopping wasting my tokens”.
I do think that this project is interesting in several ways - prioritizing privacy, minimizing spend, and using objective semantic markers to sift and consolidate the key takeaways from long sessions. I'd like to try it on my cline project history. But while it would make a great recording of project history, I wonder if a lot of it doesn't end up detailing blind alleys the project went down and had to back out of.
Generally when this happens I feel that it's due to vague specification on my part, or avoiding architectural decisions I didn't want to deal with and implicitly inviting the model to implement a lowest-common-denominator solution.
Yes, I've run into this as well. I had the agent document the changes it would make along the way, but it would want to keep making note of things that we switched away from. Eg, "In phase3 we used mysql instead of sqlite". On some projects I let the agwnt do all the documentation and plan.md and state.md files, and every so often go through manually and delete some of the cruft that's no longer needed.
The only tip I can give is that your skill that builds or wraps up work. You should have it update those files if anything has changed.
Claude/Agents files shouldn't be bloated, but should imho act as a basic amount of context on the project so your agent and skills can pick up and go, with even the most basic initial prompt.
Depending on the scope of work you’re doing, it might be better to have this removed from the context of the work that was done.
I keep a “Last Updated Hash” in my md and every so often will have the LLM pull a diff from that hash to the current head, then determine what doesn’t match.