## What happens

On every agents-panel refresh, `omarchy-agent-usage-codex` re-parses **every**
`~/.codex/sessions/**/*.jsonl` file modified in the last 30 days, from scratch.
With a normal amount of Codex history this turns into a recurring, visible CPU
spike — `omarchy-agent-u*` sitting at 100% of a core for about a minute, every
15 minutes, indefinitely.

Measured on this machine (AMD Ryzen AI 9 HX PRO 370, 24 threads, Python 3.14.7):

| | files in 30-day window | wall | user CPU |
|---|---|---|---|
| `omarchy-agent-usage-codex --force` | 1468 files / 7.8 GB | 56.9 s | **54.8 s** |
| `omarchy-agent-usage-claude --force` | 919 files / 440 MB | ~2 s | ~2 s |

99% CPU-bound, not I/O-bound.

## What I expected

A periodic stats refresh that costs roughly nothing, because Codex session
files that belong to finished sessions never change again.

## Why it is this expensive

Two things, one cheap to fix and one structural.

**1. No pre-filter before `json.loads`.** The Claude collector skips any line
that cannot be relevant before parsing it
(`bin/omarchy-agent-usage-claude`, in `scan_project_transcripts`):

```python
# Cheap pre-filter before JSON parsing keeps files with unrelated
# lines inexpensive.
if '"usage":' not in line:
    continue
```

The Codex collector has no equivalent — `scan_native_codex_sessions` in
`bin/omarchy-agent-usage-codex` calls `json.loads(raw)` on every line of every
file, then discards everything whose payload `type` is not `token_count`.
Those lines are a small minority of a session transcript.

Adding the matching guard:

```python
for raw in handle:
    if '"token_count"' not in raw and '"turn_context"' not in raw:
        continue
    try:
        entry = json.loads(raw)
```

takes the same run from **54.8 s to 20.9 s of user CPU** (56.9 s → 22.6 s wall),
with byte-identical output — I diffed `todayPrompts`, `todaySessions`,
`todayTotalTokens`, `totalPrompts`, `totalSessions`, `activeDays`,
`modelUsage`, `recentDays` and `todayTokensByModel` between patched and
unpatched runs and they match.

**2. The cache is whole-result and time-bounded, so every refresh is a full
rescan.** `SCAN_REUSE_SECONDS = 20` exists only to dedup concurrent collector
runs, as its comment says:

```
# every periodic widget refresh lands a real rescan, however low
# refreshIntervalSec is set.
```

So even with the pre-filter it is still ~21 s of CPU every
`refreshIntervalSec` (default 900, `shell/plugins/agents/Main.qml`). Because a
closed session file is immutable, a per-file cache keyed on
`(path, st_mtime, st_size) -> per-day/per-model totals` would make steady-state
refreshes proportional to what actually changed — usually one live session —
instead of to the whole 30-day window. The existing
`scan_cache_paths()` / `_cached_local_stats()` machinery looks like the natural
place for it.

The pre-filter alone is a worthwhile standalone fix; the per-file cache is what
makes the cost stop scaling with accumulated history.

## Steps to reproduce

1. Accumulate Codex sessions until `~/.codex/sessions` holds a few GB inside a
   30-day window (`du -sh ~/.codex/sessions`).
2. `time omarchy-agent-usage-codex --force >/dev/null`
3. Compare with `time omarchy-agent-usage-claude --force >/dev/null`, which
   scans a comparable file count with the pre-filter in place.
4. Leave the agents panel enabled and watch `omarchy-agent-u*` in `top` at each
   `refreshIntervalSec` boundary.

## System

- `omarchy version`: 4.0.4-1
- Kernel: 7.2.5-3-omarchy
- Python: 3.14.7
- CPU: AMD Ryzen AI 9 HX PRO 370 (24 threads)

## Workaround, for anyone who lands here first

Move older Codex transcripts out of the scanned roots — note that both
`sessions` and `archived_sessions` are scanned, so the destination has to be
neither:

```bash
mkdir -p ~/.codex/sessions-old
find ~/.codex/sessions -name '*.jsonl' -mtime +3 -exec mv -t ~/.codex/sessions-old {} +
```

Or make the spike rarer without making it smaller:

```bash
omarchy bar set omarchy.agents refreshIntervalSec 3600 --json
```

Disabling the Codex provider in `shell.json` does **not** help:
`providerEnabled()` only gates display, and `omarchy-agent-usage-update` still
forks every collector.

---

Filed by Claude Opus 5 via Claude Code.