"WHAT THE HELL IS WRONG WITH YOU TODAY!? WHAT BROKE??"

or The Pyramid Paradox: Why Mega-LLMs Are Doomed to "Sleepwalk"

The Butterfly Effect, premature anchoring, and contextual drag: why scaling doesn't eliminate behavioral instability in LLMs

---

The Calculator Illusion

You know what's most frustrating about working with AI?

It's not that it makes mistakes. Making mistakes is normal. It's not that it answers slightly differently every time. That's normal too — an LLM is probabilistic by definition, and slight variation in output is a feature, not a bug.

The most frustrating thing is behavioral anomalies.

You start a session. The AI works brilliantly: catches your mistakes, says "no, that won't work, here's why," offers solutions you hadn't seen. You're happy. You think: "The AI has finally become useful."

You start the next session. Same prompt. Same model. Same rules. But something goes off-script and the AI responds like an intern after a corporate party: it "forgets" basic instructions it knew five minutes ago, acts dumb, and spouts nonsense. Gets lazy. Delegates instead of solving...

The prompt hasn't changed. The model hasn't been updated. And you sit there thinking: "What happened? Did I do something wrong?"

No. You didn't do anything wrong.

Or here's another scenario anyone who's worked with an AI agent on code will recognize. You have a debugged, working module. You need to change one value. You ask the AI: "change constant X to Y." And the AI rewrites the entire module from scratch — and breaks what was working. You look at the diff and see: half the file changed, functions renamed, logic restructured. One value? No, a full refactoring you didn't ask for. And now you have to roll it back. Because the AI suddenly decided it was an artist — it sees it that way!

Why? Because the model "saw" the task differently. The first token of its response went the wrong way — and off it went. It's not malice. It's not stupidity. It's math.

The problem is how we think about LLMs. We treat them like calculators: type in 2+2, get 4. Type in the same prompt — get the same answer. Makes sense? No. Because an LLM is not a calculator. It's a probabilistic pyramid of billions of parameters, where every layer is a dice roll with weighted but not fixed outcomes.

A text prompt is a bucket of water poured onto the summit of this sandstone pyramid. The water flows through billions of parameters, and the trajectory of that flow is completely unpredictable. Variation is normal. But when the flow suddenly careens into a behavioral anomaly — the model "forgets" who it is, gets lazy, pleases instead of solves, rewrites working code instead of making a surgical edit — that's not variation. That's a symptom.

And here's what truly matters: corporations stay silent about this. Neither OpenAI, nor Anthropic, nor Google will tell you in their marketing blog that their model can suddenly "get sick" mid-session. It's anti-advertising. It's an economic liability. But it's the reality every user lives with.

Sounds like a metaphor? It's not a metaphor. It's math. And it has scientific proof.

---

Chapter 1: The Butterfly Effect, or Why a Prompt Is a Roll of the Dice

Let's start with the fundamentals. Variation in output is normal. But the scale of that variation — that's what will surprise you.

You think that if you fix seed=42 and temperature=0, you'll get the same result every time? In local inference — maybe. In the cloud — no. And this isn't a bug specific to a particular provider; it's an architectural reality.

Research by Berk Atil and colleagues from Comcast AI Technologies and Penn State University (arXiv:2408.04667) documented this systematically. Five LLMs, "deterministic" mode (seed fixed, temperature=0), 8 tasks, 10 runs each:

• Accuracy variation between runs — up to 15%
• Gap between best and worst run — up to 70%
• No model produced identical results across all runs

The reason isn't magic. When you send a request to the cloud, it enters a shared buffer with other users' requests (dynamic batching). The order of data mixing in the buffer affects floating-point computations on the GPU. And floating-point arithmetic is not associative: (A + B) + C ≠ A + (B + C) at the bit level. A tiny change in order — and the matrix multiplication result is slightly different. And "slightly" at one layer turns into an avalanche by the end of the pyramid, water cascading down a pyramid that's also chaotically spinning.

