The unit economics of running cattle

The first time I ran headless agents in earnest, I burned through a quarter of my Anthropic monthly limit in three days. I told that story already as a parable about treating agents as pets. It is also a story about money — and the money story is the one almost nobody plans for before it happens to them.

The pet model has a hidden cost-control mechanism that nobody designed deliberately and nobody notices until they remove it. The cattle model removes it. If you do not replace it with something explicit before the workers go headless, you find out about the gap at the bottom of an invoice.

This is the post about the replacement.

The pet model’s hidden subsidy#

When you run a pet agent, you are the spend control. Not metaphorically — literally. The reason your bill stays sane is that your attention is the bottleneck. You can only watch one or two sessions at a time. Each session can only spend money while you are in it. When you walk away from the keyboard, the spending stops because the conversation stops.

This is invisible until you scale. As long as the human is in the loop, three things happen automatically:

• You notice runaways. The agent that has been chewing on the same prompt for ten minutes producing nothing is something you see and stop. You do not need a metric for it. You see the spinner.
• You pace yourself. Token-heavy operations — long context windows, large diffs, tool calls with big outputs — get throttled because you are the one initiating them. You feel the lag and back off.
• You self-throttle on quota. When the dashboard creeps up, you slow down. The dashboard is your conscience. The agent has no conscience.

None of those mechanisms exist in cattle. The agent does not see its own cost. The agent does not see the dashboard. The agent does not get tired. Twenty headless workers running unattended, each invoking expensive tool calls in tight loops, will produce a bill that bears no relationship to the value of the work — unless something between them and the provider says no.

The pet model’s economics work because the human is the rate-limiter. The cattle model’s economics work because something else is the rate-limiter. That something else is the actual subject of this post.

Tokens are the wrong unit#

The first instinct, when the bills get scary, is to start counting tokens. Token-counting feels rigorous. The provider exposes per-call usage. You can build dashboards. You can say “this prompt averages 12,000 input tokens, this one averages 40,000” and feel like you are doing the work.

It is the wrong unit.

Tokens are an input cost, not an output measurement. A worker that burns 200K tokens to close one bead and a worker that burns 800K tokens to close five beads — the second worker is four times cheaper per outcome, even though it spent four times more on tokens. If you optimize the token line you will end up trimming context windows on the second worker until it stops being able to close beads at all, and you will congratulate yourself on the savings.

The unit that matters is cost per closed outcome. A bead closed. A test passing. A PR merged and reviewed. The denominator is the work the system actually delivered, not the inputs it consumed getting there. Token cost without an outcome attached is just spend.

This is harder to measure. It requires the orchestrator to know when a worker produced a real outcome — which is the same exhaustive-handler discipline from the previous post showing up in a different form. If your state machine cannot tell success from failure, it cannot tell expensive-but-productive from expensive-and-wasted, and you will optimize the wrong column.

The orchestrator that classifies outcomes is also the orchestrator that can compute outcome cost. They are the same machine, doing the same work, for two reasons.

Cost governance is its own component#

Once you accept that the human cannot be the spend control, the question becomes: where does the spend control live?

It does not live in the worker. The worker is fungible by design — and a worker that polices its own budget is not fungible, because some workers will refuse work that other workers would accept. It does not live in the provider, because providers are happy to sell you whatever you will buy. It does not live in the orchestrator, because the orchestrator’s job is to dispatch work, not to mediate the financial contract with each provider.

It lives in a dedicated component that sits beside the fleet rather than inside it — one that watches the subscription windows and decides how many workers are allowed to exist. In a cattle system the throttle isn’t a per-request limit. It’s headcount. Three jobs:

Forecast the window. Subscription plans meter usage in windows — five-hour, weekly. The governor polls where each window stands, learns how fast each worker actually burns it, and projects whether the current fleet will exhaust the window before it resets. The question is never “how much have we spent” but “at this rate, do we hit the wall before the clock does”.

