Sitemap
Murali Krishna

Murali Krishna

Press enter or click to view image in full size

Token Economics & its impact on Agentic SDLC

11 min readOct 2, 2026

--

In traditional software engineering, compute costs scale predictably with infrastructure runtime: CPU hours, memory allocation, microservice pod scaling, and CI/CD build minutes.

However, as software development transitions from human-written code assisted by static autocomplete tools to autonomous agentic loops driven by Large Language Models (LLMs), the primary economic unit shifts from infrastructure runtime to token velocity.

When AI agents independently navigate codebases, write specifications, execute terminal commands, parse build failures, and refactor code, token consumption scales non-linearly. Left unmonitored, an unchecked sub-agent loop can execute dozens of turns in seconds, compounding context windows, re-reading entire repository trees, and inflating operational spend by orders of magnitude without delivering verified value.

Understanding token economics is no longer merely a FinOps concern for cloud cost management — it has become a core architectural discipline for engineering leadership.

Token cost in an agentic SDLC is set by four variables: tokens per call, calls per run, price per token, and runs per accepted change. The unit that matters is cost per accepted change, not tokens consumed. Because a model call is stateless, context is re-sent on every call, so total input tokens in a loop grow with the square of the number of calls unless context is trimmed.

The post assesses this from five perspectives:

  • Methodology. Multi-agent designs multiply per-agent context. Spec-driven and test-driven loops lower the number of runs per accepted change.
  • Autonomy. Higher autonomy removes the human who stops wasted loops.
  • Enterprise constraints. Knowledge, tool catalogs, privacy controls, and security checks each change tokens per call or calls per run.
  • Developer velocity and experience. Spend does not guarantee speed.
  • Maturity. Cost cannot be controlled where it is not metered. Autonomy should rise only as verification and metering do.

First principles: Agentic SDLC and the token cost model

The cost of an Agentic SDLC is the sum of tokens sent and received across every model call in every agent loop, priced by token type.

The largest term is usually the same context re-sent on each call. This section states the principles that follow, first for the process and then for the cost.

Five principles of Agentic SDLC

  1. The SDLC is a feedback loop. Intent becomes an artifact (spec, code, test, configuration). The artifact is verified. A decision follows: accept, revise, or reject. Agents replace the executor in this loop. They do not remove verification or the decision.
  2. Verification is the control signal. An agent converges only if something returns pass or fail. Compilers, type checkers, linters, and tests return that signal at near-zero token cost. Model-based review returns it at token cost and with error. Order checks from cheapest to most expensive.
  3. Intent must be explicit. The agent resolves ambiguity through exploration, guessing, and rework, and each is a model call. A precise spec moves that cost to a one-time human step.
  4. Context is working memory with a price. The model holds only what is in the prompt. Every token in the prompt is billed on every call that includes it, and competes for attention with every other token.
  5. Autonomy is bounded by verifiability and blast radius. An agent should act without a human only where its output can be checked automatically and a wrong action can be reversed.

A sixth rule applies to all five: every loop needs a stop condition and a budget. A loop without them has unbounded cost.

The cost of one agent run is the sum over its calls:

Press enter or click to view image in full size
  1. Tokens read from a prompt cache are billed at a lower input price.
  2. Cache writes and reasoning tokens are billed differently by different providers, so the formula leaves them out.

The unit that matters to an organisation is cost per accepted change, not cost per token:

Press enter or click to view image in full size

All runs count, including failed, abandoned, and retried runs. Cheaper tokens with a lower acceptance rate can raise this number.

Impact by methodology of agentic SDLC

Each methodology sets a different value for the four variables in the cost model.

  • Chat-assisted. A human prompts, the model answers, and the human applies the result. The cost to watch is human time. A common failure is pasting large files as context.
  • Single-agent loop. One agent calls tools until it decides it is done. Step limits and bounded tool output are the main controls. Re-reading files and unbounded search results raise cost.
  • Plan-then-execute. A plan is produced and approved, then executed. Plan quality sets the number of runs per accepted change. A short plan review before execution is the control. A flawed plan executed across many steps is the failure.
  • Spec-driven. A written spec and acceptance criteria precede code. Tokens are spent early on a document that is cheap to review, and rework falls. The spec can be reused as stable context. The failure is spec drift, where code and spec disagree.
  • Test-driven agent loop. Tests are written first and the agent iterates until they pass. Flaky tests cause retries that add no new information.
  • Multi-agent (orchestrator-worker). A lead agent delegates to sub-agents with separate contexts. The control is to delegate only parallelisable work and return summaries, not transcripts. Duplicated work between sub-agents is the failure.

