Qwen3.6-35B-A3B-4bit returns thinking-only responses with no visible content via OpenAI-compatible API

[jsirish]

Environment

• oMLX version: v0.3.7rc2
• Model: mlx-community/Qwen3.6-35B-A3B-4bit
• Preset: qwen3.5/6 (r,code)
• TurboQuant: enabled
• SpecPrefill: enabled, draft model qwen3-0.6B-4bit
• API: OpenAI-compatible /v1/chat/completions
• Hardware: Apple Silicon (M-series)

Description

When using the Qwen 3.6 35B MoE model through the OpenAI-compatible API, the model consistently returns responses containing only reasoning_content (thinking) with no actual content field. This results in the downstream client (OpenClaw gateway) seeing an empty/thinking-only response and surfacing an "incomplete turn" error.

Qwen 3.5 35B MoE (Qwen3.5-35B-A3B-4bit) works correctly with the same configuration — it returns both reasoning_content and content in the response.

Observed behavior

The API response includes a choices[0].message with:

• reasoning_content: populated (contains the model's internal thinking)
• content: missing or empty
• stop_reason: stop

This happens consistently across multiple prompts and session types — both direct chat and embedded/automated runs. Switching from "thinking" mode to "instruct" mode did not resolve the issue (response came back as completely empty content: []).

Expected behavior

The model should produce a content field with the actual response text, similar to how Qwen3.5-35B-A3B-4bit behaves under the same preset and server configuration.

Steps to reproduce

1. Load mlx-community/Qwen3.6-35B-A3B-4bit with the qwen3.5/6 preset, turboquant, and specprefill (draft: qwen3-0.6B-4bit)
2. Send a chat completion request via the OpenAI-compatible API endpoint
3. Observe the response — reasoning_content is populated but content is empty/missing

Comparison data

Model	Response types	Has visible text
Qwen3.5-35B-A3B-4bit	['thinking', 'text']	✅ Yes
Qwen3.6-35B-A3B-4bit	['thinking'] or []	❌ No

Additional context

• The same oMLX instance serves both 3.5 and 3.6 models — only the model swap triggers the issue.
• Tested with multiple prompts, different sessions, and both thinking/instruct modes — same result every time.
• The 3.6 model appears to be generating correctly internally (the thinking block has content), but the final answer never makes it to the content field.

Is anyone else seeing this with Qwen 3.6 MoE models? Could this be a chat template / tokenizer mismatch for the 3.6 series?

[jundot]

Tried to repro this locally on main against localhost:8000/v1 and could not get an empty-text response from any Qwen3.6 variant I have on hand.

Environment

• oMLX: local main (post 0.3.7rc2)
• Hardware: M3 Ultra 512GB
• Server: omlx serve on localhost:8000, bearer auth

Models tested

Model	Quant
Qwen3.6-35B-A3B	unquantized checkpoint
Qwen3.6-35B-A3B-6bit	6bit mlx
Qwen3.6-35B-A3B-oQ2	oQ2
Qwen3.6-35B-A3B-oQ4	oQ4 (closest to reporter's 4bit)
Qwen3.6-35B-A3B-oQ5	oQ5
Qwen3.6-35B-A3B-oQ6	oQ6
Qwen3.5-35B-A3B-4bit	4bit mlx (control: reporter says this works)

I do not have mlx-community/Qwen3.6-35B-A3B-4bit itself locally, but I pulled its chat_template.jinja and tokenizer_config.json from the hub and diffed against my Qwen3.6-35B-A3B-6bit copy. Both files are byte-identical between the two, so the template path is not the culprit.

How I exercised each model

1. OpenAI /v1/chat/completions smoke — simple "What is 2+2? Answer in one word." at temperature=0, max_tokens=2048. All 7 models returned non-empty content (length 4) and finish_reason=stop.
2. OpenAI /v1/chat/completions code prompt, thinking on — "Write a Python function that reverses a string without using slicing. Include a docstring and one example." with chat_template_kwargs={"enable_thinking": True}, temperature=0, max_tokens=4096. Qwen3.6-35B-A3B, -oQ4, -6bit all returned content 461 / 1159 / 880 chars respectively, plus a populated reasoning_content (7k to 13k chars). Qwen3.5-35B-A3B-4bit control returned 817 / 479.
3. OpenAI /v1/chat/completions code prompt, thinking off — same prompt with enable_thinking=False. All 3.6 variants returned content 368 / 385 / 403 chars, reasoning_content empty. Matches the 3.5 control at 846 chars.
4. Anthropic /v1/messages with reporter's exact preset — temp 0.6, top_p 0.95, top_k 20, enable_thinking=True, same code prompt, max_tokens=4096, on Qwen3.6-35B-A3B-6bit. Response came back as content = ['thinking', 'text'] with text block 595 chars and stop_reason=end_turn. No empty-content reproduction.

What the shape means

The content: ['thinking'] / [] shape matches what convert_internal_to_anthropic_response in api/anthropic_utils.py produces when the model emits a thinking block and then zero post-</think> text. So the question is why the model stops right after </think> on that specific setup, not whether the server is dropping a block that was there.

What would narrow this down

Could you grab the raw scheduler log line for one failing request (the Request ... generated text: line)? That shows the model output before the reasoning parser splits it, so I can tell whether the model actually emitted any content after </think> or not. That would narrow it down a lot.

If anyone else can reproduce this on their end, a comment with the exact steps would be super helpful too.

[jundot]

One more thought while I dig further: your config has two non-default features on at the same time that I cannot exercise locally. Would you be willing to toggle them off one at a time on the 3.6 model and retry the same request?

• turboquant_kv_enabled = false (leave SpecPrefill on)
• specprefill_enabled = false (leave TurboQuant on)

If either one makes the text block come back, we have the culprit and I can focus on that path. If both off still reproduces, then it is something in the 4bit weights themselves and I will chase a different lead.

[lobsterbuko]

I've experienced similar behavior to jsirish although I have not been playing with openclaw in a while. This was prior to the turboquant or specprefill features being introduced. I experienced similar behavior with ollama etc.

I've always just chalked this up to "model failed to produce useful output". I would be very interested if this turned out to just be a bug somewhere. I will try to reproduce.

[AidenGeunGeun]

Weird, I haven't experienced this while using different quantizations and variants of Qwen 3.6 35B-A3B.

[edeltoaster]

I had this behavior in the VS code extension Continue.

[HIGGS317]

The Qwen3.6-27B OQ2 variant models exhibit the same behavior, displaying thinking without generating tokens, whether in thinking mode or as output.

[jundot]

To narrow this down I need one log line from a failing request: Request <uuid> generated text: .... That is the raw model output before the parser splits it into reasoning/content, so I can see whether the model emitted anything after </think> or stopped right there.

To surface that line, bump the log level to trace in the server's global settings (admin dashboard → settings → log level, or log_level: trace in ~/.omlx/settings.json), then reproduce once. The line lands in ~/.omlx/logs/server.log.

Without that, I cannot tell if this is the model hitting EOS early (config/quant issue) or the server dropping real text on the way to the API response (oMLX bug). Both produce the same symptom you see.

@jsirish / @HIGGS317, can either of you grab that line from one failing request? That is enough to unblock me.

[HIGGS317]

2026-04-23 17:02:34,056 - omlx.engine_pool - INFO - [-] - Loaded model: Qwen3.6-27B-mlx-oQ2 (estimated: 9.86GB, total: 9.86GB)
2026-04-23 17:02:34,057 - omlx.engine.batched - INFO - [-] - Structured output is not available in the DMG version (xgrammar requires torch which significantly increases app size). Use the pip or Homebrew version for structured output support.
2026-04-23 17:02:34,057 - omlx.server - DEBUG - [-] - Sampling params: temperature=1.0, top_p=0.95, top_k=0, repetition_penalty=1.0, min_p=0.0, presence_penalty=0.0, frequency_penalty=0.0, max_tokens=32768, xtc_probability=0.0, xtc_threshold=0.1 (model: Qwen3.6-27B-mlx-oQ2)
2026-04-23 17:02:34,063 - omlx.cache.prefix_cache - DEBUG - [-] - Cache miss for af8ba7ec-925d-498a-a1f5-778495874e7e
2026-04-23 17:02:34,063 - omlx.scheduler - DEBUG - [-] - Added request af8ba7ec-925d-498a-a1f5-778495874e7e with 11 prompt tokens
2026-04-23 17:02:35,232 - omlx.scheduler - DEBUG - [-] - Scheduled request af8ba7ec-925d-498a-a1f5-778495874e7e (uid=0) with 1 tokens to process (11 total), with cache
2026-04-23 17:02:35,891 - omlx.scheduler - DEBUG - [-] - Extracted 64 layer states for request af8ba7ec-925d-498a-a1f5-778495874e7e
2026-04-23 17:02:35,891 - omlx.scheduler - DEBUG - [-] - Request af8ba7ec-925d-498a-a1f5-778495874e7e finished: stop, 0 tokens
2026-04-23 17:02:35,893 - omlx.scheduler - TRACE - [-] - Request af8ba7ec-925d-498a-a1f5-778495874e7e generated text:

2026-04-23 17:02:35,893 - omlx.cache.prefix_cache - DEBUG - [-] - Skipping trailing partial block for af8ba7ec-925d-498a-a1f5-778495874e7e: 11 token(s) not persisted (block_size=2048, needs +2037 token(s) to fill next block)
2026-04-23 17:02:35,893 - omlx.cache.prefix_cache - DEBUG - [-] - Stored cache for af8ba7ec-925d-498a-a1f5-778495874e7e: 0 blocks (0 saved to tiered cache), 0 tokens
2026-04-23 17:02:35,893 - omlx.scheduler - DEBUG - [-] - Stored paged cache for request af8ba7ec-925d-498a-a1f5-778495874e7e (11 tokens stored, 11 total: 11 prompt + 0 output)
2026-04-23 17:02:35,893 - omlx.cache.prefix_cache - DEBUG - [-] - Cleared request entry for af8ba7ec-925d-498a-a1f5-778495874e7e (blocks retained)
2026-04-23 17:02:35,901 - omlx.engine.batched - DEBUG - [-] - [stream_generate] Request af8ba7ec-925d-498a-a1f5-778495874e7e finished normally

Here is the log of the model when I just said hello, One interesting thing is that when i said hello another time it just flowed “hot hot” gibberish.

Image is not attaching here☹️

[jundot]

Update: turns out oQ quantization has a real bug on Qwen 3.6 (tracked in #913, model returns gibberish after oQ quant). Both HIGGS317's 27B oQ2 report above and the broader "empty content" symptom on oQ variants fit that pattern. I am treating what you see here as downstream of the oQ quant bug for now.

Could you confirm whether the same issue reproduces on a non-oQ quant of the same model (standard 4bit, 6bit, etc.)? If it does not repro there, that pins it.

Sorry for the back and forth. A patch covering the oQ quant fix is going out in the next release.

[HIGGS317]

If someone can, please do; I am on M2 MacBook Air with only 16GB RAM. Cannot go at anyother quants. This was one of the reasons I have gone for this specific quant in first place.

[jundot]

@HIGGS317 re-quantized versions of the 35B are up on the hub if anyone wants to retest:

• https://huggingface.co/Jundot/Qwen3.6-35B-A3B-oQ2
• https://huggingface.co/Jundot/Qwen3.6-35B-A3B-oQ4
• https://huggingface.co/Jundot/Qwen3.6-35B-A3B-oQ6

27B will take a bit longer. I will drop a note here once it is up.

[jsirish]

Update: Issue resolved on latest oMLX release

After updating to the latest oMLX release (from v0.3.7), the issue is no longer reproducible on our setup.

Test results (post-update)

Model	Method	content	reasoning_content	finish_reason
Qwen3.5-35B-A3B-4bit	Direct API	✅ 4 chars ("Four")	✅ 673 chars	stop
Qwen3.6-35B-A3B-4bit	Direct API	✅ 4 chars ("Four")	✅ 1896 chars	stop
Qwen3.5-35B-A3B-4bit	Code prompt	✅ 817 chars	✅ 479 chars	stop
Qwen3.6-35B-A3B-4bit	Code prompt	✅ 477 chars	✅ 9962 chars	stop
Both models	OpenClaw gateway CLI	✅ Working	✅ Proper split	stop

Environment

• oMLX: Latest release (post v0.3.7)
• Hardware: Apple Silicon
• Models: mlx-community/Qwen3.5-35B-A3B-4bit, mlx-community/Qwen3.6-35B-A3B-4bit
• TurboQuant: enabled on 3.5, not 3.6. SpecPrefill disabled.
• API: OpenAI-compatible /v1/chat/completions

Both reasoning_content and content are now properly separated on both 3.5 and 3.6 models. The content: ['thinking'] / [] symptom from our original report is gone.

Thanks @jundot for the quick investigation and the oQ quant fix in #913. This appears to be fully resolved on our end.

[jeffok]

Hardware: Apple M3 Max 128GB
oMLX version: v0.3.6
Model: mlx-community/Qwen3.6-35B-A3B-4bit
Same issue — content is empty, only reasoning_content is populated.
Also seeing 500 errors in subsequent turns.