Pricing what you can prove.

Seat-based pricing makes sense when software is a tool people use. It makes much less sense when the software is doing the job. In that world, the customer should pay for the work that gets finished, not for the number of people who logged in to watch it happen. But there is a catch: before you can price an outcome, you have to prove it happened.

That is how we price AIOS. A customer pays an outcome fee when a task is completed, and no outcome fee when it is not. The promise is simple. Building a billing system around it is not. Both sides need a clear answer to the same question: what counts as done, and who gets to decide?

This post is our answer. It is not a thought experiment; it is the system we use. AIOS records what happened during a task, checks the result against criteria agreed on before launch, and calculates the bill from that record. “What do we owe?” should have a factual answer, not start a negotiation.

Outcome pricing starts with two questions.

First, how much of the work did the software actually do? Second, can you trace the finished result back to that work? Once you answer those questions, the right pricing model becomes much easier to see.

If a person is doing the work and software is helping, the product is a tool. Charging per user is reasonable. If software runs on its own but its activity cannot be tied to a specific result, the product is capacity, so usage-based pricing makes sense. Most AI products today sit somewhere between those two: a person still leads, the software does part of the work, and the bill combines seats with usage. True outcome pricing only works in the final case: the software completes the job, and the result can be verified.

Plenty of vendors want to claim that top-right corner. Getting there takes more than calling a product autonomous. The software has to carry the process from start to finish, without handing every meaningful decision back to a person. It also has to keep enough evidence to show exactly what it did. Without that record, outcome pricing eventually becomes an argument over whose spreadsheet is right.

Compute gets cheaper. A finished job does not.

The cost of running AI models keeps falling. That is good news for customers, but it makes a business built on marking up compute less valuable over time. The value of completed work is more durable. A retained subscriber, a processed claim, or a completed mortgage file is valuable because of what it means to the business, not because of what the model cost to run.

We do not want to be paid because the software ran. We want to be paid for the file that closed, the claim that cleared, and the customer who stayed.

Mitchell Gunnels, founder, cvlSoft

This model also changes how we operate. Sales cannot sell a process we cannot reliably run. Engineering cannot call a workflow finished just because the demo worked. If a process is unreliable, we feel it in the current quarter, not at a renewal meeting a year later. Our incentive is tied to the same result the customer cares about.

The invoice starts with a definition of “done.”

AIOS takes a captured process from start to finish through one cognitive core. It creates a plan before taking action, applies the customer’s policies as it works, and treats human approvals as explicit steps in the process. That makes it clear who did the work. The execution record makes it possible to prove the result.

1. 01

   We agree on success before the first production run.

   For every workflow, we define the required end state and the artifact that must exist. Those criteria are locked before launch, so neither side can move the finish line after seeing the result.

2. 02

   AIOS keeps the evidence for every run.

   The record includes the steps attempted, tools and connectors used, active orchestration time, approvals completed, and token cost. It is append-only, and the customer can inspect the same information we use to create the bill.

3. 03

   The record determines the price tier.

   AIOS measures complexity across three signals: process steps, tool calls, and active orchestration time. Completed approval gates and token cost can raise the tier. The same execution record always produces the same tier.

4. 04

   No verified success means no outcome fee.

   The engine checks the result against the locked criteria and records the status. Neither side gets to self-report success. A failed, escalated, or stopped task has no outcome fee.

The bill has three parts.

The platform fee covers the customer’s infrastructure, connectors, security, and unlimited users. We charge it at cost and take no margin. Compute is passed through at the provider’s published rate plus five percent, or not charged by us at all when the customer brings their own key. Finally, the outcome fee is a fixed price for each completed task, based on its measured tier. Compute pays for resources used; the outcome fee pays for a result delivered.

Here is what that looks like on an invoice.

When a task fails, the customer pays only for the compute used. If the customer brings their own key, they pay us nothing for that run. This is not a credit we apply later. The billing system simply does not create an outcome fee unless the task reaches the agreed finish line.

The rules protect both sides.

With prices ranging from $10 to $450 per outcome, the rules cannot be made up case by case. We publish them and lock them. AIOS measures the full chain of work behind an outcome, so a complex task does not become cheaper just because someone split it into several smaller steps. It also groups near-identical tasks launched by the same trigger and prices them as one combined task.

The same clarity applies at the finish line. If the required artifact was delivered and then the run was cancelled, the outcome still counts. Retries do not create additional outcome fees. And when our infrastructure causes the failure, we absorb the cost. Our platform, our problem.

We calibrate the tier boundaries against historical execution data, publish them, and lock them at fixed percentiles. From then on, assigning a tier is no longer a pricing decision. It is a database query. The goal is simple: no arbitration required.

The tradeoff is ours.

Outcome pricing puts our margin on the other side of the customer’s result. If a workflow is unreliable, we still spend the compute and engineering time, but we earn no outcome fee. That is why cvlSoft engineers work alongside the customer until the process is dependable. It is also why we would rather turn down work we cannot measure than call a metered engagement an outcome deal.

Not every process is a fit for this model. Some work is genuinely led by people. In other cases, the result depends on a decision AIOS does not make. Pretending otherwise would not make the pricing more innovative; it would only make it less honest. But when AIOS owns the work, we hold ourselves to the standard in the title: if we cannot prove the outcome, we do not bill for it.