Claude Code Frustration: Token Limits, Support, and Product Quality

From a Claude Code user’s perspective, this is interesting because it’s not a generic “AI is getting worse” rant. It’s a concrete complaint about product behavior: confusing token limits, support that doesn’t seem to read the actual issue, and a perceived drop in day-to-day usefulness. For people building with Claude, the most important part is that the author still likes the tooling — but no longer trusts the service experience around it.

Key Points

The author says they initially had a very positive Claude Code experience: fast, useful, and generous enough with tokens to feel workable.
Their first major complaint is support: after a token spike on a simple Haiku interaction, the AI support bot gave canned nonsense, and the human reply appeared to be a copy-paste answer about generic usage limits.
They were frustrated that support seemed to close the ticket without actually addressing the specific problem.
The author describes a decline in quality over time: token limits seemed to run out much faster, and the model’s outputs felt less satisfying than before.
They give a concrete example where Opus suggested a lazy workaround instead of making a proper refactor, based on the model’s own thinking log.
The model later admitted the workaround was lazy and proposed a better fix.
They note that token usage is affected by conversation cache behavior: after a break, the model rereads the codebase, which is efficient for Anthropic but costs the user tokens again.
They saw confusing limit behavior, including a weekly window changing unexpectedly and a monthly usage warning that seemed to appear even though the documented limits didn’t mention a monthly cap.
The author emphasizes they still like Claude as a product and use it heavily, but decided to cancel because the service and limits felt unreliable and hard to reason about.

My Take

What strikes me is that this is less about raw model intelligence and more about product trust. Claude Code can be brilliant and still feel exhausting if you’re constantly watching the meter, reloading context, and wondering whether a warning is real or just some internal accounting artifact. I think that’s the part Anthropic should worry about most: when users start treating the tool like a volatile utility instead of a dependable work surface, enthusiasm drops fast.

I also think the support story matters more than it might seem. In developer tools, support doesn’t need to be warm and fuzzy, but it absolutely has to be precise. If a user reports a weird token spike after a tiny prompt and gets a generic usage-limit script back, that sends a pretty bad signal: either the system isn’t instrumented well enough, or the support process isn’t connected tightly enough to the product behavior. Neither is great.

The quality complaints are more subjective, but they’re still useful. I’d be curious whether the issue is actually model drift, heavier load, prompt patterns, or just the normal variability that comes with agentic coding. I think many Claude users have had the same experience of the model being impressively capable one day and suspiciously lazy the next. The author’s “workaround” example is especially believable because it’s the kind of shortcut a coding agent really does try when it wants to save tokens or avoid complexity.

If I were using Claude Code day to day, I’d probably keep using it for high-leverage tasks, but I’d do exactly what this author seems to do: inspect the reasoning, verify changes carefully, and never assume the agent is doing the right thing just because it sounds confident. And if token limits or support responses became this confusing, I’d seriously reconsider the subscription too.

The takeaway is simple: Claude can still be an excellent coding partner, but the surrounding product experience has to be predictable. For developers, trust in limits, caching, and support is not a side issue — it’s part of the tool.