Why per-employee AI agents blow the budget: what an always-on agent really costs at team scale

How we modelled this

Three kinds of number appear on this page and they are not interchangeable. Measured means a provider list price, a documented framework default, or a published statistic, each carrying a source and an access date of 2026-08-17. Modelled means arithmetic on those list prices under the assumptions in the table below — every dollar figure in our cost tables is modelled, not an observed bill. Reported means a practitioner posted it publicly: useful, unverified, and biased toward people with a story worth telling.

What does giving every employee an agent actually cost?

Six ways to put AI agents in front of thirty people, priced on identical assumptions. The spread is $205 to $6,286 per month for the same thirty humans and the same category of product. Architecture, not headcount, sets the bill.

Read the table honestly and it does not flatter us. Flat-rate vendor seats at roughly $1,000/month are the safest option on the list for a company where a handful of people do agentic work, because the vendor eats the overage risk and you cannot be surprised. Shared departmental agents beat them on price and do more work, but you own the running of them. The one configuration that loses on every axis is the popular one: an always-on agent per employee at default settings, which is the most expensive option by 5–10× and the only one with no ceiling.

One calibration warning before anyone budgets from this. These figures describe a light business-operations agent at 50,000 tokens per task. Anthropic states Claude Code averages "around $13 per developer per active day" and $150–250 per developer per month, which back-solves to roughly a million tokens per task. Do not price a coding agent off a business-agent model; on identical assumptions they differ by about 20×. For build and retainer pricing rather than run cost, see our AI agent cost guide.

How much of an always-on agent bill is the agent doing nothing?

Between 74% and 97%, centred on 89–94% at realistic adoption rates. The table below takes configuration (d) — thirty always-on Opus 5 agents on the default 30-minute heartbeat — and adds real work on top, then compares it to buying exactly the same work on demand.

Read the penalty column downward and you have the finding. The always-on architecture does not merely cost more — it costs more in inverse proportion to how much anyone uses it. At full utilisation the penalty is a survivable 3.8×. At the utilisation rates Gallup actually measures, it is 9.5× to 35×.

An on-demand agent that nobody uses costs nothing. An always-on agent that nobody uses costs full price. The pricing model punishes you hardest exactly when the rollout is failing, which is why the bill and the abandonment tend to arrive together instead of the bill giving early warning.

Why should you believe the model?

Because three independent things line up with it, none of which the model was fitted to. A model that reproduces observations it was never tuned against is the only kind worth publishing.

1. It reproduces the client bill without being fitted to it. The middle row of the table above — thirty always-on Opus agents at the default 30-minute heartbeat with a third of staff actually using them — models to $5,191/month. The company we observed, at 20–50 people, reported $3–5k/month. That figure was reached from published list prices and documented defaults alone.
2. An unrelated third party measured what we modelled. A write-up at kilo.ai left an agent "completely idle for three days" and was "billed $5 a day for doing absolutely nothing" — $150/month. Our modelled Opus 5 line at a 30-minute heartbeat is $155/month. Model and measurement agree to within 3% from completely independent starting points.
3. The wake-up context is the framework's own number. Our 20,000-token heartbeat assumption is not a guess. OpenClaw's documentation prints a /context list example showing a 38,412-character system prompt (~9,603 tokens), 31,988 characters of tool schemas (~7,997 tokens) and a skills list (~546 tokens) — ~18,100 tokens before a single word of conversation history. Teams with long-lived sessions are above that floor, not below it.

The underlying mechanism is documented by the vendors, not inferred by us. Anthropic's Claude Code cost documentation states that a scheduled task "fires on its interval even while the session is idle, sending your full context each time", and that agent teams use "approximately 7x more tokens than standard sessions". Anthropic's multi-agent engineering research puts the base multiplier at "about 4× more tokens than chat interactions" for agents and "about 15×" for multi-agent systems, and adds the line that is really the whole argument: multi-agent systems "require tasks where the value of the task is high enough to pay for the increased performance." A heartbeat that finds nothing to do is worth zero and still costs 4×.

