← All articles
Security & Governance Business Leaders Published · · By ObjectStack Team

AI Agent Pricing: Per-Action Billing vs. Self-Hosted Runtime Cost

At $0.10 per Agentforce action, a successful agent can make usage-based pricing rise quickly. Compare per-action billing with a self-hosted runtime before you scale.

AI Agent Pricing: Per-Action Billing vs. Self-Hosted Runtime Cost
  • Cost
  • ROI
  • Per-Action Billing
  • Self-hosted
  • Agentforce
  • Perspective

The short version: Per-action billing means cost can rise as your agent succeeds. The real cost depends on whether usage grows with success, what you pay for compliance and lock-in, and where the self-hosting break-even point sits.

At quarter’s end, the CFO opens the agent platform’s bill and pauses: it’s four times the budget.

No one overspent; quite the opposite. The customer-service agent was simply too successful. Lay the numbers out: before launch, the team handled about 5,000 tickets a day; after the agent went live, per-person efficiency rose and throughput doubled to about 10,000. The platform bills per action. For every ticket handled, the agent may look up the customer, look up the order, check history, query the knowledge base, issue a refund, and send a notification: seven or eight actions to start. Rough math: 10,000 tickets x 7 actions x $0.10 is about $7,000 a day, or about $2.5 million a year. The budget, meanwhile, had been estimated around “5,000 tickets, fewer actions per ticket.”

Here is the uncomfortable part: the more successful this project is, the more the bill rises. So the board’s first reaction is not to celebrate doubled efficiency; it is to ask, “Can we throttle usage?” A success that should be scaled gets slowed by its billing model. Before the ROI has fully materialized, scale is already constrained by cost anxiety.

A Dime, Multiplied by a Number That Keeps Inflating

Salesforce’s Agentforce Flex pricing can be modeled at $0.10 per action. Look at the unit price alone and it seems harmless.

But this is exactly what to watch in agent billing: it ties cost to usage, and the entire point of an agent is to act autonomously, frequently, and tirelessly. The more autonomous the agent, the more intermediate actions it may use to complete one request well. A request to “tidy up this customer’s situation for me” might involve a dozen tool calls behind the scenes, and those calls are hard to count or cap in advance. Some platforms bill per token, which can be even harder to predict. At equal consumption, the difference between usage-based SaaS pricing and a fixed self-hosted deployment can become material very quickly.

Isn’t Pay-As-You-Go Cheaper and More Flexible?

Take the rebuttal seriously, because in many scenarios it is correct: pay-as-you-go has no upfront investment, you spend less when you use less, the vendor runs operations for you, and you only pay for value produced. This logic was validated repeatedly in the cloud era, so why would it not hold for agents?

It holds, but with one precondition: the “quantity” that cost grows with must be decoupled from, or weakly correlated with, your value. Cloud storage billed per GB is fine, because storing more usually means a bigger business that can afford it; the two track roughly in sync.

Agents weaken this precondition. They bill per action count, and action count can rise with degree of autonomy and degree of success. The more you want the agent to do, and the more carefully you want it to do the work, the more actions it may fire and the higher the bill can rise. This becomes a kind of tax on success: the harder you optimize, by having the agent check one more step or verify once more to improve quality, the higher the variable cost. Traditional software bills per seat, so cost is capped no matter how intensely you use it. Bill per action, and the more the agent succeeds, the more you pay.

So How Much Usage Justifies Running It Yourself? Compute the Crossover

Do not stop at “it depends.” Using the CFO’s two numbers, you can roughly compute the crossover point.

On the self-hosting side, assume annual cost is fixed at about $250,000 (license + infrastructure + a share of ops), and it barely varies with call count. On the per-action side it’s $0.10 × number of actions. Set the two equal:

$250,000 = $0.10 × annual actions
annual actions ≈ 2.5 million  →  about 6,800 actions per day

In other words, once your daily agent actions exceed roughly 7,000, per-action billing starts costing more than the self-hosted assumption, and the gap widens from there. Back to that CFO: at 70,000 actions a day (10,000 tickets x 7), the team is ten times past the crossover, which is why the annualized bill reaches roughly $2.5 million. The pain is not an accident; it is the natural result of choosing a variable pricing model for a high-volume workload.

