For the past three weeks, I’ve been experimenting with ways to keep Claude Code running almost continuously without burning through my weekly usage allowance. Before making these changes, I was regularly hitting my weekly limit within just a few days. Now I’m managing to spread usage across the full seven days, aiming for around 14% per day and usually reaching close to 98% by the end of the week. I thought I’d share how I’ve set things up, what’s worked and some of the problems I’ve encountered. First, a bit about my setup. Most of my Claude Code work is on a SaaS application I’ve been building. It’s now grown to over 300,000 lines of code, with multiple modules, functions, classes, tools, skills and integrations. It’s become a fairly large project, and simply opening Claude Code and asking it to start making changes was becoming increasingly inefficient. I run Claude Code on a dedicated VM hosted on my Proxmox server. It also has access to a separate development VM with its own allocated RAM, staging environment and Supabase instance. There’s another overflow VM available when needed. Claude Code always runs inside a tmux session, which means I can connect remotely, disconnect and leave it working.
- Documentation made a huge difference The first thing I focused on was documenting the codebase properly. I have Markdown files explaining the different modules, how they work, their dependencies and where everything lives. I also have a fairly extensive engineering policy document that links to other files covering coding standards, testing requirements, security, development procedures and release rules. The idea is that Claude doesn’t have to rediscover how the application works every time it starts a new task. Of course, maintaining all this documentation takes time, but I’ve found it much more efficient than repeatedly explaining the same things.
- I stopped treating Claude Code as a single developer This was probably one of the biggest changes. When I start a new session, I use an initial prompt that instructs Claude to act as the lead software architect. Its first job is to read the relevant documentation, recent development notes and project status before doing anything else. Once it’s familiar with the project, it reports back that it’s ready. From that point, the lead is responsible for planning the work, delegating tasks, selecting appropriate models, reviewing results and managing the development process. Rather than having one Claude session doing everything, the lead coordinates multiple workers running in parallel. Each worker operates on its own branch, allowing different parts of the application to be developed simultaneously without constantly interfering with one another.
- Model selection is extremely important One of the rules I’ve introduced is that the lead must consider token usage when assigning work. Not every task needs the most capable model. Some tasks are relatively straightforward, while others involve complicated architecture, debugging or decisions that require much stronger reasoning. The lead is expected to select the most appropriate model for each task rather than automatically using the most expensive option. This has helped considerably, but it also introduced one of the biggest problems I’ve encountered. Sometimes the lead assigns a task to a weaker model that simply isn’t capable of completing it properly. The worker submits its changes, the lead rejects them, and the worker goes back to try again. Then it gets rejected again. And again. I’ve had situations where this cycle continued for hours, occasionally even longer. The irony is that trying to save tokens by using a cheaper model can end up wasting far more tokens than simply assigning the task to a stronger model in the first place. So I’ve introduced another rule. If a worker repeatedly fails the same task, the lead must reassess the approach and consider switching models rather than allowing the same cycle to continue indefinitely. I’m still experimenting with this, but I think there’s a lot of room for improvement here.
- My development process now has proper approval stages The workflow is roughly: Lead architect → Parallel development workers → Testing → Lead review → Approval or rejection → Merge → Staging → Production. Workers develop on separate branches. Once the work is completed and tested, it goes back to the lead for review. If the lead rejects it, the task goes back for further development. If approved, the changes can be merged into the main branch and pushed to staging. Production deployment requires my approval, after which the lead handles the release process, including the necessary checks and rollback arrangements. The important thing is that the lead coordinates the process rather than doing every development task itself. It also means I don’t need to supervise every individual change.
- Testing was wasting an enormous amount of time and tokens This was another problem that took me a while to recognise. A worker would make changes and then run a complete end-to-end test of the entire process it was working on. Sometimes these tests would take a considerable amount of time. Then, right near the end, something would fail. The worker would fix the problem and start the entire test again. You can imagine how much time and unnecessary work this creates when it happens repeatedly. I’ve now changed the testing policy so workers test progressively. Rather than waiting until the end, they validate individual stages as they go. If something breaks, they can focus on the affected stage, fix it and rerun the relevant tests instead of repeating everything unnecessarily. Full integration testing still happens before changes are approved, but we’re no longer relying on complete end-to-end tests for every small correction. This has made a noticeable difference.
- I start a fresh lead session almost every day Another thing I’ve learnt is that keeping the same Claude session running indefinitely isn’t necessarily a good idea. As the context grows, token usage can increase and the lead can sometimes lose focus or start making decisions based on outdated information. So I generally start a fresh lead session each day. Because the project is documented and development progress is recorded, the new lead can read the relevant information and pick up where the previous session left off. This has worked much better than trying to maintain one enormous conversation for days. It also forces the development process to maintain proper records rather than relying on the AI remembering everything.
- The results so far Before introducing these changes, I could burn through my weekly Claude Code Max allowance in a matter of days. Now I’m generally managing to keep development running throughout the entire week. I try to maintain an average usage of around 14% per day, and by the seventh day I’m usually approaching 98% of my weekly allowance. That doesn’t mean Claude is generating code every second of the day. There are periods spent testing, reviewing, waiting for dependencies and handling other development tasks. But the overall process can continue around the clock, with relatively little intervention from me. And because it’s running in tmux on a dedicated VM, I can check progress remotely whenever I want.
- What I’ve learnt The biggest lesson for me is that optimising Claude Code isn’t simply about writing shorter prompts or choosing cheaper models. It’s about how you organise the entire development process. A poorly assigned task can waste hours. A weak model stuck in a correction loop can consume more tokens than a stronger model would have used. Poor testing practices can result in the same work being repeated unnecessarily. And without proper documentation, every new session wastes time rediscovering information that should already be available. I’m certainly not claiming my setup is perfect. I’m still finding problems and making changes almost daily. But compared with how I was using Claude Code a month ago, the difference is substantial. I can now keep development moving almost 24/7 while staying within my weekly allowance, rather than hitting the limit halfway through the week. I’m particularly interested in how others are handling model selection and preventing workers from getting stuck in endless cycles of failed attempts. Has anyone found a reliable way to make the lead recognise when a worker is out of its depth and automatically escalate the task to a stronger model? That’s probably the next big improvement I’m working towards. submitted by /u/Admir-Rusidovic
Originally posted by u/Admir-Rusidovic on r/ClaudeCode
You must log in or # to comment.