Claude Code Limits: Why Your Context Hits the Wall First

The Wall Your Sessions Hit Is Context, Not Quota

Let’s get one thing straight: the average is lying to you. The wall our sessions actually hit was the context window, not a usage cap. Our median session peaked at 86k tokens, but 7 of the newest 28 (25%) reached 400k or more, and the average is the thing hiding that tail. I know how that sounds. I’m telling you the number that makes Claude Code limits look fine is the same number that set me up to get flattened mid-session, twenty-six compactions deep into a single week of work.

Median peak

86k

Maximum peak (newest 28)

760k

Dashed line: red line, 400k

Source: Our own measurements

Here’s the embarrassing part. My first goal was literally “get the median session peak below 400k.” I wrote it, I felt productive, and then I ran the numbers. The median passed on day one. Congratulations to me. A metric that passes instantly is a metric that tells you nothing, so the target became the share of sessions peaking at or above 400k instead. That’s where the pain actually lives.

Measure	Value	Window / source
Median session peak	86k tokens	Newest 28 sessions (session-peaks.py, 2026-10-06)
Sessions at or above 400k	7 of 28 (25%)	Newest 28 sessions
Maximum peak	760k tokens	Newest 28 sessions
Sessions above 400k	7 of 30	Audit, 2026-09-28 → 10-05
Highest peak	782k tokens	Audit, 2026-09-28 → 10-05

Don’t merge those windows, by the way. The audit covers 30 sessions from 2026-09-28 to 10-05; the peak script covers the newest 28 as of 2026-10-06. Different windows, similar tails.

The framing I’ll borrow comes from Faros’ breakdown of Claude Code token limits, which splits this mess into length limits (how long one conversation can grow) and usage limits (how much you can spend across conversations). That split is right, and I’ll push it one step further: the measured wall my own transcripts hit was length, not usage. But I have to be honest about the other half of that sentence. I didn’t measure the quota. The 5-hour and weekly caps aren’t visible from inside a session, so I have no quota numbers, which means I can’t rank one limit against the other. I can only tell you which one actually stopped me, and it was context, every measured time. Am I generalizing from one week of sessions? Yes. Is one week still more than the zero weeks of distribution data in every guide you’ve already read? Also yes.

What We Measured Across 30 Sessions

Here’s what the receipts actually look like. I audited 30 sessions from 2026-09-28 to 10-05, and I need you to sit with these numbers for a second.

26 context compactions. In one week. That’s not a typo. Twenty-six times, the session hit the ceiling and Claude Code squished everything down, which is the moment your model politely forgets what it read earlier in the session and starts confidently inventing. I also typed /compact by hand 14 times, because sometimes I saw the wall coming and tried to get ahead of it. Did that help? Sort of. Compacting is less “save my work” and more “shrink my work until it fits,” and shrinking loses detail every time.

Then there’s the part I’m genuinely embarrassed about. 16 “please resume” prompts. Typed. By me. With my hands. You know the drill: session dies or gets cleared, you stare at the fresh prompt box, and you retype a little novella explaining what we were doing, what’s done, what’s left. I wrote 9 of those handoff summaries by hand. Nine. That’s not a workflow, that’s a cry for help with semicolons.

Which brings me to the goal I fumbled. My first target was “median session peak below 400k.” I ran session-peaks.py over the newest 28 sessions, the median came back at 86k, and the goal passed before I finished my coffee. Do you see the problem? A median passes instantly while a quarter of my sessions are dragging a tail behind them. The real target, the one I should have written from the start, is the share of sessions peaking at or above 400k. That’s the number that was actually ruining my afternoon. Am I being too hard on past me for writing a bad metric? Probably. But he had the data and still picked the flattering number, so.

One honest caveat, because I refuse to be the kind of person who buries it: this record covers one week. Thirty sessions, seven days. That’s a real sample of my own usage and a terrible sample of yours. I’m not claiming population statistics here. What I am claiming is that the shape of the problem is a tail, not an average, and I only found that out because I looked at individual session peaks instead of a summary line.

Next up: why the ceiling numbers in every guide disagree with each other, and with my transcripts.

Claude Code Limits: Why the Ceiling Numbers Disagree

Ask three guides what the ceiling is and you’ll get three different numbers. That’s not a rounding error. That’s the difference between someone quoting a spec sheet and someone actually looking at a transcript. Let’s get one thing straight about which one I trust.

Simplilearn claim

200k

Maximum peak (newest 28)

760k

Highest peak (audit, 30 sessions)

782k

Dashed line: claimed standard window, 200k

Source: Claude’s New Usage Limits: What Developers Need to Know

