Stop Hitting Claude Code Usage Limits (What Actually Works)

0:09 14% or 28,000 tokens of my Claude code context window is already in use before I even send a single message. This number might be more or less in your case, but I'm pretty sure it is significant. And most of the popular advice for reducing that number is either outdated or just doesn't work the way people claim it does. I have been using Claude for almost a year now and hitting the usage limit is a still one of the most frustrating messages I see on the screen. So, I spent a lot of time testing every popular Claude code optimization tip I could find. I ran each one against {slash} context measurements in my daily workflow, and I cross-referenced every claim with the official Anthropic documentation, their engineering blog, and even the GitHub issue tracker for Claude code. Over time, I built a set of habits around the methods that actually work and significantly reduce how often I hit usage limits during normal tasks. And more importantly, cut a lot of cost in heavier client projects when Claude code is connected to a credit card for extra usage.

1:04 At this point, I can confidently say that some of the advice circulating right now actually are not helpful. Today, I'm going to show you all these methods, and we'll go through each tip live in a real repo with before and after numbers on screen so you can clearly see what each method actually does. Now, this video is focused on advanced practical tips. So, if you're just casually coding with Claude code and usage limit is not really a concern, you might want to skip the video. But if you stick around, by the end of this video, you will have a clear list of strategies that genuinely reduce context usage, a solid understanding of which popular tips to ignore and why, and a simple method to verify any future Claude code advice before you add it to your setup. This video is a structured in three sections: what works, what partially works, and what doesn't. Let's start with the first section. One thing to be clear about up front, the goal here is not to minimum tokens, but my goal in this video is to show you how to minimum base. Cutting valuable context to save a few thousand tokens makes Cloud worse at understanding your codebase, not better. We are cutting redundancy and noise, not memory and reasoning. Now, let's go through the methods that have real impact. The first one, and also the simplest one, is a slash clear. So, when you finish your task and you want to switch to an unrelated task, in case you want to stay in the same session, run a slash clear.

2:18 So, here I have a session already open, as you can see, 60.62.7 thousand tokens are already in use, or 31% of my context window. So, let's run slash clear and let's see what happens. Let's run context again. Perfect. So, if I scroll back, now we have 28.2 thousand tokens in our context window, or 14%. If you compare this list with the previous one, you can see that here messages contains 37.5 thousand tokens, or 18%, or 18.7% of our context window, and here it only contains 110 tokens. So, a slash clear keeps everything the same, except it clears messages for you. And the reason this is important is not just the savings in token usage. When you keep working in the same session across unrelated tasks, you are also breaking the prompt cache that Cloud Code maintains in the background. A clean session also gives you a clean cache for the new task. So, with the simple rule, both your token count and your latency improve. A slash clear is the right tool when you are switching tasks, but sometimes you are deep into one task, you have built up real context, and you just need more headroom to keep going. That's where a slash compact comes in. As the name suggests, it forces Cloud Code to summarize the chat history and only keep the important things for you. Let's see it together. So, here I have a different session with 68% of my context window already taken. Let's run slash compact and see what happens.

4:00 >> It took 2 minutes and 10 seconds to compact the conversation history. And if I run context again, let's see it here. So, now it is 43.8 thousand tokens or 22% of the context window. Let's compare the two lists together again. So, here we have 118.9 thousand tokens in our messages. It was near 60% of our context window. And if I scroll down, we have 15.7 thousand tokens in our messages, near 8% of our context window.

4:37 So, the key difference is that Claude didn't forget what you were doing. It is just working from a summary of the conversation instead of every individual message. Use a {slash} clear when the next task is unrelated, and use a {slash} compact when you want to keep going without losing the thread. Now, the next method. Claude that MD gets loaded into every single message in our session. So, whatever you put in here, you are paying for it on every turn. The pattern that genuinely helps is keeping the root Claude that MD lean and pointing to reference files for the detailed info. Or, similar to what I showed you in my previous video, break it down into hierarchical format. Let's see three different strategies for preparing your Claude that MD. The first strategy is to have a comprehensive Claude that MD file in the root directory of your project, just like this one. This file right now contains all the testing guidelines, the deployment guidelines, and so on. And this is just redundant. So, for example, here I have 932 lines of information that Claude will will read in every session that I want to interact with it.

