How I Cut My Claude Code Token Usage by 70% (and Got Better Output)

A few months ago I was burning through my Claude Code usage before lunch. Every session felt the same: I'd describe a bug or a feature conversationally, Claude would go read half the codebase to figure out what I meant, guess at the fix, get it half right, and then I'd spend three more messages correcting course. More tokens, more time, worse code. I fixed it — and the fix had almost nothing to do with "prompting tricks." It came down to changing when I write the prompt and how much thinking I front-load into it, instead of leaving that thinking for Claude to do live, in the loop, on my token budget. Here's exactly what changed. The real problem wasn't Claude — it was conversational implementation When you talk to an agent conversationally ("hey can you fix the auth bug"), the agent has to do three expensive things before it writes a single line: Figure out what you actually mean Explore the codebase to find the relevant files Guess at your constraints — what NOT to touch, what "done" looks like All three of those cost tokens, and all three happen inside the paid session, often more than once, because the first guess is rarely right. Every round of "no, not that file" or "don't refactor the other function" is a full context reload. The fix is to stop letting the agent discover your intent live. Do that work once, up front, outside the session, and hand it over as a single structured spec. What I changed: master prompts instead of conversation Now, before I open Claude Code, I write what I've started calling a master prompt. It's a plain-text spec I write myself (sometimes with Claude's help in a separate, cheap planning pass), and it always has the same shape: 1. Role / Context A tight paragraph telling the agent what kind of engineer it's acting as and what the codebase actually is — not a generic "you are a helpful assistant," but the specific stack, the specific constraints. 2. Do-Not-Touch list This one alone probably accounts for a big chunk of the savings. Explicitly listing files, patterns, or areas that are off-limits stops the agent from "helpfully" wandering into adjacent code, re-reading it, and re-reasoning about whether to change it. 3. Phase 0: Discovery Instead of letting the agent explore ad hoc, I give it exact grep/bash commands to run first, targeted at exactly the files that matter. Discovery still happens — it just happens efficiently, against a map I already know is correct, instead of a blind crawl. 4. Numbered issues with before/after expectations Each task is a numbered item with a concrete before-state and after-state. No ambiguity to resolve mid-session, no "wait, what did you mean by fix this." 5. Acceptance criteria A checklist the agent verifies itself against before declaring done — including real browser verification where relevant, not just "the code compiles so it must be right." I paste this whole thing in as one message, as plain text (never as a markdown file the agent has to open and re-read) — Claude Code, or Cursor, executes in agent mode against it in one continuous run. The rules I enforce on every single prompt Three habits, repeated on every task, are doing most of the heavy lifting: Discovery before code. The agent maps the actual codebase against my Phase 0 commands before writing anything, so it isn't hallucinating structure. Real verification, not assumed verification. If it's a UI change, it checks in an actual browser. If it's an API, it hits the actual endpoint. Assumed success is where silent rework and follow-up sessions come from. One commit per concern. Bundling five fixes into one giant diff means the agent has to hold five contexts in its head simultaneously, and so do I when reviewing. Splitting it forces smaller, self-contained context windows per unit of work. Why this actually cuts tokens (not just "feels tidier") The token savings aren't from writing less — the master prompt is often longer than my old one-line asks. They're from writing it once: No exploratory back-and-forth burning turns on "what did you mean" No wandering into files outside scope, reading them, then discarding that context No re-explaining constraints three messages in because the agent drifted No redoing work because "done" was never actually defined Every one of those failure modes multiplies your context size every single time it happens, because the whole conversation history rides along with each new turn. A tight, unambiguous prompt is a shorter total conversation, even though the first message is bigger. That's where the 70% came from in my own usage — it wasn't one trick, it was removing the entire class of clarification loops that conversational prompting invites. What this looks like in practice If you want the actual templates — the exact Do-Not-Touch structure, the Phase 0 discovery commands I reuse across projects, the acceptance criteria checklist format, and the broader system I use for running Claude Code like a real engineering workflow instead of a chat window — I wrote all of it up in The Claude Blueprint: Master AI Workflows Like a Pro. It's the workflow this whole post is describing, just with the actual prompt templates included so you don't have to reverse-engineer them. The short version If your Claude Code sessions feel expensive and unpredictable, the problem usually isn't the model — it's that you're asking it to think and discover live, on the clock, instead of handing it a spec you already thought through. Move the thinking earlier. Give it boundaries before it starts, not corrections after. The tokens you save aren't from saying less — they're from never having to say it twice.