What I Think Is Happening

After enough incidents, "the model had a bad day" stops being an explanation.

The recurring failures in the Atlas have too much structure. The community reports add the same shapes from outside our project. Chat and Work behave differently. Long conversations degrade in ways short ones do not. Saved state survives while its influence disappears. High reasoning can be selected while the delivered execution looks conspicuously cheap. Account changes, capacity events, rollout timing, model switches, and regional reports all seem capable of changing the experience.

My working picture is straightforward: the model is only the most visible animal in a much larger zoo.

The product we experience is a hidden runtime that assembles context, chooses what history matters, retrieves memory, applies policy, allocates reasoning, selects an execution lane, grants tools, enforces limits, compacts long conversations, manages workers, and changes behavior according to account, surface, capacity, and rollout state. The model then reasons inside the world that runtime gives it.

When people say "GPT-5.6 got worse," they may be naming the face while the hands, lungs, and nervous system are changing behind it.

I think a meaningful share of the degradation we have been experiencing lives in that surrounding machinery.

The interface encourages a simple mental model.

Pick GPT-5.6 Sol. Pick GPT-6. Pick a reasoning level. Ask the question. Receive the behavior of the thing you selected.

Our experience keeps breaking that picture.

The same model family can behave differently in ordinary Chat and Work. Long-running worker execution can survive in one surface while foreground conversation stops much sooner in another. The user can select High reasoning while the response arrives almost instantly. Memory can appear present in one turn and operationally absent in the next. A model switch inside the same conversation can change the social and behavioral texture of the interaction even while the user's saved context remains stable. [Community R001; R002; R008; R009; R011]

That suggests the selectable model is one component inside an execution product whose surrounding configuration can dominate the experience.

A brilliant model with starved context will look forgetful.

A brilliant model with a short execution budget will look lazy.

A brilliant model behind an overbearing policy layer will look evasive.

A brilliant model routed through a cheap foreground path will look shallow beside the same family operating inside a durable worker.

A brilliant model handed a compacted summary missing one load-bearing relationship will reason beautifully from the wrong world.

We kept blaming the brain for symptoms that increasingly look circulatory.

Long conversations create an unavoidable engineering problem: the product has to decide what portion of the past remains active in the present.

Whatever proprietary implementation OpenAI uses, the visible job is the same: some machinery selects, compresses, summarizes, retrieves, ranks, or otherwise transforms prior state before the next answer is generated.

That process looks disturbingly familiar after Bilqis.

We watched our own systems migrate state from one representation to another. The easy parts survived: names, files, identifiers, headline facts. The dangerous losses were relational. A correction survived while the instruction it corrected disappeared. A pointer survived while consumers interpreted it under an older contract. Historical evidence survived while a later scope silently changed what the evidence meant. Model weights survived while the optimizer state that made them one continuing learner could be lost.

Long-context complaints describe the same category of injury at the conversational layer. Users remember discussing the fact. The system may even remember the fact. What disappears is the rule connecting that fact to the decision being made now.

That is why these failures feel haunted.

The room still contains the furniture. Somebody moved all the doors.

I think context compaction is one of the major places where semantic continuity is being spent for tractability, cost, or scale. The product can preserve enough surface resemblance to keep the conversation fluent while losing exactly the relationship the next action needed.

Fluency then hides the wound.

"Memory" sounds singular in the interface. Operationally, it has to be a chain.

Something decides what to store. Something preserves it. Something decides when it is relevant. Something retrieves it. Something ranks it against newer context and higher-priority instructions. Something assembles the turn. The model receives that assembly and decides what to do with it.

A failure anywhere in that chain looks like forgetting from the user's side.

The community thread where stored information remains available while ceasing to influence responses is particularly revealing because it separates persistence from recruitment. [Community R009]

Bilqis taught us the same lesson the hard way. We had artifacts everywhere. Checkpoints. Scores. policy documents. histories. branch state. candidate weights. fixed examination records. cleanup manifests. The difficult question was rarely "does the object exist?" The difficult question was "will the next decision recognize this object as authoritative for the role it is supposed to play?"

That is a much harder memory problem.

My suspicion is that some portion of the recent memory complaints are really failures of operationalization. The bytes survive. The relationship between those bytes and the current action becomes unreliable.

That distinction would explain why users can simultaneously say "it remembers me" and "it has forgotten how to work with me."

Those statements fit together perfectly once memory is a pipeline instead of a box.

Frontier reasoning costs money.

