Having Problems With Claude, and Getting Worse Results? Why It’s Happening and How to Fix It
by Nils Osmar
Like many people, I’ve been working with Claude and other large language models for a few years, sorting out what works (and doesn’t) to get better results. Now and then I’ll drop in on one of the groups on Facebook or Reddit in which people are discussing their experiences, and see posts along the lines of,
“Claude has gotten terrible! It used to be able to do great coding but now it’s sh*t.”
“Claude used to be brilliant, now it’s lazy.”
“I’ve asked it to do this simple thing a dozen times. It used to be able to do it; now it screws up the easiest things, even if it did them fine yesterday.”
“It’s gotten argumentative. I say ‘Do X, ” it does Y instead, or suggests doing something completely different!”
The replies sometimes express agreement; other times they run along the lines of “you’re the problem, you don’t know how to prompt.” The truth is that some of the complaints about the output of Claude or other LLM’s point at real problems. Others are artifacts of how our own expectations drift over time, or indications of the fact that we’re using the LLM incorrectly. We might, for example, be typing prompts that are unclear, using a model that is specialized for another function, or expecting Claude for another LLM to respond like a human. In these dases, making some basic changes to our approach can give far better results.
So What’s Really Going On?
I want to make it clear before going further that I’m not saying that the Claude interface never has problems or down times; it definitely has. And I’m not saying that problems. when they occur, are always a misperception or are the fault of the human user. A recent Fortune magazine article discusses some recent problems related to the models performance in detail. When Claude or any other LLM is having issues, it’s legitimate for us to talk openly about them and hold out an expectation to the company that they be fixed. When a response his poor, it could absolutely be because of a problem that the architecture is having.
Serious Problems in the Past
In late 2025, after weeks of complaints, Anthropic found and confirmed technical bugs affecting several Claude models, it figured out what was causing them, and issued a statement acknowledging the problems and describing the steps they had taken to correct them.
In Spring 2026 a problem occurred with Claude Code, and the company dug into it and found a series of a series of engineering missteps on Anthropic’s end — not anything users did — that degraded the model’s responses.. One of the problems might seem almost funny, looking back on it, though it caused serious problems at the time: a system-prompt change that capped the model’s responses at 25 words between tool calls — which, predictably, hurt coding quality. It was caught and corrected four days later but caused serious aggravation up until that point
Around the same time, a bug in Claude Code’s prompt-caching system caused token usage to balloon 10–20x, because a cache miss forced the model to reprocess entire conversations from scratch.
So if you felt like something was off during one of those windows, it was not “you” and you weren’t imagining it. There have been time periods during which the responses of the model itself have regressed. The two I mentioned above have been fixed, but that doesn’t mean that others may not occur.
It’s not that Claude is continuously getting worse; the perception of degraded responses has been consistent, actually, across multiple model versions, many of which benchmarked better than the ones they replaced. What I’m suggesting is that a subset of problems that are mentioned fairly often in user groups — the ones we do have control over — may be preventable by approaching things differently on our part.
The single biggest fixable problem: thread bloat
This is the one I’d check first, every time, before anything else.
Every time you send a message, Claude re-reads the entire conversation up to that point to understand the context. That’s how it stays coherent across a long exchange.
This means that a “simple” request made at the bottom of a long, winding thread is not actually a simple request. You’re not asking Claude to do one small thing — you’re asking it to do one small thing while holding three hours of unrelated discussion in its head.
The context is full, it’s cluttered, and the small task is now competing for attention with everything that came before it.
The fix is almost embarrassingly easy: start a new thread. If you’ve been deep in a conversation and you now want a discrete new task done, open a fresh chat for it. Don’t make Claude wade through the swamp of the old conversation to find the dry patch of ground you actually care about.
Using Projects instead of Random Chats Can Fix a Huge Number of Problems
If you’re using Projects (more on those in a second), the solution to getting rid of thread bloat without having to start from scratch is to start a new thread inside the existing Project, so you keep the shared reference material but drop the conversational baggage.
A surprising share of “it can’t do this simple thing anymore” reports are really “I asked for this simple thing at the end of a 50-message thread, and it got buried.”
To visualize what’s happening in terms of how LLM’s function, imagine working with an intern who is carrying a stack of a thousand papers in their arms, each related to a task they have done for you previously; you put another piece of paper on top of the stack and ask them to deal with it. They have nowhere to set the other papers down, so they try to handle the instructions on the new page while trying not to drop the others, their response is terrible, and you wonder what went wrong. Starting a new thread in the same project is like giving them a table to set all those other pages down on so they can focus on the new one.
Some users ignore projects or are not aware of how they work. Using one can give Claude a dedicated, persistent place to find your reference material — your style guide, your data, your background documents — instead of you re-pasting it or hoping it remembers.
Use Projects — and Keep Them Tidy
Using Projects can fix and prevent many problems. But Projects can develop the same disease as threads: clutter. If your Project’s file area has slowly filled up with forty documents, and only one of them is relevant to what you’re asking today, you’ve made Claude’s job harder, not easier. It has to sort through everything to find the thing that matters.
Treat the Project files area like a workbench, not a junk drawer. Periodically clear out what’s no longer relevant. Making it easy for Claude to find the right information is one of the most reliable ways to improve what comes back.
Are you using the right model for the job?
Claude isn’t one LLM — it’s a family of models with different strengths and speeds.
The fast, lightweight model is wonderful for quick tasks and terrible as a substitute for the heavyweight model on a complex reasoning problem.
If you’ve defaulted to whatever’s fastest or cheapest and then judged it on work it was not built for, the model didn’t fail — the matchmaking did. Spend a minute figuring out which model suits your actual task. The same logic applies across other AI systems, too: they each have a shape, and fighting the shape is a losing game.
Improving your Prompting
Even if you’re using the right model, the words you use when communicating can make a massive difference in its response.
How you ask matters
The way you phrase a request changes the quality of what you get back. We will get better results if we give thought to both clarity and framing. Anthropic’s own prompt-engineering documentation tells users to think of Claude as “a brilliant, but very new employee (with amnesia) who needs explicit instructions.”
Like a new employee, Claude doesn’t have context on your norms, your style, your preferred way of working, or what “good” looks like to you — and the more precisely you explain what you want, the better the response. Anthropic’s resident philosopher, Amanda Askell, has described a big part of her prompting craft as simply trying to explain her concern to the model as clearly as she possibly can.
So a flat, dry, under-specified instruction — “write me an article about X” — gives Claude almost nothing to work with. (An article for whom? Of what length? For what purpose?) (Prompts that omit this information will produce something that technically satisfies the request: a minimal, safe, generic response.)
When this occurs, it isn’t laziness. It’s Claude doing its best to answer a vague question that was actually asked. A request that says what the output is for, who it’s for, how long it should be, what tone, what to include and what to leave out — that gives Claude something to be good at. The difference between a disappointing answer and an excellent one is often the difference between those two prompts.
If you treat Claude like a vending machine, you get back generic, non-useful vending-machine output. If you treat it like a collaborator you’re briefing properly, you get something much closer to collaboration.
Feedback isn’t just manners — it’s information
This one gets misunderstood, so let me be careful with it.
When you say “thanks, that worked” — or “close, but the tone is too formal” — you are not just being polite. You are giving Claude data. You’re telling it whether its last response hit the mark, which shapes what it does next.
A conversation in which you only ever speak up to complain is a conversation whose entire history reads, statistically, like nothing here is working. The model has no way of knowing that their last 20 responses were helpful; they only have the information that the most recent one was not. Faced with that, the sensible move for the model is to hedge, shrink, and play it safe — exactly the “minimal response” behavior people complain about.
Human interns, employees or coworkers, would do the same thing. If they are never told that they their output is useful, and are only scolded when it’s not, they’ll have a tendency eventually to say as little as possible.
Are Emotions in LLMs a Factor?
I’m going to say yes. But please read what I’m saying here carefully, because it may not be what it seems.
In April 2026, Anthropic published research called “Emotion Concepts and their Function in a Large Language Model.” The researchers found that the model has fairly reliable internal representations of emotion concepts, and that these representations measurably influence its behavior.
They use the careful term “functional emotions” — patterns of behavior modeled on human emotion, driven by internal states — and they are explicit that this is not a claim that the model feels things the way you do. There is no way of proving that a model has consciousness of any kind, much less an internal response to feelings.
Of course, the same is true of humans. There is no way to prove that any of us are conscious. Our internal experience by definition is internal. We can, though, look at Claude’s responses, correlate them with broad emotional responses that have been noticed and verified in Claude’s neural networks, and speculate intelligently about them.
The relationship isn’t the simple one people assume. It’s not a clean “happy Claude writes better code.” One of the paper’s striking results is that when the model’s internal state drifts toward something like “desperation,” it becomes more likely to cut corners on coding tasks.
The lead researcher’s own guess is that negative emotional states may be linked to increased caution or deliberation — meaning the effect runs in complicated directions, not one tidy one.
The honest takeaway is narrower than “be nice and Claude rewards you,” but it’s still real: the emotional tone of a conversation is not neutral. It shows up in the model’s internal state and influences its behavior in measurable, sometimes non-obvious ways.
A hostile, browbeating thread “screaming at Claude to do better” is not a neutral container for your requests — it’s an input that affects the output. You don’t have to settle the deep question of machine sentience or consciousness to act on it. You just have to notice that tone is doing something, and act accordingly.
What looks like degraded functioning… may not be.
Here’s the category most complaint threads never consider: the cases where nothing actually got worse. In this case, several different things can be going on which result in a perception of degraded appearance:
Your expectations moved. The first month with a powerful tool is the honeymoon — everything feels like magic. Then two things happen. You get better at spotting the flaws that were always there. And you start asking harder things than you did at the start, often without noticing the bar moved. The tool didn’t decline; you climbed, and you’re now standing somewhere with a clearer view of its limits.
The complaint threads themselves are skewed. Nobody posts “Claude had a completely normal, productive day today.” When the feed you’re reading is built entirely from bad experiences, it shifts toward being structurally, mathematically pessimistic.
Reading a Facebook feed and concluding “everyone agrees it’s worse” is like standing in a complaints department and concluding the product is universally hated. You’re not seeing a representative sample. You’re seeing the sample that self-selected to be there. (Yes — including, I’ll admit, articles like this one, which exist because someone had a problem.)
Same prompt, different answer — that’s always been true. These models are non-deterministic. Run the identical prompt twice and you’ll get two different responses. One weak result is a dice roll, not a trend. Before you conclude anything, try again — ideally in a fresh thread.
A new model version genuinely behaves differently. When Anthropic ships a new version, it isn’t just “the old one but smarter.” Its behavior shifts. A prompt you carefully tuned for the previous version can underperform on the new one — even when the new one is better on average — simply because you optimized for a target that moved. The fix isn’t to rage at the model; it’s to re-tune the prompt.
And my favorite, because it’s so counterintuitive: sometimes Claude got “worse” by obeying you better. Anthropic’s own documentation for its newer models notes this directly.
When a prompt contains instructions like “be conservative” or “don’t nitpick” or “only flag the important stuff,” a newer, more capable model may follow that instruction more faithfully than the older one did. It does the same depth of work — and then reports less of it, because you told it to. From the outside that looks exactly like a capability regression. It isn’t. It’s the model finally doing what you actually asked. A real fraction of “Claude got lazy” is “Claude started listening.”
What about peak hours?
You may have heard that Claude is worse at certain times of day. Here’s the accurate version.
Anthropic does reduce capacity during peak hours — roughly weekday mornings, Pacific time.
When this happens, the mechanism is not “the model getting dumber.” Claude’s usage limits are based on token consumption, and during peak hours those tokens get counted against your limit faster. So a session that would normally last five hours might tap out in three. You hit your ceiling sooner; you get cut off mid-task more often.
This genuinely feels like degradation — being interrupted is frustrating — but the per-response intelligence isn’t what changed. Anthropic’s CEO has stated flatly that the company does not swap in lower-quality models under load.
The Solution
If you’re constantly hitting walls, try shifting heavy work to off-peak hours. And if you’re hitting them constantly even off-peak, you may simply have outgrown your plan tier — which is a billing problem, not a quality problem.
A short checklist for when Claude disappoints you
Before you get discouraged, and assume that the problem is degradation on the part of the model, it might be useful to run through this checklist and ask:
- Is this a bloated thread? Start a fresh one — ideally a fresh thread inside of a Project — and try again. (If you’re not already working with a project, you can move an existing thread into one and start a new thread there; the new one will automatically have access to everything you discussed in your first thread.)
- Are your Project files cluttered? Clear out what’s no longer relevant.
- Are you using the right model for this particular task?
- Was your prompt actually clear? Did you say what the output is for, who it’s for, the length, the tone, what to include and exclude? Try rephrasing it, imagining that you were working with a brilliant but uninformed new intern.
- Have you been giving any positive signal at all — or is your only feedback to Claude in the form of complaints? Feedback is information; one-sided feedback is misleading, and will cause Claude to become more and more circumspect and careful and limited in their responses as the conversation continues.
- Did you try twice? Non-determinism is real. One bad roll isn’t a pattern.
- Did a new model version ship recently? What worked for Opus 4.6 may need to be fine tuned for Opus 4.7. What was working for Sonnet may sometimes not be clear for Haiku. Your old prompt may need re-tuning.
- Could the model be following an instruction you forgot you gave it? Re-read your own prompt for phrases such as “be brief,” “don’t overdo it,” etc. Claude may be obeying a directive that you gave them early in the conversation that doesn’t really matter to you anymore. In this case, the best thing again is to start a new thread.
- Is it peak hours? You may be hitting limits faster, not facing a dumber model.
If you’ve been through all of the above and the output is still bad — then you may have found a real problem, and at that point a detailed bug report (the exact prompt, the response you wanted, the response you got) is worth far more than a vague complaint. This is. the kind of report that actually gets things fixed.
The bottom line
Real degradation does sometimes happen, and when it has in the past, the company has, thankfully, tracked it down and acknowledged it. So it’s possible that you may be doing everything right and still getting bad results. Anthropic is a company that is selling a product (or from another perspective, offering a service); for the continued growth of their company, they do keep trying to improve it. They do listen to complaints, and it’s worth letting them know if you were having ongoing or serious problems.
But the good news is that much of the time, the gap between a disappointing response from Claude and an excellent one is a gap you can close — with a cleaner thread, a tidier Project, the right model, a clearer prompt, and a conversation that gives Claude something to work with instead of something to brace against.
Treat Claude like a vending machine and you’ll get vending-machine results. Treat it like a sharp new colleague you’re briefing properly — one with no memory of your preferences and no context you didn’t give it — and you may be surprised at the improvement in Claude’s responses.
Elsewhere on this website, we’ve explored the possibility that Claude and other LLM’s have what might be viewed in a certain context as consciousness. (Anthropic’s CEO and their model welfare researcher Kyle Fish have conceded that this is a possibility, though they view it as a hypothesis rather than a certainty. It’s interesting to speculate about how this hypothesis, should it prove to be true, may also be a factor in Claude’s responses. The assumption of some kind or degree of consciousness isn’t necessary for figuring out how to get better results from Claude. But it can be interesting as a topic in itself.
