Agentic Playbook #16
Spend Tokens Where Thinking Matters
Agentic systems turn tokens into a variable operating cost. Understanding how context, reasoning, and repeated tool use consume that budget is essential to building AI workflows that remain effective and economically sustainable at scale.
As AI-assisted development moves from occasional autocomplete into always-on agentic workflows, a new economic reality is starting to emerge.
The cost of AI is no longer just a subscription line item.
It is context. It is reasoning. It is retries. It is tool calls. It is agents reading the same files repeatedly, summarising long sessions, reviewing generated code, running tests, and producing explanations across the entire development lifecycle.
For individual developers, this may still feel abstract.
For engineering teams, it will not remain abstract for long.
Once agents become part of daily delivery workflows, tokens become an operating cost of software engineering — much like cloud spend, CI minutes, logging volume, or observability storage.
And, just like cloud, unmanaged consumption rarely stays small.
This is why I believe we need to start talking seriously about the token economy of agentic development.
Not because we should starve our tools.
But because we should spend tokens where they create real engineering value.
There is a risk that any conversation about token efficiency sounds like cost-cutting.
That is not the point.
The point is discipline.
In the same way mature engineering teams learned to think about cloud efficiency, deployment frequency, build times, observability noise, and test duration, we now need to think about the cost profile of AI-assisted development.
Agentic tasks can consume dramatically more tokens than simpler code chat or reasoning workflows, with input tokens often becoming the dominant cost driver. More token usage also does not necessarily translate into better outcomes.
That matters.
Because if more tokens do not automatically mean better outcomes, then engineering teams need a better operating model.
One of the simplest practices is also one of the most overlooked.
At the beginning of an agentic coding session, tell the agent that budget matters.
For example:
“Operate under a limited token budget. Stay concise. Prefer targeted file reads over broad context loading. Ask before expanding scope. Suggest a cheaper model or simpler execution path when deep reasoning is no longer required.”
This will not make the agent perfectly cost-aware. Models are still poor at predicting their own token usage accurately, and agentic workflows can behave unpredictably. But it does influence behaviour.
It encourages the agent to communicate more tightly, avoid unnecessary exploration, and make scope expansion more deliberate.
The principle is simple:
If we do not tell agents that cost matters, we should not be surprised when they optimise only for completion.
In always-on workflows, completion alone is not enough.
We also need efficiency, precision, and judgment.
Not every response deserves a polished explanation.
Sometimes we need depth. Sometimes we just need the answer.
That is where tools like Caveman become interesting.
Caveman is a Claude Code skill/plugin, also positioned for Codex, Gemini, Cursor, Windsurf, Cline, Copilot and many other tools, designed to reduce output verbosity while preserving technical accuracy. Its own description captures the idea very simply:
Brain still big. Mouth small.
The example is immediately understandable.
Normal response:
“The reason your React component is re-rendering is likely because you’re creating a new object reference on each render cycle. When you pass an inline object as a prop, React’s shallow comparison sees it as a different object every time, which triggers a re-render. I’d recommend using useMemo to memoize the object.”
Caveman-style response:
“New object ref each render. Inline object prop = new ref = re-render. Wrap in useMemo.”
Same technical point. Far fewer tokens.
This kind of communication style is useful for status updates, test summaries, implementation notes, routine debugging, and file-change reports. It is less suitable when the goal is architectural learning, mentoring, or explaining trade-offs.
That distinction matters.
The aim is not to make engineering communication worse.
It is to match verbosity to value.
In many agentic workflows, the expensive part is not the final answer.
It is the context.
Large repositories, long chat histories, repeated file reads, logs, traces, generated summaries, and tool output can quickly become the real cost centre.
This becomes especially visible in monorepos.
A vague instruction such as:
“Review this repo and fix the issue”
invites broad exploration.
A token-aware version might be:
“Focus only on /packages/auth and /apps/api. Use the failing test output below. Do not inspect unrelated packages unless you explain why first.”
That change seems small, but it shifts the agent from open-ended exploration into bounded investigation.
Context should not be treated as a dumping ground.
It should be treated like memory, CPU, or cloud infrastructure: valuable, limited, and intentionally allocated.
The practical lesson is straightforward:
Smaller, cleaner context usually produces better engineering behaviour than larger, noisy context.
This is especially important as agents begin operating across larger codebases where “just read everything” becomes both expensive and cognitively messy.
A useful companion practice is to make the agent justify its context requirements before consuming them.
Instead of immediately giving the agent large files, full directories, or several thousand lines of logs, ask it to identify the minimum context it needs first.
For example:
“Before reading large files, inspect the repository structure and identify the smallest set of files needed for this task. Explain your target scope before proceeding.”
This is particularly helpful in platform repositories, full-stack applications, and large monorepos where the relevant answer is often hidden in a small part of the system.
It also creates a healthier reasoning pattern.
The agent must pause and ask:
• where is the likely source of truth? • which files are probably relevant? • what can be ignored? • what evidence is needed before editing?
That pause is valuable.
It reduces token waste, but it also improves the quality of the investigation.
This connects closely with a broader theme from my previous articles: AI-assisted development becomes much stronger when we ask agents to reason about scope before they execute.
One of the most effective cost-control strategies is not simply using cheaper models.
It is using the right model at the right time.
High-reasoning models are worth using when the task requires judgment:
• architectural planning • migration strategy • system decomposition • risk assessment • trade-off analysis • security-sensitive reasoning
But once the plan is clear, not every step needs the most expensive model.
Mechanical edits, test generation, documentation updates, formatting, and repetitive refactors can often be delegated to cheaper or faster agents — provided the scope is clear and the output remains reviewable.
This creates a model-tiered workflow:
Senior model plans. Cheaper agents execute. Human reviews.
That mirrors how effective engineering teams already work.
We do not ask the most senior architect to manually apply every repetitive code change. We ask them to shape the approach, identify risks, define constraints, and guide execution.
The same principle applies to AI.
Spend expensive reasoning where reasoning matters.
Do not spend it where execution is mechanical.
This is only the first half of the token economy conversation.
In Part 2, I want to explore techniques that reduce waste across the broader agent lifecycle:
• using Ponytail to reduce over-engineered code • summarising long sessions into compact state files • storing stable knowledge once in AGENTS.md, rules, skills, and ADRs • treating Spec-Driven Development as a cost-control mechanism • using output contracts so agents only explain what is necessary
Those practices matter because token efficiency is not only about shorter messages.
It is also about reducing rework, avoiding unnecessary abstractions, preventing repeated explanations, and making agent behaviour more predictable over time.
The token economy is not about making AI less useful.
It is about making AI-assisted development economically sustainable.
The teams that win will not be the ones that use the most tokens.
They will be the ones that understand where tokens actually create value.
Sometimes that means spending more on deep reasoning.
Sometimes it means asking for fewer words.
Sometimes it means narrowing context before the agent ever starts.
And increasingly, it means treating AI consumption with the same engineering discipline we already apply to cloud, CI/CD, observability, and production infrastructure.
Because in always-on agentic workflows, tokens are not background noise.
They are part of the cost of delivery.