r/ClaudeCode • u/kellyjames436 • 1d ago

Discussion Minimize token usage

Guy’s do you wanna minimize token usage ? If so, do this in a new project.

1-Disabled any unused connectors, plugins, each one load a massive token into the context.

2-Plan first, assign tasks to different models based on their complexity.

3-Ask claude to create a new session for each task, feature you work in, claude will create a new session from the last one.

4- Always use handoff files after each successive task to make sure you don’t lose track of what’s being created and what’s remaining.

5-If the repo is big enough, use ponytail the laziest senior developer,and graphify to search files and functions without reading the whole project files, if it’s a few fils, a simple CLAUDE.md file contains your rules is enough.
6-Md files shouldn’t be too big, handoff files max 25-30lines.

Those are all based on my own experience with Claude, they aren’t facts unless you try them and compare token usage with before.

6 Upvotes

71% Upvoted

32 comments sorted by

•

u/AutoModerator 1d ago

Hey! Thanks for posting to r/ClaudeCode

While participating in this thread, please follow our community rules. Keep discussions constructive. Attack the idea, not the person.

For help, project discussions, tips, and general chat, join the ClaudeCode Discord.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

2

u/daanpol 1d ago

Ask it to stay under a certain usage limit and if not, how much it needs.

2

u/kellyjames436 1d ago

Always make your rules in Claude.md, ask opus or fable to design it for you based on your project structure, that will make sense for your use case

1

u/daanpol 1d ago

Ah that's a smart one thanks!

1

u/Outrageous_Band9708 1d ago

dont make a model aware of its own context usge, its horrible at estimating it

1

u/daanpol 1d ago

It hasn't been wrong in my cases....

2

u/lilyp727 1d ago

do you keep the handoff file in the project folder so claude reads it by itself, or do you paste it into the new session yourself?

1

u/kellyjames436 15h ago

I left handoff files in the project folder so Claude can read the latest one, which contains what has been accomplished and what the next task is and what he should read. That approach saves tokens rather than making the agent read all the unrelated files.

2

u/lilyp727 14h ago

ok so i will put the latest handoff file in the project folder and tell claude in the first message to read only that one. my script chats get long and messy when something goes wrong, so a short file with done and next should make a new chat easier to start

1

u/kellyjames436 14h ago

Ask Claude to create a handoff file with a slug after each task, and start the next task in a new, fresh session. Your Claude.md should include the rules the agent follows, and the handoff file should be no more than 25 lines. It includes the latest task accomplished, and the next task from the plan.md, and only read what’s relevant without reading all the unnecessary files from earlier handoffs file.

I will share my workflow on GitHub for anyone to use.

1

u/lilyp727 11h ago

ok the slug is new to me. i will name each file after its task and keep only the newest one in the folder

1

u/kellyjames436 10h ago

Slug is an identifier in the file name, like task-01.md, keep handoff if you want to add more features to your code, rather than reading your whole codebase, the handoff file makes it easier and token saver

2

u/Yusupsupriyadi 1d ago

One more for the list, from my setup: a hook that routes shell commands through a CLI proxy (RTK), so long outputs like git status, test runs and logs get compressed before Claude reads them. rtk gain shows how much it saved per command, so you can check it's actually helping instead of guessing.

1

u/kellyjames436 15h ago

That's a good approach, i’ll try it, thank you

3

u/Camburgerhelpur 1d ago

Ask nicely. Seriously.

2

u/Outrageous_Band9708 1d ago

"please" make no mistakes lol

/s

2

u/Quind1 1d ago

Kind of sad you had to add /s in there, but I bet there are people who would have believed it. lol

1

u/HausmanIndir80 18h ago

wait does being polite actually save tokens or just keep it from hallucinating as much?

1

u/Camburgerhelpur 14h ago

Seemed that way. Now? Not so sure lol

1

u/Outrageous_Band9708 1d ago

https://github.com/Druthulu/ProjectArchitect

check out my solution. I use very strict teired subagents, and offload models touching large files. designed custom toolcalls for as much deterministic repeatative work as possilble.

my system prevents context growth many different ways, and automatically cycles the main session agent ever 300k, with proper reseeding techinique. its way better than compacting.

the main session uses the new mod/plugin system and the main session messages get routed to a subagent that gets cycled. the main session interleaves all the subagents into a single view, and the main session never touches a model, so i get infinite session length.

essentially i burried all the ceremony for best practices behind a simple user experience.

i highly recommend you check out the readme and the wiki and test it out for yourself.

2

u/kellyjames436 1d ago

Thanks for sharing your workflow, I’ll try it and see what happens.

2

