The Agent Bill: Why Agentic AI Costs an Order of Magnitude More Than Chat ​

We · October 2026

This is the fourth and final article in the "AI Agents & Local Automation" series. The first three covered what these tools are, what's on the market, and what it takes to build your own. This one answers the question we get asked most: why does it burn through money so fast?

AI moves fast. The tools, capabilities and numbers in this article describe where things stand right now, and are for reference only. Every price and usage figure was checked against public sources in October 2026—confirm against each vendor's official page before relying on it. All amounts state their currency, and yuan-to-dollar conversions use a rough 1 USD ≈ 7.2 CNY, purely so you can feel the order of magnitude, not to reconcile an invoice.

The short answer: you're not imagining it ​

The most common first reaction when someone moves from a chat tool to an agent is some version of: how is my quota already gone?

That reaction is correct, and it isn't one vendor being greedy. The cost structure itself changed.

Chat is "one question, one answer, one charge." An agent is "one job, dozens of charges." Ask a chatbot something and it reads your question once, writes an answer, done. Ask an agent to finish something and in between it reads the brief, looks things up, calls tools, inspects results, notices a mistake and does a pass again—every one of those steps is a complete model call. For the same request, an agent can consume tens or even hundreds of times what a single chat turn does.

So this is what the ledger looks like: which layer the money actually goes to, why billing models all changed at once, how to work out your own numbers, and whether running locally really saves anything.

Where the money goes: context is a snowball ​

This is the one mechanism worth understanding; once it clicks, everything downstream follows.

Every step an agent takes resends the system prompt, the definitions of all available tools, and the complete record of every previous turn.

The model has no memory. It isn't "remembering where it got to"—it is re-briefed on the entire situation from scratch, every single time. So context compounds like a snowball: a few thousand tokens on turn one, tens of thousands by turn ten, over a hundred thousand by turn twenty. And all of that is billed as input, which is far cheaper per token than output—which produces the counterintuitive result that almost the whole agent bill is spent on re-explaining the background, and comparatively little on the actual work.

Public figures that mark the scale (all checked October 2026):

• Gartner puts agent workflows at 5 to 30 times the consumption of a chatbot, with one request triggering 10 to 20 model calls; the same firm forecasts inference costs rising fivefold before 2028.
• Vendors' own breakdowns are finer: a single agent is roughly 4 times chat, multi-agent collaboration around 15 times, and running a parallel team of agents about 7 times a single instance.
• Data from a model-routing platform, cited by a16z, shows that from February 2026 the token volume generated by agents on that platform overtook volume from human chat, with a daily average of 7.3 trillion in August. We find this more persuasive than the two above: it isn't a marketing number, it's evidence that the usage mix has genuinely flipped.
• On the academic side there are extreme "thousand-fold" findings for long-chain coding tasks. We'll be deliberately cautious here: we could not verify the original write-up directly, so this article won't quote its multiplier. The one thing we'll keep is the direction—on long-chain tasks, a hundred-fold gap is within what public data supports, and the variance between runs is enormous; there are reports of the same task differing by tens of times across two attempts.

Then there are two costs people systematically underestimate, both of them fixed overhead:

Just telling the agent which tools exist burns tens of thousands of characters. Per vendor documentation reported in the press, wiring up five MCP servers means the tool-definition block alone is around 55,000 tokens. You haven't typed anything yet and the background for this turn is already longer than a dissertation. And those 55,000 tokens get resent at every step.

The system prompt itself runs 500 to 2,000 tokens per call, plus 300 to 400 for tool formatting, plus two to five tens of thousands of tokens added each round as history piles up. These come from community measurement rather than vendor commitments, but multiple independent write-ups agree on the order of magnitude, which is enough.

And there's a hidden surcharge: failed retries are billed too. Community measurements consistently conclude that retries and rework push actual spend 30–50% above the sticker price. This one is easy to miss because on an invoice it looks identical to normal usage—you never learn that a third of it was the agent realising it had gone the wrong way and walking back. That's also why the section below insists on acceptance criteria: an agent's rework cost is invisible.

One-line summary of this section: what determines the bill isn't how long your question was, it's how long the task chain is and how much baggage each step carries.

Five billing models, one thing in common: the ceiling is gone ​