5:38 So, let's run context here. So, right now, in a fresh session, I have 28,000 tokens in my context window. A better strategy is instead of putting your full API conventions, your full testing rules, and your full deployment guide, and whatever else you need Cloud Code to be aware of directly into cloud.md, you put one-line pointers, and Cloud reads those reference files only when the task actually needs them. Let me show you an example here. So, for example, here I have my cloud.md file. As you can see, it is much shorter than the previous one. It has only 50 54 lines of information. But, here I added three references to API standards, testing rules, and deployment guide. So, whenever Cloud needs any information from those files, it can open the corresponding markdown file, and it can read that information. So, with this strategy, you will keep your cloud.md lean, and therefore you're going to have a clean context window.

6:41 The third strategy, which I showed in my previous video, is to have hierarchical cloud.md files. Here's the cloud.md file that I created in the root directory of my project in the previous video. As you can see, this has 13 39 lines of information. And this only contains a high-level overview of the repository. And I also created a cloud.md file inside the specific project that I was migrating, which is this one. And this one has 83 lines in it. And I explained that whenever we are opening the repository and we open a new session, Cloud immediately sees this file. It was in the root directory, of course. Cloud immediately sees the very lean version of cloud.md file that we created. And whenever I want to work on this specific project, Cloud will also pick up the information from this file. So, this is the hierarchical format that I explained in the previous video. But, for this video, since we already saw {slash} context on this version of our Cloud, let me copy everything, remove this one, and paste everything in our root directory.

7:51 Let's see the difference in context here. So, before we had 28,000 tokens inside our context window. The pre-populated token inside our context window. With this format, we have near 21,000 tokens in our context window. So, always make sure to have a link cloud.md file that contains the information that is actually needed for every single session. And distribute everything else across relevant documents and allow cloud to pick them up whenever it needs their info. The next method is about choosing the right model for the right task. The model you pick has a much bigger effect on your usage than most settings. Sonnet handles most coding work well. Haiku is significantly cheaper and the right choice for simple lookups and formatting tasks. And I would use Opus for heavy lifting. For example, for hard architectural decisions and complex execution planning, where you need the deepest reasoning. The mistake I see most often is people defaulting to Opus for everything. I know it's tempting, and I also know that Boris Cherny, the creator of Claude Claude, recommends Opus with thinking mode for every task.

8:59 His reasoning is that Opus needs less of steering and uses fewer tokens per task. He's not wrong, but the math is also important. Sonnet is $3 per million input tokens versus five for Opus with the same ratio on output. For daily coding work, where the quality gap is a small, those savings compound fast. If you have seen my previous video, I was on Sonnet the whole time, and that is why a 2-hour heavy-duty session didn't destroy my limit. Plus, I used plan mode before executing the task, broke down cloud.md file right from the beginning, and made sure to use the slash clear between separate tasks.

9:35 Because combining all these methods is what gives you the most powerful result. Speaking of plan mode, the next method that does not show up directly in a {slash} context, but saves a lot of tokens across a session is using plan mode. Plan mode prevents the most expensive mistake in Claude code, which is letting it confidently go down the wrong path. Imagine it writes 200 lines of generated code that you have to throw away because it misunderstood the task.

9:58 Plan mode forces Claude to lay out the approach first and ask clarifying questions before it writes anything. The next method is the proper use of a {slash} rewind. When Claude gets something wrong, your instinct is to send a follow-up message and correct it. Don't. Every correction message gets added to your conversation history permanently. So, if you do that, now you have a bad prompt, the bad response, your correction, the new response, and all of that compounds on every future message in that session. The better way is to use a {slash} rewind.

10:25 You can rewind to any previous point in the conversation. Therefore, you can remove the bad exchange. You reprompt with a cleaner instruction and you get a fresh response for that. So, cache and memory will not be polluted anymore. Now, we get to the things that work, but are oversold. The first one is the auto compact override. The advice is to set it to 75, so compaction triggers earlier and you get cleaner context. The setting is a real and it works. One thing that many people miss is that this goes inside the end block, not as a top-level key. If you put it as a top-level key, the schema rejects it.

10:59 Two more caveats. First is that this setting is different from auto compact window. They're separate settings doing separate things. One is a percentage threshold, the other is an absolute token window. Some advice claim that they are the same or one was renamed to the other, but that is not correct. Both exist and they do different things. The second note is that there is some confusion in the community about what the default value actually is. Anthropic's documentation says compaction fires at around 95%.