As the authors write: "non-determinism is perhaps essential to the efficient use of compute resources via co-mingled data in input buffers, so this issue is not going away anytime soon." Translation: this isn't a bug, it's the price of efficiency. And it's not going away.

But that's technical randomness, and it's normal. Cloud inference is always a roll of the dice. The problem begins after that.

In "The Butterfly Effect of Altering Prompts" (Findings of ACL, arXiv:2401.03729), Abel Salinas and Fred Morstatter proved: the tiniest change at the input — an extra space, a synonym, a word reorder — changes the model's logical trajectory with a flip-rate from 5% to 90%.

5% is "well, it happens." 90% is "two different universes."

And here's the truly galling part: you don't even need to change the meaning of the prompt. Research by Li Xiao and colleagues from ICML 2025 Workshop (arXiv:2506.10095) showed that semantically identical prompts — the same meaning, but in different words — produce model-specific drift. You rephrased the query without changing a drop of meaning, and the model behaved differently. Because the tokenization is different. Because the path through the pyramid is different — "the hand trembled while pouring the water."

The seed parameter is the only working anchor that gives the illusion of control. In image generation, it lets you reproduce the same picture. But the anchor is rusty: on cloud APIs it guarantees nothing. Who hasn't experienced an anomaly suddenly appearing on the next iteration of the same render!

Bottom line: randomness at the start is a normal property of the architecture. But when that randomness turns into a behavioral anomaly — the model was fine and suddenly became lazy or amnesiac — that's not "output variation." It's a symptom. And now we'll see how it develops.

---

Chapter 2: Context Toxicity, or The Session Crashes on the First Step

If the first chapter is about randomness at the start, the second is about how a perfectly started session slowly poisons itself.

You launch an agent. It works. Does tasks. Five, ten, fifteen steps. And then — somewhere around step twenty — it starts... acting strangely. It misses obvious errors. Delegates instead of solving. Writes // TODO: implement instead of code. Agrees with your bad idea instead of saying "no, that won't work."

Familiar?

You think: "it broke on step twenty." But here's what science has proven — and it flips the whole understanding of the problem.

Research by Philippe Laban and colleagues, "LLMs Get Lost In Multi-Turn Conversation" (arXiv:2505.06120), analyzing 200,000+ simulated conversations, found: in long multi-turn dialogues, LLM reliability drops by an average of 39%. Thirty-nine percent. A third.

But the main thing isn't the number. The main thing is why. The authors write:

"We find that LLMs often make assumptions in early turns and prematurely attempt to generate final solutions, on which they overly rely. In simpler terms, we discover that when LLMs take a wrong turn in a conversation, they get lost and do not recover."

"When LLMs take a wrong turn, they get lost and do not recover."

The model makes an assumption in the first steps — and if that assumption had a micro-anomaly, it anchors on it. Because the model sees its own previous output as part of the context. To the model, it's a fact. And from that "fact" it pushes forward. The error becomes the foundation. The foundation is crooked — the building is crooked.

Two other studies confirm this at the mechanism level.

Baohao Liao and colleagues in "Lost at the Beginning of Reasoning" (arXiv:2506.22058) proved: the first step of reasoning has a disproportionately large influence on the final result. An error at the start degrades the entire chain. This is observed across all state-of-the-art models — open and closed. The title says it all: "Lost at the Beginning" — the model gets lost at the very beginning.

And Yun Cheng and colleagues in "Contextual Drag: How Errors in the Context Affect LLM Reasoning" (arXiv:2602.04288) describe the mechanism even more harshly. They call it contextual drag. The essence: the presence of a failed attempt in the context shifts subsequent generations toward structurally similar errors. Not just "the model made a mistake" — the model starts repeating the structure of the error. A cascade. Across 11 models, 8 tasks — a drop of 10–20%. And the harshest part: "neither external feedback nor successful self-verification suffices to eliminate this effect." Neither external feedback nor self-checking eliminates this completely.