The cache-interval trap: why 30 minutes is the worst number

Anthropic's default prompt cache lives for five minutes. OpenClaw's default heartbeat fires every thirty. A 30-minute heartbeat can never hit a 5-minute cache, so every single cycle is a full-price miss. The default interval is simultaneously frequent enough to cost real money and infrequent enough to be ineligible for the 90% caching discount. It is the worst point on the curve, and it is what ships.

This is not hypothetical arithmetic. A developer running an unattended 30-minute loop on Opus overnight posted the diagnosis themselves on r/ClaudeAI in May 2026 after burning roughly $6,000 in 26 hours: "By hour 20, the conversation had grown to ~800K tokens. Every overnight iteration was paying to re-cache 800K tokens at the expensive write rate." A 30-minute period against a 5-minute TTL turns every cycle from a 0.1× cache read into a 1.25× cache write — a 12.5× swing per cycle — on a context that was also growing without bound.

The obvious fix is to move to Anthropic's 1-hour cache TTL and set the interval just under it, which OpenClaw's own docs recommend ("if your model cache TTL is 1h, setting the heartbeat interval just under that, e.g. 55m, can avoid re-caching the full prompt"). Done right that is a flat 5× saving across models.

But the trap has a second jaw, and this is the part nobody writes about. Anthropic requires "100% identical prompt segments" for a cache hit. A heartbeat prompt that injects a timestamp, a changing queue depth or refreshed memory above the cache breakpoint gets a 0% hit rate and now pays the 2× write premium on every cycle. On our model that turns $929/month into $1,858 on Haiku 4.5 and $4,644 into $8,969 on Opus 5 — 2× worse than not caching at all. Turning on caching without auditing prefix stability is the most expensive mistake available to a team that has just read a cost-optimisation blog post.

The sensitivity grid makes the levers visible. Company-wide cost for thirty always-on agents, heartbeat only, 20,000-token context, no work done:

Read across any row: halving the interval doubles the bill. Read down any column: the Haiku-to-Opus swap is a flat 5×. Context size is linear on top of both. All three levers multiply, which is why the same thirty people on the same product land anywhere between $464 and $27,864 a month depending on four settings. If you want to price your own prompts rather than ours, our token counter and cost calculator does the per-call arithmetic.

Why are the defaults so expensive?

Because the defaults optimise for the agent feeling alive, and nobody pays for feelings until the invoice arrives. These are engineering facts from the shipping documentation, not opinions about vendor motives.

• The three biggest cost controls ship off. isolatedSession defaults to false — OpenClaw's docs describe it as something that "dramatically reduces per-heartbeat token cost." lightContext also defaults to false. A cheap per-heartbeat model override exists and is unset. Community documentation calls isolatedSession "the single most impactful cost reduction," cutting per-cycle context from "up to 100K tokens" to "2-5K tokens."
• activeHours is unset, which means 24/7. The docs are explicit that omitting it "is the default behavior." There are no quiet hours out of the box, so roughly half of every heartbeat bill is generated while the office is empty.
• "Dreaming" is enabled by default at 3am. OpenClaw's background memory consolidation runs on a default daily cadence using the default runtime model, as a background subagent turn. That is at least one frontier-model call per agent per day even if nobody ever sends the agent a message.
• There is no spend cap in the framework. An open GitHub issue states plainly that cost data is "observability-only — there is no mechanism to enforce a spending limit." Any ceiling has to be imposed outside, at the provider console or through a proxy.
• The SDK guardrails also default to nothing. The Claude Agent SDK ships max_turns and max_budget_usd, and both are documented as "default: no limit" while the same page recommends that "setting a budget is a good default for production agents."

The counter-example is what makes this a design choice rather than physics. Hermes Agent, same category, ships no automatic heartbeat; jobs run only when scheduled, each in a fresh session with no history to resend, behind a wakeAgent: false gate its documentation calls "a $0 way to decide whether a scheduled job should spend any LLM tokens at all." Framework default selection is a larger cost lever than any amount of prompt optimisation. That trade-off is the substance of choosing between an OpenClaw setup and a Hermes agent setup, and it is also why self-hosting changes your infrastructure bill far less than your token bill.