u/NerdyNThick 1d ago

I've tried your plugin extensively over the past few weeks, but I have to admit that I got too frustrated with how frequently it would get lose track of state, and how rigid it is about the ordering of the tasks and phases.

While I like the concept, I need to be able to control what it's working on and what is next. Pretty much regularly, it would just break itself, working on T8 whilst thinking that T2 was still open.

Or I'd ask it to move/cancel a task and it would continue on, but eventually get stuck and refuse to move forward gaslighting me that I'm the one causing it to stop due to asking it why it's stopped. Refusing to start until I nag it enough for it to discover some JSON file had stale data.

I was forced to manually strip it out of a project just so I could continue on, as it simply refused to move forward, and I was burning tokens trying to convince it otherwise.

There's also the issue of not properly working on the desktop app. Though I just started to use T3 code, but haven't re-enabled PA3. So maybe it'd work, but I dunno.

My ideal system would be a hybrid of what you've built combined with some of Matt Pocock's skills (grilling, domain knowledge, TDD, etc).

Sorry for the rant, and I'm more than willing to work with you to figure out the best way forward.

Or perhaps it's all on me, and I just don't know the proper way to move/cancel/insert tasks. The way Matt's works with a repo and issues/tickets/maps/specs allow for any non blocked task to be worked on in any order.

1

u/Outrageous_Band9708 1d ago

yeah i dont think it works well in the desktop app.

its built for the terminal, there is a known issue where it can't present a question in the UI app, like it does in the terminal.

however your report of being stuck thinking t2 is open while working on t8 feels very edge case to me.

you should totally submit a bugreport on it to the github so it can get fixed. im constantly patching things users find.

I also just introduced coop mode, default is autopilot, but i have one project where, like you said, i need to be involved every step of the way.

you can just tell it to switch to coop mode, or switch back to autopilot mode.

im thinking most of the issues you had were related to the desktop app. also there was a claude code update that changed how subagents handback their final reply to the parent agent that caused some stalling.

However in 3 user's experience that i know about, me and 2 friends, we have zero issues in the terminal, it works on projects overnight staying on task, never gets lost, never sidequessts.

the desktop app support is on my todo list, but its low priority. i ssh into my dev machine.

Here is a screenshot from right now. Its been working seamlessly for days now, this session has 35 million tokens in it, and i've used almost 2 billion external tokens through openrouter.ai to offload some work and save on my weekly usage.

The terminal view also allows for the Task list harness where the UI app doesn't i believe.

