AI Agent Unit Economics for Builders (2026)

Builders keep asking the same question: is this agent actually worth shipping? Most answers floating around treat AI agents like SaaS products with seat counts and CACs. They are not. An agent is a piece of software that runs on demand, costs real money per call, and earns revenue per call. The economics are closer to a payment processor than a CRM. This post is the math, the cost stack, and the break-even tables I wish I had when I started building agents for Gravity's platform.

What unit economics means for an AI agent

Capsule. Unit economics for an AI agent is the revenue from one run minus the cost of that run, repeated thousands of times until the build cost is paid off. A run is unit-economic when revenue exceeds variable cost with margin to spare. Internal Gravity data, May 2026.

The unit is one run. Not one user, not one month, not one workflow. One execution start to finish. This is the cleanest unit AI software has ever had, and most builders still think in SaaS terms. A SaaS app charges $20 per seat per month whether the user logs in zero times or 200 times. An agent has no such buffer. Every call has a real bill attached: tokens to the model vendor, milliseconds to the infrastructure, occasionally a paid API call to a third-party tool.

For a builder shipping on a marketplace, the margin per run is the entire game. If a run pays $0.50 and costs $0.45 to execute, the platform absorbs the squeeze. If the builder's take on that same run is pure profit with zero execution responsibility, the builder is structurally profitable from run one. That is the difference between paying for your own infra and shipping on a take-rate platform.

The cost stack of a single agent run

Capsule. A single AI agent run stacks four costs: LLM inference, tool calls, infrastructure, and orchestration overhead. For a typical mid-complexity agent in May 2026, the all-in cost sits at $0.05 to $0.40 per run. Source: internal estimate from Gravity's production traffic across 80+ agents.

Let's unbundle.

• LLM inference is usually the largest line item. A frontier model call at 8k input tokens and 2k output runs roughly $0.03 to $0.06 depending on vendor.
• Tool calls are everything the agent reaches for: a search API, a scraper, a vector store query, an email send. Most cost between $0.001 and $0.02 each, but agents that call seven tools in a sequence pile this up fast.
• Infra covers compute, storage, and egress, normally $0.001 to $0.01 per run for a sane stack.
• Orchestration is the workflow runner itself, often a flat amortised cost.

Here is what the ranges look like by agent class.

The takeaway: agent class drives cost more than any other variable. A research agent is not a more expensive Q&A bot; it is a fundamentally different cost profile. Pricing one like the other is how builders destroy their margin without knowing it.

Pricing models: per-run, per-seat, per-output

Capsule. Three pricing models dominate AI agents in 2026: per-run (Gravity, most agent platforms), per-seat (legacy SaaS retrofits), and per-output (newer outcome-based pricing). Per-run aligns cost to value, per-seat decouples them, per-output ties revenue to a measurable result. Internal taxonomy, validated against 40+ public AI tool pricing pages.

Per-run pricing

The buyer pays for each execution. Price is fixed (e.g. a few cents per run) or metered (scaling with tokens used). This is the model Gravity's marketplace runs on, with each run drawing on the usage included in the buyer's subscription plan, and it is what almost every new agent platform launched in 2026 is converging on. The buyer's mental model is simple: I get a result, it draws on my plan. No waste.

Per-seat pricing

The buyer pays a monthly fee per user. Inherited from SaaS, this works badly for agents because consumption variance is enormous. A power user runs an agent 500 times a month; a dabbler runs it twice. The seat price has to cover the power user, which prices out the dabbler entirely. Per-seat agents tend to fail in either direction.

Per-output pricing

The buyer pays only when the agent produces a measurable outcome: a qualified lead, a passing test, a published draft. Higher conversion than per-run, but only works when outcomes are objectively verifiable. Most agents don't qualify yet.

Why per-run pricing wins for marketplaces

Capsule. Per-run pricing wins for marketplaces because it aligns three incentives at once: the buyer pays only for value received, the builder earns more when the agent is useful, and the platform's revenue grows with real usage. No other model aligns all three. Observation from 12 months running the Gravity platform.

