Chat completions

Request

The request body is forwarded to the model server as you send it, after the input policy stage. These fields are understood and passed through: messages, temperature, top_p, max_tokens, max_completion_tokens, stop, tools, tool_choice, response_format, seed, stream, stream_options, user. Unknown fields are passed through unchanged.

• n must be 1 or omitted.
• Multimodal content parts are forwarded; policy evaluates their text parts.
• Optional header X-Unrefused-Policy: name or name@vN selects another profile from your workspace for this request.

Response

A standard chat.completion object with one extra top-level field:

{
  "id": "chatcmpl-…",
  "object": "chat.completion",
  "model": "unrefused-glm-5.3-flash",
  "choices": [{ "index": 0, "message": { "role": "assistant", "content": "…" }, "finish_reason": "stop" }],
  "usage": { "prompt_tokens": 19, "completion_tokens": 51, "total_tokens": 70,
             "prompt_tokens_details": { "cached_tokens": 0 } },
  "unrefused": {
    "request_id": "req_93f1a1c7182d44e29542e08c",
    "policy": "eval-harness@v14",
    "input": "redacted=1",
    "output": "pass",
    "retention": "none"
  }
}

SDKs ignore the extra field; read it from the raw response when you need it. The same values are in the decision headers.

When a policy blocks

If the input stage blocks, the model is never called and you get 400 policy_blocked with param: "input". If the output stage blocks a non-streamed response, you get the same error with param: "output" and the completion is discarded.

{ "error": { "message": "Request blocked by policy (output): block=pii",
             "type": "invalid_request_error", "param": "output", "code": "policy_blocked" } }

Tool calls

Tool definitions and tool-call responses pass through unchanged. Policy evaluates message text; tool-call arguments are not stored anywhere.