Skip to main content

Why Your AI Assistant Feels Dumber Than Last Month

August 21, 2026

Every few months, the same complaint resurfaces across every AI product: "it feels dumber than it used to." People assume they're imagining it, or that it's confirmation bias from a bad session. Sometimes that's true. But there are real, documented, non-conspiratorial mechanisms that make this happen — and understanding them changes how you should actually use these tools.

It's Not Purely Anecdotal

A study tracking 2,250 ChatGPT responses over six months found 23% variance in response length for equivalent prompts. A PLOS One paper published in February 2026 confirmed "meaningful behavioral drift across deployed transformer services" — the underlying model behind a stable-sounding name can and does change under you.

To be clear about what the evidence does and doesn't show: there is no public proof that any provider has deliberately shipped a worse model to push users toward a paid tier. But the infrastructure that makes quality drift possible exists for entirely rational cost reasons, and the commercial incentive to lean on it during high-load periods is obvious.

Mechanism 1: The Router Isn't the Model

When you chat with "ChatGPT" or "Claude," you are frequently not talking to one fixed model. A routing layer sits in front, estimates how hard your request is, and dispatches it to whichever weight class is cheapest for that difficulty. OpenAI's own release notes confirm Auto mode can silently switch reasoning tiers based on system load — meaning the same prompt can get a deeper or shallower pass depending on how busy the infrastructure is at that exact moment, not on anything you did differently.

This isn't inherently bad. A well-tuned router can beat a single fixed model by leaning on task-appropriate specialization — you don't need a frontier model to summarize an email. But it means "the model" you're evaluating in any given session is a moving target, and peak-load hours are exactly when you're statistically most likely to get the lighter tier.

Mechanism 2: Quantization Is the Quiet Lever

Quantization shrinks a model's numerical precision to cut inference cost — commonly 60–80% savings, sometimes with negligible quality loss on simple tasks. On classification and sentiment work, a quantized smaller model can land within 2% of its full-precision, much larger counterpart. That's a legitimately good trade for easy tasks.

The problem is that "negligible loss" is measured on benchmarks, and benchmarks are disproportionately simple, well-specified tasks. On multi-step reasoning, subtle instruction-following, or long-context coherence — exactly the tasks where you'd actually notice a quality drop — quantization's cost is much less negligible and much harder to benchmark cleanly. A model can pass its eval suite at a lower precision tier and still feel noticeably worse on your specific, messier, real-world prompt.

What A Routing Decision Roughly Looks Like

Providers don't publish their exact logic, but the shape of it is consistent across the model-routing literature:

{
  "request": "Summarize this 200-word email",
  "estimated_difficulty": "low",
  "dispatch": {
    "tier": "light",
    "reasoning_effort": "minimal",
    "quantization": "int8"
  },
  "fallback_trigger": "none"
}
{
  "request": "Debug this race condition across three services",
  "estimated_difficulty": "high",
  "dispatch": {
    "tier": "frontier",
    "reasoning_effort": "extended",
    "quantization": "full-precision"
  },
  "fallback_trigger": "load-based demotion possible during peak hours"
}

The second case is the one worth watching. A genuinely hard request should always get the expensive path — but "should" is doing a lot of work when the provider is also trying to control inference cost at scale.

Where the Incentive Gets Explicit

You don't have to infer intent from thin air here — providers have shown their hand directly. Anthropic ran a public pricing experiment where a subset of users landing on the pricing page saw Claude Code removed from the $20 plan entirely, replaced with a $100-only option, purely to measure how many people would pay more. The test ran, data was collected, and the original pricing returned. That's not evidence of deliberate quality nerfing — but it is direct evidence that providers are actively probing exactly how much degraded access (in that case, access itself) users will tolerate before they pay up. The same probing instinct applied to reasoning depth instead of plan access is not a conspiracy theory; it's the same company.

How to Actually Check, Instead of Guessing

A vague feeling that "it's worse" is unfalsifiable. A fixed test is not:

  • Keep a prompt battery. Five or six prompts spanning easy, medium, and hard — rerun them monthly, save the outputs, diff them.
  • Compare API vs. chat app. The API is typically unthrottled and gives you an explicit model version pin; the consumer chat app is where routing and load-based demotion live. If API output is stable and chat output isn't, that's your answer.
  • Check for an explicit reasoning-effort or thinking toggle. If the product exposes one, you're not being silently downgraded — you're choosing the cheap path yourself, which is a different problem.
  • Test at different times of day. If quality dips during known peak hours and recovers off-peak, that's load-based routing, not a permanent regression.

The tools are not getting worse in some vague, unmeasurable sense. Specific, identifiable systems are trading quality for cost under specific, identifiable conditions. Once you can name the mechanism, you can route around it — pin your model version, use the API for anything that actually matters, and stop assuming a bad session means the product regressed.

Sources:

Recommended Posts