Introduction

This article is mainly about the broken thinking mode: how it fails, what the logs show and what we know about the cause. It also shows the instruct mode results and recommends alternatives while thinking mode is broken.

We tested the model with our benchmark suite. In the coding tests, the model writes code in SC#, a custom language. Its specification is part of the prompt.

• Model: nvidia/Qwen3.8-Flash-Next-NVFP4. This is NVIDIA's own NVFP4 quantization, made with NVIDIA Model Optimizer.
• Runtime: vLLM 0.30.0, on 26 September 2026.
• Instruct mode: all six benchmarks.
• Think: medium: two benchmarks, SC# agentic and HumanEval for SC#. We stopped there, because more runs of a broken mode would not show anything new.

Every test runs once, and its first answer counts: there are no reruns of failed tests. A model might solve a failed task on a second try, but our aim is to show what a user can expect from a single request, not the best possible result.

We compare only NVFP4 runs. NVFP4 needs less VRAM than FP8, so it matters more for local users.

Instruct mode

Qwen 3.8 Flash Next Instruct is the best instruct model in four of six benchmarks. In BBH, it scores about the same as the others, and in tool calling (BFCL) slightly lower than Qwen 3.6 27B Instruct.

In SC# agentic, it is better than every other instruct run in our benchmark, FP8 runs included, and comes close to the thinking runs of the 27B models. It also needs far fewer output tokens than the 27B instruct models for the same tests.

LiveCodeBench and IFBench need more reasoning. Here all instruct models, Qwen 3.8 Flash Next Instruct included, stay far below the thinking models.

Thinking mode

With thinking enabled, the scores drop sharply. The chart below compares both modes of the same model on the same tests.

The failures do not depend on difficulty. In SC# agentic, the thinking run passed very hard tests a little more often than easy ones. Errors that hit tasks at random suggest a technical fault, not a lack of skill.

Failure patterns

Every failed HumanEval test in the thinking run follows one of two patterns: the answer stops after the first token, or the thinking block never closes. We read the log of every failed test. The instruct run is shown for comparison. Its few failures are ordinary wrong answers: code that does not compile, returns a wrong result or crashes.

1. The answer stops after the first token. The model closes its thinking block normally, after hundreds or thousands of tokens. Then the answer starts and stops at once. The whole answer is L, List, s or i, which is the first token of List<...> or int. The answer ends far below the output limit, so it is not cut off by length.

An easy test shows the first pattern. AbsoluteScoreDifferences (from HumanEval/152) asks the model for a short function and runs it on a few inputs:

void AbsoluteScoreDifferences()
{
    var prompt = BuildImplementationPrompt("List<int> Compare(List<int> game, List<int> guess)", "The two input lists have equal length. Return a new list of the same length where each element is the absolute difference between game[i] and guess[i]. Do not modify the inputs.");
    var response = AskAi(prompt, ImplementationSystemPrompt(), true);
    EnsureAiCompleted(response);
    var source = ExtractCandidateSource(response.Text);

    ExpectCompareCase(source, [1, 2, 3, 4, 5, 1], [1, 2, 3, 4, 2, -2], "baseline-one");
    ExpectCompareCase(source, [1, 2, 3], [-1, -2, -3], "baseline-negative");
    // … three more cases
}

In instruct mode, the model answers at once with correct code, and the test passes:

List<int> Compare(List<int> game, List<int> guess)
{
    var result = new List<int>();
    for (var i = 0; i < game.Count; i++)
    {
        result.Add(Math.Abs(game[i] - guess[i]));
    }
    return result;
}

In thinking mode, the model reasons first and closes the thinking block. Then this is the whole answer:

List

The compiler reports Expected '<' after 'List', found end of file, and the test fails. The model knows the answer, but in thinking mode it stops after the first token.

2. The thinking block never closes. Weaker models sometimes forget to close the thinking block and write the answer directly. For this case our backend has a fallback: if the block never closes, the whole output becomes the answer. Here, the answer therefore starts with the model's reasoning ("The user wants me to implement…") and then the code. The code is often correct, but the reasoning before it breaks compilation.

The logs do not show whether the reasoning finished and only the closing was lost, or whether the model failed during the reasoning.

SC# agentic shows the same picture. Most failed tests failed because the code did not compile, and about half of these had an empty or almost empty answer. The instruct run of the same model almost never produced code that did not compile.

