How many agents can one trunk take?

Every team that runs a fleet of coding agents asks the same question. How many agents can share one trunk? The answer depends on one number more than any other: how long your checks before landing take. This post shows the arithmetic, so you can do it for your own fleet. All numbers here come from bay's design, not from measurements.

The limit is landings, not machines

Each trunk takes one landing at a time. Each landing waits for its own check, on the exact candidate that will land. When trunk moves under a check, bay rebuilds that change and checks it again. After two such moves, the change joins a queue, and bay checks only the head. So one trunk lands at most 1,440 divided by your check minutes each day. With 12-minute checks, that is 120 landings a day.

Leave headroom

Do not plan for a queue that is always busy. The wait in a single queue grows fast above about 70% load. Bursts, retries and outages need room. We also add about 15 seconds per landing for fetch, merge, signing and push. That overhead is an estimate.

The rule of thumb

Agents per trunk ≈ 1,440 × 0.7 ÷ ((check minutes + 0.25) × landings per agent per day). Agents that work on long tasks and land rarely raise the ceiling. Agents that land small commits all day lower it.

Estimates from bay's design at 70% load, with 15 seconds of overhead per landing.

Machines matter much later

Machines add load on the Git remote, not on the queue. Each running landing renews its lease every 10 seconds. Each machine also pushes a short summary of its live sessions. Every push reads the full list of refs, and that list grows with every landing. bay's design compacts landed markers into shard indexes to keep pushes fast. Fetches stay cheap, because each machine keeps one shared object cache.

We estimate tens of machines with no tuning, and low hundreds before the remote needs care. We have not measured the machine limit yet. Agents per machine depend on the CPU and memory your agents use, not on bay.

How to raise the limit, cheapest first

The first steps cost the least and raise the ceiling the most.

1. Shorten the checks that must pass before landing. Run the full suite after landing, and fix forward.
2. Split the work across trunks, one per repository or product area. Each trunk gets its own queue.
3. Check several queued changes at once against the trunk you expect. This wastes checks when one fails.
4. Batch changes into one candidate. A failed batch blames many changes, so we keep this for last.

How to set bay up

Start with numbers you can read today.

1. Measure how long your required checks take, and how often each agent lands.
2. Keep the checks before landing short and deterministic. Move slow suites to after landing.
3. Give each area of code that rarely touches the others its own trunk.
4. Run at least two executors, so a dead executor gets replaced.
5. Watch push time as your ref count grows with landings.
6. Track three numbers: queue wait, push time, and landings per agent per day.

What we will measure

Everything above rests on bay's design. We will replace these estimates with measured queue waits, push times and landing rates. We will release the method with the results, so you can run it on your own fleet.