Reading the methodologies through the cost model

  • Single-agent loops are where the quadratic term matters. Each added step is re-sent on every later step.
  • Plan-then-execute and spec-driven methods lower runs per accepted change, but only if review catches errors in the plan or spec. An unreviewed plan adds a step and removes nothing.
  • Test-driven loops replace model judgement with a deterministic pass or fail. This is the cheapest verification signal available.
  • Multi-agent designs reduce the context growth of any one agent. They pay off when parallelism or context separation is needed, and cost more when it is not.

Impact by agent autonomy

Autonomy decides who ends the loop. At low autonomy a human ends it after each step. At high autonomy the agent or a rule ends it. Cost follows from that, because N, the number of calls in a loop, is set by the stopping rule.

Level 1: Copilot / Assistive (Human-in-the-Loop)

  • Mechanism: Single-turn inline completions and explicit inline chat prompts.
  • Token Dynamic: Low cost per interaction. Humans continuously clear state and reset context windows, preventing context bloat.

Level 2: Task-Bound Autonomous (Sub-agents, Single PR Resolvers)

  • Mechanism: The agent receives a scoped task (e.g., “Implement endpoint X and add unit tests”) and executes locally using file and terminal tools.
  • Token Dynamic: Moderate to high cost. Requires active file scoping and AST filtering to avoid loading unnecessary source code.

Level 3: Full Goal-Oriented Autonomy (Unbounded Exploration)

  • Mechanism: High-level prompt directions (“Refactor authentication service to async I/O”) with independent repo navigation, spec generation, and self-debugging.
  • Token Dynamic: Exponential cost risk. Without explicit step caps, agents can enter diagnostic loops, re-reading entire repository subtrees repeatedly and compounding token burn.

Impact of enterprise constraints: knowledge, context, security

Knowledge

An agent knows nothing about an organisation’s code, standards, or decisions unless they are placed in context. There are two supply strategies. Embedding-based retrieval fetches material before inference. Just-in-time retrieval keeps lightweight references such as file paths and queries, and loads data when needed

In cost terms, pre-loaded knowledge is paid on every call in the run, so it belongs only where most calls need it. Knowledge needed on a few calls should be fetched on those calls. Stable knowledge such as coding standards suits a cacheable prefix.

Security

Security adds tokens through guardrail checks, approval steps, and any model-based review of agent actions. Cost is also a security risk in its own right.

An agent loop without a cap is an instance of this risk. The caps in the autonomy section are therefore security controls as well as cost controls.

Context

Tool catalogs are a measurable source of overhead. Anthropic describes most MCP clients loading all tool definitions into context up front. Long contexts also reduce accuracy. Anthropic’s engineering team describes context rot, where recall of information in the window falls as the number of tokens grows. A smaller context is therefore cheaper and, on this evidence, more accurate.

Where tokens trade against time

Some token spend buys time back. In Anthropic’s research system, running sub-agents and tool calls in parallel cut research time by up to 90% for complex queries.

Parallelism does not lower token use. It raises it, in exchange for lower wall-clock time.

Whether the trade is worth it depends on the value of the developer’s waiting time against the cost of the extra calls.

Get Murali Krishna’s stories in your inbox

Join Medium for free to get updates from this writer.

Other spend produces no time saving. Re-reading unchanged files, repeating a failed approach, and carrying a stale transcript all add tokens without adding progress.

Developer experience

  1. A loop with many sequential calls feels slow even when each call is fast. Show progress and allow the developer to interrupt.
  2. Budget limits: A cap that stops a task at 90% complete costs the developer the tokens already spent. Warn before the cap, and let the agent save its state so work can resume.
  3. Review time: An agent that produces a large diff moves cost from tokens to reviewer time. Smaller, scoped changes with a stated intent are cheaper to review.
  4. Model routing: Developers should be able to see which model is routed for different kind of tasks and associate it with quality variation.

Metrics that fit

Tokens consumed is a cost measure, not an output measure. Counting it as productivity rewards waste.

  • Cost per accepted change: tokens spent across all runs, divided by merged changes.
  • Acceptance rate (q): the share of runs that pass verification and review.
  • Calls per run (N) and tokens per call: where the loop spends context.
  • Review time per change: the human cost the agent moves.
  • Time from task start to merge: developer-visible velocity.
  • Rework rate after merge: whether acceptance was premature.

Impact by organisational maturity

Organisational maturity determines whether token cost can be seen, attributed, and controlled.

It also determines how much autonomy is safe, because autonomy depends on automated verification.

The 2025 DORA report, based on nearly 5,000 technology professionals, states that AI amplifies what is already in a team: strong teams improve, and struggling teams see their problems intensified

It reports a positive relationship between AI adoption and delivery throughput, and a continued negative relationship with delivery stability. The report attributes the instability to missing control systems: automated testing, mature version control, and fast feedback loops.

DORA’s recommended starting points include clarifying AI policy, connecting AI to internal context, and strengthening safety nets.

Automated tests and fast feedback are the cheap verification signals.