Is a flat-rate seat still flat in 2026?

No. Every major vendor has bolted a meter onto the seat, so a 2026 seat price is a floor rather than a budget. It is still the option where someone other than you carries the overage risk, which is why it sits near the top of our comparison table despite not being the cheapest line.

Two things are worth stating plainly. First, Anthropic and OpenAI have converged on identical seat pricing to the dollar — $20 per seat annually or $25 monthly for standard, $100 or $125 for premium, at both Claude Team and ChatGPT Business. Independent price discovery in a two-horse market produced a single number, which means seat price is not a differentiator; capability fit and usage limits are.

Second, the meters. GitHub Copilot Business bundles 1,900 AI Credits per user and then charges $0.01 per credit. Cursor adds a $0.25 per million token surcharge on top of API rates for third-party models. Microsoft sells Copilot Studio credits at $200 per 25,000-credit pack and consumes 1 to 13 credits per action depending on type. And Claude Enterprise abandons the pretence entirely: "seat price + usage at API rates."

The existence of a 5× premium tier is the industry admitting the flat-rate model breaks under agentic usage — it exists precisely because agent workloads consume roughly what Anthropic's own research says they do. The vendors have already priced in the thesis of this study; the buyers mostly have not.

Will everyone actually use the agent you bought them?

Probably not, and the data on this is unusually clean. Gallup finds that only 16% of employees who use AI strongly agree that the AI tools their organisation provided are useful (Gallup, June 2025, n≈19,000–23,000 employed US adults, ±1pp). Its later wave measures 52% of US workers using AI ever, 30% frequently and 15% daily (Gallup, July 2026).

The more useful statistic is why non-users do not use it. Gallup's November 2025 wave found 44% simply do not believe AI can assist with the work they do, while only 16% cite lack of access. Buying thirty seats solves the 16% problem. It does nothing for the 44% problem — and in the always-on model it bills you monthly for the 44%.

Put the two together and the shape of the waste is obvious. Thirty always-on Opus agents at a 30-minute heartbeat with Gallup's daily usage rate means roughly four or five agents get talked to and about $3,900–4,000/month is billed for agents nobody opens. A seat you don't use wastes its price. An always-on agent you don't use spends money proving it.

For context on what companies actually spend: the Ramp AI Index, drawn from card and bill-pay data across more than 70,000 US businesses, puts the median firm at $11.95 per employee per month in August 2026, the top 10% at $650 and the top 1% at $7,400. The client we observed was at $60–250 per employee per month, which is top-decile spending for bottom-decile utilisation.

What should you do instead of an agent per employee?

Change the architecture before you optimise the prompts. Ranked by modelled leverage against the $5,191/month baseline, these are the moves that actually shift the number.

1. Give departments agents, not people. Five shared agents doing 40 tasks a day each cost less than thirty personal agents doing 10, on our model a 3.4× reduction while completing more work. The idle path scales with the number of agents, not the number of humans.
2. Set per-role budgets, not per-person ones. A support agent and a finance agent do not have the same economics. Giving every employee an identical token budget is what makes the 44% who will never use it invisible on the invoice.
3. Kill 24/7. Set activeHours. An agent awake all day and night spends 2× one awake twelve hours, for zero additional business value overnight. Free, immediate, no quality trade-off.
4. Lengthen the heartbeat, or replace it with an event trigger. The interval is linear in cost, and most "always-on" requirements are not actually tighter than an hour. Align whatever interval you choose to your cache TTL, then audit prefix stability before you rely on the cache.
5. Route the idle path to a cheap model. A heartbeat asking "is there anything to do?" does not need a frontier model. Haiku 4.5 against Opus 5 is a flat 5× on input tokens, and input tokens are almost the entire idle bill.
6. Impose a hard spend cap outside the framework. The Claude Agent SDK's max_budget_usd is a hard stop once set; LiteLLM proxy budgets and Helicone cost-based rate limits both block rather than warn; Langfuse observes but does not cap. Uber's response to burning a full-year AI budget in four months was exactly this — a $1,500/month cap per employee per agentic coding tool (Forbes and TechCrunch, 2026).
7. Attribute spend per agent, not per company. The most quoted complaint in this whole category is not that the bill is big. It is that nobody can say what caused it: one practitioner described paying "around $200 a month across six services" and not being able to tell you "which agent or which step ate it, so the only lever I had was turning things off and hoping." Per-agent attribution turns cost control from a guess into an edit.

