Claude Code Quotas Not Enough? We Tested Which Tricks Actually Save Quota

Opening: Same Tasks, 16x Difference in Usage

Three related coding tasks, the same Claude Code, the same $20 plan. Running with Opus used 16% of the 5-hour quota; switching to Haiku used only about 1%. And all six tasks passed tests and browser checks.

This comparison comes from a hands-on test video. The author used three related tasks from a team chat app, placed in an empty folder, as a benchmark—changing only one variable each time, running each configuration twice, and reading the quota table before and after. Before giving conclusions, let's first clarify where the quota is actually spent.

The Real Composition of Quota Consumption

When running Opus, the quota table readings after the three tasks were 4%, 10%, and 16% respectively—each completed task increased consumption. The reason is straightforward: every message resends the entire conversation, so the longer the session, the more context is repeatedly read. The author observed that by the third task, over 90% of tokens were repeated reads of the conversation.

But cache reads themselves are cheap. Estimated at list prices, about half the cost comes from Claude's own output—code and explanations; about 30% of the thinking phase is spent writing to cache; repeated conversation reads account for less than one-fifth. This is calculated at list prices, not the plan's actual billing formula, but it explains most of the phenomena that follow.

There's also an important baseline: two Opus runs with no changes at all differed by 14 cents in cost and one point on the quota table. So the author only counted results where both runs exceeded this noise and the quota table was at least a quarter lower as real savings.

Context caching (prompt caching) is the key mechanism for understanding quota consumption. When Claude Code sends a request, the system caches the unchanging parts of the conversation (such as system prompts and historical messages), so subsequent requests only need to read the cache rather than reprocess all tokens. Reading the cache is much cheaper than writing to it—typically writing costs about 10 times more than reading. This is why "repeated conversation reads," despite the huge token volume, account for a small share of cost; and each time a new session is created or the conversation is compacted, the cache must be rebuilt, making the write cost a burden instead.

The effort parameter is a setting in Claude Code that controls how much reasoning effort the model invests. Lowering effort reduces the number of tokens the model generates during the thinking phase, thereby reducing output costs and response steps. Unlike switching models, it's a trade-off that adjusts computational resources within the same model—suitable for scenarios where you don't want to change models but want to save quota.

Two Things That Really Save Quota: Switching Models and Lowering Effort

Switching Models: The Gap Between Sonnet and Haiku

Sonnet cut list-price cost to less than a quarter of the original—53 and 47 cents for the two runs, compared to Opus's $2.12 and $2.26. Note that different models write different code; the author only verified that tasks passed tests and browser checks, not that code quality was equivalent.

Haiku goes further: 6 and 11 cents, about 1% of the quota table each time, all six tasks passed, and output volume was even about 10% more than Opus—just much cheaper per token. Claude Code's official documentation recommends Sonnet for most coding tasks and reserving Opus for difficult architecture and multi-step reasoning.

These three tasks are small in scale and clearly described—simple scenarios. The harder the task, the more carefully you need to evaluate the benefits of switching models.

The Claude model family currently mainly includes three tiers: Opus, Sonnet, and Haiku, positioned from high to low: Opus for complex architecture and multi-step reasoning, Sonnet balancing performance and cost, and Haiku focusing on lightweight speed. The API pricing differs significantly—Haiku's per-token price is typically only a few tenths of Opus's. In Claude Code, users can switch models via the /model command, and plan quota is converted based on actual tokens consumed and model unit prices, so switching to a lower-priced model can greatly extend plan usage time. However, note that model capability differences may affect code quality; differences are不明显 for simple tasks, but complex tasks require careful evaluation.

Lowering Effort: A Compromise for Staying on Opus

If you don't want to switch models, you can lower Opus's effort. The same three tasks used only 8% and 9% of the quota—roughly halved—and all six passed. Output volume nearly halved, with list-price cost at $1.11 for both runs. Opus also took fewer response steps—about 20 responses instead of around 40.

Models and effort can indeed directly move the quota table. But the more widely circulated token tricks target not the model but context management—and that's where the numbers start to reverse.

