You might have noticed that Opus 5 is extremely eager to talk.
It is like the uncle at the family party who always has an overly long, boring story about literally anything, and no request is too small to set one off.
Ask said uncle for a one-line change and you'll get the long history of why the code needed changing, why he never spotted it sooner, how it was not his change in the first place, and how this whole thing reminds him of a story... which was the right call, mind you, and here is how you might approach the problem next time.
Your has said near the top for a year.
On 4.x it mostly listened.
On 5 the line is still sitting there, in the same file, in the same position, and the model reads straight past it.
I gave someone four paths for this in a Reddit thread.
Here they are again, weakest lever first.
CLAUDE.md instructions Write the rule down first.
It is the obvious move and the weakest one. on its own barely registers, because it names nothing the model can act on.
A rule that names the shape you want does better.
Here is the one I use for reply verbosity, paste-ready for your own : One caveat to keep in mind: a short confirmation is already the answer. or should not get tabulated into a wall.
The rule is about shape when there is something to shape.
Even written this tightly, a line is advice, and it competes against everything else the model is holding.
On Opus 5 there is more of that than there used to be.
I went into why a line that worked on 4.x can go quiet on 5 in a separate piece, Opus 5: Delete your CLAUDE.md?: the model reaches for more of your rules at once and checks its own work by default, so even a sharp rule gets crowded out.
Write the rule, but do not expect it to hold on its own.
Output styles An output style is a step up, and the reason is where it lands.
A file rides in as a user message after the system prompt; an output style modifies the system prompt itself, and Claude Code adds its instructions to the end of that prompt (per the output-styles docs).
Same kind of instruction, but it travels through the session better.
Being in the system prompt, it is not one more user-turn line competing with everything else you have said, and the docs note Claude Code re-reminds the model to follow the active style during the conversation, so the rule gets re-surfaced rather than decaying after one appearance.
You can switch to a terser built-in style, or write your own.
To turn the reply-shape rule from the last section into a style, save it at and give it a frontmatter header.
The header is the part that makes it an output style rather than plain text: The same five reply-shape lines from the last section go in the body below that header. keeps Claude Code's built-in engineering behavior and changes only how it communicates.
Then pick the style from under Output style. (The standalone command was removed; it lives under now.) It is read once at session start, so a change takes effect after or a new session.
Still instruction, so the model can still drift, but it drifts less than from a line buried in a file.
A hook that gates the output The rule and the style are both instruction, and the model can weigh instruction and set it aside.
A hook is different.
It is a script the harness runs at a fixed moment, and it can refuse.
That makes it the strongest of the three levers, and the one worth showing in full.
Claude Code fires a hook the moment the model finishes a turn, and hands the hook the finished reply on stdin as , so it can read what was just written.
If the reply runs long, exit 2 blocks the stop and sends a line back to the model telling it to answer again, shorter.
Drop this in and make it executable: Then wire it in .
A hook takes no matcher: Change , or swap the word count for a line count or a grep for opening filler.
It cannot loop forever: Claude Code caps a hook at five consecutive blocks with no tool call between them, then lets the turn end.
We run a version of this on our own agents.
The