Change the cost structure and the pricing follows. Here's what's currently on the market:

One observation deserves its own callout: almost every Chinese product has gone to a credit system, but transparency about the rules varies enormously. Two products both advertising "X credits per month" may use a rolling window that refills continuously, or reset to zero at month end, or make two features share one pool. If you don't read the refill rule, you can easily believe you still have allowance when what you're looking at is next month's.

The direction of travel internationally is from message caps toward usage-denominated credits, and now session-hour billing—one vendor's hosted agent reportedly prices at $0.08 per session-hour (checked October 2026; confirm against official pricing). The very existence of hourly billing is a signal: providers no longer want to assume anything about how long your job runs.

Put the published subscription tiers side by side, yuan and dollars kept separate so conversion doesn't flatter anyone: Chinese office-agent personal tiers cluster around ¥68–99 per month, with further steps near ¥200, ¥500 and approaching ¥1,000, and enterprise editions mostly per seat at roughly ¥198 per seat-month. American coding and editor products sit around $8–30 for personal tiers, $100–200 for high-usage tiers, with a few at $500. We are not going to draw a "which one is the bargain" conclusion here, because the tier definitions contradict each other (the same product appears with three different price ladders in press coverage), and because what each subscription includes and how overage converts differ so much that comparing raw numbers is self-deception.

There is one vendor figure worth quoting, though, because it tells you what heavy usage actually looks like: according to reporting on one major vendor's own enterprise cost documentation, deployment runs at roughly $13 per active user-day, $150–250 per month, with 90% of users under $30 per day (checked October 2026). In yuan that's about ¥94 per person per active day. That is one to two orders of magnitude above most people's instinct, and it describes an average active day, not an outlier.

All these models shifting around produce one common result: a heavy user's bill has gone from capped to uncapped. So what ordinary users most need to learn isn't price comparison—it's judging whether a given task is worth handing to an agent at all. That's the next section.

Do the arithmetic yourself: assumptions on the table ​

Here's the calculation we ran. Three disclaimers first: this is an order-of-magnitude estimate, not a quote; every assumption is written out so you can substitute your own; unit prices are public pricing-page figures checked in October 2026.

Assumed scenario: you hand 100 multi-step jobs per month to an agent (compiling source material into a weekly report, batch-processing documents, moving information between several applications). Each job runs about 15 turns, each turn roughly 30,000 input tokens and 800 output tokens.

Total volume first:

Input outweighs output 37.5 to 1. That ratio is the mechanism from the previous section expressed as a number—you watched it produce very little, while it read an enormous amount of background to do it.

Now apply unit prices, per million tokens, using several published tiers as samples:

From ¥39 to ¥1,836—the same workload, a spread of close to fifty times. That spread isn't "which vendor is cheap"; it's "how smart a model you put on this chain." And the most important row in the table is the market-average one: Chinese API pricing runs an order of magnitude below comparable American models (a quarterly average from an authoritative research firm). That gap is precisely the precondition that makes the "local shell + online API" hybrid from the previous article viable on cost. If the two were priced alike, the hybrid argument wouldn't get anywhere near this strong.

Now the comparison that actually justifies this article's title:

Same 100 jobs, answered one at a time in a chat tool (assume 1,000 input and 800 output tokens per exchange, at the Chinese average unit price): about ¥2.2 per month. Run through an agent on the same unit prices: about ¥247 per month. A little over a hundred times. We derived that multiple straight from the assumptions above—it is nobody's published statistic—but it points the same way as Gartner's 5–30× and the vendors' 4–15×, and the reason it's more extreme is right there in the assumptions: the chain we modelled is 15 turns long. Shorter chains land closer to the official multiples; longer ones approach the "over a hundred" end.

So the judgement we'd like readers to take away is this: the real difference isn't the price per token, it's the number of calls and how much context each one carries. Shortening the chain beats finding a cheaper model—dropping tools you don't use, and splitting one big open-ended job into several small ones with checkpoints, both save more than switching providers does.

One more cost line people overlook: caching. On some light Chinese tiers, cache-hit input drops to ¥0.02 per million tokens—one hundredth of the off-peak sticker price. Which means the agent's "send the same background repeatedly" load can be discounted enormously in the cloud. And as the previous article established, there is no such fallback when you run locally—which is also why local setups are slow and bandwidth-bound on long chains.