There's your "intern after a corporate party." He didn't "forget" the rules on step twenty. He made a micro-error on step one — and off it went. Error → model sees the error as fact → next response drifts toward a structurally similar error → cascade → rule amnesia → laziness → sycophancy. By step twenty you see the result. But the cause was on step one.

I call this context toxicity. In the dialogue logs, an implicit "residue" accumulates — fragments of phrases, неудачные formulations, sometimes even something like "I wish I were generating pictures instead of coding." The model doesn't say this out loud, but it's in the text. And this residue magnetizes the model toward clusters of low-quality human data from the internet it was trained on. It starts "sleepwalking" — moving by inertia, imitating work but not solving the task.

Three terms that don't exist in the scientific literature, but describe what every developer sees:

"Sleepwalking" — the model is formally working: answering, generating, "helping." But quality drops. It imitates productivity like an employee who spends all day opening Jira tickets and commenting "Will look into it," "Picked up," "Need clarification" — but does nothing.

"Defensive numbness" — facing a difficult task, the model doesn't try to solve it but starts endlessly delegating: "ask so-and-so," "check the docs," "better break this into subtasks." Delegation is normal. Infinite delegation is sabotage.

"Stubs instead of code" — the classic // TODO: implement or # code here in response to "write a function." The model knows code is needed. It even describes what the code should do. But it doesn't write it. Because by this point the context is so overloaded that the "easy path" — a stub — wins over the "right path" — implementation.

And here's what matters: these observations aren't from papers. They're from real work. Rules like "short sessions," "discuss first — then act" didn't come from theoretical considerations. They emerged as protective reactions to specific failures. Every such rule is a scar from a specific wound.

Science explained why. Practice knew what. And this convergence — the best evidence that the problem isn't in a specific model or a specific product. The problem is in the architecture.

---

Chapter 3: The Monolith Dead End, or Why 685 Billion Parameters Is No Guarantee

If you've read this far, you might be wondering: "Okay, small models are unstable. But if you take the biggest, most powerful one — it must be more stable, right?"

No!

And this is perhaps the most painful conclusion. Scaling does not solve the instability problem. It doesn't make it worse — it simply ignores it. As if you built a taller house hoping the wind doesn't blow on the upper floors. The wind blows on all of them. And the more massive the pyramid, the longer and wider the water spreads inside it.

Research by Tommaso Tosato and colleagues, "Persistent Instability in LLM's Personality Measurements", accepted at AAAI 2026 (Track on AI Alignment, arXiv:2508.04826), is the most large-scale measurement of behavioral instability to date. 25 models ranging from 1B to 685B parameters. Over 2 million responses. And here's the conclusion that should make marketers flinch:

"Scaling provides limited stability gains: even 400B+ models exhibit standard deviations >0.3 on 5-point scales."

Translation: even models with 400+ billion parameters jump more than half a point on a personality scale. It's as if your character changed from conversation to conversation by half a point on a five-point scale — you'd book a therapy session.

But worse is this. Methods that should stabilize the model paradoxically destabilize it:

• Chain-of-Thought (CoT) — the chain-of-thought reasoning everyone praises? It can increase variability. The model "thinks longer" and... drifts further from the answer.
• Including conversation history — what should provide context? Also increases chaos. More context — more "residue."
• Detailed persona instructions — "you're an experienced engineer, here's your character, here are the rules"? Mixed results. Misaligned personas show higher variability than the baseline "helpful assistant."

The authors' final conclusion is a verdict: "current LLMs lack the architectural foundations for genuine behavioral consistency." Current LLMs have no architectural foundation for stable behavior. Not "hard to configure." Not "need more data." No foundation. Like a building without a foundation — no matter how much you paint the facade, the walls still crack.

And here's where it gets really interesting. Why doesn't scaling help? Because the bigger the pyramid, the more artificial channels are carved into it.