11:28 But if you trace the actual code, the real ceiling is closer to 83%. That gap is why different sources quote different numbers. Either way, the important part is that the override only works in one direction. You can lower the threshold, so compaction fires earlier, but you cannot raise it above the code ceiling. So, even if you set it to 95, the system will clamp you back down to around 83. Now, the reason this is in the partially works section and not in what actually works in our video is that lowering this number means Claude is going to compact your conversation earlier, which means it has shorter memory across your session.

12:08 For long, complex tasks where you need consistency across many steps, that can hurt performance, not help it. Look at the open GitHub issues on this. The community is genuinely split. Some users want it to fire earlier. Other users, especially those on larger Opus 1 million context window, are angry that compaction fires too aggressively and wipes out context they wanted to keep. So, if you set the override, set it because you want contraction earlier than the default, not because you trust a specific number being quoted to you.

12:39 The second over sold method is the bash output length setting. The advice you see is to bump it up, so Claude does not have to retry commands that produce long output. The setting is real, and bumping it up does help with retries. One thing to flag, the unit is characters, not tokens. So, any advice that tells you, for example, to set it to 150,000 tokens is confusing the two. The other thing that many advisers skip is the trade-off. If you let the bash tool capture more output, you're also letting more output into your context window if a command is genuinely verbose. So, you are saving retry tokens at the cost of carrying more output. So, worth bumping up if your workflow has noisy built tools, but I wouldn't bump it up just because someone said it's going to save tokens. The third method that I want to discuss in this section is adding deny rules to your settings.json so Cloud cannot read node modules, log files, build artifacts, and so on. This is a good practice and you should do it. The reason it is in this section and not the previous one is that deny rules do not shrink your starting context. They prevent Cloud from reading certain things during a task, which is a hygiene win.

13:49 But, if you run {slash} context in a fresh session before and after adding deny rules, the number is identical. So, do it for the right reason, which is mainly about scope and security, not about your starting baseline. Now, we get to the claims that do not work in current state of the Cloud Code. The first claim is that you should disconnect unused MCP servers to save tokens. The reasoning behind it is that each MCP server supposedly dumps 18,000 tokens of tool definitions into your context on every message. This was true historically. It is not true anymore.

14:21 Tool search shipped in January 2026 and is now on by default. Only tool names loaded at session start. The full schema is loaded on demand when Cloud actually needs them. Disconnecting servers does not change that anymore. Let's see together in my current session. Here, I have an active session and if I run {slash} context, you can see the list of the MCP tools that are available to Cloud Code. And here, it clearly says loaded on demand.

14:47 Let's deactivate the MCP server. So, if I run MCP, these are the MCP servers. Let's disable them. Okay, and let's run {slash} context one more time. The first thing that you will notice is that the list disappeared and that was expected. So, Cloud Code does not have access to any more MCP tools. And if you check these numbers, all of them are identical with the {slash} context in the previous execution. So, one thing for sure, removing the MCP servers did not help us to save tokens.

15:28 So, next time you see an advice telling you to disconnect MCP servers to save context, check your own output. If it says loaded on demand, disconnecting them does not help. That advice is outdated. Second claim is the 40% token savings from replacing MCPs with CLIs. This number is real, but it's not about CLIs. The 40% figure originally comes from a tool called Cloud context, which is a semantic code search made by Zilis. It uses vector retrieval instead of dumping entire files into context. That is where the 40% comes from. It has nothing to do with CLIs versus MCP. Now, are CLIs useful? Yes, in some cases. A CLI invocation only consumes tokens when it's actually called. But, there is no published benchmark for CLI versus MCP gap, and after tool search shipped, the gap got significantly smaller. So, overall, this optimization advice is not correct. Third claim is that the 30th message in a session costs 31 times more than the first one.

16:28 This advice ignores prompt caching entirely. Let's check Anthropic stocks. Cloud code automatically optimizes costs through prompt caching. Anthropic's own engineering blog has a post titled Prompt caching is everything that explains they treat cache hit rate as if it were up 10. So, yes, later messages cost more than the first one because the conversation history grows, but the multiplier is much smaller than 31 times. And this is also why some of the habits I mentioned earlier are important. Things like not switching models mid-session and not swapping tools mid-session. Those break the cache, and they cost you a lot more than people realize. So, that's what works, what partially works, and what doesn't.

17:10 The most important takeaway from this video is to turn best practices into habits. You should also know how to verify any fix you come across in the future, including the ones in this video. Whatever you heard and saw here, test it, verify it, and then add it to your workflow.