AI Agent Pricing: Per-Seat vs Usage-Based vs Hosting (2026)

Why AI agent pricing is confusing

Ask three vendors what an agent costs and you get three different units. One charges per user per month. Another bills per action or per token. A third quotes a hosting fee and leaves the model bill to you. They are all measuring different things, which makes side-by-side AI agent pricing feel like comparing a phone plan to a power bill.

This guide untangles the three cost structures you will actually meet, per-seat, usage-based, and self-hosting, and puts real numbers on each. The goal is that by the end you can look at any pricing page and know which bucket it falls in and what it will cost you at your usage.

The single most useful thing to internalize first: an agent has two separate cost lines that behave differently. There is the compute to keep the process running, which is mostly flat, and the model tokens it spends thinking, which scales with use. Most pricing confusion comes from conflating them. Keep them apart and the rest is arithmetic.

The three AI agent pricing models

Model	You pay for	Scales with	Best for
Per-seat	Each human user per month	Team size	Products where humans drive the agent
Usage-based	Actions, runs, or tokens	How hard the agent works	Bursty or automated workloads
Self-hosting	Compute + your own token bill	Instances plus usage	Control, privacy, predictable scale

Per-seat pricing

Per-seat is the familiar SaaS model: a flat fee per user, often $20 to $100 per person per month, sometimes far more for enterprise tiers. It is simple to budget and it is the right shape when a human sits behind every agent, like a coding assistant one developer uses.

Where per-seat breaks is automation. If your agent runs on a schedule with no human attached, paying per seat makes no sense, because there is no seat. And per-seat plans usually still meter usage underneath, so heavy users hit fair-use caps and overage fees that the sticker price hid.

Usage-based pricing

Usage-based bills for what the agent does: per run, per action, per thousand tokens, or per task completed. It is honest for bursty and automated work, because an agent that ran twice this month costs almost nothing, while one that ran ten thousand times costs accordingly.

The risk is a bill you cannot predict. Usage-based pricing turns every design decision into a cost decision. An agent that re-reads a long document on every step burns tokens invisibly. Without a spend cap, a runaway loop is a runaway invoice. Always set a budget alert before you ship a usage-billed agent.

Self-hosting

Self-hosting means you rent the compute and pay your own model provider directly. There is no per-seat markup and no per-action margin going to a vendor. You pay for a server and for tokens at the raw provider rate. It is the cheapest at scale and the most work, since uptime, secrets, and updates are yours. We compare the hands-off and hands-on ends of this in move your local AI agent to the cloud.

What the compute actually costs

Compute is the predictable line. An agent process is usually I/O-bound, waiting on API calls, so it needs little CPU. Real numbers for hosting one agent:

Small VPS: $4 to $12 per month (DigitalOcean, Hetzner, Vultr). Fine for one or two agents.
PaaS service: free tier for hobby use, then $5 to $25 per month per service (Fly.io, Railway, Render). We list the free options in free AI agent hosting.
Cloud VM: roughly $10 to $40 per month for a small on-demand instance; check the AWS EC2 pricing page for current rates by size.
GPU instance: only if you run models yourself, and this changes everything. A GPU box is $0.50 to several dollars per hour, which is $360 or more per month if left on. Most agents call a hosted model API and never touch a GPU.

The takeaway: for an agent that calls an LLM API, compute is cheap and flat, usually well under $50 per month even for several agents. The compute line rarely decides your budget.

What the tokens actually cost

Tokens are the line that scales, and the one that surprises people. You pay your model provider per input and output token, and rates vary widely by model: frontier models cost noticeably more per token than smaller, faster ones. Rather than quote numbers that move, check the provider's own pricing page (OpenAI, Anthropic, Google, and the open-model hosts all publish current per-token rates), and reason about your usage instead:

A light agent that classifies a few hundred short messages a day costs a few dollars a month in tokens.
A medium agent that summarizes long documents thousands of times a day can run tens to low hundreds of dollars a month.
A heavy agent that reasons over large context on every step, at high volume, is where token bills reach hundreds or thousands.

