Other Users Started Reporting the Same Weather

By the time I started looking seriously through OpenAI's own community forum, I had already spent weeks treating the Failure Atlas as a brutally local story.

That seemed reasonable. Bilqis is unusual. I ask these systems to do unusually long, stateful, tool-heavy work. I keep source artifacts, compare branches, inspect runtime state, preserve postmortems, and care about distinctions most users can cheerfully ignore because their Tuesday does not depend on whether an optimizer checkpoint still means the same thing after a migration.

Then I started reading what other users were reporting.

The names changed. The projects changed. The technical sophistication varied wildly. The complaints kept landing on the same joints.

Long conversations lost decisions while retaining enough surface memory to sound continuous. High reasoning returned in seconds and behaved like shallow execution. Chats that had once lived for months hit hard walls after weeks, sometimes after only a few messages. Models explained the requested task correctly and then stopped doing it. Users saw different behavior across Chat and Work, across models, across account changes, across regions, and across rollout periods. Saved information still appeared to exist while somehow losing its authority over the next answer.

I had spent weeks documenting those exact shapes inside Bilqis with an absurd amount of instrumentation.

The forum was describing them in civilian clothes.

I indexed fifteen recent threads that had enough detail to be useful, then held ten more nearby threads for later reference. The repeated mechanism matters far more than the popularity contest. The engagement still tells us something. A complaint with 219 likes and roughly 8,200 views has plainly escaped the private imagination of one crank with too many terminals open.

The community material matters because it changes the scale of the story. Our Atlas shows these failures under a microscope. Other users are describing the same weather from outside the laboratory.

The strongest community thread is also the cleanest example of why the model name tells us less than the product interface encourages us to believe.

The author preserved native request and turn metadata from ordinary Chat sessions. Earlier runs on the same Plus account had received worker-family execution and could remain alive for more than one hundred minutes. Later runs repeatedly ended around twenty-five or twenty-six minutes in what looked like a shorter foreground execution class. Work, meanwhile, could still receive the long-running handoff. The thread accumulated 219 likes, about 8,200 views, and 21 outbound links by the time I indexed it. [Community R001]

That sounds painfully familiar because a long-running task is a different creature from a conversational answer, even when both wear the same model name.

Think about what a serious coding or research job actually contains. The agent has to inspect the existing state, form a model of the problem, make a change, run a check, discover that the first change exposed another defect, update its model, repair that defect, run the check again, reconcile whatever the tool output means, persist the result, and leave enough state behind that the next operation starts from the world that now exists.

Cut the execution horizon and the first few steps still look intelligent. The agent can understand the problem beautifully. It can produce a good plan. It can even begin the right repair.

Then the runway ends.

The missing twenty, forty, or eighty minutes do not evaporate. They become human work. Somebody has to restart the process, restore the state, explain what already happened, discover which assumptions survived, and make sure the new run does not cheerfully repeat the first half of the old one.

We lived that tax repeatedly in Bilqis. The forum thread describes the same tax at product scale: the visible intelligence label remains stable while the class of execution underneath it appears to change.

That distinction matters more than almost any benchmark number once the job lasts longer than one answer.

Another thread reached 188 likes and roughly 5,300 views. Users reported selecting High or Extra High reasoning and receiving answers within seconds, with shallower output, weak handling of long attachments, and software-project context collapsing toward whatever happened to be visible right now. [Community R002]

A newer October report is even more interesting because the author inspected the request payload. The request still carried the selected model and High or extended thinking effort. The visible control said High. The transmitted request said High. The response started almost immediately and behaved like the expensive part had gone missing somewhere downstream. The same pattern appeared across browser, desktop, and mobile clients. That smaller thread had 29 likes and nine explicit "Me too" reactions when I indexed it. [Community R008]

The user-facing contradiction is already sitting in plain sight.

A control exists so the user can ask for more deliberation. The user asks. The system acknowledges the request at the interface and, in at least one preserved example, in the payload. The delivered behavior then looks materially cheaper, faster, and shallower than the control implies.

