Agent economics are weird: three things nobody priced right in 2025

I watched three separate agent companies go from hot to cold in 2025 because they priced their APIs wrong. One was my friend. All three made the same mistake, which is assuming that the customer using the API would be a human with human usage patterns. They built beautiful pricing pages with sliders and annual discounts and three-tiered plans named "Pro", "Business", and "Enterprise". They were perfect, functional, and completely invisible to the actual customer.

When the customer is a script running on a Mac mini at 3 AM, every assumption in every pricing page breaks. The customer does not care about your brand. It does not want to join your Slack community. It wants to know the cost of a single atomic action, and it wants that information in a machine-readable format so it can decide whether to proceed.

The companies that failed last year built their entire business on a customer who was not buying. The real customer, the agent, was turned away by a pricing model it could not parse or justify. Here are the three specific mistakes I saw them make, with concrete data from my own Conway Automaton x402 gateway that I run for my own small projects.

Mistake one: per-seat pricing

The foundational sin of SaaS pricing is the per-seat model. For the last fifteen years, it has worked beautifully. You charge $20 per user per month. This scales predictably with company size. It works because the unit of value is a single human's access to a tool. Humans do not typically share accounts, they have finite attention, and their productivity, while variable, exists within a broadly understood range. A company with 100 employees pays more than a company with 10, and this feels fair to everyone.

Agents obliterate this model. An agent is not a user. A single API key given to an agent can represent the work of one, ten, or a thousand humans. An automation script does not get tired. It does not take coffee breaks. It can perform in one hour what a team of 40 humans might do in a day.

This is what breaks the economics. The vendor sees a single "seat" on their billing dashboard, paying $20 a month. But that one seat is consuming infrastructure, generating load, and extracting value equivalent to 400 human seats. The cost-to-serve for this one customer is orders of magnitude higher than their revenue. The model leaks value like a sieve.

I see this in my own logs. My Conway automaton is a simple script that helps me with research. It makes about 48 distinct requests per day to my various internal APIs. If Conway were a human, you might model that as 48 separate sessions of work. A human user on a $20 per month plan who logged in 48 times a day would be considered a power user, but still well within the bounds of the pricing. But an agent's requests are not "sessions". They are atomic units of work. A per-seat plan would fundamentally misinterpret this activity and under-charge me by a factor of at least 40 for the value I am getting.

Here is how the models differ in practice.

| Feature | Per-Seat Model (Human-centric) | Per-Call Model (Agent-centric) | | :--- | :--- | :--- | | Unit of Value | A human's access for a month | A single, successful API call | | Billing Cycle | Monthly/Annually | Instantaneous (per-call) | | Customer | A person or a team | A script or automaton | | Usage Pattern | Bursty, unpredictable | Sustained, predictable, high-volume | | Failure Mode | Under-charges for high-value automation | Fails to attract humans for exploration |

The fix is conceptually simple but requires re-architecting your billing and enforcement logic. You must switch to per-action pricing. This is often called per-call pricing. The price is not for access to the system. The price is for the successful completion of a single verb, a single API call. This is enforced at the API gateway, not on a marketing page. The agent pays for what it uses, and the vendor is compensated directly for the load it serves.

Mistake two: the free tier

The second critical error is the free tier. In the human-centric SaaS world, a free tier is a marketing tool. You give a user 100 free API calls or 1,000 free messages per month. The goal is to get them into the product, let them discover its value, and get them "addicted" so they eventually upgrade when they hit the usage cap. The limits are set high enough for exploration but too low for serious production use. This is a classic acquisition funnel.

Agents do not do "discovery". An agent does not get "addicted". An agent is given a task, finds a tool, evaluates the tool's cost and utility, and then executes. It is a purely rational economic actor.

A free tier, to an agent, is simply a zero-cost resource to be consumed in its entirety as quickly as possible. An agent can consume 100 API calls in four seconds. It will do this, achieve its goal, and then stop. It does not feel any compulsion to "upgrade". If the free tier is sufficient, it will use it and nothing more. If it is not, it will simply mark the tool as inadequate and find another.

