Platform Engineering24 August 20267 min read

Building Governed AI Agents — Part 11 of 17

Before you optimise AI coding costs, instrument every turn

A session total tells you that something was expensive. Only a per-turn view tells you which turn made it expensive, and therefore what to change.

#AI Engineering#Platform Engineering#FinOps#Observability

A monthly electricity bill tells you the house used power. A smart meter tells you the geyser came on at three in the morning and ran for six hours. Both are true, only one is actionable, and the difference between them is resolution.

Most teams running coding agents have the bill. Some have per-session totals, which is better. Very few have per-turn data, which is where the answers actually are.

A per-turn view of one sessionTurnInputContext deltaCacheRelative cost4148k+2k97%baseline4251k+3k97%baseline43214k+163k98%step change44219k+5k98%high, and stays high
Figures are illustrative, chosen to show the shape rather than to report a real run. The session total tells you this was expensive; only the third row tells you why.

What the table shows that the total does not

The session total for that run says it was expensive. It offers no opinion on why, so any fix is a guess: maybe shorter sessions, maybe a cheaper model, maybe tell people to be more concise.

The third row answers the question. Context stepped up by 163,000 tokens in a single turn, and every subsequent turn in that session paid to carry the increase. Go and look at turn 43 and you will find something specific: a directory read, a large file opened into the main thread, a log dump pasted in. That is not a policy problem, it is one identifiable action with an identifiable alternative.

The fourth row is the part people miss. The delta drops back to a normal +5k, so a per-turn cost chart looks like it recovered. It did not. The level is permanently higher, and it stays higher for the rest of the session. Context damage is cumulative, which is why the delta and the level have to be read together.

What to capture

Six fields per turn is enough to do real work:

  • Turn number, so a spike has an address
  • Model, because mixed-model sessions are common and the attribution matters
  • Input size, the actual context sent
  • Context delta, the change from the previous turn
  • Cache percentage, useful as a change detector rather than a health score
  • Estimated cost, so the numbers mean something to someone outside engineering

Estimated is fine. This data is for finding causes, not for reconciling an invoice, and waiting for billing-grade accuracy is a common way to end up with nothing. Reconciliation is a separate job with a separate source, covered in the three views article.

The five diagnostics

Once per-turn data exists, five questions can be answered that were previously matters of opinion.

Five diagnostics, and the question each one answersCache hit rateInput-to-output ratioTokens per session, and the spreadTop ten sessions by costReasoning tokens as a share of outputHow much repeated context was discounted?How much are we carrying per unit of work?Is this an average problem or a tail problem?Which specific sessions produced the bill?Are we paying to think or paying to answer?
None of these require a new platform. They require that the turn-level data exists at all, which for most teams is the actual missing piece.

Cache hit rate. Watch for changes rather than levels. A drop means the shape of the context changed.

Input-to-output ratio. The clearest single measure of context discipline, and the one that translates for a non-technical audience.

Tokens per session, and the spread. The spread is the important half. If the distribution has a long tail, you have a small number of sessions to investigate rather than a general problem to campaign about.

Top ten sessions by cost. Not a summary of them. The sessions themselves, opened and read.

Reasoning tokens as a share of output. Whether you are paying to think or paying to answer. A high share is not automatically wrong, hard problems deserve reasoning, but it should be a decision rather than a default applied to trivial work.

Reading the expensive sessions is the actual work

There is a strong temptation to stop at the dashboard. Resist it. The dashboard identifies which sessions to look at; the insight comes from opening them.

What you typically find is mundane and fixable. Somebody read a large generated file into the main thread. An agent retried a failing operation eleven times, each retry carrying the full context. A session was left open over a weekend and resumed on Monday with four days of unrelated history. A task that should have been three separate sessions was done as one because closing a session felt like losing progress.

None of these are model problems and none of them require a platform change. They are habits, and once a team has seen the per-turn view of their own worst session, the habits change without anyone needing to enforce a policy. That is the real return on instrumentation: it makes an invisible cost visible to the person who caused it, close enough in time to matter.

Instrumentation comes before optimisation

This is the principle worth carrying out of the article, and it is not specific to AI.

Every optimisation made without measurement is a bet. Sometimes the bet pays, which is worse than if it had not, because it confirms a method that will fail later. Measuring first is slower for about a week and faster after that.

There is also a governance dimension. An engineering team that can explain its AI spend in terms of specific sessions and specific behaviours is in a very different position when the finance conversation happens than one that can only offer a total and an intention to be more careful.

What good looks like

Per-turn data captured by default, for every session, without anyone opting in.

Six fields: turn, model, input size, context delta, cache percentage, estimated cost.

Delta and level read together, because a spike that recedes has still raised the floor.

An alarm on context delta above a threshold, so a spike is noticed the same day.

A standing habit of reading the top ten sessions, not just charting them.

Practical checklist

  • Turn on per-turn logging before changing anything else
  • Capture context delta, not only context size
  • Set a delta threshold that triggers an alert
  • Chart the distribution of session cost, including the tail
  • Open and read the ten most expensive sessions each month
  • Accept estimated cost figures; do not wait for billing-grade accuracy
  • Feed what you find back as habits, not policies

How CloudNala can help

Getting per-turn telemetry out of the tools a team already uses is usually a short piece of work, and it changes the conversation more than anything downstream of it. We help set up the capture, build the five diagnostics on top of it, and run the first pass through the expensive sessions with the team, because the second and third of those are where the behaviour actually changes.

The five diagnostics and the per-turn field list here follow Andrew Baker's August 2026 article on instrumenting coding agents.


Work with CloudNala

CloudNala helps organisations move from technology ambition to practical execution across cloud, AI, data, platform engineering and digital services.

Whether you are exploring AI, modernising your cloud environment, building a public-sector digital service, or turning an idea into a working MVP, we can help you shape the roadmap and deliver the next step.

Book an AI Readiness Workshop or write to us at consult@cloudnala.co.za