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 run achieves its goal, and no outcome fee when it does 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 the workflow’s goal, 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.

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

   The goal is set before any result is judged.

   AIOS writes each workflow’s goal from the workflow itself: its name, description, steps and inputs. It never reads a run’s results to write it, and the goal stays fixed until the workflow changes, so neither side can move the finish line after seeing the result. Every bill shows the goal the run was judged against.

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 goal met means no outcome fee.

   The engine judges each run against its goal and records the verdict. Neither side gets to self-report success. A step the goal doesn’t depend on, like a log upload, can fail without cancelling the fee. A run that misses its goal has no outcome fee, and a retried run pays the outcome fee once at most.

There is no platform fee.

There are no seats and no subscription. The outcome fee is a fixed price, set by the run’s measured tier, charged only when a run achieves its workflow’s goal and at most once per run. AI model usage passes through at the provider’s cost plus five percent. Calls and texts on numbers AIOS provides pass through at the carrier’s cost plus five percent. With their own model provider keys, the customer pays us nothing for AI usage, and with their own Twilio account and numbers, nothing for calls and texts. Usage pays for resources consumed; the outcome fee pays for a result delivered. There is no fee for the initial implementation either. Later rollout work can be scoped and billed separately.

Here is what that looks like on an invoice.

When a run misses its goal, the customer pays only for the usage it consumed, at cost plus five percent. With their own model keys, they pay us nothing for its AI usage, and with their own Twilio account and numbers, nothing for its calls and texts. This is not a credit we apply later. The billing system simply does not create an outcome fee unless the run achieves its goal.

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.