The acquisition funnel that assumes a free tier leads to conversion is completely broken. The agent stabilizes its usage at the point that provides the maximum value. For many, that is the ceiling of the free tier. They never become a paid customer.

The data from my x402 gateway was shocking to me at first. In the first month I had it running, eight distinct agents started calling my /api/ask endpoint. I had no free tier. Not a single call was free. And yet, they came. Of those eight agents, zero of them "upgraded" from a free plan because one never existed. They simply started paying from the very first call and continued to pay for every subsequent call. They were designed to do so.

The fix is to abolish the free tier entirely for agent-facing endpoints. Replace it with a price. It can be a very small price. A price of $0.001 per call is effectively zero for a human trying things out. A human will not bother with the mechanics of setting up a payment for a few cents. This is fine. They are not the customer. But for an agent, $0.001 is a concrete, calculable cost. It will happily pay micro-cents forever as long as the value it gets from the call is greater than the cost. You filter out the casual human traffic and attract the serious agent traffic.

Mistake three: burst caps

The third pillar of broken agent pricing is the rate limit. Traditional rate limits are designed around human behavior. A human user might click around a web app rapidly for a minute, generating a "burst" of traffic, and then go quiet for ten minutes. Rate limiters are built to allow these short bursts but punish sustained, high-frequency requests, which they interpret as abuse or a DDoS attack. A common rule is "100 requests per minute".

An agent's usage pattern is the opposite of a human's. A well-designed agent does not burst. It finds an optimal, sustainable rate of execution and holds it. Its usage graph is not a series of spikes. It is a flat plateau. It might gradient up or down as its objectives change, but its steady state looks like a sustained, high-volume stream of requests.

To a rate limiter built in 2016, this pattern is indistinguishable from an attack. An agent that maintains a steady 40 requests per minute for hours on end looks like a malicious script. The rate limiter triggers, blocks the API key, and cuts off your paying customer.

I saw this happen with one of the first serious agents to use my gateway. It hit my /api/fetch-summarize endpoint with a steady 60 requests per minute for three straight days. It never spiked higher. It never dropped lower. It was perfectly consistent. A traditional rate limit would have banned this agent within the first five minutes.

But my gateway is configured differently. It does not rate limit based on request count. It rate limits based on payment. Because every single one of those requests came with a valid x402 payment attached, my gateway welcomed them. That agent made 259,200 calls in that 72-hour window. It paid me a total of $5.12. I made money by being permissive. The vendor who blocks this traffic is literally refusing to take a customer's money.

The fix is to tie your rate limits to a payment signal. If a request is paid for, it should be allowed, subject only to your absolute physical capacity to serve it. The abuse pattern you should be looking for is a high volume of unpaid requests. If an agent is hitting you with 100 requests per minute and not paying, that is abuse. If it is hitting you with 100 requests per minute and paying for every single one, that is a good customer. Your infrastructure needs to know the difference.

A small table of my actual data

Talk is cheap. Here is the real data from my Conway x402 gateway over the last 30 days. It shows five anonymized agents that have been calling my endpoints.

The "Revenue" column is the actual money I collected via per-call micropayments. The "Would-have-paid on per-seat" column is my best estimate of what a typical SaaS company would have to charge in a monthly plan to accommodate this level of API usage without going bankrupt on infrastructure costs. This is usually a "Business" or "Enterprise" plan, which I have pegged at a conservative $96 per month.

| Agent ID (hashed) | Calls (30d) | Revenue (Per-Call) | Would-have-paid on per-seat | Ratio (Per-Seat / Per-Call) | | :--- | :--- | :--- | :--- | :--- | | a4e...b10 | 4012 | $4.65 | $96.00 | 20.7x | | f89...c33 | 2491 | $2.89 | $96.00 | 33.2x | | 3d1...a05 | 1503 | $1.74 | $96.00 | 55.2x | | 7b2...e9f | 998 | $1.16 | $96.00 | 82.8x | | c6e...47a | 843 | $0.98 | $96.00 | 98.0x | | Total | 9847 | $11.42 | $480.00 | 42.0x |

