We Tested 7 Claude Code Tips: Only Two Actually Save Usage

Claude Code "quota-saving" tips are widely circulated on video platforms, but most lack reproducible verification. One creator watched the 13 most popular tip videos and found that only 3 had run controlled experiments, and none scored results with hidden tests the model couldn't see. So he designed his own controlled experiment: 69 runs, with each tip applied and not applied to the same real task, at least 3 runs each, all using Opus 5.5 default settings, scored afterward by hidden checks the model never saw, with costs read at Claude Code's own list prices.

The conclusion is counterintuitive: of the seven tips, only two actually save usage, and the most hyped one turned out to be the most expensive.

Experimental Method: Hidden Scoring and Repeated Runs

Two things are key to this test. First, hidden checks: scoring happens after the task ends, and the model never sees the test content, avoiding the bias of "writing code for the exam." Second, repeated runs: the author notes about one-eighth variance across 9 identical runs without any tip, so any difference below that threshold is treated as noise. This provides a baseline for judging whether claims like "a tip is 5.5x more expensive" hold up.

Boundary conditions worth noting: the tasks are all short, single-model, single-codebase. The author himself admits that multi-hour long sessions might make compact or concise styles worthwhile again.

Held-out evaluation is a common practice in machine learning benchmarking: the test set is invisible to the model during training or inference and is used only for final scoring. The approach in this article is stricter — the checks were written separately by the author and the model never had access to them, so there is no possibility of the model "teaching to the test." This is fundamentally different from self-evaluation, where the model writes its own tests and then passes them, which tends to overestimate real capability.

Repeated runs and the noise baseline are equally critical. LLM output is stochastic, so the cost and results of the same prompt vary across runs. The author observed about one-eighth variance across 9 runs without any tip, so differences below that threshold are treated as noise, and only significantly larger differences are judged to be real effects. This is the precondition for determining whether conclusions like "5.5x more expensive" are reliable.

Subagents: The Biggest Counterexample to the Token-Saving Myth

The most widespread claim is "use subagents to save tokens" — each helper has a fresh memory, so in theory it burns fewer tokens. The author had Claude read 8 real code packages, comparing results with subagents on and off.

Subagents off: completed in 76 seconds, passing all 46 hidden checks. Subagents on: Claude launched 4 to 5 helpers per round, took 189 seconds, and also passed all 46. Average cost rose from $0.68 to $3.74 — 5.5x the usage, 2.5x the time, identical score. To rule out chance, the author ran a fourth time: $4.26.

More interestingly, Anthropic's own best-practices page has a "things you can stop doing" table, and "use subagents to protect the context window" is right there on it — because running out of context is rarely a real problem these days. Subagents still have value for parallel tasks, but treating them as a cost-saving measure is wrong.

Subagents refer to the main agent dispatching part of a task to independent model instances, each with its own context window and conversation history, which then report results back to the main agent. Their original purpose is parallelization and context isolation: multiple subtasks can proceed simultaneously, and their intermediate processes don't crowd the main agent's window.

But "independent context" does not mean "fewer tokens." Each subagent must reload the system prompt, tool definitions, and task background — that's duplicated overhead; the main agent also spends extra tokens splitting the task and reading and integrating each subagent's report. The more fragmented the subtasks and the more helpers, the higher the cost of reloading and aggregation. So subagents can buy wall-clock time on independent, parallelizable subtasks, but not necessarily savings on the bill.

Clearing Sessions: A Small Real Gain, But Don't Compact

"Use /clear or /compact between tasks" is another frequent recommendation. The author had Claude complete three tasks in sequence — feature development, bug fix, security fix: one long session cost $2; starting a new session per task (the effect of clear) cost $1.83, about 8% cheaper — modest but real.

The reverse backfires: compacting between tasks cost $2.34, 17% more than doing nothing. The reason is that compaction must first read the entire context pile before compressing, which is itself a large request. Anthropic's cost page agrees with both conclusions.

One small wrinkle: two of the fresh-session runs missed a security check. The author flags this as a caveat due to too few runs rather than a firm conclusion.

Models and Effort Levels: Split the Rule Apart

"Don't switch models mid-session, don't change effort level" is only half right. The author first completed a feature task, then asked a follow-up: same model and effort level, under $0.04; lowering the effort level, still under $0.04; switching mid-session to the smaller Sonnet model, about $0.11 — 2.9x the original.

