AI Build Cost: Why Token Prices Fall and Your Bill Doubles

Table of Contents

• Motivation
• The paradox: falling prices, rising bills
• Why build cost decouples from developer time
• "A developer costs $12,000 - tokens are noise"
• Build vs. Run: two different cost models
• Six cost decisions that belong in an ADR
• Example ADR: Model Routing Policy
• Conclusion

Motivation

A few weeks ago I looked at my own AI usage for the first time in months. Not at a client's. Mine.

I was surprised. Not shocked, not a horror story - no four-figure invoice, no incident. Just quietly, steadily more than I would have guessed. And I am supposed to be the person who has this on his radar.

That sent me looking for the questions I had never actually asked:

• Do you know what your last feature cost in tokens?
• Who decided that your CI pipeline runs an agent on every pull request?
• Why does team A burn three times what team B does - for the same output?
• Which model is your agent actually using? Is it still the one someone picked during the spike six months ago?
• And when the budget runs out mid-sprint - what happens?

Sound familiar?

In my role as Tech Lead and Software Architect I now see the same pattern in almost every organisation: teams have adopted agentic engineering at remarkable speed - and nobody owns the cost model that came with it.

My starting hypothesis was that token prices would rise and force the issue.

I was wrong about that. The prices are falling. The bills are rising anyway.

That turns out to be the more interesting problem.

The paradox: falling prices, rising bills

Let's get the numbers out of the way, because they are not ambiguous.

The frontier token price index sits at 12 as of late August 2026, against a base of 100 in March 2023 - an 88% decline (see).

On 30 July 2026, OpenAI cut GPT-5.6 Luna by 80%. On 11 August, Anthropic cancelled the price increase that had been scheduled for Claude Sonnet 5 and made the introductory rate permanent. The floor for mainstream APIs is now around $0.20 per million input tokens.

If your thesis is "the price per token is going up", the market has already answered you. It isn't.

Now the other number.

Anthropic publishes cost benchmarks from enterprise Claude Code deployments in its own documentation. Today that page states roughly $13 per developer per active day, and $150-250 per developer per month, with 90% of users staying below $30 on any active day (source).

Earlier this year, the same reference read $6 per day, with 90% below $12.

Same vendor. Same metric. Same page. Roughly doubled - while the unit price of the thing being measured fell.

And the tail is where budgets actually die. Microsoft told engineers in its Experiences + Devices division to stop using Claude Code after token-based billing reached $500-2,000 per engineer per month and consumed the division's annual AI budget in months. The same reporting notes Uber exhausted its 2026 AI budget. Copilot users saw monthly costs jump from $29 to $750 after a billing change in June. Gartner puts agentic coding tools at $2,000-5,000 per developer per month at the high end.

This is not a pricing problem. It is a consumption problem.

And consumption is decided by architecture.

Why build cost decouples from developer time

Here is the part that makes this an engineering topic rather than a procurement topic.

For as long as we have had developer tooling, tool cost scaled with seats. One developer, one licence, one predictable line item. AI coding assistants started out the same way - a subscription, a fixed monthly number, easy to budget.

Agents broke that link.

A few mechanisms, all documented:

Parallelism: Anthropic measures parallel sessions and agent teams at roughly 7x the token consumption of a standard session. One developer can now run several agents at once. The human is still working linearly. The consumption is not.

Subagent overhead: Subagent-heavy workflows have been measured at 200-500% overhead compared to the same task run as a single agent. The fan-out is the point of the pattern - and also the cost.

Retries resend everything: Claude Code's main query loop resends the full message history, system prompt and tool schemas on every retry. A task that needs three attempts does not cost 3x the useful work. It costs 3x the entire context, every time.

MCP servers inflate the baseline: Every connected MCP server contributes its tool definitions to the context of every single call. Connect five of them "just in case" and you have raised the floor price of every request your team makes, forever, whether or not those tools are used.

Unattended execution: Agents in CI. Nightly runs. Eval suites. Background tasks. None of these have a human watching the token counter, and none of them stop because someone went home.

The sentence I keep coming back to:

A developer scales linearly. An agent fans out.

"A developer costs CHF 12,000 - tokens are noise"

This is the objection I get every time, and it deserves a serious answer, because in its strongest form it is correct.

At $1000 per developer per month against a fully loaded salary, AI build cost is a rounding error. Optimising it is a waste of an architect's attention. If your agent saves some hours a week, it has paid for itself several times over. Anyone spending sprint time on token efficiency at that ratio is optimising the wrong variable.

I agree - under one assumption.

That ratio holds as long as a human is sitting at the agent. Human attention is the rate limiter, and human attention is expensive and finite. That is what keeps consumption bounded.

But that assumption is exactly the one our industry is currently abandoning. Every agentic pattern worth adopting - parallel agents, background tasks, CI-integrated review, autonomous refactors - works by removing the human from the loop. The value of those patterns is the decoupling. And the moment consumption decouples from human hours, the ratio that made the objection true stops being true.

