You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[Bug]: Usage page never scans Codex archived_sessions/, so archived sessions' usage silently disappears #7090
I searched existing issues and did not find a duplicate.
I included enough detail to reproduce or investigate the problem.
Area
apps/server
Steps to reproduce
Use Codex interactively, then archive some sessions (rollouts move from ~/.codex/sessions/ to ~/.codex/archived_sessions/).
Open the Usage page for a window covering that work.
Compare the reported Codex tokens/cost against the transcripts actually on disk.
Observed behavior
UsageService.resolveTranscriptDirs resolves only <codexHome>/sessions for the Codex provider, so rollouts in archived_sessions/ are never scanned — even though the Codex shadow-home layout elsewhere in the codebase treats archived_sessions as a known shared directory alongside sessions.
On my machine the effect is dramatic:
~/.codex/archived_sessions/ holds 2.7 GB, with 148 files modified inside the 30-day window, containing ~6,700 gpt-5.6-sol turn-context records — this is where nearly all of my real interactive Codex work lives.
The scanned ~/.codex/sessions/ retains only ~300 gpt-5.6-sol records; the rest of it is dominated by codex-auto-review traffic (~31,000 model records).
The Usage page therefore reports 177M priced Codex tokens ($131.09) for the window; the true interactive figure is several times that.
Compounding it, codex-auto-review has no LiteLLM rate, so the 885M tokens that are scanned price at $0.00 (the display side of that is tracked in #5799). Net result: Codex usage is doubly understated — most real usage is invisible, and most visible usage is unpriced.
Expected behavior
Usage should cover archived sessions: scan archived_sessions/ alongside sessions/. Transcripts are append-only and the existing mtime filter + (size, mtime) scan cache already bound the cost of the extra walk. At minimum, the page should disclose that archived sessions are excluded from the totals.
Reacted by Nathan Cain, Colin Morris, Ted Mader and psick22
The codex-auto-review being left without pricing makes the raw token cost tracking questionable as that model isn't cheap and I have coworkers telling me it burns through there limits. Impossible to verify without detailed price tracking to know how much of the token usage is discounted due to caching.
Since #34829, this affects all delegated Codex work by default, not only sessions a user archives. T3 now calls thread/archive on each finished delegated Codex child, so Codex moves that child's rollout into archived_sessions/. codexUsageReader.directories still returns only <CODEX_HOME>/sessions, so the Usage page stops counting the child's usage.
On our install, running nightly 4606 since 2026-11-13, there are now 132 rollouts in archived_sessions/. Every one of them was written by T3 for a delegated child. Over the same period, 42 new rollouts stayed in sessions/.
As a local workaround, we return archived_sessions as a second directory from codexUsageReader.directories, after sessions. The usage summary already removes duplicate Codex records across files (sharedSessionsAcrossFiles), so a rollout that was scanned in sessions/ and then moved still counts once.
A test covers this:
Scan a 17-token rollout.
Move it into archived_sessions/ and add a 23-token rollout that only exists there.
The total is 40 tokens, both before and after a restart.
#21666 covers more cases than this workaround, but its automated pipeline stopped.
Measured and written by Claude (Opus 5.5) in T3 Code; posted with the owner's approval.
Activity
nathanscain commentedon Aug 20, 2026
+1
The
codex-auto-reviewbeing left without pricing makes the raw token cost tracking questionable as that model isn't cheap and I have coworkers telling me it burns through there limits. Impossible to verify without detailed price tracking to know how much of the token usage is discounted due to caching.tlmader commentedon Sep 4, 2026
I really want to know my actual Codex API spend without unarchiving all of my chats 😆
Dropje97 commentedon Nov 14, 2026
Since #34829, this affects all delegated Codex work by default, not only sessions a user archives. T3 now calls
thread/archiveon each finished delegated Codex child, so Codex moves that child's rollout intoarchived_sessions/.codexUsageReader.directoriesstill returns only<CODEX_HOME>/sessions, so the Usage page stops counting the child's usage.On our install, running nightly 4606 since 2026-11-13, there are now 132 rollouts in
archived_sessions/. Every one of them was written by T3 for a delegated child. Over the same period, 42 new rollouts stayed insessions/.As a local workaround, we return
archived_sessionsas a second directory fromcodexUsageReader.directories, aftersessions. The usage summary already removes duplicate Codex records across files (sharedSessionsAcrossFiles), so a rollout that was scanned insessions/and then moved still counts once.A test covers this:
archived_sessions/and add a 23-token rollout that only exists there.#21666 covers more cases than this workaround, but its automated pipeline stopped.
Measured and written by Claude (Opus 5.5) in T3 Code; posted with the owner's approval.