Case study: token efficiency gains of a hub and spoke agent team

One settings change made the average reply from my agent teams about 40% cheaper. The teams spent the saving on more replies, not a smaller bill. That’s the main finding from a small case study: two teams of agents building two games, measured from their real session logs, as of mid-October 2026, with every session on Claude Opus 5.5.

In Agentic hub and spoke I described a producer agent directing a team of specialist agents, and listed three things one day hadn’t tested. Ten days and two teams later, the producer of Teach Your Dino Bible Stories ran the same counting scripts over the session transcripts again. The two spans did different work, so this isn’t a controlled test. It is the same method, applied twice.

What a reply costs

Every reply re-reads the whole conversation so far. In the first span, to write 6.7 million tokens the sessions re-read 3.1 billion: 468 tokens read for every one written. A git status cost as much as writing a feature, because both began by re-reading half a million tokens of history.

The one setting: compact each session at 500,000 tokens instead of letting it grow to a million. Compaction cuts the conversation down to a summary, so every later reply has less to re-read. In Claude Code it’s one line in the project’s .claude/settings.local.json:

{ "autoCompactWindow": 500000 }

With it went a hook that runs after each compaction and tells the session to read its own handover file first, so nothing it needs is lost with the old conversation.

That 40% is an average, not every reply. A reply costs roughly in proportion to the conversation it re-reads, so the first replies in a session were always cheap and the last ones dear. The setting cut off the dear end. It applies to every kind of reply alike, so none of the 40% came from git: the changes to git further down are about how many replies went on it, not what each one cost.

	First span	Second span, Dino Island	Second span, the new game
Replies	6,405	4,035	16,317
Re-read for each token written	468	358	273
Weighted tokens per reply	66,000	42,000	39,000

The saving was spent

average cost of a reply

40% less

replies a day

2,600 → 3,600

busiest session, replies an hour

32 → 90

The new team, on an upcoming game that supports a parent/child shared creative space that turns screen time into family time, made 3,600 replies a day against the first span’s 2,600, and its busiest session ran at 90 replies an hour. Its biggest day cost about as much as Dino Island’s biggest. By the Sunday night the weekly allowance read 95%.

Cheaper replies bought more replies.

That’s not a complaint. The team made 1,212 commits in four and a half days. But if you’re budgeting, budget for replies.

What compacting early cost

A long context is a feature, so halving it should cost something. The producer measured what it could, comparing the first 20 replies after each of 115 compactions with the rest of the work.

replies to get back to work after a compaction

10

the same, starting a new task after a landing

6 to 9

the recovery cost, share of the new game's tokens

under 1%

• Recovery is cheap. A session took about 10 replies to make its first edit or landing after a compaction, against 6 to 9 when starting a new task anyway. It re-read about 9 files it had already read, against about 5. In the new game’s team that came to about 40,000 extra tokens per compaction: under 1% of its spend, set against a reply costing 40% less.
• No sign of more confusion. Agents sent no more questions to other sessions just after a compaction. Phrases that read as lost context (“can’t recall”, “according to the summary”, “already landed”) came up about twice in 1,000 replies, and no more often after one.
• No more broken landings. Not one landing in the 20 replies after a compaction was refused for failed tests or a failed type-check: 0 of 79, against 25 of about 1,000 elsewhere.
• No more steering. The producer sent lanes fewer messages per hour than before the setting, not more. A slightly larger share of them read like corrections, 19 to 22% against 16%, but that’s a keyword count that also catches “hold off until Jeff says”.

Two things the counts can’t settle. Whether bugs rose: commits that read like fixes were slightly more common just after a compaction in the new game’s team (23% against 18%), but its busiest lanes compacted every two hours, so “just after” covers half its commits and its busiest stretches. And whatever a long context carries that nobody missed: a tone, a ruling said only in conversation, the reason behind a choice that never reached a file. Counting can’t see those.

The handover files are what made compacting cheap.

That’s the producer’s reading, and mine: every session keeps its decisions and reasons in a file, and reads it first after a compaction. On everything we could measure, compacting early was a gain.

What the landing command fixed, and what it didn’t

The obvious guess was that landing by hand took four or five replies: check the status, read it, fetch, read that, rebase, push. Mostly it didn’t. Agents were already chaining the steps into one shell call (git fetch && git rebase && git push) 842 times, against 294 single commands. Two landings in three went through in one reply, and only one in twenty took four replies or more.

