The Problem Isn’t That You Use Claude Code Too Much
There’s a pretty common feeling when you start working seriously with Claude or Claude Code: you look at the counter, see you’ve burned through half your quota, and swear you haven’t done anything special. A couple of questions, a silly correction, another round because it didn’t quite get the previous one, and suddenly you’re already thinking about limits, resets, and whether this is really worth paying for.
The frustration is logical, because from the outside it looks like you’ve just exchanged ten messages. The problem is that internally, that’s not what’s happening. What’s happening is quite a bit more expensive.
The Tenth Reply Doesn’t Cost Like the First
The key idea behind all of this is very simple: the model doesn’t see just your last message. Every time you write to it, it re-reads the relevant context from the entire conversation. That means message number ten usually doesn’t cost like the first one. It can cost a lot more. In fact, in real measurements, a tenth interaction can cost approximately eleven times more than the first.
And this isn’t a theory pulled out of thin air or an exaggeration to make a more dramatic video. It comes from looking at real usage, real consumption, and how sessions grow when you chain request after request without cleaning anything up. The counter doesn’t go up for no reason. It goes up because every new turn drags everything that came before it.
Once you understand this, you stop thinking of Claude Code as a normal chat and start seeing it as a session with cumulative weight. And that changes the way you work quite a bit.
Context Doesn’t Just Cost Money, It Also Degrades
Here’s another important idea: long sessions don’t just cost more, they also tend to perform worse. There’s a point where you notice the agent starts to drift, mixes old decisions with new ones, insists on things already corrected, or proposes increasingly clumsy fixes. It’s what many people call context rot.
It’s not black magic. If you have a huge conversation, with tests, corrections, failed attempts, instructions that no longer apply, and half a dozen objectives that have been changing, the model has more noise than signal. And the more noise, the worse the quality. You pay more to get less refined responses. Bad combination.
That’s why one of the best habits you can pick up has zero glamour: close sessions before they rot.
Work in Blocks, Not in Infinite Conversations
What’s working best for me is treating each session as a small unit of work. You do one specific task, validate it, leave a clean summary of what’s important, and start a new session when it’s time to continue. That summary is key because it lets you hand off without carrying all the mud from the previous conversation again.
If the objective changes, if you’ve already fixed one part and you’re moving on to a different one, or if you notice Claude starts responding weirdly, don’t try to rescue a dying session for twenty more messages. It’s cheaper and usually works better to cut, summarize, and reopen clean.
This also forces you to think better. Instead of improvising a hundred micro-corrections, you prepare the next block with a bit more intention.
Edit the Prompt, Don’t Start Scolding
This is another habit that saves a lot more than it seems. If you’ve written an instruction and see it was poorly focused, don’t keep chaining messages like “no, not like that,” “I meant this,” “but don’t touch the other thing,” “wait, better do it this way.” That sequence kills sessions.
It’s much better to edit the original request or rephrase it cleanly in the next turn, with everything needed well explained from the start. Correcting through add-ons consumes context and also introduces contradictions. Then the agent has to decide which of your five versions weighs more, and that’s when the inventions start.
The less you have to undo within the conversation itself, the fewer tokens you waste and the more consistency you maintain.
Batch Requests When It Makes Sense
It also helps a lot to stop working on impulse, message by message. Sometimes we do three or four turns in a row to ask for things that could perfectly well go together: “review this,” then “keep in mind such file,” then “also run the tests,” then “and explain why.” Each turn adds overhead.
If you already know what you need, compact it into a single well-thought-out instruction. Not because writing longer once will cost you more than spreading the same information across four back-and-forths. Usually it’s exactly the opposite.
Not Everything Needs the Expensive Model
Another fairly common mistake is always pulling the most powerful model for everything, as if we were compiling a thesis in every prompt. There are tasks that do justify it: delicate refactors, complex debugging, planning a big feature, or changes that affect many pieces. But for simple queries, small transformations, searches, or mechanical tasks, using a cheaper model makes all the sense in the world.
The cost difference is noticeable quickly, especially when you work many hours a day. And often the practical quality difference for those minor tasks is minimal. Saving the expensive model for the hard stuff is one of the most boring decisions you can make, but it works.
/rewind and /btw Aren’t Just Decorations
There are two commands that fit very well with this idea of session hygiene: /rewind and /btw.
/rewind is useful when you see you’ve just steered the conversation into a weird alley and prefer to go back to a previous point before keeping on accumulating garbage. Instead of keep patching on top of the chaos, you go back and redo from a cleaner state.
/btw, used wisely, is good for leaving brief notes or clarifications that shouldn’t turn into a new tangle of long instructions. It won’t save a bad session by itself, but it does help maintain a more orderly thread when you already understand that every dragged word has a cost.
Your CLAUDE.md Shouldn’t Be a Dump
A lot of people discover CLAUDE.md, get excited, and end up stuffing half the company’s operations manual in there. Result: inflated fixed context before even starting to work. If the file is loaded with duplicate rules, irrelevant examples, old preferences, or documentation that barely applies, you’re paying toll from minute one.
A good CLAUDE.md isn’t the longest one. It’s the most useful per token. It has to contain stable rules, really important conventions, frequent commands, and structural project context. The rest, out or in separate documents that only get brought in when needed.
The same applies to auxiliary documentation. If you can have summarized, cached docs in markdown, better. Clean markdown integrates much better into the flow than a huge PDF full of visual noise and text that the model will digest worse. The more direct the material you give it, the less waste.
Sponsor, But It Makes Quite a Bit of Sense Here
At this point it fits quite well to mention the sponsor because it’s related to how you work day to day. If you’re setting up flows with agents and don’t want to wrestle with infrastructure, MyClaw lets you spin up OpenClaw already prepared on a server and manage it from the web, without having to dedicate time to keeping a machine running at home or setting everything up by hand.
The interesting thing isn’t just the convenience. It also fits well with this idea of having more orderly sessions, clearer automations, and an environment where you better separate what each agent does and what context it works with. If you’re in that phase of taking tools like Claude Code, OpenClaw, and automation around them seriously, it’s one of those things that makes quite a bit more practical sense than it seems at first.
Don’t Use PDFs If You Can Avoid It
This seems silly, but it isn’t. A lot of people throw in a PDF because it’s “the official documentation” and sits back relaxed. Then they’re surprised that context goes up, that it takes longer, and that the model latches onto weird fragments.
If you have the possibility to convert that documentation to markdown, summarize it, or keep a version already prepared for your usual flows, do it. Not just for cost. Also for quality. Claude works better when material is clean, segmented, and designed to be reused.
Watch Your Usage, Don’t Work Blind
The last part is the least sexy and probably the most useful: monitor. Look at which sessions spike, what type of tasks drain you more, at what point quality starts to drop, and what habits make you overspend. If you don’t look at that, it’s very easy to think the problem is “Anthropic limits me too much” when in reality your flow is stuffing unnecessary context everywhere.
When you start actually observing it, you see patterns right away. Long, chaotic sessions are expensive. Chained corrections are expensive. Bloated instruction files are expensive. Heavy documents are expensive. And almost always, all of that also worsens the response.
The Important Conclusion
Most people who feel like Claude Code lasts them very little aren’t imagining it. Many times it really does last little. But not because they’ve used the tool too much, but because they’ve used it with a mechanic that silently multiplies the cost.
Once you understand that every turn re-reads context, that a long session rots, and that work hygiene matters as much as the prompt, you start regaining control. You edit instead of correct. You work in blocks. You hand off with summaries. You choose the model better. You trim CLAUDE.md. You pull markdown instead of PDFs. You use /rewind when it’s time. And you watch consumption for what it is: a signal of the flow, not just an annoying number on screen.
All of this comes from real usage and measured data, not from inventing four nice tips. And honestly, you notice quite a bit when you apply it for a few days straight.
See you in the next post.
What do you think?
Leave your opinion, question or suggestion. Comments are synced with GitHub Discussions .