I started tracking my monthly token spend across AI coding tools about six months ago. The number that caught my attention was not the total. It was the growth rate. My usage had doubled in three months, and I had not changed how I work in any obvious way. The tools had improved, I had leaned on them harder across my data engineering workflows, and the spend had crept up without a single deliberate decision.

That is how it starts for most engineers. And right now, most of us are not paying the real cost.

The subsidy is temporary

Every major AI provider is currently subsidising token usage. The per-token pricing for Claude, GPT, and Gemini models is set below the actual cost of inference. This is a deliberate strategy to drive adoption and build ecosystems. It is the same playbook that ride-sharing companies used: undercut the real cost, grow the user base, then raise prices once the behaviour is locked in.

The difference is that AI tokens have an underlying compute cost that does not shrink as fast as the user base grows. Model inference requires GPU time. That cost is real, it is large, and someone is absorbing it. When providers stop absorbing it (or absorb less of it), per-token pricing will go up. Maybe by 2x. Maybe by 5x. The exact number matters less than the direction.

Engineers who have built their workflows around unoptimised token usage will feel that price correction. Engineers who have built habits around efficiency will not notice.

Two kinds of AI engineer

This is where the maturity spectrum matters, and it changes the entire optimisation conversation.

The AI-assisted engineer uses AI tools synchronously, as a conversational partner. Open a chat, ask a question, get an answer, apply it, move on. Maybe five or ten agent interactions a day. The tools are assistants. Useful, sometimes excellent, but they slot into an existing human workflow without fundamentally changing how work gets done.

At this level, monthly token spend is often under $25. Even aggressive optimisation (say, 60% reduction) saves $15 per month. That is not nothing, but it is not going to change anyone’s cost structure.

The AI-native engineer works differently. This engineer treats AI agents as autonomous members of the team, not as assistants waiting for instructions. The workflow is orchestration: dispatch dozens or hundreds of agents across parallel tasks, review their output, course-correct, redispatch. Code review agents, implementation agents, research agents, QA agents, all running concurrently on different parts of a problem.

At this level, monthly token spend can sit anywhere from $200 to $2,000 or more, depending on the complexity of the work and the model tiers being used. Now the same 30% optimisation saves $60 to $600 per month. Across a team of five engineers, that is $3,600 to $36,000 per year. The maths changes completely.

The compounding effect makes it worse (or better, depending on your perspective). Small optimisation gains applied consistently across high-volume usage accumulate fast. A 5% efficiency improvement that saves $10 per month at the assisted level saves $100 per month at the orchestrator level. Over a year, across a team, that 5% becomes a real budget line.

Harness engineering for token efficiency

The same principle that applies to data pipeline test harnesses applies here: build the right scaffolding once, and it pays for itself on every subsequent run. Token optimisation is not about using AI tools less. It is about engineering the harness around them so that each interaction is precise.

Model routing: the right model for the task

The cost difference between model tiers is significant. A Haiku-class model costs roughly 7 to 10 times less than an Opus-class model per token. For many tasks (generating documentation, formatting SQL, summarising pull requests, scaffolding Python tests, running simple lookups), the cheaper model produces equivalent output.

The discipline is straightforward: use frontier models for work that requires deep reasoning, architectural judgement, or complex multi-step analysis. Route everything else to mid-tier or lightweight models. Most AI coding tools now support model selection per task or per agent. Use it.

This alone can cut token spend by 30 to 40% without affecting output quality for the tasks that matter.

Session discipline: precise instructions and stop conditions

Vague prompts generate vague (and long) responses. The model explores possibilities, hedges, adds context you did not ask for, and burns tokens doing it.

Precise instructions produce precise output. ‘Refactor the error handling in src/api/auth.ts to use early returns instead of nested try-catch blocks. Do not modify the function signatures or add new dependencies. Stop once the refactor is complete.’ That prompt produces a focussed response. ‘Improve the error handling in the auth module’ produces a treatise.

Stop conditions matter too. ‘Stop once the tests pass’ prevents the model from continuing to optimise, refactor, or add documentation after the stated goal is met. Without a stop condition, agents will keep working and keep spending tokens.

Context management: enough to act, not enough to drown

There is a direct relationship between the amount of context you provide and the number of tokens consumed per interaction. Every file, every conversation turn, every tool result adds to the context window. The model processes all of it on every response.

The principle: provide enough context for the model to act correctly, but no more than that. Point agents at specific files and folders rather than letting them search the full codebase. Front-load the relevant information rather than hoping the model will find it. Reference specific line numbers when you know them.

Google’s prompt engineering whitepaper and Anthropic’s prompt engineering documentation both cover this in detail. The core insight is the same: well-structured prompts with targeted context consistently outperform longer prompts with broad context, both in output quality and in token efficiency.

Session compaction

Long-running sessions accumulate context. Every tool call result, every file read, every intermediate response adds to the token count of subsequent interactions. The context window fills up, and the model starts spending more tokens processing old context than generating new output.

Tools that compress session state help here. Terse communication modes (where both the prompt and the response are stripped of filler) can reduce per-turn token usage by 40 to 60%. This sounds like a stylistic choice, but at scale it is a cost engineering decision. Skills and plugins that enforce concise interaction patterns pay for themselves quickly when applied across hundreds of daily agent interactions.

Session reset discipline helps too. Instead of running one continuous session for an entire day, break work into scoped sessions with clear start and end points. Each fresh session starts with a clean context window.

Reasoning budget: not every task needs deep thinking

Extended thinking and chain-of-thought reasoning improve output quality for complex tasks. They also multiply token usage by 3 to 5x per response.

