Pricing classic software is mostly a value question. The marginal cost of one more user is close to zero, so you charge what the product is worth and keep most of it. Pricing an AI product is harder, because every call has a real cost underneath it. Get the price wrong and you can sell more while making less, which is a genuinely new failure mode for software people.

So AI pricing is two problems at once: capture the value you create, and cover the variable cost you incur. A price that does one but not the other is a slow leak. Here is a way to think about it that keeps both in view.

Start from the cost floor, then price above it

Before you decide what to charge, know what a unit of usage costs you to serve. For an AI coding product that means the token cost of the work: input, output, the extra tokens from iteration and retries. If you have not done that arithmetic yet, the token math of a task is the place to start, and why output tokens dominate your bill explains where most of it goes.

That cost floor is not your price. It is the line you must stay above on average, per customer, across the plan. Classic SaaS could ignore this because the floor was near zero. You cannot, because AI product margins are shaped by that floor whether you look at it or not.

The four layers most AI prices are built from

Most AI pricing decomposes into some mix of four layers. Naming them separately keeps you from accidentally giving one away.

Platform fee. Access to the product itself: the interface, the orchestration, the integrations, the support. This is the part that behaves like normal software, and it is where your durable margin lives.

Model and inference cost. The tokens. This is the variable cost that is new. You either mark it up, pass it through, or have the customer pay the provider directly.

Usage. A meter on the thing that scales with value: tasks completed, documents processed, seats active. The art is choosing a meter that grows with the customer's benefit, not just with your cost.

Services. Onboarding, custom work, managed operation. Optional, but it is often where early revenue and early learning come from.

You do not need all four. You do need to know which ones you are charging for and which you are absorbing, because absorbing the inference layer silently is how margins disappear.

The three pricing axes, and when each fits

  • Per seat. Predictable and familiar, and buyers understand it. The risk is that seats and value drift apart: one power user running an agent all day costs you far more than ten light seats, but pays the same. Fine early, dangerous at scale for usage-heavy products.
  • Usage-based. Price tracks value and cost together, which is honest, but it is harder to forecast and can make buyers anxious about a variable bill. Works best with a clear meter and a predictable floor.
  • Outcome-based. Charge per unit of value delivered (a merged change, a resolved ticket). The tightest link to value, and the hardest to run: you need an outcome you can measure cleanly and a floor so a bad month does not zero your revenue.

Most mature products land on a tiered subscription plus a usage meter: a predictable platform fee for the base, a meter for the part that scales, and a higher tier when a customer crosses a usage line. It gives buyers predictability and gives you a margin that does not evaporate under heavy use.

The lever that changes the whole equation

The sharpest decision is who pays for inference. If you resell tokens, you carry the variable cost and the margin risk on every call, and you are exposed to the model vendor's price list. If the customer brings their own model account and pays the provider directly, your variable cost drops toward zero and you price the platform on its value. That is the bring-your-own-model approach, and it is the single biggest fork in an AI pricing decision, not a detail to settle later.

How to actually choose

1. Compute the cost floor per unit of real usage. Do not price until you have it. 2. Pick the meter that best tracks the value your customer gets, not just your cost. 3. Decide the inference question first: resell, pass through, or bring-your-own. It changes everything downstream. 4. Set a predictable base so buyers are not scared of the bill, and a usage or tier mechanism so heavy users pay more. 5. Instrument from day one, so your first weeks of real usage correct the guesses.

The honest limitation

There is no formula that outputs the right price. Pricing is a hypothesis you test against real customers, and the first version will be wrong in ways you cannot predict from a spreadsheet. What the framework buys you is a price that will not quietly lose money as usage grows, and the ability to see which layer is leaking when the numbers drift. Whether the price is one a customer will actually pay is a market question, and only the market answers it.

The build-or-buy decision interacts with all of this too, because a platform you buy has its pricing baked in while one you build has costs you carry directly. That trade is its own topic in build vs buy an internal agent platform.

This is a stance we took deliberately at Loopsfinity: the customer brings their own model and pays for inference directly, and we price the platform on what it does rather than on a markup we would have to defend. It keeps the pricing honest and the incentives aligned, which for a category this new matters more than squeezing the last point of margin. The full picture of what agents cost and how to control it lives in the economics of AI coding agents.