[BUG] Abnormal Usage Consumption on Claude Code Session Resume — Possible Bug

Found 2 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/27869
2. https://github.com/anthropics/claude-code/issues/36539

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

This is related but not a direct duplicate. My case involves Notion MCP cache layer + multiple CLAUDE.md files (not Chrome MCP screenshots). The root cause may be the same — accumulated MCP context causing token drain on session resume — but the reproduction path is different. Keeping this open as an additional data point for the engineering team.

I've been dealing with the same thing for 3 days on multiple accounts on multiple platforms. Claude code has been useless. Just has been in a failure loop racking up usage. My one account used its weekly amount just from one message from me, the rest was Claude code failing over and over again, timing out, and trying again. I haven't gotten a legit reply. It's seriously crazy we are paying for their failed connections like it's some kind of usage on the user end we have control of. Why do we get charged for their failure?

I have been experiencing the same issue as well!

Same here. Claude is pretty much useless at the moment. I'm currently at a 25€ plan only and it uses my "current session usage" within 187 tokens while it was "thinking" for 20 minutes straight...

Now I'm getting session limit hit restrictions at 60 percent session limit and 30 percent weekly limit. Claude is so busted right now it's insane

Anthropic's silence on this is pretty damning

@kokemizawa yeah, the resume spike is brutal. The whole context gets re-sent when you load the session, so if you've got MCP caches and multiple CLAUDE.md files piled up, that's a massive token hit before you even type anything.

@gex581990 the failure loop makes it worse. Every retry re-sends the full context again, so a few failed turns can eat more quota than an hour of actual work. Paying for retries you didn't ask for is... not great.

I built a small statusline that tracks burn rate live, mostly because I got tired of guessing: https://github.com/Astro-Han/claude-lens

With the resume issue you can literally see the usage jump the moment the session loads. At least lets you decide whether to kill it and start fresh before it eats more.

Adding another data point — seeing the same abnormal consumption after session resume. Usage jumps even when the resumed session is doing lightweight work.

What helped my workflow: routing the routine stuff (file ops, grep, test reruns) through cheaper models automatically so my Claude quota only gets used for actual reasoning. Brought my effective daily consumption down enough that I stop hitting walls.

Not a fix for the underlying bug, but keeps you productive: https://dev.to/sophiaashi/claude-code-rate-limit-on-max-plan-the-workaround-developers-are-actually-using-in-2026-16g2

Can confirm. DISPATCH IS BUGGED. Bloats context and burns tokens.

Today i had claude code sessions spawn by opening the tab, it re-read message from 2 days ago. Probebly lag due to a giant 3 days context window. Burned 20% session limit by opening the dispatch tab.

The root of the problem is by design. The dispatch session growing over time.

"Instead of starting a new session for each task, you have a single persistent thread with Claude. This thread doesn't reset—Claude retains context from previous tasks, so you can pick up where you left off."

As far i know. You cannot reset, clear, delete or create a new dispatch session. Its a cowork session in the cloud, the only way to delete it is contact privacy@anthropic.com?

Here my top 5:
Modell | Input | Output | Cache Create | Cache Read | Total | Cost
-- | -- | -- | -- | -- | -- | --
opus-4-6 | 9,239 | 315,742 | 5,288,554 | 383,860,527 | 389,474,062 | $279.37
opus-4-6 | 997 | 154,285 | 861,267 | 158,210,081 | 159,226,630 | $99.59
opus-4-6 | 889 | 66,502 | 973,940 | 128,765,225 | 129,806,556 | $78.77
opus-4-6, haiku-4-5-20251001 | 47,276 | 52,590 | 1,194,160 | 8,928,380 | 10,222,406 | $5.89
sonnet-4-6 | 126 | 32,227 | 136,449 | 10,683,804 | 10,852,606 | $4.20

How did i input 9k or 49k tokens? Im way to lazy for that, my input is like "yes, fix that", "docs that", "change this".
Must be a session reload that gets interpreted as user input.

Same here. Is it only related to the Max Plan?

Is it only related to the Max Plan?

no. reports spread cross all tiers. Some probebly linked issues.

They keep on doing it, even if you pay $280 for a Max 20x and consume zero tokens, they will still block you so you open the faucet of "Keep working even if you hit your limits", it is absolutely unethical https://github.com/anthropics/claude-code/issues/38910#issuecomment-4134768536

The resume-time spike happens because Claude Code re-sends the full JSONL on resume — if the session accumulated a lot of tool output, file reads, and progress bar noise over its lifetime, the input token flood on resume is real and expensive.