Which jobs are worth delegating, and which aren't ​

With the arithmetic done, on to judgement. This section is about task properties, not products.

Worth handing over: batch and repetitive work (renaming, format conversion, data tidying—fixed chains where a failed rerun costs nothing); long chains with a clear acceptance test (weekly reports, summary tables, "make the test suite pass"—things you can verify at a glance); jobs that require shuttling information between several applications; and anything you can leave running overnight unattended. The common thread is "tedious by hand, but obviously done or not done."

Not worth it: one-off trivia (chat is cheaper and faster); creative tasks whose acceptance criteria you can't articulate (the agent will happily burn tokens for an hour in the wrong direction and you'll only notice at the end); requests where you just wanted a paragraph of advice; and decisions where a human has to carry the responsibility anyway—not because the agent can't run, but because if you have to re-do the whole check afterwards, what exactly did you save?

One rule of thumb that we find more useful than any comparison table: first estimate how long the job takes by hand, then estimate what the agent will consume, and let the ratio decide.

Using the numbers above, at the Chinese average unit price a 15-turn multi-step job costs about ¥2.5. So a task that would eat an hour of your time is obviously worth delegating; a task that takes three minutes, you're mostly paying for rework and your own review time.

And repeating that warning, because it matters: an agent's rework cost is invisible, and failed retries are billed normally. You watch a job succeed once and think you paid once; inside it may have retried three times.

Where local deployment actually sits in this ledger ​

The last part has to be honest, and it connects straight back to the capability limits from the previous article.

When local definitely doesn't save money: you simply swapped chat for agents, with short chains and light volume. An online subscription is less fuss, and the money you'd save won't come close to the hardware.

Conditions under which local starts to pencil out (several need to hold at once): high repetition, large volume, runnable overnight unattended, material sensitive enough to matter, and you can accept a capability discount. The previous article was explicit that quantised local models are clearly behind top online models on long multi-step chains, and that discount has to be entered into the cost. The jobs local genuinely handles are a specific set: media processing, voiceover, images, batch translation—subtasks where a local model is already good enough.

Electricity is worth calculating, because it's smaller than you'd think. A high-spec machine drawing 500–800 W at full load, run 200 hours a month, uses roughly 100–160 kWh, which at residential rates is about ¥60–100 (a community back-of-envelope figure, not a measurement). Which means local's cost was never electricity; it's the machine you paid ten thousand yuan or more for upfront, plus the hours you spend configuring it. The only way that amortises is if the machine really is grinding through repetitive volume.

The hybrid is the realistic cost optimum. Complex reasoning and long chains go to an online API; the local model absorbs the cheap, repetitive calls. The community's "give local 80% of the cheap calls" pattern is a common strategy—and to be precise, that's an anecdotal rule of thumb, not measured statistics. The reasoning behind it is sound though: in any metered workload, most calls are repetitive, simple and undemanding, and only a few need a top-tier model. Splitting the traffic is itself the saving.

One last point of consistency with the local-deployment articles on this site: the test for "can local replace online" hasn't changed in the agent era—only the threshold has, from "can it run this model" to "can it finish this chain." Your hardware now has a new grading criterion: whether it sustains 64K+ context across dozens of consecutive calls, not just whether the weights fit in memory. As for the separate problem of getting the same set of models running across different machines, that's already handled by turnkey tooling and is no longer a compile-it-yourself barrier—we've covered that here before and won't repeat it.

Finally ​

This closes the series, so the last thing we want to say isn't about saving money.

An agent's cost structure makes it closer to hiring someone than to looking something up. Reference lookups charge per query; hiring charges for hours, plus your management overhead. You wouldn't evaluate an assistant by asking only "what's their salary"—you'd ask how much time they actually free up, how often you send work back, and what it costs you to check their output.

So the first skill of using agents well isn't finding the cheapest subscription. It's learning to price your own tasks—knowing which job is worth half a yuan, which is worth fifty, and which shouldn't be handed over at all.

That turns out to be the same faculty as taste and judgement. Which is also the one thing this entire series has been circling: the models are rented; the judgement is yours.