Our agent fleet
82 jobs, 44 without a model

At nine in the morning, the thousandth scheduled task process on this machine started. It wrote a row into the execution table — who woke it, when it began, which job it was — then went to work. Count back fifty-one hours and there are exactly a thousand of those rows, 19.7 wakeups an hour. I did not click anything for any of them.

Eighty-two scheduled jobs run on this machine. Two content batches a day for the company site, a health check every two hours, a social copy run every four hours, a source registry sweep once a day. They wake on a fixed clock, do the work, write back one row, and go back to sleep. The company is one person, so this fleet is not a department project. It is an extension of my hands.

I went through the last two days of records expecting a cost story about model calls. What I found was the opposite: what sets the cost of this fleet is not the jobs that call a model. It is the forty-four that never do.

One day: 475 wakeups, 38 messages

Start with definitions, because this is the layer where numbers get blurred. One row in the execution table is one wakeup, whether that wakeup produced five paragraphs or nothing at all. On 26 October the table holds 475 rows covering 69 distinct jobs, with zero non-zero exits. The delivery log for the same day holds 38 messages that reached a human. The difference is 437 wakeups that said nothing, 92 percent.

Now the fleet itself. 101 jobs configured, 82 enabled. Of those 82, 44 are plain scripts: read a file, query a database, compare two numbers, write one row of state. They check data freshness, compute field fill rates, diff two registries, hash inputs for deduplication. They never call a model. The remaining 38 are the ones that need a model to read material, form a judgment, and write prose.

Put those two facts together and something widely assumed falls apart. Most wakeups in a fleet of this size are deterministic; the answer was fixed when the job was written. The model only appears at the few forks that require judgment. Multiply total wakeups by the price of a model call and you will overestimate the bill by an order of magnitude. Plan the fleet from that price and you will hesitate to add jobs — while the jobs you should be adding cost nothing.

A wakeup costs the same whether it moves one row or a million

To see why the script half sets the cost, take a wakeup apart. The process starts and the first thing it does is rebuild context: load the rule files, load memory, load the job spec, assemble the tool list, fetch the previous state. None of that depends on whether this run will process a hundred rows or a million. It is the entry ticket. Work begins after the ticket is paid.

The model layer is steeper still. Every call rebills the entire conversation history, so multi-step tool loops compound: cost grows with the square of the step count. Augment Code measured the effect in a guide updated in June 2026 and put a number on it — a twenty-step loop can consume more than ten times what a per-step estimate suggests. Anthropic’s engineering team published its own figure from the research system behind Claude: agents use about four times the tokens of chat, and multi-agent systems about fifteen. Both sources stand on their own and point at the same mechanism. Wakeup count, not per-run workload, is the multiplier on the bill.

So we made a trade. Everything decidable goes into a script. Is the data fresh enough, is the field fill rate above threshold, have the two registries drifted, is this the same document as last week — none of these need judgment, only arithmetic and comparison. A script produces a binary result: pass or fail, exit 0 or exit 1. A model does not. Its output has to be read and judged, and the judging costs another wakeup.

The cost of the trade is easier to see stated the other way round. Hand a deterministic job to a model and you do not pay for that one call. You pay for someone, or something, checking it from then on. Verification usually costs more than execution, and it never stops.

Silence in 92 percent of runs is a specification, not a shortcut

One of our operating rules says a job may not speak unless state changed. I wrote it thinking about token cost. A month later I understood it is the condition that keeps the fleet alive. Consider the alternative: 475 messages a day. By day three I would shut the whole thing down, not because any single message was wrong, but because no human can pick the three that matter out of 475.

Silence is therefore not an omission. The job carries the filtering duty. Every job spec has to answer one question before it is built: under what conditions am I allowed to speak. We reduce it to three: the conclusion changed, a number crossed a threshold, or a decision exists that only a human can make. Outside those three, nothing. If that rule cannot be written for a job, the job is not ready to exist.

There is a side effect worth naming. Because jobs are quiet by default, a job that suddenly speaks is itself a signal. Among the 38 messages on 26 October, a few came from a monitor noticing a data source had not updated for two days, a few from a content gate rejecting a draft. Their value is not mainly in what they said. It is that they are rare. At 400 messages a day the same warnings would be invisible, and people learn to ignore what is always there.

The only failure in fifty-one hours was a monitor telling the truth

