Why Your AI Coding Tool Feels Different Week to Week
Your AI coding assistant didn't get worse overnight. Seven hidden levers, from effort defaults to automatic model routing, change how it behaves.
Every few weeks the same complaint goes round on Reddit and Twitter: my AI coding assistant has gotten dumber. The replies usually split into two camps. Camp one: the vendor secretly downgraded the model. Camp two: it's all in your head. Both are usually wrong. What actually changed is one of seven invisible levers behind the scenes - and the vendors mostly don't tell you when they move them.
What changes when nothing changes?
The model itself (the weights inside Claude Opus - Anthropic's flagship model line for complex reasoning - or GPT-5, Gemini, whatever you're using) is shipped on a release schedule that the vendor announces. New version, new name, new docs. So far, so transparent.
What doesn't get announced is the operational stack around the model. That's the layer that decides how much thinking the model is allowed to do per request, how long it can keep your previous turns in fast cache, when it summarises (and partly forgets) older context, and what happens when the platform hits an internal incident. Move any one of those dials and the same model feels measurably different to use, even though the underlying weights are bit-for-bit identical.
Anthropic itself acknowledged this dynamic in a 2025 quality postmortem after a wave of "Claude got dumb" complaints turned out to map to infrastructure changes, not the model.
Order roughly by how often each one is the actual culprit when you notice a bad day.
Effort defaults
Most hosted assistants run at one of several "effort levels" - low, medium, high. Lower effort spends less compute per request and produces faster, cheaper, lighter answers. Vendors quietly shift the default level for free tiers, busy hours, or specific tasks. The model is the same; the budget it gets to spend is not.
Model routing
Some assistants now choose the model for you. Pick an automatic or "fusion" mode and the tool decides, prompt by prompt, which model answers - and sometimes chains two or three models together. Two requests in the same session can be answered by different models, so the tool's personality shifts between tasks even when nothing has been updated.
Adaptive thinking
The model decides for itself how much reasoning to spend per request, based on its read of the task. If the task is classified as simple, it skips the deep thinking. Misclassify a complex task as simple (easy to do at the front of a conversation, before any code is loaded) and you get a shallow answer to a deep problem.
Prompt-cache duration
Big context (your whole repo, your CLAUDE.md, your design system) is expensive to send. Vendors cache it for a few minutes so follow-up turns are cheaper. Shorten that cache window from an hour to five minutes and the same coding session burns far more quota in invisible recomputation, with no visible difference in behaviour. The same pressure is pushing editors towards juggling several agents at once, as Windsurf 2.0's command center shows.
Context compaction
When a conversation runs long, the system summarises and trims older turns to keep within the model's context window. Compaction discards detail. The assistant "forgets" that you defined a helper function 800 turns ago, then writes a duplicate. You blame the model; the cause is the compaction policy.
Quota policy
When you're near a limit, you ration. You stop asking follow-up questions. You skip the long brief. You truncate the conversation. The model didn't get worse; you got more cautious about feeding it. The effect is real but the cause is your own self-throttling, not the underlying capability.
Status incidents
Brief platform-level outages, degraded inference servers, regional routing changes. Most are resolved within hours, but the user experience during the incident is markedly worse. Without a status-page habit, every infrastructure blip looks like a permanent quality drop.
Why don't vendors just tell us?
Two reasons, both of them sort of understandable.
The first is operational. Some of these levers (cache duration, regional routing) are tuned constantly based on traffic patterns. There's no clean release note for "we lowered the cache TTL on the eu-west-1 cluster from 60 minutes to 5 minutes between 14:00 and 17:00 GMT due to capacity pressure". So the change happens, and your session feels different, and there's no announcement because there isn't really a release.
The second is competitive. Effort defaults and quota policy are part of how vendors monetise. Telling users "free-tier requests now run at medium effort instead of high" is just begging for a churn event. Easier to leave that one ambient.
The result is that the public version number describes only part of what determines your day-to-day experience. The rest is undocumented and changes more often. Automatic routing pushes that further: once the tool picks the model, the version number on the box tells you which models might answer, not which one did.
What happens when the tool picks the model for you?
The newest lever is the one you hand over on purpose. GitHub Copilot Fusion (a routing mode in GitHub Copilot, GitHub's AI coding assistant) became generally available on 28 October 2026. When you select it in the model picker you are not choosing a model at all. You are choosing a system that decides, for each prompt, which models to use and how they work together. Your only dial is effort.
GitHub's changelog describes three effort levels:
- Fusion Standard leans on versatile models for everyday coding.
- Fusion High leans on more capable models for harder tasks and deeper reasoning.
- Fusion Max reaches for the most capable models for the most demanding work.
Underneath, the router runs one of three workflows. Single means one model answers directly. Cascade means a cheaper model drafts, a quality check judges the draft, and a stronger model takes over only if the draft fails. Critique means one model drafts, a second reviews it, and the first revises.
In plain English: the same question can be answered by a small, fast model on Monday and by a draft-review-revise chain of two large models on Tuesday, depending on how the router reads the task. That is a feature, not a bug. It is also exactly why the tool can feel sharper or flatter from one request to the next.
Why does routing change what each task costs?
With a fixed model, cost per request is roughly predictable: bigger prompts cost more, and that is about it. With routing, GitHub bills Copilot Fusion for each model it uses, at each model's standard rate. A task that stays on the Single path is cheap. A task that escalates through a Cascade, or goes round a Critique loop, pays for every model that touched it.
GitHub's pitch is that this averages out in your favour. It reports that Fusion Max scored within two points of Claude Code on Opus 5.5 Max in the Artificial Analysis Coding Agent Index, at about half the average API cost per task. Those are the vendor's own figures, but the logic is sound: most coding prompts are routine, and paying top-model prices for routine work is the waste routing exists to remove. Anyone who has left a premium model selected all afternoon for one-line fixes knows that waste.
The catch is variance. Your bill and your quota burn now depend on decisions the router makes per prompt, so two similar-looking days can cost noticeably different amounts.
What can admins lock down?
On team and enterprise plans the routing pool is not a free-for-all. According to GitHub, Copilot Fusion only routes to models already enabled in the organisation's model policies. Enterprise administrators can see which models it picks from, disable a model for Fusion without disabling it for everyone, and decide whether Fusion - at any effort level - is the default for their users.
That matters for the "feels different this week" problem in a new way. If your admin flips the default to Fusion, or removes a model from its pool, your experience changes overnight without you touching a setting. When a work-issued assistant suddenly behaves differently, ask whoever manages the Copilot policy before blaming the model.
Is convenience worth losing predictability?
For most everyday coding, yes. Choosing a model per task is a chore most people do badly: they pick the strongest one for a hard problem and forget to switch back. A router that makes that call every prompt removes a decision you were probably making on autopilot anyway.
The trade-off bites in three situations:
- Debugging the tool itself. If an answer looks wrong, you need to know whether a different model gave it. With routing on, "same prompt, same model" is no longer guaranteed, so pin a specific model before you compare runs.
- Reproducible work. Code generation you plan to re-run, document or audit is easier to reason about when one known model produced it.
- Tight budgets. If you need to forecast spend precisely, a fixed model at a fixed effort level is easier to plan around than a router that escalates when it judges a task hard.
A sensible default is to let the router handle routine work at Standard effort, step up to High or Max deliberately for genuinely hard tasks, and switch to a named model whenever you need to know exactly who answered.
What can I actually do about it?
Six tactics, ranked by leverage.
Check the status page first. Most vendors run one (status.anthropic.com, status.openai.com). When the tool feels off, that's the cheapest five-second check. A surprising share of "the AI got dumber today" moments line up with an open incident the user wasn't aware of.
Notice your own rationing. If you're near a quota cap, are you actually asking the same questions you would normally ask, or are you mentally pruning to save tokens? The quietest cause of perceived regression is the user being less ambitious without noticing.
Set the effort level explicitly when you can. Some tools (Claude Code, Copilot, Cursor) expose the effort dial. If a session is genuinely complex, set it to high and accept the cost. The default exists because most sessions don't need it; that doesn't mean yours doesn't.
Know whether a router is choosing for you. If your tool is set to an automatic or fusion mode, a change in feel may simply be a different model answering. Pin a named model for a session when you want consistent behaviour.
Keep sessions short, briefs long. Compaction kicks in only when conversation history exceeds the model's working window. Cut sessions at natural boundaries (one task per session) instead of letting one long conversation accumulate. You move the cost from "forgotten detail" to "longer briefs", which is the better trade.
Cross-check against a fresh session. If a tool feels off, paste the same prompt into a brand-new conversation, ideally with someone else's account on a different network. If the result is materially better, the problem is your session state (cache miss, compaction loss, in-context drift), not the model itself.
Should I switch tools when this happens?
Usually no. Every hosted AI assistant has the same operational stack with the same dials. Switching from Claude to GPT-5 because Claude felt off today is just moving to a different set of hidden levers, set to different defaults - and, increasingly, a router that may hand your prompt to a different model anyway. The grass-is-greener effect lasts about two weeks, until the new vendor's levers shift and you start the cycle again.
The honest exception: if a vendor has had three or more bad weeks in a quarter, and the bad weeks correlate with their published quality postmortems or status-page incidents, the platform itself is unstable for now. That's a real reason to switch. But "one bad day" almost never is.
20 Actually Useful Things to Ask ChatGPT
Free AI Tools You Should Be Using in 2026
