Yes, additional tokens is a cost for higher throughput quality. What I mean by this is, the structured ceremony does tax on cost for a gain on better reliability and output. It's not perfect, but in my experience better than not having altogether in the long run. A few things you can do to mitigate, which are practices I do as well: 1 - in your project/state/roadmap add a rule to never run subagents for planning. Instead, default to targeted tool calling. 2 - When claude prompts you for next steps using the [1] Apply Phase XYZ [2] Questions First [3] Pause Here << when you see this, avoid running the slash command. Instead just say 1, 2, or 3 and you can include additional context to this to further instruct claude. 3 - If you're running Opus 1mil context window, try not to exceed past 200k-230k tokens on any single session. Use handoffs and clear the session. Each back and forth resends the entire conversation, caching helps mitigate this but cache expires rather quickly within claude code so it's not always reliable. You can reduce token consumption by upwards to 70% on identical tasks / prompts just by running a handoff and clearing as opposed to continuing through the larger context window. 4 - last thing to consider, and this is something I've learned by experience. Claude conflates the line to token ratio - what it's calling out actually isn't much consumption (the number of lines, etc). If you ask it how many tokens that actually equates to, it might correct itself and say in actually it's not as much as it thought. Does this to me all the time when running my testing. Last thing I want to add is that, I've weighed the pros and cons of less consumption for saving context vs a little more ceremony and structure (at cost of more consumption) for better quality output. I've seen in my own use and experience, with proper session management, that the ceremony is most definitely worth it. The big picture actually saves more consumption long run as it gets far closer / reliable in outputting higher quality the first time around, reducing debugging, remediation, and revision on what you're creating.

Yes! This is great to see. I like to build with Laravel / Intertia / Vue stack on the applications builds (where that stack fits, it's super fun to work in). I did something similar with CARL after hammering best practice research and enterprise / security hardened principles for these technologies. There's also an "audit plan" function that can be activated for any project that slots a step after plan before apply which will audit the plan and remediate it before applying. You can modify the specs of this audit to your liking! Maybe even spin off variations of it for different "types" of projects you are running through PAUL in order to have dialed in audit phases per project. Great feedback, these are just some of my approaches and experience.

@Charles Dove looking into it now!

yes! this is 100% the targeted issue that our courses, tools, methodologies are aiming to correct or improve upon.

@Garratt Campton yep, this is all great data. I have thoughts on it all. Just to preface, this is all discovered via my own findings and testing when working out how to develop a workspace approach that operates as consistent as possible. I never use the llm generated claude.md (what the research is referring to is the /init command that half ass scans your workspace and tosses a bunch of noise in the doc). I personally have found that the What, Why, Who, Where, How (How being very general approaches to the workspace as a whole, not too specific) kept between 100-150 lines is beneficial. I prefer keeping project / application / etc context self contained, within state files that enhance sessions as direct inputs with purpose, rather than any conventional "root level agent.md / claude.md approach. I built all of the frameworks we share here for my own purposes and just decided they would be good to share. It was never the other way around, and I decided to share them because they are working very well for me overall (there are still issues here and there due to nature of LLM and frameworks still being young). A lean and workspace oriented, targeted claude.md has worked great for me. I inject behavioral rules and guidelines that many would put in such a doc using CARL which is a hook engine that matches my key phrases with the relevant rules. I am able to very intentionally invoke them and they work wonders when it's dialed in right. Something like PAUL that maintains phased execution, when layered with the above is even more accurate than without it, in my experience. Then of course for building applications I run auditing, remediation, etc frameworks to clean up as much as possible for deployment hardening. I'm under the philosophy that the workspace is the first product that can then work as a deliverable and management engine - if we treat our filesystems more strategically as such then more can be gained from it.

@Dave Miz I recommend getting CARL - it's designed for these types of explicit guardrails - you can set up the keywords yourself to match what you want so that when you send a prompt with the phrases you set a very tightly scoped group of behavioral rules land in the system messages before claude processes your prompt.

@Dave Miz also, there might actually be something up with Opus if that's the model you're running... they are about to release mythos sometime, might be consolidating compute power by reducing opus thinking capabilities