Per-Step vs Per-Token Pricing for Autonomous Agent Workflows

A support workflow that resolves a billing dispute might run six model calls, two tool queries, and a validation pass before it produces an answer. Priced per token, that workflow looks cheap on paper and expensive the moment a customer's request turns ambiguous and the agent loops twice before it finds the right policy document. Priced per step, the same workflow looks predictable on a spreadsheet, but that spreadsheet hides the fact that one of those six steps carried fifteen thousand tokens of retrieved context while another carried five hundred. Autonomous agents break an assumption that conventional software pricing has relied on for years: that cost per task is a fixed, knowable quantity. It isn't, because the number of model calls, retries, and context reads needed to produce a given business outcome swings enormously from one case to the next, and whoever sets the billing unit is really deciding which layer of that swing the vendor absorbs and which layer lands on the buyer. The unit you bill on also becomes the unit both sides start managing: a buyer paying per token starts watching context size and retry rates, while a buyer paying per step starts watching how often workflows branch and how many actions each one takes. Research into agent workflow costs points to a more useful number than either one alone, cost per completed workflow, and that framing is where this piece starts: not to declare a winner between tokens and steps, but to show what each hides and what it exposes, so a buyer can match the billing surface to the cost surface their own team can actually see coming.

Token counting in an agent loop

An autonomous agent's token bill is the sum of everything its architecture rereads, rederives, and retries on every pass through the loop, and in most production systems that total runs several times higher than any estimate made before launch. A single user request fans out into a sequence of distinct stages, each carrying its own chunk of context: a planning stage that breaks the task down and picks which tools to use, a retrieval stage that pulls in policy documents, data, and prior decisions, a round of tool calls against APIs and databases and workflow systems, a validation stage that checks the result for completeness and currency, a round of retries when a tool call fails or an assumption turns out wrong, and finally a synthesis stage that produces the answer or action the user sees. Each of those stages adds its own context package to the token count, and the effect compounds. Research into agent workflow costs finds that a six-call agent workflow uses roughly nineteen times the model tokens of a simple chat exchange on the same model tier, before any tool fees, retrieval costs, observability overhead, or human review enter the picture. The shape of the agent's loop matters as much as its length. An agent built to replay its own history at every step pays for that design choice directly: a structured single-pass approach costs a fraction of what the same workload costs when run through a growing-context agent, because the growing-context version rereads its accumulated history on every iteration, multiplying input tokens without multiplying anything the user actually gets back. And the variance across runs of the same task is severe enough to undercut any estimate made in a calm testing environment. Research on coding-agent tasks posted to arXiv found token use varying by up to thirty times across repeated runs of the identical task, so a per-token price that looks entirely manageable in development can land three to five times higher once the agent meets the ambiguous inputs, missing context, and edge cases that real users generate in production.

What per-token pricing exposes and hides

Per-token pricing is honest in one specific sense: it ties the bill directly to the compute the model actually burned, call by call. That honesty cuts both ways. It passes along not just the legitimate cost of reasoning but the cost of every architectural decision the vendor made about retries, context window management, and how verbose the model is allowed to be, and all of that lands on the buyer as the vendor's choice. What it exposes well: the buyer gets direct visibility into model spend at the level of the individual call, a clear incentive to optimize prompt length and caching and context management, and a number that reflects actual compute. On the side of what it hides: the token cost of a retry storm looks identical on the invoice to the token cost of legitimate, productive reasoning, so there's no way to tell from the bill alone whether a spike came from the agent solving a hard problem or from the agent failing and trying again. Ensemble approaches and voting configurations that chase higher reliability multiply token cost in ways the buyer cannot see, because the invoice shows only a token total, not a decomposition of how many of those tokens bought better answers versus redundant computation. And production spend routinely runs at multiples of whatever the development-phase estimate suggested, because development runs against narrow, cooperative test cases, but production runs against the full range of ambiguous and edge-case-heavy requests real customers generate. Analysis of AI agent pricing models puts a number on this: the same agent task can cost up to thirty times more from one run to the next, driven by step count, retry behavior, and context size all varying at once, and under a pure per-token structure that entire swing lands on the buyer's budget. Anthropic has measured agents using roughly four times more tokens than a comparable chat interaction, and multi-agent systems run roughly fifteen times more; a buyer tends to see these figures only once the first production invoice arrives. The usual defense of per-token pricing is that it's more transparent than the alternatives, because it ties the bill to compute a sophisticated buyer can audit and optimize against. That defense holds only if the buyer has the leverage to act on what they see. A buyer who can see every token consumed still can't necessarily touch the vendor's retry logic or context management strategy, so transparency at that granularity is really just a detailed invoice for decisions somebody else made. Does billing by step give the buyer that control back?

