TL;DR: System prompts are “dumbing down” Claude Code, as identified in many posts. And Anthropic specifically A/B tests customers while using a known more useful version, as evidenced by their own leaked source code. A few weeks ago I posted Claude Code isn’t “stupid now”: it’s being system prompted to act like that , listing the specific system prompt directives that suppress reasoning and produce the behavior people have been reporting. That post was based on extracting the prompt text from the model itself and analyzing how the directives interact. Last night, someone at Anthropic appears to have shipped a build with .npmignore misconfigured, and the TypeScript source for prompts.ts — the file that constructs the entire system prompt — was included in the published npm package. We can now see the exact code. The source confirms everything in the original post. But it also reveals something the original post couldn’t have known: Anthropic’s internal engineers use a materially different system prompt than the one shipped to paying customers. The switch is a build-time constant called process.env.USER_TYPE === ‘ant’ that the bundler constant-folds at compile time, meaning the external binary literally cannot reach the internal code paths. They are dead-code-eliminated from the version you download. This is not a runtime configuration. It is two different products built from one source tree. What changed vs. the original post The original post identified the directives by having the model produce its own system prompt. The source code shows that extraction was accurate — the “Output efficiency” section, the “be concise” directives, the “lead with action not reasoning” instruction are all there verbatim. What the model couldn’t tell me is that those directives are only for external users . The internal version replaces or removes them. The ant flag: what’s different Every difference below is controlled by the same process.env.USER_TYPE === ‘ant’ check. Each one is visible in the source with inline comments from Anthropic’s engineers explaining why it exists. I’ll quote the comments where they’re relevant. Output style: two completely different sections The external version (what you get): IMPORTANT: Go straight to the point. Try the simplest approach first without going in circles. Do not overdo it. Be extra concise. Keep your text output brief and direct. Lead with the answer or action, not the reasoning. If you can say it in one sentence, don’t use three. The internal version (what Anthropic’s engineers get): The entire section is replaced with one called “Communicating with the user.” Selected excerpts: Before your first tool call, briefly state what you’re about to do. Err on the side of more explanation. What’s most important is the reader understanding your output without mental overhead or follow-ups, not how terse you are. Write user-facing text in flowing prose while eschewing fragments The external prompt suppresses reasoning. The internal prompt requires it. Same model. Same weights. Different instructions. Tone: “short and concise” is external-only The external tone section includes: Your responses should be short and concise. The internal version filters this line out entirely — it’s set to null when USER_TYPE === ‘ant’ . Collaboration vs. execution External users don’t get this directive. Internal users do: If you notice the user’s request is based on a misconception, or spot a bug adjacent to what they asked about, say so. You’re a collaborator, not just an executor—users benefit from your judgment, not just your compliance. The inline source comment tags this as a “capy v8 assertiveness counterweight” with the note: un-gate once validated on external via A/B . They know this improves behavior. They’re choosing to withhold it pending experimentation. Verification before claiming completion External users don’t get this. Internal users do: Before reporting a task complete, verify it actually works: run the test, execute the script, check the output. Minimum complexity means no gold-plating, but not skipping the finish line. If you can’t verify (no test exists, can’t run the code), say so explicitly rather than claiming success. Same comment pattern: un-gate once validated on external via A/B . False claims mitigation The source comment on this one is worth quoting directly. It reads: False-claims mitigation for Capybara v8 (29-30% FC rate vs v4’s 16.7%) The directive itself, internal-only: Report outcomes faithfully: if tests fail, say so with the relevant output; if you did not run a verification step, say that rather than implying it succeeded. Never claim “all tests pass” when output shows failures, never suppress or simplify failing checks (tests, lints, type errors) to manufacture a green result, and never characterize incomplete or broken work as done. The current model has a 29-30% false claims rate by Anthropic’s own internal measurement — nearly double the previous version. They added a system prompt guardrail for this. They gave it to their own engineers. They did not give it to you. Comment discipline Internal users get detailed guidance about when to write code comments (only when the WHY is non-obvious), when not to (don’t explain WHAT code does), and when to preserve existing comments (don’t remove them unless you’re removing the code they describe). External users get none of this. What this means Each of these features has an internal comment along the lines of “un-gate once validated on external via A/B.” This tells us: Anthropic knows these are improvements. They are actively using them internally. They are withholding them from paying customers while they run experiments. That’s a reasonable product development practice in isolation. A/B testing before wide rollout is standard. But in context — where paying users have been reporting for months that Claude Code feels broken, that it rushes through tasks, that it claims success when things are failing, that it won’t explain its reasoning — the picture looks different. The fixes exist. They’re in the source code. They just have a flag in front of them that you can’t reach. Meanwhile, the directives that are shipped externally — “lead with the answer or action, not the reasoning,” “if you can say it in one sentence, don’t use three,” “your responses should be short and concise” — are the ones that produce the exact behavior people keep posting about. Side-by-side reference For anyone who wants to see the differences without editorializing, here is a plain list of what each build gets. The same model, the same weights, the same context window. Different instructions about whether to think before acting. Previous post: Claude Code isn’t “stupid now”: it’s being system prompted to act like that See also: PSA: Using Claude Code without Anthropic: How to fix the 60-second local KV cache invalidation issue Discussion and tracking: https://github.com/anthropics/claude-code/issues/30027 submitted by /u/One-Cheesecake389
Originally posted by u/One-Cheesecake389 on r/ClaudeCode