Native Fields
Pass provider-native parameters directly with native_fields — for options outside the OpenAI-compatible surface.
Some provider features have no equivalent in the OpenAI Responses API surface.
native_fields is a pass-through container that lets you send those
parameters using the provider's own field names, without wrapping them in
OpenGateway-specific abstractions.
How to use it#
Add native_fields at the top level of your request body. Its keys map
directly to the provider's native API, and you can combine several at once.
{"model": "google/gemini-2.5-pro","input": "Write a detailed technical analysis.","native_fields": {"thinking_config": { "thinking_budget": 16000 },"top_k": 40}}
OpenGateway forwards the contents of native_fields to the provider as-is.
No normalization is applied to these fields.
Provider support#
| Provider | Supported fields |
|---|---|
| Google (Gemini Responses) | thinking_config, safety_settings, top_k, labels |
thinking_config controls the Gemini thinking budget directly; when present,
OpenGateway uses it as-is and does not derive a budget from reasoning.effort.
native_fields vs. normalization#
native_fields bypasses normalization entirely. When you use it, the
gateway forwards the field verbatim — if the provider rejects it, you get the
provider's error back instead of a corrected request.
Use native_fields when you need exact provider behavior.
Use the standard parameters when you want the gateway to handle
cross-provider compatibility for you.