The tokens in your agent harness

OpenAI's open-source Codex CLI spends extra tokens on hidden LLM calls, including an automatic thread-naming request capped at 960 bytes that runs whenever an unnamed thread receives a completed, nonempty user text message, according to an analysis of the Codex Rust source at version rust-v0.166.0. The naming call prefers the gpt-5.6-luna model at low reasoning effort when signed into ChatGPT and the model exists in the catalog, otherwise it uses the currently selected model, and returns a structured title preferably under five words or 36 characters. The analysis follows a report that Claude Code spends 15-20% of tokens updating a three-word status line, and notes Codex instead piggybacks its live activity indicator on reasoning summaries requested with standard responses rather than issuing a separate status-generation request.

The Hidden Tokens In Your Agent Harness A look into how Codex spends your extra tokens. I was recently made aware of how Claude Code spends 15-20% of the tokens on updating a three-word status line https://gist.github.com/flamerix-ai/c3905705cc4205e5de3011fa2e74efce . Since I work almost entirely within Codex https://github.com/openai/codex , I decided to take a peek at the code Codex is open source and written in Rust . If you are working with an open source harness, be that Codex, pi, OpenCode, or something else, I encourage you to explore how it actually works. Giving threads a name Whenever an unnamed thread receives a completed, nonempty user text message, an automatic thread naming procedure is invoked behind the scenes. <sup 1 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/app/thread routing.rs L2070 , 2 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/app/thread title.rs L180 </sup This happens for example when you start a fresh Codex session and enter the first instructions into the text box. In this case the full prompt, including the title naming instructions, labels and user's text, are capped at 960 bytes and sent to an LLM. <sup 3 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/app/thread title.rs L288 , 4 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/app/thread title.rs L275 </sup The returned response is a structured output, resulting in a thread title that is preferably under five words, or 36 characters. The preferred model is gpt-5.6-luna with low reasoning effort, when signed into ChatGPT and that model exists in the catalog; otherwise it uses the current selected model. <sup 5 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/app/thread title.rs L32 </sup You can also explicitly rename the thread by evoking /rename <TITLE and this doesn't cost you anything. However, if you run /rename with no arguments, Codex immediately makes an LLM call requesting a title suggestion. That request uses up to eight recent substantive user/assistant messages, excluding assistant commentary. <sup 6 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/chatwidget/interaction.rs L476 </sup Knowing what's happening Next I took a look at the live activity indicator, to see if it's similar to how Claude Code does it. Turns out it's not. When using a model that supports it, which is any reasoning model, reasoning summaries are always requested along with the actual response. <sup 7 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/core/src/client.rs L998 </sup So Codex piggy-backs the live activity indicator with standard requests. The TUI receives ResoningSummaryTextDelta , accumulates its text, extracts the latest usable line, and sets the status header; there is no separate status-generation request. Codex TUI has a catch-up recap feature that can be invoked explicitly via /recap , but is also automatically enabled by default via tui.auto recap = true . Automatic recaps use the current model, together with the most recent visible changes and recap instructions, resulting in a structured summary and nullable next action fields. The full recap prompt has a byte ceiling corresponding to 8 192 estimated tokens and the currently selected model is the one used for recap. <sup 8 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/tui/src/app/recap.rs </sup Remembering what matters Codex memories are persistent notes carried between sessions - useful knowledge, previous decisions, your stated or implied preferences. Memories can be enabled via /memories option. There are two background stages, and both make additional LLM requests. During the extraction stage the LLM processes an eligible past thread and records useful context, i.e. what you requested, findings, changes, corrections and unfinished work. The v2 prompt explicitly tells is to preserve uncertainty and avoid turning a single task instruction into a general user preference. <sup 9 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/memories/write/templates/memories/stage one system v2.md </sup During the consolidation stage an internal agent combines those records into a compact index, updates preferences and project pointers, and removes unsupported or superseded claims. <sup 10 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/memories/write/templates/memories/consolidation v2.md </sup Extraction generally makes on request per selected thread; consolidation is an agent and can make several. By default gpt-6-luna is used for extraction and gpt-6.1-terra for consolidation, with configurable overrides. You can see your stored memories in ~/.codex/memories v2/ . Keeping watch Finally we have guardian tasks. Guardian is Codex's automatic security and permission reviewer. It evaluates whether an action could cause harm and whether the user authorised its target and side effects. It implements a background classifier, which Codex can launch when an eligible action starts, in order to determine whether the current workflow is high or low risk. It uses gpt-5.6-luna and is just a prompt <sup 11 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/prompts/templates/guardian/classifier instructions.md </sup that returns a high/low classification in the response, and converts the result into a score of 1.0 or 0.0. Additionally there is a seperate internal agent turn that can hold execution while it evaluates the action about to be executed. For example, it makes a judgment whether the action could destroy data or disclose sensitive information, or whether it follows the necessary policies <sup 12 https://github.com/openai/codex/blob/rust-v0.166.0/codex-rs/prompts/templates/guardian/policy template.md </sup The result is a structured output with an allow/deny outcome, optionally with risk level, authorisation level and rationale. The reviewer can actually involve multiple LLM requests, as it reviews, inspects files, and reasons across these. I intentionally left out more explicit features, which include actual response handling the thing that actually builds your code , as well as context compaction. Note that with compaction if you have background compaction enabled, compaction will start ahead of the foreground limit and generate candidates in parallel. Understanding where the tokens go is important both for better understanding of the billing and why you are hitting rate limits, but also in terms of being in control, wherever possible, of your agentic harness.