The reasoning_effort Cross-Platform Compatibility Challenge: A Troubleshooting Record Triggered by a 400 Error

When your application simultaneously connects to OpenAI cloud, self-hosted vLLM, and third-party relay services, how many pitfalls can a seemingly unified reasoning_effort parameter expose? A Japanese developer's hands-on record provides the answer: browser operations completely failed, streaming responses were silently lost, and even self-inflicted regressions appeared one after another. The root cause isn't model capability—it's that the error classifier misread the 400 response body.

Cloud: Tools and Reasoning Parameters Are Mutually Exclusive, but the Error Message Was Misread

The first failure occurred when sending both a tool definition and reasoning_effort to gpt-5.6-luna. The API returned 400, and the response body clearly stated: "Function tools with reasoning_effort are not supported... To use function tools, use /v1/responses or set reasoning_effort to 'none'."

The application saw the words tool and not supported and immediately concluded that the model doesn't support tool calls, permanently stripping tools from requests thereafter. The result: when the user asked for browser operations, the model had no tools to call. On the surface it looked like the model was avoiding tools, but in reality tools were never provided.

The fix was simple—carefully read the solution part of the error message. Keep the tools, set reasoning_effort to 'none', and retry; tool calls returned to normal. A side benefit was latency dropping from 4–5 seconds to 2 seconds, a direct improvement to the interactive experience.

The lesson from this case: the 400 response body isn't meant for keyword matching—it's structured diagnostic information containing repair instructions.

Differences Between the OpenAI Responses API and Chat Completions API: The error message in the article suggests switching to /v1/responses, which is OpenAI's newer Responses API. Unlike the traditional Chat Completions API, the Responses API natively supports combining tool calls with reasoning parameters and can return reasoning summaries in the same request. Many third-party clients are still built on the Chat Completions endpoint, so when encountering the mutual exclusivity of tools and reasoning_effort, simply falling back to reasoning_effort: 'none' is a compatibility compromise at the cost of reasoning depth. If the endpoint supports the Responses API, migrating to it preserves both tools and reasoning capability, but introduces new request/response structure differences that require a separate adaptation layer.

Self-Hosted vLLM: Value Range Incompatibility and Field Naming Divergence

After migrating the same configuration to a self-hosted vLLM instance, the tool calling path again returned 400. This time the error type was literal_error, with the message "Input should be 'low', 'medium' or 'high'"—vLLM simply doesn't accept the value none.

During pure conversation tests, the developer might not notice the problem at all, because conversations got faster and everything seemed normal. Only by specifically testing the tool calling path can one discover that the endpoint handles values differently.

For this endpoint, the application was changed to stop sending reasoning_effort after detecting value rejection, and instead use chat_template_kwargs: { enable_thinking: false } to disable thinking. The measured comparison is as follows:

Method of Disabling Thinking	Time
No processing	87 seconds
/no_think	154 seconds
enable_thinking=false	65 seconds
reasoning_effort none	2 seconds

A more subtle issue lies in the output fields. The field name for thinking content has three variants in the ecosystem: reasoning, reasoning_content, and thinking. The write side recognizes all three, but the read side only looks for reasoning. vLLM writes reasoning_content, so after switching endpoints the classifier reported "empty response" five times in a row—the model clearly returned thinking content, but the read side looked at the wrong field, making it impossible to even count the amount of thinking.

How chat_template_kwargs and enable_thinking Work: When rendering conversation templates, vLLM allows passing additional variables to Jinja templates via chat_template_kwargs. enable_thinking is a switch agreed upon in the templates of some models (such as the Qwen series), used to control whether a thinking segment is generated in the output. It is not a standard OpenAI parameter but a template-level convention, so different models and template versions may name it differently or not support it at all. This is also why pure conversation appears normal on the same vLLM instance while the tool path fails—the template switch only affects generated content, not API parameter validation. Before use, confirm whether the chat template of the model in use recognizes this variable; otherwise it will be silently ignored.

Relay Services: Streaming Empty Responses and content-type Traps

The third problem was in streaming response handling. Some endpoints ignore stream: true and directly return standard JSON. The application discards all lines that don't start with data:, resulting in zero fragments captured. Since response.ok is true, no exception is thrown, and nothing appears on screen.

The fix is to check content-type to determine the response type. But the problem wasn't over: one relay endpoint returned 200 OK in only 94ms in streaming mode with an empty response body; non-streaming calls instead returned 400. The empty response provided no error information for diagnosis.

