When Claude Code feels dumber, check your effort level before your prompts

You have been getting worse answers for a week. Same repo, same prompts, same model name in the header — and the results feel forgetful, clipped, or shallow. The forum consensus writes itself: they quantized the model, or they throttle you at peak hours.

Before you rewrite your prompts or start pruning your CLAUDE.md, check the two things that are under your control and that actually change what gets sent to the model: your effort level and your Claude Code version.

Why effort is the first suspect

Effort level controls adaptive reasoning — whether and how much the model thinks on each step. It is not cosmetic. The docs describe medium as the level that reduces token usage for cost-sensitive work that can trade off some intelligence, against high as the balanced default. Dropping a level is a real quality change with no visible label on the output.

And it is sticky. From model-config:

When you set low, medium, high, or xhigh in an interactive session on your machine, Claude Code saves the level and applies it in later sessions. It saves the level per model, under the modelSettings key in your user settings, so each model keeps its own saved level.

So a level you set once — during a bad week, while economizing on a long refactor, or by nudging the /model picker's effort slider without meaning to — follows you into every future session on that model, silently. Six months later you are debugging "the model got worse" and the cause is a JSON key you wrote in March.

Which key holds that level changed under people's feet, so a settings file that has been around a while can carry either shape. modelSettings "requires Claude Code v2.1.251 or later"; the effortLevel entry adds that "before v2.1.251, /effort wrote this key". A level you set before that upgrade is still sitting in a single global effortLevel string rather than a per-model entry — still sticky, still silent, and now applying to every model you have not saved a level for. Within one settings file a model's modelSettings entry wins over it, which is exactly the kind of half-shadowed state that survives a year unnoticed. The grep below covers both spellings on purpose.

The check, in order

# 1. what version am I on
claude --version

# 2. what did I save, and for which model
grep -A4 -E 'modelSettings|effortLevel' ~/.claude/settings.json

Then, inside a session:

/effort status

/effort status prints the level in force. The session header also shows it next to the model name — "with low effort" — and a custom status line can surface effort.level permanently so you never have to ask again.

To clear a saved level for the current model and fall back to the model default, run /effort auto. Other models' saved entries and any top-level effortLevel are left alone.

Managed settings complicate this: an effortLevel in managed settings outranks a level you saved in user settings, and enterprise roles can cap the maximum level per model, in which case naming a higher level runs at the cap instead. If your organization set a cap, the /effort picker does not even offer levels above it.

The version half

A client-side bug can degrade output without touching the model at all. Context handling, thinking retention, and system-prompt assembly all live in the CLI, and a regression there reads exactly like a worse model: repetitive, forgetful, burning through limits faster than it used to. That is why claude --version belongs next to /effort status in your triage, and why claude update is a cheaper experiment than a prompt rewrite.

What is unverified here

The framing above comes from a vendor postmortem covering a specific stretch of spring 2026. It attributes six weeks of quality complaints to three overlapping changes with published dates — a default reasoning effort moved from high to medium and later reverted, a thinking-retention change that cleared state every turn instead of once per idle session, and a system-prompt length cap that cost a few percent on coding quality before being rolled back — and states that the API layer was unaffected. None of that appears anywhere in the Claude Code documentation, and nobody here has independently confirmed the dates, the version numbers, or the magnitude figures. Treat the incident narrative as a first-party account, not a settled fact.

What the docs do confirm is the mechanism that makes the advice actionable: effort defaults to high on every model that supports it, xhigh on Opus 4.7, and a level you set interactively is written to user settings — modelSettings from v2.1.251, the global effortLevel before that — and reapplied in later sessions. That part you can verify on your own machine in thirty seconds, and the check at the top of this page is exactly that verification.

Nobody here has opened the postmortem either — what this page has read is a trade-press write-up of it, which is the source listed above. The postmortem is deliberately absent from the corroboration list: putting an unread vendor page there would dress a second-hand summary up as a documented mechanism, which is the one thing that list exists to prevent. What would settle the rest: an archived copy of the postmortem with its dates intact, plus a changelog entry for the version that shipped the thinking-retention fix. Absent those, the correct posture is "the quantization theory has at least one reported counterexample", not "the quantization theory is dead".

The habit worth keeping

When quality drops, spend two minutes on configuration before you spend an hour on prompts. Configuration drift is silent, persistent, and cheap to rule out. Model conspiracy theories are none of those things.