Agent billing
per turn, per wait, per active CPU

On September 25, two platforms shipped agent products on the same day, and the sentence each one wrote about billing could not have been more different. n8n was blunt: one turn with an agent is one execution, and tool calls to workflows or sub-agents are not counted separately. DigitalOcean argued the other way: an agent idles through most of its session, waiting on models, tools and people, so it bills on active CPU and peak memory, and the waits in between cost nothing.

Read as commercial terms, those sentences are trivia. Read as architecture, each one describes a different system. The unit a platform charges by decides which task shape is cheap on it, and that decides what you will end up building.

A session’s timeline decides who pays for the waiting

Spread a session out along a timeline and the time alternates: thinking burns compute, then the agent waits. There are three sources of waiting, a model returning, a tool responding, a human approving. None of the three produces anything a user sees, and together they usually take longer than the compute does.

DigitalOcean states it as the whole story: agents idle through most of their session, and that is agent economics in one line. If you are billed on provisioned capacity, you are paying for the waiting. Charging on active CPU and peak memory deletes the waiting from the invoice.

n8n goes the other way and puts the unit on the turn. One conversational turn is one execution, and calling workflows or sub-agents inside that turn is not billed again. The invoice follows how often you ask, not how long it thinks.

The previous meter left a habit behind

None of this is new; the meter is. The last generation of cloud counted the virtual machine hour, customers paid for compute whether it was working or waiting, and that meter trained a twenty-year habit: keep the machine busy, because idling costs money.

An agent does not run that way. DigitalOcean describes the shape precisely: it thinks in tokens and acts in short bursts of compute, then waits; it may need four copies of itself this afternoon and none overnight; by tomorrow morning its working state has to be picked up on another machine, possibly by another person or another agent. Its natural units are tokens consumed, seconds of real execution, and state that outlives the session.

Trading VM hours for tokens and execution seconds sounds like a bookkeeping change. The people who wrote the announcement say plainly that it is not: it changes how you architect a cloud, how you secure it, and how you bill for it.

Two meters, two shapes made cheaper

Put the meters back into the architecture and each one rewards a different shape.

A per-turn meter rewards one question that triggers a long chain of tool calls: workflow calls and sub-agents inside the same turn are free, and the invoice is tied to the number of turns. What it penalises is convergence by conversation, where a user and an agent go back and forth ten or fifteen times, each turn counted separately. A retry inside a turn, or the same tool called three times, looks the same as a clean pass on that invoice.

An active-compute meter rewards long waits and wide parallelism, because waiting is free, so a session parked on an approval no longer needs to be designed away. What it penalises is context size: peak memory is billed, so a very large context held resident comes back as a compute cost.

One detail is easy to skim past. n8n states its own boundaries in the announcement, preview status, extra setup for self-hosting, Enterprise support still to come, and a recommendation to keep human approval on anything sensitive. Those are not legal boilerplate. They are selection conditions, because preview behaviour and preview pricing both move, and building a long-lived architecture on a preview tool is tuition you pay later.

Our judgment: the meter is an architecture constraint

The shape a platform charges for is the shape it makes smooth, and that pull eventually writes itself into your system. If your shape is a user asking once while the agent works for half an hour across three approval waits, a per-turn meter makes your invoice a function of how many approvals you have rather than how much work happens. If your shape is one instruction firing forty tool calls, an active-compute meter means the numbers to watch are the concurrency peak and the memory footprint, not the call count.

That fixes the order of operations. Measure your own task shape first, then check which meter punishes it. This has to happen before selection, because once a platform is in place, orchestration, retry policy and the placement of approvals all grow into its meter, and switching platforms costs far more than switching models.

We would write the counting rule into the design document, next to concurrency limits and timeouts, rather than leaving it in a procurement annex where nobody building the system ever reads it.

The meters stack, they do not compete

Three meters are not alternatives, they are layers. Model calls are still billed per token, and the platform adds an execution charge on top, so the two layers meter different parts of the same task. What has to be settled is which part each layer charges for, and which part dominates your shape.

In the same week a third platform folded evaluation, identity-scoped authorisation and trajectory views into its agent platform. The control plane is turning into a platform built-in, which means the meter travels with whatever defaults the platform ships. Meter questions get settled at purchase, or they get learned again from a strange invoice.

Three questions before signing

• How is one interaction counted? Is it one conversational turn, or one tool call? Are workflow calls and sub-agents inside the turn billed again?
• Is idle waiting billed? Two hours parked on an approval, forty seconds waiting on an external API. Do either of those show up as zero on your invoice?
• Who pays for failed retries?If a task retries three times, is that one charge or three, and does it change when the retry is triggered by the platform’s own recovery logic?

