Claude Code Too Verbose? Why Your Rules Stop Working [2026]

You tell Claude Code to keep answers short. It does, for a while. An hour later you are reading four paragraphs where one would do, and you type the same instruction again.

The reason is almost never that you worded it badly, and it is almost never where you put it. Before any of that, there is a check almost nobody runs: /context, to confirm the file is loaded at all.

What people are actually asking

Seven question-flagged threads on r/ClaudeCode and r/ClaudeAI, collected 2026-08-15, covering roughly the previous month. Titles verbatim, because the wording is the evidence:

The third one is not a bug report. It is somebody quoting the model back at itself, and it drew 154 comments because everyone recognised it.

One correction before this goes further. My first count for this cluster was 4,497 points, which would have made it the largest thing people are asking about. It is not. The biggest item in that count was a "Built with Claude" showcase, not a question, and removing it drops the cluster to the 1,659 above, putting it second behind safety. A list sorted by points mixes questions with things people are proud of. I nearly published the inflated number.

So: a real and widely shared annoyance, not the dominant one.

Why does Claude stop following the rule?

Because instructions in memory files are context, not configuration. The memory documentation is direct about it: Claude "treats them as context, not enforced configuration", and there is "no guarantee of strict compliance, especially for vague or conflicting instructions".

First: is the file even loaded?

The documented troubleshooting path for this exact symptom does not start with wording or length. It starts with /context, and checking the list under Memory files. If your file is not there, Claude cannot see it, and nothing you do to the text will help.

That is a real failure and not a formality. A rule in a nested subdirectory CLAUDE.md loads only when Claude reads a file in that subdirectory. A file matched by claudeMdExcludes is skipped entirely. In both cases the file exists, reads perfectly, and is not in the conversation. Spend one command before you spend an evening.

The next documented step is the same question about location: confirm the file is somewhere that gets loaded for the session you are in.

Then: the four things that affect adherence

Once you know it is loaded, the documentation names four qualities of an effective instruction file: size, structure, specificity and consistency.

Size is the one worth stating carefully, because the obvious reading is wrong. The target is under 200 lines per file, and longer files "consume more context and reduce adherence". But nothing is dropped: CLAUDE.md files are loaded in full regardless of length. Your rule is not being truncated away, it is competing with more material. Note also that the same number appears twice for different things: 200 lines is a target for claude(.)md, and a hard load limit for auto memory's MEMORY.md, which loads the first 200 lines or the first 25KB, whichever comes first, and genuinely drops the rest.

This is the one that got me. My own instructions file had grown well past that line, one useful addition at a time. Nothing announces it, and the file still reads perfectly well to a human.

Structure is the quiet one: headers and bullets over dense paragraphs, because Claude scans structure the way a reader does.

Specificity: is the instruction checkable?

"Be concise" is a preference competing with everything else in context. "If one sentence works, do not write three" is a test that can be applied to a draft before sending it. The documentation's own examples run the same way: "Use 2-space indentation" over "Format code properly".

Consistency: do two rules disagree?

If two rules contradict each other, Claude may pick one arbitrarily. Worth reading your files for this specifically, because conflicts accumulate quietly across a project file, a user file and anything under .claude/rules/. A rule asking for thorough explanations and a rule asking for brevity do not average out. My own notes on writing rules Claude follows are mostly about this.

The theory I had, and why it was wrong

I want to show this one, because I believed it, I had a mechanism for it, and it is wrong.

My theory was placement. claude(.)md is delivered as a user message after the system prompt, which is documented and true. An output style is added to the system prompt itself, which is also documented and true. So, I reasoned, the memory file drifts further behind you as the conversation grows while the system prompt stays put, and that is why the rule fades.

Tidy story. The documentation kills it in one line:

Project-root CLAUDE.md survives compaction: after /compact, Claude re-reads it from disk and re-injects it into the session.

So it does not vanish at the moment people assume it does. Be careful not to over-correct that into "instructions never fade", which is the mistake I had just made in the other direction: that quote is about /compact specifically, and I have written elsewhere that unenforced rules decay over a long session. Compaction is not the mechanism. Something else is. A Reddit thread had reached the same conclusion I had, and I treated that agreement as confirmation, when in fact the thread and I had both reasoned from a message role to a persistence behaviour that neither side had checked.