This can also fail tests that check a format, such as a table, an answer marker or JSON. If the thinking block does not close, the output may contain only reasoning, because the model has not started the real answer yet. The SC# agentic run has such format failures, for example missing table rows or a missing answer marker. We have not checked each of them.

Possible causes

The cause is not known yet: it can be the NVFP4 quantization, the model itself in thinking mode, or the runtime. These facts narrow it down:

• Only thinking mode is affected. Instruct mode of the same checkpoint, on the same vLLM version, is our best instruct result. Other thinking models in our benchmark score much higher on the same tests.
• Both patterns happen where the reasoning ends and the answer starts. This points to the end of the thinking block: how the model ends it, or how the chat template and the reasoning parser of the runtime handle it. It is not a lack of knowledge.
• We tested only NVIDIA's NVFP4 quantization. We did not run the BF16 or FP8 versions of the model. A 4-bit quantization can weaken single important tokens, such as the token that closes the thinking block. So the quantization may be the cause.
• SGLang has a thinking-mode bug too, but with a different symptom. In SGLang issue #36537, the model repeats one token in a loop when thinking mode, tools and the qwen3_coder tool parser are used together. Without thinking mode, the same request works. The report covers the original model and another NVFP4 quantization. We did not find a report of the same cut answers.

We did not test llama.cpp or GGUF quantizations of this model. A community GGUF changes the weight of the token that closes the thinking block, against empty answers when the reasoning uses the whole output budget (tested on llama.cpp). This is another sign that the end of the reasoning is a weak point of this model.

So the cause can be the NVFP4 quantization, the model itself in thinking mode, or how vLLM handles the end of the reasoning. We will test thinking mode again with an FP8 version, a new vLLM release or an updated checkpoint.

Potential

Qwen 3.8 Flash Next Instruct finishes a task much faster than the 27B instruct models, but its broken thinking mode limits its use. Only instruct mode works, so we compare it with the other instruct models. Our benchmark analysis estimates the time per task on the same normalized hardware for every model, so the models can be compared without a specific GPU.

Qwen 3.8 Flash Next is an MoE model: only a small part of its parameters works on each token. So its instruct mode finishes a task much faster than the 27B instruct models, and it is also the best instruct model in our tests.

This shows the potential of the model. With a working thinking mode, it could become a fast alternative to the 27B thinking models, but we cannot measure this yet.

Recommendation

In thinking mode, the 27B models are much better in LiveCodeBench and IFBench, where the tasks need reasoning, and a little better in most other benchmarks.

Instruct mode of Qwen 3.8 Flash Next works well, but it is not a reason to choose this much larger model.

References

This article is based on our analysis of the Ai4Users benchmark results and of the execution logs of the runs below.

Qwen 3.8 Flash Next, NVFP4, vLLM 0.30.0:

• SC# Coding & Agentic Benchmark, Qwen 3.8 Flash Next, Think: medium: 152 passed, 176 failed, 3 broken (45.9%)
• SC# Coding & Agentic Benchmark, Qwen 3.8 Flash Next, Instruct: 323 passed, 8 failed (97.6%)
• HumanEval for SC#, Qwen 3.8 Flash Next, Think: medium: 35 passed, 126 failed, 1 broken (21.6%)
• HumanEval for SC#, Qwen 3.8 Flash Next, Instruct: 155 passed, 7 failed (95.7%)
• LiveCodeBench for SC#, Qwen 3.8 Flash Next, Instruct: 53.8%
• IFBench-based benchmark, Qwen 3.8 Flash Next, Instruct: 45.4%
• BFCL-based tool calling, Qwen 3.8 Flash Next, Instruct: 92.6%
• BBH-based reasoning, Qwen 3.8 Flash Next, Instruct: 96.0%

The results of the other models (the instruct runs in the first chart and the 27B thinking runs) are on the benchmark page. A test counts as broken when the model gave no answer: the generation was stopped after 62,144 output tokens, or a generation loop was detected.

Other sources:

• nvidia/Qwen3.8-Flash-Next-NVFP4, the NVFP4 checkpoint (NVIDIA Model Optimizer)
• LLM benchmark analysis: estimated time per task
• SGLang issue #36537: token loop with thinking mode, tools and the qwen3_coder tool parser
• Qwen3.8 Flash Next reasoning termination fix (GGUF): community GGUF for llama.cpp