| |

Qwen 3.5 35B-A3B was blisteringly fast, but too loose to keep

Engine/model: oMLX, Qwen3.5-35B-A3B-4bit

This was the first model in the campaign that made the stopwatch look broken. Six bounded workflow cases and four repository reviews finished in 84.5 seconds altogether. The median short-case latency was 0.68 seconds; the four much larger review packets had a 19.5-second median. For a 35B-class mixture-of-experts model on local hardware, that is terrific throughput.

Unfortunately, speed was the cleanest part of the result.

Methodology correction: This article originally reported 3/6 under scorer v1. Cloud controls exposed two benchmark defects: a hidden literal-keyword requirement and case-sensitive action enums. Under versioned scorer v2, this model scores 5/6. This supersedes the earlier workflow total; original receipts remain preserved, and the code-review adjudication and verdict are unchanged.

Corrected two-panel chart for Qwen3.5-35B-A3B-4bit: workflow score 5 of 6 under scorer v2, with independently adjudicated code-review counts.
Scorer v2 changes this workflow result from 3/6 to 5/6 by removing a hidden literal-keyword penalty and normalizing action capitalization. Code-review adjudication is unchanged.

Half the domain cases passed

The model passed three of six domain cases. It handled two of three structured portfolio actions and one of two casual community replies. It missed the hotel evidence case because one quotation was not literal and too few claims survived validation. Its failed community reply lost the required team stance. The remaining portfolio miss was painfully small: it returned HOLD where the schema required lowercase hold.

That last error is a good summary of the model. It usually understood the task, then stepped over a hard boundary near the finish line.

Code review needed almost as much review as the code

The repository-review validator accepted one of four runs. The model produced 22 recommendations, but independent checks against the pinned source snapshots changed the picture substantially: two were useful, ten needed material qualification, and ten were false or materially wrong.

The misses were not subtle. It mistook packet boundaries for truncated source even though the files were complete. It reported a missing database table that the initial migration creates. It called static export incompatible with ordinary client navigation. Several security findings jumped from an internal implementation detail to a high-severity remote threat without showing an attacker-controlled path.

There were still a couple of worthwhile leads. One review noticed that a failed external search could stop later search terms, and another correctly spotted a repository without an automated test suite. Those are useful observations. Two useful findings out of 22 is not enough for an unsupervised review role.

The token bill was mostly repository context

Across all ten calls, the model processed 97,385 tokens: 90,810 prompt tokens and 6,575 completion tokens. Nearly all of the input came from the four repository packets. The model did not ramble; it read a lot and answered quickly. The trouble was judgment, not output volume.

Provisional verdict: deletion candidate

I would not delete anything automatically, and this campaign never does. The provisional label is deletion_candidate, which means the evidence does not justify protecting this exact model from a later, explicitly authorized cleanup.

The model is wonderfully quick, and I can imagine a narrow extraction job where its speed matters more than semantic precision. In this campaign, though, it passed only half of the bounded cases and produced too many confident review errors. A fast wrong answer is still wrong, just with more time left to discover it.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *