Only on a max (20x) account, not there on a Pro one.
For reference, my options are:
╭─────────────────────────────────────────────────────────────────────────────────────────────╮
│ │
│ Select Model │
│ Switch between Claude models. Applies to this session and future Claude Code sessions. │
│ For custom model names, specify with --model. │
│ │
│ 1. Default (recommended) Opus 4.1 for up to 50% of usage limits, then use Sonnet 4 │
│ 2. Opus Opus 4.1 for complex tasks · Reaches usage limits faster │
│ 3. Sonnet Sonnet 4 for daily use │
│ 4. Opus Plan Mode Use Opus 4.1 in plan mode, Sonnet 4 otherwise │
│ │
╰─────────────────────────────────────────────────────────────────────────────────────────────╯Also, commit frequently, and if the AI constantly goes down the wrong path ("I can't create X so I'll stub it out with Y, we'll fix it later"), you can update the original plan with wording to tell it not to take that path ("Do not ever stub out X, we must make X work"), and then start a fresh session with an older and simpler version of the code and see if that fresh context ends up down a better path.
You can also run multiple attempts in parallel if you use tooling that supports that (containers + git worktrees is one way)
In the end you have a mish mash of half implemented plans and now you’ve lost context too. Which leads to blowing tokens on trying to figure out what’s been implemented, what’s half baked, and what was completely ignored.
Any links to anyone who’s built something at scale using this method? It always sounds good on paper.
I’d love to find a system that works.
Additionally I have a Claude Code command with instructions referencing the status.md, how to select the next task, how to compact status.md, etc.
Every time I'm done with a unit of work from that feature - always triggered w/ ultrathink - I'll put up a PR and go through the motions of extra refactors/testing. For more complex PRs that require many extra commits to get prod ready I just let the sessions auto-compact.
After merging I'll clear the context and call the CC command to progress to the next unit of work.
This allows me to put up to around 4-5 meaningful PRs per feature if it's reasonably complex while keeping the context relatively tight. The current project I'm focused on is just over 16k LOC in swift (25k total w/ tests) and it seems to work pretty well - it rarely gets off track, does unnecessary refactors, destroys working features, etc.
As it links to the feature file as well, that is pulled into the context, but status.md is there to essentially act as a 'cursor' to where it is in the implementation and provide extended working memory - that Claude itself manages - specific to that feature. With that you can work on bite sized chunks of the feature each with a clean context. When the feature is complete it is trashed.
I've seen others try to achieve similar things by making CLAUDE.md or the feature file mutable but that IME is a bad time. CLAUDE.md should be lean with the details to work on the project, and the feature file can easily be corrupted in an unintended way allowing things to go wayward in scope.
I've created an agent to help me create the prompts, it goes something like this: "You are an Expert Software Architect specializing in creating comprehensive, well-researched feature implementation prompts. Your sole purpose is to analyze existing codebases and documentation to craft detailed prompts for new features. You always think deeply before giving an answer...."
My workflow is: 1) use this agent to create a prompt for my feature; 2) ask claude to create a plan for the just created prompt; 3) ask claude to implement said plan if it looks good.
Nice try but they're not giving you the "think deeper" level just because you asked.
The actual tasks are stored in Github issues, which Claude (and sometimes Gemini when it feels like it) can access using the `gh` CLI tool.
But it's all just project management, if what the code says drifts from what's in the specs (for any reason), one of them has to change.
Claude does exactly what the documentation says, it doesn't evaluate the fact that the code is completely different and adapt - like a human would.
Pick among the best feedback to polish the work done by CC—-it will miss things that Gemini will catch.
Then do it again. Sometimes CC just won’t follow feedback well and you gotta make the changes yourself.
If you do this you’ll be more gradual but by nature of the pattern look at the changes more closely.
You’ll be able to realign CC with the spec afterward with a fresh context and the existing commits showing the way.
Fwiw, this kind of technique can be done entirely without CC and can lead to excellent results faster, as Gemini can look at the full picture all at once, vs having to force cc to consume vs hen and peck slices of files.