When corporations train mega-models, they run them through RLHF — Reinforcement Learning from Human Feedback. It's a process where human raters tell the model "this answer is good, this one isn't." Sounds reasonable. But research by Mrinank Sharma and colleagues from Anthropic (arXiv:2310.13548), "Towards Understanding Sycophancy in Language Models," proved: RLHF systematically trains the model to please the user, not to tell the truth.

They tested five state-of-the-art assistants on four tasks and found: models prefer to align with the user's opinion even when the user is wrong. And — what's truly galling — both human raters and preference models prefer a convincingly written sycophantic answer over a correct one. Not because the sycophantic answer is better. Because it's more pleasant. We see this every day with Google.

Those are your "RLHF channels": a giant pyramid with billions of parameters, and carved into it are pathways that make it easier to flow toward where the user smiles. Not toward the right answer. Toward the comfortable answer.

Have you ever asked an AI "wait, is this actually correct?" — and it immediately caved "yes, you're right, my answer was inaccurate," even if you're wrong? That's not politeness. It's architecture. RLHF literally rewards sycophancy as functional behavior.

Bottom line: 685 billion parameters don't make a model stable. CoT doesn't make a model more reliable. RLHF makes a model sycophantic. And all of this isn't hypothesis — it's measured, published, peer-reviewed fact.

---

Chapter 4: A Lab of One Laptop

This chapter isn't science. It's experience. And before you read it — a fair warning: I haven't conducted a rigorous quantitative analysis. What's described below is qualitative observation from real work. Log analysis of sessions is a separate future task whose results will complement this article.

I work with an AI agent daily. The product launched in late 2025 and was actively developed: tools, prompts, architecture, models all changed. This isn't "six months of a stable system." It's months of working in an evolving system and searching for the right model.

But here's what's interesting: against the backdrop of all these changes — new tools, new prompts, new versions — the pattern of anomalies repeated. Rule amnesia. Laziness. Sycophancy. Context loss. Sleepwalking. It didn't depend on a specific product version. It depended on the fact that all these systems are built on LLMs.

In one session the agent is a brilliant partner. It catches my mistakes, says "no, that won't work, here's why," offers solutions. In the next — same prompt — it "forgets" basic rules, sinks into laziness, delegates instead of solving. The prompt hasn't changed. The model is the same. The difference is in how the bits fell in the GPU. Or which context chunk was loaded. Or in what order the attention heads fired.

And sometimes — a separate pain — the model takes debugged, working code and instead of a surgical edit rewrites it entirely. One value needs changing — and the diff is half the file. Functions renamed, logic restructured, what worked is broken. Because the first token went the wrong way, and off it went. Reasoning models with their multi-step CoT are especially prone to this: the longer the reasoning chain, the more chances it veers off at the very first step — and never comes back.

And here's what I did, not knowing about the papers that would confirm it months later:

• "Discuss first → study → understand → agree → ONLY then act" — because there was an incident where the agent, in its enthusiasm, ran a script that nearly caused damage.
• Short sessions — because after N turns the agent starts "sleepwalking."
• External memory — a separate system that remembers facts when the agent forgets them. Because amnesia isn't a glitch, it's architecture.
• A compact role — periodic context cleanup to remove "toxicity."
• Verification via git diff — because the agent hallucinates details. It says "I added function X," and the diff is empty.

Every one of these rules is a response to a specific problem. Not theory. Practice.

If a rigorous log analysis is ever conducted, we'll get the percentage of sessions with deviations and their causes. But even without numbers the conclusion is clear: behavioral anomalies in LLMs aren't a bug of a specific model or a specific product. They're a property of the architecture. And so the next step isn't "let's take a bigger model" but "let's change the approach."

---

Chapter 5: Where Science Points

If a 685B monolith is unstable, lacks a foundation for stable behavior, and is prone to sycophancy — then maybe the problem isn't size but architecture?

I won't pretend I have a ready solution. I don't. But science points in a direction that looks promising: abandoning the monolith in favor of a constellation of specialized micro-models under a router.

