The card opens with a two-by-two grid: task type on one axis, whether explicit reasoning helps on the other. Multi-step math, planning, and logic puzzles land in the “helps” quadrant. Simple fact lookup, stylistic rewrite, and shallow classification land in “little gain.” A short sidebar lists what counts as reasoning today: chain-of-thought text, scratchpads, tool calls, and search loops.
“Reasoning” here means observable intermediate computation, not a separate module inside the network. The same transformer that predicts the next token can emit steps that later tokens condition on. That is why prompting techniques and inference-time search change performance without retraining. It is also why reasoning can be shallow: the model may produce plausible steps that do not actually drive the answer.
Match technique to task structure. Use chain-of-thought or scratchpads when errors come from jumping to conclusions. Use tools or program-aided methods when exact calculation or lookup matters. Skip heavy reasoning overhead on tasks where one shot answers are reliable, since extra tokens add latency and cost without benefit. The grid on the card is the decision guide.
Reasoning quality varies by model size, training recipe, and whether the model was optimized for long coherent chains. Test on your own benchmark slice rather than assuming a label like “reasoning model” transfers to every workflow. The practical frame is conditional: reasoning is a resource you spend at inference time when the problem decomposes into checkable steps, not a universal setting to leave on.