Introduction

Qwen 3.6 35B is a mixture-of-experts (MoE) model: only about 3B of its parameters work on each token. This makes it several times faster than a dense model of a similar size, and its quality is still good. A fast model that can solve many tasks is worth attention for local use, and it is a good model to experiment with. We looked at where it works well and where it fails.

This article focuses on coding, agentic tasks and instruction following, and compares the instruct and thinking modes. The results come from our benchmark suite. We also looked at the answers of the failed tests, not only at the scores.

• Model: Qwen 3.6 35B.
• Modes: instruct mode and thinking mode.
• Quantization: this article focuses on NVFP4, because it needs less VRAM and matters more for local users. Every run was repeated with FP8; the section "NVFP4 vs FP8" near the end compares the two.
• Runtime: vLLM, mostly version 0.27.1, runs from 20 to 22 September 2026.

Every test runs once, and its first answer counts: there are no reruns of failed tests. The aim is to show what a user can expect from a single request, not the best possible result.

The coding tests use SC#, a sandboxed language with a C#-like syntax. The full SC# documentation is part of the prompt, and the test compiles and runs the code that the model writes. So the model has to follow a language description from its context, not only its memory of C#.

This adds an extra challenge. With the SC# documentation, every coding prompt has about 8,700 tokens, while the task itself often has only a few dozen. The model must find the rules that matter for its task in this long context and follow them. In thinking mode, Qwen 3.6 35B does this well: its code does not compile in only about 3% of the HumanEval tests. Instruct mode fails here much more often, as the section "Code that does not compile" shows.

Coding and agentic tasks

In thinking mode, Qwen 3.6 35B solves most of our coding tasks: about 92% in SC# agentic and 93% in HumanEval. In LiveCodeBench, it solves 64%. Instruct mode scores lower in all three benchmarks, and the gap is largest in HumanEval and LiveCodeBench.

Difficulty levels

On easy and medium tasks, thinking mode solves almost everything in SC# agentic and HumanEval. On hard tasks, the score drops: in LiveCodeBench, the model solves only about a third of the hard problems. In 7% of the LiveCodeBench tests, thinking mode gave no answer at all: it reasoned until the output limit or repeated itself. In SC# agentic, it solves 36 of the 42 very hard tasks.

Example: a hard problem solved well

In thinking mode, the model also solves some hard problems with an efficient solution. One example is a hard LiveCodeBench task from LeetCode (problem 2784, "Power of Heroes"):

You are given a 0-indexed integer array nums representing the strength of some heroes. For a group with indices i0, i1, ..., ik, its power is max(nums[i0..ik])^2 * min(nums[i0..ik]). Return the sum of the power of all non-empty groups of heroes, modulo 10^9 + 7.

Thinking mode answered with this code:

int sumOfPower(List<int> nums)
{
    const long MOD = 1000000007L;
    nums.Sort();
    long ans = 0;
    long S = 0;
    for (var i = 0; i < nums.Count; i++)
    {
        long val = ((long)nums[i] % MOD + MOD) % MOD;
        long sq = (val * val) % MOD;
        long combined = (val + S) % MOD;
        long contrib = (sq * combined) % MOD;
        ans = (ans + contrib) % MOD;
        S = ((2 * S) % MOD + val) % MOD;
    }
    return (int)ans;
}

The model does not try all groups, which would take exponential time. After sorting, each value is the maximum of its groups, and S sums the possible minimums of these groups. This is the known optimal solution: O(n log n) for the sort and one pass over the list.

Not every correct solution is optimal. In another hard task (LeetCode 2827, "Greatest Common Divisor Traversal"), the model splits every number into prime factors by trial division. This is fast enough for the limits of the task, but slower than the usual solution with a prime sieve.

So correct does not mean optimal. A passing test shows that the code gives the right results for the test inputs, not that it is designed well for production. A slower solution is often good enough, but with larger inputs or code that runs very often, it can become a source of problems.

Code that does not compile

Most failed coding tests contain code that does not compile. In instruct mode, this happens much more often: the model ignores the SC# documentation in its context and writes C# instead. In LiveCodeBench, the code of instruct mode does not compile in 44% of the tests. In thinking mode, the share is less than half of that.

Once the code compiles, it is usually correct. Wrong results and runtime errors cause only a small part of the failures in both modes.

Example: a C# habit