If you would rather sanity-check the architecture before spending anything, our do-you-need-an-agent check and the self-hosting cost calculator cover the two decisions that move the bill most. If the bill is already out of control and you need it stopped this week, that is what OpenClaw rescue exists for.

How should you judge whether the spend is worth it?

Price agents against a labour hour, not against a SaaS seat. The highest-voted reframe in the practitioner threads on this is blunt: $100 per employee per month is $1,200 a year, described by one commenter as "a fractionally above rounding error on what it costs to have a skilled technology worker." Another put the pricing logic plainly: "agentic workflows are token amplifiers, a single ‘do this thing’ turns into 50-200 model calls under the hood… the pricing isn't aimed at mass consumer adoption, it's priced against a knowledge worker hour."

That cuts both ways, and the second edge is the one this study is about. If an agent saves a person five hours a week, $155/month is trivially worth it. If it saves nobody anything because they never open it, $155/month is not a small SaaS line item — it is a labour-priced cost with no labour attached. The comparison that matters is not agent versus seat. It is agent versus the hour it was supposed to replace, evaluated per person rather than per company.

This is also why we do not recommend measuring an agent rollout on licences deployed. Measure it on hours returned by role, then fund the roles where hours actually came back. Our guide to AI agents for business covers what those first roles usually are.

Who should still run an always-on agent?

Plenty of people, and we would rather say so than sell a rule. An always-on agent earns its heartbeat whenever the waking has a job: monitoring where missing an event inside the interval has a real cost, an inbox or queue that genuinely needs sub-hourly response, an on-call or alerting path, or a revenue trigger where one missed hour costs more than a month of heartbeats.

The individual case is also different from the fleet case. One always-on agent for a founder or an ops lead who lives in it all day is a good trade at almost any interval. We have watched a single non-technical professional get more out of three to five agents than entire departments get out of thirty, because he already knew how to delegate, set expectations and review work. The always-on penalty is a fleet problem, not a personal one — it appears when you multiply an architecture designed for the enthusiastic by the number of people on the payroll.

What this study does not prove

Every dollar figure here is arithmetic on public list prices, not an observed bill. Real contracts carry discounts, so these are upper bounds on list. The token-per-cycle and token-per-task assumptions do most of the work and are stated rather than measured: if you think your tasks are half our size, halve our numbers.

• We have no first-hand monthly bill for a non-coding, business-operations agent. Every practitioner figure in the public record is a coding agent or a personal assistant, and those run roughly 20× larger per task, so public reports systematically overstate what an ops rollout costs.
• The widely quoted MIT/NANDA "95% of organisations get zero return" figure is contested and we do not rely on it. Its base is small, it is not peer-reviewed, and it defines failure as not reaching full production. Gartner's 30% and 40% figures are predictions, not measurements.
• Community-reported token figures are frequently not bills. The eye-catching "$41,952/month"-style numbers circulating are usage-tool imputations of what flat-plan tokens would have cost at API list rates. The people involved paid $100 or $200. They are good evidence of token volume and bad evidence of spend.
• The specific settings are OpenClaw's. The mechanism — timer-driven full agent turns resending full context — is general, and Anthropic documents the same behaviour for Claude Code scheduled tasks. A framework with different defaults produces different numbers.

What would falsify this: telemetry from a real multi-seat always-on deployment showing idle share materially below 50%, or showing that the penalty ratio does not rise as utilisation falls. We would like that data and we do not have it. If you run a fleet like this and are willing to share anonymised usage exports, we will publish what they say even if they contradict us.

Frequently asked questions