fix: respect session context window in preflight compaction by moeedahmed · Pull Request #80222 · openclaw/openclaw

moeedahmed · 2026-05-10T10:29:19Z

Summary

Fixes preflight compaction thresholding so sessions use the active session's persisted contextTokens when it is larger than the resolved model context window.

This prevents safeguard compaction from firing too early in long-context sessions, for example compacting around ~148k tokens in an active 272k-token session.

Why

A session can persist the actual active context window on the SessionEntry. When preflight compaction resolves a smaller context window from model/config routing, the threshold can be too low and compaction can run unnecessarily even though the active session still has substantial headroom.

Change

Resolve the model/config context window as before.
Read entry.contextTokens when present and valid.
Use the larger value for preflight compaction gating.
Add a regression test covering the false-positive compaction case.

Test

npm test -- --run src/auto-reply/reply/agent-runner-memory.test.ts

Result: 16/16 passed.

Real behavior proof

Behavior or issue addressed: Preflight safeguard compaction could fire too early in a long-context Telegram session, compacting around 90k-150k tokens even though the active session had a 272k-token context window.

Real environment tested: Moeed's live OpenClaw 2026.5.5 gateway on macOS, Telegram System topic, using the installed runtime hotfix that matches this source change.

Exact steps or command run after the patch: Applied the source-equivalent installed runtime hotfix, restarted the gateway, sent normal Telegram System-topic replies, inspected the active session store, and scanned the live gateway log for post-hotfix compaction notices/triggers.

Evidence after fix: Copied live terminal output from the real OpenClaw setup:

sessionId: 86ae751a-3d4a-4c93-9c3c-d784dda1db2c
contextTokens: 272000
totalTokens: 161452
totalTokensFresh: True
compactionCount: 1
post_hotfix_compaction_events_found: False

Installed runtime marker check from the same machine:

dist hotfix marker: present
source hotfix marker: present
compaction-notifier: disabled
notifyUser: False

Observed result after fix: Normal Telegram replies continued in the System topic while the session sat around 161k/272k tokens, and the gateway log scan found no post-hotfix preflightCompaction triggered, Compacting context, or Context compacted events during the verification window.

What was not tested: I did not force the session above the real 272k-token threshold; the verification focused on the false-positive early-compaction case that this patch fixes.

clawsweeper · 2026-05-10T10:32:52Z

Codex review: needs maintainer review before merge.

Summary
The PR changes preflight compaction to gate on the larger of the resolved model/config window and the active session's persisted contextTokens, with a regression test for the false-positive compaction case.

Reproducibility: yes. source-reproducible. Current main computes the preflight threshold from the resolved model/config window only, so the PR's 149k/272k scenario can compact against a 128k resolved window while the active session still has headroom.

Real behavior proof
Sufficient (live_output): The PR body provides after-fix live output from a real gateway showing the long-context session remained below its persisted 272k-token window without post-hotfix preflight compaction events.

Next step before merge
No repair-lane work is needed; the remaining path is normal maintainer review and merge gating for this focused external PR.

Security
Cleared: The diff only changes compaction threshold logic and one focused test; it adds no dependencies, workflows, scripts, downloads, secrets handling, or supply-chain execution path.

Review details

Best possible solution:

Land the focused preflight gate fix after normal maintainer review and merge gates, preserving valid active-session context windows while keeping byte safeguards intact.

Do we have a high-confidence way to reproduce the issue?

Yes, source-reproducible. Current main computes the preflight threshold from the resolved model/config window only, so the PR's 149k/272k scenario can compact against a 128k resolved window while the active session still has headroom.

Is this the best way to solve the issue?

Yes. The PR changes the narrow threshold input, validates the persisted value, and leaves the existing compaction trigger, byte safeguard, and execution paths intact.

What I checked:

Current main preflight gate: Current main still resolves contextWindowTokens only from model/config routing before preflight thresholding. (src/auto-reply/reply/agent-runner-memory.ts:515, 605a2c87ae80)
Threshold trigger path: The resolved window feeds threshold = contextWindowTokens - reserveTokensFloor - softThresholdTokens, then shouldRunPreflightCompaction uses that value for the token trigger. (src/auto-reply/reply/agent-runner-memory.ts:592, 605a2c87ae80)
Persisted context is an established signal: Usage persistence carries params.contextTokensUsed ?? entry.contextTokens back into SessionEntry.contextTokens, and adjacent runtime hint logic already prefers a positive finite active-session context value. (src/auto-reply/reply/session-usage.ts:114, 605a2c87ae80)
PR implementation: The PR validates and floors positive finite entry.contextTokens, then uses Math.max(resolvedContextWindowTokens, persistedContextWindowTokens ?? 0) before the existing preflight threshold logic. (src/auto-reply/reply/agent-runner-memory.ts:483, 777cd4e211de)
Regression coverage: The PR adds a test where a roughly 149k-token transcript with persisted 272k context and a 128k resolved window must not call preflight compaction. (src/auto-reply/reply/agent-runner-memory.test.ts:779, 777cd4e211de)
Real behavior proof: The PR body includes after-fix live gateway output from a real OpenClaw setup showing a 161,452/272,000-token session with no post-hotfix preflight compaction events. (777cd4e211de)