The task: Return all non-empty prefixes of text from shortest to longest. Empty text returns an empty list. The function signature is List<string> AllPrefixes(string text).

Instruct mode wrote this code:

List<string> AllPrefixes(string text)
{
    var result = new List<string>();
    if (text == null || text.Length == 0) { return result; }
    
    var sb = new StringBuilder();
    for (var i = 0; i < text.Length; i++)
    {
        sb.Append(text[i]);
        result.Add(sb.ToString());
    }
    
    return result;
}

In SC#, only nullable types such as string? can be null, and the documentation says so. The parameter here is a plain string, so the compiler stops at the null check:

Typical errors

The compiler messages show which parts of the context instruct mode ignores. The most common errors are:

• C# arrays and tuples. The model declares int[] or a tuple, but SC# has only List, Dictionary and HashSet.
• Null checks on plain string and List values, which can be null in C# but not in SC#. Only nullable types such as string? can be compared with null.
• C# syntax for structs. The model creates a struct with a constructor call such as new Point(1, 2), but SC# creates structs as new Point { X = 1, Y = 2 }.
• Methods that SC# does not have, for example StringBuilder.Reverse() or Convert.ToString(value, 2).
• Text instead of code. The system prompt says: "Return only SC# source code. Do not include Markdown or explanations." In 27 answers in HumanEval and LiveCodeBench, instruct mode started with an explanation such as "Let me analyze the requirements and implement the solution…" and wrote down its doubts, such as "Wait, let me reconsider the edge cases". The compiler then fails on the first line. In thinking mode, this never happened.

Thinking mode makes the same kinds of errors, but much less often.

Code that compiles but gives a wrong result

Some failures have the right idea and a small mistake. The task: implement trapping rain water with the signature int Trapped(string heights). Each position holds min(maxLeft, maxRight) - height when positive, summed over all positions. Thinking mode wrote this code:

int Trapped(string heights)
{
    var tokens = heights.Split(' ');
    var bars = new List<int>();
    foreach (var t in tokens)
    {
        var trim = t.Trim();
        if (trim.Length > 0)
        {
            bars.Add(int.Parse(trim));
        }
    }

    int n = bars.Count;
    if (n <= 2) { return 0; }

    var maxL = new List<int>();
    var maxR = new List<int>();
    
    var curMax = 0;
    for (int i = 0; i < n; i++)
    {
        if (bars[i] > curMax) { curMax = bars[i]; }
        maxL.Add(curMax);
    }
    
    curMax = 0;
    for (int i = n - 1; i >= 0; i--)
    {
        if (bars[i] > curMax) { curMax = bars[i]; }
        maxR.Add(curMax);
    }

    int total = 0;
    for (int i = 0; i < n; i++)
    {
        int m = maxL[i] < maxR[i] ? maxL[i] : maxR[i];
        int h = bars[i];
        if (m > h) { total += m - h; }
    }

    return total;
}

Tool calls

In BFCL, instruct mode often does not stop calling tools. Most of these tests expect exactly one tool call. Instruct mode often makes the right call first and then goes on calling the same or other tools. In thinking mode, the model usually stops after the right call.

As a result, instruct mode passes only 29% of the BFCL tests, and thinking mode 92%. In 46% of the tests, instruct mode made five or more tool calls; thinking mode did this in fewer than 1% of the tests.

In our SC# agentic tests, which use tools in longer tasks, the two modes made a similar number of tool calls. There, the main difference is still the code that does not compile.

Instruction following

In IFBench, thinking mode follows these rules much more often: it passes 58% of the tests, and instruct mode 36%.

The largest gap is in tasks with counts, such as an exact number of numbers, keywords or pronouns. Here, thinking mode passes about twice as many tests as instruct mode.

An example with a count:

Include exactly 3 numbers in the response. Make this short: An alignment of resources and education goals within each community is needed to support the education ecosystem of students, teachers, and parents and assist in the adjustment to the new normal—homeschooling, parents-teachers training, community internet centers, a Citizen Watch for Education, and establishing LGU leaders as education champions.

Thinking mode has its own problem: in rules for single words, for example about the letters or the length of every word, it often does not finish. It checks the rule again and again until the output limit. In this group, 30 of 69 answers of thinking mode were broken. In IFBench, thinking mode writes about 20 times as many output tokens per test as instruct mode.

Speed