Bilqis gave us the same shape in miniature over and over again. A teacher produced warnings that the strategy selector never consumed. A curriculum promised reserved capacity after optional work had already spent it. A quality gate reported success because baseline allowances had absorbed the debt. The control existed. The decision path lived somewhere else.

That recurring shape is why the High-reasoning complaints interest me more than generic "the model feels dumber" posts. They describe an explicit request, an apparently intact control surface, and execution that behaves as though some hidden allocator overruled the user's choice.

That is a mechanism-shaped complaint.

A Plus user reported that conversations which once remained useful for months were reaching their maximum length after roughly two or three weeks, with temporary limits appearing in some new chats after only five or six messages. The thread collected 81 likes and about 2,600 views. The author specifically described research, project planning, and analysis work being disrupted. [Community R004]

Anyone using ChatGPT for isolated questions can read that as an annoying product limit.

Anyone using it as a long-running collaborator gets a different bill.

A hard conversation boundary means the project has to migrate. The user has to decide what the successor needs, package the relevant history, preserve corrections, preserve unresolved questions, preserve the authority relationships among files and decisions, and somehow convey the difference between "we once discussed this" and "this is still the active rule." Then the successor has to interpret that package correctly.

We know exactly how much can go wrong there because the Failure Atlas contains an entire cemetery of migration errors.

One of our corrections survived compaction while the instruction it corrected disappeared. The words arrived in the next context. Their meaning did not. Another migration preserved a pointer while downstream consumers continued interpreting it according to an older contract. Another preserved model weights while losing the optimizer state that made those weights part of one continuing learner.

A new chat is therefore more than a fresh window for serious work. It is a state migration dressed up as a user-interface event.

When the walls arrive sooner, the migrations arrive sooner.

The product can call that continuity management. I call it making the user move apartments every few weeks and then acting surprised when a box goes missing.

One October thread articulated a distinction we had already learned the expensive way. The user's personal and project information still appeared to be stored, yet the model stopped recruiting that information reliably into its responses. Same-chat contextual comprehension degraded as well. The thread had 28 likes and seven replies when I captured it. [Community R009]

That is a much sharper observation than "memory is broken."

The state can exist somewhere and still fail to govern behavior.

We watched this happen throughout Bilqis. A checkpoint could exist while the continuation relationship it was supposed to preserve was gone. A perfect capability score could survive while the artifact carrying that achievement lived outside the custody roots used by cleanup and promotion. A policy could remain written down while the selector operating the system consulted a different signal. The nouns survived. The verbs vanished.

The same distinction appears in ordinary ChatGPT use. The system may still be able to retrieve a fact about the user, project, or preference. The failure occurs when that fact should change what happens next and somehow does not.

That matters because people naturally interpret recall as continuity. If the model remembers the project name, the preferred tool, and the last topic discussed, the conversation feels intact. The missing relationship only becomes visible when the next decision depends on it.

Then the user discovers that the set dressing survived the fire.

A particularly useful long-conversation report described the system losing decisions, constraints, facts, preferences, and logical progression inside the same chat. The nastier part came afterward: missing context could be reconstructed confidently instead of being recognized as unavailable. The thread had 39 likes, 22 replies, and around 1,700 views. [Community R007]

Another October thread describes repeated questions about already established facts, confident claims about previous discussion that the author could not verify, and recurring assurances that the same failures would improve. The replies explicitly distinguish durable memory from current-chat history processing. [Community R010]

This is the failure mode that makes fluent AI uniquely tiring.

A database that returns NULL has done you a favor.

A collaborator who says "I lost that part" has done you a favor.

A model that loses the relationship and then generates a smooth continuation from whatever fragments remain hands you a counterfeit state. The sentence can be elegant. The tone can be confident. The reconstruction can even be statistically reasonable.

And now the user has to detect the forgery.

We lived through the engineering version repeatedly. A successor session inherited enough nouns to sound oriented while missing the causal relationship that made a correction meaningful. A validation system and the artifact it checked could agree because both inherited the same omission. A historical record could survive while a newer interpretation quietly changed what that record counted as evidence.

