In this article
Interleaved thinking, preserved thinking and turn-level control govern different parts of a GLM conversation.
GLM-4.7 has several thinking controls that solve different problems. Preserving past reasoning, reasoning between tool results and enabling thinking for one request should not be treated as the same switch.
Distinguish the three mechanisms
The GLM-4.7 card describes a coding-oriented model. The thinking documentation separates interleaved thinking, preserved thinking and turn-level control. Interleaving lets the model reason between tool interactions. Preservation concerns historical reasoning returned in later requests. Turn-level control chooses reasoning behavior for a particular turn.
These distinctions explain why an application can enable reasoning yet still lose useful history, or preserve history while making an unsuitable mode choice for a simple follow-up.
Read endpoint defaults as documented service behavior
The thinking guide says preserved thinking is enabled by default on the Coding Plan endpoint and disabled by default on the standard API endpoint. It describes clear_thinking set to false as the way to enable preservation for the relevant API workflow.
Those defaults belong to the documented hosted services. A local engine has its own template and integration path. Do not assume that a display label such as GLM automatically selects the same history policy.
Follow a concrete coding conversation
Suppose the first request introduces a function that must distinguish a missing value from an empty value. A tool then returns a failing assertion. After repair, the user asks only to improve the function’s explanation.
| Mechanism | Question in this conversation |
|---|---|
| Interleaved thinking | Can the model reason after the failing assertion? |
| Preserved thinking | Does the next request retain the intended earlier reasoning? |
| Turn-level control | Does the explanation-only request require new deep reasoning? |
| Final acceptance | Does the code still preserve the original distinction? |
The Flash card recommends preserved thinking for particular multi-turn evaluation tasks. That recommendation reinforces the need to identify a workflow, rather than prescribing identical behavior for every conversation.
Preserve blocks without silently rewriting them
The guide requires complete, unmodified reasoning_content for preservation and warns against reordering or editing consecutive blocks. A wrapper that summarizes them is implementing a different history transformation, even if the summary sounds equivalent.
Keep final answers and tool results distinct from reasoning fields. Removing a final answer because it followed a think marker is a parsing mistake, not a legitimate preservation policy. Inspect the structured conversation at the boundary where the next request is assembled.
Choose the control that addresses the failure
A missing intermediate step calls for examining interleaving and tool history. Lost continuity across requests calls for examining preservation. Unnecessary reasoning on a lightweight wording task calls for examining turn-level choice.
Store those diagnoses separately. A successful coding exchange supports only the observed model, endpoint or local implementation and message structure. It does not prove that retaining every trace always helps, that all GLM releases accept the same controls or that turning on thinking automatically preserves historical reasoning.