The wall you hit mid-session is a different limit than the one on the rate-limits page — and a long conversation gets there faster than the turn count suggests.
Beginner → Intermediate
two limits, easy to conflate
API rate limits — requests/tokens per minute — are an
organization-level ceiling that only matters if you're calling the Messages API directly.
Usage limits are the separate thing that actually affects a person typing
into Claude.ai or Claude Code on a Pro or Max plan: a cap on how much you can use the
product within a rolling time window, independent of any per-minute throughput math.
They also fail differently. An API rate limit returns a 429 instantly and
clears within seconds to minutes. A usage limit tells you up front how much runway is
left, and once it's gone you're waiting out an actual clock, not a token bucket.
the shape of a usage limit
Consumer plans meter usage on a short rolling session window (currently a few hours),
and heavier Claude Code usage on Pro/Max plans additionally counts against a longer weekly
allowance layered on top — so bursting through the short window repeatedly across a week
can still stall you out even if any single session looked fine. Exact durations and
allowance sizes are plan-dependent and change over time; check your account's current
numbers rather than trusting a cached figure.
Claude Code surfaces where you stand with /status; Claude.ai shows
remaining usage in the app itself. Check before starting something you know will run long,
not after it stalls partway through.
context window vs. usage limit
A conversation's context window filling up is a per-session,
per-conversation ceiling — solved with /compact or /clear (see
CLI Basics). A usage limit is a cumulative, account-level
ceiling across every session in the window, and no in-conversation command resets it. They
also compound differently — the next section is why a long conversation's real cost grows
faster than its turn count suggests.
how a long conversation compounds tokens
Claude has no memory between calls — every turn resends the entire conversation so far
(system prompt, every prior message, every tool call and result) as input, plus whatever's
new. So the size of any one turn's input grows roughly in a straight line with the
turn count, but the total tokens processed across the whole conversation is the
running sum of that — and a running sum of a straight line grows quadratically, not
linearly. A 20-turn conversation doesn't cost about 20x one turn; in the illustrative
numbers below, it's closer to 200x.
Tokens sent this turnCumulative tokens processed this session
this turn:
cumulative:
Illustrative example: roughly 1,500 tokens of new material
per turn (a typical coding-assistant exchange), with no memory between calls. Hover the
chart, or focus it (Tab) and use the arrow keys, to inspect a specific turn.
View the numbers as a table
Turn
Tokens sent this turn
Cumulative tokens processed
1
1,500
1,500
2
3,000
4,500
3
4,500
9,000
4
6,000
15,000
5
7,500
22,500
6
9,000
31,500
7
10,500
42,000
8
12,000
54,000
9
13,500
67,500
10
15,000
82,500
11
16,500
99,000
12
18,000
117,000
13
19,500
136,500
14
21,000
157,500
15
22,500
180,000
16
24,000
204,000
17
25,500
229,500
18
27,000
256,500
19
28,500
285,000
20
30,000
315,000
This is the real mechanism behind "the session felt fine, then usage ran out fast" —
the growth isn't in what you see on screen, which grows in a straight line. It's in what
gets silently reprocessed underneath it, which doesn't.
context rot, aka "AI dementia"
A long, unmanaged context has a second cost, independent of any hard ceiling: quality.
Instructions from early in a session get diluted, a contradiction between turn 3 and turn
40 doesn't always get caught, and a fact or file buried in the middle of a huge context is
retrieved less reliably than one near the start or the end — researchers call this general
pattern the "lost in the middle" effect. Practitioners have taken to calling the everyday,
informal version of this "context rot," or, more bluntly, "AI dementia" —
not a technical term, but a fair description of what a long, cluttered session starts to
feel like: it keeps talking, but it's stopped tracking what you actually said ten minutes
ago.
The fix isn't a command, it's a habit — the same /compact, /clear,
and start-fresh discipline that manages token count also manages this, because a shorter,
more focused context is both cheaper and more reliable at the same time.
auto-compaction, and its limits
Claude Code doesn't wait for you to notice: it automatically compacts a conversation as
it approaches the context window's ceiling, summarizing older turns so the session doesn't
just fail outright. That's a safety net, not a strategy — auto-compaction fires on its own
threshold, with its own judgment about what's safe to summarize away, not yours. Running
/compact yourself, before it's forced, means you pick the moment (between
logical steps, not mid-thought) and what's worth keeping close to verbatim — a key file, a
decision — versus what's fine to lose to a summary.
One distinction worth repeating: auto-compaction manages the context window. It does
nothing for account-level usage — a heavily-compacted session can still be the one that
runs you out of usage for the window, because usage is metered by what was actually
processed, compaction or not.
five ways to respond once a session gets heavy
Once a session has real weight behind it — a long context, real progress made — there
are five ways to move forward, and picking the wrong one either wastes what you've built or
drags a bloated context further than it needs to go.
Option
What it does
Reach for it when
Continue as normal
nothing changes — Claude keeps working in the same context
the context is still lean and the task is still on track
delegates a self-contained sub-task to a separate session with its own context
the next step is a big, bounded exploration (read this whole codebase and summarize X) that would otherwise bloat your main session for one answer
running work in the background
Some work doesn't need Claude's attention for the whole time it runs — a test suite, a
build, a long-lived server. Claude Code can push that kind of work into the background
instead of sitting there blocked on it: you keep working the actual problem, and get
notified when the backgrounded task finishes, rather than watching a terminal scroll.
This helps usage two separate ways: the wall-clock time spent waiting isn't wasted
inside your rolling usage window doing nothing, and the backgrounded command's full output
doesn't get poured into your main conversation's context the moment it finishes — you see
it and decide what's worth pulling in, rather than eating the whole log by default.
plan mode: agree on the approach before spending tokens on it
Plan mode has Claude research a task and lay out its intended approach before writing
or changing anything — you read the plan, redirect it, or approve it, and only then does it
act. It's a checkpoint inserted before the expensive part of the work, not after.
The usage math favors this more than it looks. Catching a wrong approach at the plan
stage costs a few turns of back-and-forth. Catching the same wrong approach three turns
into an implementation costs those turns, plus the turns spent debugging why it isn't
working, plus the turns spent unwinding and redoing it — usually several times the cost of
having asked first. For anything nontrivial, plan mode is closer to reserving usage than
spending it.
prefer markdown over HTML or PDF
When you hand Claude a document to work from — a spec, notes, reference material — its
format changes how many tokens it costs, for reasons that have nothing to do with the
information inside it. HTML carries markup, styling, and script alongside the text; PDF
extraction is often lossy and padded (repeated headers/footers, broken table layouts,
sometimes an image-based scan that needs OCR-like handling). The same content as plain
Markdown is usually a fraction of the token count of either.
That matters more than once. It leaves more of the context window free for the actual
task, and — per the compounding effect above — it's not a one-time cost: that document
re-enters the model's input on every turn for the rest of the conversation, so a bloated
format keeps charging for the same information over and over. Convert to Markdown before
attaching a document if you have the choice; it's also why CLAUDE.md
and Claude's own memory files are plain Markdown rather than anything richer.
different models, different costs
Not every model costs the same to run, and the difference is usually several-fold
between tiers rather than a rounding error — check current pricing rather than trusting a
cached number, since it's exactly the kind of detail that goes stale fast (see
Choosing a Model). Under a seat-based plan, that spread
matters even if you never look at a bill: a message to a heavier model doesn't just cost
more on the API side, it consumes proportionally more of your rolling usage allowance too,
for the same reason a longer context does.
The practical default carries over unchanged from the API case: start with the
mid-tier model, and reserve the most capable one for the specific turns that actually need
deeper reasoning — not as the everyday default out of habit. Routing routine work to a
lighter model is one of the few habits that reduces both your bill and how fast you burn a
usage window, at the same time.
the 1M-token context window — bigger isn't automatically better
Some Claude models offer a context window far beyond the standard size — up to 1M
tokens, currently available as an expanded option on certain plans/tiers rather than the
default. It's tempting to treat that as the fix for everything on this page: a window that
big should never fill up.
It solves a narrower problem than it sounds like it does. A request that actually uses
a huge context costs proportionally more, and burns proportionally more of a rolling usage
allowance in that single message — one giant-context turn can spend what would otherwise
cover many ordinary ones. The context-rot problem described above doesn't go away because
the ceiling moved, either. And it does nothing at all for the
usage-limit accounting from earlier on this page — it only moves the context-window
ceiling, which is a different limit.
The large window earns its cost on a genuinely large, single-pass job — read an entire
multi-hundred-thousand-line repository and answer one question about all of it in one shot.
Reaching for it as the everyday default mostly means paying a larger tax on every message
for headroom a normal task never needed.
a short checklist
Habit
Why it helps
Check usage before a long push
starting a multi-hour task with half your window already spent guarantees a mid-task stall
Spread heavy work across the window
pacing sustained work rather than bursting it keeps you inside the rolling allowance instead of racing it
Right-size the model, every time
see "different models, different costs" above
Compact or clear on purpose, before you're forced to
see "five ways to respond" and "auto-compaction" above
Keep reference material in Markdown
see "prefer markdown over HTML or PDF" above
when a usage limit is the wrong tool for the job
Usage limits exist because a seat-based plan has to bound cost somehow without metering
every token. If you're consistently running into the wall, that's usually a sign the
workload has outgrown a seat-based plan — the API replaces the fixed
session window with pay-as-you-go spend and rate limits instead, which scale with the work
rather than capping it.
related topics
Claude Code CLI Basics — /compact, /status, and where a session's settings actually live. Effective Prompting — managing the context window itself, separate from account-level usage. Agents & Subagents — delegating a self-contained sub-task to its own session, the practical form of "hand off to a subagent" above. Claude API for Developers — the rate-limit and spend-cap model that API usage runs on instead. Choosing a Claude Model — matching model size to the task to stretch a usage allowance further. Claude Code Keyboard Shortcuts — Esc, Esc is the keystroke behind /rewind. Extended Thinking & Effort Levels — thinking tokens are billed the same as any other tokens, and count against this same allowance.