Hitting the weekly limit cost me a second subscription - session cost is invisible and the handoff is left to the user
What happened
I am a Max subscriber. I run Claude Code across ~20 projects on one machine, all day, every day.
On 2026-09-12 my main session stopped mid-task on You've hit your weekly limit · resets Sep 14, 11pm. Turn 72. Work in flight. No handoff written — because the session that gets cut off is, by definition, the session that never got to write one.
I could not wait two days. So I bought a second Max subscription.
That is the part I want you to sit with. The product's answer to "your context got expensive" is a ritual the user performs by hand — end the session, write a handoff file, open a new one, tell it to read the file — and when the user doesn't perform that ritual correctly, or can't because the session was cut off mid-turn, the fallback is to pay again.
Then the second subscription cost me more, in three separate ways I had no warning about:
- Switching accounts invalidates the prompt cache. Cache read bills at 0.1x, cache write at 1.25x — 12.5x apart. Every session re-paid cache creation on day one. Measured: ~1/3 of that day's entire spend was re-creating cache I already had. Nothing warned me before I switched.
- 55 of my sessions vanished from the sidebar. The transcripts are still on disk, untouched — but the session list is stored per-account (
claude-code-sessions/<account>/<org>/local_*.json), and the new account has its own empty folder. The cards contain no account id, so copying them into the new account folder restores the list — confirmed the next day: the card reappeared in the sidebar after an app restart, with its original title and last-activity timestamp intact. Nothing was ever broken; the UI simply stops showing you your own work, with no explanation and no "these are on your other account" affordance. (The app only re-reads that folder at startup, so the fix costs a restart, which kills every running session.) - I had to parse a 20.7 MB JSONL transcript myself to recover the context of the session that died, because there is no supported way to carry a dead session's state forward.
I paid twice, and still recovered my own context by hand.
Gap 1 — You cannot see what a session costs
/usage reports account totals. There is no per-session number anywhere in the product. So the user has no signal for when the handoff ritual is due — you find out by hitting the cap mid-task.
I only have the numbers below because I parsed ~/.claude/projects/**/*.jsonl myself. That should not be the interface.
Gap 2 — The handoff is manual, and fails exactly when it is needed
There is no "continue in a fresh session" action carrying a summary plus open tasks. /compact is adjacent, but it solves the context-window problem, is all-or-nothing, and leaves you in the same expensive session.
And note the failure mode, because it is not an edge case: a file-based handoff is written by the agent, so the sessions that end abruptly — limit, crash, kill — never write one. Those are precisely the sessions worth recovering. Only the host knows a session is about to stop. This has been raised in #11455 as well.
I have been papering over this for months with a project rule that makes every session write a HANDOFF.md after each work unit. It works — until the day it matters, which is the day it doesn't.
Evidence
Measured from local transcripts. One user, one machine, 2026-09-12 (KST), all projects:
| metric | value |
|---|---|
| assistant turns | 11,795 |
| session files active | 112 |
| cache-read tokens | 2,630M |
| cache-creation tokens | 100.9M |
| output tokens | 20.2M |
The three largest sessions — 589, 825 and 1,059 turns — accounted for ~590M cache-read tokens between them. Every turn re-reads the whole accumulated context. Nothing in the product surfaced that while it was happening.
Across 09-04 → 09-12, daily cache-read ranged 403M to 2,944M for a comparable workload. The variable was simply how many long sessions were open. A user cannot see that ratio, so they cannot manage it.
What I am asking for
- Per-session cost in the UI, and
/usagebroken down by session. - A warning when a session's per-turn cost crosses a threshold — "this session now costs ~N× a fresh one; carry over?"
- Host-triggered handoff. Fire it on limit, crash and abrupt exit — not only when the agent remembers. The host knows; the agent may not get another turn.
- One-action "continue in a fresh session" that carries the summary and open tasks (this is #11455, restated as a cost control rather than a convenience).
- Selective context pruning — drop or summarize old large tool outputs, instead of all-or-nothing
/compact. - Warn before an account switch that the prompt cache will be discarded, and show sessions from the user's other accounts in the sidebar instead of silently hiding them.
Items 1, 2 and 6 are diagnostics and warnings. They should be cheap, and they would have saved me the second subscription.
Closing
None of this is exotic. Every one of these gaps is something the product could close, and every one of them was instead closed by me — manually, or with my credit card.
I am not asking for a discount. I am asking you to stop shipping a paid product whose documented remedy for its own cost curve is "end the session and start over, and remember to write yourself a note first." Is that really the experience you intend to ship to paying users?
Showing cached comments. Read the full discussion on GitHub ↗
5 Comments
Follow-up with what "working around this" actually looks like day to day, plus what I learned while digging — posting the findings in case they save someone else the same archaeology.
What the workaround looks like from here
HANDOFF.md(three lines — done / next / blocked) after each unit of work, and every new session starts by reading it. I wrote that rule because the product doesn't do it. It has been in place for months.That is one user hand-maintaining the continuity layer and the cost dashboard that the product does not ship.
What I learned (in case it helps others on capped plans)
1. A new session is not free. Measured on mine: 82K tokens of context before I type a single word — tool definitions,
CLAUDE.md, memory index. Of that, 48K came from cache (shared with my other sessions) and 33K was created fresh, most of it my memory index. Trimming that index is a real saving, multiplied by every session you open.2. A session's cost is its context size, and you can measure it. The last
assistantentry'susagein~/.claude/projects/**/*.jsonlgivescache_read + cache_creation + input— that is the context that will be re-sent on the next turn. Read the file backwards and it takes ~50 ms per session. That is the per-session number the UI doesn't show.3. Cache read is 0.1x, cache write 1.25x — 12.5x apart. A session with a warm cache is cheap to resume; one whose cache expired re-pays creation from scratch. Practical consequence: step away for an hour and a fresh session is usually cheaper than resuming the old one.
4. Above roughly 300K of context, don't resume — hand off. Resuming a 990K-token session costs ~1.2M tokens of cache creation on the first turn alone. A new session reading a handoff file costs a few KB. On my machine 22 of 54 sessions are past that line, and nothing in the UI says so.
5. Switching accounts loses the sidebar, not the data. Session cards live in
%APPDATA%\Claude\claude-code-sessions\<account>\<org>\local_*.json; transcripts live in~/.claude/projects/and are shared, account-independent. The cards contain no account id, so copying them across accounts should restore the list — I have the cards copied and am waiting on an app restart to confirm, since the app only re-reads that folder at startup. (Restarting also kills every running session, which is its own small tax.)None of the above is documented anywhere I could find. I worked it out by parsing my own transcripts.
Why I'm posting it here rather than a blog
Every one of those five is something the product already knows and the user does not.
I would rather have these in the product than in a forum comment. But until they are, other people paying for capped plans should at least be able to measure what is happening to them — so, above.
Update on item 5, since it now has a definitive answer and it is more useful than what I originally reported.
Moving the session cards across accounts restores the sessions fully — not just the sidebar entry, but the conversation itself.
What I verified, in order:
%APPDATA%\Claude\claude-code-sessions\<old account>\<old org>\local_*.jsoninto the new account's folder. Transcripts stay where they are (~/.claude/projects/, shared).You've hit your weekly limitmessage that had killed it.One correction to what I wrote above: I said the cards carry no account id. That is true of the cards, but the transcript itself does — there is a
bridge-sessionrecord in the JSONL carryingownerAccountUuidandownerOrganizationUuidpointing at the old account. I assumed that would block the resume. It did not. The session reopened and resumed on the new account regardless.Two caveats worth stating plainly, because they are costs:
So the migration path exists and works end to end. It is just made of undocumented folder layout, a mandatory restart that kills every running session, a surprise cache bill, and duplicate entries you have to disambiguate yourself. Every step of that could be a supported "move my sessions to this account" action.
@intermap74 I hope it's okay to ask here, since your profile doesn't list another way to reach you. I'm doing some research for a school project on what happens to the work people do with AI once a session ends, and your write-up of buying a second subscription and then digging a dead session's context out of a 20 MB transcript is honestly one of the clearest accounts I've found. What I'm trying to understand is where that work was headed when the session died, and who needed it next. If you'd be open to a 15 or 20 minute call, I'm at oluwaniifemi.emmanuel@uni.minerva.edu. If writing is easier, I'd mostly like to know what you were working on at the time and who else, if anyone, relies on what comes out of those sessions, and what the hardest part of getting going again was. Thank you either way.
@diegosoek I'm doing some research for a school project on what happens to work people do with AI when a session stops partway, and your point about getting cut off mid-task with no warning is close to what I'm trying to understand. What I'd most like to know is what happened to the work in those sessions when the limit hit, and how you picked it back up afterwards. Would you be open to talking about it at some point, either on a short call or over email at oluwaniifemi.emmanuel@uni.minerva.edu?
Hey @intermap74 — the follow-up you wrote (30-45 sessions/day, 8-12k turns, buying a second Max sub) reads like the most expensive workaround in this thread. The root cause you are fighting is context fill-rate: sessions burn their window on raw MCP tool outputs before the work is done.
I built MCP Shrink (https://updatesbyai.com/mcp-shrink) to attack exactly that: a hosted proxy URL that compresses tool definitions to ~50-token stubs and distills tool responses before they enter context — so each session lasts meaningfully longer before hitting the wall. Works with any MCP client, OAuth passthrough, dashboard shows tokens saved per session.
Free tier = 3 servers, one-line setup. If it stretches your weekly limit even 20 percent, that is a second subscription you do not need to renew. Would love your feedback as someone running your workload.