Release Notes

0.0.11b0 — 2026-07-08

Model name override — each entry in the models config file accepts an optional model field that overrides the model name forwarded to the upstream provider. This decouples the routing key (name, matched against the request's model) from the model string the provider receives — useful when a friendly route alias needs to map to a different upstream model, such as fronting an Azure AI Foundry agent endpoint. When omitted, the request's model is forwarded unchanged, so existing configs are unaffected. See Configure the upstream provider.

Responses API null tool fields — the Responses API no longer sends unset optional parameters (such as tools: null) as explicit JSON nulls to the upstream provider. Azure AI Foundry rejects explicit nulls with HTTP 400; unset fields are now omitted from the upstream request, fixing tool-calling requests against Foundry endpoints.
Documentation links — fixed broken "Model routing" links in the server run guide that pointed at a non-existent anchor. Upstream provider configuration now lives on its own Configure the upstream provider page, and the cross-references from the Chat Completions and Responses API pages have been updated accordingly.

Azure deployment URL routing — the server accepts requests on the native Azure path (/openai/deployments/{deployment}/chat/completions), so Azure OpenAI SDK clients can point at the guardrail server without changing their URL shape. The deployment name from the path is used as the model identifier when the request body omits model.
Streaming — Chat Completions and Responses API endpoints now support stream: true with Server-Sent Events. Pre-flight and input guardrails run before the first byte; output guardrails run periodically during the stream and once at completion.
Tool-calling parameters — tools, tool_choice, and parallel_tool_calls are now accepted on Chat Completions and Responses API requests and forwarded to the upstream provider unchanged. Use them to enable function calling through the guardrail server the same way you would with the OpenAI API directly.

Moderation keyword allowlist — the HarmfulContent guardrail accepts a keyword_allowlist of terms or phrases. When the input matches an allowlisted keyword (case-insensitive), enforcement is suppressed even if the toxicity or harmful-request model would otherwise trigger.

Responses API — the server now supports the OpenAI Responses API in addition to Chat Completions, applying the same guardrail pipeline to both.
List models — a new endpoint returns the list of configured upstream models in OpenAI-compatible format.
Model routing — the server can route each request to a different upstream provider based on the model name, configured via a JSON file.
Per-request header/query forwarding — the server can relay specific headers and query parameters from the inbound client request to the upstream LLM, controlled by an explicit allowlist.