Four Context Tricks: Measured Savings Are Nearly Nonexistent

/clear: No Obvious Difference

The idea is to start a new session for each task so Claude no longer sends the old conversation, while code remains on disk. Measured usage was 19% and 16%, versus 16% and 17% for the control group—within noise, inconclusive. The reason is that each new session must rebuild the cache, and writing cache is much more expensive than reading it.

The author also acknowledges that the official documentation says to use /clear when switching to unrelated work, whereas this group of tasks is interrelated—a scenario the documentation doesn't promise.

Cache rebuild cost is key to understanding the /clear effect. Each time /clear starts a new session, Claude needs to rebuild the context cache, including system prompts and initial conversation. Writing cache is much more expensive than reading it, so even if the old conversation is no longer resent, the cost of building a new cache may offset or even exceed the saved read costs. In short sessions, this offset effect is especially pronounced; only when a session is extremely long and repeated read costs accumulate to a high level might /clear's savings become apparent.

/compact: Actually More Expensive

Instead of restarting the session, let Claude summarize the conversation and continue. After the first task, it compressed about 36,000 tokens to 5,000. The result was more expensive: quota table at 18% and 23%, list-price cost about a quarter higher. Each compaction is itself a request costing 7 to 10 cents, and after compaction Claude needs more steps to complete tasks. The documentation also hints at this: compact needs to read the entire conversation being summarized, and it's recommended to use it at natural breakpoints between tasks. The author's sessions were very short, far from hitting the context limit, so this trick had no room to work.

Plan Mode: Slightly Higher, and Completion Could Not Be Verified

Plan first, then approve, then execute. The author ran it keyboard-free: one call only plans, then in the same session lets it execute. Quota table at 17% and 20%—both slightly higher than without plan mode.

This test also exposed a problem: its browser checks couldn't drive the login page these runs built. All tests passed, and manual verification showed the app worked, but the author doesn't conclude whether plan mode actually completed the tasks. Plan mode's value lies in avoiding expensive rework after going in the wrong direction—and this group of tasks was clearly described, with almost no room for rework.

The Hook That Trims Test Output: Never Triggered Once

This is a hook from the same official documentation page, used to rewrite test commands so Claude only sees failures instead of a screen full of passing tests. Measured 17% and 15%, list-price cost the same as without it—within noise.

Further investigation found the reason: for NPM tests, this hook only modifies commands starting with npm test, and Claude never ran it that way—it always ran tests after type checks or directory changes, within longer commands, and had already trimmed output itself with tail and grep. Among 63 shell commands, the hook didn't modify a single one. So this trick isn't broken—it simply had no chance to take effect in this project. It might be useful in your project, but first confirm whether your test commands actually appear in that form.

Claude Code's hook mechanism allows users to insert custom scripts at specific events (such as before or after executing shell commands) to modify commands, filter output, or perform additional operations. The hook that trims test output typically rewrites commands by matching command prefixes (such as npm test) so Claude only sees failing cases. But if the actual command executed includes pipes, cd changes, or type-check prefixes, the hook's matching pattern won't hit, making it completely ineffective. Therefore, before using such hooks, confirm whether your test commands strictly match the rules, or adjust the hook's regular expressions to cover the actual invocation forms.

Conclusions and Applicable Boundaries

In this hands-on test, only two things could stretch the $20 plan: switching models (Sonnet or Haiku) or lowering effort. The same three tasks cost less than half, and every task passed checks. The four context tricks—/clear, /compact, plan mode, and the trimming hook—showed no measurable savings, with /compact actually being more expensive.

The author repeatedly emphasized the boundaries: the three tasks are very short work, and in short sessions the bulk of the bill is Claude's own output, so models and effort have the greatest impact. Long sessions flip this conclusion. In an earlier test, Claude Code handled a 12-task app and was stopped by the plan at the 7th task; by the 6th task, about 70% of the cost was already repeated conversation reads. In that scenario /clear might make sense—but this hasn't been measured.

If you're stuck on quota, prioritize switching models or lowering effort; judge context tricks based on your own session length and command forms—don't copy them blindly.