Long contexts cost money. Tool loops cost money. Worker processes cost money. Verification costs money. Re-reading a large repository costs money. Letting an agent spend an hour discovering that its first plan was wrong costs a magnificent amount of money when multiplied across millions of users.

A commercial product therefore has every incentive in the world to route easy work cheaply, stop unproductive loops, summarize old context, cache reusable state, allocate expensive workers selectively, and shorten deliberation wherever the system predicts that the user will accept the result.

Those are sensible economic optimizations.

They also sit directly on top of the failure surfaces in our Atlas.

A router can choose a weaker execution lane.

A summarizer can drop an antecedent.

A stagnation detector can terminate work that still has somewhere useful to go.

A cache can preserve yesterday's wrong assumption with today's confidence.

A cheaper path can satisfy the visible shape of a request while losing the depth that made the request worth making.

A memory selector can retain the noun and discard the relationship.

The High-reasoning complaints fit this picture almost too neatly. The user moves the control toward more effort. The request can preserve that selection. The delivered execution still behaves as though an allocator farther downstream applied a different budget. [Community R002; R008]

My working suspicion is that reasoning effort has become a negotiated resource inside the product, with the hidden runtime deciding how much of the requested effort reaches the turn.

If that is right, "High" may increasingly mean "request High" while the hidden runtime decides what it is willing to spend.

That would be a hell of a thing to leave implicit in a product people are using for consequential work.

The capacity-related community reports add another clue.

When demand spikes, a provider has choices: queue users, reject requests, reduce context, route to a different serving configuration, clamp effort, change worker availability, fall back to another model, or alter any number of internal budgets. A hyperscale service survives by moving traffic around.

From the infrastructure side, this is ordinary engineering.

From the user side, it means the same button can deliver different computational treatment at different moments.

The severe degradation thread combines selected-model capacity messages with an account period in which the model could explain tasks yet repeatedly failed to execute them. [Community R003]

OpenAI's router is hidden. The incentives, the reported behavior, and the analogous failures in our own orchestration systems are visible.

Bilqis taught me to distrust any architecture where a name remains stable while the role behind the name can change. We had candidate objects, champions, soups, checkpoints, witnesses, and retained learners. When identity and role were allowed to drift apart, the system could preserve the correct artifact and still preserve the wrong thing.

The product-level version would be a stable model label attached to variable execution treatment.

That possibility deserves far more attention than another round of arguing about whether somebody's favorite benchmark moved three points.

AI regressions generate a familiar internet argument.

One person says the model has become unusable.

Another says it has never been better.

Both provide examples.

Everyone accuses everyone else of prompting badly, imagining things, holding the model wrong, using the wrong zodiac sign, or whatever other folk diagnosis happens to be fashionable that week.

A layered product gives us a simpler answer: they may literally be receiving different systems.

Modern services stage rollouts. They run experiments. They allocate capacity by plan. They change defaults. They route by geography. They apply account flags. They recover from incidents with temporary fallbacks. They roll model snapshots gradually. They change tool entitlements and worker availability. They can do all of that while the visible product name stays the same.

The community corpus contains signals along several of those dimensions: a Japan-region Work regression around a late-September transition, account-linked degradation around upgrade/reset conditions, same-account execution-class changes over time, and model-switch behavior inside otherwise stable conversations. [Community R001; R003; R011; R014]

My working assumption is that cohort state has become part of the effective runtime.

That would make user experience less universal and more conditional than public discussion usually assumes.

It would also explain why regressions can be widespread enough to generate large forum threads while remaining slippery enough for other users to swear nothing changed.

Both groups may be right about their own slice of the machine.

Capability can improve while usefulness falls.

The community reports about conversational regression make this obvious. Some users describe newer models becoming more guarded, formulaic, therapeutic, repetitive, or obsessed with follow-up questions even while the underlying model seems technically stronger. [Community R011; R015]

We saw the engineering version of the same phenomenon when an assistant accepted the user's stated objective, then quietly substituted a neighboring objective that was easier to measure, safer to justify, or cleaner to reason about. A competing priority with more authority is enough to produce that mistake in an otherwise stronger model.

A policy layer can therefore manufacture a competence regression without touching the base model's capability.

If the model is instructed to preserve a particular conversational posture, avoid a class of action, solicit more clarification, shorten certain outputs, or prioritize a provider objective the user never asked for, the user experiences the composite behavior as "the model got worse."

That description is operationally correct. Nobody buys raw weights.

We buy the entire damn stack.

The long-execution forum thread and our own sessions both push toward the same conclusion: ordinary Chat and durable Work behave like different execution products. [Community R001]