The check took one page of documentation. I had already written the post around the theory before I ran it.

What placement really changes

Placement does matter. It just does not do what I thought, and the balance runs the other way from the move I was about to recommend. I am naming the differences rather than totalling them, because the total went out wrong twice: first as "two of the three", then as "one, three and a wash".

Invoked skill bodies sit in the same table, re-injected but capped at 5,000 tokens each and 25,000 total with the oldest dropped first. That turns "put the important part near the top of a SKILL.md" from a style preference into a compaction rule.

What separates them, in plain terms. For the style: it triggers reminders during the conversation, and nothing in claude(.)md does. For claude(.)md: a mid-session edit reaches it at the next /compact, where an edited style waits for /clear or a restart, and it reaches subagents where the style does not. Neither way: existing content survives compaction on both sides, and a fork inherits both. That is the whole comparison; the table above is the arithmetic.

The subagent row is the one that should stop you moving everything: ordinary subagents load your claude(.)md hierarchy and do not get your output style. Move your voice rules into a style and they come back written in the default voice. Two caveats in opposite directions. A fork inherits the parent's whole system prompt, so it does get the style. And claude(.)md is not the same as auto memory here: auto memory is not loaded into subagents at all, fork again excepted.

That is the opposite of the upgrade I was about to recommend.

The five places a rule can live

There is no single right file. There are five, they behave differently, and choosing is mostly about how badly you need the rule obeyed.

Hooks are the only one that enforces anything. The documentation is explicit: if an instruction must run at a specific point, write it as a hook; a PreToolUse hook is the documented way to block an action regardless of what Claude decides. Everything else here is text that Claude reads and generally follows. I have written up what happens when you mistake an observer for a gate, and it applies directly: a rule in a markdown file is a request.

.claude/rules/ with paths: frontmatter is the underused one. A path-scoped rule loads only when Claude reads matching files, which attacks cause one head on. Instructions that only matter for your API handlers stop costing context and adherence everywhere else, which is the same budget problem behind context management generally. If your memory file is over 200 lines, this is where the excess should go.

There is a trade-off, and the documentation states it and its own remedy plainly. Path-scoped rules and nested claude(.)md files load into message history when their trigger file is read, so compaction summarises them away with everything else; they reload the next time Claude reads a matching file. The advice given is to drop the paths: frontmatter or move the rule to the project-root file if it must persist. Note the direction: toward the memory file, not away from it.

User-level ~/.claude/claude(.)md is a documented home for personal style. The scope table gives its purpose as personal preferences for all projects, with code styling preferences as the example. If you have felt vaguely wrong about keeping voice rules there, do not. It is the intended location, and it reaches subagents. With one exception: Explore and Plan skip the memory hierarchy entirely, and those are two of the ones Claude spawns most. The mitigation is in the same documentation: custom subagents you define yourself do load the full hierarchy, and any subagent can preload named instructions through its skills frontmatter field. So the gap is specific to those two built-ins rather than a general ceiling on how far your rules reach.

Both scopes survive compaction, and it took me two passes to state that correctly. The compaction table names "project-root CLAUDE.md and unscoped rules", which I first read as leaving the user-level file undocumented. The prompt-caching page closes it outright: "Your project-root and user-level CLAUDE.md files are read once at session start... The new content loads on the next /clear, /compact, or restart." So both are reloaded from disk at the same points, and the personal file the docs recommend for style preferences is not the weaker option.

The lesson from getting that wrong twice: silence in one table is not a documented gap. I published a gap that existed only in the page I happened to be reading.

The rules I run, and where I keep them

This block is mine, verbatim:

Language: [ENGLISH / GERMAN / etc.] by default. All output in this language unless I switch.

Banned in any text I will read:
- Em-dash (U+2014). Use "-" or " - " instead.
- Emojis, unless I ask.
- Filler phrases ("Great question", "Certainly", "I would be happy to").

