A 120k-Token Branch Budget for Claude Code Teams

01 · The 40-day branch where every session re-reads the same diff

A release train that stays open for weeks does something specific to a coding agent: it accumulates decisions. Every new session drags in the original design note, three rounds of review comments, two abandoned approaches, and a wall of failing test output that was relevant in week one. The agent is not confused because it is weak. It is confused because everything in the branch history looks equally authoritative, from the first token of the window to the last.

Teams with heavy, sustained workloads feel this in two places. The first is quality. The agent re-litigates closed questions, regenerates a shim someone deleted ten commits ago, or asserts a migration policy the team retired before the branch turned a month old. The second is cost. Long context is metered work. Every re-read is real tokens, and the churn that follows a stale, overstuffed window shows up as repeat turns, repeat tool calls, and repeat cache writes.

The fix is not a bigger window. A larger window only postpones the argument about what belongs in it. The fix is a deliberate policy for what a long-lived branch keeps in working memory, what it stores as retrieval material, and what it forgets on purpose. Two workable policies dominate, and under sustained volume they behave very differently.

02 · Compact-and-summarize against retrieve-and-pin

Contender A, compact-and-summarize. The harness watches the window and, at a threshold it chooses, compresses the conversation into a rolling brief: decisions made, files touched, conventions enforced, open questions, current test state. The older turns are discarded and the brief becomes the ground truth for the next stretch of work. It is simple to operate, it needs no retrieval infrastructure, and it makes long sessions survivable on any model. Its failure mode is quiet corruption. A summary that drops a negated decision, or flattens two conflicting reviews into one confident sentence, will be trusted for the rest of the branch because nothing later contradicts it.

Contender B, retrieve-and-pin. Nothing is summarized mid-session. Instead the team pins a small curated core at the top of the window: a branch contract, the non-negotiable conventions, the current task statement, and pointers to where the real history lives. Everything else stays outside the window and is pulled in only when the agent demonstrably needs it. Its strength is fidelity, because the full review thread is available when an argument resurfaces. Its failure mode is drift at the edges: a pin list that nobody prunes becomes its own form of bloat, and an agent that retrieves lazily will re-fetch the same large file three times in one session.

• › Choose A when sessions are short, the branch is converging, and the team can afford one deliberate verification pass before merge.
• › Choose B when the branch is long, contested, and full of decisions that keep coming back from the dead.
• › Most teams that run at volume end up hybrid: a pinned core plus a rolling brief that is rewritten rather than appended.

03 · Scored on cache writes, cache reads and repeat turns

Put the two policies on a metered ledger and the difference is no longer philosophical. Compaction rewrites the working set each cycle. That is good for keeping the window small, and expensive at the moment of rewrite, because the new brief sits at the front of the prefix and the next call has to pay for a fresh cache write. Retrieve-and-pin keeps the prefix stable across many turns, so it leans on cache reads instead, which is exactly the behavior you want when a team runs fifty sessions a day against the same branch contract.

Repeat turns are the hidden multiplier. A corrupted summary produces confident wrong work, and confident wrong work produces repair turns. Repair turns are the most expensive tokens in any agent rollout, because they burn context, tool calls, and reviewer attention at the same time. On this round, the policy with more fidelity per token wins, not the policy with the smaller window. If your traffic runs through Quanta, where one balance covers the full roster of models and every call is metered on real tokens with cache writes and cache reads priced separately, you can see which policy you are actually running without guessing.

One practical note on routing the bulk work. Running the cheap, high-volume passes on a fast model keeps the ledger tidy. Claude Haiku 4.5 is a good fit for rolling branch briefs and diff summaries, while DeepSeek V4 Flash handles large log and test-output digests without pulling the premium tier into routine context maintenance.

04 · Five pin rules that hold a branch near a 120k-token ceiling

A budget is only real if it has mechanical enforcement. The rules below are the ones that survive contact with a busy release train.

• › Pin the contract, not the history. The pinned core states what must remain true. It does not retell how the team got there.
• › Prune the pin list on every merge into the branch. A rule that no longer constrains anything is context debt with a friendly face.
• › One brief owner per branch. If two people rewrite the rolling summary, the branch ends up with two truths and an agent that picks one at random.
• › Re-verify before merge. Spend one deliberate pass confirming that the brief and the codebase still agree, because that pass costs far less than a wrong diff escaping review.
• › Cap retrieval targets. Fix the set of directories and documents an agent may pull in, so a desperate turn cannot drag the whole monorepo into the window.

05 · Rolling the 120k budget out across Claude Code and Gemini CLI

Rollout order matters more than tooling. Start with one long-lived branch that is already hurting, not the whole fleet. Write the branch contract first, hand it to the harness as pinned context, and let the agent work for a week. Then compare the repair turn count and the reviewer complaint list against the previous stretch of the same branch. That comparison is your acceptance test for the policy, and it is cheap to repeat.

Second, decide where the summaries and digests run. Teams that keep routine context maintenance on an efficient tier and reserve the heavy tier for architectural work keep their budgets predictable across sustained volume. Both Claude Code and Gemini CLI will respect a stable prefix and a clear pin list once the policy is in place, and a relay such as Quanta makes it straightforward to watch token consumption, cache writes and cache reads per branch instead of per month. Open a Quanta account once and you can meter this rollout against real tokens from the first session.

Third, write the policy into the team ritual rather than the agent prompt. The brief owner rotates on the same cadence as the release train. The pin list is reviewed at the weekly branch sync. A budget like 120k tokens is not a technical limit at all; it is an agreement about which decisions deserve to stay in working memory and which ones the branch has already settled.