What a Free AI Agent Costs, and Who Gets Paid First

ISSUE 30 COMPANION · FRIDAY 25 SEPTEMBER 2026

What a Free AI Agent Costs, and Who Gets Paid First

Two models, kept separate: the platform’s economics per user, and when those turn into hardware orders. Plus a map of who carries a data-centre delay.

Somewhere in a Meta data centre, a virtual machine is still working for a Muse user who closed the app hours ago. Each agent runs on its own machine and can keep going when nobody’s watching. Somebody pays for that.

Halve the cost of every token that agent uses and, in the model below, the platform’s break-even hurdle roughly halves. Whether its chip suppliers then sell more hardware is a different question, with a different model, and it’s the question Monday’s rally skipped.

This companion keeps the two apart. First the platform: what a free agent costs per user and what has to happen for it to pay. Then the supplier: when extra usage becomes new hardware orders. Then the problem neither model can fix, a delivery date nobody controls.

THE ANNOUNCED STARTING POINT

Muse launched on 8 September with a free tier and plans at $20 and $100 a month. Meta’s AI chief, Alexandr Wang, told Axios that most users should manage on the free tier and that subscriptions help cover compute costs. At Connect on 23 September, Zuckerberg added a planned second line: a small fee on purchases the agent completes. Muse runs on Meta’s own Muse Spark models.

Axios · Meta debuts Muse, free and paid tiers · 8 Sep | Yahoo Finance · Muse to take a small fee from transactions · 23 Sep | CNBC · Muse and the Muse Spark model family · 8 Sep | Yahoo Finance · Each Muse agent runs on its own cloud VM · 8 Sep

A day earlier, Anthropic and OpenAI cut list prices on new models by 20% to 50%. Those are prices for outside customers, not Meta’s own cost. TrendForce cites estimates that some agent workloads need four to forty CPUs per GPU, because each agent runs on its own virtual machine.

SiliconANGLE · Opus 5.5 and GPT-6 Sol and Luna pricing · 22 Sep | TrendForce · Agents and CPU-to-GPU ratios · 22 Sep

Everything in the two models below is invented. They illustrate a method. They are not estimates of Meta’s, Anthropic’s, OpenAI’s or any chipmaker’s economics.

FOUR NUMBERS TO KEEP SEPARATE

NVIDIA · Form 10-K revenue recognition policy · FY2024

My starting point: operating spend and hardware orders are linked, but through capacity, not directly. A platform can cut its cost per token on hardware it already owns. Orders come when workload outgrows the fleet, or when the operator upgrades to newer chips.

MODEL ONE: THE PLATFORM

All figures are hypothetical. An average active user runs 5 million tokens a week. The operator’s internal cost is $0.20 per million tokens, and virtual-machine orchestration adds $0.15 per user per week. Four per cent of users pay $20 a month. Users buy $40 a week through the agent, and the platform keeps 1.5%.

Weekly compute spend is therefore $1.15 per user. Revenue is about $0.78: $0.18 from subscriptions ($20 × 12 ÷ 52 × 4%) and $0.60 from fees. That leaves a shortfall after compute of about $0.37 per user per week, roughly $190m a year at 10 million weekly users. Counting subscription income, breaking even needs about $64 of purchases per user per week; without subscriptions it would need about $77.

Per active user per week. Illustrative only; orchestration cost is held fixed per user. Figures rounded.

Productive usage versus expensive activity

C and D use the same compute. The difference is whether the extra usage produced anything anyone paid for. In C, the agent thinks longer and browses more but nobody buys more, and the shortfall nearly quadruples. In D, purchases double with usage, which helps, but not enough at today’s cost.

C is the row that worries me. An agent that spends an hour comparing prices and buys nothing looks like engagement on a download chart and like a cost line in a 10-Q. From the outside, you can’t tell C from D until the company discloses purchases.

E and G show how a free agent can cover its compute: usage grows, efficiency keeps pace, and the extra usage generates purchases. A higher fee (F) is one lever. More commissionable purchases are another, and arguably the more durable one. At 10 million users, G turns a $190m annual shortfall into a positive contribution of about $170m. That’s after the compute costs in the model only, not company profit.

So for any platform, ask two questions about a price cut: how much more will users consume, and how much of that extra consumption turns into revenue?

MODEL TWO: WHEN USAGE BECOMES HARDWARE ORDERS

Chipmakers recognise product revenue when control of the hardware passes to the customer. They aren’t paid per token. Orders come from two places: a fleet that can’t carry the expected workload, and upgrades to newer, more efficient chips.