Set the headcount. When the forecast says the window runs out early, the fleet shrinks; when capacity will be left on the table at reset, it grows. Scaling down retires idle workers first, so a busy one is touched only when there aren’t enough idle ones to cover the cut — and a hard brake drops the fleet to zero if any window crosses 98%, because hitting the provider’s ceiling is the bad failure mode. You hit your own ceiling first.

Price the work. Every token the fleet burns is converted to what it would have cost at API list price, per model, including cache reads and writes. A subscription hides marginal cost; the governor puts it back, which is what makes cost per outcome computable at all.

claude-governor is what this looks like in my setup. It is unromantic plumbing — a Rust daemon on a five-minute loop: an observe side that polls Claude Code’s usage endpoint and collects token counts, and an act side that launches or retires NEEDLE workers per subscription pool, within each pool’s floor and ceiling. There is nothing clever about it. The cleverness is that the workers do not know it exists. No worker checks a budget, and no worker can refuse work on cost grounds — they stay fungible. The policy lives entirely in how many of them are running.

Run a portfolio, not a provider#

There are two pricing models in this market and they do completely different things to your unit economics.

Subscriptions (Anthropic Max, Z.AI Max) cap your downside. You pay a fixed amount per month, you get a quota window, and if you exceed it you get cut off — not charged more. The cost per outcome is bounded above. The downside is bounded; the upside is bounded too. Subscriptions are how you fund sustained throughput, the steady drumbeat of cattle work that runs every hour of every day.

Metered API caps nothing. You pay for what you use. There is no ceiling. A bug in your retry loop can turn into a five-figure invoice overnight if nothing is bounding how much work is running. The upside is real — metered access is how you handle bursts, spikes, one-off batches that exceed the subscription window without burning the next week’s quota. The downside is unbounded. You only run metered traffic with a hard cap on how many workers can draw on it, no exceptions.

A healthy fleet runs both. The subscription is the floor — committed throughput at a known cost. The metered API is the surge capacity. The orchestrator does not care which is which. Each subscription and the metered pool is its own worker pool with its own floor and ceiling. The governor adds workers to the cheapest pool first, and when it has to shrink, it sheds the pools that delivered the fewest verified closures per dollar — headcount shifting as each window’s forecast moves.

The mistake I have watched people make repeatedly is going all-in on metered API “for flexibility.” You get the flexibility. You also get a cost structure that scales linearly with how aggressive your retry policy is, which is exactly the wrong elasticity to give an autonomous fleet.

Quota observability is asymmetric#

The governor needs to know how much you have spent against each window. This sounds trivial. It is not, because the providers expose this information unevenly.

Anthropic exposes the usage of each window — five-hour and weekly — through an endpoint the governor polls. It knows where it is in every window and sizes the fleet accordingly. You can build proper closed-loop control because the loop has a sensor.

Z.AI exposes nothing programmatic. There is no quota endpoint. There are no rate-limit headers. The only place you can see your usage is the web dashboard, which is fine for a human checking in once a day and useless for a process that needs to make a decision every second. The governor is flying blind on Z.AI quota — until the wall, when the API starts returning rate-limit errors and you reverse-engineer what just happened.

The fix is to model your own quota independently. Measure outflow yourself, count it against your own ledger, and treat that as the source of truth — not what the provider reports, because the provider may not report at all. “You are out of quota” should be a fact your governor knows before the provider tells you, because the only signal the provider gives some of these subscriptions is the failure itself.

This is more work than it should be. It is the cost of operating against providers whose business model has not yet caught up with the operational needs of customers running unattended fleets. It will get better. Until then, the governor’s quota model is a thing you maintain by hand.

The cheap-restart reflex#

The pet operator has one cost-control reflex that the cattle operator should preserve and amplify: when a worker is stuck, kill it.

In the pet model this is intuitive. You see the agent thrashing, you stop it, you start over. The cost of the restart is small. The cost of letting it grind for another five minutes is large.

In the cattle model the same reflex is correct, but the operator cannot apply it manually because the operator is not watching. The reflex has to be built into the orchestrator. Three bounds, enforced at the worker level:

Time-bounded executions. A worker that has been running on the same task for longer than the budget gets killed. The handler is the timeout handler from the previous post — release the task, mark deferred, loop. No appeal. No “but it might be making progress.” Long-tail tasks are almost always stuck tasks.

Token-bounded executions. A worker that has emitted more than N tokens of output on a single task gets killed. Most real outcomes fit comfortably in a budget. The ones that exceed it are usually agents in some kind of loop — emitting the same diff over and over, retrying the same failing tool call, repeating themselves with minor variations.

Iteration-bounded executions. A worker that has invoked the model more than N times on a single task gets killed. This catches the case the previous two miss: a worker that produces small, fast, expensive calls in tight succession. None of them individually trips the time or token bounds. The count does.

These three bounds together convert “the worker decides when to stop” into “the orchestrator decides when to stop.” Which is the only correct allocation of that decision in a cattle system, because the worker has no skin in the game and the orchestrator has all of it.

A worker killed early might have been about to succeed. That is fine. The task goes back on the queue, gets picked up by another worker, possibly with a different prompt or a different model, and tries again. The cost of a wasted execution is a single bounded run. The cost of an unwasted runaway is unbounded.

Cheap restart, every time.

What I’d change#

Three things, in order of how often I think about them.

Outcome cost should be a first-class metric, not a derived one. Today I compute cost per closed bead by joining provider invoices to the orchestrator’s outcome log after the fact. It works but it is asynchronous — I find out about expensive failures after they have already happened. The governor already prices every token as it is collected. The orchestrator already knows what task each call belonged to. The metric should be emitted live: this bead just closed, here is what it cost, here is whether that is in line with the historical distribution. If it is an outlier, alert immediately. Part of this has landed since I first wrote it: the governor now reads a ledger of verified closures per adapter, and when it has to shrink the fleet, the pools that bought the fewest closures per dollar go first. The live per-bead alert is still missing.

Per-task budgets should be configurable, not fleet-wide constants. Right now the time / token / iteration bounds are global. Some tasks legitimately want bigger budgets — a complex refactor across many files genuinely needs more space than a one-line fix. The bead should declare its budget. The orchestrator should enforce it. Today everything gets the same budget and I either set it too low for hard tasks or too high for easy ones.

The governor should expose its policy decisions as a stream. When the governor shrinks the fleet from eight workers to three, the visible effect is just fewer workers. Its state file records the current target, but not the history of why — which window, what forecast, what headroom it believed it had at the time. When you go to debug “why did the fleet’s throughput drop in this hour,” the governor’s reasoning is opaque. It should not be. Every policy decision the governor makes — scaled down, scaled up, braked, shifted to another pool — should be a structured event that the observability stack can query.

The question I now ask#

Before I run any new workload on the cattle pipeline, I ask:

What is each dollar of spend supposed to produce, and how would I know if it didn’t?

Both halves matter. The first half forces you to attach a denominator to the spend — you are not buying tokens, you are buying outcomes. The second half forces you to instrument the answer — if you cannot tell whether the spend produced the outcome, you cannot govern it. You are just hoping.

The pet model lets you skip both halves because your attention substitutes for both. You see the outcome (or its absence) directly. You see the spend (or its absence) directly. The cattle model takes both signals away from you and forces you to rebuild them in the orchestrator and the governor — explicitly, before the workers go live.

If you have not built that, you do not have a cattle system. You have a pet system with the supervision removed, which is a different thing. It looks the same right up until the bill arrives.

— Jed

If you want to see the governor side: claude-governor is the Rust daemon described here. The fleet side — workers, state machine, outcome handling — is NEEDLE. Together they bound the system from both ends: NEEDLE decides what work to do; claude-governor decides how many workers may do it.

Updated October 3, 2026: corrected how the governor works. An earlier version described it as a request proxy holding the API key; it governs worker headcount against subscription windows instead, and never sits in the request path.