Summary

• Problem: For Telegram (and other channel) sessions running against z.ai-style OpenAI-compatible providers (z.ai direct, openrouter z-ai/glm-*), conversational context is lost on consecutive turns. The HTTP request body that reaches the provider contains only the system prompt and the just-submitted user message, even though the runner's prompt.submitted trajectory event captured the full prior transcript with messagesLen matching the number of stored messages. Pronouns lose their referent, and continuation requests can ship a bare tool result without its preceding assistant tool call.
• Root Cause: pi-coding-agent's Session.prompt() runs _checkCompaction(lastAssistant, false) before it appends the new user message. For z.ai-style providers, pi-ai's isContextOverflow (Case 2 — "Silent overflow z.ai style") returns true whenever the last successful assistant turn has usage.input + usage.cacheRead > contextWindow, even with stopReason: "stop". That triggers Pi's _runAutoCompaction("overflow", true) which reassigns agent.state.messages to the post-compaction view — typically a single compaction summary, sometimes empty. When agent.prompt(messages) then runs the agent loop, the snapshot of state.messages is the now-tiny array, so streamFn ships a near-empty transcript to the provider. The runner's prompt.submitted event already deep-cloned state.messages via safeJsonStringify before _checkCompaction mutated it, so the trajectory still shows the pre-compaction count — making the trajectory look correct while the actual provider call is starved of context. OpenClaw's runner already drives compaction itself (shouldPreemptivelyCompactBeforePrompt and the tool-result-context-guard mid-turn precheck), so Pi's parallel auto-compaction inside Session.prompt() is redundant for the failure cases this fix targets.
• Fix: Extend applyPiAutoCompactionGuard so setCompactionEnabled(false) also fires when the active model matches z.ai-style silent-overflow accounting. Detection routes through structured channels already present in the codebase — the ProviderEndpointClass typed enum (matching endpointClass === "zai-native" for direct api.z.ai), the existing normalizeProviderId normalizer (matching the zai family for a config-set z.ai provider), and a z-ai/ or openrouter/z-ai/ model-id prefix as a documented string fallback for openrouter routing — any one signal is sufficient. The compaction-LLM call site reads effectiveModel.baseUrl (the post-applyAuthHeaderOverride view that matches every other reference in that scope), so an api.z.ai baseUrl injected via auth profile is still visible to the detector. The existing contextEngineInfo.ownsCompaction === true short-circuit is preserved unchanged. Default-mode runs against non-z.ai providers are not touched — Pi's auto-compaction stays on for them, preserving the existing baseline. To survive DefaultResourceLoader.reload() rehydrating settings from disk and silently re-enabling auto-compaction (the same rehydration the existing applyPiCompactionSettingsFromConfig re-call sites already document), the guard is invoked a second time after the reload in both the embedded runner and the runner-driven compaction LLM session, mirroring the pattern already used for compaction config rehydration.
• What changed:
  • src/agents/pi-settings.ts: new exported isSilentOverflowProneModel({provider, modelId, baseUrl}) helper using resolveProviderEndpoint's endpointClass, normalizeProviderId, and the z-ai/ / openrouter/z-ai/ model-id prefix. shouldDisablePiAutoCompaction and applyPiAutoCompactionGuard accept a new silentOverflowProneProvider?: boolean in addition to the existing contextEngineInfo.
  • src/agents/pi-embedded-runner/run/attempt.ts: the existing applyPiAutoCompactionGuard call now computes silentOverflowProneProvider from params.model. A second applyPiAutoCompactionGuard call is added immediately after resourceLoader.reload(), alongside the existing post-reload applyPiCompactionSettingsFromConfig re-call.
  • src/agents/pi-embedded-runner/compact.ts: imports applyPiAutoCompactionGuard and isSilentOverflowProneModel; adds a guard call after the local resourceLoader.reload(). This site previously had no guard call at all, leaving the nested compaction LLM session vulnerable to the same _checkCompaction re-entry on z.ai-style runs.
  • src/agents/pi-settings.test.ts: nine new cases appended to the existing colocated test file. Five cases for isSilentOverflowProneModel (z-ai-prefixed model ids in both bare and qualified forms, config-set z.ai/z-ai provider, direct api.z.ai baseUrl, anthropic/openai/google routes negative, missing fields negative) and four cases for applyPiAutoCompactionGuard (silent-overflow-prone disables, ownsCompaction === true still disables, default-mode + non-z.ai is left enabled, missing setCompactionEnabled reports unsupported).
