Per-token pricing made sense when a model call was one prompt and one reply. It stopped making sense the moment agents started looping — planning, calling tools, reading the results, and looping again. A single "task" can now burn fifty silent round trips before it ever shows you an answer.
What actually changed
The new pricing charges per completed task, not per token consumed getting there. A task is defined as one top-level agent invocation that terminates in a final response, regardless of how many tool calls or reasoning steps happen underneath it.
- Simple lookups and single-tool tasks got cheaper — often by half.
- Long-horizon tasks with heavy tool use got more expensive, sometimes by 3x.
- Failed or abandoned tasks are now billed at a flat reduced rate instead of full token cost.
If your workload is "ask a question, get an answer," you win. If it's "watch an agent iterate for four minutes," read the fine print before you migrate.
We ran three real workloads
We took three production agent workloads — a support ticket triager, a code review bot, and a research summarizer — and re-priced a week of their actual traffic under the new model.
| Workload | Old cost | New cost | | --- | --- | --- | | Ticket triager | $412 | $198 | | Code review bot | $890 | $1,340 | | Research summarizer | $205 | $211 |
The triager won because most tickets resolve in one or two tool calls. The code review bot lost because it re-reads diffs and re-runs tests across many iterations per task — exactly the pattern per-task billing penalizes.
What to do about it
- Audit your longest-running agent tasks first; they're where the delta hides.
- Cap iteration counts where you can — a bounded loop is now a pricing lever, not just a safety one.
- Re-benchmark before you commit to a migration date. The public calculator undercounts tool-call overhead.
Small builders running simple, single-purpose agents come out ahead here. Anyone running open-ended, multi-step agents should model this carefully before the next billing cycle.