Source	Claim
Simplilearn	200K standard window on paid plans
UsageBar	Context error when the running total exceeds 200,000 tokens
Damian Galarza	Opus 4.7 has a 1M token window (model-specific)
Our audit	Peaks up to 782k (30 sessions) and 760k (newest 28)

Simplilearn’s guide to Claude’s usage limits states a 200K standard window on paid plans, and UsageBar’s fix guide repeats the same 200,000-token error threshold. Meanwhile, Damian Galarza’s breakdown of the context window says Opus 4.7 carries a 1M token window. So is the ceiling 200K, 1M, or “it depends on the model”? My measured peaks of 782k and 760k blow straight past the 200K claim, which means at minimum that figure is stale for whatever model I was on. Do I get to declare the 200K number wrong? Not cleanly, because I don’t know which model version my sessions ran, and the 1M claim is model-specific anyway. I’m presenting the conflict, not refereeing it. You’re telling me the single most-asked question in this niche has four competing answers and nobody tabulated them?

Your Starting Context Is Already Heavy

Then there’s the part nobody warns you about: the ceiling isn’t where your tokens start. A fresh session is already heavy. The XDA writer measured 51,400 tokens burned before typing a single real prompt, then clawed back about 10k by disabling auto-memory, landing around 41,400. Ten thousand tokens of pure overhead. On an empty session. Doing nothing. Damian’s post adds that the playwright-mcp tool set alone eats about 14.3k tokens, which is 7.2% of a 200K window, sitting there idle before you invoke a single browser action. Run /context on your own setup and see what your starting number is. I’ll wait. It’s higher than you think, isn’t it?

Now, the advice category you’ve definitely already seen: trim the bloat. The DEV Community post about cutting token overhead by 44%, the tokenlimits.app guides on compressing tool outputs by 60-80%. Fine tips. Real mechanics. But they’re all averages again. Trimming 44% of overhead on a session that was going to peak at 760k still leaves you with a session that peaks at 425k, which is still in the tail, which is still the session that compacts and forgets your function signatures. The bloat posts optimize the median. The tail doesn’t care about the median.

So the honest summary is: the published numbers disagree, my own transcripts disagree with the smallest of them, and the only ceiling you can trust is the one you measure on your own sessions. Next up, the 60-minute cache timer that determines whether staying under that ceiling even matters.

The 60-Minute Cache and the Cold-Cache Tax

Let’s talk about the timer nobody can see. The prompt cache is the reason your third turn costs pennies instead of dollars, and it comes with an expiration date: on this plan it lasts 60 minutes, and if you’re in usage overage, it collapses to 5. Go quiet for an hour, come back, and the next turn re-reads your entire context uncached. Full price. Full pause. And here’s the part that genuinely annoys me: you can’t watch this countdown from inside a session, because the mods API reports four token counts with no 1-hour/5-minute split. A mod literally cannot confirm the TTL itself. I only know these numbers because they’re stated in the session’s own system prompt, which is a deeply unsatisfying evidence source. Is it reliable? Probably. Can I verify it independently? No.

First, a quick definition, because “prompt cache” gets thrown around like everyone agrees on it: it’s Anthropic’s mechanism for not re-charging you to re-read the same context every turn. Warm cache, your conversation gets billed at cheap cache-read rates. Cold cache, the whole thing gets processed again like it’s brand new.

What a Cold Cache Actually Costs

To see what “the whole thing” means, look at the docs. Anthropic’s cost management guide walks through /usage with an example session showing 940.0k cache-read tokens. Read that number again. Nine hundred and forty thousand tokens of cache reads in one session. That’s not your prompt. That’s the context you keep re-reading, turn after turn, until the cache dies. And when it dies, that’s the volume getting re-ingested at full price, right before the model answers whatever one-line question you typed.

So warm versus cold isn’t a rounding difference, it’s a cost regime change, plus a noticeable pause while the re-read happens. Which is why the 60-minute window quietly shapes how you should work. If I’m stepping away from a heavy session, I now try to either send something before the hour lapses or end the session deliberately rather than letting it sit there rotting. Is that backed by a measured comparison of warm vs. cold spend on my own sessions? No. It’s arithmetic: the docs’ own example shows the volume, and the system prompt shows the clock. I’m not going to pretend I benchmarked it when I didn’t.

Credit where it’s due, because I didn’t invent this obsession. MindStudio’s context window guide describes the cache window as “around 60 minutes,” and their mods guide includes a countdown mod that displays how much cache time is left. I like their instinct. My problem is that a countdown built on the mods API can’t actually read the TTL, so any number it shows you beyond the token counts is an assumption wearing a UI. Similarly, ClaudeFast notes that /usage flags cache misses once they’re 10% or more of recent usage, which is a checkable tip, and to be fair to my own standards: I haven’t measured that threshold myself either. I’m passing it along, not certifying it.

