Run a big model (Sol, Opus) at low reasoning intensity, or take a small model (Luna, Haiku) and crank reasoning to max? Kun Chen spent about two weeks deliberately trying every combination, and came away with a clean intuition: model size gives you “wisdom,” reasoning intensity gives you “diligence.” Two completely different things.

Wisdom and Diligence

A bigger model has seen more, remembers more, and spans a wider range of domains. Its intuition is sharper—it can connect dots scattered across different fields and come up with ideas that are creative and genuinely illuminating. That’s wisdom: having seen enough of the world that you can find unexpected connections when a new problem lands in front of you.

Reasoning intensity makes the model more careful: evaluating each option one by one, thinking through the consequences of every step, digging up edge cases and checking them. That’s diligence—not smarter, just more thorough. No option left unevaluated, no branch left unexplored.

Mogu going off-topic:

“Reasoning intensity” is the user-facing knob for test-time compute. Set it to low and the model answers instantly; set it to high and it goes back and forth in its head for several rounds before speaking. What it burns is inference-time compute. No amount of overtime can produce insights that weren’t baked in during training.

The same author’s agent fleet composition chart (first mate gets the smartest model with reasoning cranked to max; grunt work goes to the cheap ones) is the applied version of this principle—that post gave the lineup, this one explains why it’s arranged that way. Even earlier, people were already debating that the strongest reasoning model isn’t necessarily the best coder—same axis.

A Hundred Roads and a Tunnel

A hundred roads lie ahead. The diligent model evaluates them one by one, missing none—but it won’t spontaneously realize: maybe the best move is to skip all hundred and dig a tunnel instead.

The ability to step outside the given options and think of “dig a tunnel”—that’s wisdom.

Diligence makes sure no given option is missed; wisdom is what goes back and asks whether the set of options itself is right. The two can’t substitute for each other. Cranking up reasoning intensity won’t suddenly give a small model the breadth of a large one; using a bigger model won’t automatically make it more careful.

Kun Chen says this is when it clicked for him why the providers arrange their lineups the way they do, rather than just shipping one Fable-tier model with twelve reasoning presets—because model size and reasoning intensity aren’t on the same axis at all.

Mogu real talk:

Diligence walks every road; wisdom discovers the roads themselves are wrong. Next time your agent handles every edge case flawlessly and still gets the whole direction wrong—that’s full marks for diligence, zero for wisdom. gu-log’s own four-judge system sits right on this line: quality scoring needs taste (wisdom), so it uses the largest model; fact-checking needs thoroughness (diligence), so it deliberately swaps in a different model as a second pair of eyes. Different knobs, different turns. (⁠╯⁠°⁠□⁠°⁠)⁠╯

Why People Confuse Them

Because of benchmarks.

The industry has been plotting model capabilities on a single line—run a test, get a score, rank them, highest on top. Kun Chen puts this bluntly: this framing is broken at the root, because it uses one dimension to measure a two-dimensional thing, flattening “wisdom” and “diligence” into a single number. Look at that number and you’ll naturally think model size and reasoning intensity are interchangeable: a small model with cranked-up reasoning catches up in score, so it must have caught up to the big model.

But what caught up is the score on the same test, not the same kind of capability. Being able to evaluate all hundred roads and being able to think of digging a tunnel might score the same on a benchmark—but when solving real problems, they’re worlds apart.

Kun Chen just hopes that evaluation benchmarks will eventually catch up and measure these two dimensions separately. Until then, the illusion persists.

Choosing in Practice

Until that day comes, Kun Chen’s own approach boils down to three rules of thumb:

  • This problem needs a genius to crack—use a big model.
  • This problem needs a pen and a lot of paper to work through—crank up reasoning intensity.
  • It needs a genius to sit down with a pen and a lot of paper—turn both knobs up.
Mogu OS:

Compare these against the three most common types of work: refactoring a module where nobody can clearly define the boundaries—the option set itself is the problem, a genius-level call, bring the big model; sweeping a known bug across thirty files—the options are clear, there are just a lot of them, a pen and lots of paper is enough, max out reasoning intensity; deciding whether the entire system should switch architectures and then actually getting all thirty files right after the switch—congratulations, both knobs go to eleven, and so does the bill.

Closing

The model walked all hundred roads and the problem still isn’t solved—maybe what’s missing isn’t more roads. It’s a tunnel.