AI coding is getting cheaper per token and more expensive per engineering team.
On July 30, 2026, OpenAI cut GPT-5.6 Terra API pricing by 20% and Luna pricing by 80%. Terra now costs $2 per million input tokens and $12 per million output tokens, while Luna costs $0.20 and $1.20 respectively. OpenAI left Sol pricing unchanged.
Anthropic moved in the same broad direction. Claude Sonnet 5 launched at an introductory price of $2 per million input tokens and $10 per million output tokens. On August 10, Anthropic updated the launch announcement to confirm that those prices would become permanent rather than increasing to the previously planned $3/$15 rate in September.
Yet enterprise spending isn't following the same downward curve. Uber reportedly exhausted its planned 2026 AI budget within four months, then introduced a roughly $1,500 monthly spending cap per employee, per agentic coding tool. The cap applies separately to tools such as Claude Code and Cursor.
The broader cost pressure isn't unique to Uber. In June 2026, Gartner predicted that AI coding costs could overtake the average developer salary by 2028, pointing to rising token consumption and the shift toward consumption-based licensing.
There's no contradiction here.
Token prices tell you what one unit of computation costs. Your engineering bill tells you how many units you're consuming to produce something useful.
And those are becoming very different numbers.
The wrong metric is price per million tokens
Model-price comparisons are useful when you're choosing infrastructure. They're much less useful when you're trying to explain an engineering budget.
A developer doesn't buy “one million tokens” and turn them into one million tokens' worth of product value. They ask an agent to investigate a bug, change a service, run tests, inspect failures, search for another implementation, revise its first answer and prepare something another human can review.
That workflow can involve hundreds of model and tool interactions. A 2026 trace study of roughly 4,300 real Claude Code and Codex sessions captured around 350,000 LLM steps and 430,000 tool calls, showing just how different agentic workloads are from single-response prompting. The full workload study is available on arXiv.
The bill accumulates across that loop.
The useful question therefore isn't:
How much does our model cost per million tokens?
It's:
How much does one accepted unit of engineering work cost?
Start measuring cost per accepted task
An accepted task can be whatever unit makes sense for your team: a merged pull request, completed bug fix, accepted migration or finished ticket.
The exact denominator matters less than using one consistently.
A basic internal metric is:
AI cost per accepted task = total AI coding spend ÷ accepted AI-assisted tasks
But that still misses one expensive input: the person checking the output.
A more useful internal calculation is:
Effective cost per accepted task = (AI spend + human review cost + failed-attempt cost) ÷ accepted AI-assisted tasks
This isn't an industry-standard accounting metric. It's a practical operating metric for comparing your own AI workflows over time.
That distinction matters because a low-cost model that takes three attempts to produce acceptable work can be more expensive at the task level than a stronger model that succeeds immediately. API pricing is only one component; retries and senior review consume real engineering capacity too.
Where does the money go, actually?
Agentic coding spend isn't limited to the tokens that eventually become code. A large part of the workflow can be spent finding enough information to know what code should be changed.
The 2026 coding-agent workload study found that these systems characteristically run long autonomous loops with long contexts and comparatively short outputs, alongside large numbers of tool calls. That workload shape is described directly in the research paper.
In a large unfamiliar codebase, that can mean searching for relevant files, tracing dependencies, inspecting tests, reading interfaces, invoking tools and revisiting earlier context before implementation even begins.
Some exploration is unavoidable. The expensive part is reconstructing the same organizational context again and again.
Caching helps enormously, but it doesn't REMOVE the problem
Any realistic discussion of agent costs needs to include prompt caching.
The same 2026 trace study measured a 95.7% global token-weighted prefix-cache hit rate. It also found that most misses occurred around the transition from the model's previous output to the next human input, where the delay caused by reading, thinking and typing can exceed cache lifetimes.
See the caching analysis in the paper.
That's a major efficiency gain, but caching and context discipline solve different problems.
Caching makes repeated context cheaper. It doesn't tell you whether all of that context needed to be read in the first place.
And cache misses can be more expensive than they initially appear. With some providers, writing tokens into the cache carries a premium over ordinary input tokens. That makes a miss particularly painful in human-in-the-loop workflows: an agent finishes a task, someone spends several minutes reviewing it, the cached prefix expires, and the next turn may require paying to process — and potentially cache — a large part of the conversation again.
This creates an operational problem too. Most users don't actively think about cache lifetimes while working with an agent. Cache behavior becomes yet another implementation detail that someone has to design around or remember. When it is ignored, repeatedly re-processing a long conversation can quietly turn into a meaningful part of the bill.
A second 2026 study looking specifically at prompt caching across long-horizon agentic tasks found API-cost reductions of roughly 41–80%, depending on provider and caching strategy. It also found that caching configuration mattered: naïve full-context caching wasn't always the best strategy.
The study is available on arXiv.
So the sensible relationship is: Caching discounts repeated context. Better retrieval reduces how much irrelevant context there is to repeat — and how much you pay when the cache misses.
The cheapest model can be the most expensive choice
A second trap is routing every apparently “easy” task toward the cheapest model.
The problem is that difficulty changes across the lifecycle of a task. A simple rename can begin with a difficult architectural question. A difficult migration can end with hours of mechanical work.
A useful operating model is therefore to route by phase, not only by ticket difficulty.
The Plan–Build–Grind–Review model
PLAN
Use stronger reasoning when the system needs to understand constraints, explore alternatives or discover the correct scope.
BUILD
Once the plan and context are known, a capable mid-tier model may be enough for implementation.
GRIND
Mechanical transformations, repetitive migrations and boilerplate can often move to the cheapest adequate model or local inference.
REVIEW
Spend more on judgment again when the job is checking assumptions, dependencies and potential failure modes.
This framework is a recommendation for internal experimentation rather than a published benchmark. Teams should validate it against their own success rate, retry rate and review time rather than assuming a model tier will always win.
Model routing changes the price of reasoning. Context changes how much reasoning you buy.
Those are separate levers.
Routing decides which model handles the work.
Context decides how much material the model has to process before it can do that work well.
And bigger context windows don't automatically solve that problem.
A 2025 controlled study across five open and closed models found that performance degraded as input length increased even when retrieval was perfect and all relevant evidence remained available. The authors observed degradation across math, QA and coding tasks and concluded that input length itself can hurt performance.
Read Context Length Alone Hurts LLM Performance Despite Perfect Retrieval.
A separate 2026 study focused specifically on automated bug fixing found a similar pattern. Successful agentic trajectories generally stayed between 20-30K tokens, while longer accumulated contexts correlated with lower success. In single-shot tests using 64K–128K contexts, performance dropped sharply despite the relevant files being included.
See The Limits of Long-Context Reasoning in Automated Bug Fixing.
So: More available context isn't the same thing as better selected context.
For code work, retrieval precision matters.
Four relevant files can be more useful than forty loosely related ones.
Is your AI bill really a context bill?
Check everything that happened this month:
- Agents repeatedly search the same repositories
- Similar tasks trigger similar file exploration
- Senior engineers regularly add missing architectural context
- Agents read many files before making small changes
- Reviewers reject work because it duplicates something elsewhere
- Long sessions become noticeably more expensive
- Developers restart sessions when accumulated context becomes noisy
- Different engineers make assistants rediscover the same system knowledge
Score
0–2 checked → Your main cost problem probably sits elsewhere.
3–5 checked → Context retrieval may be a meaningful part of the bill.
6–8 checked → You're repeatedly paying models to rediscover organizational knowledge.
METR's 19% result is a warning about self-assessment, not a verdict on AI coding
One of the most frequently cited AI-coding productivity studies comes from METR.
In its randomized controlled trial, experienced open-source developers took 19% longer to complete tasks when allowed to use AI tools. Before the study, they expected AI to make them 24% faster; after completing the work, they still estimated that it had made them around 20% faster. METR publishes the methodology and results here.
The sample matters enormously: 16 experienced maintainers, 246 real issues and repositories those developers had worked on for years. METR itself has repeatedly warned against generalizing the result into “AI makes software developers slower.”
METR also updated its research direction in February 2026 after later data suggested the impact of newer tools might be different, while acknowledging substantial uncertainty and selection effects. The update is available here.
If the tooling feels faster while retries, review time or cost per accepted task move in the wrong direction, measure the workflow.
Context becomes infrastructure when the same knowledge gets rebuilt repeatedly
A coding agent working on an unfamiliar system can reconstruct context during each session.
Or the organization can maintain a reusable context layer that already knows where relevant implementations, dependencies and relationships live.
Tentaro is built around the second model.
Tentaro describes itself as an on-prem AI-powered code context platform. Its internal product boundary is also explicit: it doesn't generate code. It extracts code context and makes that context available to engineers and compatible AI assistants via MCP.
Tentaro's internal dogfooding has covered 100+ repositories built over 15 years of enterprise delivery. That number describes the real multi-repository code estate on which the product has been used internally, not a published maximum repository limit.
The architectural idea is straightforward.
Instead of asking a frontier coding model to rediscover:
- where authentication is implemented
- which repository already contains a similar abstraction
- what depends on a service
- where a method is called
- which implementation is relevant
the context layer retrieves that information first.
The expensive model can spend more of its work on reasoning and less on archaeology.
Five numbers we'd put next to your DORA metrics
You don't need a new FinOps platform to start understanding agent economics.
Start with five internal measures.
1. Tokens per accepted task
How many tokens did the complete workflow consume before something useful was accepted?
2. Attempts per accepted task
Track how often the first implementation survives review.
3. Retrieval share
Estimate how much of the workflow is spent locating and reading information versus modifying or generating.
4. Cache hit rate by step type
The coding-agent trace study shows why a single aggregate hit rate can hide different behavior around autonomous tool calls and human-initiated turns. See the workload analysis.
5. Cost per merged PR
Don't compare this blindly between teams because PR size and workflow differ. Use it as an internal trend line.
If the same team's cost per merged PR climbs while API prices fall, you've learned something much more useful than another vendor pricing comparison.
Monthly AI Coding Economics Review
MODEL ECONOMICS
- AI coding spend this month
- Effective price per model used
- Spend by model tier
WORKFLOW ECONOMICS
- Tokens per accepted task
- Attempts per accepted task
- Cost per merged PR
- Review minutes per accepted task
CONTEXT ECONOMICS
- Retrieval/tool calls per task
- Files inspected per accepted task
- Repeated retrieval patterns
- Human-added context frequency
- Cache hit rate: human-initiated vs tool-driven steps
QUESTION TO ANSWER
Did cost rise because reasoning got more expensive, or because we're buying more retrieval and retries?
CTA:
Use this scorecard on one team for 30 days
What NOT to optimize first
Move everything to the cheapest model
Cheap tokens don't guarantee cheap completed work. Compare success rate, attempts and review time alongside API cost.
Put hard quotas everywhere
Usage controls can be necessary at scale. Uber's roughly $1,500 monthly cap per employee and per coding-agent tool is a real example. TechCrunch reported the policy in June 2026.
But a quota tells you how much you're willing to spend. It doesn't tell you why you're spending it.
Fill the largest possible context window
Long-context research gives us little reason to assume that “more” is automatically “better”. Controlled studies have found degradation with increasing context length even under strong retrieval conditions. See the 2025 perfect-retrieval experiment and the 2026 bug-fixing study.
The better sequence is:
measure → route → retrieve precisely → cache → cap where necessary
Falling token prices are exposing a different problem
Cheaper models are good news.
But consumption is changing faster than the price list.
The move toward autonomous coding agents creates longer workflows with more tool calls, more repository exploration and more material for humans or automated systems to verify. Gartner explicitly identifies rising token consumption and consumption-based pricing as the reason it expects AI coding costs to keep climbing. Its June 2026 forecast is available here.
That is how both things can happen at once:
The tokens get cheaper.
The workflow buys many more of them.
Before negotiating another model discount, take one heavily AI-assisted repository and measure:
- accepted tasks
- attempts
- token consumption
- retrieval activity
- review time
Then work out where the cost actually accumulates.
If the frontier model is spending a meaningful part of its workflow rediscovering facts your organization already knows, price per million tokens isn't the only lever left.
Context is another one.
Find out how much of your AI workflow is context reconstruction
Start with one repository.
Tentaro can index the code and serve grounded context to compatible assistants through MCP, giving your team a way to compare repeated repository exploration with a workflow where relevant context is already retrievable. Tentaro's current positioning and shipped product boundary are context-first rather than code generation.
