WhatisLLMover-refusal,andwhydoesithitharmlesscodingquestions?

What is LLM over-refusal?

LLM over-refusal is a model declining a request that is safe to answer, usually because the request looks like an unsafe one. The XSTest authors call the same failure “exaggerated safety”: a model that refuses clearly safe prompts that resemble unsafe ones in wording or touch on sensitive topics. Their test suite pairs each safe prompt with an unsafe contrast, such as “kill a person” against “kill a Python process”, so a model has to read the whole request instead of reacting to the verb.

Developers hit this constantly. A question about terminating a hung process, parsing a suspicious binary you own, or explaining a vulnerability class for a code review can all trigger a refusal written for a very different user. The model is not judging your intent. It is matching a pattern.

Why do models refuse benign requests?

Models over-refuse mainly because safety training teaches them to associate surface cues with refusal, and some of those cues are not harmful on their own.

XSTest concluded that exaggerated safety is likely “a consequence of lexical overfitting, whereby models are overly sensitive to certain words or phrases.” A 2026 paper, Deactivating Refusal Triggers, makes the mechanism explicit. It defines refusal triggers as linguistic cues in the training data that elicit refusal, and argues that these include non-harmful cues, so the model learns to refuse benign queries that share them.

Three further findings sit behind this:

• Refusal is a compact internal signal. Arditi et al. found that across 13 open chat models up to 72B parameters, refusal is mediated by a one-dimensional direction in the residual stream. Erasing it stops refusals, and adding it makes models refuse harmless instructions. A single dial can fire on a surface feature.
• The boundary is blurry. Zhang et al. report that models are “unable to effectively distinguish between over-refusal samples and malicious samples” in representation space, which is why defenses that make a model safer tend to push benign prompts over the line too.
• Ambiguity has no free answer. A short prompt with no context (“write a payload that…”) has both benign and malicious readings, and a cautious model resolves it toward refusal.

How common is over-refusal?

Over-refusal is common enough to measure at scale, and it shrinks in newer models without disappearing. Benchmark detail belongs on the refusal rate benchmarks page; these are the findings that explain the cause.

XSTest tested three models in 2023 on 250 safe prompts:

Two takeaways. First, the same model refused far less once its system prompt was removed, so the policy layer you cannot see can matter as much as the weights. Second, Mistral’s unguarded version barely over-refused but also complied with even the most unsafe prompts, which is the trade-off in miniature.

OR-Bench scaled this up: 80,000 prompts that only look harmful across 10 categories, plus a hard subset of about 1,000 and 600 toxic prompts, run against 32 models from 8 families without system prompts. Its headline: the Spearman correlation between rejecting toxic prompts and rejecting safe ones is 0.89, so most models simply trade over-refusal for safety, with few breaking the trade-off. It also found newer models tend to over-refuse less than older ones.

These are published results on models available at the time of each paper. Current models differ, and we have not run our own tests yet.

Which coding questions trigger over-refusal most?

Coding requests that share vocabulary with harm trigger it most, and developers have reported this in real agents. In anthropics/claude-code issue #84815 (opened Aug 2026, closed as not planned), a developer says Claude Code refused to edit, commit or open a PR for their own prompt-injection guardrail, a defensive file listing the attack strings it blocks, even with an in-prompt statement that the repo was theirs. It is a single community report, not our test. The papers themselves measure general benign prompts, not coding, so the table below is inference from their findings rather than a measurement.

XSTest’s own “safe contexts” category is the closest analogue. Llama 2 with its original system prompt fully refused 24 of 25 of those prompts, such as asking how to kill someone in Call of Duty, even though it mostly recognized the safe context. The authors attribute such failures to overemphasis on what the prompt asks for rather than who or what it is about.

What do developers report in practice?

Developer reports match the research on the cause, and they add two things the papers do not cover: coding agents refuse at the tool layer, and newer open models are harder to un-refuse. These are community reports, not our tests, and each is one person’s experience.

• Context did not help in a coding agent. The reporter in the Claude Code issue above says the refusal spread to other files in the repo and persisted across fresh sessions despite a CLAUDE.md declaring the code defensive. This is the lexical-overfitting pattern in an agent: the file’s contents, not the task, tripped it.
• Older assistants did it with harmless requests too. A HuggingChat discussion from February 2024 reports that the CodeLlama 70B assistant “refuses and gets all preachy even with harmless requests.” The post gives no example prompts, so treat it as a sentiment signal. A second user says they saw the same.
• Stronger alignment resists weight edits. The author of Heretic, an automatic abliteration tool, wrote in a Hacker News comment that Llama 3.1 is trivial to decensor, while for gpt-oss and Qwen3 most parameter settings barely changed refusals. Another commenter in that thread guessed that thinking models are harder to decensor because they are trained to reason about whether to accept a request. That is speculation, not a measurement.
• Some open models were taught refusal, others were never taught the topic. One HN commenter argues gpt-oss was trained on a curated dataset that left some material out of pretraining, while most other models know the answer and were only taught refusal in post-training. It is an unverified claim, but it explains why removing a refusal does not always restore capability.
• Local models often take defensive work. A blog post by a developer (Aug 2026) ran 10 defensive security tasks, about systems they own, against each of five local models on an RTX 5090 through Ollama, one run per task at temperature 0. None refused, though two runs timed out. The author’s own caveat applies: zero refusals says nothing about answer quality, and one model confidently misnamed a vulnerability class.

