Ollama's OpenAI-compatible /v1 endpoint silently drops the think toggle

The bug

Ollama ships an OpenAI-compatible /v1 endpoint precisely so that applications written against OpenAI's chat API can point at locally hosted models with minimal changes. According to a post on dev.to, that endpoint has been silently discarding the think toggle for Qwen3-family models, and the failure mode is particularly awkward: the model consumes its entire generation budget on hidden reasoning and then returns an empty response.

The post's example is a request to the qwen3 model asking it to translate "hello" into French, with "think": false included in the payload. The expectation was a short, direct answer with no chain of thought. What actually happened, the authors report, is that the flag never reached the model. It reasoned internally until it exhausted its num_predict budget, the cap on how many tokens it may generate, and produced no visible content at all.

Why the flag matters

Qwen3 belongs to a growing set of hybrid reasoning models that can emit an internal chain of thought before answering. That reasoning helps on hard problems and is wasteful on trivial ones, which is why Ollama exposes a per-request think flag to turn it on or off. When the switch is ignored, you do not get slightly worse behaviour. You get a request that succeeds at the HTTP level, returns a well-formed response object, and contains nothing where the answer should be. There is no error to catch, only an empty string.

The workaround

The fix described in the dev.to post is to bypass the compatibility layer and call Ollama's native /api/chat endpoint instead. The payload is nearly identical: same model, same message list, same "think": false field. On the native endpoint the flag is respected, so the model answers directly and returns the expected output.

The tradeoffs

The workaround is not free. Code built on OpenAI-compatible clients has to be refactored to speak Ollama's native API, which is exactly the integration work the /v1 endpoint exists to avoid. The post's authors also caution that /api/chat may carry different rate limits and pricing structures than the compatibility endpoint, which is worth verifying against your own deployment. They are additionally investing in monitoring and alerting so that silent behavioural changes like this get caught earlier next time.

The post does not explain why the flag is dropped. One plausible reading, and this is speculation rather than something the source confirms, is that think is an Ollama-specific extension rather than part of the OpenAI API schema, so a compatibility layer that forwards only standard fields would strip it. Teams hitting the same symptom may want to reproduce the behaviour on their own Ollama version before assuming a cause.

Why it matters

OpenAI-compatible endpoints have become the lingua franca of LLM tooling: every framework, agent library and proxy assumes them. That convenience depends entirely on parameters actually being passed through, and non-standard flags like think are exactly where silent divergence shows up. A missing flag on a hybrid reasoning model is not cosmetic. It multiplies token usage and latency, and in this case it produced completions with no content at all, which looks like a model bug while actually being a plumbing bug.

The practical lessons are straightforward. Integration tests for LLM applications should assert that toggles such as think take effect, empty completions deserve an alert, and "OpenAI-compatible" always deserves an asterisk until you have verified which parameters survive the trip from your client to the model.