Thinking mode is only a little slower than instruct mode. On the normalized hardware of our benchmark analysis, Qwen 3.6 35B needs about 17 seconds per task in instruct mode and about 22 seconds in thinking mode. A dense model such as Qwen 3.6 27B needs about 39 seconds in instruct mode and about 93 seconds in thinking mode. So the thinking mode of Qwen 3.6 35B is faster than the instruct mode of the dense model.

Thinking mode does not think briefly: it writes about as many output tokens as the thinking mode of Qwen 3.6 27B. The small difference in time has another reason. Instruct mode also writes long answers, because it often reasons in the answer itself. In LiveCodeBench, it writes about eight times as many output tokens per task as Qwen 3.6 27B in instruct mode.

Other benchmarks

In BBH, both modes score about 95%, so the mode makes no difference. The tool calling results (BFCL) are described in the section "Tool calls".

NVFP4 vs FP8

NVFP4 and FP8 give similar results. In the benchmarks of this article, the scores differ by up to about four percentage points, in both directions. The largest difference is in SC# agentic in thinking mode, where FP8 scores higher. In this NVFP4 run, the model server did not respond in six tests, which count as failures. At that time, the NVFP4 support in vLLM was newer and less stable than the FP8 support, and later vLLM versions improved it. Without these six tests, the difference would be about two percentage points. In LiveCodeBench and IFBench, NVFP4 scores slightly higher in thinking mode. This looks like normal variation between runs, not a loss caused by NVFP4.

The VRAM saved with NVFP4 can hold a larger KV cache, for longer contexts or more parallel sessions.

Recommendation

For professional use, the model is not reliable enough on its own. In thinking mode, it solves only about a third of the hard LiveCodeBench problems, and some of its code still does not compile. It also sometimes does not finish answers with rules for single words. Check the generated code, for example with a compiler, tests and a review, before you use it. The review should also cover the efficiency of the code, because code that passes the tests is not always efficient.

Our coding tests use SC#, a language that the model knows only from its prompt. With a common language such as Python or C#, the results may be different. Other workloads and other runtimes may also give different results.

Bonus: a real example of an agentic repair loop

This last section shows one run of our agentic tests in detail: how the model works with feedback from a compiler and a time limit.

A simple agentic loop

The idea behind agentic coding fits in a few lines of SC#. The script asks the model for code, compiles it, and if it does not compile, sends the compiler errors back and asks again, at most 10 times:

struct DigitArgs { int N; }

string ImplementWithRetries()
{
    var system = "Return only SC# source code. Do not include Markdown or explanations.";
    var prompt = "Implement int SumOfDigits(int n) for n >= 0.";
    for (var attempt = 1; attempt <= 10; attempt++)
    {
        var code = AskAi(prompt, system, true).Text;
        var run = RunScript<DigitArgs, int>(code, "SumOfDigits", new DigitArgs { N = 0 });
        if (run.Compiled)
            return code;

        prompt = $"The code does not compile:\n{run.Error}\nReturn the fixed code.";
    }
    throw "No code that compiles after 10 attempts.";
}

AskAi keeps the conversation within one test, so the model sees its earlier code when it gets the errors. In our agentic tests, the model drives this loop itself: it gets a tool that compiles and runs its code and returns the output or the errors, and it decides when to try again.

Example: six runs to a correct answer

This task from our agentic tests asks for a number, not for code. The tool is optional: the model may count the subsets in its reasoning, or write code and run it. Both modes chose the tool.

System prompt

The SC# documentation is also part of the prompt, but it is not shown here.

Solve the user's problem accurately.
You have access to RunScSharpScratchpad, an executable SC# computational scratchpad.
You MAY use it when exact computation, symbolic manipulation, enumeration, parsing, simulation or verification would materially improve reliability or efficiency.
You are NOT required to use it.
Choose the strategy yourself.
If you use the scratchpad, write a zero-parameter SC# function returning string, and pass its full source plus the function name to RunScSharpScratchpad.
Convert computed numeric or structured results to the final textual form inside SC#.
Do not use the scratchpad merely because it is available, and do not repeatedly run equivalent computations without a concrete reason.
If scratchpad compilation or execution fails, you may fix the program and retry.
On the FINAL line output exactly `ANSWER: X`, where X is the requested answer only.
Do not put anything after the ANSWER line.

User prompt

Consider the following 18 values, where each position is a distinct item:

[8, 13, 5, 21, 3, 34, 2, 11, 17, 6, 9, 14, 4, 19, 7, 12, 10, 15]

How many distinct subsets of POSITIONS have values whose sum is exactly 60?

Each index may be selected at most once.
Two subsets using different indices are distinct even if some values happen to be equal.
Return the exact count.

Result

Instruct mode needed six runs before it had the answer. In each run, the model wrote code with one idea for the solution, and the tool compiled and ran it:

• Run 1: code that checks all 2^18 subsets. Result: the code compiled, but stopped at the time limit of 30 seconds.
• Run 2: a recursive search with global variables. Result: a compile error, because global variables need an initial value.
• Run 3: the recursive search as a function inside another function. Result: a compile error, because SC# has no local functions.
• Run 4: code that checks all subsets again, written in a different way. Result: the time limit again.
• Run 5: dynamic programming over the possible sums. Result: a compile error, a type mismatch and a method that SC# does not have.
• Run 6: the same dynamic programming, with the errors fixed. Result: the correct answer, 1216.

Run 1: a correct idea with a poor complexity

The first run checked every subset with a bit mask. The idea is correct, but its complexity is O(2^n · n): 2^18 subsets with 18 steps each are too many for the time limit of the SC# interpreter.

int CountSubsetSums(List<int> nums, int target)
{
    int n = nums.Count;
    int count = 0;
    int limit = 1 << n;
    for (int mask = 0; mask < limit; mask++)
    {
        int s = 0;
        for (int i = 0; i < n; i++)
        {
            if ((mask & (1 << i)) != 0)
            {
                s += nums[i];
            }
        }
        if (s == target)
        {
            count++;
        }
    }
    return count;
}

string Solve()
{
    List<int> nums = [8, 13, 5, 21, 3, 34, 2, 11, 17, 6, 9, 14, 4, 19, 7, 12, 10, 15];
    int result = CountSubsetSums(nums, 60);
    return result.ToString();
}

Run 6: the final version with a much better complexity

The model read the feedback and changed its approach: after two timeouts, it moved to dynamic programming over the sums up to 60. The sixth run gave the correct answer in 143 milliseconds:

string Solve()
{
    List<int> nums = [8, 13, 5, 21, 3, 34, 2, 11, 17, 6, 9, 14, 4, 19, 7, 12, 10, 15];
    int target = 60;
    
    // dp_sums[k] = sum value, dp_counts[k] = number of ways to achieve that sum
    List<int> dp_sums = [0];
    List<long> dp_counts = [1];
    
    foreach (var num in nums)
    {
        int size = dp_sums.Count;
        for (int i = size - 1; i >= 0; i--)
        {
            int old_sum = dp_sums[i];
            long cnt = dp_counts[i];
            int new_sum = old_sum + num;
            if (new_sum <= target)
            {
                // Linear search for new_sum in dp_sums (small enough)
                int pos = -1;
                for (int j = 0; j < dp_sums.Count; j++)
                {
                    if (dp_sums[j] == new_sum)
                    {
                        pos = j;
                        break;
                    }
                    else if (dp_sums[j] > new_sum)
                    {
                        break;
                    }
                }
                if (pos >= 0)
                {
                    dp_counts[pos] += cnt;
                }
                else
                {
                    // Insert in sorted position
                    int insPos = 0;
                    for (int j = 0; j < dp_sums.Count; j++)
                    {
                        if (dp_sums[j] > new_sum)
                        {
                            insPos = j;
                            break;
                        }
                        insPos = j + 1;
                    }
                    dp_sums.Insert(insPos, new_sum);
                    dp_counts.Insert(insPos, cnt);
                }
            }
        }
    }
    
    // Find target in dp_sums
    for (int i = 0; i < dp_sums.Count; i++)
    {
        if (dp_sums[i] == target)
        {
            return dp_counts[i].ToString();
        }
    }
    return "0";
}

The final code works, but it is more complicated than needed. It keeps the sums in a sorted list and searches it for every new sum, so its complexity is O(n · S²), where S is the target sum of 60. A plain list of 61 counters, one for each sum from 0 to 60, would do the same in a few lines with O(n · S).

A repair loop is not enough on its own. In a task with brackets, thinking mode fixed its code after two compile errors and got the right result, but then gave the answer without the required ANSWER: line, so the test failed.

References

This article is based on our benchmark analysis and on the runs below.