Likely related people:

@steipete: Recent verified history includes oversized-transcript compaction work on the affected memory/flush files, and current blame in the shallow checkout points to recent compaction-path maintenance. (role: recent area contributor; confidence: high; commits: 29af4add2a8e; files: src/auto-reply/reply/agent-runner-memory.ts, src/auto-reply/reply/memory-flush.ts)
@jared596: Introduced the transcript-estimate preflight compaction path that this PR adjusts for persisted session context windows. (role: feature introducer; confidence: medium; commits: c6d8318d07f5; files: src/auto-reply/reply/agent-runner-memory.ts, src/auto-reply/reply/memory-flush.ts)
@neeravmakwana: Recent provider-qualified session context-limit work touched memory-flush.ts, directly adjacent to the resolved-window helper used by this gate. (role: adjacent context-window contributor; confidence: medium; commits: 2645ed154b42; files: src/auto-reply/reply/memory-flush.ts, src/auto-reply/reply/reply-state.test.ts)

Remaining risk / open question:

I did not execute the regression test in this read-only review; the PR body reports a passing focused test run.
The related Feishu large-session slowdown remains broader than this PR and should not be treated as fully resolved by this narrow compaction-threshold fix.

Codex review notes: model gpt-5.5, reasoning high; reviewed against 605a2c87ae80.

samiralibabic · 2026-05-21T19:34:55Z

I’m seeing what looks like the same issue on OpenClaw 2026.5.12 with Telegram + Codex runtime.

/status shows the active session has the correct context window:

🧠 Model: openai/gpt-5.5 · 🔑 oauth (openai-codex:default)
📚 Context: 147k/272k (54%) · 🧹 Compactions: 4
⚙️ Execution: direct · Runtime: OpenAI Codex
🧵 Session: agent:main:main

But compaction still appears around this range, and the compact message can report:

⚙️ Compacted • Context 147k/?

That suggests /status can resolve/persist the effective 272k session context window, while the preflight/manual compaction path is using a different or missing budget.

This PR’s fix direction, using the active session’s persisted contextTokens when larger than the resolved model/config window, looks directly relevant to this production symptom.

RomneyDa · 2026-05-29T06:30:48Z

Heads up: this PR needs to be updated against current main before the new required Dependency Guard check can pass.

fix: respect session context window in preflight compaction

955e21b

openclaw-barnacle Bot added size: S triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 10, 2026

moeedahmed added 2 commits May 10, 2026 12:19

chore: rerun checks after proof update

9f33343

chore: rerun proof check with structured evidence

777cd4e

openclaw-barnacle Bot added proof: supplied External PR includes structured after-fix real behavior proof. and removed triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 10, 2026

clawsweeper Bot added the proof: sufficient ClawSweeper judged the real behavior proof convincing. label May 10, 2026

clawsweeper Bot mentioned this pull request May 15, 2026

Windows + Feishu DM becomes very slow after upgrade to 2026.5.2; latency appears in agent/session processing, likely amplified by large session context #76702

Closed

Thinkscape mentioned this pull request May 26, 2026

[Bug]: sessions_yield subagent wake can compact parent branch at low context usage #86684

Open

moeedahmed closed this by deleting the head repository May 31, 2026

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Uh oh!

Uh oh!

fix: respect session context window in preflight compaction#80222

fix: respect session context window in preflight compaction#80222
moeedahmed wants to merge 3 commits into
openclaw:mainfrom
moeedahmed:fix/preflight-compaction-context-window

moeedahmed commented May 10, 2026 •

edited

Loading

Uh oh!

clawsweeper Bot commented May 10, 2026 •

edited

Loading

Uh oh!

samiralibabic commented May 21, 2026 •

edited

Loading

Uh oh!

RomneyDa commented May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

Uh oh!

Uh oh!

Conversation

moeedahmed commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Summary

Why

Change

Test

Real behavior proof

Uh oh!

clawsweeper Bot commented May 10, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

samiralibabic commented May 21, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

RomneyDa commented May 29, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

moeedahmed commented May 10, 2026 •

edited

Loading

clawsweeper Bot commented May 10, 2026 •

edited

Loading

samiralibabic commented May 21, 2026 •

edited

Loading