Per-step pricing: what it exposes and hides

Per-step or per-action pricing charges for discrete units of work, a record lookup, a system write, a tool call, a conversation turn, and in doing so it ties cost to something the buyer can actually observe: workflow volume, rather than architectural detail buried inside a model call. That shift solves one problem and opens another, because it moves the forecasting burden to the step-count layer, and step counts carry their own kind of variance. What per-step pricing exposes well: cost scales with business activity the buyer already tracks, cases handled, documents processed, actions executed, so a finance team can forecast total spend by multiplying expected workflow volume against a per-step rate, a calculation anchored in business metrics. It also gives the vendor a direct incentive to keep each step efficient, since any bloated token consumption inside a step comes out of the vendor's own margin. What it hides is just as costly: step counts vary by case in ways that are hard to predict ahead of time, a straightforward request might resolve in two steps, while an ambiguous or policy-heavy one branches into twelve, and the distribution of that complexity across a real production workload is about as hard to forecast as token variance itself. The token weight hiding inside each step is invisible to the buyer: a single step in one vendor's definition might be one model call of five hundred tokens, while in another it's three calls totaling fifteen thousand, and the step unit abstracts away exactly the dimension that drives the vendor's own cost. There's also a definitional risk: what counts as a completed step, a billable action, or a resolved workflow needs precise agreement in the contract, and any looseness there turns into billing disputes later. Salesforce's Agentforce Flex Credits, priced at $500 per 100,000 credits, is a concrete example of a per-action structure where total cost depends on the distribution of case complexity a buyer's own customers happen to generate. Agentforce also shows a second structural wrinkle: its Conversations SKU charges per conversation regardless of whether the issue actually gets resolved, while Salesforce's separate Pay-Per-Resolution model (branded Help Agent) charges only for sessions that succeed. Under the Conversations SKU, a buyer pays for failed attempts at the same rate as successful ones, a cost that per-token pricing shares too but that the per-step framing makes harder to miss. The usual defense of per-step pricing is that it's simpler to model and lets finance teams budget against expected workflow volume. That defense assumes the volume forecast is reliable, and it's only as good as the forecast of case complexity behind it. A buyer whose agent ends up handling a wider range of request types than planned faces step-count variance that behaves structurally like token variance, just measured at a coarser resolution.

How task completion definitions change billing economics

Neither unit means anything to the business unless the completion criterion, what actually counts as a successfully resolved task, is nailed down before the system goes into production. Agent cost benchmarking draws this line clearly: a tool call succeeding is not the same thing as a task completing. For a support workflow, completion might require a correct answer grounded in an approved source with no prohibited disclosure; for a coding workflow, it might require a specified test suite passing and a human reviewer accepting the change. Failed attempts still consume resources, and they belong in the cost numerator: leaving them out produces a cost-per-completed-task figure that looks better than reality. Under per-step billing in particular, a retry that eventually succeeds counts as a single completed business task on the outcome side, even though every attempt along the way, successful or not, adds to the step count the buyer gets billed for. Outcome-based pricing tries to close this gap by tying the billing event directly to the completion criterion, as Intercom Fin does at $0.99 per resolved conversation. But Intercom's own definition of a resolved outcome includes cases where the customer simply doesn't ask for further help after the agent responds, a criterion generous to the vendor that shows outcome definitions need just as much contractual scrutiny as step definitions do. A contract needs to define what counts as task completion, how retries and failures get counted, and what happens when the agent produces a partial or ambiguous result, regardless of whether it bills per token or per step. Without that, the pricing model has no reliable connection to the business outcome it's supposed to measure.

Choosing a billing unit by predictable cost surface

The right billing unit is the one that lines up with whatever cost surface a given team can actually watch and influence. A team whose engineers can instrument and bound token consumption, through caching, context management, and prompt discipline, gets real leverage from per-token pricing, because they can act on what the invoice shows them. A team whose product side can define and bound workflow steps, through tighter task scoping and controlled branching logic, gets more out of per-step pricing, because finance can actually forecast against that surface. A few questions help sort which situation a given team is in: whether the team can define a bounded set of workflow paths or whether case complexity varies in ways no one can anticipate before launch; whether the team controls the agent's own context management strategy or is consuming a black-box agent whose retry and reasoning behavior stays hidden; whether the bigger risk is overrunning a predictable workload volume or facing unpredictable cost per task on a known case type; and whether the team's own customer-facing pricing commits to per-outcome or per-task rates, which would mean the team is already absorbing the variance internally and needs a billing unit that matches what it can actually engineer around. Agent cost research names the underlying driver: what determines cost isn't which model is cheapest but how much work the agent repeats before it lands on a trusted result. A shared context layer, one that makes approved definitions, policies, and lineage reusable across agents instead of forcing every agent to rederive the same business context from scratch, cuts both token consumption and step count at the same time. It improves both billing surfaces together. Engineering levers like prompt caching, batch processing, and context summarization reduce the token numerator no matter which billing model sits on top, but they only help the buyer's economics directly under per-token pricing; under per-step pricing, those same savings accrue to the vendor's margin instead. In practice, teams that build and run their own agent infrastructure tend to gravitate toward per-token visibility because they can optimize against it directly, while teams buying an agent platform they can't see inside of tend to prefer the predictability of per-step pricing. Either choice carries a consequence downstream: it determines what the billing infrastructure underneath it has to be able to measure.

