What Codex Actually Sends to the Model | 0xkato

What Codex Actually Sends to the Model

Tuesday. August 04, 2026

10 mins

Codex

AI

LLM

Context

Privacy

Tooling

I recorded the requests Codex generated for a 16-character prompt, then measured what changed as it loaded instructions, exposed tools, read files, ran commands, received images, and compacted its history.

When I typed Reply with pong., the prompt was 16 characters long.

The request Codex sent was 42,980 bytes.

Encoded locally as JSON with o200k_base, it came to roughly 9,435 tokens. The wrapped prompt accounted for about 25 of them, or 0.3%. The rest came from Codex itself: instructions, tool definitions, permissions, skill metadata, environment context, and request framing.

Those token counts are local estimates, not API usage or billing. The captured request body itself is exact.

File reads and command output are added later. When the accumulated history gets too large, Codex can send it through another model request, replace it with a summary, and continue.

How I recorded the requests

Codex supports custom model providers. I pointed it at a local HTTP server that saved each request, redacted sensitive headers, and returned a fixed fake response. The experiment did not call an external model.

Codex client → local recorder → deterministic fake response<br>request saved here

The recorder shows what the client sent. It cannot show what a real provider might change after receiving the request, whether any input would be cached, or how it would be billed.

I measured two things:

Raw request bytes: the size of the HTTP JSON body before sanitization.

Approximate text tokens: the sanitized JSON encoded locally with o200k_base.

The tests used Codex CLI 0.145.0 with the gpt-5.6-sol model.

The first request

I started Codex in an empty temporary Git repository, disabled project instructions, and pointed CODEX_HOME at an empty directory.

The request still described five bundled system skills, so this was an isolated-home baseline rather than a minimum possible request.

Three items accounted for 7,696 of the 9,435 tokens:

What it contained<br>Serialized size<br>Local estimate

additional_tools developer item<br>Four top-level tool entries<br>16,741 characters<br>3,942 tokens

Developer message<br>Main Codex instructions<br>17,730 text characters<br>3,729 tokens

User message<br>Reply with pong.<br>16 text characters<br>25 tokens

The four tool entries were exec, wait, request_user_input, and a collaboration namespace. They represented more than four actions. collaboration contained six subtools, while exec described command execution, patching, image inspection, plan updates, and other nested tools.

In this run, Codex placed the tool entries and base instructions inside the input array instead of using top-level instructions and tools fields.

Project instructions

Codex builds its project instruction chain from the repository root to the directory where it starts. It looks for AGENTS.md at each level, placing the closer instructions later.

I created one root and one child AGENTS.md, each with 100 unique markers.

Starting at the repository root sent all 100 root markers and no child markers.

Starting in the child directory sent all 200 markers.

Starting at the root and later running ls child did not add the child instructions.

The launch directory determined the automatic instruction chain. Reading the child file explicitly could still add its contents as ordinary tool history.

For the size test I used synthetic high-entropy markers rather than natural prose. Each marker is a string like PAIRED_AGENTS_1000_0001, which o200k_base splits into 11 tokens on its own. Ordinary prose words do not. The table below shows that instructions are transmitted in full — it is not what your own AGENTS.md would cost.

Larger files changed the first request directly:

Raw request bytes<br>Local estimate<br>Difference from baseline

Isolated-home baseline<br>42,980<br>9,435

250 synthetic AGENTS markers<br>48,927<br>11,965<br>+5,947 bytes; +2,530 tokens

1,000 synthetic AGENTS markers<br>67,177<br>20,465<br>+24,197 bytes; +11,030 tokens

In a two-request trace with 250 markers, all 250 appeared in both requests.

Skills loaded in two stages

Repository skills under .agents/skills/ initially contributed their name, description, and path. Their SKILL.md bodies were absent until read.

Each synthetic skill had a 12-word description and a 200-word body with unique markers.

One skill added 481 bytes and approximately 125 tokens to the first request.

Ten skills added 4,810 bytes and approximately 1,250 tokens.

None of the body markers appeared in either first request.

MCP tool descriptions were deferred

I tested one local MCP server with three tools and two local servers with seven tools in total.

In the initial-only runs, both requests were 46,582 bytes and approximately 10,410 local tokens. Neither contained the custom tool names or descriptions. Instead, the exec interface gained generic MCP discovery...