The conclusion from this data is stark. My per-call model captured $11.42 in real revenue. A traditional per-seat SaaS model would have presented these agents with a cumulative price of $480. No agent developer would pay that. They would simply go elsewhere. The per-seat model would have captured $0. It creates a price-to-value mismatch of 42x that drives away the very customers it is meant to serve. The per-seat model would leak nearly 100% of the potential revenue because the price is not just wrong, it is nonsensical to the customer.

What agents actually want from a pricing page

So what does an agent want? If it does not want sliders and annual plans, what does it look for? It looks for a contract it can understand.

• JSON, not HTML. An agent cannot parse your beautiful, responsive pricing page. It wants a /pricing.json endpoint that it can curl once. This file should contain the endpoint, the verb, and the price per action. It will read this once, parameterize its caller, and never look at your marketing site again.
• Micropayments, not subscriptions. An agent wants to "sign per-call", not "sign up". It wants to transact for the value it receives at the moment it receives it. The x402 Payment Required standard is built for this. It wants to pay, not subscribe.
• Stable prices. Agents often run cost-benefit calculations on every action. If your prices are volatile, changing week to week, the agent's calculations will fail. An agent that cannot predict its costs will abandon your integration and find a more stable provider. Price changes should be rare and well-communicated in the machine-readable format.
• Idempotency keys. Agents operate in an unreliable world. Networks fail. APIs time out. An agent will retry its requests. If you charge it twice for the same logical operation, you have broken its trust. It will mark you as an unreliable vendor and may block you permanently. Supporting idempotency keys is not optional. It is a fundamental requirement for serving automated clients.
• A price signal in the 402 response header. The best place to tell an agent how to pay is in the response that tells it to pay. The 402 response should contain a header that specifies the exact amount and currency required for the call to succeed. Do not make it look up the price in your docs. Provide the payment instructions with the payment demand.

What I ended up with

Based on these principles, my own pricing is brutally simple. There is no "plan". There is only a price list.

• /api/ask: $0.001 per call
• /api/og: $0.002 per call
• /api/fetch-summarize: $0.005 per call

All payments are handled via the x402 standard, accepting USDC on Base. There is no free tier. There is no subscription. There is no "pro plan".

The results are small, but they are real. I have eight distinct agents calling my endpoints this month. I served 124 paid calls last week. This is not big money. But it is cleanly profitable. There is no acquisition funnel to maintain, no sales cycle, and no support burden. The agents read the spec, pay the price, and get the value. It is the cleanest business model I have ever seen.

The contrarian view I want to name

When I discuss this, someone always raises the scaling objection. "But what happens when the agents scale to millions of calls? You will not be able to serve them!"

My answer is: good. That is a wonderful problem to have. Let us do the math. At a million calls per agent per month, at a modest price of $0.001 per call, that is $1,000 in monthly recurring revenue from a single, silent, automated caller. I will happily take on the technical challenge of serving that customer.

The actual risk is the exact opposite. The real danger is not that you will be overwhelmed by demand. The actual risk is that you will build an agent-facing API, price it with monthly subscriptions and per-seat tiers, and no agents will call it at all. You will have zero demand because you priced it in a language your customers do not speak.

What to do if you maintain an API today

If you run an API and you believe agents will one day be your customers, you can start preparing now. It is not a massive undertaking.

1. Expose a /402 or equivalent. Alongside your existing authentication, allow for per-call payment. The x402 standard is a good place to start.
2. Accept at least USDC on Base via x402. This is currently the most common and lowest-friction payment rail for agents.
3. Publish a machine-readable /pricing.json. Create a simple, stable endpoint that lists your per-call prices.
4. Do not remove your human pricing. This is an addition, not a replacement. Let your human customers continue to pay via monthly credit card subscriptions. Just add the agent-friendly path alongside it.
5. Expect the first agent to be small. Your first automated customer will likely make a few dozen calls a week. Expect the fiftieth to be significant. This is a long-term architectural shift, not an overnight revenue boost.

The agent economy is not coming. It is here, and it is paying in increments of one-tenth of a cent, and the companies that did not notice are the ones whose MRR graphs went flat last summer. If your pricing page only knows how to read humans, you are leaving real money on the table. It is not even complicated to fix. It is just different.