Find out what ate your Claude Code or Codex window: a prompt for your own agent

Find out what used up my Claude Code and Codex allowance. Read only the session logs on this machine, and send nothing anywhere.

1. Do not read the log files into this conversation. Write one small script (Node.js or Python, whichever is installed) in a temporary folder, run it, and let it print a short report. That keeps this check cheap.
2. Claude Code logs are the .jsonl files under ~/.claude/projects/, including the subagents/ folders inside each session folder. Each line with "type": "assistant" has message.usage with input_tokens, cache_creation_input_tokens, cache_read_input_tokens and output_tokens, plus timestamp, sessionId, cwd, isSidechain and message.model. One request can appear on several lines: count each requestId once.
3. Codex logs are the .jsonl files under ~/.codex/sessions/. Each event whose payload.type is "token_count" has payload.info.last_token_usage (the tokens for that call) and payload.rate_limits, whose primary and secondary used_percent show how full each window was at that moment. The session's folder is payload.cwd in the session_meta event, and the model is payload.model in each turn_context event.
4. Look at the last 7 days unless I name another period. Report:
   - for each tool, the 10 sessions that used the most tokens, with the project folder, start time, number of requests, model, and tokens split into new input, cache writes, cache reads and output;
   - the 10 single requests that used the most, with their session and time;
   - for Claude Code, how much came from subagents (isSidechain) compared with the main conversation;
   - for Codex, how many percentage points each of the heaviest sessions moved each window, from used_percent before and after;
   - any request that came more than an hour after the previous one in the same session with a large cache write, which is usually a long conversation re-read after a break.
5. Read only usage numbers, timestamps, model names and folder names. Do not open or print anything I or the agent wrote.
6. Finish with three plain sentences: what used the most, the likely reason, and one change to try. If long conversations are the reason, the change is a short handoff note and a fresh session, not /compact, which itself re-reads the whole conversation. Say that token counts are not the same as the percentage of a window, because the vendors weight models and cache reads differently and do not publish how.

To look at a different period, add it at the end, for example "Look at the last 24 hours" or "Look at 3 November".

We ran the prompt on one of our own machines, with a week of heavy Claude Code use and some Codex, in both tools. In Claude Code it took five turns and under two minutes; in Codex it used between 20,000 and 31,000 tokens across two runs. Both reached the same answer:

• 98 per cent of the week's Claude Code tokens were cache reads: the conversation so far, sent again with every request.
• The ten largest single requests were each close to a million tokens, almost all of it conversation history, from a few sessions that had run for days.
• 27 requests came more than an hour after the one before, in the same session, and re-wrote a large conversation to the cache. Together they made up about two fifths of all cache writes.
• Subagents were about an eighth of the total, and a large share only in a few sessions.

That is the pattern why your limit ran out so fast describes, seen on real logs. Your own report will differ, which is the point of running it.

• Tokens are not the same as the percentage of a window. Anthropic and OpenAI weight models and cache reads differently and do not publish how, so the report tells you where the activity was, not exactly how much of your allowance each part took.
• Cache reads are cheap per token but add up. On Anthropic's API a cache read costs a twentieth of a new input token on Opus 5.5 and Sonnet 5.5 (pricing), yet when every request re-sends a long conversation, they become most of the total.
• For Codex, the percentage points are the closest thing to the real window. Codex records how full each window was after every call, so the report can show how far each session moved it. When sessions overlap in time, they share the movement.
• A large cache write after a long gap is the re-read after a break. If you see many, the fix is a short handoff note and a fresh session when you come back.

Why your limit ran out so fast explains each cause the report can point to, what people do when they run out collects the habits that help, and the tools that make your allowance last covers what to switch on.

Session Forensics is a free page from OpenReason that reads your Claude Code folder (~/.claude/projects) and your Codex folder (~/.codex/sessions) in your browser. Your report is created in the tab, and your files are never uploaded. It lists the limits you hit in the last seven days, with the evidence and when each reset, and for each one the turns that used it up, with their estimated share of the window, their prompt and the files they touched.

Two things it does differently from the prompt. For Codex it reads the meter Codex records in its own files, so the share of the window is Codex's figure; for Claude Code the 5-hour figure is an estimate, because Claude Code's files do not record the meter. And it looks back seven days on the computer you open it on, where the prompt can be asked about any period. It needs a computer, and works best in Chrome or Edge; on a phone it shows an example only.

The prompt answers the question once, on one machine, when you remember to ask. OpenReason Intel, a dashboard for Claude Code and Codex usage, records it as you work: your 5-hour and weekly windows over time from every machine you use, each time a window filled, and the turns that filled it, each with its estimated share of the window.

It shows you what happened; it does not stop a session as you work, and it cannot change your vendor's limits. Unlike the prompt, it does send your usage to OpenReason, which is how it keeps the record across machines.