Twenty engineers, one relay balance, zero key sprawl

01 · Twenty engineers, forty keys, and the Friday rotation

A twenty-person engineering team adopting Claude Code meets the credential problem before it meets the cost problem. Every developer wants a personal key. The merge queue wants one for its review agent. The nightly migration script wants one, and so does the benchmarking rig that runs unattended on weekends. By the end of the first quarter the team is holding dozens of keys spread across laptops, runners and shared dashboards, and nobody can say which key belongs to which workload.

The damage surfaces in ordinary incidents. One engineer rotates a key on a Friday afternoon and three long-running agents drop mid-task. A colleague leaves and no one can say with confidence which credential was theirs, so every key gets rotated anyway and Monday disappears into breakage. Usage arrives per key rather than per team, so the simplest budget question, what did our coding agents actually consume last month, has no clean answer.

That is the head-to-head moment for an engineering organisation of this size. The comparison is not really about security policy documents. It is about what happens to revocation, budgeting, routing and everyday friction when twenty people run heavy, sustained workloads through one tool.

02 · Per-developer credentials against one shared metered balance

Per-developer upstream keys. Each engineer provisions their own credential and manages their own environment. This feels tidy on day one, because ownership is obvious. It also multiplies the surfaces that need auditing, gives every laptop its own blast radius when a key leaks, and fragments spend across accounts that report in different shapes. Rate limits and balances are per key, so one person's benchmark run can starve someone else's agent even though the team believes it is sharing capacity.

One balance behind a single relay. A team points its tooling at one API base address and draws from one pooled balance. Quanta works this way: one balance covers Claude, GPT, Gemini, DeepSeek, Kimi, GLM, Qwen, Grok and other models, and the same credential serves Claude Code, Codex, Gemini CLI and any OpenAI SDK. The engineering win is that key count stops scaling with headcount. Adding a new hire is an environment variable, not a provisioning ticket.

Four dimensions decide the contest for most teams:

• › Revocation. With one shared balance, a departing engineer loses access through the laptop and the team profile you already manage, not through a key hunt. With scattered keys, revocation becomes a forensics exercise.
• › Budget attribution. A single metered stream lets you attribute spend by project, session or machine, because the tokens are measured at the call. Per-key billing forces you to reconstruct attribution after the fact.
• › Routing. A relay lets the same balance carry several models, so a team can move a workload to a faster or stronger model without renegotiating contracts or reissuing keys.
• › Friction. Shared credentials reduce the number of secrets in rotation to a small, reviewable set, which is the only reliable way to keep twenty engineers from inventing private workarounds.

03 · Cache writes and cache reads on the meter

Claude Code is unusually sensitive to how tokens are metered, because its sessions are long and its context is repetitive. The same project instructions, tool descriptions and file excerpts sit at the front of nearly every request. A billing model that treats every token as fresh punishes exactly the behaviour that makes agents useful: keeping context warm so the model does not re-read the repository on every step.

Relay metering on real tokens, with cache writes and cache reads priced separately, changes how a team should think about session design. A cache write is the cost of establishing shared context. A cache read is the cheap continuation of it. The practical guidance that falls out of this is straightforward.

• › Keep sessions alive across related tasks instead of restarting the agent for each ticket, so the expensive write happens once and the following calls draw mostly cache reads.
• › Keep the stable parts of a prompt, project conventions and tool definitions, in a fixed order. Unstable prefixes force fresh writes.
• › Watch the write to read ratio week to week. A rising write share usually means something in the prompt is churning, not that the workload grew.

This is where a pay-as-you-go relay earns its place in a heavy-workload team. You are billed on what the agent actually consumed, split by cache behaviour, instead of paying a flat seat price for engineers who use the tool once a day and one automation that never stops.

04 · Routing agent traffic across the model list

One balance covering many models turns model choice into an engineering decision rather than a procurement decision. Most teams settle into a two-tier split. A strong reasoning model handles the main coding loop, refactors and tricky debugging. A smaller, faster model handles the surrounding work: commit messages, test triage, quick summaries and low-risk edits. As concrete examples, a team might run Claude Sonnet 5.5 for the core agent loop and Claude Haiku 4.5 for the fast, repetitive tasks around it.

The second part of the routing story is tooling. Engineers do not all want the same client, and forcing a single editor experience on twenty people is a morale tax. Because one balance serves Claude Code, Codex, Gemini CLI and anything built on an OpenAI SDK, the team can standardise the credential and the budget while letting people keep the client they are productive in. The head-to-head here is not model against model. It is one governed spend stream against twenty private ones.

05 · Rolling out to twenty engineers without a support rota

A rollout that depends on a per-person provisioning checklist will be abandoned by week two. The version that holds up is small and boring. Start with one shared balance and one base address, and point a single pilot group at it. Give the team a short written convention for session length, cache-friendly prompt structure and which tier of work belongs to which model. Then review metered usage weekly for the first month, adjusting the split as real workloads arrive.

Governance follows the same simplification. Access is granted through the tools you already manage, spend is visible as one stream, and the question of who consumed what is answerable from the meter rather than reconstructed from invoices. Teams that bring others into the relay earn 19% of their top-ups, which is a reasonable way for an infrastructure-minded group to offset the budget it already planned.

The cleanest way to settle the argument is to test it against your own workload. Open an account, point one Claude Code profile at the relay, and let a week of metered sessions show you the real write and read pattern before you commit the other nineteen engineers.