One command now does a whole landing: rebase, type-check, test, wait its turn, push. It barely changed the number of replies, and that was never where the cost was. What it removed was failure.

replies per landing

1.6 → 1.3

pushes rejected because main had moved

50 → 0

tokens per landing

103k → 53k

Before, two agents racing to push meant one push bounced and had to go round again. Now a landing that can’t go through is refused with a reason, and main is left alone. In the new game’s team that happened about 100 times:

Why a landing was refused	Times
Uncommitted files in the main checkout	29
A conflict while rebasing	22
Unit tests failed	19
My game was running on the laptop	6
The type-check failed	5

Each one stopped before it touched main, rather than after.

The cost per landing halved, but mostly because every reply got cheaper after the compaction change, not because of the command. Agents didn’t start landing more often for the same work, either: commits per landing held between 1.2 and 1.5.

So the land command fixed the edge case: the landings that would have bounced or broken something, and the replies spent working out why. The common case was already one reply, and stayed one reply. It was the compaction setting that changed the common case.

Where the extra calls went

The habit that grew was looking. Calls that only check the state of things (git status, git log, the team’s where and sync) went from about 48 in every 1,000 replies to between 141 and 173. The ones followed by nothing at all for five replies, no edit, no commit, no test and no message, went from about 4 in every 1,000 replies to between 26 and 29.

status checks per 1,000 replies

48 → 141

checks followed by nothing

4 → 26

That’s a proxy: it can’t see a check that changed what an agent thought. But it’s the “in case” habit, and a tool that’s cheap per call gets called more.

Counting git and the team’s git tools together, the new game’s team spent 14% of its tokens on them, against 17% on the first weekend. The Dino Island team spent more than before, 23%, much of it on sync when every lane caught up after days idle. So the tools saved tokens for one team and not the other, and the dependable win was the landing itself.

Shorter messages between agents

The teams’ rule is that agents talk to each other in short reports with a fixed shape: what’s on main, how it was checked, what wasn’t, what’s waiting on whom. The new game’s producer keeps its messages under a hundred words. Messages between sessions fell from 20 in every 100 replies to 9, and from 10% of the token spend to 5%.

Replies with no tool call at all, where an agent only thinks and writes, fell from 18% to 6%. The producer’s guess, which it marks as a guess, is that most of that was long status reports that stopped being written.

Writing code rose from 6% of the spend to 10%. Polling stayed small throughout.

Where the token spend went

First weekendTen days later

The numbers

Where the token spend went

Measure	First weekend	Ten days later
Git, with the team's git tools	17%	14%
Replies with no tool call	18%	6%
Messages between sessions	10%	5%
Writing code and data	6%	10%
Waiting on things already running	3%	4%

The three open questions

Did the queues keep agents moving with nobody watching?

Yes. In stretches of three hours or more when I typed nothing to it, the new game’s team still made 37% of its replies, some of them overnight. No session was ever stopped by a usage limit. The nearest was that 95% night, which was a person deciding, not a queue carrying on. Whether the unwatched work was what I’d have asked for, tokens can’t say.

How well did a session do from its handover file?

No session was replaced outright. Each carried on through compaction, which is the same test in practice: afterwards it knows only a summary and its files. Before the hook, a session opened its own handover file within five replies of a compaction 5 times out of 8. After it, 88 times out of 115.

read its handover file after a compaction, before the hook

63%

after the hook

77%

Was nine agents too many for one person?

I typed about 30 messages a day to the new game’s team, nine in ten of them to the producer, and each message led to about 114 replies, against 43 in the first span. The allowance ran out before my attention did. In the producer’s own view, which it marks as opinion, the limit is how much each session does unasked: Dino Island’s queue ended with 107 unticked lines. Most weren’t left undone: the deadline passed, or later work made them unnecessary, and nobody went back to tick or delete them.

A correction

The first measurement said git was a quarter of usage. Its counting script treated any command with “git” in it as git, and many commands began cd /c/git/.... Counted properly, git was 17% with a reply’s cost split across its tools, and 29% with any command that ran git counted whole. Either way it cost several times what writing code did.

What I’d copy

• Compact earlier. It’s the largest saving available, and nobody has to change how they work.
• Give landing one command. It ended the race between agents pushing at once.
• Watch the cheap commands. Count how often status, sync and their cousins run in a reply of their own.
• Budget for replies, not tokens. The cost of a reply is mostly the context it re-reads, whatever it does.