Per seat
A monthly price per named person. Predictable, easy for procurement, and it grows with adoption - every colleague who wants access is a line on the invoice. It assumes a person is the unit of value.
Explainer
AI agent pricing: per seat, per usage or per deployment
Per-seat pricing does not fit AI agents, because a seat is a person and an agent is not one: a working deployment often has more agents than people, and most of its work happens with nobody logged in. Most business software is still licensed by the seat, which is why a per-seat quote for agent work so often scales in a way nobody can explain to the person signing it. This page sets out the three pricing shapes in the market, what each one is optimising for, how to predict your own usage before you have any, and how to compare quotes that are not measured in the same unit.
The unit is the whole argument
Every pricing model is a claim about what the value scales with. Per seat says value scales with the number of people using the software. Per usage says it scales with the work done. Per deployment says it scales with the capacity you reserve. None of these is dishonest; each is right for the product it was designed around. The trouble starts when a shape built for one kind of product is applied to another.
Agent platforms are that case. A seat licence was designed for software a person opens and operates - a mailbox, a spreadsheet, a ticketing queue. An agent is operated by nobody in particular. It is set up by one person, messaged by many (some of them customers who will never see a login screen), and it does much of its work with no one watching at all. Ask "how many seats" of that and every answer is a guess.
So the first thing to do with any quote is not to look at the number. It is to find the unit, and ask whether the unit describes anything real about how you will use the product.
Three pricing shapes
Almost every agent platform quote is one of these, or a hybrid of two.
Per usage
A meter: tasks, runs, credits, tokens or resolutions. Cost tracks work, so a quiet month is cheap and a busy month is not. It assumes the work is the unit of value, and it moves the forecasting problem onto you.
Per deployment
A flat price for reserved capacity - a machine of a given size, with a usage allowance on top. People and agents are not counted. It assumes the unit of value is having the thing running, with usage metered separately.
The hybrid
Seats plus credits, or a base fee plus per-task charges. Common, and worth naming because it can inherit the downside of both parents: adoption is taxed and usage is still variable.
What per-seat optimises for
Per-seat pricing is popular because it is legible. Finance can forecast it from a headcount plan. Procurement can compare two vendors on one number. The vendor's revenue rises as the product spreads through a company, which is a fair reward for being useful. For software that people sit in front of, the seat is a decent proxy for value, and there is nothing wrong with it.
Why agents break it
Three things go wrong at once.
The ratio inverts. A conventional tool has one person per licence and value in proportion; an agent deployment has several agents per person. A small business might spread one person's worth of attention across a research agent, an inbox agent, a bookkeeping agent and a customer-facing one. Per seat prices that as one seat and hopes you buy more. Per agent prices it as four and penalises the design that made sense.
The people using it are not your people. An agent answering enquiries on WhatsApp is used, all day, by customers. They are not seats, they cannot be issued logins, and their number is not under your control. A seat model has no column for them, so it either ignores them or invents a proxy - conversations, contacts, resolutions - at which point the pricing is per usage wearing a seat's clothes.
Most of the work happens with nobody logged in. Scheduled runs, standing instructions, overnight monitoring, background improvement. The point of an agent is that it works while no seat is occupied. A price that counts occupied seats is measuring the part of the product you bought it to avoid.
The practical symptom is a quote that scales in a way nobody can explain. If adding a colleague who will only ever read the agent's output doubles the bill, the unit is wrong, and no discount on it fixes that.
What consumption pricing gets right
Metered pricing fixes the unit. The work is what you are paying for, so the meter counts the work. A month in which the agents did little costs little; a month in which they carried a product launch costs more, and you can see why. It also removes the adoption tax: a tenth colleague reading the dashboard costs nothing, because reading is not work the meter counts.
Underneath, it mirrors how the models themselves are bought. Model providers charge by usage, so a fixed price per seat is a bet the vendor is making about your behaviour, and the bet is priced in.
What it makes scary
Variance. A finance lead can plan for a number; they cannot plan for a meter they have never watched. Three fears come up in every conversation about it, and all three are reasonable.
The runaway. An agent in a loop, or a schedule set too tightly, spending all night. This is a real failure mode. The answer is not to avoid metering but to cap it: a per-agent spending limit with a defined behaviour at the cap, and ceilings on total usage that refuse a turn rather than bill it.
The invisible line. Background work that never appears in a conversation. If the meter only shows chat, the number on the invoice will not match the number on the screen, and every discrepancy reads as a mistake.
The unit you cannot picture. Tokens mean nothing to someone building a budget; "tasks" and "credits" mean whatever the vendor defines them to mean. A meter is only reassuring if you can drill from the total down to the agent, the conversation or the scheduled run that spent it.
Consumption pricing with visibility and caps is the most honest shape in the market. Consumption pricing without them is the one people are right to be afraid of.
Predicting your own usage
You will not have a number before you start. You can have a method.
List the jobs, not the peopleCount runs per day for eachPilot on the smallest planRead the breakdown at seven and thirty daysSet a cap per agentResize when a limit is hit
Count jobs, not seats
Write down what each agent will do and how often: a report every morning, an inbox checked on an interval, a channel that answers customers. Usage follows the schedule, and the schedule is something you set.
Treat background work as a real line
Improvement runs, standing instructions and scheduled tasks spend while nobody is chatting. A platform that records every call on one ledger and breaks the total down by kind of work lets you see that line instead of being surprised by it.
Know the three levers
Which model tier each agent runs on, how often background work fires, and the cap you put on each agent. Each is a setting rather than a negotiation, and the fast everyday tier, which is also the cheapest, is the right default until an agent's work demonstrably needs more.
Comparing quotes that use different units
Put every quote through the same seven questions. The answers matter more than the headline price.
| Question | Per seat | Per usage | Per deployment |
|---|---|---|---|
| A colleague joins to read the output | A new seat. The bill rises. | No change - reading is not metered work. | No change. |
| You add a fourth agent | Usually nothing, unless agents are the seat - then a new licence. | Nothing until it does work. | Nothing; agents are not counted. Capacity may need resizing eventually. |
| A customer messages the agent | Not a seat, so either uncounted or converted into a proxy unit. | Metered as work. | Metered against the plan's allowance. |
| A quiet month | Full price. | Close to nothing. | The base price, allowance unused. |
| A busy month | Full price. | Whatever the meter says. Ask what caps exist. | Base price plus usage beyond the allowance. Ask what caps exist. |
| What you can inspect | The seat count. | Whatever the vendor's reporting shows - ask to see it before signing. | The reserved capacity and the meter. |
| Where the surprise lives | In adoption - the tool spreading is what raises the bill. | In variance - a busy month, or a badly configured one. | In outgrowing the capacity, which usually shows up as slowness before it shows up as cost. |
What Olano does, and why
Olano Cloud is priced per deployment. Every plan is your own isolated deployment with unlimited agents, unlimited people and unlimited connections; what changes up the ladder is how much work the deployment can do at once. Managed plans start from $10 a month, and the recommended agent count on each plan is sizing guidance rather than a licence limit. The figures, and the plans above the shared line, are on the pricing page, which is the only place we publish them.
Model usage sits on top as a meter, in the form that makes the fewest assumptions about you. Olano-managed model tiers are billed in credits from an allowance the plan includes, which you can top up. Or bring your own provider keys, and that usage bills to you directly with no surcharge from us. One agent can run on credits while another runs on your own key, because billing is a property of the model an agent is set to rather than a mode the whole deployment is in.
The meter is meant to be watched rather than discovered. Every model and service call records its charge on your deployment as it happens, so the dashboard's Insights page breaks usage down by agent, by tier and by kind of work - chat, background improvement, scheduled tasks and the rest - and the conversation list shows each conversation with its running cost. Per-agent spending caps take a daily, weekly or monthly figure, warn before it is reached, and at the cap can either switch that agent to a cheaper model or stop it; with neither set, you get the warning and the agent continues. Usage ceilings, per agent and deployment-wide, refuse a turn once they are spent rather than bill it, and notifications fire as a budget fills. Background improvement has its own cadence setting with a daily limit on expensive runs.
Two limits worth knowing. The plan price covers hosting, updates, monitoring, snapshots and model access; designing and building the agents is yours to do in the dashboard, or Olano Studio's if you would rather it were done with you. And a per-deployment shape has an edge of its own: a deployment can be outgrown. Moving up within the shared plans is an in-place resize rather than a new licence, but it is still a step, and it is worth knowing where it sits before you start.
The reason for the shape is the argument above. We could not find a way to count seats that described anything true about how agents are used, and we would rather the unit be the capacity and the work than a number both sides know is a proxy.
FAQ
How is AI agent pricing usually structured?
Three shapes cover almost every quote: per seat (a monthly price per named person), per usage (a meter counting tasks, runs, credits, tokens or resolutions), and per deployment (a flat price for reserved capacity with a usage allowance on top). Many vendors combine two, typically seats plus credits. The unit a vendor counts tells you what it believes the value scales with, and whether that matches how you will actually use agents is the first thing to check.
Why do some AI platforms charge per seat?
Because it is legible: finance can forecast it from headcount, procurement can compare vendors on one number, and the vendor's revenue grows as the product spreads. It was designed for software a person opens and operates. Agents break the assumption because a deployment often has more agents than people, the people using a customer-facing agent are customers rather than staff, and most of the work happens with nobody logged in.
How much does it cost to run AI agents for a small team?
It depends on the unit more than on the team. On a per-seat model the cost follows headcount; on a metered model it follows the work; on a per-deployment model it follows the capacity you reserve plus usage. On Olano a managed deployment starts from $10 a month with unlimited agents and people, and model usage is metered in credits or billed by your own provider if you bring your own keys. The reliable way to get your own number is a pilot month on the smallest plan, reading the usage breakdown at seven and thirty days.
Which is cheaper for AI agents, per-seat or usage-based pricing?
Neither, in general. Per seat wins when a few people use the software heavily and constantly; usage-based wins when there are more agents than people, when customers rather than staff are the ones messaging, or when usage is uneven across the month. Work it out for your own case by pricing three scenarios - a quiet month, a typical month and a busy one - at your current headcount and at double it, and see which quote moves and by how much.
How do I stop usage-based pricing from running away?
Ask for four things and check that they are settings rather than promises: a spending cap per agent with a defined behaviour at the cap, such as switching to a cheaper model or stopping; deployment-wide ceilings that refuse a turn rather than bill it; notifications as a budget fills; and a breakdown of usage by agent and by kind of work, so background runs are visible before the invoice arrives. A cadence setting for autonomous work, with a daily limit on expensive runs, closes the last gap.
Can I avoid a monthly fee by self-hosting?
Yes. Olano can be self-hosted on your own infrastructure, and a self-hosted install has no plan and no credit balance - you bring your own provider keys and model usage bills to you directly. The trade is that you become the operator: updates, connection health and uptime land on you. A managed deployment pays for that to be someone else's job.
Related reading
Where to go next.
Olano Cloud pricing
The plan ladder, what every plan includes, and the questions about credits and keys answered on the page itself.
How to choose an AI agent platform
The evaluation checklist these pricing questions belong in, alongside channels, approvals and audit.
An agent team compared with a human team
The other cost question - agents against labour rather than against licences.
AI agent platform lock-in
What a pricing shape can quietly tie you to, and how to keep the exit open.
Bring the quote you cannot explain.
Send us the pricing page you are weighing, with your headcount and the jobs you want done. We will put it through the seven questions above alongside our own, and say plainly which shape fits - including when the answer is not us.