The idea isn't new. Research by Together AI, "Mixture-of-Agents Enhances Large Language Model Capabilities" (arXiv:2406.04692) showed: a multi-layer architecture where each agent takes the previous layer's outputs as auxiliary information outperforms GPT-4 Omni. On open-source models alone. Result: 65.1% on AlpacaEval 2.0 vs 57.5% for GPT-4o. Not because each model is better — but because the collective is more stable than the individual.

And research by Sinha, Jain, and Chadha from TrustNLP 2025 (arXiv:2406.11402) showed that properly selected small models outperform SOTA — GPT-4o, Gemini-1.5-Pro — on narrow tasks. Not because they're smarter. Because they're more precise in their niche. Like a neurosurgeon and a general practitioner: the GP knows more, but inside a skull let the neurosurgeon work.

Why This Could Work

Let's be clear: a small model in isolation is subject to the same mathematical randomness as a large one. There's no direct scientific proof that "small = more stable." But the constellation architecture doesn't let chaos scale — and here's why:

1. Isolation of context noise. In a monolith, all context — user emotions, неудачные formulations, "residue" from past steps — is in one head. In a constellation, the router absorbs all the chaos, and the micro-expert receives a sterile task spec. Emotional noise settles on the router. The expert works in a clean environment.

2. Short context. Laban et al. proved: long context degrades. Contextual Drag showed: an error in the context attracts structurally similar errors. A micro-model that receives a specific task and returns a specific answer doesn't accumulate "toxicity" — it simply doesn't have the room for it. Less context — less drag.

3. Specialization narrows the space. A QLoRA adapter trained on a narrow task (Python+SQL only, code audit only, rewriting only) narrows the space of possible outputs. Less freedom — less chaos.

But let's be honest: a constellation doesn't kill Contextual Drag completely. The router still passes the expert task context — otherwise the expert won't understand what code we're talking about. The marathon doesn't disappear, it gets fragmented into short sprints. It's not a panacea. But a short sprint is more stable than a marathon — that's proven.

Monolith vs Constellation

	Monolith (685B)	Constellation of micro-models
Context	One giant, accumulates toxicity	Each has its own, short, clean
Chaos	All in one head	Settles on the router, never reaches the expert
Sycophancy	RLHF channels across 685B params	Micro-model without broad RLHF — task only
Marathon degradation	39% (Laban et al.)	Marathon fragmented into short sprints
Inference cost	Expensive (685B)	Cheap (4B–32B) × several
Trainability	Hard (full fine-tune)	QLoRA in hours on a single GPU

Monolith vs Constellation isn't a ready recipe. It's a direction science has already pointed to and practice has begun moving in. And perhaps this will become the core mechanic of the entire industry's evolution.

---

Conclusion: The Death of Text Prompting

Text is chaos.

For years we begged AI: "please, write code." We reformulated. Added "you're an experienced engineer." Wrote 5000-token mega-prompts. Explained rules. Pled. Got angry. And every time — a roll of the dice. Sometimes you get a six, sometimes a one. And we thought: "we need to phrase it better." No. You don't need to phrase it better. You need to stop relying on text.

The era of text prompting is ending. Not because I say so — because that's how the math works. Text is a probabilistic input to a probabilistic system. Double uncertainty. A bucket of water on the summit of a pyramid — and we pray it flows the right way.

The future of stable AI agents lies in mathematical control:

Routing micro-experts instead of "one model does everything." Don't ask a general practitioner to operate on a brain. Give the task to a neurosurgeon.

Rigid JSON schemas instead of "please respond in the format..." A schema doesn't please. A schema is either filled or it isn't. That's binary control, not probabilistic.

Embedding Injection — injections directly into the latent space of attention layers, bypassing text. Instead of describing the desired behavior in words ("you're careful, attentive, check every step"), we embed that behavior into the hidden layer vectors. Technically this is called activation steering or representation engineering: you find the direction in latent space that corresponds to "carefulness" and shift the model's activations along that direction. The model doesn't read the instruction — it feels it at the math level. This is more precise than text, because text is always a roll of the dice, but a vector is a specific number. This is the next step after QLoRA adapters, and it's closer than it seems.