All three answers belong in the contract along with a notice obligation when the meter changes. There is also a more practical demand to make: per-task records you can export, with turns, tool calls, waiting time and peak memory. Without those numbers you cannot measure your own shape, and you cannot predict which way the invoice moves when the meter changes.

Measure your own shape before you shop

One internal job belongs ahead of vendor selection. Record turns, tool calls, waiting time and peak context per task in the pipeline you already run, two weeks is enough for a distribution. With that distribution in hand, selection stops being “who is cheaper” and becomes “whose meter favours my shape”. The first is a feeling; the second can be checked.

The payoff is not only cost. Once you know where your tasks wait and for how long, you also know which waits can run in parallel and which can be removed. None of that optimisation needs a vendor’s help, and all of it can start today.

What the meter usually gets wrong

Retries are the most common miss. Automatic recovery looks like reliability the platform throws in, but under a per-turn meter an automatic retry is a new execution, and the extra charge arrives without a label. The second miss is the long tail: one or two sessions that run all night lift a monthly bill under provisioned capacity and leave almost no trace under active compute. The third is people, an engineer holding a session open while an approval clears, time that lands in a completely different category depending on the meter.

None of those three can be computed from a pricing page. They can only be reconciled against per-task records, which is why we treat those records as a precondition rather than a feature request. The meter is written on paper; the invoice grows in the data. Only the two matching counts.

Run one task through both meters

The argument can be settled on a single task. Take a refund approval: the user asks once, the agent clarifies over fifteen turns, calls tools forty-five times in total, spends ten minutes waiting on a human approval, and holds a peak context of 80,000 tokens while it works.

• Per-turn meter. That task produces fifteen executions. The forty-five tool calls are not billed again, the ten minutes of waiting cost nothing, and one more clarifying question from the user adds one more turn to the invoice.
• Active-compute meter. What gets billed is the tens of seconds actually spent thinking and executing, the ten-minute wait is zero, and cost moves toward that 80,000-token peak. Either shrink it or accept it.

Which meter is cheaper for the same piece of work depends on whether turns multiplied by unit price, or active seconds plus peak memory, is the larger number. That comparison has to be done before signing, because afterwards you are living with whichever side has already grown into the architecture.

Three orchestration patterns and the meter each one suits

• One question, a long chain. The user asks once while the agent runs a dozen tool calls and sub-agents inside that turn. Few turns, long chain, so a per-turn meter suits it.
• Convergence by conversation. Information arrives incomplete and gets filled in over many turns. This shape is the most expensive under per-turn billing and the closest to its real consumption under active compute.
• Long-running background batches. Tasks fire in bulk, wait a long time on external systems, run wide but in small slices of compute. Waiting dominates and peak context stays small, which is what an active-compute meter rewards.

The point of that mapping is not to pick the cheapest platform. It is to know which shape you are walking toward while the orchestration is still being designed, because the same business requirement can be built as a clarifying conversation or as one long chain, with entirely different bill structures.

A counter-intuitive result: the meter shapes the product

Per-turn billing does not stay on the engineering side. When each turn is an execution, asking every clarifying question at once, handing over full context in one go, and letting the agent do more inside a single turn all show up on the invoice. So interaction design drifts without anyone deciding to move it, away from asking one thing at a time and toward submitting a structured description up front and letting the system fill the gaps. The second is not obviously more natural for a user, but it is friendlier to the bill.

A meter that does not charge for waiting pushes in a different direction. Its pressure lands on concurrency and memory, so the product feels the question of how many sessions can run at once rather than how many times a user has to repeat themselves. Those two pressures come back into product decisions in completely different ways, which is worth knowing before the choice is locked in.

When the meter is not worth the arithmetic

If your monthly volume sits in the hundreds of calls, meter differences round to noise, and the time belongs elsewhere: defining what finished means for a task, fixing the retry policy, placing the approval in the right spot.

The meter starts to matter once concurrency and waiting become normal, hundreds of tasks in parallel in a day, approvals queueing, external systems answering in minutes. At that point the difference moves from noise to a budget line. The signal for which stage you are in is simple enough: what fraction of your task time is spent waiting rather than computing.

References

• n8n: Introducing n8n Agents (2026-09-25, includes the billing line “One turn with an agent is one execution” and the preview boundaries)
• DigitalOcean: The agent-first cloud, why we built Managed Agents (2026-09-25, active CPU and peak memory billing, idle time at zero)
• DigitalOcean: Harness Runtime pricing (published rates for active CPU and peak memory)
• LangChain: LangSmith Engine and Managed Deep Agents 0.8 (2026-09-25, evaluation, identity-scoped authorisation and trajectory views shipped into the platform)