senn-techQwen3.8-27B with Claude Opus reasoning traces: four fine-tunes tested, one holds up
Is there a "Claude thinking mode" variant of our production model Qwen3.8-27B-FP8, trained on real Opus reasoning traces rather than just finished answers? A look at Hugging Face says yes — an active community ecosystem exists for exactly this. We checked four candidates and ran the most promising one against our own test battery.
Four candidates, a first cut
Two of the four projects fell out during a read of their model cards alone: one describes itself as an unfinished pipeline validation run, only 12.6 percent of a training epoch; another backs its reasoning claim only with saturated commonsense benchmarks and no training transparency. A third project doesn't target better reasoning at all but censorship removal — its own model card admits coding ability drops from 7.9 to 4.3 percent HumanEval score as a result.
The fourth candidate, barozp/Qwen3.8-27B-Opus-Distill-v2, passed the first cut and got rebuilt and tested directly.
A training bug found and fixed
The model's own history is instructive on its own. A user reported a reproducible hang in version 1: stacked formatting constraints like "no prose, no markdown" sent the model into an endless self-checking loop, burning its entire token budget with no output. The author traced the cause: 83 percent of the training data wasn't genuine Opus reasoning at all, but reconstructions a helper model invented after the fact from a real Opus answer. For version 2, every unverified line was replaced with the genuine trace, cutting the dataset from 14,250 to 11,716 lines.
We reproduced this exact case on our own copy: version 1 does hang at 3000 of 3000 tokens with zero output, version 2 solves the same task in 87 of 4096 tokens with clean code.
A test-harness bug found before trusting the number
The first run against our 21-task battery scored 16 of 21, with two apparently failed tool calls. A direct follow-up query showed both calls were actually correct. The bug sat in our own test script, which concatenated streamed tool-call fragments raw and then searched the result for a substring — when a backend like llama.cpp splits a value such as a part number across fragments, JSON syntax ends up sitting between the pieces, and the search wrongly reports failure. After the fix, at deterministic temperature zero, the reproducible result was 18 of 21 — exactly what our production model scores on the same battery.
Three genuine failures, each with a found cause
One of the three remaining failures isn't a math weakness but a prompting effect: a discount-chain task fails under a terse "just the number" instruction but succeeds reliably once the prompt explicitly asks for intermediate steps.
A second failure involves a counting task over heavily repetitive text: at high reasoning effort, the model burns its entire token budget on internal reasoning without ever producing an answer. That isn't specific to this model — it's a known operational risk of this reasoning setting on exhaustive tasks.
The third concerns turning reasoning off entirely: despite enable_thinking:false being set, a raw reasoning tag shows up in the visible answer field. The first guess, that this was an llama.cpp quirk, didn't survive a follow-up check — the same behavior showed up identically when we ran the same checkpoint in FP8 through the same production-style configuration as our 27B model on vLLM. The bug sits in the model itself: the fine-tuning was built around continuous deep reasoning, and both reasoning parsers trust the request flag instead of checking the actual output. A working workaround exists: a system-prompt instruction instead of the API flag reliably suppresses the leak, with the answer staying correct.
Freeform reasoning tasks: four out of five
On five freshly written reasoning tasks not part of the test battery, the model solved four correctly, each with a genuine, unprompted self-check via an independent calculation path. The one miss involved an unusually shaped problem with an implicit volume equation: the derivation set a boundary condition wrong, and the model's own verification in the text only checked its already-wrong formula against itself, so it couldn't catch the error. On the four classically shaped tasks — rate, probability, optimization — self-checking worked reliably.
Where things stand
barozp-v2 is the only one of the four candidates checked that survives real testing, with one operational bug still open before any production use. The other three remain either watch items or not relevant to us.
Further reading
What is a Claude Opus distillation fine-tune?+
A fine-tuning approach where an open model is trained on real Claude Opus reasoning traces — the internal chain of reasoning, not just the finished answer. The goal is to carry a proprietary reasoning model's answering behavior into an open weight.
Why does the winner's v1-to-v2 history matter?+
Because it shows how easily training data can be corrupted: 83% of v1's traces weren't genuine Opus reasoning, but reconstructions invented after the fact by a helper model. That caused a reproducible hang under stacked formatting constraints. Version 2 replaced every unverified line — we reproduced the fix on our own copy and it holds.
What does the enable_thinking bug mean in practice?+
The model was fine-tuned for continuous deep reasoning and ignores the API flag meant to turn thinking off — confirmed on both llama.cpp and vLLM. A raw reasoning tag can leak into the visible answer field as a result. The working workaround is a system-prompt instruction instead of the flag.