Marketplaces have a coordination problem. Buyers want low commitment. Builders want predictable income. Platforms want signal on what's actually working. Per-seat fails for buyers and is noise for platforms. Per-output is great for buyers but creates revenue volatility for builders. Per-run is the rare model where everyone reads the same number and reaches the same conclusion: this agent ran 1,200 times last month, it earned $X, and that revenue maps to genuine demand.

There's also a discovery effect. When agents are priced per run, buyers are willing to try more of them. Trying an agent for $0.30 is a no-brainer; subscribing for $19 a month is a commitment. The marketplace catalogue gets explored, builders get discovered, and the long tail actually monetises. Where you publish your agent matters partly because of this discovery dynamic.

How Gravity prices agent runs

Capsule. Gravity users subscribe to a plan: a free tier covers one agent, and paid plans start at $20 per month with $20 of usage included, with the option to buy extra usage beyond the plan. Builders set a per-run price when they publish an agent; a simple agent's run draws a few cents of plan usage, a complex one fifty cents to a few dollars. Gravity covers all execution cost. Source: Gravity pricing model, 2026.

Plan usage keeps run costs legible. A simple run draws around five cents of a buyer's monthly usage allowance, so builders and buyers can reason in cents while Gravity handles the dollar accounting. The run price is the usage unit; the subscription plan is how buyers pay for it.

The builder picks a run price when publishing the agent. Gravity recommends a band based on the agent class and average token spend, but the builder has final say. Once set, the price is what every run draws from the buyer's plan, and Gravity handles billing, fraud, refunds, and the underlying LLM and infra bill. The builder never sees a Stripe webhook or an OpenAI invoice.

The plan abstraction matters more than people think. When buyers see a run price measured in cents of included usage rather than a separate invoice, they compare agents to other agents on the platform, not to another SaaS subscription. That lets builders price closer to the actual value delivered instead of anchoring to a seat price.

Builder margin: a fixed share as pure profit

Capsule. On Gravity, builders earn a fixed share of gross revenue per run as pure profit. Gravity's own share carries the execution cost (LLM, tools, infra) and the platform overhead (CAC, support, fraud, payments, evals). Creator referral, if present, is funded jointly from the builder and Gravity sides. Source: Gravity platform economics, May 2026.

This is the line builders should anchor on. The builder share of gross is pure profit. There is no infrastructure capex to recover, no Stripe fee to subtract, no inference bill at month-end. The builder ships an agent, buyers run it, the share lands in payouts twice a month.

Why a platform share that large? Because the cost side of agent operation is genuinely heavy. LLM inference alone can be 20-30% of gross at typical price points. Once you add infra, payments, fraud, evals, support, refunds, catalogue SEO, and platform engineering, the platform share disappears fast. Gravity bears that risk so builders don't have to. When I built agents on my own infra before launching Gravity, I would routinely lose 15-25% of revenue to surprise inference spikes from a single bad prompt. Builders on Gravity simply do not experience that volatility.

When a creator brings the buyer (a referral), the referral share is funded jointly from the builder and Gravity sides. The builder gives up a small slice to acquire a buyer they would not have reached. Most builders find this trade obvious. Monetisation strategy often comes down to which creators you partner with.

When an agent becomes unit-economic for a builder

Capsule. An AI agent becomes unit-economic for a builder when total expected lifetime runs times the builder's take per run exceeds build hours times the builder's hourly rate. A 10-hour build at a $50/hr opportunity cost needs the take from a few thousand runs to cover the $500 of build time. Internal Gravity back-of-envelope.

Here's the formula in one line:

Build hours × hourly rate < Lifetime runs × builder take per run

Rearrange and you get the lifetime run threshold to break even:

Breakeven runs = (Build hours × hourly rate) / builder take per run

Plug in numbers. A 15-hour build at $60 per hour costs $900 in opportunity cost. If the builder's take is $0.10 per run, break-even is 9,000 lifetime runs. Across 24 months that's 12.5 runs per day. A useful niche agent will clear this. A vanity agent will not.

