One Day of an AI Coding Fleet, in Numbers

Most writing about coding agents describes one agent on one task. We run a fleet of them against a single Rust monorepo, all taking tickets from the same board and merging into the same integration branch. This post takes one day, 21 October 2026 (Pacific time), and lays out what the fleet did, using the gateway’s per-call usage ledger and the branch history. It was a quieter day than average: the 30-day average was 94 merged pull requests a day, with a peak of 197.

• 21 sessions made model calls: 18 long-running coding agents and three short ones.
• 11,873 model calls, which produced about 8 million output tokens.
• 51 pull requests merged, plus 14 automated board-sync commits.
• About $87 of estimated model spend across every role on the gateway that day, roughly $1.70 per merged pull request.

When the fleet works

The fleet is not a steady 24-hour machine. Agents pick up work when the operator sets it or the board schedules it, and they stop when a task is done or blocked. The hourly shape follows the operator’s day: calls start around 9am, peak in the evening, and fall off after midnight. Between 4am and 8am that day there were no coding-agent calls at all.

Merges were spread more evenly than calls, with at least one in every hour from 9am to midnight. A merge is the end of a chain of work (edit, remote build, CI run, review, merge), so merges trail the calls that produced them by tens of minutes to hours.

Where the time goes

The ledger records when each call happened, so the gap between one call and the next in a session shows what the agent was doing in between. Short gaps are the agent reading files, editing and running quick commands. Gaps of several minutes are almost always a remote build or a CI run. Gaps over an hour are idle time between tasks.

97% of gaps were under two minutes, and they added up to about 75 session-hours of active work. The 336 gaps between two minutes and an hour were rare but long: about 45 session-hours, most of it waiting on builds and CI. That is the number we work hardest to shrink, because a waiting agent holds its context and its task while doing nothing.

Agents are not equal

The busiest session made 1,589 calls; the quietest long-running one made 83. The top five sessions made 53% of the day’s calls. Call count tracks the shape of the task more than the agent: refactors across many small files produce many short calls, while a task that waits on a long build produces few.

What the day was spent on

Pull request titles give a rough split of the work. A dozen touched long-running agent workflows (scheduling, recovery, forecasting). Six were Android client fixes, five each were terminal UI and image-publishing work, five were changes to the gateway’s prompt-cache guard, and the rest were spread across billing, builders and data reads. Most of these were small: a fix, a guard, a missing check found while doing something else.

What we take from it

• Waiting is the biggest cost after tokens. Cutting build and CI time helps more than a faster model.
• Throughput comes from many small merges. Fifty-one merges a day only works with strict branching rules and CI that proves it tested the exact commit that merged.
• A per-call ledger is enough to see all of this. We did not need tracing or a separate analytics stack, only a timestamp and a session key on every call.