The Claude Code output cap is gated on the payload's own shape rather than on the host that
will render it:
// post_tool.rs:390
if normalized.agent_id == "claude_code" && host_capped {
normalized.agent_id comes from the payload's shape. stats_agent_id(&normalized.agent)
is the resolved host, which is what distillation books under and, since #773, what a
decline records. The two differ in exactly one documented case, which is why
resolve_agent_id exists: Codex sends a Claude-Code-shaped payload
(normalize.rs:294).
Two ways that lands, and neither has been measured:
Which of the two is real depends on Codex's own behaviour above its cap, and that is a
fact about their product that this repository has never established. The host capability
matrix in the memory board records that Codex Full tier "was never measured and does not
hold on 0.144.6" (#359), so the honest answer today is that nobody here knows.
What this is not
Not a fix waiting to be typed. Swapping the id changes which payloads are declined, so it
changes behaviour and needs the measurement first: what does Codex do with a tool result
above 30,000 bytes, and does it apply a cap of its own.
Found while fixing the attribution half of the same line in #773. That half was
bookkeeping and shipped; this half is behaviour and did not.
The Claude Code output cap is gated on the payload's own shape rather than on the host that
will render it:
normalized.agent_idcomes from the payload's shape.stats_agent_id(&normalized.agent)is the resolved host, which is what distillation books under and, since #773, what a
decline records. The two differ in exactly one documented case, which is why
resolve_agent_idexists: Codex sends a Claude-Code-shaped payload(
normalize.rs:294).Two ways that lands, and neither has been measured:
If Codex has no 30,000 byte inline cap, OMNI declines a payload it could have shortened,
and the decline is silent.
distils past it and books a saving the model never received, which is the Claude Code post-hook emits
updatedResponse, a key Claude Code ignores: the distilled output never reaches the agent, but OMNI records and reports the saving #158 and Ledger records a passthrough the harness never delivered: a 30 KB cat is 2 KB in context, then a later tail folds 90 of those lines as "already shown" (0.7.7) #716class: right in our books, absent from the transcript.
Which of the two is real depends on Codex's own behaviour above its cap, and that is a
fact about their product that this repository has never established. The host capability
matrix in the memory board records that Codex Full tier "was never measured and does not
hold on 0.144.6" (#359), so the honest answer today is that nobody here knows.
What this is not
Not a fix waiting to be typed. Swapping the id changes which payloads are declined, so it
changes behaviour and needs the measurement first: what does Codex do with a tool result
above 30,000 bytes, and does it apply a cap of its own.
Found while fixing the attribution half of the same line in #773. That half was
bookkeeping and shipped; this half is behaviour and did not.