An AI agent pricing model is the rule that converts what an agent does into what a buyer owes: per person with access, per unit of computation consumed, per agent running, per result delivered, or — when the buyer brings their own model — for the software alone. The choice is not a billing detail. It decides who absorbs the variance when a month goes badly, and it determines which behaviors the vendor is quietly incentivized to encourage.
Published prices in this category move faster than almost anything else in software. This page describes models rather than numbers; the “last reviewed” date at the top is the one to trust, and any figure you need should come from the vendor’s own pricing page on the day you need it.
The five models
Per human seat. The oldest model, priced per person with access. It is predictable, easy to forecast, and structurally awkward for agents, because the premise of an agent product is that work happens without a person present. A per-seat agent product bills you for observers.
Per unit of usage. Tokens, minutes, runs, actions. This is how the model providers themselves price — OpenAI and Anthropic both publish per-token rates — and it passes cost through with near-perfect fidelity. Per-run and per-action variants are more legible than tokens, because a business person can count tickets triaged without a calculator. The failure modes are forecasting, since nobody can predict the line item and a buyer who cannot forecast it will cap it by using the product less, and incentive: revenue rises with the number of actions, including the redundant ones.
Per agent. A recurring price for each agent that exists. It maps cleanly onto how buyers already think about capacity, and its weakness is that agents are cheap to create, so the model only stays honest if the count reflects something real rather than every experiment anybody ever tried.
Per outcome. A price per result the buyer would otherwise have paid a person to produce. Customer support is where this has gone furthest: Intercom’s Fin and Zendesk both price around automated resolutions rather than seats, and Salesforce’s Agentforce has moved through several variants of consumption-and-conversation pricing. It is the most aligned model on paper and the most contested in practice, because “resolved” is a definition, and definitions get argued about at renewal.
Bring your own model. The vendor charges for the software, and the buyer connects their own model accounts — API keys or subscription logins — and pays the provider directly. Inference then costs whatever you already pay: a metered API rate, or a flat subscription with usage limits. There is no markup to find and the bill is one you already understand. The costs are that you manage those accounts yourself, and that a subscription’s usage limit quietly becomes your real spending cap: when it is reached, the work waits rather than billing overage.
What the model is really allocating
Underneath the taxonomy there is one question: who carries the variance.
An agent’s cost per run is genuinely variable. Two runs of the same task against different inputs can differ by an order of magnitude in tokens, and a retry loop that goes wrong can differ by two. Somebody absorbs that. A pure per-seat vendor absorbs it and prices in a margin for the worst case, which means the disciplined buyer subsidizes the careless one. A pure usage vendor pushes it entirely onto the buyer, who now has an unbounded liability attached to a system that runs unattended. Hybrid pricing — a floor plus a metered component — is the market’s compromise, and it is popular for the ordinary reason that both sides find it survivable. Bringing your own model moves the variance onto you, but into a contract you already have with the provider, where the limits are the provider’s and are visible.
The second allocation is failure. When an agent attempts something and gets it wrong, somebody has paid for that attempt: in tokens certainly, in an action count possibly, in an outcome fee only if the contract says so. Ask this early. A vendor whose answer is vague is a vendor whose answer is “you do”.
Questions to ask before signing
What happens in a bad month? Not the median month — the one where an integration breaks and a loop runs for three days. Is there a ceiling, and does it stop the work or merely warn? A budget that sends an email while spending continues is a notification, not a control.
Who pays for retries and failures? Get the answer in writing, per model. Under outcome pricing, establish who decides whether an outcome occurred, and what the appeal is when the two sides disagree.
Is inference being resold, and at what markup? If a vendor buys tokens and sells them inside a bundle, the markup is real even when it is invisible. Bringing your own engine accounts removes it entirely, at the cost of managing those accounts yourself.
What is the unit’s definition, exactly? “Per agent” means little until you know whether a paused agent bills, whether one that was configured but never run bills, and what happens when you remove one mid-cycle. Proration is where billing disputes are born; ask for the policy in writing.
Can you see what each run spent? If the product cannot show consumption per run, in the units the model provider bills in, you cannot audit the invoice or find the one task that is costing you most.
What does the price do when the product is failing? A platform that keeps charging full freight while the machine running your agents is offline is charging for availability it is not providing. A platform that stops working but keeps your records legible is behaving reasonably. Find out which one you are buying.
Ceilings belong in the system, not the invoice
A pricing model tells you what things cost. It does not stop them from costing that.
The control that bounds spend lives in the system: a limit declared where somebody can see it, enforced at the moment of action, that stops the work rather than warning about it. Such a limit can sit in two places. One is per run — a cap on how many turns a single run may take, so one runaway loop cannot become a three-day bill. The other is per account — the usage limit on the model subscription itself, which, if you bring your own model, the provider enforces for you. For actions that spend money outside the model, such as a paid API call or a purchase, the control is a person saying yes before the act; the general shape is covered in human approval workflows. Ask a vendor which of these it enforces, and which it only reports.
How Klingbar prices, and why
Klingbar is free during early access. Klingbar.com takes no money today — there is no payment processor, no card at signup, and no invoice — and this page will not guess at future prices. Access is by invite from the early access list; the pricing page says the same thing in fewer words.
The shape is bring your own everything that costs money to run. The box is a Linux machine you control — a small server, a VM, or a spare computer — and every run happens there. The engines are headless CLIs (Claude Code, Codex, OpenCode, Antigravity, Grok, and Gemini) logged in on the box with your own accounts, so your engine subscriptions pay for runs at whatever terms you have with each provider. Klingbar never buys inference and never resells it. That is the same decision described in self-hosted agents, showing up where an invoice would be.
What Klingbar does is record. Every run carries what it spent as the engine itself reported it: input, output, and cached tokens, turns, and the engine’s own cost estimate. When a run needed more than one attempt, the figures sum over the attempts and say how many there were. When the engine printed nothing — one of the six CLIs reports no usage today, and a run that was killed reports none — the page says “not reported” rather than showing a zero it was never told; a reported zero is shown as a zero. The runs list carries a seven-day estimate for the crew and says how many of the window’s runs reported a figure. Klingbar.com computes no price from tokens. The cost figure is the engine’s own estimate at its list price, which on a subscription login is a reading, not a charge.
What Klingbar does not do is budget. Klingbar.com sets no spending threshold, sends no spend alert, and never blocks a run for cost. The limits that exist are the two described above. A crew or a task can carry a turn ceiling, max_turns, which is passed to the engines whose CLI takes one — Claude Code and Grok. A run that spends it ends with the verdict CEILING, posts nothing, and is not retried; its record names the configured ceiling to raise. Separately, your engine subscription’s own usage limit applies: when a login reaches it, only that login pauses, the job keeps its session and resumes when the limit resets, and a persona whose standby is on another engine can carry on in the meantime.
That is an honest limitation as much as a design. If you want a hard monthly figure, the place to set it is with your model provider, and Klingbar will show you afterwards what each run spent.
Modeling your own costs
Take one task. Run it twenty times against real inputs and record the spread, not the average. Multiply the ninetieth percentile by the schedule to get a monthly figure for that task, then add the platform’s own fee. On a Klingbar box, a read-only tool (python -m crewd.spend) prints those figures as medians per crew, task, and model, from the box’s own run records.
If you bring your own model on a subscription, the question changes shape: not “what will this cost” but “will this fit inside the plan’s usage limit”, and the answer is the same spread measured against the limit. Either way, compare the result with the hours of human work it displaces — and if the comparison only works at the average rather than at the ninetieth percentile, the case is thinner than it looks.
Then watch what the ceiling catches. A turn ceiling that never fires taught you nothing. One that fires occasionally is a working instrument, and the pattern of which tasks trip it is the most useful pricing data you will get, because it is about your own workload rather than a vendor’s rate card.
Prices in this market will have changed by the time you read this; the models above change much more slowly, which is why this page describes them.