• What did NOT change (scope boundary):
  • No vendored dependency edits — pi-coding-agent and pi-ai are untouched. Their compaction and overflow-detection logic is correct in isolation; this fix only stops them from firing in parallel with OpenClaw's runner-owned compaction in the cases listed above.
  • No change to default-mode runs against non-z.ai providers. They retain Pi's auto-compaction inside Session.prompt() as before.
  • No change to other documented-unreliable providers (e.g. ollama silent truncation). Reporter's repro is z.ai-specific; extending the guard without an actual repro would be speculation.
  • No change to shouldPreemptivelyCompactBeforePrompt, the tool-result-context-guard mid-turn precheck, context-engine assemble, the trajectory event's snapshot timing, or any provider transport.
  • No change to the CLI /compact entrypoint surface — its nested runner-driven compaction LLM session is protected through the compact.ts site this PR modifies.
  • No any types introduced.
  • No edits to baseline / inventory / snapshot fixtures.

Reproduction

1. Run OpenClaw with the bundled legacy LegacyContextEngine (default).
2. Configure an OpenAI-compatible provider that points at a z.ai-style model — for example, provider: openrouter with model: z-ai/glm-5.1 via a custom baseUrl for an in-house model gateway. Anything where the previous successful assistant turn has usage.input + usage.cacheRead > model.contextWindow works (z.ai-family accounting is documented as silent-overflow style in pi-ai's overflow.ts).
3. Open a Telegram session and send: "first off - there's a folder full of my projects at /root/code - these all live in github. They're my main focus". The agent calls a tool, observes /root/code, and replies.
4. Send a follow-up: "just note where they are - remember that. They'll be needed in future".
5. Capture the outbound openai-completions request body at the gateway (correlate with the run id from the OpenClaw trajectory). Without the fix, the body contains only the system message and the just-sent user message, while the trajectory's prompt.submitted event records the full pre-existing transcript. The agent's reply ignores the earlier /root/code context and asks what "they" refers to.
6. With this fix, applyPiAutoCompactionGuard sets setCompactionEnabled(false) for z.ai-style runs both before and after resourceLoader.reload(), Pi's _checkCompaction short-circuits inside Session.prompt(), state.messages keeps its prior contents, and the model receives the full transcript. Coreference resolves correctly.

Targeted test: pnpm test src/agents/pi-settings.test.ts — 25/25 pass (16 existing + 9 new), including the explicit silent-overflow-prone disable regression case for #75799 and the explicit baseline-preservation case for default-mode + non-z.ai providers.

Risk / Mitigation

• Risk 1 — Real overflow recovery on z.ai: With Pi's auto-compaction off for z.ai-style runs, a genuine context overflow on the previous turn previously had two recovery paths (Pi's _runAutoCompaction and OpenClaw's shouldPreemptivelyCompactBeforePrompt). After this PR only OpenClaw's path runs for z.ai.
  • Mitigation: OpenClaw's preemptive check already runs unconditionally on every turn and skips submission with a preemptive-overflow signal when compaction is needed; the tool-result-context-guard mid-turn precheck handles overflows mid-tool-loop. The runner's compaction recovery path then drives compaction. Default-mode runs against non-z.ai providers are not changed — they keep Pi's auto-compaction as the secondary recovery.
• Risk 2 — z.ai detection scope: isSilentOverflowProneModel uses three signals (typed endpointClass enum, normalized provider id, model-id prefix). A future provider rename or an unusual proxy that re-exposes z.ai under a different model-id namespace could miss detection.
  • Mitigation: All three signals are documented in JSDoc with their intended channel; the new tests pin each branch; and the helper is exported so follow-up changes can extend it once a reproducible repro for additional providers exists. Detection is intentionally conservative — false negatives leave the existing buggy behavior, but never invent a regression for unrelated providers. The auth-profile-injected baseUrl case is exercised at the compaction-LLM site by reading the post-override effectiveModel.baseUrl.
• Risk 3 — Rehydration regression: The post-reload re-call adds two new call sites. If applyPiAutoCompactionGuard ever gains expensive side effects, those sites will execute twice per run.
  • Mitigation: applyPiAutoCompactionGuard is a small decision plus at most one setCompactionEnabled(false) call; that write is idempotent (sets the same field to the same value when already disabled). The two applyPiCompactionSettingsFromConfig calls already follow the same "before + after reload" pattern at the same files.

Change Type (select all)

• Bug fix

Scope (select all touched areas)

• Agents (pi-embedded-runner, pi-settings)
• Tests

Linked Issue/PR

Fixes #75799