The pace is the price

Ask any business what a token costs and you'll get a pause. Ask what an hour of a person's work costs and you'll get a number.

That gap is the whole problem with how AI agents get sold today. Businesses are buying agents for support, operations, legal, sales, and finance, and the people signing off are rarely engineers. They're being asked to budget in a unit they can't see, can't predict, and can't compare with anything they already pay for. So they do the sensible thing. They hesitate.

Finance makes the problem concrete, so it's our running example throughout - the bookkeeper, the reconciliation, the month-end close.

In Signature economy, we argued that a ledger built for agent work should be priced for the SMB and mid-market teams doing the close by hand today. This memo is about what "priced for" should mean - for those teams, and for any business buying agent work. Our answer is older than software.

Nobody wants to buy tokens. Businesses buy work, and the unit they've always bought work in is the hour.

The rest of this is why we think AI labor should be sold by the hour, what it takes to make an hour mean something, and what we haven't solved yet.

Nobody understands the unit

Start with tokens. A model charges one rate for the text it reads, another for the text it writes, and a third for text it has already read and cached. Every model has its own rates. A task that reads a lot costs differently from a task that writes a lot, and both cost differently the second time around. Even engineers who work with this every day struggle to say in advance what a task will cost. The team buying agents has no chance.

Credits were meant to fix that. They give you one currency across every feature. But a credit is a dollar amount in a costume. Every credit system reduces to a price per credit you can work out from the tiers, so customers work it out anyway, and then they still have to guess how many credits a task will burn. "What's a credit?" turns out to be the same question as "what's a token?", one layer up.

The market has already shown how fragile these units are. In June 2025, Cursor moved its Pro plan from 500 requests a month to $20 of model usage at API prices. Three weeks later it apologized - "our recent pricing changes for individual plans were not communicated clearly" - and refunded unexpected charges. The plan cost the same as before. What changed was the unit, and people who were already paying could no longer predict what their money bought.

Seats break the seller, usage breaks the buyer

The pricing models on offer today each break a different side of the deal.

Seats are predictable for the buyer. You know the bill before it arrives. But a seat says nothing about how much work gets done, and with agents that's the whole question. One heavy user can cost the provider more than they pay. Seats also fit a world where people do the work. When an agent does the work and a person reviews it, charging the reviewer a seat charges the wrong person.

Usage is fair to the provider. You pay for what the model consumes. But the bill can drift anywhere, and for the team buying agents, a number that can drift anywhere isn't a budget. It's a risk.

Seats can bankrupt the provider. Usage can bankrupt the customer.

The pricing people praise in this market is the pricing that makes spend predictable and visible. Lindy pauses at zero instead of charging overages. Viktor passes model cost through at no markup. Intercom charges $0.99 per resolved conversation, with a precise definition of what counts as resolved. Each is an attempt to give the buyer something to plan around.

Outcome pricing works well in support because a resolved conversation is a countable event. Most work isn't that tidy. A month-end close, a contract review, or a pipeline cleanup has no single moment that counts as done.

Fast, good, cheap

Every job trades off speed, quality, and price. Pick two.

Look at usage pricing through that triangle. When you choose a model, you fix quality. That's the one corner you fix. Speed and price both float. It's like renting rowers by the stroke - depending on how busy the cluster is, you might get one rower or a thousand, and they'll row through everything you allow. The task finishes when it finishes and costs what it costs, and some of that depends on how well you phrased it.

That's the right deal for some buyers. If you want the best possible answer as fast as possible and don't mind the bill, usage pricing serves you well. It isn't what a business wants from routine work, whether that's tickets, contracts, or the books. A business wants routine work done faster and better, at a cost it knows in advance.

The ideal would be a fixed price per task. But most tasks don't have a knowable size. A bank reconciliation is narrow enough to price. "Work out why gross margin dropped on one job last quarter" isn't. No pricing model has cracked fixed prices for general work, and we don't expect one to soon.

Here's the thing, though. People are bad at pricing tasks, but they're very good at rates. Nobody can quote the price of a reconciliation off the top of their head. Every business knows roughly what a person's day costs, and roughly what that person gets done in one.

Fix the pace, and the hour has a price

So go back to the triangle. Price per task can't be fixed in general. Quality is already fixed by the choice of model. That leaves speed.

Speed is the lever nobody pulls. If we hold an agent to a set working pace, the same amount of work per minute, every minute, then an hour of agent work always means the same thing. It always costs us the same to deliver. And anything that costs the same to deliver can have a fixed hourly rate.

That's the idea. Fix quality and pace, and you can sell AI labor by the hour.

It means doing something that sounds backwards - we deliberately slow the model down. Underneath, a pricing layer watches each task as it runs - how fast it's going, what it's consuming - and holds it to the set pace. Within that pace, it uses every optimization available, like caching and prompt shaping, so the hour holds as much work as it can. The agent is never as fast as it could possibly be. In exchange, everything becomes predictable for both sides.