An organisation without them has no inexpensive way to tell an agent it is wrong, so it relies on model review or human review, and cost per accepted change rises.

Token-efficient patterns by SDLC stage

Requirements & Spec Definition

  • Task: Translating business goals into execution tasks.
  • Strategy: Use large-context high-reasoning models to analyze product documents once, outputting structured, machine-readable markdown specs. Front-loading clarity prevents downstream code-generation sub-agents from wasting tokens in iterative guessing loops.

System Architecture

  • Task: Defining service boundaries, data models, and API interfaces.
  • Strategy: Omit source implementation details and focus strictly on interface signatures and contracts. Avoid loading full source code files into context.

Code Generation & Implementation

  • Task: Writing feature code inside existing modules.
  • Strategy: Use dynamic tool resolution. Rather than presenting 30 system tools at once, expose only the tools needed for the current phase (e.g., expose search tools first, then swap to file-writing tools during the edit phase).

Testing, CI/CD, and Debugging Loops

  • Task: Fixing broken builds and test failures.
  • Strategy: Never dump raw build logs or full stack traces into the agent prompt. Use local log parser tools to extract only the failed test assertions, file paths, and error lines before invoking the model.

Maintenance & Refactoring

  • Task: Upgrading dependencies or refactoring legacy modules.
  • Strategy: Map dependency graphs off-model using static analysis tools, supplying the agent with focused structural slices rather than broad file trees.

Top practices to keep token cost efficient

Implement Dynamic Tool Schema Hydration

Avoid exposing your entire suite of system tools in the default system prompt. Instead, load tool definitions dynamically based on the current step in the execution pipeline. This prevents paying a fixed tool schema token penalty on every single turn.

Truncate Build Logs Using Deterministic Pre-Parsers

Raw build outputs and test suite logs contain substantial repetitive boilerplate. Run logs through lightweight local parsers (e.g., regex filters or AST error extractors) to pass only relevant exception traces to the model, reducing diagnostic context payloads by up to 90%.

Establish Strict Loop Termination Safeguards

Define clear stopping conditions for all autonomous agents: set maximum turn limits (e.g., cap at 10–15 steps), enforce maximum token spend thresholds per task, and mandate deterministic validation checks (such as passing linters or unit tests) before allowing further reasoning turns.

Leverage Prompt & Context Caching Strategies

Architect repository context layers to take full advantage of model prompt caching. Keep system prompts, repository conventions, and architecture docs static at the top of the context structure so that repeated sub-agent invocations reuse cached prompt tokens at a fraction of standard input costs.

Adopt Tiered Model Routing (Task-to-Model Matching)

Do not deploy top-tier high-reasoning models for routine tasks. Route sub-tasks strategically: use fast, lower-cost models for file discovery, AST parsing, and boilerplate generation, and reserve high-reasoning models for core algorithm implementation, architectural validation, and complex bug resolution.

Meter cost per accepted change by stage, then route

Meter tokens by user, team, workflow, and SDLC stage. Report cost per accepted change, not tokens consumed. Use the data to route: send mechanical and well-verified tasks to a lower-cost model tier or a deterministic tool, and reserve higher-cost models and multi-agent designs for tasks where measured acceptance rate or wall-clock time justifies them.

Verify cheaply first and specify clearly

Run compilers, type checkers, linters, and tests before any model-based review. Return only the failing output to the agent. Write acceptance criteria before the agent starts, including the interface to change and the tests that define done.

References

Spec-Based Agentic Development & Spec-Driven Engineering — Design patterns for deterministic agentic software execution.

LLM Cost Optimization & Context Window Management in Autonomous Agents — Industry research on context caching, AST retrieval, and agent turn convergence.

Autonomous Software Engineering Benchmarks (SWE-bench) — Evaluations of multi-turn problem solving, tool interaction overhead, and patch efficiency.

Measuring the impact of early-2025 AI on experienced open-source developer productivity. METR. https://metr.org/blog/2025-07-10-early-2025-ai-experienced-os-dev-study/

We are changing our developer productivity experiment design. METR. https://metr.org/blog/2026-02-24-uplift-update/

How we built our multi-agent research system. Anthropic Engineering. https://www.anthropic.com/engineering/multi-agent-research-system

Announcing the 2025 DORA report: State of AI-assisted software development. Google Cloud Blog. https://cloud.google.com/blog/products/ai-machine-learning/announcing-the-2025-dora-report

Code execution with MCP: Building more efficient agents. Anthropic Engineering. https://www.anthropic.com/engineering/code-execution-with-mcp

Prompt caching. OpenAI Developers. Retrieved October 1, 2026, from https://developers.openai.com/api/docs/guides/prompt-caching

OWASP GenAI Security Project. (2025). LLM10:2025 Unbounded consumption. https://genai.owasp.org/llmrisk/llm102

--

--