The argument for these tools is usually made on time. It is cheaper to spend a few pounds of inference than an hour of salary, and nobody with a calculator disputes it for a single task.
The arithmetic stops being obvious once the loop runs unattended, in parallel, for hours. I wanted to know where the crossover actually sits, so I worked it out rather than assuming.
Table of contents
Open Table of contents
Both sides of the comparison
A mid level engineer in the UK on sixty thousand costs an employer somewhere around seventy eight to eighty four thousand once you add employer national insurance, pension, equipment and premises. In London the range runs higher, with a fully loaded figure between eighty five and a hundred and twenty five thousand being normal at a multiplier of about one point three. Contract rates land in a similar place, with a median around forty seven pounds an hour and five hundred a day being an unremarkable number.
Call it sixty pounds an hour fully loaded for an experienced person, allowing for the fact that nobody delivers seventeen hundred productive hours a year without holiday, illness and meetings taking their share.
On the other side, published prices per million tokens as they stand in October 2026.
| Model | Input | Output |
|---|---|---|
| GPT-6 Luna | $0.10 | $0.50 |
| Gemini 3.1 Flash-Lite | $0.25 | $1.50 |
| Claude Haiku 4.5 | $1.00 | $5.00 |
| Gemini 3.1 Pro | $1.35 | $6.75 |
| Gemini 3.5 Flash | $1.50 | $9.00 |
| Claude Sonnet 5.5 | $2.00 | $10.00 |
| GPT-6 Sol | $2.00 | $10.00 |
| Claude Opus 5.5 | $4.00 | $20.00 |
| GPT-6 Astra | $10.00 | $50.00 |
| Claude Fable 5.1 | $10.00 | $50.00 |
Exactly a hundred fold between the cheapest and the dearest, on both input and output, which matters later. Note also that the previous generation is not uniformly cheaper than the current one: GPT-5.6 Sol sits at five and thirty, more than double the price of the GPT-6 Sol that replaced it. Running an older model to save money is worth checking rather than assuming.
The first number
At sixty pounds an hour, and converting roughly, an hour of engineer time buys about four million output tokens at top tier rates. Twenty million input tokens.
Four million output tokens is an enormous amount of generated text. A substantial coding session might produce a few hundred thousand. On that comparison the model is somewhere between ten and forty times cheaper per hour than the person, and this is the calculation everybody does.
It is also the wrong calculation, because output is not where the money goes.
The money is in what you resend
The API is stateless. Every turn of an agentic loop resends the entire conversation so far, and the input bill grows with the square of the conversation length rather than linearly.
Take an agent running a long task. Fifty turns, an average context of a hundred and fifty thousand tokens, two thousand tokens of output per turn. That is seven and a half million input tokens and a hundred thousand output tokens. At top tier rates the input costs thirty dollars and the output costs two. The part everybody worries about is six percent of the bill.
Scale it to something realistic for unattended work. An agent running for eight hours, five hundred turns, same context size. Seventy five million input tokens, a million output. Three hundred dollars of input, twenty dollars of output. Against eight hours of engineer time at sixty pounds, call it six hundred and forty dollars, the model is still cheaper, but only by a factor of two.
That is a very different conclusion from forty times cheaper, and it came entirely from counting the input properly.
Where it crosses over
Three factors move you past the engineer.
Running them in parallel. Ten agents on that eight hour task is three thousand two hundred dollars against six hundred and forty for the person. The comparison people make is one model against one engineer, and that is not how anybody uses them once the tooling gets good.
Paying top tier rates for work that does not need it. That same eight hour loop costs three hundred dollars of input on Claude Opus 5.5 and about seven on GPT-6 Luna. Most of the turns in a long agentic run are not hard, and the hundred fold spread is the difference between a rounding error and a line item.
Not caching. This is the big one and it gets its own treatment in the next piece, because it moves the number by an order of magnitude on its own. Cached input reads at roughly a tenth of the normal rate, sometimes a twentieth on the larger models. That three hundred dollar input bill becomes thirty or forty if the stable part of the context is cached, and the entire crossover moves back out of reach.
So the honest version is this. A single agent, cached, on a sensible model, is dramatically cheaper than the person. A fleet of them, uncached, at top tier, on work that did not need the top tier, is comparable to hiring someone and possibly worse.
The factor everybody leaves out
All of the above compares inference against salary as though the engineer stops existing. They do not. The engineer is reviewing the output, which is the part that did not get faster.
If an agent produces eight hours of work that takes two hours to review properly, the real comparison is three hundred and twenty dollars of inference plus a hundred and sixty of review against six hundred and forty of doing it directly. Still favourable, by less than the raw numbers suggest, and it degrades fast if the review takes longer than you assumed or if the work has to be redone.
The number that matters is cost per completed and accepted task, not cost per hour of autonomous operation. A cheaper model that needs three attempts is not cheaper. An agent that runs all night and produces something nobody can review is not an eight hour saving, it is a three hundred dollar loss plus the review time it consumed before being abandoned.
What I would do with this
Measure the input to output ratio on your actual traffic before optimising anything. If you are like most of the workloads I have looked at, input is somewhere between ten and thirty times output by volume, and your intuitions about where the money goes are wrong.
Then check your cache hit rate, because the single largest lever is already available and most teams have it silently switched off without knowing.
Then, and only then, think about model choice. The hundred fold price spread is real and tempting, and it is the third lever rather than the first, for reasons the next piece goes into.