openai

The prompt is 0.3% of what Codex sends

Promtime

openai

Typing "Reply with pong." into Codex produced an HTTP request of 42,980 bytes, roughly 9,435 tokens when encoded locally with o200k_base, and the wrapped prompt accounted for about 25 of them, or 0.3%. The measurement comes from 0xkato, who pointed Codex CLI 0.145.0 with the gpt-5.6-sol model at a local HTTP server that saved each request and returned a fixed fake response.

At a glance

  • Three items carried 7,696 of the baseline request's 9,435 tokens: a developer item with four tool entries at 3,942 tokens, the main Codex instructions at 3,729, and the user message at 25.
  • File contents, terminal output, MCP tool descriptions and images entered the traffic only after an action; unread repository files, ignored files and a planted fake .env stayed out of the first request.
  • The token counts are local estimates rather than API usage or billing, though the captured request bodies are exact, and .gitignore did not stop an explicitly read log from entering later requests.

Agent tooling is usually discussed in terms of what the operator types, but the measurements suggest the operator's text is a rounding error next to the scaffolding the client assembles. For teams reasoning about data boundaries, the useful line appears to run between what a client ships by default and what a single read or command promotes into permanent conversation state. That state, once written, travels with every later turn.

Tool definitions and base instructions carried 7,671 of the baseline's 9,435 tokens

The baseline came from an empty temporary Git repository with project instructions disabled and CODEX_HOME pointed at an empty directory. The request still described five bundled system skills, which makes it an isolated-home baseline rather than a minimum. The developer item holding four tool entries ran 16,741 characters; the main instructions ran 17,730.

The four entries were exec, wait, request_user_input and a collaboration namespace, and they covered more than four actions: collaboration contained six subtools, while exec described command execution, patching, image inspection and plan updates. In this run Codex placed the tool entries and base instructions inside the input array instead of the top-level instructions and tools fields.

Project instructions travelled in full, adding 11,030 tokens at 1,000 markers

Codex builds its project instruction chain from the repository root down to the launch directory, looking for AGENTS.md at each level. Starting at the root sent all 100 root markers; starting in a child directory sent all 200. Running ls child from the root added nothing.

Instructions travelled in full. A file with 250 synthetic markers pushed the first request to 48,927 bytes and 11,965 local tokens; 1,000 markers took it to 67,177 bytes and 20,465 tokens, 11,030 above the baseline. The markers are high-entropy strings, 11 tokens each under o200k_base, so prose costs less.

Repository skills under .agents/skills/ contributed only name, description and path: one skill added 481 bytes and about 125 tokens, ten added 4,810 bytes and about 1,250. MCP tool descriptions were deferred behind generic discovery guidance; printing the deferred entries for one server with three tools added 5,894 bytes and about 1,522 tokens.

A ten-step bug fix grew the request by 2,074 tokens

The coding task fixed a precedence bug where explicit false values were overwritten by user defaults, across ten predetermined steps. The first request measured 44,189 bytes and about 9,815 local tokens, the last 52,389 bytes and 11,889. Search results, file contents, the failing test, the patch and the final diff all stayed available to later turns.

Five planted files stayed out of the first request; rg --files -uu added their filenames only. After explicit reads, the source file, an ignored file, a fake .env and an ignored 20,000-line log all appeared, the log truncated to a head-and-tail sample that still pushed the request from 46,250 to 87,561 bytes.

Command output survived verbatim at ten and 100 lines, and repeated output was not deduplicated. A truncated 10,000-line result still moved the request from 43,337 bytes and about 9,584 tokens to 88,480 bytes and 25,835. Images crossed as data URLs: a 32×32 PNG as 442 characters, a resized gradient as 71,666.

What compaction leaves behind

Against a custom provider, compaction was forced with 13,000 reported input tokens, a 20,000-token window and a 12,000-token threshold, producing requests of 42,030 bytes, then 68,375 with the history and an empty tool list, then 42,646 with the output replaced by a summary.

The measurements do not cover provider-side transformations, cache hits, billing or the quality of a real summary, and no universal minimum request is claimed across Codex versions, models or platforms. The recorder, sanitized request bodies, analysis files and tests ship in a companion artifact pack.

Comments

No comments yet. Be the first.

Join the conversation

Sign in with Google to leave a comment. Your name and avatar come from your Google profile, and the comment appears after moderation.

We only use your name and avatar from Google. We never store your email address.