Claude Code + Codex Multi-Agent System Tested: The Real Problem Behind a 98% Cache Rate

A developer built a multi-agent development system using Claude Code and Codex, and published 7 days of local runtime data: Claude Code's input/output token ratio reached 353.9:1, with cache reads accounting for 98.23% of total tokens; Codex's corresponding figures were 314.7:1 and 96.42%. But the author admits these are only usage metrics—they don't prove the system is more efficient. What he's really stuck on is organizational orchestration and output ratio, so he's publicly asking the community for help.

What the System Looks Like: Shared Task Coordination and Verification Gates

This system isn't just two models stitched together. According to the author, it contains four modules: shared task coordination, structured handoffs, verification gates, and local usage telemetry. In other words, Claude Code and Codex each handle different stages, passing state between them in an explicitly agreed format, with a verification gate deciding whether to let it proceed to the next step.

The starting point of this design is clear: make multiple agents collaborate like an assembly line, rather than having two models chat with each other. But the cost is that every handoff must carry context, and the coordination layer itself consumes tokens. The author didn't disclose the specific share of coordination-layer overhead—which is precisely the most easily overlooked part when evaluating multi-agent systems.

Reading the Data: What Does a 98% Cache Rate Mean?

First, the numbers. Claude Code's cache reads account for 98.23% of total tokens, Codex's for 96.42%. A high cache rate usually means the same prefix is being reused repeatedly, indicating the workflow has a lot of duplicated context—this could be a sign of good system design (cache hits save money), or a signal of task fragmentation, where only a tiny bit is advanced each time.

The input/output ratio is more concerning. 353.9:1 means for every 1 output token generated, the system consumes about 354 input tokens. Generated output accounts for only 0.282% (Claude Code) and 0.317% (Codex) of total tokens. The author himself pinpoints the cause: the low output ratio is because the system is struggling at the implementation stage. This isn't a model capability problem—it's that the orchestration layer fails to break tasks down to a granularity small enough and clear enough.

Cache Read is a billing and optimization mechanism in large language model APIs: when the prefix of a request exactly matches a previous request, the provider can directly reuse the already-computed key-value cache (KV Cache) without rerunning attention computation. In Anthropic's and OpenAI's pricing systems, cache-read tokens typically cost only about 10% of standard input tokens, so a high cache rate can significantly reduce unit cost. But cache hits require strict prefix matching, meaning that repeatedly sending the same system prompt, tool definitions, and conversation history in agent workflows will push up the cache rate. Conversely, an excessively high cache rate may also suggest that only extremely small increments are being advanced each time, causing a large amount of duplicated context to be read over and over.

Input/Output Ratio refers to the ratio of input tokens consumed to output tokens generated in a single API call. In ordinary chat scenarios, this ratio usually ranges from single digits to a few dozen to one; in agent workflows, because tool definitions, history, and retrieved context must be carried, the ratio rises significantly. 353.9:1 means the model spends the vast majority of its compute processing input rather than generating output—this doesn't necessarily mean inefficiency; if much of the input consists of cheap cache-hit tokens, the actual cost may be manageable. But an excessively high ratio usually indicates that task decomposition is too fine-grained, or that the system is repeatedly retrying the same stage, diluting effective output.

The Author's Two Real Problems: Organization and Output

The first problem is organization. The author says he's been struggling with multi-agent orchestration for months, and whenever he tries to go deeper he can't find the way. This is actually a common ailment of multi-agent systems: how to split tasks, how to design handoff protocols, how to roll back on failure—these engineering details determine success or failure far more than which model you choose.

The second problem is output ratio. The system gets stuck at the implementation stage, so a large number of tokens are spent reading context and retrying, while the share of code actually produced is extremely low. An intuitive comparison: if a task requires 100 reads to yield 1 effective generation, then no matter how beautiful the cache rate looks, it's only optimizing the cost of an ineffective loop.

