Preserved Thinking: Why GLM Feels Coherent in Long Agentic Sessions on CloudCode.ONE

Preserved Thinking: Why GLM Feels Coherent in Long Agentic Sessions

If you've run an open model through a coding agent for more than a handful of turns, you've probably felt the drift. The agent makes a good plan, calls a few tools, and then — somewhere around turn ten — starts contradicting itself, re-deriving decisions it already made, or forgetting why it went down a particular path. The code still compiles, but the coherence is gone.

A big part of that problem is what happens to the model's thinking between turns. On CloudCode.ONE, GLM-5.2's reasoning is preserved across the whole session — in both Harness and Claude Code — and that's most of what separates a session that holds its shape from one that unravels.

Here's what "preserved thinking" actually means, why it's non-trivial to get right through an Anthropic-compatible gateway, and how we handle it.

What preserved thinking is

GLM-5.2 ships with thinking enabled by default. Before it answers or picks a tool, it produces a chain of reasoning — the scratchpad it uses to plan, interpret tool output, and decide what to do next.

The question is what happens to that reasoning on the next turn. There are three ways an agent can treat it:

Interleaved thinking — the model thinks between tool calls and after each tool result, reasoning about the output before deciding the next step. This is the default for agentic loops.
Preserved thinking — the model keeps the reasoning from previous assistant turns in context, not just the current one. Its earlier plan, its earlier interpretation of a file, its earlier "I'll come back to this" all stay visible to it.
Turn-level thinking — reasoning toggled per turn: on for the hard steps, off for the trivial ones.

Preserved thinking is the one that matters for long-horizon coding. It gives the model reasoning continuity: instead of reconstructing its plan from the visible chat and tool history every turn, it can see the actual reasoning that produced those actions. And because that reasoning stays byte-stable in the prompt prefix, it plays nicely with prompt caching — you're not paying to re-process it from scratch each round.

Why it matters more for agents than for chat

In a single-shot chat, thinking is disposable. The model reasons, answers, done.

An agentic session is the opposite. A whole-repo refactor or a multi-file bug fix is dozens — sometimes hundreds — of tool calls stitched into one long chain. Every read_file, bash, edit, and grep is another turn. If the model's own reasoning evaporates between those turns, it's rebuilding its mental model from tool transcripts over and over. That's where you get:

Plan drift — the strategy from turn 3 quietly mutates by turn 15.
Repeated work — it re-investigates a file it already understood, because the understanding lived in a thinking block that got dropped.
Weak cross-file coordination — the whole reason you want a 1M-context, agentic-first model is to hold a repo in its head. Strip its reasoning and you throw away half of that.

Preserved thinking is what lets GLM-5.2 behave like it's working one continuous problem across a long session instead of waking up fresh every tool call.

The part that's actually hard: the Anthropic Messages API

Both Claude Code and Harness speak the Anthropic Messages API. In that format, thinking isn't free text — it's a structured thinking content block that carries a signature:

{
  "role": "assistant",
  "content": [
    { "type": "thinking", "thinking": "The failing test is in the auth module...", "signature": "5eff91fec6454ce6..." },
    { "type": "tool_use", "id": "call_...", "name": "bash", "input": { "command": "pytest -k auth" } }
  ]
}

The rule the API enforces is strict: thinking blocks must be passed back unchanged. Modify one, drop its signature, or reorder it, and the next request is rejected outright. Anyone who's wired up a custom provider has seen these:

thinking blocks in the latest assistant message cannot be modified — these blocks must remain as they were in the original response
Assistant message must start with a thinking block when thinking is enabled

A naive proxy in front of an open model tends to fail this in one of two ways. It either strips thinking entirely — which "works," but throws away exactly the continuity you wanted — or it passes reasoning through in a slightly-wrong shape and the client hard-errors mid-session.

GLM-5.2 makes this a little spicier because its native emission doesn't line up one-to-one with Anthropic's. A well-known example: GLM sends the signature in content_block_start, where the Anthropic streaming contract puts it in a signature_delta just before content_block_stop. Get that mapping wrong and the signatures never round-trip, so preservation silently degrades into stripping.

What CloudCode.ONE does

Our gateway sits between the agent and GLM-5.2 and does the boring, load-bearing work so you don't have to:

Normalizes GLM-5.2's native reasoning stream into well-formed Anthropic thinking blocks, including moving the signature into the position the Messages API contract expects.
Preserves signatures verbatim across the whole session, so every subsequent turn round-trips the block exactly as it was issued — no rejections, no "must start with thinking block" surprises.
Keeps prior-turn thinking in context for the long-horizon modes, so the model gets real reasoning continuity rather than a summary of what it once thought.
Stays cache-friendly — because the preserved reasoning prefix is stable, prompt caching keeps hitting, which is the difference between "affordable long session" and "surprise bill" on a pay-as-you-go plan.

The net effect: preserved thinking is on by default, and it just works in the two clients most of our users live in.

Using it in Harness

Harness is the free desktop agent that ships with CloudCode.ONE. Point it at GLM-5.2 and preserved thinking is already active — you'll see the agent carry its reasoning forward across tool calls instead of restating its plan every turn. For heavy multi-file work, bump the thinking effort up (Max) and let the preserved chain do its job; for quick edits, drop it down and save the tokens.

Using it in Claude Code

Claude Code talks to CloudCode.ONE by pointing its Anthropic base URL at the gateway:

export ANTHROPIC_AUTH_TOKEN=sk-O...
export ANTHROPIC_MODEL=glm-5.2[1m]
export CLAUDE_CODE_EFFORT_LEVEL=max


claude

From there it behaves like any other Anthropic-compatible session — except the model underneath is GLM-5.2, and its thinking is preserved turn to turn. The /effort control maps through to GLM-5.2's thinking modes, so you can dial reasoning depth from inside Claude Code the same way you would with a native model. No framework changes, no custom shims to maintain — the gateway absorbs the interop.

Two things worth remembering

Preserved is not the same as displayed. The thinking that keeps the model coherent is not an audit trail. Keep thinking blocks when you re-invoke the model; strip them before showing a transcript to an end user. Mixing those up is the single most common bug in this space.
Thinking is tokens. Preserved reasoning stays in context and is billed as input. That's the trade: continuity and better cache hits in exchange for a bigger prefix. For agentic coding it's almost always worth it — which is exactly why GLM-5.2 turns it on by default.

The short version

Open models have closed most of the capability gap. Where they still fall over in practice is the plumbing — the unglamorous business of making a model's reasoning survive a hundred tool calls through a strict, signature-checked API. That's the gap CloudCode.ONE fills for GLM-5.2. You get the model's full agentic coherence in Harness and Claude Code, on pay-as-you-go pricing, without babysitting thinking blocks yourself.

Spin up a key and run GLM-5.2 through your agent of choice at cloudcode.one. New accounts can use MYFIVECENTSFORDEV26 for starter credit.

All posts · CloudCode.ONE home