Claude Usage Weekly Report
A local script that parses your Claude usage and writes a weekly cost/consumption report — the raw data that feeds decisions like the Kimi re-price. It is currently failing and needs a one-line fix.
You can’t optimize what you don’t measure — this is the meter. A small launchd job runs
weekly_report.sh, which calls claude-usage-analyzer.py and writes the result to
last-run.log. It’s a local parser: it reads usage data on disk and does not call the Claude API,
so it never draws on your shared usage window.
Operation not permitted trying to open the analyzer script inside ~/Desktop/Claude Usage Reports/.That’s macOS privacy protection (TCC) blocking a background job from reading the Desktop folder — a classic launchd gotcha.
The report hasn’t generated in weeks.
The fix (two clean options)
- Move the script out of a protected folder. Relocate
claude-usage-analyzer.pyfrom the
Desktop into~/claude-usage-automation/and pointweekly_report.shat the new path. Background jobs
can read that folder freely. - Or grant Full Disk Access to the process that runs the job (
cron/launchdor the
Terminal that launches it) in System Settings → Privacy & Security. Cleaner is option 1.
Its place in the loop
This report is the input to the Kimi re-price and to every “are we on the right model” call. When it’s dark,
the meta-loop is flying blind. Getting it green again is what lets the fleet keep pricing itself honestly. Timing note: it fires
around 7 AM, but as a local parser it never touches your Claude quota, so the timing is harmless — if it’s ever upgraded to
call Claude, run it overnight so it doesn’t share a 5-hour window with your own work.