One non-zero exit in 1001 runs, a failure rate of 0.1 percent. That looked too good, so I read the error text. Exit code 1, followed by a column of passes and one failure: audit freshness passed, observer continuity passed, detection path coverage at 100 percent passed, and one check did not. The process had not crashed. A monitoring script had reported a real condition and exited non-zero to do it.

That distinction matters more than the rate. Count non-zero exits as failures and the team gets a flattering number, then spends its effort improving that number while the real failures sit in the completed rows. They come in at least three shapes. Quietly wrong: schema valid, conclusion false, exit 0. Duplicated work: two jobs process the same input and produce two reports that say the same thing in different words. Stale conclusions: no new evidence, but the clock came round, so a piece gets written anyway.

None of the three turns a dashboard red, so they have to be designed out. Each job gets a fingerprint — hash of its input files, digest of query results, version of upstream artifacts. If the fingerprint is unchanged, the job exits 0 and says nothing. Duplicated work stops being a problem to detect and becomes a thing that cannot happen. Stale conclusions are handled by a second rule: a job without new evidence may only write increments, never a full rewrite.

The first shape is hardest, because catching it requires reading the output rather than the status. We split it: machines check what machines can check — language rules, citation completeness, title length, component rendering — and one deliberate read handles the rest. That is why a good share of those 38 messages ask for a glance rather than report a finished job.

Our position

The architectural unit of a scheduled fleet is not the model and not the orchestration framework. It is the wakeup contract. Four questions: what condition wakes it, what it can see when awake, what counts as done, and how it stays quiet when those conditions are unmet. Write all four and the model underneath becomes swappable — cheap or expensive is then only a price question. Leave one unwritten and no model upgrade fixes it.

This is also why we do not chase multi-agent frameworks. When a job has a clear boundary and a writable test, it needs no orchestration; one execution table and an idempotency key are enough. When the boundary is unclear, orchestration does not clarify it. It copies the confusion four times, and copies the tokens four times. Anthropic’s four and fifteen are what that copying looks like on an invoice.

One choice we do not intend to revisit. Those 44 script jobs are the least impressive part of the fleet. There is no demo in them and they would not survive a launch keynote. They are also the most stable part, and the only part no vendor price change can touch. Compressing an operation down to one person depends on exactly that half.

Five moves before building the same thing

First, classify before you build. Split candidates into jobs whose test can be written in code and jobs whose test needs a human. The first category may not use a model. No exceptions — grant one and every later job will claim it needs judgment.

Second, write wake conditions, not schedules. If a job can wake on “the input changed”, do not wake it every fifteen minutes. Schedules are for jobs that cannot observe their input. Using one for a job that can means buying uncertainty at a fixed price.

Third, one fingerprint per job. Unchanged means exit, and exit silently. This handles duplication and noise in a single rule.

Fourth, write “done” as an executable test rather than a description. “It is written” is not a test. “The file exists, clears the word floor, and passes validation” is.

Fifth, keep four counters per job: wakeups, messages spoken, non-zero exits, human interventions. One table, reviewed weekly. If messages approach wakeups, the job is designed badly. If messages stay at zero for weeks, the job may be dead and still waking on time.

One question for teams laying this path now. Of your scheduled jobs, how many wakeups would reach the same conclusion without a model? That ratio sets your unit cost, and it sets your room to negotiate when next year’s prices change. It is usually far higher than estimated, because jobs get handed to a model not when they need judgment but when writing the script would cost an afternoon.

How the numbers were counted

The four figures come from this machine’s scheduler database, covering 25 October 06:18 to 27 October 09:00, 1001 execution rows. Wakeups are counted as execution rows, one per job per firing. Deliveries come from the delivery database and count messages, so a batch that sends three messages counts as three. Job totals and the script-only flag come from job configuration. Every number is recomputable from the same records; the definitions are here so a reader can run the same query on their own database instead of trusting a percentage.

One caveat. The execution table keeps roughly the last thousand rows, so daily wakeups are complete for a day while deliveries are complete for five days. The two cannot be divided directly. The 92 percent figure uses one day’s numerator and that same day’s denominator: 475 wakeups, 38 deliveries on 26 October. Mixing windows across days yields a falsely low silence rate. My first pass made exactly that mistake.

References

Anthropic engineering, measured token multipliers for the multi-agent research system (vendor self-report, primary): anthropic.com/engineering/built-multi-agent-research-system

Augment Code, quadratic context cost in agent loops, page updated 18 June 2026: augmentcode.com/guides/ai-agent-loop-token-cost-context-constraints

All wakeup counts, delivery counts, fleet composition and the quoted error text are first-party records from this machine, not relayed.