Cost of an AI-Assisted Engineering Team
4 min read · updated August 3, 2026
Nobody here has your spend data, and any figure quoted as typical would be someone else’s. What is transferable is the structure of the bill, which is determined by the loop rather than by the tool. Every number below is an input you replace.
Three request shapes, three bills
| Shape | Description |
|---|---|
| autocomplete | Very high frequency, tiny output, small model. Hundreds to low thousands of requests per developer per day, each a couple of thousand input tokens and a few dozen out. Cache-hostile: the prefix changes with every keystroke, so prompt caching mostly does not apply. |
| chat | Low frequency, medium context, medium output. Tens of turns a day. The context is whatever you attached, so the variance between developers is enormous — this is the shape where one person's habit of attaching the whole folder shows up on the invoice. |
| agent | Very low frequency, enormous total tokens. A handful of sessions a day, each dozens of turns, each turn re-sending the whole transcript. This is where the money is, and the reason is arithmetic rather than model choice. |
Why an agent session costs what it does
A conversation is stateless. Every turn re-sends everything before it, so if the context starts at b tokens and grows by g tokens per turn — a file read, a test output, the model’s own last message — then turn i sends b + g·i, and over n turns:
input_tokens(n) = SUM over i=0..n-1 of (b + g*i)
= n*b + g * n*(n-1)/2 <- the quadratic term
ASSUMPTIONS (replace all four):
b = 20,000 starting context: repo map, instruction file, task, 2 files
g = 3,000 growth per turn: a file read plus truncated test output
n = 25 turns before it stops
out= 800 output tokens per turn
input = 25*20,000 + 3,000 * 25*24/2 = 500,000 + 900,000 = 1,400,000
output = 25*800 = 20,000The quadratic term is 900,000 of the 1,400,000 — nearly two thirds of the session, produced by nothing but re-sending. At an assumed $3 per million input and $15 per million output, that is $4.20 + $0.30 = $4.50 for one session.
Now apply caching. The prefix is stable up to the point where this turn’s new material begins, so most of what is re-sent is cache-eligible. Assume 90% of input reads from cache at 10% of the uncached rate: 140,000 tokens at $3/M ($0.42) plus 1,260,000 at $0.30/M ($0.378), so input falls to about $0.80 and the session to $1.10. A four-fold difference, from one property of how the context is laid out. The break-even arithmetic for caching matters more in agent loops than anywhere else precisely because of this term.
The other consequence of the quadratic term: turns are not linear in cost. Going from 25 turns to 50 does not double the session, it roughly triples it. A turn budget is a cost control, not just a safety rail.
A day for one developer
Same treatment, all inputs labelled. Substitute yours; the point is the shape of the total, not the total.
ASSUMED PRICES ($ per million tokens)
frontier: 3.00 in / 15.00 out small: 0.15 in / 0.60 out
cached read: 10% of the input rate
AGENT 4 sessions x $1.10 (from above, cached) = $4.40
CHAT 30 turns x 8,000 in = 240,000 in -> $0.72
30 turns x 600 out = 18,000 out -> $0.27 = $0.99
AUTOCOMPLETE 400 requests x 2,000 in = 800,000 in -> $0.12
400 requests x 30 out = 12,000 out-> $0.01 = $0.13
day = $5.52
x 21 working days month = $116Two things to notice before you argue with the numbers. Agent work is roughly 80% of this bill on 4 requests out of 434 — the meter that feels cheapest per interaction dominates. And autocomplete, the one that fires constantly, is the smallest line, because a small model at a small price times a small output is small however often it runs.
The line that is missing from that table is failure. Sessions that stop without landing anything cost the same as sessions that succeed — arguably more, because they tend to be the long ones that ran to the turn limit. If a third of sessions end without a usable diff, the true cost per landed change is 1.5 times the session cost, and the fix is not a cheaper model but the no-progress stopping rule, which converts a 25-turn failure into a 6-turn one. Track cost per merged change rather than cost per session, or the metric hides exactly the thing worth improving.
The number that will actually surprise you is variance between people. A developer running long agent sessions on a large repo can be an order of magnitude above the median, and the reason is always one of b, g or n. Per-developer attribution is worth having before you argue about a total.
Which term to attack
- Cap
n. A turn budget plus the no-progress stopping condition from the agent page. The quadratic makes this the highest-leverage single control, and stalled turns produce no value anyway. - Shrink
b. The starting context is paidntimes. A 3,000-token instruction file across 25 turns is 75,000 tokens; a 12,000-token one is 300,000. Prune the repo map and the instruction file with the multiplier in mind. - Shrink
g. Truncated test output and line-ranged file reads. Feeding back a full verbose test run every turn is the single most common cause of a session costing four times what it should. - Make the prefix cacheable. Stable material first, volatile last. Anything that changes near the front of the prompt — a timestamp, a shuffled file list — invalidates the whole cache every turn.
- Route by turn type. Not every turn needs the strong model. Summarising a test failure, deciding which file to open next and formatting an edit are cheap-model work; the planning and the hard patches are not.
- Watch reasoning tokens. On models that think before answering, hidden tokens are billed at output rates and are invisible in the transcript — the usual explanation for a bill above what the visible output suggests.
The comparison you actually want
Set against salary, these numbers are small, and that is the honest headline. If a session costs C and saves t minutes of an engineer whose fully loaded cost is R per hour, it pays for itself when:
C < R * t / 60 At C = $1.10 and an ASSUMED R = $100/hour: t > 0.66 minutes Whole-day spend of $5.52 pays for itself if it saves 3.3 minutes a day.
Which reframes the entire budget conversation. At these ratios the token bill is not the decision variable; a rounding error against payroll either way. The decision variable is whether t is positive — and on some classes of work the published evidence says it can be negative, which is the subject of the productivity page. Time spent optimising a $116 monthly bill is time not spent working out which tasks are in the band where the tool helps.
The exception is scale-dependent: a hundred engineers at $116 is $11,600 a month, and an agent loop with no turn cap is one bad afternoon away from a very different number. Budget controls exist for the tail, not for the median — controlling agent spend covers the mechanisms.