Two weeks ago, I opened Moneyball for AI Agents by noting that Leaf, my local Level 5 dark software factory, had burned through 15.8 billion tokens inside its build runs over its first 50 days.

In the 14 days since that post went live, Leaf burned 15.50 billion raw tokens across all five factory loops (2.87 billion input-equivalent tokens and 101.7 million output tokens over 162,946 model turns). Two weeks of autonomous work nearly matched the factory’s entire first seven weeks of build volume.

Pulling the full 64-day ledger (September 9 to November 12, 2026) from the live DB shows how fast an unattended harness compounds when you stop babysitting terminals:

  • Total token volume across all seats: 39.90 billion raw tokens (37.13 billion cache reads, 274.35 million output tokens, and 7.89 billion input-equivalent tokens) across 460,740 model turns and 1,412.4 hours (58.9 continuous days) of active model execution.
  • Where the tokens went: 22.66 billion inside 4,044 completed build runs (4,026 confirmed merges, or 99.6%), 9.47 billion across 4,112 PM and Architect planning rooms, 5.47 billion across 14,321 autonomous Improvement file examinations, and 0.39 billion across 722 Technical Writer and Lead Writer runs.
  • Telemetry and fleet archive: 2,539,265 event frames stored in a 1.7 GB SQLite WAL database, 49,746 indexed pod trajectory bundles (78 GB on disk including retained conversation spools), 15,565 deterministic CI job pods, and 9,340 CD build and deploy attempts across 1,856 CD runs.
  • Closed work across 13 repositories: 7,370 closed issues (with only 10 open across the entire fleet tonight), led by 5,042 verified AST cognitive complexity reductions (up 2.8x from 1,814 two weeks ago) and 980 human Development features, stories, and bugs.

To keep that ledger grounded in reality, almost all of those 39.9 billion tokens are prompt cache reads running against flat monthly subscriptions and palm-sized mini-PCs in my office closet. I did add a fifth worker box (factory-node-5, 12 slots, 32 GB RAM, 500 GB NVMe) this week to bring the fleet to 60 concurrent pod slots, tagging both newer Zen 4 nodes with a fast host label so 84.4% of container image builds (448 of 531) and 61.2% of CI suites (1,173 of 1,916) land on modern silicon while the 2019 Intel NUCs handle network-bound agent turns. Still, nobody is confusing my closet shelf with us-east-1.

Even on a closet shelf, two and a half million SQLite frames won’t let you lie to yourself for long.

The nuance: catching my own lying denominator

When I queried weekly rework rates tonight, the top-line number made me blink. Overall engineer rework across the factory had jumped from 8.4% (2026-W43) and 9.6% (2026-W44) all the way to 24.1% this week (2026-W45). Back in October, I had bragged on a chart that Class 4 Development rework was sitting at a polite 5.9%.

My first instinct was to blame a model regression. Instead, I checked the timestamps on the send_back table in factory.db:

SELECT MIN(at) AS first_send_back,
       MAX(at) AS last_send_back,
       COUNT(*) AS total_rejections,
       COUNT(DISTINCT room || ':' || pod) AS distinct_pods
  FROM send_back;
first_send_back           last_send_back            total_rejections  distinct_pods
------------------------  ------------------------  ----------------  -------------
2026-10-25T04:29:06.506Z  2026-11-12T22:41:21.090Z  550               532

That single row exposed two things at once.

First, my October 29 post measured a 14-day window (October 15 to October 29), and send_back didn’t exist for the first ten days of that window. Ten days of unrecorded zeros sat in the denominator and made early Development rework look artificially tiny. Inside Leaf’s own retro skill, we keep a list titled “Columns that have lied” so post-mortem agents don’t build arguments on schema migration artifacts. Tonight I tripped over my own rule.

Second, the jump from 8.4% overall rework in late October to 24.1% this week was a workload mix shift, not a model collapse. After Leaf closed its five-thousandth complexity reduction, I switched autonomous Improve sweeps to off across my repositories so the fleet could focus on feature work. In W43, human Development nodes made up just 15.5% of engineer pods (501 of 3,229). This week, Development made up 56.8% (196 of 345).

Why 28.3% feature rework is the whole ballgame

Once you filter strictly to runs started after send_back went live on October 25 (4,985 planned engineer nodes across all five loops, excluding CI repair pods and retired September validators), the real picture snaps into focus:

Leaf Dark Software Factory 64-day ledger (39.9B raw tokens, 4,044 completed build runs at 99.6% merge, 460.7K turns, 5,042 closed reductions) and horizontal bar chart comparing Tech Lead first-pass rejection rate against final unattended completion across 4,985 nodes since Oct 25: Improvement 5.5% rework and 99.5% done, Quality 16.3% rework and 100% done, Trajectory 18.9% rework and 100% done, and Development 28.3% rework and 99.5% done.

Look at how cleanly Tech Lead rejection rates track the amount of open judgement left to the builder pod:

  • Improvement (3,764 nodes, 5.5% rework, 99.5% completed): Before an Improvement reduction ever reaches a builder pod, an examiner agent has already proven in a throwaway worktree that the test suite passes and Tree-sitter cognitive complexity strictly drops. Because the edit is mechanically pre-verified before planning starts, builders nail 19 out of 20 nodes on the first try.
  • Quality (49 nodes, 16.3% rework, 100.0% completed) and Trajectory (185 nodes, 18.9% rework, 100.0% completed): These bugs are filed by machines with exact file paths, symbol names, and reproduction steps, leaving moderate room for implementation drift.
  • Development (981 nodes, 28.3% rework, 99.5% completed): Human features and bug reports ask engineers to wire new behavior across real modules. More than one in four engineer diffs (278 of 981) gets rejected by the Tech Lead on the first pass, yet 99.5% of those nodes still finish green and merge unattended.

A 28.3% rejection rate sounds terrible if you judge an agent factory like a typing contest.
It looks completely different when you remember nobody human is reading the diffs.

Think about what happens in a standard “autonomous PR” product that spawns one coding agent, runs npm test, and opens a pull request for a human teammate to review. Every engineer pod in Leaf already had to pass its scoped test check before it was even allowed to report done to the Tech Lead (the single rule that pushed early pass rates above 97%). All 278 of those rejected Development diffs already had green unit tests.

The Tech Lead sent them back anyway because unit tests only prove what the test author thought to assert, whereas adversarial review checks the diff against the contract: files touched outside the node’s ownership boundary, missing edge cases named in done_when, dead helpers left behind, or shortcuts that satisfied a mock without wiring the real route.

Green tests prove the code runs.
Adversarial review proves the contract held.

If that Tech Lead seat were a rubber stamp, 28.3% of our feature nodes would have shipped silent contract drift straight into main (or dumped 278 sloppy diffs onto my desk, turning me right back into a full-time code reviewer). Instead, the Tech Lead rejected the branch with line-level defects, the engineer fixed the gap in the next turn, the deterministic repository CI suite verified the integrated branch (548 of 565 CI runs green over the last seven days, 97.0%), and 4,026 of 4,044 build runs landed cleanly.

Next in this series

Pulling this 40-billion-token snapshot uncovered two other stories big enough to deserve their own space today:

  1. Why the Best AI Architect Isn’t the Best Coding Builder: How randomizing Class 5 quota across 1,199 planning rooms accidentally ran a head-to-head trial between Claude Opus 5.5 and Codex GPT-6.1-Sol, and why letting an Architect override historical precedent doubled rework.
  2. Checking My Dark Factory’s Receipts After 4,000 Runs: Eight days of full-fleet data after pruning 65% of our prompts and teaching Leaf to dream, including a textbook Simpson’s paradox that had me chasing a phantom regression.

So what?

If you’re tracking throughput and quality in your own multi-agent workflows, keep three lessons from this ledger in mind:

  • Audit the start dates on your telemetry joins. When you add a new table like send_back mid-month, any rolling window that crosses the migration date pads your denominator with zeros. Keep a written list of columns and date boundaries that have lied in your schema.
  • Separate mechanical cleanup from feature work in every rollup. Blending 3,764 pre-proven AST reductions (5.5% rework) with 981 human feature nodes (28.3% rework) hides what your agents actually do when a human asks for new behavior.
  • Treat reviewer send-backs as proof of friction, not a vanity metric to push to zero. A 0% rejection rate in an unattended loop doesn’t mean your builders are flawless; it usually means your reviewer is asleep. What matters is the pair of numbers together: how often the counterweight pushes back (28.3%), and how often the room still ships working software without waking up a human (99.5%).