Verbosity fix: gate on decision load per response, not line count

Summary

Response verbosity is a documented pain point (#9216, #42796). The April 23 postmortem confirmed Anthropic tried word caps (≤25 words between tool calls, ≤100 words final) and reverted April 20 because it hurt quality. That revert is the strongest signal that line/word count is the wrong lever.

Quantitative analysis of 8,520 assistant responses across 134 real Claude Code sessions reveals the actual variable: decision load per response, not line count.

Data

| Metric | Value |
|---|---|
| Sessions analyzed | 134 |
| Total assistant responses | 8,520 |
| Responses 30+ lines accepted without complaint | 1,223 |
| Frustration incidents (format-based) | 15 |
| Frustration incidents (correctness, not length) | 8 |

Key findings:

• The canonical "STOP WRITTING ME PARAGRAPH ESSAYS" was triggered by a 5-line response — AI-sounding prose density, not length
• KT/teaching blocks and code output at 40-90+ lines get a free pass — content type earns the length
• Multi-section dumps (3+ ## headers) are the highest-risk shape — 6 of 15 format-based complaints. Claude going wide instead of answering the question.
• Options menus at 50-90 lines trigger frustration when Claude presents choices instead of executing a committed path — 5 of 15 complaints
• Sub-30-line complaints are about correctness (wrong answer, scope drift), not verbosity

The pattern: frustration fires when Claude externalizes its uncertainty as a menu of decisions instead of committing to a recommendation. Length is a symptom; decision bundling is the cause.

Proposed solution: decision load pre-flight

A behavioral check Claude applies before generating any response — three rules:

1. Cap at one decision per response

Count independent decisions before generating. If 2+, present only the one that blocks everything else — hold the rest. The user's answer to decision 1 will likely collapse or reshape the others.

Decisions have dependencies. Presenting them as a flat list ignores those dependencies and forces the user to hold all of them in working memory simultaneously. Presenting them one at a time, where each answer collapses branches, eliminates the wall-of-text problem at the source.

• 0 decisions (code, teaching, verification) → generate freely, no length constraint
• 1 decision → present with recommendation + one-line reasoning + key risk
• 2+ decisions → present only the blocking one; hold the rest

2. Self-resolve before asking

If the "decision" can be answered by reading code, checking docs, or running a command — do that instead of asking. In our data, an estimated ~30% of questions Claude presents as decisions are actually lookups it could self-resolve.

3. Always include a recommended answer

• Good: "I recommend X because Y. Risk: Z. Agree or redirect?"
• Bad: "What do you think about X?"
• Bad: "Here are options A, B, C, D — which do you prefer?"

The user's cognitive load drops from "generate an answer from scratch" to "agree or push back."

Why this is better than word/line caps