A token-spend chart that bins usage by task label — scan repository, run tests, orchestrate agents — is a common way to visualize where an agentic system’s money goes.
It’s also the wrong frame for the question an enterprise actually needs answered. Task labels describe what an agent was doing. They say nothing about whether that spend produced something an auditor could stand behind, or whether it was cache-eligible and therefore cheap to repeat. This readout works through what a governance-oriented breakdown looks like instead, and what happened when the resulting rubric was checked against both major agent platforms’ own first-party documentation.
Two questions a task-label chart can’t answer
Two things determine whether agentic token spend is defensible, and neither shows up in a breakdown by activity. First: how much of the spend was cache-eligible input that a well-architected system reuses, versus output that has to be regenerated every time. Second: how much of the spend produced an auditable work product — a test result, a citation-checked claim, a decision a named party would sign off on — versus overhead that leaves no trace a reviewer could inspect.
A task-label chart also tends to bury a specific failure mode inside an ordinary-looking category. When an agent’s context window fills up, most production systems now compress the conversation and continue — a step commonly called compaction. On a chart bucketed by activity, compaction reads like just another kind of work. It isn’t. It’s a context-management operation with its own cost and its own fidelity risk, and treating it as equivalent to, say, running a test hides both.
What’s actually computable, and what isn’t
Two governance-relevant figures turn out to require nothing beyond what both major vendors already report in their usage accounting. A cache-efficiency ratio — the share of input tokens that were served from cache rather than processed fresh — is native to both platforms’ usage fields. So is a multiplier comparing a given run’s total token spend against a plain single-turn chat baseline for the same task, which at least one vendor has published a reference class for.
The third figure — what share of total spend produced something an auditor could review — is not computable from a raw usage log at all. It depends on what a step did, not how many tokens it used, and neither vendor’s usage object carries that information. An agent has to tag its own steps — by function, and by whether the step’s output persisted as a reviewable artifact — before this figure means anything. Call it a reviewable-output ratio, deliberately, not an assurance ratio: it establishes that something persisted in a form a reviewer could open and look at, and nothing more. It says nothing about whether that output was correct, whether required verification actually happened, or whether the action was authorized. An unauthorized step that happens to leave a clean, persistent artifact scores identically to an authorized one. A well-instrumented agent and a poorly instrumented one can also show identical usage logs and produce a wildly different picture of how much of the spend was reviewable.
Compaction is a design choice, not a defect
Both Anthropic and OpenAI treat context compaction as a deliberate, named capability rather than an unmanaged side effect. Anthropic frames it as a technique for preserving the parts of a conversation that matter — architectural decisions, unresolved issues — while dropping what doesn’t, so an agent can keep working without a meaningful drop in behavior, while acknowledging that compacting too aggressively risks quietly losing context whose importance only becomes clear later. That framing matters for how compaction gets scored: it should not be counted as pure waste by default.
Where the two platforms diverge is in what compaction actually returns, and that divergence has a real governance consequence. Anthropic’s compaction is implemented by asking the model to produce a plain-text summary — something a person can open and read. OpenAI’s compaction returns a compacted context object built around an encrypted item, one the documentation is explicit is not meant to be read by a person at all. Neither choice is unreasonable on its own terms: an opaque artifact narrows what a compromised log can expose, while a legible one lets a reviewer check what survived compression against what came before. But the practical effect for a governance rubric is asymmetric regardless of which design is preferable. On one platform, a reviewer can inspect a compaction step and judge whether it preserved what the task needed. On the other, that inspection is architecturally unavailable for that step — not for the run as a whole, since other steps can still carry their own inspectable evidence.
There’s a second, narrower interaction worth flagging on the OpenAI side specifically: its own documentation notes that compaction can reduce cache reuse, since replacing earlier context changes the prefix a cache lookup depends on. A governance rubric applied to an OpenAI-based agent should treat a compaction event as something that can suppress the cache-efficiency figure on its own, not as an unrelated line item.
One benchmark exists; the other doesn’t yet
Anthropic has published a concrete reference class for how much more expensive agentic architectures run relative to a single chat turn: roughly four times the tokens for a single agent, roughly fifteen times for a multi-agent system, with token usage alone accounting for the large majority of the performance variance the company measured on an internal benchmark. That gives a governance rubric something to compare a given run against.
No equivalent figure exists in OpenAI’s first-party documentation as of this readout. Two targeted searches for a comparable published multiplier or variance benchmark returned no first-party results. That gap is reported as a gap, not filled in by analogy.
The rubric
Everything above describes what the three governance-relevant figures mean and why they diverge by platform. Here is how to actually compute them against a run.
What a raw usage log can and can’t give you. Cache-efficiency and the multiplier-vs-baseline need nothing beyond the usage object either vendor already returns. The reviewable-output ratio needs more: a step-level record of what each call did — step type, and whether the step’s output persisted as something a reviewer could inspect — which no vendor’s usage accounting carries. An agent that never instruments its own steps can produce the first two figures and not the third.
step: step_id vendor # “anthropic” | “openai” usage: { input_tokens, output_tokens, cache_read_tokens, cache_write_tokens } step_type # perception | cognition | action | verification | coordination | compaction produces_artifact # did this step’s output persist as something a reviewer could inspect? compaction_inspectable # set only when step_type = compaction
Classifying each step. Direction and Cacheability come straight off the usage fields. Function needs tagging at the call site: Verification beats Coordination beats Compaction (scored separately) beats Cognition beats Action beats Perception, first match wins. Governance weight is a binary call per step, and the unit of governance is the step, not the token — when a step is marked reviewable, its entire token count counts toward the numerator, not just the tokens making up the artifact itself. This is closer to “share of calls that produced something reviewable” than a literal token-level accounting, and that distinction is stated here rather than left implicit.
The three figures.
cache_efficiency = total_cache_read / total_input reviewable_output_ratio = (full token count of steps where produces_artifact = true) / (total input + output tokens, including compaction and discarded work) multiplier = total_run_tokens / chat_baseline_tokens_for_same_task
The multiplier compares against Anthropic’s disclosed bands only — roughly 4x for a single agent, roughly 15x for multi-agent — and only when the run itself is on Anthropic’s architecture. An OpenAI-based run’s multiplier gets reported on its own terms, flagged as having no published reference class to compare against.
What comes out the other end. A scored run reports the cache-efficiency ratio, the reviewable-output ratio with governed and unaudited overhead tokens broken out, a per-step confidence flag (not a single run-wide verdict), and the multiplier against the applicable reference band. Function breakdown by token count is reported alongside as context — it is not a fourth governed figure.
Where this breaks. The reviewable-output ratio only reflects the instrumentation quality of the agent being scored. The name is deliberately narrow: this is not a formal assurance measure. Attribution happens at the level of the whole step, not the individual token. Fidelity checks on inspectable compaction aren’t fully automatable — a “fidelity-checked overhead” label is a claim that a check ran, not a guarantee it was rigorous. And the multiplier logic assumes no OpenAI reference class exists; if one gets published later, this comparison needs revisiting.
A token log tells you what something cost. It cannot tell you whether that cost was governed unless the system generating the log was built to say so. What every vendor gives you for free is native usage telemetry — raw token counts, cache reads and writes. Cache efficiency is computed directly from that telemetry. A cost multiplier is not: it’s a derived figure requiring a published reference class only one vendor has disclosed.
The deeper point: the token is the unit you’re billed in, but it isn’t the unit governance operates on. The step is what gets classified. The artifact is what a reviewer actually inspects. Governance sits above all three. Cost telemetry and governance evidence answer questions at different semantic layers, and no amount of refining the token count closes that gap on its own.
