Every subscription I pay for has a number I can say out loud without looking: this much, once a month. Every product I've worked on that bills by use has a much harder problem than pricing, and it starts with a boring question. What exactly did you just charge me for?
This is a write-up of the meter we had to build, because the product is a long-running agent and there is no honest way to sell one of those on a monthly plan. Three units we rejected, the one we kept, the objections we got wrong, and the failure modes that only show up once money is attached to an execution.
The unit is the design, not the billing detail
A subscription prices capacity. You pay for the right to have a seat, a workspace, a plan tier, whether or not anything happens. That works when the thing being sold is a place to keep work.
An agent isn't a place. It's an execution: you hand it a request in a sentence, it goes and reads, decides, writes, and comes back with a document. The thing that costs us real compute is not your account existing. It's the twenty minutes where the run is happening.
So a monthly plan has to answer a question with no good answer: how much execution is in a month? Everyone answers it by inventing a unit and hiding it — credits, "generations", message counts, or a limit with an asterisk. The user then has to do currency conversion in their head between their actual work and our internal ledger. That conversion is where trust dies, because nobody can check it.
Whatever the meter is, it has to be something a person can point at and say: that one, I did that one.
Three units we rejected
Tokens. It's the truthful cost, and it's useless as a bill. Nobody knows what a document is worth in tokens before asking for it, so the only way to use the product is to spend first and find out. We'd be handing someone an invoice written in a language they don't speak and calling it transparency.
Minutes. Time is measurable and feels fair, which is why it's the trap. The moment the meter is on the clock, every incentive in the system changes: a slow pipeline is a bigger bill, and a run that's waiting on a rate limit costs the same as one that's thinking. Worse, the customer starts optimizing the wrong thing — asking for less, asking for shorter, watching a timer instead of reading the result.
Seats. Seats are a proxy for "how many people care", which is fine for a wiki and meaningless here. One person with a real, recurring need can hammer a system harder than a team of ten who signed up to look.
All three share one property: the number that appears on the bill is not the thing the person asked for. They asked for a document. The bill should be about documents.
The unit we kept: the run
A run is one request, one finished artifact. Start is when the request is accepted. End is not when the process exits — it's when there is a document you can open, edit, and file. That second boundary is the important one, and it's the one that took the most work to make true.
The reason the end boundary matters for billing is that runs are not clean. In an unattended system, an execution can be interrupted, resumed, retried, or extended. If the meter is attached to attempts, then a flaky upstream turns into a bill the customer can't predict and can't explain, and the only person who can explain it is us. That is not a meter, it's a hostage situation with a receipt.
So the charge is attached to the delivered artifact. Internal attempts, re-reads, and dead ends inside the run are our problem — they're the cost of running the thing, and they're already reflected in what a run costs. One document on the bill, one line. If I can't map a charge to a document the person asked for, the meter is broken, not the customer's understanding.
The objection was never price
We assumed the resistance to pay-as-you-go would be money. It wasn't. It was the invoice.
Ask someone why they keep a monthly subscription they barely open, and the answer is rarely "it's cheap". It's that a monthly plan has one virtue pay-per-use doesn't: the bill is knowable in advance. You can decide on the first of the month what this will cost you. With usage billing, the fear is not the amount, it's the ceiling: what if it's big, what if it's wrong, who do I argue with.
That fear is rational and it's a design problem, not a messaging problem. Two things have to exist before usage billing is usable by a normal person:
- A number before the work, not after. Before anything expensive starts, you should be able to see what this request is likely to cost, in the same units as the bill, and change your mind for free.
- A line after the work that matches the thing you asked for. One artifact, one line, with the request beside it. Not a breakdown of internal steps, which is our cost structure, not your purchase.
The phrase we kept coming back to internally is a bill you can read before you spend. It's a strict standard. It rules out "surprise" as a business model, which is exactly why it's worth writing down: if the estimate and the final line ever disagree badly, something is wrong with our estimation, and the product is supposed to tell you that rather than charge you for it.
Nothing accrues while it waits
The other half of the meter is what it does when the agent isn't working.
Subscription tools are honest about this — idle is included. Time-based metering isn't: a scheduled thing that wakes up every morning, finds nothing to do, and goes back to sleep still burned a minute, and on a time meter that minute is on your bill. Do that 30 times and you're paying for the agent's patience.
For something described as always on, that's the wrong shape entirely. Always on should mean available, not billing. A run that is sitting in a queue because it's waiting for its scheduled time isn't working; there's nothing to charge for. The meter starts when the reading and writing start.
That single decision has a visible consequence, and it's the one people notice first: the bill can be zero. Not a trial, not a discount, an actual month where the line is absent because you didn't ask for anything. It lets you not use it — which, for a tool you're not sure you need yet, is the only honest way to be told to try it.
For the same job it comes out several times cheaper than the comparable monthly plans, and you pay only for what you use. I want to be careful about that sentence: it's true of the work we've measured, and it isn't a promise that usage billing always wins. If you need something running constantly, all day, every day, a flat monthly fee will beat a meter. That's fine. The meter is for people whose need is real but not continuous, which is most people with a document problem.
Failure modes that only appear with money attached
The moment a charge is attached to an execution, some bugs stop being bugs and become incidents. Three we had to design around.
The run that doesn't know it's done. An agent can finish the writing and then keep going: re-reading, second-guessing, adding a section nobody asked for. Without a stop condition this is a slow leak, and with a meter it's a leak the customer watches. The end of a run has to be a decision the system can make and defend — there is an artifact that satisfies the request, so stop — not a budget that runs out.
The ambiguous completion. If the process died halfway, is that a failed run or a short one? Getting this wrong is worse than getting the price wrong, because it makes the bill unpredictable in a way the customer can't audit. The rule we use: the run ends when a complete artifact exists. Anything else is an unfinished run, and unfinished work isn't a thing you can be charged for having received.
The silent duplicate. Retries create the classic double-charge bug, and it's usually invisible until someone reconciles a statement. We handle it the boring way: the run has an identity from the moment the request is accepted, and the charge hangs off that identity rather than off the HTTP call. Ten retries of the same request are still one document.
None of this is novel billing engineering. It's just the part that becomes mandatory once the number on the invoice is attached to something a person can see happening.
What this doesn't solve
The meter doesn't make the output better. A readable bill and a good document are unrelated properties, and it would be easy to write a post implying that charging by the run makes runs worth paying for. It doesn't.
It also doesn't make small tasks feel worth it. If what you need takes a person two minutes, a metered agent is the wrong tool regardless of how fine-grained the unit is; the overhead of describing the request is the whole cost, and no billing scheme fixes that.
And an estimate is an estimate. A request that turns out to be much larger than it sounded — the source material is messy, the scope widens — will come in above the number shown at the start. The honest version of that is to surface it while the run is happening rather than after, which is what we do, and it's still not a guarantee.
A five-minute test
If you want to judge a usage-billed agent rather than read about one, the test is about the meter, not the prose.
Ask for something real, in one sentence, the way you'd actually think it. Before it starts, look for a number: will this cost me something I can see, and can I back out before it does? Then let it finish and look at what comes back — is there exactly one line, and does it name the document you asked for, or does it name a unit you've never heard of?
Then leave it alone for a week and check the bill. If something accrued while you weren't asking for anything, the meter is attached to the wrong thing.
Where it sits
CloudPal runs long tasks on our machines and hands back a finished document — nothing to install, nothing asked of your computer, nothing read from files you already have. You describe what you want in a sentence; it goes and does the reading and writing, and the charge is one run, one charge, with the bill readable before you spend.
It's in limited preview. New accounts get a dollar of credit, which is enough to run something real, and the number of new accounts per day is capped.
If you're evaluating it as an engineer, the interesting property isn't the output quality — read that yourself. It's whether the accounting matches the work: one artifact, one line, nothing accruing while it waits.
CloudPal.TuringCorp.net - create an Agent Pass, sign in, and say what you want done.
Earlier in this series: we deleted the install step and found out it was holding the whole design together, what breaks when an agent has to keep an appointment, and why the engineering is everything the request left out.
Top comments (0)