What Codex Actually Sends to the Model

I'll pull the source article so the paragraphs stick to verified details only.A reverse-engineering write-up on 0xkato measured what the Codex CLI actually ships to a model when a user types a 16-character prompt, Reply with pong. Against Codex CLI 0.145.0 and the gpt-5.6-sol model, that short line produced a 42,980-byte request body that tokenized locally to about 9,435 tokens with o200k_base. Only about 25 of those tokens, or 0.3%, came from the wrapped user text. The rest was Codex scaffolding: base instructions, tool definitions, permissions, skill metadata, environment context, and request framing. The author captured this by pointing Codex at a custom local HTTP provider that saved each request, redacted sensitive headers, and returned a fixed fake response so no external model was called. On Hacker News the piece sits at 6 points with no comments yet.

The first request was dominated by three items: an additional_tools developer payload with four top-level tool entries at roughly 3,942 local tokens, a developer message of main Codex instructions at about 3,729 tokens, and the tiny user message at 25. The tools were not four simple actions. They included exec, wait, request_user_input, and a collaboration namespace; collaboration alone held six subtools, and exec nested command execution, patching, image inspection, plan updates, and more. In that run Codex put tools and base instructions inside the input array rather than top-level instructions and tools fields. Project AGENTS.md files were loaded by launch directory: root-only starts sent root markers only, a child start sent both levels, and later listing a child path did not pull child instructions automatically. Skills under .agents/skills/ initially contributed only name, description, and path; SKILL.md bodies stayed out until read. MCP tool descriptions were also deferred: configured servers added generic discovery guidance on exec, and full names and descriptions appeared only after discovery, growing later requests by thousands of tokens when many markers were retained.

For builders, the practical result is that context cost and privacy risk are driven more by agent packaging than by the prompt string. A controlled coding-task trace grew from about 9,815 local tokens on the initial task to about 11,889 after search, file reads, tests, a failed regression, a fix, a green suite, and a verified diff, a gain of roughly 2,074 tokens and 8,200 raw bytes while search hits, file contents, failures, patches, and diffs stayed available to later turns. Unread repo files, including ignored paths and a fake .env, did not appear until explicit reads. .gitignore did not block those reads or keep the resulting tool output out of subsequent requests. Terminal output stayed in history, including ANSI text and stack traces, and large outputs were truncated to head-and-tail samples rather than fully dropped. Images crossed as data URLs after attachment and resize. Compaction, when forced against the custom provider, sent accumulated history plus a summary prompt as a second request, then rebuilt around retained user messages and the returned summary, cutting the resumed request by about 25,729 bytes and 11,908 local tokens relative to the compaction request.

Market-wise this sits next to Claude Code, Cursor, and other agent CLIs that also wrap models with large tool schemas and project instruction files, but the measurement is specific to Codex’s client-side request assembly rather than a provider bill or a rival product. The experiment does not claim a universal minimum across every Codex version, OS, or surface, and it does not measure autonomous model reasoning, summary quality after real compaction, provider-side caching, or billing. What it does show is a repeatable client boundary: some payload leaves before any tool use, and other payload only after read, exec, MCP discovery, or image attach. That distinction matters for anyone shipping AGENTS.md chains, MCP servers with long tool descriptions, or agents that may open logs and env-like files on demand.

Watch request size and history retention as the operational metrics, not prompt length. Keep AGENTS.md and skill metadata short on the cold path if first-request overhead is a concern. Treat MCP allowlists as a size control as well as a capability control, since one large discovered description still left over a thousand markers after truncation and added tens of thousands of bytes. Assume anything explicitly read or printed can reappear in later turns until compaction replaces raw tool history with a summary. Compaction itself is another model call that may drop detail that only lived in tool output, so critical constraints should live in durable instruction files or repeated user messages if they must survive. The companion artifact pack on the post includes the recorder, sanitized bodies, analysis files, tests, and figure sources for anyone who wants to re-measure against a newer CLI build.