A developer asks an AI for a strawberry cheesecake recipe and turns on “show reasoning.”
The model pauses, then a neat little thought chain appears:
- Identify required ingredients
- Break recipe into steps
- Ensure baking time and temperature are correct
- Present answer clearly
Another model gets the same prompt. Its “thoughts” look almost identical. Line by line, the same kind of bullets, the same structure, the same calm, generic self-talk.
If you’re building with these systems, that sameness raises some uncomfortable questions:
- Are these models secretly sharing training data?
- Are they all just copying one another’s “reasoning style”?
- And most important: are these traces actually how the model thinks, or just a story it tells you after the fact?
This is the tension at the heart of a growing debate: when an AI shows you its “chain of thought,” how much of that is real reasoning—and how much is just UI sugar?
What we see vs. what the model actually does
The core claim from practitioners digging into this is simple: the “thought chains” you see for models like Qwen3.5 and Gemini are summaries, not raw internal reasoning.
In one example, a user compared how Qwen3.5-397B-A17B and Gemini 3 handled that cheesecake recipe request. The visible reasoning traces looked strikingly similar: both started by planning ingredients, broke the answer into stages, and ended by double‑checking clarity. At first glance, it felt like they were thinking in the same template.
But when the same Qwen3.5 model was run locally with deeper access to its internals, the “true reasoning” looked different from what the hosted interface showed. The displayed chain was cleaner, shorter, and more human-readable than the messy underlying process.
That’s the key idea: what you’re shown is a compressed narrative. It’s as if the model first does a bunch of opaque math, then later generates a tidy explanation of what it “must have been thinking” to get that answer.
Once you see it that way, the surface similarity between models stops being surprising. Of course their thought chains look alike. They’re all:
- Trained to speak to humans in a certain way
- Rewarded for producing clear, ordered, polite reasoning
- Optimized to fit into the same “assistant” UI pattern
The sameness is less about a shared mind and more about a shared script.
Why thought chains converge across different models
Under the hood, these models are trained with reinforcement learning and supervised fine-tuning. They don’t just learn to be “right”; they learn to be “right in a way that humans like.”
That matters for reasoning traces. If you give a model a reward every time it produces:
- a numbered list of steps,
- a preamble like “Let’s think step by step,” and
- a conclusion that wraps everything in a bow,
then, over time, that’s the shape its visible reasoning will take, no matter how it got to the answer internally.
The dossier points to several families—Qwen, GLM, MiniMax M2.5—that all show this kind of convergence in how they present reasoning. They’re trained differently, on different data, but they’re optimized against similar reward functions and human preferences. If evaluators and users keep picking the same style of explanation as “good,” the models all drift toward that style.
When you then compare their “thoughts” on simple prompts—like cheesecake recipes—it’s no shock that they rhyme.
Summarized reasoning vs. raw chain-of-thought
Another important distinction in the material is between:
- Raw chain-of-thought: the unfiltered sequence of intermediate tokens the model generates to get to an answer, and
- Summarized reasoning: a cleaned-up explanation produced after the model has essentially made up its mind.
The public interfaces almost always show the second.
One observation about Gemini 3, for example, is that its displayed “thoughts” are condensed. They are not a dump of the internal reasoning tokens. They look like the kind of thing you’d write if you knew the answer already and were reconstructing the logic for someone else’s benefit.
A similar pattern appears with Qwen3.5: when inspected locally, its internal reasoning trace is more chaotic and less polished than what the hosted product shows users. The visible chain is best understood as post-hoc explanation, not a transparent window into the model’s cognition.
This has two implications:
- Similar explanations do not prove similar internal reasoning or shared training data.
- You shouldn’t over-trust the step-by-step trace as a diagnostic tool for the model’s actual “thought process.”
It’s closer to a student who solves a math problem in their head, then writes up a neat solution afterward. The solution may be valid and helpful, but it’s not necessarily how they truly got there.
Where chain-of-thought training breaks down
The dossier also flags a practical weakness: supervised fine-tuning directly on reasoning chains tends to perform poorly on out-of-distribution tasks.
In plain terms, if you train a model to imitate human-style explanations on a certain set of problems, it can get very good at:
- sounding logical,
- following the familiar “First, I will…” pattern, and
- matching the training examples.
But once you move into unfamiliar territory—new domains, strange edge cases—the model can keep producing confident, well-structured reasoning while getting the actual answer wrong.
You end up with:
- Beautiful chains of thought
- That are internally inconsistent
- Or that rest on hidden mistakes
The dossier mentions that Qwen3 itself shows a pattern of self-contradiction until its confidence increases. This looks like the model generating early, tentative reasoning lines, then revising or contradicting them as it settles on a final answer. If you were to expose those raw steps, you’d see it arguing with itself more than the clean UI suggests.
For builders, this is a warning sign: a tidy reasoning trace is not the same as robust reasoning. It’s entirely possible to optimize for the former while barely improving the latter.
So what should you trust as a builder or operator?
If you’re a founder, engineer, or marketer working with these systems, it’s tempting to lean on “show reasoning” as a debugging tool or as proof of sophistication. There is some value there—but only if you treat these traces with the right level of skepticism.
Here are some grounded takeaways from the discussion.
1. Treat visible reasoning as UX, not X-ray vision
The explanation you see is a layer built for humans. It is shaped by:
- interface design choices,
- summarization steps, and
- reward models that favor a certain tone and structure.
Use it to improve user trust and clarity, not as a literal trace of what the model did internally.
2. Don’t infer copying from style alone
If Qwen3.5 and Gemini 3 produce very similar-looking thought chains for simple questions, that alone is weak evidence of shared data or imitation.
Given similar reward functions and human feedback, different models will converge on similar “assistant voice” and reasoning templates. If you’re investigating potential training contamination, you need deeper, more controlled tests than just side-by-side thought chains.
3. Evaluate on outcomes, not just explanations
A model that explains itself beautifully but fails on hard, unfamiliar tasks is not a strong reasoning system—it’s a good explainer.
When you’re choosing or tuning models:
- Focus on task accuracy under realistic conditions
- Test across varied and out-of-distribution cases
- Check not only that the reasoning sounds good, but that it holds up under scrutiny
If the model frequently contradicts itself, corrects itself, or “forgets” earlier steps, those polished reasoning traces are veneers.
4. Be careful training on human-style reasoning text
Supervised fine-tuning on curated reasoning chains can help your model speak more clearly, but it may not help it think more clearly.
If your goal is better generalization and robustness, you likely need:
- higher-quality, diverse problems,
- outcome-based rewards, and
- evaluation schemes that don’t over-emphasize presentation.
Let the model optimize for being right before you push it to explain itself in a particular style.
5. Use reasoning traces as a design tool, not a security blanket
There is still real product value in showing a chain of thought:
- Users can understand why a recommendation was made
- Support teams can see how an answer was arrived at
- Developers can spot obvious gaps, like missing constraints or skipped steps
Just remember: you’re designing an experience, not unlocking the model’s soul. Use these traces to guide user expectations and collect feedback, not as a substitute for proper testing, guardrails, and domain checks.
The promise of “showing the model’s thoughts” is powerful. It hints at transparency, accountability, and even a kind of shared reasoning space between humans and machines. But the reality, at least for now, is more modest.
What we see are stories about reasoning, shaped by training and reward functions, compressed into friendly bullet points. They are useful stories—but they are still stories.
For builders, the discipline is to appreciate the narrative without mistaking it for the whole truth. Measure what the model can do, not just how well it can explain itself. And when two models start sounding eerily alike, remember: they might just be reading from the same playbook we handed them.
