A token-efficiency checklist for Claude Code landed in my downloads folder. Sensible structure, mostly correct, the kind of thing that gets pasted into team wikis. I verified it against the installed binary instead of reading it. Four items were wrong, one of them in a way that can quietly revert your code.
A token-efficiency checklist for Claude Code landed in my downloads folder last week. Twenty-odd bullets, sensible structure, no obvious nonsense. It was the kind of document that circulates in operator communities, gets pasted into a team wiki, and is still being followed eighteen months later.
Most of it was right.
I checked it against the installed binary rather than reading it, and four items were wrong. One of them was wrong in a way that can quietly revert work you meant to keep.
This post is the corrections, the method I used to find them, and the reason the method matters more than the corrections do.
Verified against Claude Code 2.1.245 on 26 August 2026, on macOS via a Homebrew install. Claude Code ships continuously, so every version-specific claim below has a shelf life. The method for re-checking any of it against your own version is in the post, which is the part intended to outlast the findings.
Why advice about AI tools rots faster than other advice
Claude Code ships continuously. The version on my machine while writing this was 2.1.245. By the time you read this it will not be.
Most guidance about it is written from memory, or from another guide that was written from memory. That is not laziness. It is the normal way technical advice gets made, and it works fine for tools that change once a year.
It fails here for a specific reason: the failure mode is not obvious wrongness. Nobody circulates a checklist claiming a command exists when it does not. What circulates is advice that is directionally sensible, was accurate at some point, and is now subtly incomplete. It reads as correct because it is mostly correct. That is exactly the profile of advice nobody re-checks.
The method
You do not need to reverse-engineer anything. The user-facing strings are in the binary, and the ones worth grepping are the error messages and menu labels, because those are written to be read by you.
which claude
claude --versionB=$(readlink -f $(which claude))
strings -a "$B" | grep -F "Rewind" | cut -c1-300On a Homebrew install that resolves to /opt/homebrew/lib/node_modules/@anthropic-ai/claude-code/bin/claude.exe.
The honest limitations, because this is a heuristic and not documentation:
- The bundle is minified. Variable names are meaningless and control flow is unreadable.
- The presence of a string is not proof that a feature behaves as the string implies.
- The absence of any matching user-facing string is strong evidence that a described feature does not exist in the form described.
- Some behaviour is not represented in strings at all, so this method cannot confirm it either way. I hit that below, and said so rather than filling the gap.
That is enough to check whether a command exists, what options it presents, and what it tells you when it refuses.
Correction 1: /rewind is not conversation-only
The guide said to use /rewind when recent turns went off course, to remove the bad branch while keeping the useful earlier context.
The binary offers three options:
Restore conversation
Restore code
Restore code and conversationTwo of the three revert files to a checkpoint. /rewind is a code checkpoint system as much as a conversation one.
Advice that says “rewind to drop the bad turns” without naming the mode is one careless selection away from undoing an afternoon of edits that were fine. The correct instruction is to choose Restore conversation unless you specifically want the file changes reverted too.
This is the item that made me write the post. Every other correction costs tokens. This one costs work.
Correction 2: fast mode is not a token lever
The guide said to enable fast mode only at the beginning, because changing it during a session can disrupt prompt caching.
The caching half is right, and it generalises further than the guide takes it. Changing model or effort mid-session invalidates the cached prompt prefix as well, which means the next request re-reads the entire conversation at full price rather than at cache rates. That is the rule worth writing down, and fast mode is only one instance of it.
But fast mode itself does not belong in a token-efficiency guide. Anthropic describes it as faster output on the same model rather than a downgrade to a smaller one, which makes it a latency setting. The binary labels it “Fast mode (research preview)”, which is worth knowing separately.
I want to be precise about the boundary here: I verified the label and the toggle by grep. I did not verify the model-routing behaviour that way, because it is not represented in any string I could find. That claim rests on Anthropic’s own description of the feature, not on my check. Saying which of your claims survived verification and which did not is the entire point of doing the verification.
Correction 3: the thinking-tokens exception is the wrong shape
The guide recommended MAX_THINKING_TOKENS=0 for mechanical work, with a single named model as the exception.
The real constraint is broader, and Claude Code states it plainly when it refuses:
Effort ‘X’ isn’t available with thinking turned off on this model · run /effort high to continue, or turn thinking back on (unset MAX_THINKING_TOKENS=0)
So the exception is not one model. It is a combination of model and effort level. And because the same guide separately recommended setting a low /effort for mechanical work, two of its bullets could combine into a request that fails outright.
That is a useful category of error to notice: not a wrong fact, but two right-looking facts that were never tested together.
Correction 4: precise numbers that were never measured
The guide stated that context degradation “commences around 30% and can become a real issue after about 50%”.
There is no published figure behind those numbers. The underlying heuristic is reasonable, and matches what most people observe: quality tends to slip somewhere past a third of the window and becomes hard to ignore past half.
Stating it to the percentage point is the problem. A number carries an implied provenance. Once it is written as 30%, it gets quoted as 30%, and three documents later nobody can find where it came from because there was never anywhere for it to come from. Label heuristics as heuristics and they stay useful. Dress them as measurements and they become folklore.
What was missing mattered more than what was wrong
The corrections were the interesting part to find. The gaps were the more expensive part.
There was no measurement step anywhere. Twenty bullets of optimisation and nothing telling you to check whether any of it worked. /usage, /cost and /context exist for this. A guide with no feedback loop is a set of beliefs.
Auto-compact was never mentioned. It is on by default and its window is configurable via --autocompact or the config dialog. That changes the framing of manual compaction entirely: you are not avoiding a cost, you are choosing what survives.
MCP tool results persist, not just tool definitions. Claude Code says this itself when a result is large:
MCP tool results stay in context for the rest of the session. /compact to flush them, or disable servers you don’t need.
That is a stronger argument for pruning unused servers than the one the guide made.
Images are permanent and expensive. Screenshots cost thousands of tokens each and only leave via /compact or /clear. Nothing in the guide covered them.
Hooks inject tokens on every prompt. A UserPromptSubmit hook is a recurring tax that never appears in CLAUDE.md, so “keep your instructions lean” does not catch it.
The part with a shelf life, and the part without
Every specific correction above expires. Some already will have. The version number in this post is a decay date, not a credential.
The method does not expire, and it is not really about Claude Code:
Any document describing a tool that ships weekly is a depreciating asset from the day it is written.
That has an operational consequence most teams have not absorbed. Internal SOPs, onboarding docs, and the prompt libraries pasted into team wikis are usually treated as finished once approved. For anything touching AI tooling, “approved” now has a half-life measured in weeks. The document that was carefully reviewed in March is not neutral by August. It is actively teaching people something that used to be true, with all the authority of having been reviewed.
The fix is not to write fewer documents. It is to make verification a step that happens on a schedule rather than a virtue that happens when someone feels suspicious. Check the tool, not the tutorial. Record what you checked it against, so the next person knows what your claims are worth and when they stopped being worth it.
Four wrong items out of twenty is not a bad guide. It is a normal one. That is the uncomfortable part.
The review discipline behind this post is packaged as The Ship Gate, a set of Claude Code skills for the part that happens after something is built and before it goes out, including an eight-dimension review that cannot contradict itself. The other AI-operator packs are on the products page.
Disclaimer: This article is general information for operators running Claude Code and does not constitute professional, technical, or business advice. All tool behaviour described was verified against Claude Code 2.1.245 on 26 August 2026 and is accurate only as at that version and date. Claude Code is updated frequently and its behaviour may change without notice. Verify against your own installed version before relying on anything here, particularly any command that can modify or revert files. GrokoryAI builds AI and automation systems for Australian businesses.
