> ## Documentation Index > Fetch the complete documentation index at: https://gomodel-feat-per-child-quotas.mintlify.site/llms.txt > Use this file to discover all available pages before exploring further. # Responses compatibility > Understand which Responses API features GoModel can translate to chat providers, which ones require native provider support, and how this affects agent SDKs. GoModel accepts OpenAI-compatible `/v1/responses` requests and routes them to the selected model provider. Some providers expose a native Responses-compatible surface. Others expose chat completions or provider-native chat APIs, so GoModel translates the request. The compatibility rule follows Postel's Law: GoModel translates portable model features and accepts unfamiliar tool declarations without forwarding them to a provider that cannot execute them. Fields that would change the meaning of the model output are still rejected when they cannot be translated safely. ## Routing modes | Mode | What happens | | ------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------- | | Native Responses provider | GoModel forwards the Responses payload to the provider's Responses-compatible endpoint. Provider-native features may work if that provider supports them. | | Chat-translated provider | GoModel converts `/v1/responses` to chat semantics, calls the provider's chat API, then converts the result back to a Responses shape. | Chat-translated providers include Anthropic and Gemini native routing. They work well for text, streaming, multimodal inputs supported by the target adapter, and function tool loops. They cannot safely execute OpenAI-hosted tools. ## Feature behavior | Feature | Native Responses provider | Chat-translated provider | | ------------------------------------------------------------------------------------------- | -------------------------- | ------------------------------------------------------------ | | Text input and `instructions` | Forwarded | Converted to chat messages | | Streaming over HTTP/SSE | Forwarded | Converted from chat streaming events | | Function tools | Forwarded | Converted to provider function/tool declarations | | Function call output items | Forwarded | Converted to chat tool-result messages | | `text.format` structured output | Forwarded | Converted to `response_format` when the provider supports it | | Responses-only tools (`web_search`, `file_search`, `computer_use_preview`, and `namespace`) | Provider decides | Accepted and omitted | | `previous_response_id` and `conversation` | Forwarded | Rejected | | `include` annotations | Forwarded | Accepted and ignored, except `message.output_text.logprobs` | | Unknown Responses input item types | Preserved | Rejected | | Responses websocket transport | Not implemented by GoModel | Not implemented by GoModel | Anthropic does not currently accept translated `response_format` or `text.verbosity` settings through GoModel's chat translation path. GoModel rejects those fields instead of dropping them. ## The `include` field `include` asks for extra annotations on response items, such as `reasoning.encrypted_content` or `file_search_call.results`. It never changes what the model does, so chat-translated providers accept it and return a response without those annotations, exactly like a native provider that does not support them. Clients that always attach `include`, such as Codex with `wire_api = "responses"`, work without extra configuration. The one exception is `message.output_text.logprobs`, which requests real model output rather than an annotation. GoModel rejects it for the same reason it rejects `top_logprobs`. ## Hosted tools Hosted tools are executed by the upstream provider, not by the model text completion alone. Their payloads often reference provider-owned resources and runtime state: * `web_search` and its legacy `web_search_preview` alias depend on the provider's search implementation and event schema. * `file_search` references provider vector stores such as `vector_store_ids`. * `computer_use_preview` depends on a provider-managed computer session, display environment, and safety model. GoModel does not translate these into Anthropic, Gemini, or other chat-provider tool calls. A fake translation would change where the tool runs, how state is stored, and which security controls apply. Chat-translated providers therefore accept the request but omit every non-function tool before provider dispatch. Supported function tools in the same request continue to work normally. `namespace` tools are omitted as a unit rather than flattened. Flattening would change the tool names and break the client's routing contract. A `tool_choice` that selects an omitted tool is omitted too. If every tool is omitted, `parallel_tool_calls` is also removed from the translated request. This is graceful capability degradation, not hosted-tool emulation. In particular, a response from a chat-translated provider does not imply that a web search, file search, or computer action occurred. Use a native Responses provider when the result depends on one of those tools running. ## Agent SDKs OpenAI Agents SDK clients can talk to Anthropic and Gemini models through GoModel for portable flows: * plain `Runner.run(...)` * `Runner.run_streamed(...)` over HTTP/SSE * local function tools * SDK-managed local history replay Provider-hosted tools are ignored by chat-translated providers. Server-managed conversation state and websocket Responses transport still depend on provider-specific support. For Python Agents SDK clients, namespaced GoModel model IDs such as `anthropic/claude-sonnet-4-20250514` and `gemini/gemini-2.0-flash` need model ID pass-through mode: ```python theme={null} from agents import MultiProvider, RunConfig from openai import AsyncOpenAI client = AsyncOpenAI( base_url="http://localhost:8080/v1", api_key="change-me", ) run_config = RunConfig( model_provider=MultiProvider( openai_client=client, unknown_prefix_mode="model_id", openai_prefix_mode="model_id", ) ) ``` Use that `run_config` when calling `Runner.run(...)` or `Runner.run_streamed(...)`. ## Test the compatibility boundary The OpenAI Agents SDK examples include probes for Anthropic routing through GoModel: ```bash theme={null} export OPENAI_BASE_URL=http://localhost:8080/v1 export GOMODEL_MASTER_KEY=change-me export OPENAI_MODEL=anthropic/claude-sonnet-4-20250514 python3 docs/examples/openai-agents-sdk/anthropic_responses_probe.py python3 docs/examples/openai-agents-sdk/anthropic_agents_probe.py ``` The Responses probe verifies both supported and unsupported paths: plain Responses calls, function tools, structured-output rejection, stateful-field rejection, unknown input-item rejection, and graceful hosted-tool omission. The Agents probe verifies basic runs, function tool loops, and streamed function tool loops. ## Roadmap Future support for hosted tools should use explicit provider capability mapping. That means GoModel should know which provider, model, API mode, and request shape can safely handle each feature before accepting the request.