Looking at the top quartile of Gravity agents by usage, the median crosses break-even between months 2 and 4 post-launch. The bottom quartile never crosses it. The single best predictor of which side an agent lands on is whether the builder validated demand before building, not how technically impressive the agent is.

Break-even math for 5 agent classes

Capsule. Break-even runs vary 50x across agent classes once build time and run price are factored in. A simple summariser breaks even at roughly 1,800 runs; a complex research agent at 600 runs but needs $3+ per-run price points. Source: modelled from real Gravity builder data, May 2026.

Two patterns jump out. First, cheap agents need volume; expensive agents need fewer customers but face harder distribution. Second, build time is the variable most builders underestimate. A 40-hour build is rarely actually 40 hours once you include evals, prompt iteration, and fixing the first batch of production failures. Double whatever you estimate, then check the table again.

What kills builder unit economics

Capsule. Three failure modes destroy builder unit economics: over-tool-using agents that fan out unnecessarily, retry storms that quietly multiply token spend, and expensive frontier model defaults used for trivial subtasks. Each can 3x to 10x cost per run with zero quality gain. Internal Gravity production observations.

Over-tool-using agents

An agent that calls seven tools when two would do is not a smarter agent; it is a slower, more expensive one. Every tool call adds latency, failure surface, and cost. The discipline is to ask, for each tool: does removing this tool change the output quality? If no, cut it. Tool use design is where most builder margin leaks happen.

Retry storms

An agent that fails a tool call and retries five times has just quintupled the spend on that call. Worse, if the retries also pass through the LLM (e.g. for reformatting), each retry is a fresh inference. Set retry limits aggressively. Two is usually enough; three is the upper bound for production agents.

Expensive model defaults

Routing every step through the most expensive frontier model is the most common margin killer. Use cheap models for routing, extraction, and classification. Reserve frontier models for genuinely hard reasoning. A well-tuned model routing setup can cut per-run cost by 60% with no measurable quality drop. Evaluation metrics tell you when you've over-cut.

FAQ

What does unit economic mean for an AI agent?

An AI agent is unit-economic when the revenue per run exceeds the variable cost per run with margin left over. For Gravity builders the math is simpler: there is no infra to pay back, so the builder's share of gross revenue per run is pure profit. The agent is unit-economic the day it ships.

How much does one AI agent run actually cost?

A simple agent run costs roughly $0.005 to $0.03 in LLM and infra. A medium tool-using agent costs $0.05 to $0.40. A heavy research or long-context agent can hit $1 to $5 per run. These are internal estimates based on May 2026 frontier model pricing and typical tool fan-out.

Why is per-run pricing better than per-seat?

Per-seat pricing decouples cost from value, so a buyer pays the same whether they run an agent twice or 2,000 times. Per-run aligns price to outcome. The buyer only pays when work happens, and the builder earns more when the agent is genuinely useful. See our full economics explainer.

How is builder margin 100% pure profit on Gravity?

Gravity pays the LLM bill, the infra bill, and the platform overhead out of its own share. The builder keeps a fixed share of gross revenue per run with zero infrastructure to amortise. Every paid run lifts builder margin without a fixed cost drag.

When does an AI agent become worth building?

Back of the envelope: build hours times your hourly rate must be less than expected lifetime runs times your builder take per run. A 10-hour build at $50 per hour needs the take from a few thousand runs to cover the $500 of build time. Most useful agents clear this in months. For bootstrappers, see the bootstrapped agent economics post.

What destroys builder unit economics fastest?

Over-tool-using agents that call seven APIs when two would do, retry storms that quietly multiply token spend, and defaulting to the most expensive frontier model for every step. These three failure modes can 5x to 10x cost per run with no quality lift.

Does Gravity charge builders to publish an agent?

No. Publishing is free. Builders take a fixed share of gross revenue per paid run. Creators who refer the install take a referral share, funded jointly from the builder and Gravity sides. Gravity covers all execution cost from its remaining share.