How To Reduce Token Costs of AI Coding Agents
Costs related to AI coding tools are projected to only go up from what they are today. We’ve seen this before with Anthropic adding weekly rate limits on top of Claude Pro and Max’s existing five-hour windows, with little warning. So the question on everyone’s minds these days is how do you get more work out of the same AI budget.
One answer is you have your AI agents burn less tokens. But token burn isn’t one problem. An agent stuck looping on a bug it can’t see and an agent reloading the same instructions on every single prompt look identical on your bill: a long session, a high token count. But the causes are completely different, and so are the fixes.
In this post, we’ll go through five specific ways this happens:
- Agents reading half your repo to change three files
- Agents doing mechanical work on your most expensive model
- Agents guessing at what a live dependency looks like, or trusting a mock that drifted away from it
- Agents looping without any way to tell if their fix actually worked
- Agents loading instructions on every prompt instead of only when needed
For #3 and #4 we’ll show how mirrord, our Kubernetes development platform, closes the gap: it connects code to a real cluster without deploying it, whether that code runs on a laptop, in CI, or in an agent’s sandbox.
Reading half the repo to change three files
Point an agent at a large codebase with a vague instruction and it will go exploring, and that exploration is usually the single largest line item in a session: file after file pulled into context, most of which never ends up informing the change. What makes it expensive isn’t the reading itself so much as the compounding, because a file read on turn three is still being re-sent on turn forty.
The easiest fix to this is just being specific in your prompts. If you already know the change lives in three files, just say so. If the search genuinely is the task, hand it to a subagent, which does the fan-out reading and returns a conclusion, so the forty files it opened never enter your main context at all. And when you move on to something unrelated, start a fresh session rather than continuing the old one, because a long-running session carries its full history into every new request whether or not any of it is still relevant.
Paying premium model rates for mechanical work
Not every task needs your best model. Renaming a symbol across a repo, writing a migration from a schema you’ve already specified, reformatting test fixtures, drafting a commit message: these are all mechanical, and a smaller model does them at a fraction of the cost.
The mistake is treating model choice as a per-project setting rather than a per-task one. Reach for the expensive model when the work is genuinely architectural, when you’re debugging something subtle or designing an interface or deciding how a change should be structured, and drop down for everything downstream of that decision. Most agent tools let you switch mid-session, and most people never utilize that.
Guessing at environment shape vs. reading it live
An AI agent writing code for a microservice doesn’t get to see the cluster where the entire application is deployed. It only sees your repo, whatever context you gave it, and patterns from its training data, and it fills every other gap with an assumption: what response a downstream service returns, what a queue message actually looks like, what a config value resolves to once it’s deployed. Some of those assumptions are wrong, and the agent has no way to know which ones until the code runs against the real thing.
Say you ask an agent to add a consumer for order events, and it writes the handler expecting a flat total_cents field, because that’s what the schema doc in the repo still says. In staging, that event has looked like {"pricing": {"total": ...}} for the last two months, ever since a migration that never made it back into the docs. The agent doesn’t find out until it runs the code and the field comes back None, and at that point fixing it means re-deriving the real shape from the failure and rewriting the parsing logic from scratch. Every downstream call, config value, queue, or database the code touches carries the same risk, and each wrong guess costs a whole new bag of tokens.
The usual answer to this is a mock, and mocks make it worse rather than better, because now the agent isn’t missing information, it’s being handed information that’s confidently wrong. A mock is a snapshot of what a dependency looked like the day someone created it, and nothing keeps that snapshot in sync automatically, so the gap only ever grows. Say the real order queue gains a required currency field, and the agent knows about it from a recent PR, so it writes a consumer that correctly expects the field. Locally it fails, because the mock is still emitting the old shape. The agent has no way to know the mock is the outdated one, so it assumes its own code is wrong and starts “fixing” it, loosening the field to optional, adding fallback logic, trying variation after variation, none of which touch the actual bug because there isn’t one. The bug is the mock. The agent just burned a dozen turns proving that correct code doesn’t satisfy an incorrect test.
The fix for both is to stop guessing. With mirrord connected to your cluster, an agent can read the real shape of a dependency before it writes a single line: what’s actually on the queue right now, what a service returns today, or what a ConfigMap resolves to in the running pod. That collapses the guess-then-fail-then-regenerate cycle most AI-generated code goes through into just one or two passes, because the first draft is already written against what’s true instead of what’s assumed. And there’s no need to maintain mocks that drift, because you can get a response from the dependencies running in the cluster directly.
No integration feedback
Without a way to verify its own work, an agent can make a change, declare it done, and open a PR with a bug baked in that only shows up once the code touches the real dependencies in the cluster. Nobody catches it at write time. It gets caught in review instead after a CI run or a staging deploy, which means going back, explaining what’s actually wrong, and waiting on another round of fixes, and possibly another after that if the first fix is incomplete. Every one of those review-fix-review rounds costs tokens the agent wouldn’t have spent if it had caught the bug itself the moment it introduced it.
Give the agent the same tests your team already runs in CI, but let it run them itself, against a real environment, right after it makes a change. Then it catches that kind of bug in the same turn it introduced it, not two review cycles later. We’ve walked through exactly this kind of case in detail in our previous blog How to prevent token burn using mirrord with e2e tests.
Context loaded on every prompt vs. on-demand skills
Most AI coding agents support an instructions file like AGENTS.md or CLAUDE.md that the agent reads in full on every single prompt in a session. It’s the simplest way to tell an agent “always do X, never do Y,” but that simplicity has a cost baked in. The file loads regardless of whether the current prompt has anything to do with it. If you’ve added a paragraph asking the agent to use mirrord to verify its code, one about your auth conventions, one about deployment rules, the agent is now paying to re-read all three on every request, including one that touches none of them.
Agent Skills fix this by making the loading conditional. Each skill ships as its own file with its own description, and the model only pulls it into context when a prompt actually matches what that skill covers. We packaged mirrord’s own instructions this way: six Agent Skills covering commonly used mirrord use cases, installed in one command. Ask an agent to set up queue splitting and only the mirrord-kafka skill loads. Ask it to fix a typo in your frontend and none of the six load because nothing in that prompt matches any of them. The rule of thumb is that your always-loaded file should only hold what’s true for every prompt, and everything else belongs in a skill.
Frequently asked AI agent token cost questions
Why do AI coding agents burn through so many tokens?
What's the fastest way to reduce AI coding agent token costs?
Do mocks reduce or increase AI agent token costs?
What's the difference between an AGENTS.md file and Agent Skills for token costs?
How does mirrord reduce AI coding agent token costs?
Token costs are going up, but your bill doesn’t have to
The first two scenarios trace back to the same root cause: an agent that can’t see what’s actually true about your cluster, so it guesses at a dependency’s shape, gets fooled by a mock that no longer matches reality, or ships a change with no way to check it actually works. mirrord closes that gap by connecting the agent’s locally running code to your real cluster. The agent now knows what’s actually on the queue, what a service returns, what the values of the environment variables the process inherits in the cluster are, so it is testing against reality instead of an assumption.
The other three, on-demand skills and tighter context scoping and matching the model to the task, are solving different problems, but the same principle applies to all of them: only pay for what the current prompt actually needs, and not a wasted guess, an irrelevant paragraph of instructions, or forty files the agent read once and re-sends forever.
If your AI agents are writing code for Kubernetes services, give mirrord a try. Our guide on using mirrord with AI agents walks through the setup for each of these workflows.