You can apply this formula directly to your own numbers: multiply your team’s daily interaction volume by “roughly how many actions per interaction,” compare against the ~7,000 mark, and you’ll know which side of the crossover you’re on.

Three Cost Models, Laid Out Side by Side

ModelRepresentativeWhat cost grows withPredictabilityWhere the data is
Per-action / per-tokenAgentforce Flex ($0.10/action)Inflates linearly or even super-linearly with action countPoor — the better you use it, the more expensiveVendor cloud
Per-seatMost Copilot-classGrows with headcount, capped but not low per personMedium, but decoupled from agent autonomyVendor cloud
Self-hosted runtimeObjectStack / ObjectOSGrows with infrastructure, basically decoupled from usageGood — double the usage and the curve barely movesYour own infrastructure

Per-seat pricing looks stable, but it has an inherent contradiction: an agent’s value lies in replacing a large volume of repetitive labor without taking a seat, yet you are still paying per “head.” The billing dimension and the value dimension do not line up. Self-hosting changes the cost structure: you pay for the execution engine and your own compute, and when usage goes from ten thousand to a hundred thousand, the bill does not increase tenfold in the same way.

First, Be Honest: Self-Hosting Is Not Cheaper Everywhere

Do not take “save 40-60%” as universally true. It has a range where it holds, and crossing the boundary breaks it.

That $250,000 headline number does not count people. Self-hosting means you need someone to run operations, patch, and guarantee availability. If you have no platform team, this hidden labor cost can consume a large share of the paper advantage and push the crossover point to the right. Self-hosting also has fixed costs: infrastructure and operations are spent up front, with little relation to usage.

So in the very-small, very-low-frequency, purely experimental stage, pay-as-you-go is often more flexible and cheaper. You do not need to keep a team around to run a nearly idle runtime. Self-hosting’s advantage only materializes once you are reasonably confident you will reach scale.

The Truly Expensive Line Item Isn’t on the Price List

Even once you’re on the side where self-hosting pays off, comparing only the monthly bill still underestimates the problem. Before picking a billing model, what you should truly compute is three bills, two of which aren’t on the price list:

  1. The usage bill: will cost rise with success? This is the CFO’s four-times bill: whether your usage is positively correlated with the agent’s success. If yes, per-action pricing can become expensive quickly.
  2. The compliance bill: the cost of data leaving your domain. Per-action and per-seat SaaS means business data flows continuously to the vendor cloud. With the EU AI Act phasing in and CADA proposing a sovereignty framework, the cost of a single data-residency issue could outweigh many years of license savings.
  3. The lock-in bill: the cost of not being able to leave later. When business definitions, processes, and permissions all grow inside one platform, migration cost compounds with time in use. You think you’re paying for software; you’re actually putting down a deposit on “not being able to leave later.”

Add these three together and the surface cheapness of “a dime an action” can disappear quickly.

Why Self-Hosting Can Pin All These Down at Once

The core is just one line: you pay for the engine that runs this business definition, not for how many times it gets called. From this:

  • Cost decoupled from usage. ObjectOS executes the business definition on your own servers, and however many times the agent calls a governed tool, it’s not billed per call — cost is determined by infrastructure: predictable and plannable. That CFO’s tickets double and the bill barely moves.
  • Data stays in domain. Objects, permissions, and audit evidence all stay on your own infrastructure, so compliance risk and the cost of data leaving your domain drop together.
  • No lock-in. The business definition is metadata in your repository under an open protocol (Apache 2.0): diffable, migratable. What you buy is the runtime’s service, not a deposit on “not being able to leave later.”

Closing

“$0.10 per action” looks harmless when you are starting with low usage, and becomes material when usage takes off. Back to that CFO at quarter’s end: the bill was not out of control; it was the expected result of a billing model tied directly to action volume. It produced the biggest bill at the moment the team should have been celebrating.

When you do the math on agent cost, don’t just look at unit price. Compute those three bills — usage, compliance, lock-in — then use that crossover formula to compare against your own usage. Work all this out, and “self-hosting saves 40–60%” stops being a slogan and becomes a conclusion you can write into the budget — one you also know when not to count on.

npm i -g @objectstack/cli && os start

Stand up a business object on your own machine, have an agent call it thousands of times, and look at the bill. There is no “$0.10 each” line item.