[Bug] Unusually High Token Usage and Cost Calculation (Showing 2.8B Tokens / $1,547 for a Single Day)

[Empress7211]

Hi there! First of all, thank you for building and maintaining this amazing tool.

I am writing to report a potential bug regarding token consumption tracking. Today, my CodexBar dashboard displayed an incredibly high usage: 2.8B tokens in a single day, with an estimated cost of $1,547.13 (primarily from gpt-5.4, as shown in the screenshot).

In reality, I have only used about 70% of the weekly quota on my OpenAI Team account today, so my actual usage is nowhere near this number. I suspect there might be a miscalculation or a loop in the token counting logic.

Context & Usage Pattern
To help with debugging, here is my specific usage pattern over the last two days, which might have triggered this behavior:

• Operating Mode: Codex Sub Agent mode
• Main Agent: gpt-5.4
• Sub Agent: gpt-5.4-mini
• Reasoning Effort: xhigh
• Workflow: All my conversations were continuously conducted within a single, long-running session on the Main Agent.

Expected behavior
I'm wondering if using the Sub Agent mode combined with a very long context session and xhigh reasoning might be causing the app to repeatedly count the historical context. It would be greatly appreciated if you could look into this when you have time.

Screenshots

Environment

• OS: macOS Tahoe 26.2
• CodexBar Version: 0.18.0 (52)
• Codex App Version: 26.317.21539 (1088)

Thank you for your time and help!

[iam-brain]

I've looked into this many times, and I have't been able to find hard evidence of over counting. You can have 5.4 analyze your own usage yourself.

[josephyooo]

Adding a data point from Claude.

Environment

• Plan: Claude Max
• Usage type: Heavy agentic sessions (Opus 4.6 Max)
• CodexBar version: 0.19.0

What I'm seeing

CodexBar reports 2.7B tokens / $1,605.90 over 30 days for Claude. Meanwhile, Claude Code's own /stats (which tracks input + output tokens from local JSONL logs) shows only ~6M tokens for the same period.

The gap is almost entirely cache read tokens. In agentic sessions with subagents and large context windows, cache reads dwarf actual input/output by 100–900×. A single day (Mar 23) logged 2.61M input+output but 2.37B cache reads in the JSONL files.

Daily breakdown (Mar 20–27)

Date	/stats Input+Output	CodexBar (API dashboard)
Mar 20	~0.5K	2.9M
Mar 21	59K	15.8K
Mar 22	854K	1,489.9M
Mar 23	2.61M	225.2M
Mar 24	193K	91.1M
Mar 25	939K	574.6M
Mar 26	1.55M	291.6M
Mar 27	67K	~6.5M

Why this matters for the reported issue

I think the core of what @iam-brain said is right — CodexBar may not be overcounting. It's faithfully reporting what the API dashboard returns, which includes cache read tokens. The problem is that cache reads are not intuitively "usage" to most users, and displaying them as a single undifferentiated token count makes light agentic days look enormous.

This likely explains the original report too: long-running Codex sessions with subagents and xhigh reasoning will generate massive cache read volumes that are real API-level token counts but don't reflect what most users think of as "tokens used."

Possible UX improvements

• Show cache reads separately from input/output tokens (the way Claude Code /stats does)
• Consider whether the "Tokens per Day" chart should default to input+output only, with cache as an optional overlay

Happy to share raw JSONL data if it would help.

[iam-brain]

Yeah, I should've added that tidbit about the cache reads; it needs to be decided whether or not cached tokens are counted (easy to patch in the current logic). They'll still be counted for the cost readouts, of course, leading to potentially less confusing token usage counts. Adding additional metrics showing the separation would be a better UX