Hypothetical assumptions: the operator’s fleet runs at 70% utilisation today, and it orders more capacity when projected load would exceed 85%. “Workload” means total tokens served, so it grows with both users and usage per user. “Efficiency” means tokens served per unit of today’s capacity. Capacity needed, relative to today, is 70% × workload multiple ÷ efficiency multiple ÷ 85%.

Illustrative only. Capacity is measured in today’s processing capacity; after an upgrade, a smaller physical fleet can deliver the same capacity. Excludes replacement timing, hardware price changes, lead times, and savings from power or margins.

Where the efficiency comes from matters as much as its size. A software gain lets the same chips serve more tokens, and nobody buys anything. A hardware gain usually means buying the next generation of chips, and that purchase is itself supplier revenue. So “cheaper tokens” can be bad news for chipmakers or the thing that sells their newest product. The company’s own disclosures on replacement cycles and new-generation deployments tell you which.

Putting the two models side by side

Platform scenario B, cheaper tokens with flat usage, creates no orders if the saving came from software, and an upgrade order if it came from new chips. Scenario E creates none from software either, because workload and efficiency both doubled. Scenario G is where both sides win: the platform covers its compute and the operator needs roughly a quarter more capacity.

So platform and supplier are neither simply opposed nor simply aligned. Their interests meet in G, where workload outgrows efficiency and the extra usage is productive. They diverge elsewhere: a platform gains when efficiency outpaces usage (B), while a supplier can gain from upgrades even when workload is flat. My read: Monday’s rally priced something like G. Before paying for G, I’d want one number from Meta, contribution per active user, and one from the chipmakers, orders separated from deliveries. Neither exists yet.

Timing matters too. Orders are placed months before delivery, so near-term chip revenue largely reflects commitments made before Muse launched. Muse’s effect, if any, shows up in orders and guidance first.

WHO CARRIES THE DELAY

Model two assumes new hardware has somewhere to go. Thursday showed it may not. According to Bloomberg, Oracle sent a force majeure notice to the Blue Owl unit developing Project Jupiter in New Mexico, seeking to delay payments if the site misses its 2028 start. The campus needs about 2.45GW from Bloom Energy fuel cells, fed by a gas pipeline whose construction has slipped to February 2027 pending permits.

Yahoo Finance · Oracle force majeure notice · 24 Sep | Motley Fool · Pipeline permit delay behind Jupiter · 24 Sep

Oracle says the project remains on schedule, Blue Owl that its financial commitments are unchanged, and Bloom that it remains committed. No contract terms are public, so the table below is a checklist of questions, not a finding.

CNBC · Oracle, Blue Owl and Bloom statements · 24 Sep

A force majeure clause can excuse or postpone obligations when specified events outside a party’s control intervene; whether a permit delay qualifies depends on the wording. The practical signal is simpler. A counterparty is preparing for a delay and wants its cost to sit elsewhere.

In model two, a capacity shortfall becomes an order only when there’s a powered building to put the hardware in. A late site defers the supplier’s delivery and the tenant’s rent. It may also delay the cash flow that lenders rely on, although repayment dates depend on the loan terms, which aren’t public.

What a year’s delay costs

A hypothetical, unrelated to Jupiter’s actual figures. Suppose $10bn of hardware is bought for a site that opens a year late. Financed at 5%, carrying it for that year costs about $500m in interest. There may be a second cost: if newer chips arrive during the wait, the hardware could earn less over its life than planned. Sizing that needs assumptions this example doesn’t make, including lost earning years, resale value and whether the hardware can be used elsewhere. The carrying cost is arithmetic; the ageing cost is a range.

That’s why I read the force majeure notice as a question about who carries the cost of waiting, not about whether AI demand is real.

TURN THE ANALYSIS INTO A DECISION

The bull case is scenario G: agents drive real purchases, efficiency keeps pace, the platform covers its compute and suppliers sell more capacity. Nothing in this week’s news rules that out. The evidence to look for: contribution per active user from platforms, orders separated from deliveries at suppliers, and dated first-rent milestones from capacity owners.

The case weakens when usage rises without purchases (C), or when the capacity to serve it arrives late and financed at 5%. Dilution was last week’s cost to measure. Delay is this week’s.

This companion supports Issue 30 of iPrompt Signals, the Friday briefing on AI and robotics investing. If someone forwarded it to you, subscribe at [SUBSCRIBE LINK] to get the next issue, with this week’s tripwires checked against the results.

For information and education only, not financial advice. Figures in both models are hypothetical. iPrompt Signals is not a registered investment adviser.

iPrompt Signals Deep Dive · Issue 30 · 25 September 2026