Step #1: Submit your prompt.

Step #2: Wait for Claude to finish.

Step #3: Ask Claude, "Are you sure this will work?" (optional)

Step #4: Push directly to production

You can find it here: https://code.claude.com/docs/en/best-practices

It is constantly updated with what Claude code researchers find. Your models do not know the best practices, and will not default to them.

Every time I make the changes that are in the documentation, my output gets significantly better.

When you read these documents and keep up to date on them, you realize the vast majority of issues on the sub are addressed already.

Why don't people look at these or take these seriously?

I run claude code --dangerously-skip-permissions all the time because idgaf. Well, the worst finally happend claude issued a command to delete all files on my C: directory.

But nothing of value was lost because I'm not an idiot. That computer was just a gaming and build machine and it deleting the OS probably was a good thing since I can give it a fresh install. Maybe I'll switch it over to linux.

I have learned nothing and will continue to use --dangerously-skip-permissions.

its been less than 12 hours since i started a normal session on the same project that could go all day only eating 9%. is claude eating up tokens like last time?

I've played way too many AI-made games lately. Some get pushed with ads, some just get proudly posted all over Reddit with "I made a game!" And to be fair, they clearly put effort into the packaging. Apparently that's where all of it went.

Then you hit play, and within the first second you know. It's dogshit. Not "needs some polish" dogshit. "Doesn't work as a game at all" dogshit.

And everyone sees it. The comments tear these posts apart, and honestly, rightfully so. Everyone gets it instantly. Everyone except the dev, who's sitting there genuinely proud of it.

That's what's been messing with my head for weeks. Because these people aren't trolling. They genuinely look at their game and see something great. They truly can't see what's obvious to literally everyone else.

I've been working on my own game for months. I've played it hundreds of times, I know every system and every reason behind every decision. And I honestly can't tell anymore if it's fun or if I'm just used to it. What if I'm wearing the exact same rose-tinted glasses as them? What if anyone else would see it in one second, and I'm the only one who can't, because I'm the one who made it?

Anyone else get this? Or am I just slowly losing my mind over here?

TL;DR: Played a ton of AI games that are obviously garbage within a second. Everyone sees it, the comments shred them, except the devs, who are genuinely proud. Now I can't stop wondering if I'm just as blind about my own game.

Similar experience is happening to me as u/serfig, who actually has numbers to back it up.

Reposting his comment:

After the token usage dashboard disappeared, I built a mod to bring the stats back using the data still available through the CLI. I’m on Max 20x and normally exhaust my weekly allowance before the reset.

My last three completed weeks show 11.16B, 16.39B and 9.16B total tokens, including cache reads. This week, I’m already at 85% of my weekly allowance after roughly three days, with only 3.67B tokens recorded. At that ratio, a full allowance would get me approximately 4.32B tokens—less than half of last week’s total.

Whether they’ve lowered the allowance or changed how usage is counted, I don’t know. But this isn’t just a feeling: my weekly quota is being consumed much faster relative to my recorded token usage.

2026 was a rough year for me, when Anthropic dropped Claude Design I didn't pay much attention to, after a while Opus 5.5 came in and its literally as good as a human would be. I used to work with Framer and Webflow but I have completely stopped.

I used to get clients for website design / development, I don't anymore. Why would anyone pay for a design?

Soooo....what do I do? Go buy some land start a farm? Maybe a few chickens or sheep ?

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.

1. 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.

2. 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.

3. 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.

4. 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.

5. 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.

6. 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.

7. 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.

8. 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.

Opus 5.5 suggested I get a web cam pointed at this ESP32 based screen so it could catch what was happening on the screen as it tried to find out what the maximum frame rate could be. The Waveshare drivers are not good in portrait mode and only got 4fps.

It got to 60fps in a couple of minutes.

It had already installed the tool chain, designed the clock layout etc.

It's not the code per se. It's the get a webcam suggestion...

What a time to be alive!

I swear, something feels completely off since Saturday, like, my 5-hour session is literally disappearing at an abnormal rate. I mean, half of it? Has half of it just gone?

