The meter is the tell: reading an AI vendor's pricing page

The fastest read on an AI vendor is not the demo. It is the pricing page. Find the meter, and you know what the company is built to maximize before the first call.

Every software price has a unit somewhere under it. The unit looks like an accounting detail, a way to slice a number that was going to be roughly the same anyway. It is the opposite of a detail. The unit is the vendor's incentive structure written down in public, and with AI systems the gap between what the meter measures and what the buyer wants has never been wider.

Four meters, four incentives

Per-seat pricing bills the humans with access. It made sense when software was a surface people worked in: more users, more value, more seats. An agentic system inverts that. The software does the work, and the person reviews it. A seat meter on an AI system charges you for the number of people watching, and the count it rewards is the count of watchers. The vendor's growth motion becomes driving logins, because logins are what renew. You can see it in the products: adoption dashboards, engagement nudges, weekly digests engineered to touch the seat.

Per-token and per-call pricing bills the words the model reads and writes. Cost now tracks verbosity. The bill grows when the system retries, rereads its own output, or reasons in circles. The vendor carries no cost for sloppy work. You do, by the thousand tokens. And because token burn depends on how the vendor's own orchestration behaves, the one party who controls the cost is the one party who profits from it.

Per-action and credit pricing sounds closer to honest. It still meters doing. Four thousand actions can contain zero finished decisions. An agent that pings five systems, drafts three summaries nobody reads, and schedules a meeting that gets cancelled has consumed credits all day. Activity is not value. A credit meter cannot tell the difference, and a credit forecast asks your finance team to model the work habits of software they have never operated.

Outcome pricing points the right direction, and it carries its own burden: you cannot bill on results you cannot attribute. That problem has its own machinery, and most vendors who advertise outcome pricing have not built it.

What a buyer is buying

Strip the vocabulary away and the thing an enterprise buys from an AI system is a loop that finishes. Something changes in a system of record. The layer reads it, drafts the next workflow, and attaches what acting and waiting each cost. A person approves, edits, or declines. The approved action executes across the systems where the work lives. Evidence lands in the record, signed, replayable, reviewable.

A finished decision with its evidence attached. That is the unit. No seat, token, or credit appears anywhere in it.

One workflow, read as a unit

Take a single loop and hold it against each meter. A resignation-risk signal fires on a team that is expensive to backfill. The layer reads the surrounding systems, drafts an intervention: a retention conversation for the manager, a compensation review queued for the next cycle, an internal role match surfaced for the person's stated growth interest. It attaches what the intervention costs and what a departure would cost. A person approves two of the three actions and edits the third. The approved actions execute in the systems that own them. The evidence trail records who approved what, on which data, and what happened next.

A seat meter would have billed you for the recruiter, the HR business partner, and the manager who logged in to look. A token meter would have billed the reading and the drafting, and billed more if the model took the long way around. A credit meter would have counted the systems touched. None of the three would have noticed the only fact that matters: the loop closed, a person made the call, and the record can prove it.

Priced as a workflow, that loop has a name, a trigger, a finish line, and a cost the CFO can read. Run it ten times or ten thousand times and the vendor's incentive is the same: close it cleanly.

The meter is an incentive disclosure

Revenue shapes roadmaps. When revenue scales with an input, the roadmap drifts toward producing more of the input. Seat-metered vendors build adoption dashboards. Token-metered vendors build chattier agents. Credit-metered vendors build agents that do more things per decision, because doing is what invoices.

Price the workflow instead, from trigger through approved action, and the incentive flips onto the vendor. Every wasted model call inside a priced workflow is the vendor's margin. Efficiency stops being your monitoring problem and becomes their engineering problem.

It also changes what a budget conversation looks like. A CFO can read a list of named workflows and say which ones the business runs. Nobody can read a credit forecast. When the quote only moves because a workflow was added or materially broadened, spend follows scope, and scope is something a business governs on purpose.

The renewal is where the meter bites

Metered contracts are calm in month one and loud in month eleven. Consumption drifted, the true-up arrives, and procurement discovers that the forecast everyone signed was a guess about software behavior dressed up as a budget. The renewal conversation becomes an argument about usage curves instead of a review of what the system decided and what those decisions returned.

A workflow contract renews on a different question: which of these named loops did the business run, and which should it add? That is a conversation your operating review already knows how to have. The quarterly review changes shape with it. Workflows read like operating lines, each with a run count, an approval rate, and a returned value, instead of a consumption chart nobody in the room can defend.

The objection worth answering

Is a workflow price just a bundle with better branding? A bundle hides inputs behind a number. A workflow price names the trigger, the systems read, the human gate, the actions taken, and the evidence produced. You can audit whether it ran and what it returned. The scope is legible precisely because the unit is the thing you wanted in the first place. When volume grows inside a workflow, the price holds. When the business asks for a new loop, the quote changes, and everyone can see why.

Where meters still belong

None of this is an argument against usage-based pricing as a category. Metering is the right shape for infrastructure you operate yourself: compute you provision, storage you fill, bandwidth you consume. You control the input, you can forecast the input, and the input is the product.

The failure mode arrives when the metered input is the behavior of delegated judgment. You do not control how many tokens an agent burns deciding, how many actions it takes to close a loop, or how many retries its orchestration needs on a bad day. Metering what you cannot control is not a price. It is a variance you agreed to hold on the vendor's behalf.

The dividing line is worth writing down for your procurement team: meter what the buyer operates, price what the vendor delivers. An AI system that reads, drafts, and acts is a delivery. The delivery has a name, and the name belongs on the invoice.

Three questions for the next pricing page

Ask what unit is on the invoice. If the answer is an input, ask what happens to the bill when the system works harder to reach the same decision.

Ask what makes the bill grow. Growth tied to consumption means you are funding activity and hoping it correlates with value. Growth tied to new named workflows means you are funding scope you chose.

Ask which line on the invoice maps to a decision someone on your team approved. If no line does, the meter is measuring the vendor's product for them, and the product is motion. An AI council should be asking this before the pilot, because after the pilot the meter is in the contract.

The meter is honest in exactly one way. It tells you what the vendor is optimizing. Read it before you read the roadmap, and if you want to see what a workflow-priced quote looks like in practice, the Nodes pricing page is the artifact this piece describes.

Sources

• Nodes pricing: how a workflow is priced

Saad Bin Shafiq is the founder of Nodes, serving data-sensitive enterprises.