CAL Dimension 1: Phase Attribution
Every multi-agent run has at least two phases: generating a plan and executing it. Larger pipelines add verification and synthesis. The CAL tracks phase boundaries as explicit events, not inferred from timestamps.
The mechanism is a phase tag injected into the system prompt of each LLM call:
PHASE: plan | execute | verify | synthesize
CAL_RUN_ID: run_20260618_042
CAL_AGENT_ID: orchestrator_0
Your logging layer reads these tags and bins every input/output token count under the correct phase. The phase cost then becomes a first-class metric in your post-run report.
In a well-structured run, plan phase should be cheap. Planning is high-density reasoning: a small context window, a tight prompt, one or two tool lookups. If your plan phase is consuming 30% of total tokens, that is a signal your planner is doing execution work — fetching full documents, running code, generating long-form drafts instead of outlines.
CAL Dimension 2: Agent Role Attribution
In a multi-agent system, roles are logical separations of responsibility. The CAL treats each role as a separate billing entity within the run. A single LLM model can fulfill multiple roles sequentially, but the CAL tags each call with its role at call-time.
Four canonical roles in most pipelines:
- Orchestrator: Owns the plan, dispatches tasks, collects results. Should have the highest context window but lowest call frequency.
- Subagent: Executes a discrete, bounded task. Should have a minimal context window scoped to that task only.
- Critic: Reviews output for correctness or quality. Often over-populated with context it does not need.
- Formatter: Transforms structured data into final output format. Should almost never need reasoning tokens — a formatter calling a 100K-context model is waste.
The orchestrator anti-pattern is the most expensive: an orchestrator that re-summarizes every subagent result before dispatching the next task. Each dispatch adds the full accumulation to the next context window. A run with five sequential subagents, each triggering an orchestrator re-summarization, multiplies orchestrator token spend by roughly 5x compared to a parallel dispatch with a single final aggregation.
Tool calls are the silent budget eaters. An LLM call that costs 4,000 tokens might trigger a web-search tool that returns 12,000 tokens, all of which get appended to the next call’s context. The tool’s output tokens cost nothing in isolation, but they multiply every subsequent input token count until the context is trimmed.
The CAL tracks two numbers per tool invocation:
- Returned tokens: Total tokens in the tool’s output payload.
- Used tokens: Tokens from that payload that appear in the agent’s subsequent reasoning (measured by substring matching or embedding similarity, depending on your implementation).
The return/use ratio is the core metric. A web-search tool returning 8,000 tokens where the agent extracts a single 200-token fact has a 2.5% use ratio. That is not a tool-call problem; it is a tool-output truncation problem. The fix is trivial: return the top 1,000 tokens and let the agent request more if needed. The impact is immediate: every subsequent call in that agent’s chain is 7,000 input tokens lighter.
Five tool-call types with their typical pathologies:
CAL Dimension 4: Context Carry
Context carry is the fraction of an agent’s input token count that comes from prior conversation history, injected documents, or system prompt boilerplate — as opposed to the new task instruction for that specific call. It is the single largest source of silent cost multiplication in multi-agent pipelines.
The formula is straightforward:
carry_overhead = (input_tokens - task_instruction_tokens) / input_tokens
A call with 18,000 input tokens where the actual task instruction is 2,000 tokens has a carry overhead of 88.9%. That means you are paying for 16,000 tokens of history and boilerplate on every single call in that agent’s chain. If the agent runs 10 calls, you have spent 160,000 tokens on carry alone, not reasoning.
Two carry patterns to eliminate immediately:
Full-history carry: The orchestrator’s complete conversation history gets attached to every subagent spawn. The subagent needs a 500-token task brief. It gets a 15,000-token orchestrator history instead. Fix: generate a structured handoff document at spawn time — task description, required inputs, expected output format, nothing else.
Boilerplate inflation: A 4,000-token system prompt that re-explains the company background, the agent’s role, its tools, its output format, and three pages of safety rules — on every call, including tool-call follow-up turns. Fix: move static boilerplate into a cached prefix. Anthropic’s prompt caching feature reduces the cost of repeated static prefix tokens to roughly 10% of normal input token price. A 4,000-token system prompt called 50 times goes from 200,000 billable tokens to 20,000 billable tokens with a single cache breakpoint marker.
CAL Dimension 5: Retry Tax
Every failed tool-call or parse error that triggers a retry is a taxable event. The retry carries the full conversation history up to that point plus the failure message. In a long chain, a retry at step 8 is far more expensive than a retry at step 1 because it carries seven steps of accumulated context.
The retry tax compounds. A parse failure at step 8 in a 10-step chain might add 12,000 tokens to that call and inflate every subsequent call by the same amount. If the parse failure happens three times before the agent succeeds, the retry tax on that single error is 36,000 tokens, before accounting for the downstream carry effect.
The CAL makes retry tax visible by tagging every call with a retry_depth counter. When retry_depth > 0, the tokens for that call are classified under Retry Tax rather than the normal phase bucket. This surfaces failure-mode cost separately from productive spend.
Retry tax above 15% of total spend is a clear signal that your tool interface is unreliable or your output parsing is fragile. Structured output schemas (JSON mode, typed function signatures) typically cut parse-failure retry rates from 15-25% to under 3%, which directly reduces Retry Tax as a share of total spend.
Worked Example: A Research-and-Draft Pipeline
Below is a fully illustrative worked example. The numbers are constructed to be internally consistent and represent the order-of-magnitude behavior you would observe in a real pipeline of this type, but they are not measurements from a specific run. Use them as a calibration template, not benchmarks.
Pipeline: Orchestrator spawns three subagents to research three sub-topics, then synthesizes results into a 1,500-word draft.
Configuration: Model with 100K context window, web-search tool returning up to 10,000 tokens per call, no prompt caching, full-history carry on all spawns.
Totals (illustrative): 175,000 input tokens + 10,350 output tokens = ~185,350 tokens total.
Now the CAL attribution breakdown:
The CAL immediately surfaces four problems that a flat token count hides entirely. The synthesize phase is consuming 39% of budget because the formatter and aggregation calls carry massive histories. The formatter alone is 23% of total spend — a role that should be sub-5%. Context carry at 82% means the pipeline is spending roughly four dollars on history for every one dollar on actual reasoning. And the web-search tool has a 6% use ratio, meaning 94% of what it returns gets ignored.
The Optimized Version: What the CAL Tells You to Change
The CAL is not just a diagnostic. Each alert maps directly to a specific fix. Here is what the four alerts above prescribe:
Alert: Synthesize phase 39% (target <10%)
Root cause: formatter and aggregator carry full conversation history. Fix: generate a structured JSON handoff after the critic pass. The formatter receives a 2,000-token structured document, not a 38,000-token conversation. Synthesize phase drops from 39% to under 8%.
Alert: Formatter role 23% (target <5%)
Root cause: same as above, plus the formatter is running on the same 100K-context model. Fix: route formatter to a cheaper, smaller model (Haiku-class). The formatting task is deterministic template filling, not reasoning. Combined with the context fix, formatter cost drops from 23% to under 3%.
Alert: Web-search use ratio 6% (target >25%)
Root cause: tool returns 10,000 tokens per search call; agent extracts a few hundred. Fix: add a two-step tool design. First call returns metadata + 150-token snippets. Agent decides which snippets are relevant. Second call fetches full text for selected results only. Use ratio rises to 40-60%; downstream carry inflation drops by 70%.
Alert: Context carry 82% (target <40%)
Root cause: every spawn passes full orchestrator history. Fix: generate a structured handoff summary at each agent spawn — task, required context, expected output format, nothing else. Enable prompt caching for the static system prompt. Carry overhead drops to the 35-45% range.
Running the optimized version against the same task with these four changes applied, total token spend drops from ~185,000 to roughly 60,000-75,000 tokens — a 60-65% reduction. The CAL attributed the waste; the fixes were each obvious once the attribution was visible.
Implementing the CAL in Your Pipeline
The CAL does not require a third-party tool. You need three things:
1. Phase and role tags in every LLM call header. Add a structured block to the start of every system prompt with CAL_PHASE, CAL_ROLE, CAL_RUN_ID, and CAL_AGENT_ID fields. These tags cost roughly 20 tokens per call and give your logging layer the dimensions it needs.
2. Token counting at call boundaries. Most LLM providers return token counts in the API response. Log input_tokens, output_tokens, and the phase/role tags together. Do not rely on post-hoc token estimation — count at the API response, not in your prompt template.
3. Tool-call output interception. Before any tool output is appended to an agent’s context, log the token count of the returned payload. Track this as a separate “tool_return_tokens” field alongside the LLM call that follows. You can compute the use ratio later by comparing tool_return_tokens to the delta in the next call’s context.
A minimal implementation in any language fits in under 80 lines. The data model is four columns: run_id, call_id, dimension_values (phase, role, tool_type, retry_depth), and token_counts (input, output, tool_return). Every other CAL metric — carry overhead, use ratio, retry tax — is a derived query over those four columns.
Once you have three or four instrumented runs, patterns emerge fast. You will find that 80% of your excess token spend concentrates in two or three specific agent transitions. That is where the optimization work pays off.
CAL Thresholds as a Go/No-Go Gate
The CAL becomes most valuable when you use its metrics as a quality gate before scaling a pipeline. A research pipeline with 82% context carry is not ready to run at 1,000 tasks per day. At scale, that 82% carry means you are spending $8,200 on carry for every $1,000 of productive reasoning. Before any multi-agent workflow goes to production scale, run the CAL attribution check and confirm all five dimensions are within target thresholds.
Define your thresholds explicitly in your pipeline config, not in a spreadsheet. Something like:
cal_thresholds:
phase_plan_max: 0.15
phase_synthesize_max: 0.10
role_orchestrator_max: 0.20
role_formatter_max: 0.05
tool_use_ratio_min: 0.25
carry_overhead_max: 0.40
retry_tax_max: 0.08
Fail the pipeline run with a hard error if any threshold is breached. This creates the feedback loop: engineers cannot add a new agent role without the CAL noticing if that role inflates carry overhead past the threshold.
You can explore the cost calculators and developer tools at WOWHOW Tools to build out your own CAL dashboard, or browse the full template collection for multi-agent pipeline starters. If you are running production pipelines with real cost pressure, the Pro Vault tier includes the full CAL implementation template with logging adapters for the major LLM APIs.
The immediate action item: pick the most expensive multi-agent run you ran this week. Add CAL phase tags retroactively by reading through your log traces and manually binning each call. You do not need instrumentation to do the first attribution — just a log file and 20 minutes. What you find will determine whether you need a 2x optimization or a 10x one.
People Also Ask
What is the WOWHOW Cost-Attribution Ledger (CAL) for multi-agent token cost?
The WOWHOW Cost-Attribution Ledger (CAL) is a token accounting framework that assigns every token in a multi-agent LLM run to one of five cost centers: Phase, Agent Role, Tool-Call Type, Context Carry, and Retry Tax. Instead of reading a flat invoice total, engineers see exactly which agent role or pipeline phase is consuming the budget — making targeted optimization possible.
How do I reduce context carry overhead in a multi-agent pipeline?
Generate a structured handoff document at every agent spawn rather than passing the full orchestrator history. The handoff should contain only the task description, required inputs, and expected output format — typically 500–2,000 tokens instead of 15,000+. Combine this with prompt caching on static system prompts to bring context carry overhead below the 40% target threshold.
The CAL framework targets a use ratio above 25%: at least one in four tokens the tool returns should appear in the agent’s subsequent reasoning. Web search tools commonly produce ratios of 2–8%, meaning 90%+ of returned tokens are discarded. A two-step design — first return metadata and short snippets, then fetch full text only for selected results — typically raises the ratio to 40–60%.
When should I apply CAL thresholds as a go/no-go gate before scaling?
Apply CAL thresholds before any multi-agent workflow moves to production scale — meaning more than 100 runs per day. At that volume, an 82% context carry rate translates to paying roughly eight dollars of carry cost for every one dollar of productive reasoning. Define the five threshold values in your pipeline config and fail the run hard if any dimension is breached.
How does the Retry Tax dimension differ from normal phase token spend?
Retry Tax tracks tokens spent specifically on failed attempts: tool errors, parse failures, and output-validation loops. Unlike phase spend, which funds productive work, retry tokens compound — each failure adds the accumulated conversation history to the retry call. In deep chains, a single parse failure at step 8 can add 10,000–15,000 tokens of retry tax before the step succeeds. The CAL tags these separately using a retry_depth counter so failure-mode cost is never hidden inside the execute phase.
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.