Problem Solutions
Why Claude Feels Slower and Hits Limits You Can't See
Claude users have a running joke that the service is not down, it is just slow — and a running thread to prove it. The r/ClaudeAI community maintains a Performance and Bugs Discussion Hub, updated on October 24, that gathers user reports on slowdowns, usage limits, bugs and account issues in one place. The volunteers who run it say it is often the most-viewed post on the subreddit, and they recently added a log of user problem reports so everyone can see how many people are reporting limits, performance drops and bugs in real time. The hub exists because the experience does not match the dashboard: users report being throttled while their usage meter reads 6%, and sessions that slow to a crawl without any outage showing on Anthropic's status page. Here is what is actually going on, and what to do about each cause.
The limits you cannot see: three systems, one misleading number
The most confusing part of Claude's limits is that the dashboard percentage reflects only one of them. Claude Code rate limits operate as three independent, overlapping constraints. There are the 5-hour rolling windows most users know about. There are weekly rate limits that reset every seven days, including an overall usage cap plus a separate weekly cap for Opus models. And since March 2026, Anthropic has adjusted 5-hour session limits during peak hours — weekdays from 5am to 11am Pacific — so heavy agentic work during those windows drains faster than identical work run at night. That is why a dashboard reading 6% can coexist with a throttle: you may be fine on the number it shows and exhausted on one it does not. The confusion got worse this week, with reports that Anthropic is A/B testing usage limits — one analysis claims the test decreases monthly API value by about 20% while increasing 5-hour limits by about 20% for some accounts. That claim is reported, not confirmed by Anthropic, but it fits the pattern users describe: limits that move without any visible announcement, hitting some accounts and not others.
Why long sessions slow down even when nothing is wrong
The second cause is mechanical, and it affects every long conversation. Every tool result and conversation turn is appended to the context window, which is re-processed on every subsequent call. One developer who measured 74,493 of his own Claude Code turns found median turn time rising from 1.1 seconds under 25,000 tokens of context to 4.0 seconds at 300,000 tokens — roughly a 4x penalty — and within a single session, the first five turns ran at a median of 1.4 seconds against 3.5 seconds for everything after. The important nuance is that the curve flattens: going from 300,000 to 700,000 tokens only adds about another second per turn. So if a session feels dramatically slower than that, the cause is usually not context size but tool calls. Each tool call — a file read, a shell command, a directory search — wraps a model turn around it: Claude must receive the result, re-process the conversation, and decide the next step, which takes 2 to 4 seconds in a typical session. A task requiring 20 sequential tool calls therefore costs roughly a minute of model turns, almost none of which is spent executing tools. The tools themselves are fast; the thinking between them is the bill.
The pauses that are actually retries
The third cause looks like a freeze and is actually the system working. Claude Code retries failed calls silently with backoff, so a retry loop presents as an unexplained pause. In the same 74,493-turn measurement, 375 API errors were logged, of which 325 were local network failures on the user's side, 12 were rate limits and 6 were overload errors. The practical advice is blunt: check your own connection before checking the status page. A weak connection, an outdated browser session or a conflicting extension can make Claude appear broken when the problem is local. Similarly, a single user-visible command can generate multiple API calls — a lint, fix, test, fix cycle might produce 8 to 12 calls within 60 seconds — and when one tool call fails, Claude retries rather than surfacing the failure cleanly. You see the session hanging; what is actually happening is a retry loop billing you for the confusion. Anthropic's own status page currently lists its services as operational, which rules out a general outage but not isolated errors, regional problems, or an issue affecting a subset of users.
What actually helps
Start with the cheapest fixes. Split big work across several focused chats instead of running everything in one endless thread — one for outlining, one for drafting, one for editing — which keeps every individual chat small and fast. When a session slows, start a fresh one with a short summary of what matters rather than pasting the entire history back in. Break big projects into stages and generate one section at a time. Do not repeat instructions: every repeated "write naturally, optimize for SEO" adds to the context for no benefit, and accumulated skill files with contradictory guidance slow the model down while confusing it. If you hit a limit, check which one: wait out the 5-hour window, check whether you are near a weekly cap, and avoid peak hours for heavy agentic work. And use the community resources that exist for exactly this: the r/ClaudeAI hub and its survival guide, the user problem report log, status.claude.com, and Downdetector, which sometimes shows outages faster than the official page. One more thing to know: from next week, Claude web, desktop and mobile sessions default to auto mode on Pro, Max and Team plans, which changes how steps are approved — if your workflow suddenly behaves differently, that default is the first place to look.