The number that makes AI look free
Price one piece of work both ways. A support ticket triaged by a model - read it, classify it, route it, draft the acknowledgement - consumes about 500 tokens in and 50 out, which on Haiku 4.5 at published rates comes to $0.00075. The same ticket handled by a person at a $22-an-hour loaded cost, thirty tickets an hour, costs $0.73. That is a gap of roughly 978 times, and every number in it is an assumption you can swap: pay $30 an hour, handle 20 tickets, use a bigger model, the gap stays three orders of magnitude wide.
| Task | Cost / task |
|---|---|
| AI · Haiku 4.5 | $0.00075 |
| A person | $0.73 |
| People vs AI | ~978× |
What one task costs
Ticket triage, modelled · logarithmic scale, every gridline is 10×
Modelled, not measured: triage on Haiku 4.5 at published rates (500 tokens in at $1 / 1M, 50 out at $5 / 1M = $0.00075) versus a person at a $22-an-hour loaded cost handling 30 tickets an hour ($0.73). The scale is logarithmic. The wage, the throughput and the token counts are inputs you should replace with your own; the gap survives any realistic set of them.
Numbers like that make AI feel like an automatic yes, and they are precisely how owners end up disappointed. Because the per-task price is not the decision. It is the smallest number in the room.
The real gate is the build
Between you and those fractions of a cent stands a fixed cost: someone has to build the feature. Wire it to your ticket system, write and test the prompts, handle the edge cases, put a review screen in front of it, deploy it. Whether that is a $3,000 script or a $20,000 integration depends on scope, and it behaves like every other capital decision your business makes: it has to be recovered out of the savings, month by month. AI did not remove that logic; it only made the marginal cost so small that the build is virtually the entire investment. If you are weighing this against buying an off-the-shelf tool, that is its own decision, but the arithmetic below works the same either way.
The break-even formula
The whole model fits in one line: payback in months = build cost ÷ (tasks per month × saving per task), where the saving per task is what a person costs to do it minus what the model costs. Loaded hourly cost divided by tasks per hour gives the human side; the token math gives the AI side. Three inputs, one division, and every one of them is yours to correct: your wages, your throughput, your quote.
The same build at three volumes
| Volume | Break-even |
|---|---|
| 10,000 tasks / mo | ~5 weeks |
| 3,000 tasks / mo | ~3.7 mo |
| 300 tasks / mo | ~3 yr |
The same build at three volumes
Build $8,000; each task: AI ~$0.00075 vs a person ~$0.73 (modelled)
Cumulative cost of people doing the task (three volumes) versus building once for $8,000 and running on AI. Task assumptions as in the chart above; AI usage at these volumes is $0.23 to $7.50 a month, so the amber line draws as flat. Break-even lands at about 5 weeks for 10,000 tasks a month, 3.6 months at 3,000, and roughly 3 years at 300. Swap in your own wage, throughput and build quote; the shape is the point.
This is the chart that settles most build-or-not arguments, because the only thing that changes between the three lines is volume. At 10,000 tasks a month the $8,000 build is recovered in about five weeks; the same build at 300 tasks a month drags on for roughly three years, which in software terms is a different decision entirely. Nothing about the model, the prompts or the quality changed. Volume alone moved the answer from obvious yes to probable no.
The payback table
Find your column, find your quote, and you have a defensible first answer before anyone opens an IDE.
| 300 tasks / mo | 1,000 / mo | 3,000 / mo | 10,000 / mo | |
|---|---|---|---|---|
| Monthly saving | $220 | $733 | $2,198 | $7,326 |
| $3,000 build pays back in | 13.7 mo | 4.1 mo | 1.4 mo | 0.4 mo |
| $8,000 build | 36.4 mo | 10.9 mo | 3.6 mo | 1.1 mo |
| $20,000 build | 91.0 mo | 27.3 mo | 9.1 mo | 2.7 mo |
Two honest readings of that table. Down a column: scope discipline pays, because at 1,000 tasks a month the difference between a $3,000 and a $20,000 build is the difference between four months and two years. Across a row: volume is leverage, because the same $8,000 build swings from a rounding error to unjustifiable depending on how many tasks you actually feed it. When an estimate lands in the grey middle, the cheapest experiment is usually a smaller build that tests the volume assumption, not a bigger build that bets on it.
When the token price does matter
Triage is a cheap task; not everything is. A drafting job that reads a 2,000-token brief and writes a 1,500-token document on Opus 4.8 costs about $0.05 per task, and long-context work can climb well past that. It still compares to $0.37 for a single minute of human time, so the gap survives, but at tens of thousands of tasks the marginal line stops being decoration: it is the difference between the tokens costing $8 a month and $500. That is where part one's hidden multipliers and part two's levers plug into this model: they move the saving per task, which shortens the payback. They rarely flip the build decision on their own, but they decide how good a good decision gets.
What this model leaves out
Honesty about the envelope. If a person still reviews every output, your saving per task is the review-time delta, not the full $0.73, and the payback stretches accordingly; the model earns its keep where it fully closes most tasks and escalates the rest. Errors have a price this formula does not see, so tasks where a wrong answer is expensive need a cheap check in the loop before the volume math means anything. And the build is not the last invoice: prompts drift, systems change, someone maintains the integration. None of that breaks the model; it just belongs in the build column, and a pilot sized to test your volume assumption is the cheapest way to find out what the numbers really are.
