How to be token efficient using Paul? #18
Replies: 2 comments
|
I would not start a brand-new session for every Paul command. The framework is designed around persistent A good pattern is:
The docs also point toward keeping plans small: standard plans target a few tasks, and the planning workflow says to load only the context needed for the current plan. That is probably the biggest token saver: do not pull in old summaries or broad project context unless the current plan actually needs them. So I would start a new session when you are changing milestones, after a completed handoff, or when context is getting too large. I would not restart just between normal commands in the same plan. A compressed note style can help for handoffs, but it should not remove acceptance criteria, decisions, or file references, because those are the parts Paul relies on for continuity. |
|
It would be interesting to have Paul enforce the size of plans and even let you know when its time to start a new session. The context window for my projects (mainly game development) fills up quickly and I have to start new session. Also on the Claude pro plan I hit my token limits for the entire day very quickly. Anything that can be done to have the same results with fewer tokens would be greatly appreciated. |
Uh oh!
There was an error while loading. Please reload this page.
Whats the best way to be token efficient when using Paul? should i start a whole new session each time issue a new Paul command? or are there certain Paul commands that work better together? Have you thought about using a method like caveman to reduce the token usage?
All reactions