There is a second problem with reasoning from the average.

The published distribution is not normal. Roughly 90% of users below $30 per active day means a small tail is driving a large share of spend. Microsoft's division did not fail on the median. It failed on the tail at $500-2,000 per engineer.

If your budget model assumes the mean, the tail will find you.

Build vs. Run: two different cost models

Before the decisions, one distinction that gets muddled constantly - including, until recently, by me.

At Fellow I see both sides of this: seats internally, metered API spend on the client side. They feel similar on an invoice and behave nothing alike. Build cost is an investment you can throttle. Run cost is a variable cost that scales with every customer you win - which means a flat-rate product with an unbounded AI feature has a margin problem, not a budget problem.

This post is about build cost. Run cost gets its own post.

Six cost decisions that belong in an ADR

Here is the practical part. In my experience these six decisions determine most of your build cost - and almost nobody writes them down.

They are architecture decisions in the strict sense: made once, hard to reverse, consequential, and currently being made implicitly by whoever set up the repo first.

1. Model Routing Policy

Which model handles which class of task - and who is allowed to deviate?

The most expensive decision in most organisations was never a decision. Someone picked a model during a spike, and it silently rode into production. Define task classes (trivial edit, feature work, architectural refactor, research) and map them to model tiers. Make escalation explicit and cheap, but visible.

2. Context Budget

How much context per request, and which MCP servers are loaded by default?

Tool schemas, chat history and retrieved files dominate the bill far more often than the prompt does. Treat the default context set like a dependency list: everything in it is paid for on every call.

3. Agent Concurrency & Loop Limits

How many agents run in parallel, and how many attempts before the agent stops?

This is the 7x multiplier and the retry loop. An agent without a loop limit is an open tap. Set a ceiling, and make hitting it a visible event rather than a silent one.

4. Automation Boundary

What runs unattended, and what requires a human in front of it?

The single line where cost decouples from developer time. Agents in CI, nightly runs and eval suites are the right pattern for many things - but each one crosses this boundary and should be crossed deliberately.

5. Attribution & Telemetry

Is spend attributed to a ticket, a team, a feature - and how?

Without attribution you have one aggregate invoice and no way to act on it. With a ticket ID on the session, you have unit economics. Emit cost telemetry from your agent workflows the way you emit traces.

6. Budget Guardrails & Degradation

What happens at 80%? At 100%?

Alert, downgrade to a cheaper tier, queue, or hard stop. Note that this is a system behaviour - a degradation strategy, exactly like the ones you already design for rate limits and downstream outages. It belongs in the architecture, not in a finance process.

The metric to steer by

Once attribution exists, you can pick a unit.

I would use two:

• Cost per feature / epic / user story - the steering metric. It is the unit your product and planning conversations already happen in.
• Cost per merged PR - the instrumentable proxy. Derivable from session logs and ticket IDs, and it punishes exactly the behaviour you want to punish.

Cost per token rewards a cheap agent. Cost per merged PR rewards an agent that gets it right the first time.

An agent that takes three attempts looks fine on the first metric and terrible on the second.

Example ADR: Model Routing Policy

Using the structure from the Architecture Decision Canvas:

Context. Our agents default to the top-tier model for every task, a choice made during an initial spike and never revisited. Build cost per developer has roughly doubled over two quarters with no corresponding change in throughput. We have no data on whether the premium tier improves outcomes for routine work.

Decision. We define four task classes and map each to a model tier. Agents default to the tier for their class. Escalation to a higher tier is permitted at any time and requires a one-line justification in the PR description. Routing configuration lives in the repo and is version-controlled like any other config.

Consequences.

• Expected reduction in build cost, concentrated in the routine-work classes.
• Higher retry rate where tasks are misclassified - we accept this and monitor it.
• Routing logic becomes a component we own and maintain.
• Escalation friction is deliberate but must stay low; if developers route around it, the policy has failed and we revisit.

Fitness function. Cost per merged PR, per team, reported weekly. Alongside it: retry rate and PR cycle time, so we can see if we bought savings with delay.

Conclusion

For twenty years, software architects have owned a familiar set of quality attributes. Performance. Security. Availability. Maintainability.

Cost was never one of them. It was a constraint that arrived from outside, expressed in servers and licences, and it changed slowly enough that it could live in a spreadsheet somewhere in finance.

That is over. Cost is now decided at design time, by the same people who decide everything else at design time - and it moves at the speed of a retry loop.

The teams that treat it as an architecture concern will write down six decisions, instrument one metric, and get on with building.

The teams that treat it as a finance problem will find out, one budget cycle at a time, that procurement cannot renegotiate its way out of an architectural default.

My prediction: within two years, a team's token budget will be as ordinary a part of sprint planning as its capacity - and the teams that get there first will have written it down as an ADR, not as a spreadsheet.