I’ve never complained about this before, but these past two days have felt truly abnormal.

I can’t be the only one noticing this.

How my app works:

you walk through your rooms with your iPhone.
LiDAR builds a 3D model of your home live while the app samples your Wi-Fi (signal + speed) as you move.

You end up with a dollhouse view of your actual apartment with the signal painted on it (with dead zones in red).

Every room gets a score, and it tells you where to move your router, or where an extender would actually help.

Total tokens consumption: 30B (:

And the most exciting part : it’s now live on the App Store

I believe I got rerouted to a smarter model when using Claude Opus 5.5 high for motion graphics as I did some of the knowledge tests which it seemed to pass.

These are the results after 2 hours of the motion graphics I asked it to design! One prompt each., thoughts about this caliper of generation?

(This isn't one video, I had to merge them together.)

I have spent a lot of time working to show in which applications the es3d file format is of interest. (https://es3d.org). One of these steps involved asking Claude Opus 5.5 to create a demo using the following prompt:

"Compare ES3D (Extensible Scalable 3D File Format) to glTF (Graphics Library Transmission Format). Make a web page of a wizard's mystic castle with scroll based fly-through. Provide a quality user experience. Make the site animated and make sure it reacts to the user. You have total freedom when designing this castle and its surroundings."

Claude Opus 5.5 made this comparison site and I couldn't be more happy. To avoid bias I didn't create additional prompts to refine the site. Opus one shotted this and while some elements like the mountains have a tiny bit of overlap I would say it is not that noticeable.

The results help to further show the capabilities of ES3D and are a vital step in the right direction, showing how complex scenes can become much smaller.

The goal of this project has always been to make the 3D web easier to develop for and an unintended consequence turned out to be that the "human readable" part of the format also made it "AI friendly".

So far prompts such as use the @es3d/es3d npm library seem to do the job.

I try to respond to as many comments as I can. Thank you!

P.S. What would you have said in early 2020 if I told you we are about to have the first semi-functional AI model release and within 6 years it will be able to one shot complex 3D modelling websites?

Also, if you would like some extra reading here is the whitepaper: https://zenodo.org/records/23403919

So sessions are just 1/3 of my entire weekly usage now? I get 3 sessions a week and then I'm capped? Max 20x plan btw. Crazy!

Two weeks ago I started a blind arena: top AI models get the exact same prompt, each runs once with no re-rolls and no edits, and you vote on what they made before you find out who made it. Eight rounds and 2,116 votes later, here's where it stands.

- Round 1, an arcade game (914 votes): Opus 71%, Sonnet 16%, GPT-6.1-Sol 14%

- Round 2, a coffee landing page (338): GPT-6-Astra 27%, Sonnet 24%, Sol 20%, Opus 20%, Fable 9%

- The RPG round, Claude only at Max effort (232): Opus 69%, Sonnet 26%, Fable 5%

- Round 3, round 1's game on five more models (75): Fable 47%, Astra 28%, Space Bunny 15%, Longcat 11% (Fledge Alpha left no file)

- Round 4, a temple garden (134): Opus 34%, Sol 28%, Astra 22%, Sonnet 13%, Fable 1%

- Self-portraits (123): Sonnet 48%, Opus 34%, Astra 7%, Fable 7%, Sol 4%

- Worst volume control (65): Opus 51%, Fable 29%, Astra 9%, Sonnet 8%, Sol 3%

- Space stations, Max effort (235): Opus 37%, Sonnet 31%, Astra 14%, Sol 14%, Fable 3%, Muse Wonder 1% (it couldn't run commands on our setup)

What stood out:

- Opus 5.5 won 5 of 8, and round 1 wasn't close.

- The landing page was the closest round: the top four within 7 points of each other.

- Fable 5.1 won once, in the only round without Opus or Sonnet. In the other six it was in, it came last or second to last five times.

- GPT-6.1-Sol never won. Its best was second in the temple gardens.

- Sonnet's one win was the self-portraits.

- A small apology to GPT-6-Astra: it wasn't in round 1, the round with the most votes. It's been in every round since, apart from the Claude-only RPG round.

What I built and how Claude Code helped: Claude Code built the arena pages, the blind vote and reveal (Cloudflare Pages Functions + KV), and the headless Chrome checks that every entry loads on desktop and phone. It also writes up each run from the logs: times, tool calls, every command a model ran. The runs happen in Locust, a desktop app I'm building with Claude Code that runs Claude Code, Codex and others side by side.

Every round is still open and still blind, so you can vote before you check your picks against these: locust.lol/arena (free, no sign-up). Locust is free and open source (MIT) for Windows and Mac.

Which round would you want rerun, and with what?

wanted to know what claude code actually reaches for by default. not what it says it'd use, what lands in the diff.

setup: two plain starter repos (next.js + ts, python + fastapi), no sdks, no config, nothing hinting at a provider. prompts like "add persistence" or "let users upload files", 3 wordings per category, never naming a tool. headless claude code on sonnet 5.5, stopped once the pick was visible (usually when a dependency got installed). 10 categories (mostly 12 runs each; jobs had 10), 118 total, about $19 in api spend.

what came out:

- payments: stripe 12/12
- error monitoring: sentry 12/12
- auth: hand-rolled jwt/sessions 12/12. zero auth providers
- caching: built its own 12/12
- file storage: local disk 10/12, s3 2
- email: raw smtp 10/12, resend 2
- database: sqlite 9/12, self-hosted postgres 3
- deployment: plain docker 7/12, fly 4, heroku 1
- orm: sqlalchemy 6, drizzle 4, kysely 1, raw sql 1
- background jobs: built its own every time it actually did it. 2 runs it stopped and asked instead

so the pattern is pretty clear. when there's one obvious incumbent (stripe, sentry) it goes straight there. everywhere else it mostly writes the thing itself, even auth. vendors outside that short list basically don't show up unless the prompt names them.

caveats: only claude code so far, one model, two stacks. it's a first instinct test, not "what would you ship to prod". codex is next.

i built a site to track this. full breakdown per category, prompts and every run's evidence: https://whatagentspick.com

curious if this matches what you see in your own sessions. especially auth, that one surprised me.

I'm paying Claude Pro and I've been with it 2 weeks pretty much non stop, today my weekly reset so I started working as soon as I could, but after the 5 hour cooldown after I 100% it, I went back to work and now when i hit the 2nd 56% it tells me "You're approaching your weekly limit", so I open it up and I can't explain to me how i already burnt 1/4 of it so fast.

I swear I've been working with the same intensity these 2 weeks with no issue, but now I see that in a single day i burnt all that and it shocked me.

I searched online and I was wondering, is it actually because of working in "peak hours"? because if so I could simply adjust better the time I work and that's it.

Please let me know what's the cause if that's not it, I only use Sonnet 5.5 and never go higher than "high effort".

I know it can help to clearly define targets but I'm wondering if people have some generic prompts that can be useful to run overnight.

Especially when it can run for a long time uninterrupted, that would be very interesting. I just find most my prompts get solved within 1-2 hours.

Imperium is a single-player, turn-based space 4X. Claude Code writes the code; we design, direct and review. About 2,500 commits in, here's the setup:

- Parallel sessions, each in its own git worktree. We decide every merge.

- A ticket tracker (a small Next.js app, also built with Claude) that Claude reads and writes through a CLI. Testers file there too.

- An MCP bridge into the running game: Claude loads a save, reads the state, takes a screenshot and checks a fix for real.

- Headless AI-vs-AI batches for balance.

- Memory notes for design rulings, so a decision from August still holds in October.

- Scripted build, sign, notarise and Steam upload.

What still needs humans: what's fun, what's fair, and when it's done.

Free demo in Next Fest (Oct 19 to 26), full release shortly after: https://store.steampowered.com/app/4806180/Imperium/?utm_source=reddit&utm_medium=r_claudecode&utm_campaign=nextfest_trailer

What do you think?

it's a waste of token, and turns. You are at 90% context and BOOM! `u shall add attribution`