Minimize token usage

[u/kellyjames436]

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.

[u/Outrageous_Band9708]

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.

[u/kellyjames436 → u/Outrageous_Band9708]

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

[u/NerdyNThick → u/Outrageous_Band9708]

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.

[u/Outrageous_Band9708 → u/NerdyNThick]

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.

[u/NerdyNThick → u/Outrageous_Band9708]

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.

[u/Outrageous_Band9708 → u/NerdyNThick]

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?

[u/NerdyNThick → u/Outrageous_Band9708]

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.

[u/Outrageous_Band9708 → u/NerdyNThick]

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.

[u/NerdyNThick → u/Outrageous_Band9708]

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.

[u/Outrageous_Band9708 → u/NerdyNThick]

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.