When a promising conversation goes off course
The first suggestion is useful. A follow-up brings the improvement you wanted. After several corrections, however, an error returns that seemed resolved. An important requirement disappears while the AI explains at length that it has considered everything.
That is how a frustrating session might unfold. Someone trying to finish an application gains little from repeating the same instruction for the fifth time.
Has the model deteriorated? Did something change? Or has the conversation become so cluttered that crucial information gets lost?
Quality problems can be real. How disappointing an answer feels does not, by itself, reveal their cause.
What the often-quoted 39 per cent actually means
The paper “LLMs Get Lost In Multi-Turn Conversation” was first published on 9 May 2025 and is listed by Microsoft Research as an ICLR 2026 contribution. Its authors compared fully specified single requests with conversations that supplied information gradually. Across six task areas, average performance fell by 39 per cent in the studied multi-turn setting. More than 200,000 simulated conversations were analysed. [1]
This does not mean every long conversation inevitably loses 39 per cent of its accuracy. Nor is it a general measurement of today's models.
The studied systems often made early assumptions and relied too heavily on their initial solutions. The research does not establish safety instructions or deliberate provider degradation as the cause. [1]
The practical distinction matters: a conversation stuck on an incorrect assumption may need a cleaned-up assignment, not another correction built on the same premise.
Working context is more than the latest message
An agent may draw on system instructions, conversation history, file excerpts, tool descriptions and previous results alongside the current request. Anthropic's context-engineering article of 29 September 2025 describes context as a finite resource that should be assembled deliberately. [2]
“Context bloat” means an overloaded working context, including irrelevant, outdated or competing information, not simply a large amount of text.
For example, an application initially uses a local file, then the project switches to a database. Both approaches continue to be discussed. Unless the binding decision is recorded clearly, the history remains contradictory.
My conclusion is not to explain as little as possible. The AI needs the right information, not every fact that has ever appeared in the project.
A fresh conversation helps only if current decisions and files accompany it. Otherwise, another round begins with incomplete information.
Real deterioration has been documented
It would be equally wrong to blame every complaint on poorly written user requests.
On 23 April 2026, Anthropic published an investigation into quality problems affecting Claude Code, the Claude Agent SDK and Claude Cowork. It identified a temporarily reduced default reasoning effort, a bug handling earlier reasoning in longer sessions, and a brevity instruction that combined with other changes to harm coding quality. [3]
The provider reported that all three issues had been resolved by 20 April 2026 and that the API was unaffected. This is a historical analysis, not evidence that those same problems remain today. [3]
The case nevertheless shows something important: applications, settings and history management can affect results alongside the underlying model.
“That cannot happen; the model has not changed” is therefore too simple a response to a substantiated complaint.
Outages and usage limits are different problems
Slow responses, aborted requests and temporary unavailability initially concern service availability.
OpenAI's API documentation distinguishes rate-limit errors from server errors and temporary overload. An error or rejected request is therefore not, by itself, evidence that completed answers have become less accurate. [6]
A rate limit restricts usage. The documentation describes limits on requests or tokens over a period; this does not automatically mean an answered request secretly used a weaker model. [5]
Requests fail or hit a limit: check the error, service status and available allowance.
Answers misrepresent earlier decisions: check context, conflicting instructions and current project state.
The same assignment changes after a product update: check model selection, reasoning effort, tools and application version.
An agent claims to have changed files but the result is missing: check actual files, tool output and execution records.
These are starting points for investigation, not a method that conclusively identifies every cause.
Is a smaller model secretly used under the same name?
Different models and reasoning settings exist. OpenAI's official documentation describes them explicitly and notes that availability and tools depend on the product and model version. [5]
A documented selection is different from claiming providers generally switch secretly to poorer models whenever demand rises.
The sources reviewed here do not substantiate that blanket claim. Stronger quantisation cannot be inferred from one unusual answer either.
In its 17 September 2025 postmortem, Anthropic attributed the then-reported problems to infrastructure faults, not deliberate quality reduction during high demand. It described routing and output-computation problems. That is the provider's explanation, not an independent audit of every internal system. [4]
Quality criticism is legitimate. An explanation of its cause still needs evidence of its own.
Developers do not all feel the same way
Forum reports can highlight problems, but do not automatically establish how common they are or what causes them.
The Stack Overflow Developer Survey 2026 does not paint an entirely negative picture. Positive attitudes predominate, while 48 per cent of respondents to the trust question say they trust AI when they can easily validate its answers. [7]
That fits a measured approach: a tool can be helpful without receiving every task unchecked.
Frustration and benefit can coexist. AI may reduce routine work yet need more supervision than expected for a difficult change.
Record the binding project state
Before requesting another correction, I would reorganise the assignment: what is the goal, which decisions stand, which option was rejected and which files are current?
For example: “The application uses the existing database. The earlier local-file proposal will not be implemented. Change only the search function. Keep permission checks unchanged. Identify open questions before making changes.”
This is an example, not a guarantee of an error-free answer. It provides a clearer basis than “Get it right this time.”
Compare under the same conditions
If there is a reasonable suspicion of deteriorating quality, I would record typical tasks and expected results, then compare the existing conversation with a fresh, organised one.
Keep the model, tools and settings as similar as possible. Otherwise, the cause of any difference remains unclear.
One better answer does not demonstrate a lasting advantage. Several comparable attempts provide a more useful picture.
Report errors without disclosing confidential information
A useful report includes the time, application, expected behaviour and actual result. For development tools, version details and available request identifiers may help.
Do not put customer data, access keys or internal documents into a public report without review. I would start with a small, sanitised example.
My conclusion: Take the fault seriously and examine the explanation
Frustration is understandable when an AI loses requirements or repeats errors. Users need not make excuses for a paid tool.
But treating every disappointing answer as proof of secret throttling is not helpful either. Documented product bugs, cluttered context, changed settings and service outages are different things.
I expect providers to explain changes clearly and investigate reproducible complaints seriously. In my own work, I would also keep assignments, decisions and outcomes verifiable.
The question is not just whether an AI seems worse, but under which conditions it fails and what can actually be changed.
Scope and research
Research date: 11 October 2026. Historical incidents and studies do not transfer unchanged to current models or accounts. No comparison measurements of our own and no evidence of generally practised deliberate throttling. General technical guidance, not individual legal advice.
Sources and further reading
[1] Original source
Read source ↗
[1] Original source
Read source ↗
[2] Original source
Read source ↗
[3] Original source
Read source ↗
[4] Original source
Read source ↗
[5] Original source
Read source ↗
[5] Original source
Read source ↗
[6] Original source
Read source ↗
[7] Original source
Read source ↗