A long conversation with an assistant tends to degrade in a specific way: earlier instructions stop being followed, established facts are asked for again, and the tone drifts. The cause is mechanical and follows from how a chat interface is constructed.
Each turn is a fresh request
The model holds no state between messages. It does not remember the previous exchange in any persistent sense.
What creates the impression of continuity is the interface re-sending the entire conversation with every new message, so the model reads the whole history again before answering.
The conversation is therefore not a session but a document that grows, and the model's apparent memory is the document being resupplied.
Anything not in that document does not exist, regardless of how recently it was discussed.
The document has a hard limit
Models accept a bounded amount of text, and the transcript eventually exceeds it.
At that point something must be removed, and the standard approach is to drop from the beginning, keeping the most recent exchanges.
The oldest content is usually where the user stated their purpose, gave constraints, and established the facts that the rest depends on.
Trimming therefore removes the highest-value part of the conversation first, and the model has no signal that anything is missing.
From its position, the conversation simply begins at whatever point the trim started, and its answers are consistent with that truncated version.
Summarising loses the specifics
A more sophisticated approach replaces old turns with a generated summary of them.
This preserves the general shape of the conversation and reliably loses details: the exact spelling of a name, the specific number that was corrected, the precise wording of a constraint.
Summaries also compound. Summarising a summary drifts further from the original with each pass.
The result is an assistant that remembers the topic and forgets the particulars, which is the failure mode users report most often.
Attention thins as the input grows
Even inside the limit, a long input is not attended to evenly.
Material at the start and end of a long context tends to be used more reliably than material in the middle, a pattern observed consistently across models.
A constraint stated in the middle of a lengthy conversation can be present in the input and still fail to influence the output.
Expanding the context limit reduces truncation without eliminating this, which is why longer windows help less than their headline numbers suggest.
Contradictions accumulate
Over a long exchange, a user corrects things. The original statement remains in the transcript alongside the correction.
The model sees both and has no reliable rule for which supersedes the other, particularly once the two are separated by many turns.
It may follow the earlier version, or blend them, producing behaviour that looks like forgetting but is closer to confusion.
Explicitly restating the current requirement resolves this more effectively than saying that the earlier one was wrong.
Persistent memory features work differently
Assistants that claim to remember across sessions are usually storing extracted facts in a separate database.
Relevant entries are retrieved and inserted into the context at the start of a new conversation, which is why the memory feels selective.
What gets stored is decided by a process that judges importance, and it will save trivia while discarding something the user considered central.
This is a retrieval system rather than memory in any ordinary sense, and its failures are retrieval failures: the fact was stored and not fetched.
Long conversations get more expensive
Because the whole transcript is resent, cost and latency grow with conversation length.
The tenth message in a thread is processing far more input than the first, for the same visible output.
Providers manage this with aggressive trimming and caching, and trimming is exactly what causes the degradation users notice.
The economic pressure and the quality pressure point in opposite directions, and cost usually wins on consumer products where nobody is paying per message.
Working with the constraint rather than against it
The practical response is to treat a conversation as disposable and the important content as something to hold outside it.
Starting a fresh thread with a compact statement of the requirement produces better results than continuing a thread that has drifted, and it costs less.
Keeping a short specification in a document and pasting it at the start of each session makes the critical material recent rather than ancient, which is where the model attends most reliably.
Users who do this stop experiencing the problem, not because the limitation went away, but because they stopped relying on the part of the system that was never designed to hold anything.