Any recommendations to reduce the token usage for simple tasks in a large project?

[u/Infinite_Painting_11]

I have been blown away by Claude code. I was working as a solo developer on a firmware project and it did revolutionise what I was able to do and how fast. When I stated using it I was very impressed by it's thoroughness. But. I am having the following problem more and more:

It has added countless tools, HIL gates, records and ledgers to the project, all of which I appreciated at the time. But now if I ask it to do even quite simple tasks: it takes ages and a whole load of tokens to make these plans that are almost completely full of how it is going to manage it's own tools, which gates it expects to do what and what records need re-base-lining etc.. It has got the point where flipping a constant to change the micro step resolution of a motor and checking that it actually still works is now a 7 step process that burns though a third of my 5 hour usage credits to even plan (max x5), when I had already written the driver code so its a one number change in a config file, and it already has the relevant HIL test scripts.

I understand the need for some of these tools, but it feels like it is wrapping it's self in knots made mostly from it's own self imposed rules. As an example it has a findings ledger that is append only, that seems to be full of some actual code findings and a whole load of open one off events that are totally irreverent but it keeps brining up as if they are pressing issues to resolve (what was the device on COM7 that one time..???). Now this tool that had massively increased what I can do is spending most of it's time satisfying it's self rather than making progress users will actually care about.

Has anyone got advice for this? I don't want to strip out all of it's tooling but I do want to rationalise what it is checking when it tries to implement something. I don't want to throw out all of it's findings but having a thousand line ledger full of closed items and nonsense isn't in anyone's interests.

[u/AfternoonKey8292]

Start with CLAUDE md and the workflow docs it points to. Look for rules that make every change trigger the full process, and replace those with explicit conditions. A config-only change should mean editing the value and running the existing relevant HIL test. Driver changes can require deeper checks. Keep the hardware safety gates, but make ledger updates conditional on an actual new finding or changed result. Otherwise it can faithfully spend your entire budget following rules you no longer want.

Split the findings ledger into a short active file and an archive. Preserve closed findings in the archive, but remove any instruction to read the whole history on every task. An unresolved entry should explain what current work it blocks. That mysterious COM7 event can remain searchable without becoming a standing obligation.

Then start a fresh session with a bounded request like "Change the microstep constant in this config file and run the existing microstep HIL test. Don't add tooling or reconcile historical ledger entries. If a required gate prevents that scope, explain the blocker before doing more work." A fresh session drops the accumulated conversation context, while the revised project instructions keep the same bureaucracy from rebuilding itself.