For tasks that do not require multi-step reasoning (formatting, simple refactors, documentation generation, test scaffolding), turning off extended thinking or using models that do not include it by default is a direct cost saving. The model does not need to reason through a chain of logic to add a docstring to a function.

Sub-agent routing with conditional model selection

When orchestrating multiple agents, not every agent needs the same model. A code review agent that checks for style consistency can run on a lightweight model. An architecture agent that evaluates trade-offs across a system needs a frontier model.

The pattern: define agent roles with explicit model tier assignments. Route by task complexity, not by default. Most orchestration setups default every agent to the same model, which means you are paying frontier prices for work that a model ten times cheaper could handle.

Tool call hygiene

Every MCP server, every tool integration, every external connection adds overhead to the context window. Tool definitions are included in the system prompt. Tool results are appended to the conversation. The more tools available, the more tokens the model spends on tool-selection reasoning before it even starts the actual task.

Remove tools and integrations that are not actively needed for the current session. If a session only involves code editing, it does not need database connectors, deployment tools, or monitoring integrations loaded into context. Lean tool configurations reduce the per-turn overhead that compounds across long sessions.

Guardrails: keeping agents on track in large codebases

The optimisation strategies above assume the agent is doing useful work. In a large repository (a cloud data platform codebase with hundreds of dbt models, pipeline configs, and infrastructure definitions), that assumption breaks down fast without guardrails.

I have watched an agent tasked with fixing a failing test in a data pipeline repository spend 40 minutes and several hundred thousand tokens rewriting the test framework instead of fixing the test. The instructions were clear enough for a human. They were not precise enough for a model with access to the full codebase and no sense of scope.

Persistent instruction files (CLAUDE.md, AGENTS.md, GEMINI.md, depending on the toolchain) exist to solve this problem. They define boundaries that persist across sessions and agents: what files to touch, what conventions to follow, what not to do. But the way most teams write them defeats the purpose.

Simon Willison has written about this problem repeatedly on his blog, and his observation holds: the most common failure with AI agent instructions is treating them like comprehensive documentation. A 2,000-line instruction file does not make an agent more capable. It makes the agent worse at following any single instruction, because the signal-to-noise ratio drops with every line added. The model reads all of it, weighs all of it, and the critical guardrails get diluted by the less important ones.

The practice that works:

  • Keep instruction files short. A few hundred lines maximum. If you need more, the instructions are trying to do too much.
  • State constraints, not context. ‘Do not modify files in src/core/’ is a guardrail. ‘The src/core/ directory contains our core business logic which was originally written in 2019 and has been maintained by the platform team…’ is documentation. One prevents mistakes. The other burns context tokens.
  • Treat them as living documents. Update instruction files as the project evolves. A guardrail that references a deprecated folder or an outdated convention is noise at best and a misdirection at worst. Review them on a regular cadence, the same way you would review CI/CD configuration or data quality rules.
  • Do not aim for perfection on the first pass. Start with the three or four constraints that matter most. Add more only when you observe agents making specific mistakes that a guardrail would have prevented. Reactive additions based on real failures are more useful than speculative ones based on imagined risks.

The token cost of a well-maintained 200-line instruction file is trivial. The token cost of an agent that goes off-track because it lacked a two-line boundary statement, or because the instruction file was so long that the boundary got buried, is enormous.

Test-driven agent work: shift left or pay later

There is a pattern I have seen repeatedly with AI agents working on feature implementation across Python codebases and data pipeline automation. The agent builds the first version. Something is off. It fixes the issue. The fix introduces a side effect. It fixes that. Another side effect. Fifty iterations later, the codebase has a tower of patches, each one compensating for the last, and the original feature still does not work correctly.

The problem is not that the agent is bad at coding. The problem is that it built without verification, so each iteration assumed the previous one was correct. When that assumption is wrong (and it will be wrong, often), the errors compound silently. By the time anyone notices, the agent has spent thousands of tokens constructing on a broken foundation.

Test-driven development addresses this the same way it addresses it for human engineers: shift the verification to the point of creation. Instead of building first and testing later, the agent writes a test for the expected behaviour, confirms it fails, writes the minimal code to make it pass, then moves to the next requirement. Each step is verified before the next one starts. If a fix breaks something, the test suite catches it immediately, not fifty iterations later.

This is the same principle behind CI/CD pipelines in data engineering: validate early, fail fast, never let a broken artefact propagate downstream. Applied to agent workflows, it means the agent runs the test suite after every meaningful change. Not at the end of the session. Not when the feature is ‘done.’ After every change.

The token cost of running tests frequently is real but predictable. The token cost of an agent spiralling through dozens of fix-on-fix iterations without verification is unpredictable and consistently higher. I have seen single agent sessions burn through $15 to $20 in tokens on a problem that a test-first approach would have resolved in $2 worth of inference.

The optimisation gap

Right now, the gap between an optimised and unoptimised AI engineering workflow is masked by subsidised pricing. A 40% cost reduction on a $25 monthly spend is barely noticeable. The same 40% reduction on a $2,000 monthly spend, once subsidies contract, becomes the difference between a sustainable practice and a budget crisis.

The engineers who will adapt best are the ones building these habits now, while the cost of learning is low. Token optimisation is not an advanced topic. It is the AI-native equivalent of knowing how to write efficient SQL, how to avoid N+1 queries, or how to design data pipelines that do not reprocess entire datasets on every run. A basic competency that separates engineers who understand the systems they work with from engineers who treat them as black boxes.

The subsidy will not last. The habits you build now will.