### What variant of Codex are you using? cli ### What feature would you like to see? # Add context token composition breakdown to /status (and optional statusline segment): show absolute tokens and percentage by source, including: - system prompt total - AGENTS.md (root/global/project) total - MCP total, with per-tool breakdown - tool calls total, with per-kind breakdown Even a first version with just system prompt, AGENTS.md, and total MCP would already be very useful Why:

Tokens usage breakdown

Resolved 💬 6 comments Opened Mar 2, 2026 by 0xdeafbeef Closed Aug 5, 2026

💡 Likely answer: A maintainer (etraut-openai, contributor) responded on this thread — see the highlighted reply below.

What variant of Codex are you using?

cli

What feature would you like to see?

Add context token composition breakdown to /status (and optional statusline segment): show absolute tokens and percentage by source, including:

system prompt total
AGENTS.md (root/global/project) total
MCP total, with per-tool breakdown
tool calls total, with per-kind breakdown

Even a first version with just system prompt, AGENTS.md, and total MCP would already be very useful

Why:

Makes context pressure explainable instead of opaque.
Helps identify instruction/tool bloat early.
Makes it easier to decide when to compact, split sessions, or disable heavy MCP/tool surfaces.

Additional information

_No response_

View original on GitHub ↗

6 Comments

ariccio · 5 months ago

If like Claude, this would be quite nice!

oxysoft · 5 months ago

Related broader statusline/airline direction: #14043\n\nThis request already mentions an optional statusline segment. A custom statusline widget API could be a nice long-term fit for richer token/context breakdown displays instead of having to keep adding one more built-in field.

joemerrillis · 5 months ago

Took a look at jeprofl — really clean eBPF/userspace separation with the shared Histogram type in jeprofl-common. The crate boundaries are exactly right.

One thing that jumped out re: your context pressure question: collector.rs is doing a lot of heavy lifting. It bundles eBPF map polling (spawn_collector), per-CPU histogram aggregation (merge()), and three output formats (pager text, CSV via CsvWriter, flamegraphs via write_flame_graph) all through EventProcessor. That's 419 lines where an AI agent trying to touch flamegraph rendering (~80 lines of actual relevant context) has to ingest the full PerCpuHashMap<MapData, HistogramKey, Histogram> types, blazesym resolver, and CSV writer — none of which matter for that task.

Concretely, if you split EventProcessor into collection (owns the aya map polling) and rendering (owns output formatting), an AI tool could load just the rendering half for output changes. That alone cuts the context needed for flamegraph work from ~350 tokens to ~80 — a 4.4x reduction.

Also noticed ~30 lines of commented-out code in the eBPF probe (update_counter at lines 114-131, dynamic arg index at lines 36-48) that's adding noise to any analysis pass.

I mapped out the full dependency graph and blast radius for every function — you can see the interactive breakdown here: https://seshat.papyruslabs.ai/demo/121

The structural analysis behind this is from Seshat (https://seshat.papyruslabs.ai) — it builds a typed symbol graph so you can ask "what's the minimum context for modifying X" instead of feeding entire files to your AI tools.

blain3white · 2 months ago

I'm building Clean My Agent as a local desktop app that reads Codex session files and shows per-session token usage breakdowns — might be a useful reference while this is tracked natively.

etraut-openai contributor · 23 days ago

Desktop now shows detailed per-chat and historical usage breakdowns.

kdawgwilk · 22 days ago

@etraut-openai where can that be seen? This is what this issue is asking for and I still don't see a way to see the context window usage in Codex