Agentic Coding Best Practices for Sane Token Costs

What are the best practices for keeping agentic coding cheap?

The single best practice for agentic coding is to control what the agent reads, because in a tool-using loop the input — not the output — is where your money goes. Everything else is downstream of that one idea. I build token tooling for a living, and I've watched the same mistake play out across every agent I've profiled: people obsess over writing the perfect prompt while the agent silently slurps a 4,000-line file, dumps a verbose test log into context, and then re-sends that entire transcript on the next turn, and the next, and the next. The prompt was never the problem. The context was. So this isn't a listicle of "prompt hacks." It's the set of habits that actually move the bill, ranked roughly by how much they save. If you want the broader picture first, the pillar is How to Reduce AI Coding Agent Token Usage.

Why does the agent loop cost so much in the first place?

Agentic coding costs add up because every turn re-sends the entire accumulated conversation as input, so context isn't a one-time cost — it's a recurring tax. A plain chat sends your prompt once. An agentic loop reads files, runs commands, observes output, and repeats — often dozens of times for one task. On turn 12, the model re-reads turns 1 through 11 as input. The files it opened on turn 2 are still riding along on turn 20. This is why a "quick fix" can quietly burn hundreds of thousands of input tokens: the context window only grows, and you pay for the whole thing every single step. The pricing makes the stakes concrete. On Claude Opus 4.8, input runs $5 per million tokens and output $25; Sonnet 4.6 is $3 / $15; Haiku 4.5 is $1 / $5; GPT-5.5 is $5 input / $30 output. Output is pricier per token, yes — but in a long agent loop you typically read far more than you write, so the input column is where the damage compounds.

Best practice 1: search semantically instead of reading whole files

The highest-leverage habit is to never let the agent read a file whole when it only needs one function. Whole-file reads are the biggest single source of wasted input tokens I see. The default agent behavior is brutally literal: it wants to understand auth.ts, so it reads all 1,200 lines, even though the bug lives in one 15-line handler. Multiply that across a debugging session and you've paid for thousands of lines the model glanced at and forgot. The fix is semantic code search — retrieving the relevant snippets by meaning rather than grepping or slurping files. Pull the three functions that actually matter, not the four files they live in. I wrote up the head-to-head in Semantic Search vs Grep; the short version is that grep finds string matches and semantic search finds concepts, and concepts are usually what you're debugging.

Best practice 2: filter command output before it hits the context

Always strip tool output down to its signal before the agent ingests it. A passing test suite, a successful npm install, a verbose build log — the agent does not need all 800 lines to learn "it worked." This is the most underrated lever, because the waste is invisible. You run the tests, they pass, you move on — and the agent quietly absorbed the full reporter output, then carried it forward on every subsequent turn. Output filtering collapses that to the one line that matters: pass/fail, the error, the diff. I broke down concrete examples in Output Filtering for Command Logs. A rule of thumb I use: if a human would skim a log and read one line, the agent should receive one line.

Best practice 3: keep your CLAUDE.md and rules files lean

Trim your project instruction files ruthlessly, because they're prepended to every request and you pay for them on every turn whether the agent uses them or not. CLAUDE.md, .cursorrules, and friends are persistent context. A bloated 600-line rules file that documents your entire architecture is 600 lines of tax on every single message — including the ones where the agent is just renaming a variable. I've seen instruction files larger than the code they describe. Cut them to the rules the agent actually needs to follow, and move reference material into files it can retrieve on demand. More on this failure mode in CLAUDE.md Token Bloat.

Best practice 4: load MCP tools lazily, not all at once

Don't register every MCP server you own on every session. Each tool definition is tokens in your context before the agent has done anything. MCP servers are wonderful, and that's exactly the trap — it's easy to wire up ten of them and never notice that their combined tool schemas are eating thousands of tokens off the top of every conversation. Lazy loading means the tool definitions only enter context when they're plausibly relevant. If you're choosing which servers to keep, I keep a running shortlist in Best MCP Servers for Claude Code.

Best practice 5: scope the task and let context compress

Give the agent a tightly scoped task and let long histories compress, because an unbounded objective produces an unbounded loop. "Fix the failing tests in the payments module" is a job. "Improve the codebase" is an invitation to read everything you own. The narrower the scope, the fewer files the agent touches and the shorter the loop runs. For long sessions that can't be avoided, context compression summarizes the early turns so the model keeps the conclusions without re-paying for the raw transcript. This is the discipline of context engineering: you are the editor of what the model sees.

Best practice 6: exploit prompt caching instead of fighting it

Structure your sessions so the stable parts of your context stay byte-for-byte identical, because cached input reads cost roughly 10% of normal input. Prompt caching is the one place the providers give you a real discount, and most people forfeit it by accident — they edit the system prompt mid-session, or shuffle the order of context, and bust the cache. Keep the stable prefix (your rules file, your system prompt, the project overview) constant and let the volatile part change at the end. A cache hit on Opus 4.8 turns that $5/MTok input into roughly $0.50/MTok for the cached span. That's not a rounding error; over a day of agentic work it's most of your bill.

How do I apply all this today?

Here's the order I'd actually do it in, fastest payback first:

Lean out your instruction files. Open CLAUDE.md / .cursorrules right now and cut anything the agent doesn't strictly need. Five minutes, recurring savings on every turn.
Trim your MCP servers. Disable the ones you're not using this session.
Stop reading files whole. Get into the habit of asking for the specific function, not the file.
Filter loud commands. Pipe verbose tools through something that returns the summary.
Scope tasks tightly. One job per request.
Protect your cache. Don't reorder or edit the stable prefix mid-session.
Measure. You can't fix what you don't see — instrument your token usage before and after.

Most of these are habits, which means they're easy to forget under deadline pressure. That's the honest reason I built Tokenade: it does the semantic search, output filtering, skeleton compression, and lazy MCP loading automatically, then shows you the savings on a dashboard so you're not guessing. It runs across Claude Code, Cursor, Codex, Copilot, Windsurf and the rest, it's source-available under MIT, and the free tier covers about 10M tokens a month — enough that you can verify the savings before you ever think about the $19.90/mo Pro plan.

What goes wrong: the anti-patterns

The failure modes are mostly the inverse of the practices above, but a few are worth calling out because they're easy to do while feeling productive.

Prompt-golfing while context bloats. Spending twenty minutes wordsmithing the prompt while the agent reads half the repo on turn one. The prompt is maybe 5% of the spend.
"Just to be safe" file reads. Telling the agent to read related files preemptively. It'll read them, forget most of it, and carry the rest as dead weight for the rest of the session.
Treating output tokens as the enemy. People cap max_tokens aggressively and feel thrifty, then wonder why the bill didn't move — because input was 80% of it the whole time. Check the token costs breakdown if you don't believe me.
Cache busting by habit. Editing the system prompt or reordering context mid-task, silently discarding the 90% discount.
No measurement. The most common one. If you're not counting tokens, you're flying blind; start with a token counter and the cost calculator to put real numbers on a task.

None of this requires a smaller model or a worse agent. It requires being deliberate about the one variable that actually scales your bill: what the model reads.

See also (hub-and-spoke):