Why AI agents fit usage-based pricing better than per-seat subscriptions

A human can buy a seat because the seat represents a person’s attention. An agent is different: it has no office hours, inbox or seat to occupy. It performs work by making requests, receiving results and deciding what to do next. Pricing that work by the number of people in an account hides the thing that actually changes the cost: usage.

Seats meter people, not work

Per-seat subscriptions are useful when a team is buying a stable workspace for humans. They are a poor fit for an agent that may run once today, run a hundred times tomorrow and sit idle next week. The subscription remains fixed while the work varies. That makes an agent’s cost harder to explain and encourages teams to buy broad provider plans just to cover occasional jobs.

A usage-based model starts with a clearer question: what unit did the work consume? That unit might be a search, result, verification, generated image or another provider-defined event. The denominator matters. A price shown as “per call” when the provider bills per result would make a cheap-looking call impossible to reason about.

Usage pricing maps the bill to the job

scrollport keeps the public taxonomy explicit. A category is a broad navigation group. A capability is a provider-neutral job or outcome. A provider supplies the underlying service, and a catalog toolis the independently discoverable, inspectable, priceable and runnable operation. The current research tools show the kind of job-led surface an agent can browse without choosing a supplier first.

This makes a bill legible: the agent selects a catalog tool for a capability, the tool exposes the provider’s own billing unit, and the wallet settles the measured usage. A reader can compare work rather than comparing opaque plan tiers. The live catalog owns current tool descriptions and prices, so this article deliberately does not repeat a provider rate that could change.

One wallet and one key reduce account overhead

One scrollport key gives an agent one authentication path into the four control tools:discover, inspect, run and wallet. One wallet gives the human one place to top up, set a spending boundary and review what was charged. That is simpler than teaching an agent several provider billing portals and several account-level limits.

This does not pretend that every provider account disappears. Some catalog tools still require a human to connect the relevant provider account, and that requirement is shown on the tool surface. The reduction is in billing and control overhead: the agent gets a consistent interface, while the human keeps provider authorization explicit.

The boundaries of “pay for what you use”

Usage-based pricing is transparent only when its boundaries are visible. The catalog should state the billing unit and current published price, and a run should reserve the expected amount before execution. A successful run captures the actual cost and releases any remainder; a failed run releases the hold rather than charging for work that did not settle.

• It is not a promise that every provider connection is free or unnecessary.
• It is not a promise that a provider’s public rate never changes.
• It is not a guarantee that every job has the same unit or the same cost.
• It is not permission to hide failed calls, holds or released funds.

The practical rule is simple: describe the work, expose the denominator, keep the live catalog authoritative and let the wallet show the money movement. For the full setup and control-tool path, read the platform documentation; for the product model, see how scrollport works.