We call the unit an agent hour. An agent hour is active agent time at a published standard pace. Time spent waiting on a person or a system shouldn't count. Neither should time spent in a queue.

An agent hour is a promise about pace, not a promise about output.

What an agent hour could look like

Picture how it might work. The numbers below are an example, not a price list.

A rate. Imagine one rate to start, say $5 per agent hour, for every agent. Later, different agents could have different rates, the way different specialists do. That's not where you'd start.

A price built from cost. Imagine the rate is what the hour costs to run, plus a small, fixed markup, the way OpenRouter adds a few percent on top of model prices. The markup covers the machinery around the model - sandboxes, processing, monitoring. Nothing in the rate is there to be hidden. If a cheaper model or better caching makes the hour cheaper to deliver, the hour can do more work.

A plan of hours. Imagine a starter commitment of 40 agent hours a month, larger plans above it, and top-ups when you need more. The commitment exists for an honest reason - it reserves capacity for you. There's one pool for the whole workspace and no seats, so the people who review and approve the work never need a license to do it.

A timesheet. Every task shows the time it took - a reconciliation took 18 minutes, the October close took 3.5 hours. Actual time varies by task. But whoever owns the budget can read that line and explain the bill to anyone who asks, because it's written in the unit they already use to explain staffing costs.

Boost. Need it sooner? Put more agents on the task - two, five, or ten. The task costs the rate times the number of agents, for as long as they're working. Five agents for ten minutes is 50 agent minutes. You trade speed against cost on purpose, instead of discovering the trade-off on your invoice.

Max agents at once. The owner sets the monthly plan and how many agents can work at the same time. Allow four agents at once, and the workspace can never use more than four agent hours in an hour of real time. The plan lasts the month because the ceiling is built into the pace.

A queue, not an error. When every allowed agent is busy, new work waits its turn. You don't get a rate-limit error. You see that your request is queued under the limit your admin set. It starts on its own as soon as an agent is free, and you don't need to do anything.

Here's how that adds up for a team. Say ten people each use about one agent hour a day. That's around 50 hours a week, or roughly 200 – 240 a month. At the illustrative $5 rate, that's about $1,000 – $1,200 a month for the whole team. The owner knows it before the month starts.

The comparison buyers already make

The deepest advantage of the hour isn't that it's predictable. It's that buyers can compare it with something.

Nobody can compare a credit with a person. Everybody can compare an hour with one. A US bookkeeper costs a business about $34 an hour, including taxes and benefits, according to the US Bureau of Labor Statistics. In Germany, back-office finance staff cost about €30 an hour, according to Eurostat, the EU's statistics office. A buyer can hold those numbers next to an hourly rate and reason about them immediately.

Finance is our example, but the comparison isn't specific to finance. A business buying a support agent can hold the rate next to what an hour of its support team costs. A law firm can hold it next to a paralegal's hour.

The same goes for outsourcing, which is the real alternative for many finance teams. A dedicated offshore bookkeeper costs a US company roughly $11 – $16 an hour at published prices: $1,799 a month for a dedicated bookkeeper from Wishup, and from $1,988 to $2,500 a month for dedicated staff from MyOutDesk. A mid-level bookkeeper in Latin America earns $2,500 – $3,000 a month before the agency's fee, according to Hire with Near.

An agent hour and a human hour don't produce the same output, so the rate is only half the comparison - but it's the half everyone already understands.

What remains hard

None of this is solved. Here's what we're still working through.

1. Predicting the price of a task. For most work, nobody can tell you up front what a task will cost an agent. Sizes vary, and so does the path to the answer - in Anthropic's research, how many tokens an agent spent explained 80% of the difference in how well it did. That's exactly the problem the hour avoids - it doesn't solve it. Repeatable work, like a monthly reconciliation, is where that changes first: with enough history, its price becomes predictable. Until then, the hour is the honest unit.

2. Picking the right model and effort. Not every step needs the strongest model or the deepest thinking. Matching each step to the cheapest model and the lowest effort that still gets it right is what makes an hour go further. Research on routing, like FrugalGPT and RouteLLM, shows big savings are possible, but nobody does it well in production yet.

3. Knowing when a task is done. A person stops when the work is good enough. An agent can keep refining, checking, and exploring. Researchers call this overthinking: on real software tasks, curbing it improved results by almost 30% while cutting compute by 43%. Where "done" sits decides how many hours a task really takes.

---

The industry has spent the last few years inventing new units for AI: tokens, credits, compute units, effort. Each one asks the buyer to learn a new currency before they can decide whether the work is worth it.

The hour needs no explaining. Every business has budgeted in hours for as long as it's paid for work. Finance teams, support leads, and law firms all know what one costs and roughly what one is worth. The job isn't to teach anyone a new unit. It's to make an agent hour honest enough to sit next to the hours they already know.