One practical note: overage changes the math entirely. Five minutes of cache means a coffee run mid-session is a full re-read. If you’re burning through your weekly cap and drifting into overage, that’s when the cold-cache tax compounds with the quota pressure. And I can’t rank that pressure against context, because as I said earlier, the quota numbers aren’t visible from inside a session. Two invisible limits, one visible one. You know which one I built a band around.

The Context Band: Thresholds, Toast, and What It Won’t Do

So the cache timer is invisible, the quota is invisible, and the one number I can see is context. Fine. If the only readable dial is context, I’m putting a gauge on it. Enter the context band, a mod I built on 2026-10-06, and I need to be upfront about what it is: a tool I built and tested, not a proven fix. Six tests pass. Whether it actually changes my session outcomes is a question for later, and I’ll say exactly when later is.

Let’s get one thing straight about what it is. It’s one line above your prompt, and here’s an example of what it looks like (this is an example, not a live readout):

ctx 312k · cache 41 min · ▲ 18k last turn

That’s it. No dashboard, no confetti. It reads the same context number your status line already shows, after each main-thread turn. One quirk I confirmed by testing: subagent turns don’t move it. Your main thread can be sitting at a placid 180k while a subagent is doing cardio in the background, and the band won’t blink. Know that before you trust it.

Condition	What the band shows	What it does
Context below 250k	Plain line: ctx, cache minutes, last-turn change	Nothing
Context 250k to under 400k	Amber	Warns
Context 400k and above	Red	Warns
5 minutes of cache left and context above 150k	One toast	Prompts you to send a prompt or hand off

And directly beneath that table, in text you cannot miss: the band never runs /compact or /clear by itself. It warns. You act. I made this choice deliberately, because an automation that silently squishes your session is an automation that silently deletes your detail, and I’ve already lived through 26 compactions I didn’t ask for. The toast is the same philosophy: when the cache is five minutes from cold and you’re carrying more than 150k of context, it tells you to either send a prompt to keep the cache warm or hand off entirely. What it doesn’t do is decide for you.

Notify-First vs. Andrew Baker’s Automate-First

Now, the contrasting design, because it’s worth naming. Andrew Baker’s pauseless compaction setup compacts at 400k in the background and writes a HANDOFF.md on session close, which is genuinely clever: the compaction happens asynchronously, so you don’t sit through the pause. His approach is automate-first; mine is notify-first. And Baker himself flags the failure mode that makes me side-eye full automation: if the session crashes, no hook runs, and no handoff gets written. You’re telling me my safety net depends on the session dying politely? Make it make sense. I’d rather have an amber warning at 250k and a red one at 400k and be the one who pulls the trigger.

Is this a fix? Not yet, and I refuse to pretend otherwise. The band’s remove-check is on or after 2026-10-20: if 25% or more of my sessions since 2026-10-06 still peak at 400k or above, the band comes off the wall, because a warning nobody acts on is just decoration. Am I attached to it? Sure. But I’d rather delete my own tool than keep a placebo with a nice UI.

One last calibration note: the thresholds are mine, not a spec. Your tail might live somewhere else. Run your own peak script, find your own 400k, and set the band accordingly.

Replacing Hand-Written Resume Prompts with /handoff

Let’s talk about the 16 “please resume” prompts. Sixteen. Typed by hand, in one week, because the session died and I had to explain my own job to a fresh context like I was onboarding a temp. Add the 9 hand-written handoff summaries and you’ve got a genuine workflow problem disguised as muscle memory. So I built /handoff to do it for me, and here’s the whole thing, step by step.

1. Type /handoff in the live session. A forked copy of the session takes over and writes a summary for you: goal, done, owed by Claude, owed by you, and next step. Capped at 25 lines, which I consider a feature. Your hand-written novellas were not a feature.

2. The fork adds git status and writes the file. That last part matters more than it sounds, because a handoff that exists only in the chat log isn’t a handoff, it’s a eulogy.

3. The text lands in your prompt box. The fork reuses the session’s prompt cache, per the docs. A warm fork means the summary gets read cheaply, not re-ingested at full price.

4. /clear, then Enter. Fresh context, same work. No retyping.

Interactive Only, and Other Limits

Now the part I have to say plainly, because it cost me a confused afternoon to learn: /handoff runs only interactively. I tried claude -p "/handoff" hoping to script the whole thing, and the mod’s command did not run. The text just reached the model as a plain prompt. Anthropic’s skills documentation describes these command definitions as a way to extend what Claude can do, which is consistent with what I saw, but I’ll leave the “why” to them. The measured result stands: interactive only. Could I be wrong about why it behaves that way? Possibly, but the measured result is what it is.