Two levers cut this bill hard: use a smaller, cheaper model for the easy calls and reserve the expensive one for the hard ones, and avoid re-sending the same context on every step. Retrieval and memory design matter here, which is why vector database for AI agent memory is partly a cost article in disguise. Sending less context means spending fewer tokens.

A worked example: what one production agent costs

Say you run an agent that triages 500 support emails a day, drafts replies, and files each into a CRM. Rough monthly math:

Compute:   1 small always-on instance          ~$10/mo
Storage:   persistent volume for state          ~$2/mo
Tokens:    ~500 classifications + drafts/day
           mixed small + larger model calls    ~$40-90/mo
--------------------------------------------------------
Total:     roughly $55-100/mo, token-dominated

Compute:   1 small always-on instance          ~$10/mo
Storage:   persistent volume for state          ~$2/mo
Tokens:    ~500 classifications + drafts/day
           mixed small + larger model calls    ~$40-90/mo
--------------------------------------------------------
Total:     roughly $55-100/mo, token-dominated

The shape is typical: compute is a rounding error, tokens are most of the bill, and the total is modest for the work replaced. Scale the email volume 10x and the compute barely moves while the token line grows almost linearly. That is the mental model for AI agent pricing in one example: budget the tokens, not the box.

How the runtime affects the bill

Where and how the agent runs changes the cost too. A poorly-built runtime that restarts and redoes work doubles your token spend. One that caches context and resumes cleanly saves it. If you want to understand the always-on layer that this depends on, what is an AI agent runtime covers it. The efficiency of that layer is a real, and often ignored, cost lever.

Reading any pricing page in 30 seconds

When you next hit an agent product's pricing page, run this checklist:

Find the unit. Per seat, per action, per token, or flat hosting? That tells you the model.
Find what scales. Which number goes up when you use it more? That is your real bill at scale, not the headline price.
Find the token story. Is the model bill included, or is it "bring your own key" on top? Bundled looks pricier and can be cheaper, or the reverse.
Find the cap. Is there a spend limit or budget alert? If not, assume the worst case is possible.

Answer those four and you have decoded the pricing, whatever creative unit the page used.

The hidden costs that do not appear on any pricing page

Three real costs never show up in a vendor quote, and they change the total more than the headline number does:

Retries and failures. An agent that fails and retries pays tokens twice. A runtime that restarts and redoes work instead of resuming from saved state can quietly double your token line. This is why the execution layer is a cost decision, covered in what is an AI agent runtime.
Context bloat. Every extra token of context you send on every call multiplies across thousands of calls. An agent that re-sends its whole history each step costs far more than one that sends only what it needs.
Engineering time. The cheapest hosting on paper can be the most expensive in practice if you spend your weekends keeping it alive. Value your own time and the build-versus-buy math often flips toward managed.

None of these are on the pricing page, and all of them are in your bank statement.

Four levers to cut the bill

Once you know tokens dominate, the optimizations are clear:

Right-size the model. Use a small, cheap model for classification and routing, and the expensive frontier model only for the hard reasoning. Mixing models by difficulty is the single biggest lever.
Trim the context. Send the model what it needs, not everything you have. Good retrieval instead of dumping the knowledge base cuts tokens directly.
Cache and resume. Persist state so a restart continues instead of recomputing. Cache repeated prompts where the provider supports it.
Batch the cheap work. Group low-priority tasks and process them together rather than firing a full model call per event.

Applied together, these routinely cut a token bill by half or more, without changing what the agent does. The pricing model you chose sets the unit; these levers set how many units you burn.

The honest recommendation

For a single human-driven agent, per-seat is fine and simple. For automation with no human attached, usage-based or self-hosting wins, because you are not paying for seats nobody sits in. For anything at scale, or where you want predictable costs and control over your own token spend, self-hosting on a managed platform gives you the raw provider rates plus the uptime and security you would otherwise build yourself. Sokko runs each agent as an isolated workload and leaves the model bill directly between you and your provider, so the pricing stays legible: flat compute, plus the tokens you actually spend. See Plans and pricing for what each tier costs.