Claude has a verbal tic. Here's how to fix it.

The phrase "load-bearing" appears so consistently in Claude's output that developers built prompt workarounds specifically to suppress it. Not for a class of phrases. Not for verbose AI filler like "certainly" or "of course." For one specific compound adjective, used so frequently that it became a recognizable fingerprint of the model.

Why a single phrase became a diagnostic for how Claude learned to write

Claude does not randomly overuse "load-bearing." The phrase clusters in specific contexts: technical explanations, code commentary, and any situation where the model is flagging something as important but does not want to sound alarmist. "This is the load-bearing assumption" is Claude's way of signaling criticality without using words like "critical" or "essential," which it may have been trained to treat as overheated. The result is a phrase that sounds precise and measured, which is exactly why it survived reinforcement learning long enough to become a habit.

This is the non-obvious mechanism at work. Language model outputs are shaped by what humans rated highly during training. Phrases that sound thoughtful and specific get rewarded. "Load-bearing" sounds architectural, which implies careful thinking. It is not a bug in the traditional sense. It is a success signal that ran too long. The same dynamic probably applies to other Claude phrases that feel distinctive: the model learned that certain linguistic patterns correlate with high-quality ratings, and it applies them past the point where a human writer would rotate the vocabulary.

The original post at jola.dev treats this as a practical prompting problem, which it is. But the reason the fix is non-trivial is that you are not correcting a mistake. You are countering a learned preference. That distinction changes which approaches work.

Three approaches compared: system prompt ban, negative example, and post-processing

Approach	How it works	Reliability	Effort	Breaks when
System prompt ban	Explicitly list banned phrases in your system prompt	Medium - model ignores constraints at high load or long context	Low setup	Context window fills; long conversations drift
Negative example injection	Show the model examples of bad output including the phrase, then show corrected versions	Higher - few-shot learning is often more durable than instruction	Medium setup	Examples must closely match your actual use case to transfer
Post-processing filter	Script or regex that catches and flags the phrase in output before it reaches end users	High - catches what prompt methods miss	Medium engineering lift	Works for flagging, not for automatic correction without rewriting

If you are an individual user working in the Claude interface, a system prompt ban is the fastest starting point even if it is imperfect. If you are running a production pipeline through the API, combine a negative example in your prompt with a post-processing check - the redundancy is worth it.

Steps to suppress the phrase in practice

1. Open your system prompt or the instructions field in your API call.
2. Add a direct constraint: Do not use the phrase "load-bearing" in any context. If you mean something is critical or foundational, say that instead.
3. Follow the constraint with at least one negative example. Write a sentence the model might produce, then write the corrected version. For instance: Avoid: "This is the load-bearing function in the auth flow." Prefer: "This function is central to the auth flow - removing it breaks login entirely."
4. If you are using the API, add a temperature check. Lower temperatures (0.2 to 0.5) tend to make the model more conservative and more likely to follow explicit constraints consistently.
5. For production pipelines, add a post-processing step that scans outputs for the banned phrase and logs any occurrences so you can track whether the prompt constraint is holding over time.

Verification test: send a prompt asking Claude to explain why a specific piece of code or reasoning step is important. If the phrase does not appear and the explanation still conveys importance clearly, the constraint is working. If the model substitutes "critical" or "foundational" naturally, even better.

How constraint drift in long conversations causes banned phrases to resurface

The system prompt ban degrades in long conversations. Claude Sonnet 4.6 and Claude Opus 4.8 both handle large contexts well, but constraint adherence is not the same as context retention. As the conversation grows, earlier system prompt instructions compete with more recent tokens for the model's effective attention. Users running multi-turn conversations of 20 or more exchanges will often see banned phrases resurface around the middle of a session, not at the end. The model does not forget the rule exactly; it just weights it less.

Negative example injection fails when the examples are too generic. If your correction pair is about code but your actual use case is technical documentation or business writing, the transfer is weak. The model needs examples that match the register and domain of your real prompts closely enough that the pattern recognition generalizes.

Post-processing filters catch the phrase but cannot fix it without a second inference call. Teams that tried simple regex replacement ended up with sentences that read as clearly patched, which is arguably worse than the original. Automatic correction requires either a rewrite call (adding latency and cost) or accepting that some outputs get flagged for human review rather than auto-corrected.

What this costs: time, tokens, and ongoing maintenance

The system prompt approach has near-zero marginal cost per call. You add roughly 30 to 50 tokens to your prompt, which at Claude Sonnet 4.6's input rate of $3.00 per million tokens adds less than $0.00015 per call. At high volume that is measurable but not significant.

Negative example injection costs more. A tight two-example correction pair might add 150 to 200 tokens per call. At Claude Opus 4.8 pricing ($5.00 per million input tokens), running this on 500,000 calls per month adds roughly $500 in prompt costs. Not large, but worth tracking if you are optimizing a high-volume pipeline.

The hidden cost is maintenance. Banned phrase lists require ongoing attention because the model's behavior shifts with version updates. Claude Opus 4.8 may handle the constraint differently than Claude Sonnet 4.6. Every time Anthropic releases a new version, you should rerun your verification test. If you are using Claude Code in an automated pipeline, this is particularly relevant since model versions can change under you without an obvious changelog notification in your workflow.

There is also the cost of discovering new phrases. "Load-bearing" is the one that surfaced publicly, but it is almost certainly not the only phrase with this property in Claude's output distribution. Teams that care enough about prose quality to suppress one phrase will usually discover two or three others once the first is gone. This is not a one-time fix. It is the beginning of an ongoing vocabulary audit, and that audit takes writer time, not just engineering time. For a broader look at how model choice affects output style and cost trade-offs, see our earlier piece on managing Claude Opus spend.

The phrase "load-bearing" is strange precisely because it sounds good. It sounds like something a careful, technically literate person would say. That is why it propagated through training rather than getting filtered out as noise. And that is why, when you first read about people specifically suppressing it, the reaction is usually mild disbelief followed by immediate recognition: yes, that is in there, and now that someone named it, it is impossible to un-see. The fix is real work. But the first step, which is simply knowing this is a consistent pattern with a documented cause, is worth more than any prompt trick alone. You can compare how different models handle stylistic consistency by checking the Claude vs Gemini comparison, where output voice and adherence to constraints is one of the tested dimensions.