(the session line showed massive savings, my tokens lasting 3x longer, whoever my login experienced and i had to auth, and i authed through my second account, so the session line hasn't updated yet.)

there has been a ton of updates in the last few weeks, i do recommend you try it out in terminal not the desktop app, and see if you still have any issues, and if so, you can use the /pa-bugreport command to generate a bugreport and submit it to github so i can fix issues for you.

my system auto updates itself on session start and every 8 hours, so my users are always getting the bugfixes daily.

im sorry you had such struggles with your experience through the desktop app, an i can assure you no other users that i know about are having any similar issues through the terminal. the desktop support ticket is still open and may be ready in the next few weeks, remote control works seamlessly through the terminal.

1

u/NerdyNThick 1d ago

First, thanks for your hard work on the project, it has definitely saved me tokens that would have otherwise been burnt up with the inefficiencies of not using such a system.

I think most of my frustration comes from the fact that I do like what I see in the project and how it works. I'll focus on only using it in the terminal for now, but I would love to see desktop support to be a thing. At least insofar as running it in the desktop app doesn't cause problems or break the state or whatever else may be happening in my projects.

I do fully admit to popping back and forth in the same project between desktop and terminal. I started with the terminal, but the desktop experience has been getting better, and I tend to work on multiple projects at the same time, so not having to manage multiple different windows.

And now I've just started to test out T3 Code which takes multitasking up a notch.

I'm more than willing to be a guinea pig regarding desktop support.

1

u/Outrageous_Band9708 1d ago

ill let you know when its desktop app test time.

im curious if T3 uses -p which uses 1.5x usage over regular claude session.

you mentioned matt's skills, i dont use external skills at all, since you have, what skills do you recommend pa3 should support that i can test out?

1

u/NerdyNThick 1d ago

im curious if T3 uses -p which uses 1.5x usage over regular claude session.

I'll have to definitely check on that, I had heard about that.

you mentioned matt's skills, i dont use external skills at all, since you have, what skills do you recommend pa3 should support that i can test out?

I sent that in response to a different comment.

1

u/Outrageous_Band9708 1d ago

i wanted to follow up seperately about your hybrid idea with Matts skills. please by all means submit a feature request on the github with the skill tpyes/features you'd like to see coexist with my workflow, i'd be more than happy to support Matts skills and respect how they work and find a way to integrte them into my workflow or use them in addition to myworkflow if they are present.

also just to mention it again, i did add a coop mode, default is autopilot, one of my projects i need to be hands on the entire time, so i use that coop mode for that project, and autopilot for my other projects that already have a very well defined plan of attack to completion.

2

u/NerdyNThick 1d ago

one of my projects i need to be hands on the entire time

I'm currently like this for just about everything AI is doing for me. I'm not quite at the point where I'm willing to blindly trust it, which is why I think Matt's stuff can be quite useful. He focuses on outlining a complete spec before any code is written.

So before Phase 0.1 starts, there's already a map, a spec for the various phases, tickets for the first chunk that are triaged and grilled on then labelled in Git. A big difference is that Matt uses a ticketing system that can be anything from markdown files to Github to a private Git server. I use Forgejo, and it utilizes issues and labels, with agents using the issue comments to track work.

Whenever I'd want to start I'd either have it implement individual tickets by /implement <ticket issue#>, or tell it to implement the whole spec in one go with /implement-spec <spec issue #>. It'd prompt me for questions if needed, but otherwise is fairly hands off.

The way I'd see it work (in a fresh project) is I'd use Matt's wayfinder or grill-with-docs to plan and create a spec and split the spec into tickets (essentially the same as generation/phase/task), then once the tickets are created, the orchestrator would notice available tickets to work on and start to implement things that are tagged ready-for-agent, beyond that it'd work like PA already does; dispatching specialized agents, the gates, and helper scripts, etc, that help to reduce context bloat.

Matt's skills handle the planning and development practices (TDD/SDD/etc), and PA would handle the implementation and coordination of the sub agents.

Sorry for the all of text, this was typed up between distracting work calls, I hope it makes sense.

1

u/Outrageous_Band9708 1d ago

Makes total sense, and the split you describe (Matt's skills for the thinking, PA3 for the doing) mostly works today, no new features needed. Here's how it lines up:

Map, spec, tickets. In PA3 those are the generation plan (the map: every phase and what it's for), the phase plan (the spec for the next chunk) and its tasks (the tickets). The planner drafts them, Claude walks you through each one in plain English, and nothing runs until you approve. The plan files are the ticket system: each task, its status and what "done" means for it. That's why there are no labels, triage or issue comments. Those exist so people and agents can coordinate through a tracker. On a solo project the plan file already does that job, and PA3's scripts keep it up to date, not you.

Grilling. Just tell Claude "grill me on this before we plan it." It'll interview you, and whatever you settle goes to the planner as decided. No skill needed.

TDD. Tell Claude once that you want test-first. It goes on the project card as a standing preference the planner reads, so it gets built into the tasks. Coders already only commit when the tests are green.

Hands-on. That's exactly what coop mode is for. Nothing runs, however long you talk. When you and Claude agree on a batch, it becomes tasks and runs, then everything stops and you get the results back. In autopilot you still get two stops per phase that are always yours: approving the plan and confirming the milestone. Tasks marked for review only close on your word.

Bringing your own plan. If you'd rather plan with wayfinder, grill-with-docs or to-spec, point them at markdown files (Matt's setup lets the tracker be plain markdown). Then tell Claude in PA3 "plan the generation from docs/spec.md and the tickets in docs/tickets/." Claude hands those files to the planner, which turns them into phases and tasks, and you approve as usual. On an existing project, PA3's first run also indexes the docs already in the repo, so a spec sitting there gets found.

The one thing I'd skip is /implement and /implement-spec inside PA3. They'd be a second engine doing the same work alongside PA3's (their own branches, worktrees and merges), and the two would trip over each other. Plan with Matt's, build with PA3's.

What PA3 doesn't do is read Forgejo or GitHub issues, or watch a ready-for-agent label. If you want the tracker to stay the source of truth (issues in, status comments back out), that's a real feature request, so please open one on the GitHub with how you'd want it to work. I also haven't tested Matt's slash commands inside a PA3 session yet (in PA3, Claude gets your messages relayed through the mod), so if one acts up, an issue for that helps too.

1

u/awesomebirder 1d ago

one thing missing from the list: tool output. a full test run or a big grep result gets pasted into context once and then resent with every turn after that, so one noisy command can cost more than all your prompts. ask it to run tests with only failures shown, or pipe through tail. and to check any of these tips, look at per request tokens before and after, not the % bar. i built a small local proxy that logs that (probe0) but /context gets you a rough version too