What happened
Lucian of lucianLabs says he inspected Codex session logs stored as JSONL files under ~/.codex/sessions. They contain what was sent to the model and token usage recorded for each response. The analysis covered 12 real sessions on one computer. For the first call in three freshly started sessions, he measured roughly 12,000 tokens from instructions added by the Codex app, 5,000 from base instructions and 6,000 from the skill list. Other parts, including tool definitions, account for the remainder of the roughly 33,000 tokens present before a user message. The author says users cannot reduce that remainder through the changes discussed.
Those figures are not all measured in the same way. Codex’s recorded usage gives the measured token totals. To estimate how much of the context came from specific items such as skill bodies or tool output, the analysis uses the size of each item left in the session log, converting bytes to tokens at four bytes per token. Comparing estimated growth with measured context growth produced a match of about 0.85; the author says the estimates are therefore about 15% lower than reality. The report distinguishes estimates from measured usage rather than treating the breakdown as a direct token count.
Across the sessions, tool output accounted for more than half of context during work, according to the analysis. Reading a file or running a command adds its output to context; reading a large file in full sends the whole file. Skill descriptions were a small cost: one description used 39 tokens per session. A skill body read 19 times used 36,000 tokens. The result challenges the intuitive focus on trimming descriptions or simply reducing the number of skills: frequently used long bodies and whole-file reads were larger opportunities in this sample.
The accompanying Codex Token Xray tool lists skills not read in the last 90 days and lets users choose which to delete. It backs up the folder as a zip and offers a restore command; skills written by the user are not deleted by the tool. For skills and project AGENTS.md files, it recommends keeping frequently needed material in the main file and moving occasional details into reference files. It shows a diff and asks for confirmation before making changes, and preserves sensitive or consequential rules such as those covering production, secrets, deployment and irreversible actions. It does not edit third-party skills, built-in skills or plugins, or alter model, approval, sandbox, hook or MCP settings. Changes affect new sessions, not sessions already open.
What the archive adds
New Runtime’s earlier coverage on token efficiency for longer agent runs noted that Cursor’s reported 7% token-cost reduction pointed to harness design as a cost lever. This is a new fact on the broader story: a Codex session-log analysis identifies which context components may be worth trimming, rather than reporting a product-level cost reduction.
Trend signal
This supports agent economics moves to completed work in a limited way: context efficiency depends on harness and workflow choices, not only model selection. The analysis does not measure cost per verified task or show that the proposed edits improve task economics; it identifies likely sources of avoidable context growth in one user’s sessions.
Why it matters
Teams often respond to rising context use by deleting skills or shortening their descriptions. This analysis suggests that can target the wrong part of the system: the initial skill list is a real fixed cost, but descriptions were tiny compared with a frequently read skill body, while tool output was the largest share during work. Builders can use that distinction to prioritize audits: find which long instructions are repeatedly loaded, move occasional guidance behind references, and avoid sending whole files when a relevant range will do.
The trade-off is not simply fewer tokens. Skills and project instructions can encode safety-critical constraints, and the tool itself preserves rules around secrets, production and irreversible actions. Any reduction should retain those protections and be reviewed against real tasks. The findings are useful as a measurement method and a hypothesis for local tuning, not as a universal estimate of Codex overhead or a promise of savings for every team.
Limits and uncertainty
The sample is 12 sessions from one computer, with only three freshly started sessions used for the first-call breakdown. The component split is estimated from log contents, not directly recorded token attribution; the author reports a roughly 0.85 match to measured context growth and an estimate about 15% below reality. The report does not establish how representative these sessions are of other Codex configurations, users or workloads, nor quantify cost savings or task-quality effects from the suggested cleanup. The measurements are the author’s analysis, not an independent audit.
Skill to build now
This week, inspect a few of your own Codex session logs and identify long skill or AGENTS.md content that is repeatedly loaded but only occasionally needed. Move that occasional material into a referenced file, then compare new-session context use and check that safety-critical rules remain intact. For large files, try reading only relevant line ranges or searching with rg before opening the whole file.
Reader takeaway
Do not assume skill descriptions are the main source of Codex context overhead. In this small analysis, repeated skill bodies and tool output mattered much more once work began; measure your own sessions, trim selectively, and preserve the rules that constrain consequential actions.