The sticker price of AI is not the true cost of AI-assisted delivery

Most discussion amongst teams when evaluating AI cost starts with the rate card. The characteristics that make up a rate card is normally the following:

• Cost per x input tokens
• Cost per x output tokens
• Maximum context window size
• Usage limits and allowances

This is useful for non-agentic, relatively static AI workloads that do not involve reasoning, tool use, or the capability to autonomously decide what to do next.

Let's use an analogy. We know how much our utility provider charges us per unit of gas, but that does not particularly help us understand how much our bill will be at the end of the month. That bill is impacted by insulation, outside temperature, how often the heating is on, how often doors are left open, and how efficiently the system operates.

Rate cards simply tell you what the provider charges for usage. They do not tell you what it costs to get useful work done.

This article explores

👉 Capability shifts

👉 The challenge for engineers

👉 Rate card can't be the whole answer

👉 Model pricing and delivery economics are different

👉 Capability expands the consumption envelope

👉 Local optimisation can create system waste

👉 Cost per prompt is the wrong metric

👉 Engineering discipline still matters

Capability shifts

Over the last few years, we have seen tremendous shifts in the overall capability and accuracy of AI systems. We have moved from tools with limited training cut-offs and constrained interaction patterns to systems that can access live information, inspect files, call tools, interact with services, and reason through tasks in multiple stages.

This capability uplift is not purely down to model improvement. It is down to improvement of the AI system as a whole.

AI system's ability to reason and break down tasks through incremental token generation has improved, as has its ability to call arbitrary tools to gather information or produce deterministic results, and its ability to discover, inspect, and interact with remote services, documents, and code.

The more capable a model becomes, the more tooling, information, and data it is likely to retrieve. These systems are, after all, optimised to produce accurate and useful results.

The challenge for engineers

As capability grows, the tooling and ecosystem around the model becomes more deeply integrated.

Unfortunately, for engineers, the tools and context a model might need sit on a file system, in a repository, in documentation, in logs, in issue trackers, in CI output, or behind internal services.

Rate card can't be the whole answer

As AI models evolve, so too does their need to consume tokens. With that, the way we evaluate the cost effectiveness of this tooling also needs to evolve.

The cost question can no longer start and end with the rate card. The more useful question is "what is the cost of getting to a correct, useful, production-grade outcome?"

Rate cards tell us the cost of usage, not the cost of value.

Model pricing and delivery economics are different

A cheap model can be expensive if it creates poor-quality work, requires repeated correction, increases reviewer burden, or generates output that looks plausible but does not hold up under engineering scrutiny.

An expensive model can be economically efficient if it reduces cycle time, improves accuracy, lowers the amount of rework required, and gets the work closer to production quality earlier in the process.

Therefore we should assess whether the overall system helps teams move from idea to validated outcome with less waste, less rework, and less human correction.

AI cost has to be evaluated across the full delivery loop:

• How much context does the system need?
• How many tool calls does it make?
• How many attempts does it take to reach an acceptable answer?
• How much human review is required?
• How much rework does it create?
• How often does it produce output that is functionally correct but architecturally poor?
• How often does it accelerate the team versus creating additional coordination overhead?

We should not evaluate AI tooling purely through the lens of token pricing. We need to evaluate it through the lens of delivery economics: throughput, quality, rework, review burden, cycle time, and the cost of correction.

Capability expands the consumption envelope

As models become more capable, it's natural to ask them to do more.

A simple prompt-response interaction is relatively easy to reason about. An agentic workflow is not. A capable coding assistant will do many things such as inspect files, read documentation, call tools, spawn subagents, run tests, review failures, revise its approach, and produce implementation changes.

The cost goes beyond input and output tokens in the final interaction, and now includes the workflow wrapped around the model.

model price × context consumed × workflow depth × retry and rework rate

This is why headline pricing can be misleading. A model may become cheaper per token while the total cost of the AI-enabled workflow increases, because the organisation is now using it for larger, more complex, and more consequential work.

That does not mean the model is poor value. A more capable system may cost more in absolute terms but still create better economics if it reduces cycle time, improves quality, lowers coordination overhead, or gets work closer to production quality sooner.

As the model becomes more capable, the unit of analysis changes. Instead of buying tokens, we begin buying workflow capacity, decision support, implementation acceleration, and, in some cases, partial automation of work that previously required multiple human steps.

Local optimisation can create system waste

To reduce apparent LLM cost:

