The meter is not running

What the pipeline costs, who pays per token instead, and why a watertight spec turns out to be a cost lever.

The second question

The first question people ask about the pipeline is what it runs on. The last post answered that one at beer mat length. The second question usually arrives a little later in the evening and a little closer to my ear, the way money questions do: what does this cost?

I understand why people brace for the answer. We have all sat through the vendor deck where the agent platform turns out to have a per-seat licence, an onboarding programme and a customer success manager. So the honest answer feels almost impolite: this runs on a subscription I was already paying.

The bill, itemised

The shape of the bill matters more than the total, so let me itemise it properly. Linear was already there, holding the backlog it had always held. GitHub was already there. The Mac Studio was already on the desk, doing Mac Studio things. The watcher cost me an afternoon, which I have written off as entertainment. And the agent runs on the big Claude Max subscription, which is about two hundred dollars a month.

Two hundred dollars is real money. It is also the only line on the bill, and it was already leaving my account every month for the ordinary business of writing software. So the marginal cost of asking the system to build the next feature is, rounded honestly, nothing. My accountant has had more exciting quarters.

The subscription is the whole bill, and the bill already existed.

Flat price or meter

Now, to be fair: my setup is deliberately the flat-fee flavour of this, and not everyone gets to choose it. If you run agents in the cloud, connected straight to GitHub, a subscription can sometimes cover it, but a lot of enterprise setups go through the API instead. And the API charges per token, which is a very different way to experience the same technology.

Neither is wrong. But meters change people. When every run costs money, every run becomes a small purchasing decision. You save the agent for issues that feel worth it, you think twice before trying something that will probably fail, and thinking twice before trying something that will probably fail is a polite description of not experimenting any more. Nobody plans to ration. The meter does it for you.

With a flat price, none of that happens. I hand the agents small issues that would never survive a purchasing decision. I hand them issues where I suspect my own spec is weak, just to see what the ASSUMPTIONS section makes of it, which has turned out to be the cheapest spec review I have ever had. And when a pull request is wrong, I close it and feel nothing, because nothing was spent. An evening of agent runs costs the same as an evening of not running them. I dropped that line almost in passing last week, and it is quietly doing more work than the rest of the architecture combined.

Nobody plans to ration. The meter does it for you.

The spec is a cost lever

There is a second dial hiding in this system, and I only noticed it once the first one stopped moving.

Not every issue needs the smartest model. If the spec is watertight, with testable acceptance criteria and the don't-wants spelled out, then most of the thinking has already happened, on paper, before any model gets involved. A cheaper, faster model can carry out work like that just fine, because carrying out is all that is left to do. The vague issues, the ones where something still has to be figured out, go to a smarter model, which burns more tokens and earns them.

Deciding which issue gets which model is still me, per issue. An agent could make that call too, but I have not yet given the intern the company credit card.

The same flexibility applies one level up. The workflow is built so I can swap the model out entirely, and run an issue through Codex instead of Claude if I want to. The models are suppliers. The specs, the templates and the standing project rules are the asset, and they are the part that keeps its value when the pricing page changes. Which, in this market, it will.

The models are suppliers. The specs are the asset.

The column that is not on the invoice

Now the honest part, because a cost story this cheap should make anyone suspicious, CFOs first.

The money column rounds to a subscription. The hours column does not. What this pipeline actually consumes is specification time at the front, because an issue has to survive a reader that never asks questions, and review time at the back, because every pull request arrives from a confident stranger and deserves to be read like one. Neither of those shows up on an invoice. Both used to be hidden inside the general busyness of building. The cost has not disappeared. It has changed currency, from money into judgement, and there is no second subscription for judgement.

If you hold the budget

So, for the founders, CFOs and agency owners this series keeps circling back to: if someone proposes an agent pilot priced like an infrastructure project, with a platform, a programme and a steering committee, you are allowed to ask why. The experiment costs a developer, a subscription and an afternoon. The business case is short enough that you have already read it.

Budget generously for the unglamorous side instead: time to write specs that survive a literal reader, and protected time to review what comes back. Those two line items decide whether any of this works, and they are the two that never make it into the deck.

Budget for judgement. The tooling is a rounding error.

What's next

The next post is a field experiment I did not entirely volunteer for. I am going on holiday, and the agents are not. What happens to a backlog when its owner is on a campsite, how much of this system survives two weeks of benign neglect, and what that says about the difference between automating your work and automating yourself. Written with whatever evidence the campsite wifi permits.