We built Cozempic to solve this: cozempic treat --session <id> before resuming deflates the history by stripping the noise while keeping the semantically important turns. The SessionStart hook can also fire automatically on every resume so the treatment happens before Claude sees the session.

Open-sourced it because this pattern — an expensive resume from a previously cheap session — kept catching us off guard on long Opus 4.6 runs. Happy to hear if it helps.

Two hooks that help detect and mitigate this pattern:
1. resume-context-guard — Notification hook on SessionStart
Checks if a previous session state file exists (indicating resume). If the tool call count exceeds a threshold (default: 100), warns immediately:

INPUT=$(cat)
STATE="/tmp/cc-tool-count-$(echo "$PWD" | md5sum | cut -c1-8)"
if [ -f "$STATE" ]; then
    COUNT=$(cat "$STATE" 2>/dev/null || echo "0")
    if [ "$COUNT" -gt "${CC_RESUME_WARN:-100}" ]; then
        echo "⚠ LARGE SESSION: $COUNT tool calls. Run /compact before continuing." >&2
    fi
fi
exit 0

2. output-explosion-detector — PostToolUse hook
Tracks cumulative output size. Warns when a single response exceeds 50KB or session total exceeds 500KB:

INPUT=$(cat)
OUTPUT=$(echo "$INPUT" | jq -r '.tool_output // empty' 2>/dev/null)
[ -z "$OUTPUT" ] && exit 0
OUTPUT_LEN=${#OUTPUT}
if [ "$OUTPUT_LEN" -gt "${CC_OUTPUT_WARN_SINGLE:-50000}" ]; then
    echo "⚠ LARGE OUTPUT: $(( OUTPUT_LEN / 1000 ))KB in one call." >&2
fi
STATE="/tmp/cc-output-total-$(echo "$PWD" | md5sum | cut -c1-8)"
CURRENT=$(($(cat "$STATE" 2>/dev/null || echo "0") + OUTPUT_LEN))
echo "$CURRENT" > "$STATE"
if [ "$CURRENT" -gt "${CC_OUTPUT_WARN_TOTAL:-500000}" ]; then
    echo "⚠ SESSION OUTPUT: $(( CURRENT / 1000 ))KB total. /compact recommended." >&2
fi
exit 0

These don't prevent the root cause (which appears to be a bug in session resume logic), but they provide early warning so you can /compact or start fresh before costs spiral. Both available via npx cc-safe-setup --install-example resume-context-guard.

I got two pro accounts and things are so bad right now that I've even had Sonnet model do a simple task, literally after a minute I hit limits so it didn't finish it. So I wait hours....try again AND IT STILL COULDN'T FINISH THE TASK. I literally only asked it remove all source files that contained certain "#include" files. If chatgpt wasn't so god awful I'd just switch to that. Tho, Qwen3.5-Coder is look pretty damn good. And the kicker is........that's FREE lmao. I decided to mess with it since this whole mess started a week ago and yeah......Claude is getting to be less worth it especially when they take our money and give next to nothing in return. Also the fact their customer service is garbage (any issue I've had it takes them a month to reply, then they just send FAQ info and a "guide to manage your usage", like we can control anything on their end...) and literally refuse to comp anyone.........I still would like to use Opus for more complex code foundations but I'm really running out of reasons to give them money especially when they disrespect customers.

Today’s date is 30‑03‑2026. I am also facing a similar issue. I waited for my current session usage to go back to zero, and then I was just watching a YouTube video in the desktop app. Suddenly I saw that my usage jumped to 37%, even though I hadn’t sent a single message during that time. I have no idea why that 37% token usage happened. Is there any fix for this, or should I be worried that my system might have been compromised for a moment?

I am also watching this carefully. My session usage was at 58%, then I just sent a single message saying “hi,” and Claude replied with “hi, what do you need?” — but that alone used another 1% of the session. This feels really bad.

Still having this issue.

I cancelled my subscription back to OpenAI I guess. I was able to get 10 messages in using Sonnet for brainstorming, then swapped to Opus to do the code edits. Opus made one change, then I made a suggestion and got hit with the rate limit. It is completely useless now.

cancelled my plan, it worked fine on Pro up to a few days ago. hit with usage limits every few hours even though i use /clear after every small task. have to walk away and come back to finish my workflow. claude says no

if you couple that with the leaking source code. it seems like claude has some employees trying to destroy the company internally!

Do you think this is related to Notion MCP? I’m also using Notion MCP and experiencing the same issue.

ngl that sounds awful, resuming the claude business session and seeing 652,069 output tokens with no prompts is a clear bug. tbh wozcode cut my token spend about 50% with better caching, might help while this gets looked at https://wozcode.com