Guide 2 of 5

What an AI coding agent costs per ticket, and how to cap it

Last updated 25 September 2026

The problem

When a person works on a ticket, the cost is their time, and they notice when they are stuck. An unattended agent doesn't notice. It keeps going, and it spends money on every step. If nobody is watching, the first sign that something went wrong can be the invoice.

So there are two questions. What does one ticket normally cost? And what stops a bad ticket, or a bad month, from costing far more? This guide answers both, with the numbers we have measured ourselves.

Where the money goes

An agent run has two bills.

Model usage. You pay your AI model provider for the text the model reads and the text it writes.
Machine time. You pay your cloud account for the virtual machine (a rented computer) that holds a copy of your code while the agent works on it.

Model usage is measured in tokens. A token is a small chunk of text: a short word, or part of a longer one. Providers charge a price per million tokens, usually more for tokens the model writes than for tokens it reads. The instructions, the ticket, the files the agent opens and the output of the tests it runs all count as tokens the model reads.

The machine is cheap by comparison. In six real runs, installing tools and building the project took about three to four minutes and cost about half a cent. Model usage in the same runs cost between 19 cents and $2.35.

On the same scale, the machine barely registers. Model usage is the cost to manage.

Model usage, cheapest of six real runs: $0.19.
Model usage, dearest of six real runs: $2.35.
Machine setup (installing tools and building the project) in the same runs: about $0.006.
All three bars use the same scale, from $0 to $2.50.

That has a practical consequence. Saving money on the machine is almost pointless, and it can backfire. Anything that throws away a half-finished run throws away the model spend already sunk into it.

Technical detail: why we don't use cheaper, interruptible machines

Cloud providers sell discounted machines that they can take back at short notice. By our arithmetic, the discount would save roughly 3.5 cents a run. One interruption, though, loses the whole run, because a half-finished session can't be resumed. Our early estimate was that a long run could cost $5–15 in model usage, so the discount only pays off if fewer than about 3 runs in 1,000 are interrupted. The downside is about 300 times the upside, so every run uses an ordinary machine.

The same arithmetic rules out a prepared machine image (a snapshot with the tools already installed). It would save the half-cent of setup: about a thousandth of a run's cost. In exchange you would have to build, patch and store images in every account.

What drives cost up

An agent works in turns. In each turn, the model reads the conversation so far, then takes one step: open a file, make an edit, run a test. The result of that step joins the conversation, and the next turn reads all of it again.

That is the key to agent cost. The first turn is cheap. Every later turn rereads everything before it, so each turn costs more than the one before, and a long run costs far more than twice a run half its length.

Illustrative: every turn rereads the start plus everything since. The total is the sum of all the bars.

Illustrative example, not measured data.
Turn 1: the model reads only the starting context: instructions and the ticket.
Each later turn reads the same starting context again, plus the whole conversation so far.
By turn 8 the model is reading several times as much as on turn 1.
The run costs the sum of all the bars, so cost grows faster than the number of turns.

From there, the things that push a ticket's cost up are easy to name:

More turns. A session that tries, fails and tries again rereads its own failures every time.
A large starting context. Long instruction files, big files opened whole, and noisy test output are all reread on every turn. In one test, a session that did nothing but start up cost $0.44, just to read about 44,000 tokens of starting context.
Unclear tickets. An unattended agent can't ask a clarifying question. It guesses, and it often produces a confident change to the wrong thing. That run's whole cost is wasted.
Tickets that are already done. An open ticket isn't always unfinished work. When we checked our own tracker, 3 of 5 hand-picked "top tickets" had already shipped.
Automatic retries. Retrying a failed ticket usually repeats the same failure at the same price.
A bigger model or a higher effort setting than the ticket needs. Many models let you choose how hard they think. More thinking means more tokens.
A broken environment. If the tests can't run, the agent spends turns finding that out.

Real numbers from our runs

These figures come from our own runs on our own product's repository in September 2026. It's a small sample, and the per-run cap below will be re-measured as more runs come in.

What	Cost	Where it comes from
Model usage per run	$0.19 to $2.35	Six real runs
Preparing the machine (tools and build)	About half a cent	The same six runs
A small test ticket on a smaller model	$0.32, 14 turns	First full run: draft pull request opened, machine gone about 6 minutes after launch
A test ticket whose tests ran out of memory	$0.87, 57 turns	The agent correctly refused to commit untested work, so nothing came of the spend
A session that only started up, larger model	$0.44	The cost of reading its starting context once
Expected typical ticket, larger model, medium effort	About $1 to $2	Our working estimate, not yet a measured average

Two lessons stand out. The fixed cost of starting a session is real, so a trivial ticket is never free. And the most expensive run is often the one that produces nothing, like the 57-turn run that hit a broken environment.

Caps on one run

Good habits lower the typical cost. Only hard limits bound the worst case. Each run gets three, and whichever is reached first ends the session.

A dollar cap. The session stops once its model spend reaches the cap.
A time limit. The machine is set to shut itself down, and delete itself, when the time is up, whatever the agent is doing.
A turn limit. The session stops after a fixed number of steps.

Whichever limit is reached first ends the run. Here it's the dollar cap.

Illustrative run. The limits are the ones in our own setup.
Spend: the meter fills to the $4 session cap. One last reply goes slightly over, still inside the $5 reserved for the run. The session stops.
Time: the run has used part of its 90 minutes. The last 10 minutes are always kept for checking and publishing.
Turns: the run has used fewer than half of its 100 turns.