For this, the developer chose to treat empty responses as exceptions: retry once after disabling the thinking spec, and if it still fails, stop sending requests to that endpoint. After the retry, correct JSON was returned in 327ms. The final endpoint adaptation strategy is: standard endpoints send reasoning_effort: 'none'; vLLM switches to chat_template_kwargs after value rejection; relay endpoints that return empty in streaming mode receive no reasoning parameters at all.

SSE (Server-Sent Events) and Streaming Response Detection: Streaming responses from OpenAI-compatible interfaces typically use the text/event-stream content-type and separate events with data: lines. However, some relay services or proxies ignore stream: true and directly return a complete application/json response, or return 200 with an empty body. If the client only parses based on the data: prefix, it will discard the complete JSON or capture zero fragments. A robust implementation should first check content-type, then decide whether to use the SSE parser or the JSON parser; at the same time, set up separate exception paths for empty bodies and zero fragments, and never judge success solely by response.ok.

Self-Inflicted Regressions: Overly Broad Classifiers and Configuration Contamination

After fixing endpoint differences, the developer introduced two new problems.

The first regression was overly broad 400 error body detection. The detection logic also checked for the invalid keyword, causing 400 responses containing invalid_request_error to be treated identically. The system incorrectly learned that gpt-5.6-luna "lacks the reasoning_effort field" and stopped sending even the necessary none specification, causing browser operations to fail entirely. The root cause was that the tests used self-made error messages that differed from real rejection responses. The fix was to use recorded real error bodies for testing.

The second regression was local settings contaminating cloud endpoints. A thinking auto-truncation setting enabled during voice conversations was applied globally, causing none to be sent to the official OpenAI endpoint. All response generation requests timed out after 60 seconds and returned 500, four consecutive attempts, while the OpenAI status page showed the service was normal. The fix was to limit that setting to local providers only.

Additionally, the retry mechanism for rejected fields had a flaw: only one retry was allowed per utterance, so if temperature and frequency_penalty were rejected simultaneously, the first utterance would silently fail. The updated logic removes the field and retries after each rejection, up to 8 times; if at least one character of response is received before failure, no retry is triggered.

Design Principles for Error Classifiers: Matching error response bodies based on keywords is fragile, because error message wording varies greatly across providers and versions, and may contain generic types like nested invalid_request_error. A more reliable approach is to parse the structured fields of the error body (such as error.type, error.code, error.param) and make decisions for specific fields and values. Tests should use recorded real error responses as fixtures, covering typical rejection scenarios for each endpoint, to avoid self-made messages masking logic flaws. Classifiers should also follow a "minimal learning" principle: adjust requests only based on explicit repair instructions, and don't globally disable parameters due to generic error types.

Engineering Principles for Multi-Endpoint Adaptation

This set of hands-on records points to several reusable principles. First, the 400 response body must be read in full before classification; keyword matching will miss the solution. Second, the behavior of reasoning_effort should be determined by actual endpoint testing, not assumed compatibility. Third, writing and reading of thinking fields need to cover all three naming variants: reasoning, reasoning_content, and thinking. Fourth, streaming empty responses need a separate exception path; success cannot be judged by response.ok. Fifth, test cases must use recorded real error bodies; self-made messages will mask flaws in detection logic.

When an application claims to support "OpenAI compatibility," the boundary of compatibility is often much narrower than the similarity of interface paths. Parameter value ranges, field naming, streaming behavior, and error semantics—each dimension can diverge independently.

One-line Summary

Through 400 error troubleshooting, reveals the compatibility pitfalls and repair principles of reasoning_effort across cloud, vLLM, and relay services.

Paragraph Summary

The article records a series of failures caused by the reasoning_effort parameter when a Japanese developer connected to OpenAI cloud, self-hosted vLLM, and third-party relay services. The cloud API returned 400 because tools and reasoning parameters are mutually exclusive; the error body already provided a solution, but the application permanently stripped tools due to keyword misjudgment. vLLM rejected the none value and wrote thinking content into the reasoning_content field, causing the read side to report empty responses. The relay service returned empty 200 responses in streaming mode, requiring content-type detection and retries. During the fixes, self-inflicted regressions of overly broad classifiers and global configuration contamination also appeared. Finally, multi-endpoint adaptation principles were distilled: read 400 response bodies in full, test behavior per endpoint, cover three thinking field naming variants, handle streaming empty responses separately, and test with real error bodies.