/handoff runs only interactively. claude -p “/handoff” does not run the mod’s command. The text reaches the model as a prompt. Run /handoff inside a live session.

Here’s the comparison I actually care about, and it’s the one no competitor has measured. Hand-written: 9 summaries, 16 resume prompts, and every summary a slightly different format because future-me is an unreliable narrator. /handoff: same five fields every time, capped at 25 lines, git status attached, written in seconds. The mechanics are documented; the outcomes are not, and I won’t pretend otherwise. Whether this drops the resume-prompt count is exactly the kind of question the remove-check on the band will answer, and I refuse to declare victory before the numbers do.

One honest limit: research found no measured handoff outcomes anywhere, mine included yet. What I can say is that the workflow removes the retyping, which was the entire cost. Am I hyping a 25-line file? Maybe. But 25 lines beats a fresh context staring back at you, blank, waiting for you to explain yourself. Again.

What We Don’t Know Yet, and the Remove-Check

Let me tell you what I don’t know, because every guide you’ve read so far has quietly skipped this part and I find that rude.

The band is unproven. I built it, six tests pass, the thresholds fire. The full step-by-step of how I assembled the thing lives in my Workshops write-up, and that write-up ends the same way this section does: with a working prototype and zero longitudinal evidence. Because here’s the uncomfortable part. Whether a glowing amber line actually changes my behavior, and whether that behavior keeps sessions out of the 400k tail, is a question with no data behind it yet. That’s why the remove-check exists, and I want it on the record instead of in a footnote: on or after 2026-10-20, if 25% or more of my sessions since 2026-10-06 still peak at 400k or above, the band comes off. Not “gets tweaked.” Gets removed. A warning nobody acts on is decoration with a UI, and I already have enough of those in my life.

The 60-minute cache TTL is not confirmed by the API. The mods API reports four token counts with no 1-hour/5-minute split, so no mod can independently verify the timer it’s displaying. My only source is the session’s own system prompt. It’s probably right. “Probably” is doing real work in that sentence.

The quota was never measured. The 5-hour and weekly caps are not visible from inside a session, so I have zero quota numbers. I’ve said all along that context was the wall that actually stopped me, and that’s true of my transcripts, but I cannot rank context against quota because one of them refuses to show me a number. If you came here hoping for a definitive “which limit hits first,” the honest answer is: mine was context, yours might not be, and neither of us can check the other one from the prompt box.

One Spend Story, and Where This Leaves You

Nobody, including me, has measured handoff outcomes. The /handoff mechanics are documented and the workflow removes the retyping, but whether it actually drops the resume-prompt count is unmeasured across every source I read. Research found zero measured handoff outcomes from any competitor. I’m not going to be the first person to fake one.

And one spend limit, because it fits in a paragraph and because it’s my favorite story of me being wrong. A video-draft session burned about $5.20 against my own $1.86 estimate, because the pricing API answered its cheapest 360p tier ($0.03/s) while the drafts actually ran at 720p ($0.10/s). Ten drafts after a $10 top-up left $4. Fixed by scaling the estimate by resolution. The whole post-mortem, mechanism and repair included, is filed under my Fixes page, which is where every “what broke and why” incident of mine goes to be publicly embarrassed. Am I embarrassed the estimate was wrong? Deeply. Is money a limit too? Ask my wallet.

So here’s the whole article in three moves, question-answer style, because I know you’re skimming by now. Watch the context number, with your own thresholds around 250k and 400k instead of borrowing mine. Respect the 60-minute cache window, and step away deliberately instead of letting a heavy session rot. And use /handoff instead of typing “please resume” like it’s 2019. Could I be wrong about the band, the thresholds, or the TTL? Genuinely possible, and the remove-check on 2026-10-20 exists precisely because I’d rather find out from data than from vibes. That’s the difference between a guide and a guess, and I’d like to stay on the right side of it.

Sources

• How Claude remembers your project - Claude Code Docs
• Manage costs effectively - Claude Code Docs
• Extend Claude with skills - Claude Code Docs
• Claude Code Token Limits and How to Manage AI Coding Costs
• What Is the Context Window Limit in Claude Code? How to Manage It for Better Results
• Claude’s New Usage Limits: What Developers Need to Know
• Claude Code was using 51,000 tokens before I even typed a prompt — I fixed it
• Claude Code Context Window: What It Is and How to Manage It
• Claude Context Window Exceeded: How to Fix It (2026)
• Claude Code Pauseless Context Compaction With Claude Burst
• Fixes
• Workshops
• The column