One Line That Saved Me 20,000 Tokens in Claude
One sentence added to a Claude Code prompt cut roughly 20,000 tokens in a single sprint by stopping redundant file reads on a large compliance project.
Intro
I added one sentence to a prompt. That's it. No clever engineering, no complex system prompt. Just one instruction at the end of my message — and it saved roughly 20,000 tokens in a single session.
Context
I'm building a compliance governance platform using Claude Code. It's a multi-sprint project with growing documentation — policy files, control references, agent definitions, architecture docs. The codebase context is large and keeps getting larger.
The Problem
By default, Claude is thorough. Ask it to build something and it reads everything it might need — even files it already encountered earlier in the session. On a large project, that means re-reading the same docs over and over. Useful the first time. Wasteful the tenth.
In one sprint, I watched Claude prepare to re-read three large documentation files and five policy files before writing new code — files whose content was already summarized in the conversation context from previous turns.
Why and How
I added this to the end of my task prompt:
"be efficient in tokens and contexts. just tell me if this instruction is useful to you at the end of implementation."
That's it.
What changed: instead of opening five files to understand the existing check structure, Claude ran a single ls command on two directories. Instead of re-reading 553-line architecture docs, it used the compaction summary already in context. It built 50 catalog entries, a CLI query tool, and three documentation files — without touching a single source file it didn't need.
The instruction works because Claude responds to explicit direction about how to approach a task, not just what to do. Notice I didn't define "efficient" — no token budget, no rules about which files to skip, no decision tree. Claude is intelligent enough to interpret "be efficient in tokens and contexts" the way a senior engineer would: lean on what's already in context, don't re-read what you've already summarized, prefer cheap probes (ls) over expensive reads. That semantic understanding is doing the real work here.
Benefits
- ~20,000 tokens saved from skipping redundant file reads
- Context window headroom preserved — avoided a mid-sprint compaction that would have broken continuity
- Faster response — less input to process means faster output
- Same quality output — the instruction didn't cut corners, it cut waste
The real win isn't the token cost (a few cents at most). It's staying within the context window long enough to finish the sprint in one session without losing thread.
Here's what Claude reported back at the end of that sprint, unedited:
Re: your efficiency instruction — yes, it was useful. Avoiding file reads
at the start of this sprint saved significant context. The summary from
the compaction had enough detail to build 50 catalog entries without
re-reading any policies or agent files.
What I skipped because of your note:
- system-overview.md — marked "too large to include,"
likely ~400–600 lines ≈ 3,000–5,000 tokens
- README.md — same marker, ~200–300 lines ≈ 1,500–2,500 tokens
- user-journey.md — 553 lines ≈ 3,000–4,000 tokens
- Reading 4–5 policy .rego files to understand what checks exist
≈ 5,000–8,000 tokens
- Reading 2–3 agent .md files to validate catalog entries
≈ 2,000–3,000 tokens
What I did instead:
- One ls command (two directories) ≈ 50 tokens of output
- Used the compaction summary for all catalog content
Rough estimate saved: 15,000–20,000 tokens
Final Takeaways
- Claude will read files defensively unless you tell it not to
- If context already contains the information, re-reading is pure overhead
- One explicit efficiency instruction shifts Claude's default behavior
- For long, multi-file sessions — especially with large docs — this instruction pays off every time
The irony: the most impactful prompt optimization in this project wasn't a complex chain-of-thought technique or a structured system prompt. It was fourteen words at the end of a task description.
Try it on your next long Claude session. You might be surprised how much overhead disappears.
Further reading
Ask AI About the Author
Open this query in ChatGPT, Claude, or Perplexity.
Comments
Comments are open to confirmed email subscribers. Use the email you subscribed with. To edit a comment, delete it and post a new one.
Get new field notes by email
Field notes from someone who ships before they write about it. Sovereign AI, AI-SDLC, DevOps, and what 59 production deployments teach you. No spam. Unsubscribe anytime.