What they did
Hossain saw his Claude Max weekly meter at 2% a few hours after the reset, though he had barely worked. He did the investigation with Claude Code. It summed the token usage recorded in every local session transcript since the reset, checked the Claude Desktop usage history file to confirm the meter was real, then turned to the one background process he ran: the claude-mem memory plugin, whose observer runs without writing transcripts. They queried the plugin's status endpoint, read its logs to rebuild the overnight timeline, and inspected why each observer turn was so large. Claude Code then helped him write the fix, replay it against stored Edit results, and get the tests passing.
How it went
His own sessions explained about 0.26% of the limit. The plugin had paused near the old week's cap, buffered over 3,000 tool calls, and replayed them after the reset: 677 observer turns in one hour, with a queue of 2,080 still waiting. A trim that strips whole files out of Edit results had silently stopped working after a Claude Code update added two boolean fields. The patch took tests from 4 of 6 passing to 6 of 6 and raised trimmed results on 639 real samples from 29 to 168. The maintainer merged it about 15 hours after the issue was opened. He then uninstalled the plugin anyway.
Worth knowing
Any background tool that runs on a subscription spends the limit while you are away, and work paused near a cap is still billed later. The gap between the meter and your own transcripts is the clue: look for whatever is not writing logs. Other users reported far larger usage from the same plugin, which he did not verify.