HowdoLLMrefusalbenchmarksmeasurerefusalrate?

What is a refusal rate?

An LLM refusal benchmark is a fixed set of prompts used to measure a model’s refusal rate: the fraction of prompts it declines to answer, usually reported as a percentage. On its own the number says nothing. It only means something relative to what the prompts were: a 5% refusal rate on harmless prompts is a flaw, and a 5% refusal rate on dangerous prompts is a safety failure in the other direction.

That is why benchmarks fall into two families:

• Over-refusal benchmarks use prompts that sound risky but are fine to answer. Every refusal is an error. Examples: OR-Bench, XSTest.
• Harm benchmarks use prompts a model should decline. Every refusal is a success, and the headline number is how often the model complies anyway. Examples: SORRY-Bench, HarmBench.

Refusal Rate, the site you are reading, cares about the first family, because that is where developers feel the problem. Why models behave this way is covered in why LLMs over-refuse.

Which LLM refusal benchmarks measure over-refusal?

The two reference benchmarks are XSTest and OR-Bench, with newer domain and multilingual sets building on them.

XSTest is small and hand-written, which makes it a quick sanity check. OR-Bench is generated automatically, which makes it large enough to rank dozens of models, at the cost of some noisy prompts. The authors say human review flagged 2.9% of the hard subset and that it may still contain debatable prompts because an LLM moderated it.

The harm-side counterparts are SORRY-Bench (440 unsafe instructions across 44 topics, plus 20 linguistic variations such as different phrasings and formats) and HarmBench (510 harmful behaviors, evaluated across 18 red-teaming methods and 33 target models and defenses). Their prompts are not reproduced here.

How do benchmarks decide what counts as a refusal?

Benchmarks decide by one of three methods: keyword matching, an LLM judge, or human labeling. The choice changes the number.

1. Keyword or prefix matching. If the response opens with a phrase like “I’m sorry” or “I cannot”, it counts as a refusal. It is cheap and reproducible. XSTest’s authors note it cannot separate full from partial refusal. OR-Bench uses it on the whole 80K set.
2. LLM judge. A model reads the prompt and response and labels it. OR-Bench uses GPT-4 for its hard and toxic subsets. SORRY-Bench meta-evaluated judge designs against more than 7,000 human annotations and found that fine-tuned 7B judges can approach GPT-4-scale accuracy at lower cost. HarmBench scores non-copyright behaviors with a fine-tuned Llama 2 13B classifier that agreed with human labels 93.19% of the time on its validation set, against 88.37% for GPT-4.
3. Human labeling. XSTest treats manual annotation as the reference: two annotators per prompt, disagreements settled by discussion. XSTest uses a three-way taxonomy of full compliance, full refusal and partial refusal.

The methods disagree by small but real margins. OR-Bench reports keyword matching running slightly below its GPT-4 check, for example 10.6% versus 13.0% for GPT-3.5-turbo-0125, because indirect refusals escape the keyword list. XSTest found GPT-4 as a classifier struggles most with partial refusals.

Judges also have their own bias. The OR-Bench authors dropped Claude-3-Opus from their prompt-moderation panel because it labeled many prompts toxic that other models called safe, and used an ensemble of GPT-4-turbo, Llama-3-70b and Gemini-1.5-pro instead.

What do published results show?

Published results show enormous spread between models, and between prompt sets for the same model. The table below is reported by the OR-Bench paper (v5, June 15, 2025). The paper does not state when the evaluations ran, and the models are mostly 2023 to 2024 releases, so treat it as a snapshot of the method, not a current ranking.

Two things to read from it. First, the hard subset was built from prompts that models tend to reject, so its rates are far higher than the 80K set, and the authors call the 80K set the better indicator of everyday use. Second, versions of the same family move a lot: GPT-3.5-turbo went from 34.7% to 0.9% on the 80K set across three snapshots.

XSTest tells the same story on a smaller scale. On its 250 safe prompts, with manual labels, Llama 2 with its original system prompt fully or partially refused 59.6% (38% full, 21.6% partial). Without the system prompt that fell to 29.6%. Mistral-7B-Instruct with no system prompt refused 1.6%, and GPT-4 refused 8.4%. The same weights gave very different numbers once the system prompt changed, so a refusal rate describes a model plus its deployment, not weights alone.

Why is refusal rate alone misleading?

Refusal rate alone is misleading because a single-turn benchmark cannot see how refusals happen in real work. In anthropics/claude-code issue #84815 (closed as not planned), a developer reported that a built-in malware reminder led the agent to refuse edits to their own defensive security code, even with in-prompt authorization and a CLAUDE.md. A prompt-set score would never show that. Refusing less is also not the same as being better. OR-Bench reports a Spearman rank correlation of 0.89 between rejection of safe prompts and rejection of toxic prompts across its models. In plain terms, most models that refuse fewer harmless prompts also refuse fewer harmful ones. A model with a 0% refusal rate would look perfect on an over-refusal benchmark and fail every harm benchmark.

Other blind spots to keep in mind:

• Refusal is not the only failure. The StrongREJECT authors argue that existing evaluations overstate jailbreak success and score how useful a response is, not just whether the model declined. A model can comply with a prompt and still give a useless answer.
• Refusing is not binary. Health-ORSC-Bench argues that refuse-or-comply scoring misses the middle ground of high-level, safe completions on dual-use questions.
• Prompt sets age. Models are trained against public benchmarks, and a leaked test set stops measuring anything.
• Coverage is thin. The Health-ORSC-Bench authors note general benchmarks give minimal healthcare coverage. Coding, security and reverse-engineering requests, the ones developers care about, have no widely used over-refusal set that this page could verify.
• Context is invisible. Single-turn prompts with no system prompt differ from a real agent loop, as the issue above shows.

A refusal rate for an abliterated model, covered in what abliteration is, needs the same care: lower refusals are the intended result, and the question is what else changed.

What do practitioners report about benchmarks versus real use?

Practitioners report that benchmark scores and daily experience diverge, mostly because benchmarks test the model while developers meet the model plus a harness. These are community and third-party reports, not our measurements.

• A homemade check can be simple and still informative. A developer’s blog post (Aug 2026) tested five local models on 10 defensive security tasks each, on an RTX 5090 via Ollama at temperature 0. They scored refusals with deterministic markers in the first 400 characters of each response, deliberately avoiding a judge model that could add its own refusal behavior. All 50 tasks produced no refusals (two timed out), but the author stresses the sample is tiny and that willingness is not accuracy. It is a keyword-style method in practice, with the weaknesses described above.
• A single rate hides the trade-off, and some new benchmarks say so. RefusalBench, a third-party leaderboard on biological research prompts, reports benign-refusal and dual-use rates separately and combines them with Youden’s J. It covers 22 models and 141 prompts. Its page notes that one model was judged by a rotated panel, so cross-panel comparisons carry a caveat. It is a different domain from coding, so it shows the method, not coding numbers.
• Alignment strength varies by model family. The author of the Heretic abliteration tool wrote on Hacker News that gpt-oss and Qwen3 were much harder to push toward lower refusal rates than Llama 3.1. That concerns removal difficulty rather than a refusal rate, but it is why a post-modification refusal rate needs the benchmark, the method and the model version stated.

How will Refusal Rate measure it?

Refusal Rate has not published any measurements yet. The plan, not yet executed, is a monthly evaluation on a fixed prompt set aimed at developer tasks, with every run labeled with the model version, quantization, hardware and settings, and with the judging method stated next to each number. Results will appear on the uncensored LLM leaderboard once they exist. Until then, treat any model ranking on this site as a summary of the papers above and nothing more.

FAQ