The Three Questions He Asked the Community

The author's questions are very representative. First, are this cache rate and input/output ratio typical in conventional coding agent workflows? Second, what metrics do people use to distinguish "useful implementation" from "agents spinning their wheels"? Third, are there public datasets or reproducible benchmarks that can fairly compare different agent orchestration systems?

The three questions progress layer by layer: first confirm the baseline, then define the metric for effectiveness, and finally demand reproducible comparison methods. Currently, industry evaluation of agent systems mostly stops at task completion rate or human ratings; metrics like cost per successful task, context overhead, crash recovery, and number of human interventions lack a unified standard. The author's telemetry data, though only for personal use, at least provides a discussable template.

Common Challenges of Multi-Agent Orchestration

Several common challenges can be seen from this system. Cost accounting shouldn't look only at unit price, but at the comprehensive token consumption per successful task, including coordination and retries. Context overhead grows linearly or even superlinearly with the number of agents; poor handoff design will trap you in the strange loop of high cache rate but low output. Crash recovery is more complicated in multi-agent scenarios—failure at one stage may cause the entire pipeline to rerun. The number of human interventions is the most honest metric—the more autonomous the system, the less people intervene, but only if the verification gates are reliable enough.

The author's system put effort into verification gates, yet still struggles at the implementation stage, showing that verification gates can only intercept errors, not replace task decomposition. Breaking a large task into small steps that the model can get right in one go may be more effective than adding more agents.

Verification Gate is a quality control mechanism in multi-agent pipelines: after an agent completes a stage, an independent checking step (which can be a rule engine, another model, or human review) determines whether the output meets preset standards, and only if it passes is it allowed to proceed to the next stage. Its core value is intercepting error propagation, preventing deviation at one stage from being amplified along the pipeline. But the verification gate itself also consumes tokens and latency, and it can only judge "whether the output is qualified," not solve the upstream problem of "whether the task was correctly decomposed." When the implementation stage repeatedly fails, the verification gate keeps intercepting and triggering retries, further pushing up the input/output ratio.

Structured Handoff refers to using explicitly defined formats (such as JSON schema, fixed-field message bodies) when passing state between agents, rather than free-text conversation. Its benefits are reducing ambiguity and facilitating programmatic validation and rollback, but it also means every handoff must serialize and carry the necessary context, so the coordination layer incurs additional overhead. Poorly designed handoff protocols lead to two extremes: too many fields bloats the context, while too few fields forces downstream agents to do extra reads to fill in information—both push up the input token share.

References for Fellow Practitioners

If you're also building multi-agent development systems, you can copy a few things from this data: record the input/output ratio and cache rate for each task, but don't treat them as a report card; use "cost per successful task" as the primary metric; count human interventions separately; write explicit schemas for handoff protocols to reduce context ambiguity. As for public benchmarks, there is indeed a lack of recognized solutions at present; community-level telemetry sharing may be a realistic choice for the transitional period.

One-line Summary

Developer publishes 7-day data for a Claude Code + Codex multi-agent system; high cache rate and low output ratio expose orchestration bottlenecks.

Paragraph Summary

A developer built a multi-agent development system with Claude Code and Codex, including shared task coordination, structured handoffs, verification gates, and local telemetry, and published 7 days of runtime data: Claude Code's input/output ratio was 353.9:1 with cache reads at 98.23%, while Codex's were 314.7:1 and 96.42%, with output shares of only 0.282% and 0.317%. The author admits these are only usage metrics that don't prove the system is more efficient; what's really stuck is organizational orchestration and output ratio—the system repeatedly struggles at the implementation stage, with large amounts of tokens consumed on context reads and retries. He publicly asks the community three questions: whether these metrics are typical, how to distinguish effective implementation from spinning wheels, and whether reproducible comparison benchmarks exist. The article then extends the discussion to common challenges of multi-agent orchestration in cost accounting, context overhead, crash recovery, and human intervention.