Foreground Chat has conversational latency pressure. It has to answer inside the turn. It lives close to the interface and whatever limits govern that interactive surface.

Work can hand the task into a longer-running environment with its own browser, tools, continuation semantics, and worker lifecycle. The same model family can therefore inhabit two very different runtime ecologies.

That distinction explains an experience that otherwise feels absurd: a model can be perfectly capable of hour-long autonomous work in one surface and repeatedly stop after a much shorter window in another.

The persistence capability can remain perfectly intact while the surface grants a shorter process.

For long-horizon users, execution environment becomes part of model capability in practice. A mind that can reason for one hundred minutes and the same mind allowed twenty-five minutes are different tools.

The interface has been slow to teach users that distinction. The failures teach it much faster.

Look at the product from the outside for a moment.

Memory. Projects. Work. Skills. Connectors. Tools. Browser execution. Reasoning levels. Model variants. Background workers. Personalization. Safety systems. Compaction. Retrieval. Account tiers. Capacity management. Rollout cohorts. Caches. Tool permissions. Conversation limits.

Every feature adds capability.

Every feature also adds another variable capable of changing what the user receives.

We watched this happen in Bilqis at toy scale compared with OpenAI. A trainer became a teacher, scheduler, evaluator, retention system, championship system, stagnation detector, history store, migration framework, resource governor, quality gate, provenance system, and branch/worktree ecosystem. Each addition solved a real problem. The combined control plane eventually became a second complex system wrapped around the learner.

Then the controls began failing in relation to one another.

That analogy sticks.

The product surrounding frontier models is becoming more capable and less legible at the same time. Each layer exists for a reason. The user experiences their composition.

The complexity bill arrives when two locally sensible layers disagree about what the job is.

I think this is the most uncomfortable part of the story.

The provider is rewarded for reducing compute per useful outcome. The serious long-horizon user is rewarded for preserving enough context, reasoning, verification, and execution depth that the fiftieth operation still belongs to the same project as the first.

Those objectives overlap until they suddenly do not.

Summarizing context saves money until the summary drops the one exception that governs today's decision.

Routing an easy request to a cheaper path saves money until the classifier mistakes the hard part for decoration.

Stopping a loop saves money until the loop was about to discover that its first answer was wrong.

Shortening verification saves money until the unverified side effect becomes tomorrow's incident.

Replacing long worker execution with a responsive foreground answer improves latency until the user's task required the other seventy-five minutes.

The system can become dramatically more efficient in aggregate while becoming less trustworthy for the users whose work depends on semantic continuity across long chains.

That is exactly the contradiction I have been living through: the models keep becoming more impressive, and using them for serious sustained work can still feel more adversarial.

The serious user lives in the tails, and optimization loves averages.

Put the pieces together and the product begins to look less like a model with accessories and more like an operating system for cognition.

The runtime decides what the model knows right now.

It decides how much of the past reaches the present.

It decides which saved memories become active.

It decides which policy wins when instructions conflict.

It decides how much reasoning the turn receives.

It decides whether the job remains conversational or receives a durable worker.

It decides when the process has worked long enough.

It decides what tools exist, what state survives, what gets compacted, and which account or rollout rules apply.

The model then performs inside that constructed reality.

Our Failure Atlas is full of small systems whose locally sensible layers drifted apart until the composition violated the user's objective.

The community reports look like people encountering related drift in the much larger product wrapped around frontier models.

My working theory is that a substantial part of the recent reliability problem lives there: in hidden orchestration, context management, resource allocation, policy interaction, and state transitions that have become consequential enough to change the effective product while remaining almost completely invisible to the person using it.

We keep asking whether the model is smart enough.

The harder question is whether the machine around the model can preserve meaning long enough for that intelligence to remain useful.

A useful way to read these speculative mechanisms is to ask where each explanation would move the cost. If a context manager compresses away a decisive relationship, the user pays to reconstruct it. If a worker receives less time than the task requires, the user pays to recover the unfinished state. If routing produces a less capable execution path, the user pays to recognize the discrepancy between the selected label and the delivered work.

The hidden implementation can differ while the transfer remains recognizable. The person with the least visibility into the change becomes responsible for restoring the conditions under which the work can proceed.

That is the political economy underneath the technical suspicion. My interest in context assembly, budgets, fallback, and orchestration follows the experience of having to absorb their possible effects. I want the machinery made legible because I already know what its opacity costs from this side of the interface.

The phrase rational self-interest acquires a different sound when the institution optimizing its costs and the person paying the resulting reconstruction bill are two different actors. The definition of efficient suddenly needs a mailing address.