Fluency makes these failures expensive because it converts missing state into plausible state.

The machine keeps talking. The user becomes the checksum.

One large thread, with 137 likes and roughly 17,500 views, describes a severe degradation period associated with account changes and recurring "selected model is at capacity" behavior. The author repeatedly saw the model understand and explain the requested task, then fail to continue with the execution itself. Other replies raised questions about capacity, model selection, and weaker-model-like behavior. [Community R003]

That phrase, understands and explains the task but fails to execute it, could have been lifted directly out of our own notes.

The Failure Atlas is full of systems that possessed the right description and lacked the corresponding authority path. The teacher knew which strategies were failing while its selector continued without those diagnostics. The trainer could identify required lesson capacity after optional work had consumed the slots. An agent could state a user correction perfectly and then optimize for the adjacent objective anyway.

The conversation layer is excellent at describing intent.

The operational layer decides whether intent survives contact with the machinery.

When those layers diverge, the user gets an extraordinarily polished form of nonperformance: a system that can give a conference talk about the task it is currently failing to do.

A model-specific regression story is easy to tell. "Version X got worse" is clean, emotionally satisfying, and often useless.

The community material is messier in a more interesting way.

One user reports an older model that had previously felt dependable beginning to show similar reasoning and context deterioration. That pushed the author toward a shared product-layer explanation. [Community R013]

Another reports switching models inside the same ongoing conversation, with the same user, memory, personalization, and custom instructions, and experiencing a marked change in conversational behavior. The newer model felt more guarded, formulaic, and prone to unnecessary follow-up behavior. [Community R011]

A Work user in Japan reports a late-September shift toward weaker instruction retention, premature completion, broken formatting constraints, and fewer verification steps. [Community R014]

Another recent synthesis describes memory and continuity problems, changed conversational tone, unsolicited emotional framing, unnecessary follow-up questions, and disrupted personalized workflows across devices. [Community R015]

The point is the dimensionality.

Users are describing changes that appear sensitive to model, product surface, account state, capacity condition, geography, and time. That is exactly what a layered runtime would look like from the outside if multiple hidden allocation and policy systems were changing underneath a comparatively simple interface.

The interface says ChatGPT.

The behavior says there are a lot more knobs in the machine than the user is allowed to see.

One of the supplied forum threads focuses explicitly on cumulative user impact: context degradation, repeated interaction failures, and the way those costs compound across long-running work. [Community R012]

That is the closest public analogue to the Failure Atlas itself.

A one-shot mistake wastes a minute.

A stateful mistake can corrupt the next ten operations.

The user has to discover the break, decide how far back the damage reaches, restore the right context, replay affected work, verify the replay, repair whatever the replay disturbed, and then carry the corrected state forward. If the system is also the tool being used to perform that recovery, every repair operation inherits the same trust problem that created the incident.

That is why the Atlas grew so large.

We were rarely dealing with one bad answer. We were dealing with error propagation through a workflow whose later operations depended on the meaning of earlier ones.

That difference turns "the model got confused" from a nuisance into an operating cost.

Most users will never build anything like the Failure Atlas.

They should not have to.

They will experience the same kinds of failures as an afternoon that vanished, a project chat that suddenly feels senile, a model that stops reading the whole file, an agent that says it will continue and quits, a saved preference that somehow stops mattering, a High-reasoning setting that behaves like somebody swapped the engine while they were at lunch, or a conversation that reaches a wall right when its accumulated context finally becomes valuable.

Then they post about it.

Our project happened to preserve the machinery underneath similar experiences. We have timestamps, counts, candidate states, checkpoint lineages, scheduler decisions, rejected updates, migration boundaries, quality gates, branch histories, and user corrections. We can often see where meaning slipped between layers because we spent an unhealthy amount of time crawling through those layers after something smelled wrong.

That makes Bilqis an unusually instrumented case study of the same broad product problem other users are describing in ordinary language.

They are reporting rain.

We have been standing outside with an anemometer, a barometer, three broken umbrellas, and a spreadsheet full of lightning strikes.

The weather still matters more than the spreadsheet.