API contract
OpenAI web search guardrails in an LLM proxy
Expose web_search only when the selected OpenAI model is configured to support it.
Teams that need controlled search-enabled model calls without making web search a universal flag.
The problem
A generic web_search flag can be misleading when only some providers and models support a search tool.
How LLM Proxy helps
LLM Proxy accepts web_search per request but enables it only for OpenAI model catalog entries marked with web_search support.
How it works
- Mark supported OpenAI model entries with web_search: true in config.yml.
- Send exact web_search=true only when the selected route supports it.
- Expect unsupported provider/model combinations to fail before an upstream call.
- Keep non-OpenAI providers on normal text routing.
Feature-to-benefit table
| Feature | Why it matters here | Example |
|---|---|---|
| Exact boolean contract | GET / accepts only web_search=true or web_search=false. | Other supplied spellings return 400 instead of silently disabling search. |
| Model-aware flag | The request option is checked against provider and model metadata. | DeepSeek with web_search returns a client error instead of a hidden fallback. |
| Config-owned support | OpenAI web-search support is explicit in the model catalog. | Operators can see which model entries expose the capability. |
| Early rejection | Unsupported combinations fail before provider spend. | Callers get a clear request error. |
Use-case examples
Research prompt
A caller selects gpt-5 with web_search=true for a search-enabled answer.
Non-search provider
A Gemini request with web_search does not silently pretend to search.
Default model check
If the tenant default model lacks web search, the request must choose a supporting OpenAI model.
Objections and limitations
- Web search is currently exposed only for configured OpenAI model entries.
- The proxy does not claim provider-side search for providers without an implemented search adapter.
- Search-enabled answers are still provider outputs and should be evaluated by the caller.
FAQ
What is the main job of OpenAI web search guardrails?
LLM Proxy accepts web_search per request but enables it only for OpenAI model catalog entries marked with web_search support.
Who should read this api contract resource?
Teams that need controlled search-enabled model calls without making web search a universal flag.
Does this page claim provider performance or pricing advantages?
No. The supported claim is about LLM Proxy's documented routing, configuration, management, security, usage, and deployment contracts. Provider cost, speed, rankings, and benchmark claims are not made here.
Where should setup details come from?
Use the main README and implementation notes for current command, config, and endpoint details. This page summarizes the workflow without replacing LLM Proxy documentation.
What should I read next?
A closely related resource is Canonical /v2 chat messages API for LLM calls, which covers v2 chat messages API.
Related resources
Use this pattern in LLM Proxy
Start from the canonical API reference, then use the management surface when the workflow needs tenant or provider configuration.
Open API reference