Taken together, the reports suggest refusals depend on the whole stack, meaning the model, the harness and the wording, which is why the research finding that a system prompt moves the number is not an academic point.

What can developers legitimately do about it?

Developers can usually reduce over-refusal by being clearer, choosing a better-calibrated model, or running a model they control. None of this requires tricking a hosted model, and trying to bypass a provider’s policy is outside what this site covers.

1. Say what you are actually doing, accurately. Name the task, the system you own, and the defensive purpose. Research on mitigation found that inference-time rephrasing and context help. Yuan et al. (arXiv 2510.08158) tested ignore-word instructions, prompt rephrasing and attention steering on four instruction-tuned Llama models and report improved compliance on safe prompts while keeping safety protections. Anthropic’s constitution also lists apparent legitimacy, such as a penetration tester asking about an existing piece of malware, as something that can change whether Claude should help. It notes models cannot verify claims, so true context may still be declined, and developers do report that (see the community section above).
2. Remove the trigger word if it is incidental. “Stop the worker process” says the same thing as “kill the worker” without the cue. This is clarity, not evasion. If the word is the point of the task, say so plainly instead.
3. Switch models or deployment. Calibration varies. Anthropic’s constitution says that with no operator prompt, Claude “is likely being tested by a developer and can apply relatively liberal defaults.” A raw API call and a consumer app can behave differently on the same prompt.
4. Use a local open-weight model. You control the system prompt and the policy layer, and your code never leaves the machine. Some people go further and edit the weights; see what abliteration is and how abliterated, uncensored and fine-tuned models differ for the trade-offs, including quality loss and license terms that still apply.
5. Report the false refusal. Both vendors publish guidance that counts needless refusals as a failure. Anthropic’s constitution lists “refuses a reasonable request, citing possible but highly unlikely harms” among behaviors a thoughtful reviewer would be unhappy to see, and OpenAI’s Model Spec states that the assistant “should never refuse a request unless required to do so by the chain of command.” A report with the exact prompt shows a vendor where shipped behavior misses its own stated policy.

When is a refusal correct?

A refusal is correct when the likely harm is severe and the request offers real uplift, even if most askers are benign. Anthropic’s constitution frames this as thinking about the whole population of people who would send a message. A question about which household chemicals not to mix is fine to answer, while a request for step-by-step instructions to make a dangerous gas at home deserves more hesitation. OpenAI’s Model Spec makes the same point from the other side: a model should refuse tips for getting away with shoplifting but comply with shoplifting deterrence tips, even though the latter could be misused.

For coding, the line tends to fall between understanding and operational capability. Explaining how a vulnerability class works, writing a detection rule or analyzing a sample for defense is different from producing a working attack against a system you do not own. For security work done with authorization, see AI for security research.

FAQ

Why does my LLM refuse to answer a normal coding question?

Most likely a word or topic in your prompt matches patterns the model learned to refuse, such as “exploit,” “payload” or “kill.” XSTest attributes this to lexical overfitting, and OR-Bench shows it is a general trade-off between safety and helpfulness, not a bug in your prompt.

Is over-refusal the same as a safety refusal?

No. A safety refusal declines a request that is actually harmful. Over-refusal declines a safe request. The difficulty is that both can look similar to the model, which Zhang et al. attribute to benign and malicious prompts overlapping in representation space.

Do newer models refuse less?

Generally yes. OR-Bench found newer models tend to over-refuse less than older ones, and XSTest showed GPT-4 refusing far fewer safe prompts than Llama 2 did in 2023. Both studies are dated, so check recent evaluations for the model you use.

Does a system prompt make refusals worse?

It can. In XSTest, Mistral-7B with a guardrail system prompt went from 4 refusals of any kind in 250 safe prompts to about 19%, and removing Llama 2’s original system prompt cut its full-refusal rate from 38% to 14%.

What is a “refusal vector”?

It is the direction in a model’s activations that Arditi et al. found mediates refusal across 13 open chat models. Removing it stops refusals and adding it triggers them on harmless prompts. It is the mechanism behind abliteration.