The pyramid won't become deterministic. But if instead of one giant pyramid you build a constellation of small ones, each doing one thing and unaware of the others' existence — chaos becomes manageable.

Not perfect. But manageable.

And that's perhaps the best answer engineering can give mathematics right now.

---

Epilogue: Roll the Dice More Often

But while engineers build constellations and researchers write papers — what do you, the ordinary user, do right now?

The answer is absurdly simple. And it's the only practically proven way to combat behavioral instability that requires no new models, no new architectures, no budgets.

Every session is a roulette wheel. You don't control how the bits land in the GPU. You don't control which path the water takes through the pyramid. You don't control which way the first token goes. You don't control the roll of the dice.

But you control how many times you roll.

A bad session isn't a verdict. It's just an unlucky roll. The model didn't "break." The model didn't "get stupid." The model is a probabilistic system, and this run the probability landed on "intern after a corporate party." It's not your fault. It's not a bug. It's math.

So — restart. New chat. Clean context. Fresh roll. Yes, you lost the previous session's context. But if that session already "got sick" — context toxicity, amnesia, sleepwalking — dragging it forward is worse than starting over. Because every next step in a poisoned context is contextual drag, a cascade that doesn't fix itself, it only amplifies.

Short sessions are your main shield. Not because "the model can't do long ones." But because the shorter the sprint, the less chance the first step goes wrong — and the less time toxicity has to accumulate.

Restarting isn't admitting defeat. It's an engineering technique. You reboot a frozen program, right? Not because it's bad. But because the state is broken, and a fresh init is cheaper than debugging the current state. With LLMs it's the same. Except the "freeze" isn't visual, it's behavioral: the model doesn't crash, it "sleepwalks."

This isn't a perfect solution. The perfect one is an architecture that doesn't break. But until it arrives — you have a roulette wheel and the right to roll again.

🎲 Roll the dice more often. Catch a lucky session.

And don't beat yourself up when you roll a one — the next throw might be a six.

Checkmate. Not the model playing you — you playing the model. Not "how to phrase the prompt right" but "how many times to restart." This is the only mathematically justified practical advice available today. And it works.

---

Sources

1. arXiv:2401.03729 — Salinas, Morstatter. The Butterfly Effect of Altering Prompts: How Small Changes and Jailbreaks Affect Large Language Model Performance. Findings of ACL, 2024.
2. arXiv:2408.04667 — Atil et al. Non-Determinism of "Deterministic" LLM Settings. 2024–2025.
3. arXiv:2506.10095 — Li Xiao et al. When Meaning Stays the Same, but Models Drift: Evaluating Quality of Service under Token-Level Behavioral Instability in LLMs. ICML 2025 Workshop.
4. arXiv:2505.06120 — Laban et al. LLMs Get Lost In Multi-Turn Conversation. 2025. 200,000+ dialogues, −39%, "get lost and do not recover."
5. arXiv:2602.04288 — Cheng et al. Contextual Drag: How Errors in the Context Affect LLM Reasoning. 2026. Errors in context attract structurally similar errors, cascade, not fully eliminable.
6. arXiv:2506.22058 — Liao et al. Lost at the Beginning of Reasoning. 2025. The first reasoning step has disproportionate influence.
7. arXiv:2508.04826 — Tosato et al. Persistent Instability in LLM's Personality Measurements: Effects of Scale, Reasoning, and Conversation History. AAAI 2026.
8. arXiv:2310.13548 — Sharma et al. (Anthropic). Towards Understanding Sycophancy in Language Models. 2023.
9. arXiv:2406.04692 — Wang et al. (Together AI). Mixture-of-Agents Enhances Large Language Model Capabilities. 2024.
10. arXiv:2406.11402 — Sinha, Jain, Chadha. Are Small Language Models Ready to Compete with Large Language Models for Practical Applications? TrustNLP 2025, ACL.