Repository navigation
[Feature]: Customizable Codex status bar with input, output, and cache hit rate #132
Description
Preflight checklist
- I searched existing issues and didn't find this request.
- This fits the project's scope (Claude-only, lightweight, token-attribution focused).
What problem would this solve?
I'm using Claude Code Usage primarily to monitor OpenAI Codex directly from the VS Code status bar.
Currently, the Codex status bar supports only one usage metric at a time: Processed, Uncached, or Output. To see the other metrics, I have to hover over the status bar item or open the dashboard.
My preferred workflow is passive monitoring while coding. I would like to see three key metrics simultaneously without interacting with the UI:
Input tokens
Output tokens
Cache hit rate
All other detailed metrics can remain in the existing tooltip or dashboard.
Proposed solution
Please add an optional, configurable Codex status-bar usage template.
For example:
CX | In 8.2M | Out 520K | Cache 86%
Ideally, users could configure a template such as:
CX | In {input} | Out {output} | Cache {cacheHitRate}%
Suggested placeholders:
{input} — Input tokens, including cached input
{output} — Output tokens
{cachedInput} — Cached input tokens
{cacheHitRate} — Cached input / total input × 100
{processed} — Total processed tokens
The displayed values could follow the existing status bar's daily aggregation scope.
A few implementation preferences:
Keep the current status bar behavior as the default for backward compatibility.
Make the custom format optional, ideally through the extension's Settings dashboard.
Reuse existing Codex usage aggregates rather than adding file scanning, polling, or API requests.
Keep the existing hover tooltip and dashboard functionality unchanged.
Handle missing or incomplete metrics gracefully, without displaying misleading percentages.
Performance is especially important for users with large local Codex session histories. This feature should ideally be presentation-only, with negligible additional CPU or memory overhead.
Alternatives you've considered
The existing Processed, Uncached, and Output options each display only one metric.
Hovering over the status bar item works, but it interrupts the passive monitoring workflow.
I also considered developing a separate status bar extension, but that would duplicate Codex log processing and add unnecessary background resource usage.
Extending the existing status bar renderer would provide a cleaner and more maintainable solution.
Anything else?
The existing quota formatting template introduced in PR #108 is a useful precedent for this feature. A similar optional template system for Codex token metrics would be a natural extension.
This is not a request for additional data collection or an expanded dashboard. The primary goal is to make existing usage metrics more visible in the VS Code status bar.
Thank you for considering this improvement!
Activity
github-actions commentedon Oct 15, 2026
🤖 Automated first-pass reply
TL;DR
The feature sits entirely in the status-bar presentation layer (
src/statusBar.ts/src/codexStatus.ts) and can reuse the existing Codex daily aggregates — no new scanning, polling, or API calls are required, so it fits the project's local-first, token-attribution-focused scope. The main design questions to settle before implementation are: the exact placeholder names and semantics, where the template is stored/validated (Settings dashboard +SETTINGScatalog insrc/settings.ts), and backward-compatibility of the current single-metric modes.Analysis
src/statusBar.tsowns token/cost/quota/context presentation and that Codex metrics already exist as materialized aggregates.AGENTS.md): processed =input + output; cached input is a subset of input, never additive; cache hit rate should becachedInput / input(not/ processed) and should be suppressed rather than shown as0%orNaNwhen input is zero or the metric is unavailable.SETTINGScatalog and any new user-facing copy must go throughI18nacross all eight locales.Suggested next step(s)
{input}includes cached input (the issue text says yes) and whether{cacheHitRate}iscachedInput / inputorcachedInput / (input + output); I'd default tocachedInput / input.–), since the issue asks to avoid misleading percentages.SETTINGScatalog, defaulting to the current single-metric behavior.If you'd like, I can point at the precise functions after you confirm the semantics above; I did not need to read additional source files to answer this triage.
🤖 Generated by DeepSeek as an automated first pass — not a maintainer decision.
Carl723000 commentedon Oct 15, 2026
Thanks @ZYQ-2020 — the passive-monitoring use case is clear and fits the existing presentation layer. This is not implemented in 2.5.0: the current Codex status item still selects one of Processed / Uncached / Output, with additional metrics in its tooltip/dashboard.
Keeping this as an enhancement request. A bounded follow-up can reuse today's existing aggregates, keep the current default, and add an optional template in the Settings dashboard without new scans, polling or API requests. The proposed
{input}would include cached input;{cacheHitRate}would use cached input / input, never / processed, and unavailable or zero-input data must not become a misleading percentage. Placeholder validation and unknown/partial-data behavior need tests alongside the existing tooltip and provider-switch behavior.The template approach is consistent with the existing quota-format precedent. No delivery date is promised here; the issue remains open for implementation planning. The older Claude-only wording in the issue checklist does not reflect the current multi-provider product scope.
🤖 Generated by OpenAI Codex as an automated first pass — not a maintainer decision.