I've been spending time in the Claude Code community lately, reading through the complaint threads. Model got nerfed. Token usage exploded. It ignores my CLAUDE.md. It's vague and won't explain itself.
Some of these are real. But after reading enough of them, a pattern shows up: the same underlying issue keeps wearing different costumes. It's almost always about context. What's in the window, what the model is being asked to infer, and what nobody told it explicitly.
Here are the four versions I keep running into, and what actually fixes them.
The complaint: usage doubled without the workload changing.
What's usually happening: long sessions. Every turn resends the entire conversation history. A session that ran for two hours isn't paying for what you asked in the last message. It's paying for everything you asked since the beginning, again, on every single turn.
The fix is unglamorous: end sessions and start fresh ones. Keep durable state in files (a PROJECT.md
, a scratch notes file) rather than letting it accumulate in the conversation. Then every new session starts compact and reads only what it needs.
A useful signal: if you can't remember what you asked at the start of the session, it's too long.
The complaint: rules are written down, the model doesn't follow them.
What's usually happening: the file is too long, and the rules are bare assertions.
Two things consistently help. First, shorter. A file with twelve rules that get followed beats forty that get diluted. Second, attach reasons. Compare:
Never use raw SQL string concatenation.
Never use raw SQL string concatenation, injection risk.
The first is a rule the model applies literally, to the exact pattern named. The second is a principle, and the model generalizes it to the whole category: parameterized queries, ORM misuse, anywhere the same risk shows up. Models extrapolate from reasons far better than they comply with lists.
The complaint: it says there are "some issues to address" and you burn three rounds extracting what it means.
What's usually happening: you asked for clarity, which is an adjective, not a constraint.
Asking a model to "be clear" or "think like a senior engineer" gives it a persona, not a specification. It has no way to know what clear means for you, so it defaults to hedged, safe phrasing.
Replace the adjective with a structure. Instead of "explain the issues clearly", try:
For each issue, state:
- file and line
- what breaks
- the exact fix you propose
If you can't fill all three, say so instead of guessing.
Two things happen. Vagueness has nowhere to hide, because every slot has to be filled. And when the model genuinely doesn't know something, you see it immediately instead of receiving a confident paragraph that says nothing.
This is the same lesson as skill descriptions, which I wrote about in a previous post: adjectives are wishes, constraints are instructions.
The complaint: same kind of task, wildly different quality day to day.
What's usually happening: the inputs are more different than they feel. Different session length, different amount of prior context, different phrasing, different starting state of the codebase.
If you want to know whether something actually changed, you need a fixed reference. Keep two or three prompts from your real work as a benchmark. Same prompt, same starting state, run them every few weeks. Compare outputs.
Without that, you're comparing today's frustrating session to a remembered good one, and memory is a terrible instrument for this.
All four are the same mistake in different clothes: assuming the model has context it doesn't have, and hasn't been given.
It doesn't know your session got long. It doesn't know which of your forty rules matter most. It doesn't know what "clear" means in your codebase. It doesn't know what last week's output looked like.
None of this means the models are perfect or that complaints are always user error. Genuine regressions happen, and vendors should be held to them. But before concluding a model got worse, it's worth checking whether the thing that changed was the context around it.
Cheaper to check, and fixable today.
I write about building Claude Code skills and workflows for a real dev team. The full field guide, covering 5 skill patterns, anatomy, and the 7 mistakes I made, is here, and a complete debugging skill is free here.