Qwen3.8 API empty answer: finish_reason stop with blank content

Independent setup guidance. Guides and local tools are free; provider inference has its own terms. The site-provided pool is separate.

HTTP 200, finish_reason: "stop", and an empty choices[0].message.content means the response contains no assistant text. It is not a JSON parsing error to repair. First check the raw body: an application can also hide text that the API actually returned.

Inspect a handwritten empty-answer example

The example stays in your browser. It sends no request to Qwen, another model or an API provider.

What the empty response looks like

Handwritten Chat Completions response
{
  "id": "handwritten-empty-answer",
  "object": "chat.completion",
  "choices": [
    {
      "index": 0,
      "message": {
        "role": "assistant",
        "content": ""
      },
      "finish_reason": "stop"
    }
  ]
}

This is a synthetic shape, not a captured model response. In the response checker it should read No assistant text to check. The checker cannot identify why a provider returned that shape; it only confirms that the content string is empty.

Separate it from tool calls, truncation and a broken display

Raw responseNext check
stop, empty content, no tool_calls or refusalNo assistant text was returned. Compare the exact provider, model and serving route with the response body.
tool_calls finish reason and a tool payloadThis can be a normal tool request. Continue the tool round in the client; check tool-call history and empty content.
lengthThe output reached a limit or ended without enough text. Follow the output-limit diagnosis.
Streaming capture has no terminal finish reason or [DONE]That is a stream-ending question. Compare the complete capture in the stream-stall guide.
The raw response has text, but your app shows noneCompare the raw JSON with the client’s response mapping and renderer. That points to a display or adapter path, not this empty-body shape.

What the Qwen3.8 reports establish

QwenLM issue #216 describes a Qwen3.8-27B response that ended with HTTP 200, finish_reason: "stop", and empty content while running through specific inference stacks. The reporter revised the measurements and explanation several times as tests across runtimes and settings produced different results. Treat this as one evolving report, not an official failure rate for Qwen3.8 or every provider. GitHub marked the issue inactive and closed it as not planned; that status does not mean a fix shipped.

A separate vLLM issue #55420 describes EOS being emitted while Qwen3.8 is still inside its reasoning block. The proposed reasoning_eos_policy="force_end" change was in PR #55562, which closed without merging on 13 September 2026. Do not assume that option is supported by a stock vLLM build.

There is a relevant SGLang source change: commit 1c59953 suppresses model EOS while a reasoning phase is still open. Its linked report used Qwen3.6-27B, not Qwen3.8. If you use SGLang, check whether your exact deployed build contains that commit; a provider’s packaged runtime may differ.

Check your own serving path

  1. Save the complete HTTP status and response JSON. Record the returned model name, provider product, endpoint family and UTC time. Redact API keys, private prompts and user data before sharing a report.
  2. Confirm the response has no refusal and no tool request. If your client displays an empty answer but the captured JSON has text, inspect the client adapter instead.
  3. For a self-hosted route, record the serving engine and exact version, model build or quantization, reasoning parser, speculative-decoding configuration and settings actually sent on the wire. A client may ignore an effort field; do not infer that a setting took effect from its UI alone.
  4. Compare repeated runs on the same route, then change one supported setting at a time. Keep the original response and usage data so a successful run does not hide an intermittent failure. Avoid copying penalty values or unmerged engine parameters from an issue as a universal fix.
  5. In your application, treat empty content with no tool call or refusal as “no answer.” Do not send it to a JSON parser as if it were a result or mark the task successful just because the finish reason is stop. Avoid automatic retry loops; inspect usage and route details first.

Sources checked 2 November 2026. This guide summarizes public issue reports and source changes; it is not a live model test or a prevalence estimate.

Free API access and limits

Check the site free API access and limits before trying to obtain a site key. Read the current status and request limits before using a site key. It is not a source of official provider keys.

ChinaGenAI is not affiliated with the providers named here. This release contains setup guidance and explicitly labeled fictional examples, not claimed live model benchmarks.

Exact symptom wording and source

Use the quoted text to locate the relevant check. Providers and clients can phrase the same failure differently; compare the complete response before applying a fix.

  • Reported text: Qwen3.8 Chat Completions returns HTTP 200 with finish_reason stop and empty assistant content

    Issue #216 is one reporter's evolving test; its headline rate changed across revisions. It was marked inactive and closed as not planned on 12 October, not marked fixed. A separate vLLM feature request remains open and its proposed force_end PR closed unmerged. SGLang commit 1c59953 addresses a similar Qwen3.6 report; verify the exact runtime build before relying on it.

    Jump to: Check the raw response and exact serving stack

    HTTP 200, `finish_reason: "stop"`, and an empty `content` field

    QwenLM/Qwen3.8 issue #216, opened 19 August 2026; checked 2 November 2026