The reason is that each model has its own cache, so switching models forces the entire conversation to be re-read. But adjusting Opus 5.5's effort level on a paid plan keeps the cache intact. So the right move is to keep "one model per session" and drop "don't touch effort level."

Concise Style: Fewer Words, Bigger Bill

One video claimed a certain "caveman style" cuts 65% of tokens. In testing, this style did write 12% fewer words, but the whole run was 12% more expensive; another concise style scored the same but cost 20% more.

The contradictory explanation lies in caching: both styles change the instructions Claude starts with, breaking the cache, so the first round writes about 16,000 tokens instead of 4,000. On short tasks, this kind of tip is a net loss.

Prompt caching is the key mechanism behind several of these conclusions. The server caches the fixed opening portion of a conversation (system instructions, tool definitions, message history), so subsequent requests only need to read the cache rather than reprocess and re-bill. Once that prefix changes — modifying the system prompt, switching models, compacting history — the cache is invalidated, and the whole segment must be reprocessed as new input.

This also explains why "writing less" can cost more: a concise style modifies the startup instructions, invalidating the cache from the first round, with first-round input jumping from about 4,000 tokens to about 16,000 — the saved output words are far from enough to offset that. Similarly, switching models mid-session creates separate caches, forcing the entire conversation to be re-read. The existence of caching means stability itself has a price.

Plan First, Then Act: Depends on Whether the Task Is Clear

On the same feature task, planning before building cost $0.81 and took 161 seconds; building directly cost $0.53 and took 107 seconds — both passed all 11 checks. Planning first was 54% more expensive with the same result.

But Anthropic's reason for planning first is to avoid rework after going in the wrong direction, and this task was completely unambiguous. So this one is "it depends": skip it when the task is clear, keep it when direction is unclear.

CLAUDE.md: Keep It, But Keep It Thin

The author planted a test rule in the rules file: "every new error reply must include a message." With no file at all, Claude missed this rule every time; a lean 31-line file, followed every time; a bloated 599-line file that buried the rule deep, also followed every time.

The file does work, but at a cost of $0.88 versus $0.59 — about half again as much to re-read every line. Anthropic's recommendation is to keep it under 200 lines. Conclusion: keep one, but keep it short.

Plugins and Add-ons: Check Slash Context Before Acting

"Turn off unused plugins" showed only an 18% difference in testing ($0.64 versus $0.54), right at the edge of noise. The old warning that "a certain add-on eats 26,000 tokens" is also outdated — full tool descriptions are now loaded only when needed.

The right approach is to run slash context first to see what's actually loaded before you speak, then decide whether to remove anything — rather than cleaning up blindly.

Slash context (type /context in Claude Code) is a diagnostic command that shows, before a real conversation begins, what the current session has already loaded and how many tokens each item takes — including the system prompt, CLAUDE.md, enabled plugins and tool descriptions, MCP servers, and so on.

Its value is making the "invisible fixed overhead" visible. Blindly disabling plugins may remove genuinely useful capabilities while saving only noise-level usage; checking context usage first lets you locate the real heavy hitters — a bloated rules file, say, or an extension that loads a large number of tool descriptions. Now that tool descriptions are loaded on demand, the old experience of "some add-on eats tens of thousands of tokens" no longer applies, and cleanup decisions should be based on measured data rather than hearsay.

Final Conclusions

Of the seven tips, only two actually save usage: /clear between tasks, and keeping CLAUDE.md lean. Two more are worth keeping: one model per session, and deciding whether to plan first as needed. Three should be skipped: subagents for token savings, compact, and concise style — with subagents the loudest failure case. Plugin cleanup is a case-by-case matter.

The value of this experiment isn't in giving ultimate answers, but in demonstrating a way to judge: any "quota-saving" tip should be verified with hidden tests and repeated runs, not forwarded on gut feeling.

One-line Summary

69 controlled runs show that of seven popular quota-saving tips, only two actually work.

Paragraph Summary

The author designed a reproducible controlled experiment for Claude Code quota-saving tips circulating on video platforms: 69 runs, each tip applied and not applied to the same real task, at least 3 runs each, all using Opus 5.5 default settings, scored uniformly by hidden checks the model never saw, with costs at list price. Results show only /clear between tasks and keeping CLAUDE.md lean actually save usage; one model per session and deciding planning as needed are worth keeping; subagents for token savings is the biggest misconception, at 5.5x cost for the same score; compacting between tasks and concise reply styles are more expensive; plugin cleanup is at the edge of noise and should follow a context check.