• Shorten prompts
• Reduce verbosity
• Use cheaper models
• Constrain outputs
• Remove context
• Or force smaller changes.

To drive accuracy up, many teams are adopting tooling such as Caveman for input compaction, and using faux-TDD and DDD to constrain the model.

All of these can help, but only if they reduce the total cost of reaching the desired outcome. Removing nuance and specificity can result in more work for the model, more clarification from the user, or more rework later in the delivery process.

The same is true of superficially disciplined workflows. Genuine human-driven TDD can reduce ambiguity because the tests express intent, constrain the implementation, and create a feedback loop around the desired behaviour.

Faux-TDD driven by an AI can do the opposite if the model is asked to generate the tests, generate the implementation, interpret the failures, revise the approach, and then integrate the result back into the system. In that case, the organisation may have doubled the surface area of the task rather than reduced it.

The prompt may look cheaper, but the workflow may be more expensive:

• More generated tests need to be reviewed.
• More implementation paths need to be inspected.
• More failures need to be interpreted.
• More integration points need to be checked.

All of that can drive more token consumption, more human review, and more rework in pursuit of a correct and trusted outcome.

We've noticed that many cost-saving techniques optimise the local interaction, not the end-to-end system. They make the individual prompt look cheaper, while pushing cost somewhere else.

That does not mean teams should ignore token efficiency. They absolutely should not.

But be wary of wasteful prompting, excessive context loading, unnecessary tool calls, and verbose output. Aim to minimise the cost of getting to a useful, correct, validated outcome.

Cost per prompt is the wrong metric

A better metric than cost per prompt is cost per correctly delivered outcome. For software teams, that might become cost per correctly delivered feature.

A correctly delivered feature is a change that meets the definition of done. It is:

• Reviewed
• Tested
• Integrated
• Observable
• Maintainable
• Secure
• Aligned to the product intent.

That means the cost calculation needs to include:

• Tool usage
• Infrastructure
• Developer prompting time
• Review time
• Rework
• Defect correction
• Rollback risk
• Future maintenance burden.

A useful framing is:

Cost per correctly delivered feature = total AI-assisted delivery cost ÷ accepted features meeting the definition of done

The goal is to make every accepted outcome more efficient, reliable, and valuable.

If organisations want to understand AI economics properly, they need to measure the conversion from AI activity into accepted value.

Useful metrics include:

• AI spend per accepted pull request
• AI spend per deployed feature
• Cycle time from intent to merged change
• Review time for AI-assisted work
• Rework rate on AI-generated changes
• Defect escape rate
• Rollback rate
• Test pass rate after AI-generated changes
• Percentage of AI-generated code accepted without material rewrite
• Human intervention required per completed task

These measures are harder than token reporting, but they are much closer to the truth. They help distinguish between cheap but noisy AI, expensive but effective AI, false efficiency, and actual productivity.

Engineering discipline still matters

Bear in mind that AI increases the return on engineering discipline.

A codebase can give an AI model a narrower and safer path to value. To realise this value, make sure your codebase has clear boundaries, good tests, consistent patterns, reliable delivery pipelines, and strong observability. The model has less ambiguity to resolve, fewer assumptions to make, and fewer opportunities to drift.

In a well-structured system, the model is being guided through a system that expresses intent clearly.

A poorly structured system does the opposite.

The model has to infer intent from inconsistency, missing tests, weak documentation, and fragile integration points. It consumes more context, makes more assumptions, creates more rework, and places more burden on human reviewers. The apparent cost may still show up as model spend, but the real cost is being created by ambiguity in the delivery environment.

Remember, the better the system, the lower the cost of correct delegation. The organisations that scale AI well will not simply be the ones using the cheapest model. They will be the ones that understand, instrument, and control the workflow around the model.

That means investing in:

• Context architecture
• Retrieval
• Model routing
• Tool governance
• Evaluation
• Test strategy
• Delivery telemetry
• Outcome-based cost measurement.

Questions you can ask:

1. Are teams shipping better outcomes?
2. Is cycle time improving?
3. Is quality improving?
4. Is review burden falling or rising?
5. Are defects reducing?
6. Is AI increasing strategic capacity, or just creating more output to inspect?

Principles to adopt:

Do not stop short at measuring the cost of asking the model. Instead, measure the cost of accepting the work.

If the work is not accepted, the prompt was not cheap; it was waste.

If the work is accepted but creates downstream defects, the prompt was not cheap; it deferred cost.

If the work is expensive to generate but reduces cycle time, improves quality, and reaches production safely, it may be economically efficient.