Codex tool loop causes context snowballing and multi-million-token input amplification

Summary

Codex appears to have a serious token-efficiency problem during tool-heavy coding sessions. This is not simply “complex tasks use tokens.” Shell commands, file inspections, tool results, progress messages, and prior model interactions accumulate in working context, and subsequent model requests appear to carry much of that accumulated context again.

tool call → result enters context → next model request includes accumulated context → another result is added → next request carries an even larger context → repeat

This makes tool inefficiency multiplicative rather than additive. A redundant inspection is not only wasteful once: its output can remain in context across many later model requests.

Evidence from complete rollout JSONL

I independently audited completed Codex rollouts using the complete rollout JSONL files as the source of truth, not UI estimates or log tails.

Recent run (~11.4 minutes)

• 34 model requests
• 33 tool calls
• 3,521,627 total input tokens processed
• 3,368,448 cached input tokens
• 153,179 noncached input tokens
• 12,403 output tokens
• 4,897 reasoning output tokens
• first request: 16,654 input tokens
• final/largest request: 158,312 input tokens
• 23 inspection calls
• 2 edit calls
• 5 validation calls
• 1 delivery call
• 47 surplus repeated file-inspection references
• 15 large inspection outputs
• 2 exact duplicate tool calls
• 0 compactions

The active request context grew roughly 9.5×, from 16.7K to 158.3K tokens, during one ~11-minute run. Cumulative input processed reached 3.52 million tokens.

More extreme observed run

• 84 model requests
• 83 tool calls
• 12,385,089 total input tokens processed
• 12,184,320 cached input tokens
• 200,769 noncached input tokens
• 45,468 output tokens
• 11,268 reasoning output tokens
• context grew from 17,182 to 197,167 input tokens
• 28 inspection calls
• 18 edit calls
• 14 validation calls
• 15 exact duplicate tool calls
• 53 surplus repeated file-inspection references
• 18 large inspection outputs

This run processed more than 12 million cumulative input tokens.

Caching materially helps and I am deliberately separating cached from noncached input here. But caching does not solve the underlying context-growth architecture: the model is still repeatedly operating against an enormous accumulated working context.

Why the tool loop is the problem

Nearly every shell/tool action requires another model turn. That next model turn carries the accumulated conversation/tool state needed to decide what happens next:

model → inspect → model → inspect → model → search →
model → inspect → model → edit → model → test → model → inspect

A tiny visible command such as grep, sed, cat, git diff, or a test invocation can therefore have a large hidden downstream token cost when its output becomes persistent context.

A large inspection introduced early in a run can contribute to the input of dozens of subsequent model requests. Effective consumption starts resembling:

context size × subsequent model requests

rather than:

new information introduced

As a result, context can snowball toward the model limit even while Codex is successfully making progress.

Repeated inspection is especially expensive

In the recent example, 23 of 33 tool calls were inspections while only 2 were edits. The audit detected 47 surplus repeated file-inspection references and 15 large inspection outputs.

Some rereading is obviously legitimate during debugging. The problem is that unnecessary rereads are disproportionately expensive because duplicated information can continue traveling through later model requests.

Users should not need to micromanage a capable coding model's file-reading strategy merely to prevent the orchestration layer from producing massive context amplification.

This is not solved by shrinking AGENTS.md/prompts

I have already aggressively reduced persistent repository instructions and removed unnecessary workflow text. That reduces initial request size but does not address the dominant effect.

Saving 1,000 prompt tokens is insignificant when a run begins around 17K and grows to 150K–200K because tool interactions continually enlarge the working state.

Cached tokens do not make this irrelevant

The majority of cumulative input in these examples was cached. That is useful and should absolutely be preserved.

However, repeatedly exposing 3.5M or 12.4M cumulative input tokens during ordinary tool-driven coding still creates:

• context-window pressure
• earlier compaction pressure
• less effective room for useful reasoning
• increased latency
• unnecessary model/tool iterations
• unpredictable usage/allowance consumption
• greater risk of losing important state during long tasks

What I would like the Codex team to investigate

Please investigate whether Codex tool execution can preserve a compact structured working state rather than repeatedly injecting the accumulated execution transcript into subsequent model requests.

Potential areas:

• deduplicate previously inspected file content
• reference cached tool results instead of reinserting their contents
• evict obsolete inspection output
• use delta-based file context after edits
• maintain structured persistent state for known files/commands/results
• distinguish durable task state from ephemeral shell output
• summarize old tool interactions before context becomes enormous
• detect identical/redundant inspections before executing them
• reuse already-known repository information
• allow trivial orchestration decisions without another enormous model request where architecture permits

The design goal I think matters most is:

Preserve Codex's understanding of the task without preserving every byte of the journey it took to acquire that understanding.

Desired behavior

A long-running Codex task should be able to inspect files, edit code, run tests, debug failures, and deliver a coherent change without model input growing almost monotonically toward the context limit.

The effective token cost of a tool call should be reasonably proportional to the genuinely new information it provides, rather than that information being multiplied across every remaining model request.

Reproducibility / discoverability

These measurements come from complete Codex rollout JSONL session logs. The behavior has appeared across many completed runs rather than a single anomalous session. Our current independent audit set contains 331 completed Codex runs, tracking request counts, token growth, compactions, tool calls, duplicate calls, repeated inspections, and large inspection outputs.

Keywords for related reports/automated triage: Codex CLI, token efficiency, context growth, context snowballing, context injection, repeated context, tool calls, tool output, cached input tokens, input token amplification, rollout JSONL, compaction, repeated file inspection, shell tool loop, context window, usage limits.

I can provide sanitized per-turn/token-growth measurements from additional rollout logs if useful for reproduction or diagnosis.

Start by examining complete rollout JSONL session logs and the Codex tool-loop path that assembles model requests. Compare successive request sizes, tool outputs, repeated inspections, and compactions across the reported runs. Done means preserving task understanding while avoiding near-monotonic replay of the full execution transcript; the issue does not name specific source files or tests.