In this article
Granite low-effort combines enabled thinking with low_effort, while history truncation is a separate control.
Granite 4.2 distinguishes full thinking, low-effort thinking and non-thinking behavior. These modes are controlled through the model’s template rather than a universal effort vocabulary copied from another family.
Read the documented controls
The 4.2-8B card lists enable_thinking=True for full thinking, enable_thinking=False for non-thinking and enable_thinking=True together with low_effort=True for low-effort reasoning.
The IBM technical article explains usage, and the official repository supplies release artifacts. The card recommends temperature 1.0 and top_p 0.95 across its documented modes. Preserve that guidance when establishing a reference condition, while recording any deliberate experiment with other settings.
Understand what the template changes
With thinking enabled, the generation prefix opens a think block. With thinking disabled, the prefix supplies an empty block. Low-effort mode adds a specific low-effort instruction to the user message.
These are different prompt constructions. A request field named reasoning_effort does not automatically perform the same transformation unless the selected integration maps it correctly. Inspect the template path before interpreting an apparent mode failure.
Choose a small task for each mode
| Task shape | Useful acceptance check |
|---|---|
| Fixed-label decision | Correct label without unsupported explanation |
| Simple checked calculation | Completed correct final value |
| Multi-constraint problem | Every condition satisfied |
| Code repair | Applicable patch preserves protected behavior |
| Follow-up question | Prior final facts remain available |
The mode name should not decide acceptance. A long trace with a wrong result fails; a concise correct result can pass if the task did not require a proof.
Keep history behavior separate
The card describes truncate_history_thinking=True as the default for stripping earlier assistant reasoning. Setting it to false preserves that history. This is a different choice from enabling thinking for the current generation.
If a follow-up loses a needed fact, first determine whether the fact was in the final answer or only in removed reasoning. Preserve final messages and tool observations correctly. A history-construction problem should not be diagnosed as proof that full thinking is ineffective.
Direct comparison of the rendered prefixes can explain unexpected behavior before a different model is selected.
Produce a mode acceptance sheet
Store exact checkpoint and template revisions, forwarded controls, output allowance and reference checks. Compare full, low-effort and non-thinking on the same fixture where a direct comparison is useful. Retain incomplete outputs separately.
Select the documented condition that meets the task’s requirement. This can justify different modes for simple and complex requests without promising a universal latency gain. The result does not establish identical controls across engines, guaranteed reasoning depth or the safety of extracting tentative values from an unfinished thought block as final answers.