Two details matter here. The dollar cap sits below the amount set aside for the run, because the cap is checked only after each reply, and one reply can take the session a little past it. And the time limit is enforced by the machine itself, not by the agent, so a stuck agent can't talk its way past it.

Technical detail: the limits and how each is enforced

Reserve and cap. Each run reserves $5 of budget. The session's own spend cap is 80% of that, $4, so a one-reply overshoot stays inside the reserve.
Time. The first line the machine runs at boot, before anything else is downloaded, schedules a shutdown at 90 minutes. The machine is set to delete itself on shutdown rather than pause, because a paused machine keeps billing for its disk. The model session gets its own timeout that ends 10 minutes before the shutdown, so the checks and the push are never cut off halfway. If setup leaves under 5 minutes for the session, the run doesn't start it.
Sweeper. Every 15 minutes, a separate process deletes any machine still running 15 minutes past its limit and raises an alert. It should never fire. If it does, the first two defences failed.
Turns. 100 per session, set per repository.
Effort. The effort level is always set explicitly, at medium. The model tool's own default is higher, and costlier, than most tickets need.
Recording. Each run posts its cost, turn count, duration and how it ended (finished, hit the dollar cap, hit the turn limit, timed out) on the ticket, so the caps can be re-derived from measured runs.

The monthly budget

Per-run caps bound one run. They don't bound the month: forty well-behaved $4 runs are still $160. A monthly budget closes that gap. There are two ways to enforce one.

A spending limit at your AI model provider. Give the agent its own API key under a project with a hard monthly limit. The provider refuses requests once the limit is hit, even in the middle of a run. This is the stricter option and the one we prefer. It also limits the damage if that key ever leaks.
A check before every launch. Before starting a run, read how much has been spent this month. Launch only if the money left covers one more full run. If the spend can't be read, don't launch.

That last rule is the important one. When a budget check fails, it's tempting to shrug and launch anyway. But the check exists for exactly the case where nobody is watching. A check that lets runs through whenever it breaks would stay broken while the money was spent. A refused launch costs one skipped run.

Illustrative: caps turn a runaway month into a flat line under the budget.

Illustrative example with a $25 monthly budget and $5 reserved per run.
Both months start the same: a few runs costing between $0.80 and $2.30.
On day 7 a run gets stuck. Without caps it spends $12. With caps it stops at $4.
Without caps, the failed ticket is retried automatically on day 8 for another $10, and spend passes the budget.
Without caps, spend keeps climbing past $35 by day 16.
With caps, new launches stop once less than $5 of the budget is left, and spend levels off under $25.

The budget also tells you how many runs a month you're paying for, roughly the budget divided by the reserve per run. A $300 budget with $10 reserved per run allows about 30 runs. In practice, other limits usually bind first, such as how quickly people review the pull requests (see Too many AI pull requests to review?).

Technical detail: the pre-launch budget check

This mode is for accounts whose provider can't set a hard limit. It reads month-to-date spend from the provider's cost report, which usually needs a separate administrator credential, not the key the agent runs on. The month starts at midnight UTC on the 1st.

It launches only if monthly budget − spent so far ≥ one run's reserve. A gate that fires only after the ceiling is breached hasn't prevented anything.
It refuses to launch, and raises an alert, if there is no credential, the request fails, the response has an unexpected shape, or the amount is in a currency it doesn't understand. "Couldn't read the budget" is never treated as "the budget is zero".
If the report covers your whole organisation, other API use counts against the agent's budget. That errs toward not launching. Scope it to the agent's own project to count only its spend.
The launch gates run in order, and the budget comes second: first "is there a ready ticket?", then "is there budget?", then "is a run already going?", then "was there a launch in the last 25 minutes?". The cheapest refusal comes first.

Spend nothing on the wrong ticket

Caps bound the damage of a bad run. The cheapest run, though, is the one that never starts because it would have been wasted. Four habits do most of the work:

Check the ticket before starting a run. A quick automated check asks whether the ticket says what "done" looks like, where the change goes, and whether a decision is still open. A ticket that fails goes back to its author with what's missing. See Is this ticket ready for an AI coding agent? In a simulation on 30 of our own tickets, our earlier checks would have let 8 tickets into runs that were wasted. The reworked checks let 2 through.
Skip tickets that have already shipped. If recent history shows the ticket was fixed, don't work it again.
Never retry automatically. A failed ticket is marked and waits for a person to look at it.
Match the model to the ticket. Small, clear tickets can run on a smaller, cheaper model at lower effort.

Give the agent its own API key with its own monthly spending limit at your AI model provider. It's the one cap that still holds if everything else fails, including a leaked key.

In practice with BacklogBeast

BacklogBeast runs in your cloud account, on your AI model provider key, so both bills are yours to see and neither passes through us. Every run has a dollar cap set below its reserve, a time limit the machine enforces on itself, and a turn limit. Each run records its cost and turn count on the ticket. The monthly budget is either a hard limit at your provider or a check before every launch, and that check refuses to launch when it can't read the spend.

Before any of that, BacklogBeast checks each ticket, skips ones that have already shipped, and sends unclear ones back with what's missing, without booting a machine. A ticket it judges confidently small can run on a cheaper model. Failed tickets are never retried on their own. A limit on open draft pull requests keeps runs at the pace your team reviews them. If that sounds like the right shape for your backlog, join the waitlist.