wheresmytokens.Codex session analyzer
All in your browser
Make sense of your Codex token usage
Dude,
Where Are My
Tokens?
Asked for a tiny fix and the context grew by half a million tokens? The logs remember every step. Let’s take a look.
No sign-upNo log uploads
01
Let’s figure it out.
Open your Codex logs to see your sessions.
Drop your sessions folder here
Or choose a folder, ZIP archive or JSONL files.
Where are my logs?
macOS, Linux, WSL
~/.codex/sessionsWindows%USERPROFILE%\.codex\sessionsArchived sessions~/.codex/archived_sessionsOpen the hidden folder by pasting its path into the file picker’s address bar. On macOS, press ⌘⇧. to show hidden files.
Your files are read only in your browser and are never uploaded.
Totem
Your session totem: its animal, adjective, colors, and rhythm come from the ratios in your logs. Same logs, same totem.
Sessions
All sessions, or selected days using Date range. “% week ≈” estimates this session’s share of the observed weekly counter increase; parallel sessions are not double-counted. “—” means no readings; “*” means some requests have no estimate. Click a heading to sort or a row to open a session.
Click for one day, drag for several days, Shift+click to extend through that day
What would it cost?
The same requests at official OpenAI API prices and as a percentage of the subscription’s weekly limit, when limit counter readings are available in the logs.
At API prices
What these requests would cost if Codex used the API with per-token billing.
Model prices
Dollars per 1M tokens for models in your logs. Reference prices are filled in automatically. You can edit any price; changes are saved in this browser.
What fills the context
Input tokens across all requests, broken down by what was in the context at request time. A command’s output is counted each time it was sent to the model.
Four sources
Share of all input tokens
By category
On the right: the total over the full period in the selected units, its share, and the average number of times each token in the category was resent to the model (×).
Why so much?
The context grows with each agent step, and all of it is sent to the model again. Long sessions with large contexts account for most of the volume.
Context growth in the five most expensive sessions
Input size for each model request; sharp drops indicate context compaction. Click a line or label to open the session.
Large contexts: fewer requests, more tokens
Share of requests and input tokens by request context size.
share of requestsshare of tokens
Models: share of requests and usage
Models used for requests and their usage in the selected units. Click a model to see its sessions in the Sessions table.
share of requests
Auto-review (guardian)
Separate sessions where a model reviews agent actions before execution. Each receives the session history again, which can be costly. Click a row to open the session being reviewed.
Tools
How much text each command type returned and its repeated presence in context. Click a row to inspect commands, the most expensive calls and their sessions.
When and where
By day: input and output
Daily cached input, fresh input and model output in this computer’s time zone. Use Date range in Sessions to inspect any day or range.
cached inputuncached inputmodel output
By project
Session working directory
By model
codex-auto-review — action review model
By hour of day
Total over the full period
Most expensive messages
Your message and every model request the agent made while answering it. Click to open the session at that point.
How it’s calculated
- Tokens for each request come from the usage counters Codex writes to the files
rollout-*.jsonlafter the model replies. Records with the sameresponse_idare the same response and count only once, even if recorded in two files. Session-level totals are not used: they reset on compaction and resume. - The context breakdown is an estimate. Before each request, the context is reconstructed. Model replies and reasoning use exact counts; other content is estimated from character counts (Cyrillic ≈0.33 tokens per character, Latin text and code ≈0.27). The coefficients were calibrated against actual input growth between adjacent requests.
- “Not visible in logs” is the remainder: actual request input minus everything reconstructed from the file. It usually includes the system prompt and tool descriptions; after compaction, it may also include an encrypted summary. Character-based estimation error is included here too. The logs cannot identify its exact components or their proportions, so it is not split further. All request categories always sum to the actual input.
- Auto-review (guardian) uses separate sessions in which a model checks the agent’s actions before execution.
- In the session viewer, cached and uncached input are exact counters for the whole step. Logs do not identify which individual blocks were cached. Block highlights show what was added to context for the selected step. A cache-miss marker appears when cached input is smaller than the input read at the previous step; the log does not state the cause.
- Cumulative totals in the session viewer sum cost, tokens and estimated limit share for all requests up to and including the selected step.
- Date ranges and the By day chart assign requests to days in this computer’s time zone. A multi-day session contributes its corresponding cost to each day. With a date range selected, Tokens, API cost, Requests and % week in Sessions cover only those days; other columns cover the entire session.
- Cost is an estimate at OpenAI API Standard rates, not actual charges or subscription limit usage. Fresh input, cached input and output use their respective prices. Above 272K input tokens, input and cache are multiplied by 2 and output by 1.5. Cache writes (×1.25 for GPT-5.6 and newer) use cache_write_input_tokens from newer Codex logs. Older logs lack it: the base estimate prices new input normally, while the alternative scenario prices all of it as cache writes. Requests with no model price are excluded: “—” marks an unpriced request; “*” marks a partially priced session or day.
- Weekly usage uses the counter Codex logs after responses. Only the seven-day window (window_minutes = 10080) is used, regardless of its position; the five-hour window is ignored. Measured: counter increases between accepted readings across all sessions on one timeline. The first reading is existing usage, not new consumption. Late lower readings are skipped, resets_at changes do not carry increases across windows, and unexplained drops leave a gap. Estimated: allocating increases to requests in proportion to their API cost, hence ≈ on sessions and days. Requests outside two readings get no estimate, which is not zero. All logs are assumed to belong to one account.
- “Sent” in the commands table is the command output size multiplied by the number of requests whose context included it.