Qwen 3.8 27B Swift vs Original: Does It Really Think Less?
A fine-tune claims to fix Qwen 3.8 27B's overthinking. A real coding benchmark shows more tokens, more tool calls, but a faster finish.
Does Swift Qwen 3.8 27B actually think less than the original?
No, not in the way the name implies. A side-by-side test on a real coding task found that Swift Qwen 3.8 27B (ukisai/Swift-Qwen3.8-27b) generated more output tokens (60,572 vs 11,744) and made more tool calls (21 vs 4) than the original Qwen 3.8 27B. It still finished faster, 35 minutes 52 seconds against 47 minutes 7 seconds, but the speed gain came from wasting less time second-guessing itself, not from producing a shorter reasoning trace.
TL;DR
- Swift is a fine-tune, not a new model: it uses the same Qwen 3.8 27B weights, tuned to penalize tokens associated with overthinking and blended with an efficiency transfer from a separate model called Thinking Cap.
- The token count actually went up: in a head-to-head HTML/JS coding test, Swift produced roughly five times more output tokens than the original model, contradicting the “thinks less” framing.
- Swift still finished faster: 35:52 versus 47:07, because the original model burned time deliberating over how to approach the task rather than producing fewer tokens overall.
- Published benchmarks show a real accuracy cost on hard math: Swift’s own benchmark sheet shows AIME 2026 dropping from 98.67% (base) to 94%, and HMMT falling from 99.33% to 96%, a gap that shows up specifically on multi-step reasoning problems.
- Output quality differed on the actual coding task: the original model’s generated simulation ran end to end without stalling, while Swift’s version got stuck partway through the animated sequence.
- The real advantage of Swift looks like reduced wasted effort, not reduced thinking: it skipped the original’s habit of hesitating between strategies, which is a different claim than “shorter internal monologue.”
- ✕a coding agent
- ✕no-code
- ✕vibe coding
- ✕a faster Cursor
The one that tells the coding agents what to build.
What is Swift Qwen 3.8 27B supposed to fix?
Qwen 3.8 27B has a known reputation among people running it locally: it tends to generate long reasoning traces before it produces an answer, even for tasks that don’t obviously need that much deliberation. Swift Qwen 3.8 27B, published on Hugging Face by ukisai, is pitched as a fix for that specific complaint.
It’s not a model trained from scratch. It starts from the same Qwen 3.8 27B base weights and applies a fine-tune (distributed as a LoRA-style adapter according to its model tags) designed to penalize the tokens that tend to trigger long overthinking chains. It also pulls in what its creators call an “efficiency transfer” from another model, Thinking Cap, aimed at compressing the internal reasoning process. The stated goal: same underlying capability, shorter internal monologue, faster time to answer.
How was the comparison actually run?
The test used vLLM to serve both models locally on identical hardware (a system with 80GB of VRAM), connected to an agent framework called Hermes, so both models had access to the same tool-calling setup. Both were given the same hard prompt: generate a complete, self-contained HTML file simulating a latte-making process, including grinding, tamping, pulling the shot with a timer, steaming milk, and pouring. This was chosen specifically because it requires multi-step state logic, not just a single-shot code generation.
Each model’s session was tracked through direct queries to the underlying database logging input and output tokens, rather than relying on on-screen estimates, so the token and tool-call counts are measured rather than approximated. One methodological wrinkle came up along the way: on the first run, the original model appeared to reuse a leftover file from the Swift run instead of generating fresh output. The test was restarted with vLLM cleaned and the working directory reset to avoid any caching or file carryover, and the original model was rerun from scratch for a fair comparison.
Why did Swift use more tokens but still finish faster?
This is the counterintuitive part. If Swift’s fine-tuning goal is to cut down on reasoning tokens, you’d expect a lower token count. Instead, Swift generated over 60,000 output tokens against roughly 11,700 for the original, and it also made more than five times as many tool calls (21 vs 4).
The explanation lies in what the original model spent its time doing. Rather than reasoning efficiently and stopping, the original spent a chunk of its runtime deliberating over strategy, at one point apparently weighing whether to copy and modify an existing file versus writing one from scratch, before settling into the actual work. That kind of indecision doesn’t necessarily show up as more output tokens, but it does show up as wall-clock time. Swift, by contrast, seems to move into tool calls and iteration faster, even if that iteration itself produces a larger volume of tokens.
Everyone else built a construction worker.
We built the contractor.
One file at a time.
UI, API, database, deploy.
So the practical takeaway is that “faster” and “thinks less” are not the same claim, and Swift’s benchmark story really only supports the first one. The efficiency gain observed here looks more like reduced hesitation than a shorter reasoning trace.
Does cutting overthinking cost the model accuracy?
On published benchmarks, yes, and the gap is concentrated exactly where you’d expect it: sustained, multi-step mathematical reasoning. Swift’s benchmark sheet shows it staying within about a point of the base model on general reasoning, GPQA, and MMLU, and its makers claim a 40 to 50 percent cut in mean tokens on those categories.
But on AIME 2026, a competition math benchmark, Qwen 3.8 27B scores 98.67% and Swift scores 94%, a 4.6 point drop. On HMMT, the base model scores 99.33% against Swift’s 96%. Both are areas that require the model to carry a long, uninterrupted chain of reasoning to reach a correct answer, which is precisely the kind of task a token-efficiency fine-tune would be expected to struggle with if it’s trimming reasoning steps rather than trimming redundant deliberation.
The hands-on coding test lines up with that pattern. The original model’s generated HTML simulation ran through its full sequence, including a reset function, without stalling. Swift’s version visually looked comparable through the early steps (grinding, tamping, pulling the shot) but got stuck partway through the milk-steaming animation and didn’t respond to reset commands. That’s a small, single-task result rather than a benchmark, but it’s consistent with the idea that something is being traded away.
Is Swift Qwen 3.8 27B worth using over the original?
For tasks that need reliable, sustained multi-step logic, the original Qwen 3.8 27B held up better in this test, both in benchmark scores on math-heavy tasks and in actually completing the coding task without getting stuck. Swift’s real advantage looks like fewer wasted tool calls and less strategic hesitation, which does translate into a faster finish time in practice. But it’s not accurate to market that as “thinking less,” since the measured token count went up, not down.
For lighter-weight coding or general tasks, especially where the original model’s tendency to overthink is genuinely a bottleneck, Swift may still be a reasonable tradeoff. But for anything resembling competition math or long-form step-by-step reasoning, the accuracy gap on Swift’s own published benchmarks suggests sticking with the base model. Other efficiency-focused variants are still being developed elsewhere, including one from a group at GSQRCO in Austria, but based on this test, the original Qwen 3.8 27B remains the safer default for demanding reasoning work.
Frequently Asked Questions
What is Swift Qwen 3.8 27B?
It’s a fine-tuned version of Qwen 3.8 27B, published by ukisai on Hugging Face, that penalizes tokens associated with overthinking and incorporates an efficiency transfer from a separate model called Thinking Cap. It uses the same base weights as the original Qwen 3.8 27B rather than being trained from scratch.
Does Swift Qwen 3.8 27B use fewer tokens than the original?
Not necessarily. In a hands-on coding test generating a multi-step HTML simulation, Swift produced about 60,572 output tokens compared to 11,744 for the original model, along with more tool calls. It finished faster overall, but not because it generated less text.
Why was Swift faster if it used more tokens?
The original model spent time deliberating over its approach, at one point weighing whether to copy and edit an existing file rather than start fresh, which added to its wall-clock time without necessarily adding output tokens. Swift moved into execution and iteration more directly.
Does Swift Qwen 3.8 27B lose accuracy compared to the original?
On published benchmarks, yes, particularly on competition math. AIME 2026 scores drop from 98.67% (base) to 94% (Swift), and HMMT drops from 99.33% to 96%. General reasoning benchmarks like GPQA and MMLU stay much closer between the two versions.
Should I use the original Qwen 3.8 27B or the Swift fine-tune?
For tasks requiring sustained multi-step reasoning, such as complex coding logic or competition-level math, the original model performed more reliably in both benchmarks and a hands-on test. Swift may suit lighter tasks where reduced hesitation and faster completion matter more than squeezing out maximum reasoning accuracy.