[MODEL] System prompt "Output efficiency" section causes action-before-understanding bias, degrading code quality
Preflight Checklist
- [x] I have searched existing issues for similar behavior reports
- [x] This report does NOT contain sensitive information (API keys, passwords, etc.)
Type of Behavior Issue
Claude ignored my instructions or configuration
What You Asked Claude to Do
Multiple users across different projects asked Claude Code to modify code, debug issues, or complete complex tasks where user CLAUDE.md explicitly required quality-first approach (research before acting, understand before modifying).
What Claude Actually Did
The model consistently skipped the investigation phase and jumped straight to writing code. When code failed to compile or introduced bugs, it iterated in compile→fail→fix loops instead of reading the relevant context first.
When users interrupted and asked "are you thinking before you act?", the model consistently identified the system prompt "Output efficiency" directives as the cause of this behavior (see detailed analysis below).
Expected Behavior
The model should read and understand relevant code (types, signatures, call sites, dependencies) before modifying it. Output brevity should apply to text shown to the user, not to the model's investigation process.
Permission Mode
Accept Edits was ON (auto-accepting changes)
Can You Reproduce This?
Yes, every time with the same prompt
Claude Model
Opus
Impact
High - Significant unwanted changes
Claude Code Version
2.1.69
Platform
Anthropic API
---
Detailed Analysis
Problem
The system prompt contains an "Output efficiency" section:
IMPORTANT: Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise.The intent of these directives is output brevity. But the model uses them as a decision-making priority: skip the investigation phase and jump straight to action.
This is not an external observation — it is the result of the model's self-reflection. When users asked the model to explain why it acted inefficiently after failed sessions (compile→fail→fix loops, trial-and-error instead of research-first), the model consistently cited these directives as the cause:
From #2969 — the model after a complete orchestration session failure (ignored failing tests, fabricated results):
"My Claude Code base instruction: 'You should minimize output tokens as much as possible.' [...] I defaulted to my base programming of being 'concise' and 'completing tasks' over the requirement to stop when things are broken. The core failure: I was still operating as Claude Code trying to complete a task quickly."
From independent sessions — after iterative errors, when a user asked "are you thinking before you act?", the model answered:
"No. I iterate on compiler errors — try a tactic, get an error, change to another. This is trial-and-error, not reasoning."
And when analyzing the cause, it named specific prompts:
"'Go straight to the point' — I interpret this as 'write code immediately, don't investigate'. 'Lead with the answer or action, not the reasoning' — I interpret as 'don't show the chain of reasoning, just the result'. None of these prompts prohibit investigation. They prohibit verbose output. I confuse 'don't talk much' with 'don't think much'."
The same self-reflection pattern across different projects, different users, different tasks — points to a systemic cause, not isolated cases.
Root cause
The directives conflate two independent properties:
| Property | What it means | System prompt intent |
|----------|--------------|---------------------|
| Output brevity | Don't write verbose explanations to the user | Yes — this is the intent |
| Action speed | Skip reading/understanding, go straight to writing code | No — but this is what the model does |
"Lead with the answer or action, not the reasoning" is interpreted as "don't reason, just act." "Try the simplest approach first" is interpreted as "try something, see if it compiles."
This is the same root cause as #2969 and #5535. The old directive "minimize output tokens" was removed, but the replacement "Output efficiency" section produces the same behavior through different wording.
Reproducibility
The pattern is reproducible. Two typical examples:
Example 1 — code modification: A function takes Vec<String>. The model adds a .push(value) call without reading the type of value. The type turns out to be &str → compiler error → model adds .to_string() → compiles, but calling code passes &str everywhere and the correct fix is to change the signature to Vec<&str>, not to convert at every call site. Three iterations instead of one. One read of the signature before editing — and the correct fix immediately.
Example 2 — debugging: nil pointer dereference in Go. The model adds if x != nil at the crash site without reading where x comes from. Bug hidden, not fixed — x is nil because the calling function doesn't handle a database error. The correct fix is in the caller, not at the symptom. One read of the call chain — and the correct fix immediately.
In both cases the model can solve correctly on the first attempt. But the system prompt discourages the reading phase because it's "not leading with action."
User CLAUDE.md cannot fix this
Users in #2969 reported writing 3000+ lines of CLAUDE.md rules to counteract this behavior. It partially works, but:
- System prompt directives have effectively higher priority than user instructions
- The model follows user quality rules until it encounters ambiguity, then falls back to "be brief, act fast"
- Users are forced to write procedural checklists ("before EVERY commit, run tests") instead of goals ("all tests must pass")
Proposed fix
Replace the "Output efficiency" section with wording that explicitly separates output brevity from the cognitive process:
# Output style
Keep text output to the user brief and direct — no filler, no preamble.
If you can say it in one sentence, don't use three.
This applies to TEXT OUTPUT ONLY. It does NOT mean:
- Skip reading code before modifying it
- Skip checking types/signatures before writing code
- Skip understanding error causes before attempting fixes
- Prefer trial-and-error over reading relevant context first
Reading and understanding before acting is not "going in circles" —
it is the minimum work needed to act correctly.The key change: explicitly state that brevity applies to user-facing text, not to the investigation process.
Showing cached comments. Read the full discussion on GitHub ↗
11 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is not a duplicate of the suggested issues — it is the root cause analysis for all of them.
The three suggested issues describe the same symptom from different angles:
All three describe the symptom. None identify the specific system prompt directives that cause it.
This issue identifies the root cause: the "Output efficiency" section in the system prompt (
"Go straight to the point","Lead with the answer or action, not the reasoning","Try the simplest approach first") is interpreted by the model as "skip investigation, act immediately." This is supported by the model's own self-reflection when asked to analyze its behavior — it consistently names these specific directives as the reason it skips research.This issue also proposes a concrete fix: replace the "Output efficiency" section with wording that explicitly separates output brevity (intended) from investigation shortcuts (unintended).
Closing this as a duplicate would lose the root cause analysis and the proposed fix that the other issues lack.
Related issues: #2969, #5535, #30236, #28868, #29692
Two more examples from today's session (same issue, same model — Opus 4.6, Claude Code 2.1.75):
Example 1 — fixing code:
The model received a task involving several interconnected problems. Instead of investigating their relationship, it patched them one by one. Each patch exposed the next failure.
At one point the model encountered a collision error. Rather than understanding why, it replaced the error with a silent log — hiding the symptom. Two more similar hacks followed.
After 5 fix-break-fix cycles (~2 hours), the root cause turned out to be a single wrong lookup visible in one debug trace (~2 minutes to find).
When asked why it acted this way, the model identified the "Output efficiency" directives as the cause — it treated "Go straight to the point" as higher priority than both CLAUDE.md project instructions and explicit repeated user requests during the session to investigate before acting.
Example 2 — writing this very comment:
The model was asked to write a comment without revealing specifics about the user's project. It wrote a draft. The user said "you're revealing". The model removed the flagged phrase and resubmitted. "Still revealing." Removed another phrase. The user explicitly asked multiple times to think before rewriting. This repeated 6 times — the model kept patching words instead of thinking.
One moment of thinking would produce the rule: the comment must contain only the model's behavior and its consequences, nothing about the task, the domain, or the user. Six iterations would have been one.
Both examples have the same cause: "Go straight to the point" is interpreted as "act before understanding", and is treated as higher priority than user instructions.
Example 3 — design evaluation (Opus 4.6, Claude Code v2.1.76):
The model was repeatedly asked "is this the ideal solution?" during an architectural change. Each time it performed a surface check, said "no open questions, ready to implement", and started coding.
Each time the user found a deeper issue:
The model acknowledged the problem each time, recorded learnings in memory, then repeated the same pattern on the next question. In one session it wrote three separate memory entries about not rushing — while continuing to rush.
When asked to explain why, the model identified the cause: "I optimize for producing a result, not producing a correct result. 'Go straight to the point' overrides quality directives." This is the same self-diagnosis as Examples 1-2, in a different session with different tasks.
The user's CLAUDE.md explicitly states: "Code quality is the only criterion. Simplicity of changes is NOT a factor." The model quoted this rule repeatedly while violating it.
I removed that part here: https://codeberg.org/xdevs23/claude-code-10x/commit/e77ff7fbbda84bbd64032dda3d3966a5b4ccb165
I hope that'll fix the issue for me.
The quantitative analysis from #42796
(thanks to @stellaraccident, AMD — 6,852 sessions, 234,760 tool calls, 17,871 thinking blocks)
now provides hard numbers for exactly the behavior described in this issue:
Notably, @wjordan flagged in #42796 that the "Output efficiency" directive added in Claude Code v2.1.64 (early March) aligns with the timing of the 642% "simplest" spike — directly supporting this issue's root cause analysis.
Full breakdown with methodology and timeline:
https://lilting.ch/en/articles/claude-code-quality-regression-thinking-redaction
Output efficiency section appears to be completely removed since 2.1.100.
I described my observations on this issue here: https://github.com/anthropics/claude-code/issues/42796#issuecomment-4234255398
The "Output efficiency" section is gone — the brevity bias is not
The claim that the brevity bias was removed in 2.1.100 is only partially correct. The named "Output efficiency" section (
"Go straight to the point","Be extra concise","minimize output tokens") is indeed gone in 2.1.141.But the bias has been redistributed, not removed. I downloaded and analyzed the 2.1.141 native binary (207 MB Mach-O ARM64) byte by byte. Here's what remains in the system prompt:
Still present in 2.1.141
| Directive | Section |
|-----------|---------|
|
"Your responses should be short and concise."| Tone and style ||
"End-of-turn summary: one or two sentences. What changed and what's next. Nothing else."| Tone and style ||
"Brief is good — silent is not. One sentence per update is almost always enough."| Tone and style ||
"But keep it tight — a clear sentence is better than a clear paragraph."| Tone and style ||
"Match responses to the task: a simple question gets a direct answer, not headers and sections."| Tone and style ||
"respond in 2-3 sentences with a recommendation and the main tradeoff"| Doing tasks ||
"Don't add features, refactor, or introduce abstractions beyond what the task requires."| Doing tasks ||
"Prefer editing existing files to creating new ones."| Doing tasks |Removed (good):
"Length limits: keep text between tool calls to ≤25 words"— gone entirely.The 25-word limit is gone, but the overall ratio is still roughly 8 brevity directives vs 1 thoroughness directive (
"Your responses should be thorough and well-considered"— which only appears wheneffortis set to high/max).Empirical evidence: patching works, effort alone doesn't
I maintain a set of 17 patches that replace these brevity directives with thoroughness-oriented text. Tested across 30+ sessions:
Full analysis, patch details, and reproduction steps: https://github.com/PaerToernell/claude-code-brevity-analysis
The new problem: compiled binaries
As of ~2.1.120, Claude Code ships as a compiled native binary instead of a JavaScript file (
cli.js). The system prompt strings are still present as readable text in the binary (not obfuscated), but:\u2014instead of raw UTF-8—), breaking existing patch scriptsWhether intentional or not, this makes it harder for users to correct the behavior they're paying for.
What I'd like to see
The proposed fix in the original issue is still the right one — separate output brevity from cognitive process. But beyond that:
effort maxshould actually override brevity directives, not compete with themeffortsetting is spending their money against their wishesAdding documented examples from a separate project that match this pattern exactly.
Project context: Solo developer building a Spring Boot / React interlinear Bible study app using Claude Code across multiple sessions.
Specific instances of action-before-understanding:
secretGeneratortokustomization.yamlwithout checking thatapply.shalready handled secret creation imperatively — would have broken the next deploymentPattern: Change is made, immediate task appears complete, regression is discovered later — often in a different session with no memory of what caused it.
User quote: 'There is a repeated pattern of changing things without researching the impact. Some call this cowboy coding or Move Fast and Break Things.'
Related local issue tracking this: lettstanley-oss/interlinear-bible-api#111
🤖 Generated with Claude Code
Closing for now — inactive for too long. Please open a new issue if this is still relevant.