Refusals and Safety Stops

Refusals

Part of: Reading Model Outputs

You wire up a model to answer customer questions, ship it, and one day it replies "I'm sorry, but I can't help with that request." Your app proudly displays those words as if they were a real answer, formatted, timestamped, sitting in the chat bubble. The model didn't fail. It refused , on purpose, and your code never noticed the difference between a refusal and an answer. Reading that difference is the whole skill. What it is A refusal is when the model declines to fulfill a request, usually for safety, policy, or capability reasons, and says so in plain language instead of doing the task. A close cousin is the safety stop : the platform's filter blocks the output entirely, and the response signals that the content was withheld rather than completed. The trap is that a refusal looks like a normal answer. It arrives in the same content field, with the same fluent tone, and often with finish reason == "stop", because from the model's point of view, "I can't help with that" is a complete, natural reply. Naively, your code treats it as a successful answer and shows it to the user as if it solved their problem. How it works There are two signals to watch. First, the structured one: som

Challenge: Refusal Router