What the Token Ledger Showed Across Six Departments

01 · Active-User Counts Hide the Workload You Actually Pay For

Most adoption dashboards answer one question: who logged in. For a team running heavy, sustained AI workloads, that question is almost useless. A department where forty people each ran one short prompt last week looks identical to a department where four engineers ran thousands of calls against production data. The bills will not look identical, the limits will not trip at the same time, and the capacity planning will not hold up.

Adoption, for a team lead, is better defined as sustained, metered use that produces finished work. Everything else is curiosity. Once you accept that definition, the measurement problem changes shape. You stop counting seats and start reading a ledger: how many tokens moved through each department, what kind of tokens they were, which tools produced them, and whether the spend is attached to an outcome the department would defend in a budget review.

This matters most when several departments share one spending envelope. Power users and teams with heavy workloads tend to concentrate demand: a handful of people in one group generate most of the volume, while other groups trickle. If you roll that up into a single company-wide average, the average describes nobody. The primer that follows is written for team leads who need per-department numbers that survive scrutiny from finance, security and the engineers themselves.

02 · Six Numbers That Survive a Budget Review

Put a small, stable set of metrics on every department page and resist the urge to expand it. Six are usually enough:

• › Weekly active builders: people who made at least one metered call that produced output used in a real task. This is your floor, not your headline.
• › Tokens per builder per week: the volume signal. It separates casual testers from departments whose workflows now depend on model output.
• › Share of volume from the top five users: concentration risk. If five people carry ninety percent of a department's usage, your adoption story is a dependency story.
• › Cache writes against cache reads: the efficiency signal, discussed below. Teams that reuse context well show a very different curve from teams that rebuild every prompt from scratch.
• › Metered cost per completed task: tie spend to output, whether that is a merged change, a resolved ticket or a generated report. Without this denominator, adoption numbers float free of value.
• › Tool mix: which interfaces carried the calls. Work done through a coding agent counts differently from work done through an SDK integration, and rollout decisions depend on the split.

Report these weekly, per department, and keep the definitions frozen. Metrics that change meaning mid-quarter teach people to distrust the whole sheet.

03 · Split Cache Writes From Cache Reads Before Comparing Teams

The single most common mistake in adoption reporting is treating every token as interchangeable. It is not. When calls are metered on real tokens, with cache writes and cache reads priced separately, a department's cost profile is shaped as much by how it structures prompts as by how much it uses the tool.

A team that keeps stable instructions in context and only appends fresh material each turn will generate cache writes early and cache reads on every subsequent call. Its usage curve looks expensive on day one and efficient for the rest of the sprint. A team that rewrites its preamble for every call pays to write context it never reuses. Both teams might show the same token totals in a naive dashboard, and one of them is quietly spending several times more per task.

So measure the split explicitly. Track cache writes and cache reads per department, and treat a rising read-to-write ratio as a health signal rather than waste. When two departments show similar monthly volume, the one with the heavier read share is usually the one with disciplined, repeatable workflows. When a team lead sees the ratio collapse after a rollout, that is a prompt hygiene problem, not an adoption problem, and the fix is training rather than budget.

04 · Segment by Department First, Then by Model Family

Department rollups come first because that is where budgets, approvals and accountability live. Model mix is a second cut, useful for explaining the numbers rather than replacing them.

Keep the model dimension coarse. A department that routes routine drafting to a lighter option such as Claude Haiku 4.5 and escalates hard reasoning to a flagship such as GPT-6 Astra has a sensible tiering strategy, and your reporting should make that strategy visible instead of flattening it into an average cost per token. Watch for departments that default to the most capable option for everything: their adoption will look strong and their cost per completed task will look weak.

A shared balance helps here. When one account covers the full range of models your teams use, and the same metering applies to every call, comparisons across departments stop being apples-to-oranges exercises. The same is true for tooling: teams working in coding agents, command-line assistants or SDK integrations all report into the same ledger, so a rollout measured in one group can be reasoned about in another.

05 · Budgets and Limits Should Track Sustained Volume, Not Spikes

Heavy workloads fail budget reviews in predictable ways: a spike week is read as the new normal, a flat month is read as underinvestment, and limits get set at the wrong grain. Anchor your limits to sustained weekly volume per department, then allow headroom for known spikes such as release weeks or audit periods. Publish the limit and the trigger for raising it, so teams plan rather than hoard.

Rollouts follow the same logic. Move one department at a time, measure the six numbers for a full cycle before scaling, and treat a flat adoption line as information rather than failure. Often the blocker is not enthusiasm but a missing integration path, an approval step, or unclear guidance on which workload belongs on which tier. Fix the path and the volume follows.

Finally, keep the commercial side simple. Quanta is a pay-as-you-go API relay for power users and teams with heavy, sustained workloads: one balance covers the models and tools your departments already use, every call is metered on real tokens, and cache writes and cache reads are priced separately so the efficiency gains you engineer actually show up in the ledger. People who refer others earn 19% of their top-ups, which helps when adoption spreads informally between teams. If your departments are about to share a single spending envelope, open an account and put everyone on one metered ledger from the first rollout.

06 · What Good Adoption Looks Like at Six Departments

Return to the six departments that framed this article. The healthy pattern was never uniform volume. It was legible volume: builders active every week, token totals rising with delivered work rather than drifting upward, cache reads growing faster than cache writes, spend per completed task trending down as teams learned to reuse context, concentration falling as more people adopted the workflows, and limits that were set from sustained usage instead of panic.

That is the standard to aim for. Measure adoption as metered, sustained, outcome-linked use, report it per department with the cache split intact, and your budget conversations become much shorter. The ledger will tell you which teams have made AI part of how work gets done, and which teams are still experimenting on someone else's budget.