Metering infrastructure requirements at agent scale

Metering at agent scale is a different engineering problem than metering a subscription. A single agent workflow can throw off thousands of billable events, token counts, tool calls, step completions, retries, within a few milliseconds, and the billing system has to capture, attribute, and aggregate all of it without slowing the agent down. That requires a few specific things of the event architecture that supports it. Billing events can't sit on the agent's critical path; they need to be emitted asynchronously to a queue, Kafka, SQS, or Redis Streams among the common choices, and processed independently of the workflow that generated them. Ingestion has to run at sub-second resolution, because token consumption and step completions happen fast, and a system batching on a per-minute or per-hour cycle can't attribute costs correctly to the workflow instance or billing period they belong to. Retries inside the agent loop will generate duplicate events, so the metering layer needs to deduplicate them without undercounting legitimate activity. And a single billable event often carries several dimensions at once, token count, step identity, model tier, tool type, workflow ID, so the aggregation layer needs to support arbitrary combinations of those dimensions rather than collapsing everything into one flat token total. Per-token billing specifically needs infrastructure that can ingest raw token counts from every model call across a multi-step workflow and aggregate them correctly across retries, subagents, and parallel branches, a requirement that looks nothing like counting subscription seats or monthly API calls. Per-step billing needs its own schema for what counts as a step, enforced at the point of ingestion, with a way to resolve ambiguous or partial events, a tool call that timed out, a subagent that got cancelled midway, without either double-charging the buyer or leaving a gap in the bill. The common setup of a separate metering tool bolted onto a separate billing tool creates a reconciliation seam right where event volume peaks: any gap between what the metering system counted and what the billing system invoiced needs a manual investigation, and at agent scale those gaps tend to appear at the very first invoice of every billing cycle. Flexprice is built as a single system covering both metering and billing, designed to ingest usage events at up to 1 million per second with under 60ms P99 latency, and it supports pricing across multiple dimensions at once, token counts, GPU-minutes, step completions, or any other agent-specific measure, while running prepaid credit wallets alongside postpaid invoicing on the same engine. So a team selling per-step pricing to its own customers can still instrument per-token data internally for cost attribution, without having to maintain two separate billing codepaths side by side.

Hybrid pricing structures and the reconciliation trade-off

For most production deployments, the trade-off between per-token and per-step pricing doesn't resolve into a clean winner, which is a large part of why the dominant commercial pattern by 2026 is a hybrid: a platform fee that gives the buyer a predictable floor, paired with a metered layer on top that exposes whichever cost surface the team has decided it needs to watch. That hybrid tends to take one of a few concrete forms. A monthly platform fee can cover a defined allowance of tasks or steps, with per-token charges kicking in only above that included tier, so finance gets a fixed floor to plan against and engineering gets a visible target to optimize toward. A prepaid credit wallet denominated in a neutral unit, credits rather than tokens or steps directly, lets the vendor adjust the underlying pricing mechanic over time without changing what the customer sees on their invoice. Or a base subscription can carry a metered overage denominated in workflow completions, with the completion criterion written directly into the contract, tying the billing event to the same outcome definition discussed earlier. The real risk in any hybrid setup is reconciliation. When the platform fee, the step meter, and the token counter each live in a separate system, the first week of every month turns into a manual exercise in matching three numbers that should have been one number all along, which is the exact failure mode that consolidated billing infrastructure exists to prevent. Teams introducing a usage layer on top of an existing flat or per-seat model have a workable path available: roll the metered component out to new signups first, leave existing customers on their current plans until their next renewal, then at renewal add the usage component on top of the existing subscription with an included allowance sized to match average current consumption, so a typical customer's bill stays flat and only heavier users see it grow. That transition needs at least sixty days' notice, and ninety is better for annual or enterprise accounts, along with a worked example showing each customer how their own bill changes. The pricing model itself needs to stay a lever a team can actually pull: a team that can't adjust tiers, change usage rates, or run a pricing experiment without a full engineering sprint loses its ability to respond to what production data shows about real cost distribution, and that data is precisely what the first three months of any hybrid rollout will hand them.