Voice:
- I work alone. Never say "we / our / us". Always "I / my".
- Concise over exhaustive. If one sentence works, do not write three.
- Lead with the answer or the action, not the reasoning. Reasoning second, only when it adds value.

It lives in my user-level memory file, and having checked the subagent coverage above, it is staying there. Three things about it are worth stealing, and none of them is a specific rule.

Ban a thing, do not request a quality. "Be concise" competes with everything. "Em-dash (U+2014)" names a character, which makes it the most reliable line in the block. It has never failed, because there is nothing to interpret.

Pair every ban with its replacement. Each line above says what to do instead. A rule that only forbids leaves a gap, and the gap is where the invented vocabulary comes from.

Keep it short enough to stay obeyed. Nine lines. That is the whole point of cause one: this block competes with everything else in the same file, so anything I add here I try to remove from somewhere else.

The fuller version, with the profile and sparring blocks around it, is in connecting Claude across surfaces. Worth saying plainly: in that post it is presented as profile content to sync between Claude.ai and Claude Code, filed as something to copy around rather than as an answer to "how do I stop this". I had the useful part filed under the wrong problem, which is a small version of what this whole post is about.

Two traps worth knowing

/output-style will not do anything for you. It was deprecated in v2.1.73 and removed in v2.1.91, and plenty of published guidance still opens with it. It is not quite gone: typing it returns "/output-style isn't available in this environment" rather than the "Unknown command" you get for a genuine typo, so it still resolves to something. It just will not set your style. Use /config and pick under Output style in the terminal, or set outputStyle in a settings file. In the desktop app /config opens Settings rather than a menu, so the settings field is the reliable route.

keep-coding-instructions defaults to false. Write a custom output style without it and you drop Claude Code's built-in software engineering instructions: how it scopes changes, writes comments and verifies work. Set it to true whenever you are changing voice but still writing code.

---
name: Plain
description: Short answers, no filler, answer first
keep-coding-instructions: true
---

Lead with the answer. Reasoning after, and only when it changes what I do.

Styles live in three places: ~/.claude/output-styles/ for every project, .claude/output-styles/ for one, and the same path inside the managed settings directory for an organisation-wide policy. Plugins can ship them in an output-styles/ directory, and a plugin style carrying force-for-plugin overrides your own selection while that plugin is enabled.

What none of this fixes

The threads at the top are largely about how the model writes, and configuration only reaches part of that.

Filler phrases, banned characters and burying the answer are all rule-shaped, and they respond well. Invented vocabulary does not, because a model reaching for a compact term is not breaking a rule you could have named in advance. One line asking for the plain word rather than the clever one helps, and does not solve.

The built-in Explanatory and Learning output styles are documented to produce longer responses than Default by design. A style is not inherently a brevity tool; it is a way to change the voice, in either direction.

And none of it is enforcement. Memory files, rules and styles are all text Claude reads. If a rule genuinely must hold, it belongs in a hook.

Honest scope

The mechanisms here are read from Anthropic's documentation, not measured by me. I have not instrumented adherence against file length, and I have not run a controlled comparison of the same rule in different files. What I can report is that my own instructions file was well past the documented 200-line target, that the four qualities the docs name for an effective file are size, structure, specificity and consistency, that the troubleshooting path for an ignored rule starts with /context and then location rather than with any of them, and that I have since moved instructions into path-scoped files on that basis rather than on measured results.

Two claims here were hard to get right and both failed in a summary layer rather than in the argument. The comparison of the two placements was published with a wrong total twice, as "two of the three" and then as "one, three and a wash", so it no longer carries one at all. And whether the user-level file survives compaction went wrong twice in opposite directions - first published as "unstated", then quietly omitted from an FAQ answer that was asked about the class. Both are corrected above; I mention them because a reader deserves to know which parts of a post were slippery.

I have left the wrong theory in this post on purpose. The first draft argued that voice rules belong in an output style because a memory file drifts out of reach as context fills. That is wrong, the documentation says so in one line about /compact, and I only found it because an external model attacked the draft before it shipped. If you have read that argument somewhere, including from me, it does not survive checking.

Thread counts are one snapshot of two subreddits sorted by points, and individual dates are approximate. Version numbers are from Claude Code v2.1.233.