AI Tokenomics: Context, Cost and Better Coding Workflows
This post explores AI tokenomics and practical ways to reduce token costs while improving coding workflows through context management, caching and spec-driven development.
AI can generate code, search documentation and run tools. Every interaction, however, consumes tokens. With agents working through multiple steps, the economics extend beyond the price of a single prompt.
How do context management, caching and development practices influence the final cost?
Understanding tokenomics
Here, tokenomics refers to the economics of using language models. Tokens are units into which content is divided for processing. A token may represent part of a word, punctuation or other content.
The bill depends on several categories:
| Category | What it represents |
|---|---|
| Input | Instructions, conversation history, files and tool results sent to the model |
| Output | Generated content, including billable reasoning where applicable |
| Cache writes | Creating reusable prompt context, where separately priced |
| Cache reads | Reusing previously cached prompt context |
Providers and models price these categories differently. Anthropic's prompt caching documentation, for example, describes five-minute and one-hour cache durations, with different prices for writing and reading cached content.
A short message can trigger a large request. Asking "continue" may involve processing the accumulated conversation, instructions and tool results again. Caching can reduce the cost of repeated content, but that content still occupies the context window.
Matt Pocock: the smart zone and dumb zone
I would highlight Matt Pocock's AI Coding Dictionary, which explains the smart zone and dumb zone.
The distinction describes how a focused session can become less reliable as context accumulates. Failed attempts, irrelevant files and outdated assumptions remain alongside useful information. The model may start overlooking constraints or repeating mistakes.
This is a practical mental model. There is no universal token count at which every model becomes unreliable. The useful working context depends on the model and task.
Lost in the Middle
Context length and effective context usage are different.
The paper Lost in the Middle, by Liu et al., found that the tested models often performed better when relevant information appeared at the beginning or end of the input. Performance declined when that information appeared in the middle of long contexts. These findings concern the models and tasks studied, rather than establishing an identical limitation for every newer model.
My practical takeaway: keep the objective visible, retrieve relevant information selectively and avoid burying requirements inside large document dumps.
Suggested visual: Figure 1 from Lost in the Middle, subject to applicable reuse terms.
Practical token-saving techniques
Claude Code's cost management guide and Anthropic's context engineering article provide useful starting points:
Scope the task. Specify the expected change, constraints and acceptance criteria before implementation.
Retrieve selectively. Search for relevant functions or file sections before loading entire files.
Filter tool output. Return relevant errors and test failures, with a path to the full logs when needed.
Keep standing instructions short. Load detailed workflow guidance only when required.
Clear between unrelated tasks. Start the next task with a focused brief.
Compact deliberately. Preserve decisions, unresolved issues and verification results.
Match the model and reasoning effort to the task. Compare quality and retries alongside price.
Use subagents selectively. They can isolate verbose exploration, but their own token consumption still counts.
Compacting versus clearing
Compacting replaces accumulated conversation with a shorter summary. In Claude Code, /compact can include instructions about what to preserve. This supports continuing related work, although summarisation can lose details.
Clearing, using /clear, removes the conversation history from the active context. Before clearing unfinished work, save a brief handoff containing the goal, decisions, relevant files, completed checks and next action. Project instructions can still be loaded into the new session.
Checking the setup: The /doctor command diagnoses your Claude Code installation and configuration. It helps troubleshoot setup issues, while /clear and /compact manage conversation context.
For example, after investigating a bug, I would preserve the confirmed cause and reproduction steps. A new implementation session can start from that evidence without carrying every unsuccessful investigation.
Neither operation reverses tokens already consumed. Savings depend on the work that follows, including any information that must be reloaded.
Spec-driven development
GitHub Spec Kit provides structured processes for carrying specifications through planning and implementation.
A useful specification defines expected behaviour, constraints and how success will be verified. It also gives a fresh session a durable starting point.
For example: "Add payment retries" leaves many decisions open. A specification can define which failures are retried, the maximum attempts, duplicate-payment protection and required tests.
My expectation is that this can reduce clarification and rework. It should still be measured: generating extensive specifications for a small change may consume more effort than it saves.
ADLC: managing the development lifecycle
The Agentic Development Lifecycle, or ADLC, extends the discussion to the overall delivery process. One published ADLC framework organises work into phases with verification gates before progression. The terminology is still developing, so it helps to name the particular framework being discussed.
For token management, I would apply a simple workflow: agree the scope, record a concise specification, implement a bounded task, verify the result and save a handoff when another session is needed.
Each phase should produce something useful for the next. Repeatedly asking an agent to rediscover requirements or investigate an already diagnosed failure is avoidable work.
Measuring the economics
Token counts become more useful when connected to outcomes.
I would track input, output, cache writes, cache reads, model choice, retries and task completion. Alongside API spend, I would include human review and correction time.
A useful measure is cost per successfully completed task. A cheaper model that needs repeated corrections may cost more overall. A larger model may justify its price when it completes difficult work reliably.
The question I would ask is: how much did it cost to produce a verified, usable result?