chronicle-quota-check

Is something in the ChatGPT desktop app quietly spending your quota while you're not using it? Find out in about three seconds.

Full write-up (70-day timeline, controlled on/off data, raw logs): https://machblink.com/chronicle

A read-only shell script that surfaces every local trace of the background screen-capture summarization pipeline in the ChatGPT desktop app for macOS (the "Chronicle" research preview, and its successor "Computer History").

No dependencies. No network calls except one optional request to OpenAI's own usage endpoint, using the token already on your machine. Nothing is modified, nothing is uploaded, nothing is phoned home.

---

Why this exists

"My Codex/ChatGPT quota drains while the app sits idle" has been reported many times since May 2026. The reports are real, but the answer people usually get is "check your usage page" — and the usage page is precisely where this particular consumer does not appear.

On my machine the pipeline ran for at least 70 days. Over the 8 days still covered by my local logs it captured 82,791 screenshots and made 6,002 background model calls. I could not find it by asking ChatGPT, by contacting official support, by signing out of all devices, or by deleting and reinstalling the app. I found it by reading local logs and Time Machine snapshots.

This script is the shortcut, so nobody else has to do that.

---

What it checks

---

You do not have to download anything

The point of this repository is that software should not do things on your machine that you have not looked at. It would be inconsistent to then ask you to run a stranger's script. So here is every check as a command you can read and paste yourself. All read-only.

# 1. Is it running right now?  (no output = no)
pgrep -lf codex_chronicle

# 2. What does the config say?  (look for chronicle = true)
grep -A3 '^\[features\]' ~/.codex/config.toml

# 3. Screenshot cache size, and files written in the last hour
D="$(getconf DARWIN_USER_TEMP_DIR)chronicle"; du -sh "$D"; find "$D" -type f -mmin -60 | wc -l

# 4. How many background summaries are on disk
ls ~/.codex/memories/extensions/chronicle/resources | wc -l

# 5. Frames captured and model calls per day, from your own logs
for d in ~/Library/Logs/com.openai.codex/*/*/*/; do
  f=$(grep -ahc 'wrote sparse memory frame' "$d"*.log 2>/dev/null | awk '{s+=$1}END{print s+0}')
  [ "${f:-0}" -gt 0 ] || continue
  c=$(grep -ahc 'starting codex exec summary session' "$d"*.log 2>/dev/null | awk '{s+=$1}END{print s+0}')
  echo "${d#*com.openai.codex/}  frames=$f  calls=$c"
done

Command 5 is the important one. wrote sparse memory frame is a captured frame; starting codex exec summary session is a model call billed to your quota.

Prefer to have your own assistant walk you through it? Paste these and ask it to explain the output — but ask it to run and explain these exact commands, not to write its own. Those two event names came from reading real log files; an assistant guessing from general knowledge will get them wrong and report that everything is fine.

Or run the script

Same checks, formatted output, plus consent flags, the disabled-but-still-running cross-check, and an optional quota sample.

curl -O https://raw.githubusercontent.com/hankwangtw/chronicle-quota-check/main/chronicle-quota-check.sh
less chronicle-quota-check.sh     # read it first
bash chronicle-quota-check.sh

There is deliberately no curl … | bash one-liner.

Options:

bash chronicle-quota-check.sh --usage      # also sample your official quota
bash chronicle-quota-check.sh --days 30    # scan 30 days of logs (default 14)

Sample output

== Live background processes ==
  ✗ codex_chronicle is RUNNING right now

== Codex config (~/.codex/config.toml) ==
  ✗ features.chronicle = true (screen capture pipeline ENABLED)

== Log evidence, last 14 days ==
  · 2026-08-26   frames captured: 5539    background summary calls: 1450
  · 2026-08-25   frames captured: 3521    background summary calls: 2986
  ✗ totals: 23047 frames, 6033 background model calls across 8 day(s)

---

How to turn it off

1. Turn Memory off under Settings → Personalization. This is what worked on my machine, and it is first here for a reason: the dedicated Chronicle page only exists while the feature is enabled, so by the time you go looking for it, it may already be gone. The Memory toggle is always there.

   Verified on my machine: the app logged sidecar state changed … next=disabled previous=running and screen recording shutdown requested at the moment I toggled it, and no capture event has been logged since.

   The cascade is one-way. I turned Memory back on 49 minutes later; the config now reads memories = true with chronicle = false, and capture did not resume. So you do not have to give up Memory permanently to stop this.

2. If the Chronicle / computer-activity page is present, you can also disable it there directly.

3. Verify it actually stopped. Setting the config flag is not always enough (#27773):

   pgrep -f codex_chronicle      # no output = not running
   

   If it still prints a PID after you have quit the app, terminate it with pkill -f codex_chronicle, then re-run this script.

4. Confirm the next day. Today's frame count should be zero.

---

What the numbers mean, and how confident I am in them

Every figure here is labelled, because the difference matters.

Blind spots I know about: local logs rotate after roughly two weeks, so absence of old evidence is not evidence of absence. I have no visibility into server-side accounting; my causal evidence is behavioural — the drain stopped when the feature was disabled and has not resumed.

---

Prior reports

I am not the first to point at this. These came before me and deserve the credit:

• community.openai.com #1380250 (May 3) — disabling Memories stopped the drain
• community.openai.com #1380899 (May 14) — 572 background summaries in one night. Zero replies to date
• openai/codex#23124 (May 17) — quota consumed with no UI control to disable
• openai/codex#26808 (Jun 6) — 138,835 tokens in a single consolidation pass
• openai/codex#27773 (Jun 12) — names the codex_chronicle process directly
• Also: #26600, #28687, #28694, #30081, #30525, #31165, #41617
• This report: openai/codex#42282 (Sep 2, 2026) — attribution gap + this script. If the check shows the same on your machine, add your numbers there.

What I am adding is a longer measured timeline, a controlled before/after, and a tool you can run yourself.

---

FAQ

"You opted into a research preview. What did you expect?" Fair, and OpenAI did disclose the cost — the original Chronicle documentation had a Rate limits section stating the background agents "consume rate limits quickly." The gap this script addresses is not disclosure, it is observability: once running, the consumption appears in no usage surface, no per-conversation breakdown, and no local token record. You cannot see it, so you cannot attribute it, so you cannot make an informed decision about it.

"n=1. How do you know this is widespread?" I don't, and I don't claim it. Chronicle was opt-in, and I have no data on how many people enabled it. What is documented is that idle-drain complaints are common and that this is one confirmed mechanism behind some of them.

"Didn't OpenAI already fix this?" On Aug 23 the Codex lead publicly identified high p95 usage in Computer History — Chronicle's successor — among other causes, and fixes plus a full usage reset followed on Aug 24. That fix concerned the newer system. On this machine, the older screenshot pipeline was still running on Aug 30, seventeen days after the successor shipped. Run the script and see which one you have.

"Is this safe to run?" It is read-only. The only write it performs is to your terminal. The only network request is optional and goes to chatgpt.com with your own local token — the same call the app makes. Read it first; it is short.

---

Full write-up

The complete 70-day investigation — timeline, methodology, log excerpts, support transcript, and the before/after measurements — is here: machblink.com/chronicle

License

MIT. Do whatever you want with it.

Maintained by Hank Wang (@hankwangtw), the author of MachBlink.