Fifty People, One Balance: Rolling Out the AI Usage Policy

01 · What fifty people must agree on before the first session

Most AI usage policies fail in the opening paragraph, where they declare that AI must be used responsibly and then stop. For a fifty-person company running heavy, sustained workloads, the useful version is shorter, more concrete, and organised around four decisions: who may spend, what they may spend it on, what may leave the building, and who reviews the trail. Put those four decisions on one page, attach an appendix for tooling, and you have a document team leads can enforce without a compliance team on call.

The headcount matters. Fifty people is large enough that informal habits break within a quarter, and small enough that one shared balance can still work. Divide the company into cost centres — engineering, operations, research, marketing — and give each an owner who approves new seats and reads the monthly meter. The policy must name those owners. A rule without a name attached to it becomes a suggestion in about two weeks.

Version the document too. Put a date on it, state that the tooling appendix may change more often than the principles, and require team leads to acknowledge each new version. That single habit keeps the policy alive as models, clients and workloads change underneath it.

02 · Real tokens, cache writes and cache reads: the meter the policy encodes

Any policy that talks about cost without talking about metering will be gamed or ignored. When your team runs sustained workloads through a pay-as-you-go API relay such as Quanta, every call is metered on real tokens, with cache writes and cache reads priced separately. That distinction belongs in the policy, because it changes how engineers structure their work.

The plain-language version for the appendix: a long prompt sent once is expensive to write and cheap to think about; the same prompt sent two hundred times is cheap to write and expensive to re-read. Cache reads are where repeated work becomes affordable, and cache writes are what make those reads possible. Once the team understands that trade, they will keep stable instructions and reference material in context deliberately instead of retyping everything on every call.

• › Tier models by task. Routine triage, formatting and classification belong on lighter models; architecture reviews, hard debugging and high-stakes generation justify the largest model on your allowed list. Use one or two concrete pairings in the appendix — a fast model for bulk sweeps, a strong model for judgement calls — rather than a catalogue.
• › Batch the cheap path. Exploratory retries, sweeps and evaluation runs should be pointed at economical models so that a failed hypothesis costs little.
• › Cache on purpose. Repeated system instructions, schemas and stable documents are written to cache once and read back many times; treat that as a normal engineering pattern, not an accident.
• › Stop at the budget line. A run that exceeds its cost-centre budget stops, logs the exception, and asks the owner before continuing. No silent overruns.

One balance covering every model you allow simplifies the accounting considerably: one meter, one owner, one review. And if your team refers other teams or partners onto the platform, the referral share — 19% of their top-ups — should flow back into the cost centre that referred them, recorded in the same monthly sheet.

03 · Approved surfaces: Claude Code, Codex, Gemini CLI and the OpenAI SDK

Name the approved clients explicitly. Your engineers are already using command-line coding agents and SDK-based scripts, and a policy that pretends otherwise will simply be routed around. A relay that works with Claude Code, Codex, Gemini CLI and any OpenAI-compatible client means the policy does not need a separate chapter per vendor; it needs one credential model and one allowed-tool list.

• › Approved clients. List them by name. Anything not on the list requires an exception request before it touches production work.
• › Credentials. Keys are issued per person or per service account, stored in a secrets manager, and rotated when someone changes team or leaves. Keys are never pasted into chat, tickets or shared documents.
• › Local agents. Tools that can edit files or execute commands require a human approval step before destructive actions, and their output is reviewed like any other change.
• › Managed endpoints. Every client is pointed at the same relay endpoint through one managed configuration, so nobody is quietly running a personal key against a personal card.
• › Personal accounts. Company work does not run on personal subscriptions. If someone wants to experiment privately, that is their call and their data — and it stays out of company repositories.

Keep the allowed model list short. Two or three models per tier is enough, and a two-page catalogue invites wandering between vendors with no measurable benefit. When the list changes, it changes in the appendix, and team leads acknowledge the new version.

04 · Data rules that survive contact with a real deadline

Under pressure, people paste whatever unblocks them. The policy has to be specific enough to guide that moment. Start by classifying what the company handles: public material, internal material, customer data, and regulated or contractually restricted data. State plainly which classes may be sent to an external model, which require redaction first, and which are never sent at all.

• › Strip secrets first. Credentials, tokens, private keys and connection strings are removed before any prompt is assembled, including in logs and error traces.
• › Minimise the payload. Send the smallest slice of context that answers the question. A whole customer export is rarely necessary; a sample usually is.
• › Respect contracts. If a customer agreement restricts processing, the work stays on the approved path or does not happen. Escalate rather than improvise.
• › Label outputs. Generated code, reports and designs are marked as generated where the team's process requires provenance, and they are reviewed by a human before they ship.
• › Keep the trail. Requests that touch customer data are logged with enough metadata to reconstruct what was sent, by whom, and under which policy version.

One more rule earns its place: no one is penalised for stopping a run to ask whether data may be sent. Teams that punish hesitation end up with silent policy violations, which are far more expensive than a delayed ticket.

05 · Exceptions, escalation and the monthly meter review

Every policy needs an off-ramp. Define a lightweight exception request: what is being asked, which cost centre pays, what data is involved, and when the exception expires. Team leads approve ordinary exceptions; anything touching customer data or adding a new tool goes to the policy owner. Put the expiry date in the request itself, because open-ended exceptions quietly become permanent.

The monthly review is where the policy earns authority. Each cost-centre owner reads three things: total metered tokens, the split between cache writes and cache reads, and the number of exceptions opened. Patterns matter more than totals. A sudden rise in cache writes usually means someone is rebuilding context on every call; a rise in exceptions usually means the tooling appendix is out of date. Both are fixable in one afternoon.

Review model choices at the same cadence. If most traffic is triage-grade work running on your most capable models, move the default down and keep the expensive tier for tasks that genuinely need it. The goal is not to spend less in absolute terms — heavy workloads are the point — but to spend predictably.

06 · A four-week rollout with one acknowledgement per person

Week one: publish the one-page policy and the tooling appendix, name the cost-centre owners, and hold one short session per team. Week two: issue credentials through the managed configuration, move existing scripts onto approved clients, and retire personal keys. Week three: run the pilot with one heavy-use team, watch the meter daily, and fix the two or three rules that turned out to be impractical. Week four: freeze version one, collect a written acknowledgement from every person who uses the models, and schedule the first monthly review.

Two habits make the rest stick. First, every incident — a leaked key, an over-budget run, an awkward data question — produces a one-line amendment rather than a lecture. Second, the meter is shared openly inside the company. Teams that can see their own numbers manage themselves.

If your team is about to scale sustained workloads across many models and clients, open a Quanta account, load a single balance, and let the first month of metered usage become the evidence base for version two of your policy.