[Suggestion] lastPromptTokenCount is hardcoded to 0 here, forcing estimatePromptTokens into the char/4 heuristic branch even when this.lastPromptTokenCount has already been updated by tryCompress (set to info.newTokenCount on COMPRESSED, unchanged on failure). The codebase's own comments document char/4 as under-counting by ~15–20K tokens.

In the non-COMPRESSED branch (compression failure, history unchanged), shouldStopAfterHardRescue compares only localPromptTokensAfterCompression against hardLimit. But effectiveTokens — which triggered hard-rescue in the first place and uses the API-anchored lastPromptTokenCount when available — is never passed into the decision function. A resumed session where lastPromptTokenCount > 0 and the API-anchored count exceeds hard by less than ~15–20K tokens will trigger hard-rescue, fail compression, and then the guard will NOT fire because the char/4 re-estimate falls below hard. The oversized request proceeds to the API — the exact scenario this guard exists to prevent.

Consider passing this.lastPromptTokenCount instead of 0, or threading effectiveTokens into shouldStopAfterHardRescue and using Math.max(effectiveTokens, localPromptTokensAfterCompression) in the non-COMPRESSED branch (mirroring what getHardRescueFailureMessage already does for the error text).

— qwen3.7-max via Qwen Code /review

[Suggestion] In the COMPRESSED branch, tokenCount is always compressionInfo.newTokenCount — even when the guard fired because localPromptTokensAfterCompression >= hardLimit (while newTokenCount < hardLimit). In that scenario the error message reports a token count below the hard limit, leaving users unable to understand why the guard triggered.

Consider using Math.max(compressionInfo.newTokenCount, localPromptTokensAfterCompression) so the reported value always matches or exceeds the limit that was breached:

— qwen3.7-max via Qwen Code /review

[Suggestion] When compression succeeds (COMPRESSED status), tryCompress has already called this.setHistory(newHistory) before this guard runs. If the guard then throws, the original pre-compression history is irreversibly replaced. The session file records the compressed (but still oversized) history, and --continue loads the same unusable state.

This is a design tradeoff — the original history was already too large to send — but it's worth documenting explicitly. Consider either:

1. Adding a code comment noting that history mutation is intentional and the original is recoverable only from the session JSONL backup, or
2. Snapshotting the history reference before tryCompress and restoring it on guard failure, so the user's session file retains the original conversation.

— qwen3.7-max via Qwen Code /review

[Suggestion] The existing hard-rescue warn at ~line 1565 uses a [compaction] prefix and includes effectiveTokens, hard, and consecutiveFailures for greppability and correlation. This new warn uses the user-facing error message as-is, with no [compaction] tag and no prompt_id. In log aggregation, there's no way to filter for all oversized-history guard triggers or correlate with the upstream hard-rescue warn.

Consider adding a structured log prefix:

— qwen3.7-max via Qwen Code /review

[Suggestion] shouldStopAfterHardRescue has a branch that is not covered by either test: COMPRESSED + compressionInfo.newTokenCount < hard + localPromptTokensAfterCompression >= hard. This catches cases where the compression service's reported token count is optimistic but the local char/4 re-estimate still shows oversized. It's the branch most likely to catch real tokenizer mismatches in production.

Consider adding a third test where compression succeeds with newTokenCount just under hard but the returned newHistory is still large enough that local re-estimation exceeds the hard limit. For example, mock newTokenCount: 176_999 (just under hard) while keeping the 720K-char history content so char/4 estimates ~180K.

— qwen3.7-max via Qwen Code /review

[Suggestion] In the COMPRESSED branch, compressionInfo.newTokenCount >= hardLimit is logically redundant. After tryCompress succeeds, this.lastPromptTokenCount = info.newTokenCount (line ~1404), so localPromptTokensAfterCompression = lastPromptTokenCount + estimateContentTokens(userContent) + imageTokenEstimate. Since the user-content and image estimates are non-negative, localPromptTokensAfterCompression >= newTokenCount always holds. If newTokenCount >= hardLimit, then localPromptTokensAfterCompression >= hardLimit is guaranteed to fire first.

The function could simplify to:

if (!shouldForceFromHard) return false;
return localPromptTokensAfterCompression >= hardLimit;

unless the explicit newTokenCount check serves as a defensive safety net worth documenting.

— qwen3.7-max via Qwen Code /review

[Suggestion] When compression succeeds (COMPRESSED) but the guard still rejects, tryCompress has already called chatRecordingService.recordChatCompression() (line ~1394), writing a compression checkpoint to the JSONL session log. This rollback restores in-memory state (history, lastPromptTokenCount, telemetry) but the JSONL record persists.

On --continue resume, buildApiHistoryFromConversation would use the stale compressed snapshot as the reconstruction base, even though the in-memory session was rolled back. Consider either:

1. Deferring recordChatCompression until after the guard passes (move the call from tryCompress into the caller).
2. Emitting a compensating "compression rolled back" record after the restore.
3. Documenting that this asymmetry is acceptable since the guard re-fires on resume anyway.

— qwen3.7-max via Qwen Code /review

[Suggestion] Tests 2 and 3 both exercise the COMPRESSED-then-restore path but neither asserts chat.getLastPromptTokenCount() after the guard throws. The production code at geminiChat.ts:1622 restores lastPromptTokenCount, but if that line were accidentally removed, these tests would still pass.

Consider adding after the rejects.toThrow(...):

expect(chat.getLastPromptTokenCount()).toBe(0);

For stronger coverage, set a non-trivial value before the send (e.g., chat.setLastPromptTokenCount(50_000)) and assert it's restored — this verifies the round-trip through compression's mutation and back.

— qwen3.7-max via Qwen Code /review

[Suggestion] CompressionStatus is a numeric enum (COMPRESSED = 1, COMPRESSION_FAILED_EMPTY_SUMMARY = 4, etc.). The template literal ${compressionInfo.compressionStatus} renders as a raw integer (e.g., "compression status: 1") in this user-facing error message.

This also applies to the debug log at line 1630 where the same pattern appears.

— qwen3.7-max via Qwen Code /review

[Suggestion] This test uses chat instead of chatWithRecording, so it cannot verify two important invariants that the other COMPRESSED+rollback tests check:

1. recordChatCompression was NOT called (the deferred-record invariant that this PR introduces)
2. History was rolled back to the original pre-compression state

This is the subtlest edge case (compressed history is below hard, but the pending user message tips it over) and the one most likely to regress. If a future change accidentally moves recordChatCompression before the guard, this test would not catch it.

Consider switching to chatWithRecording (same pattern as the "hard-rescue compression is still oversized" test above) and adding:

expect(recordChatCompression).not.toHaveBeenCalled();
expect(chatWithRecording.getHistory()[0].parts?.[0].text).toBe(
  'x'.repeat(720_000),
);

— qwen3.7-max via Qwen Code /review

[Suggestion] The comment says "defer the JSONL compression checkpoint until a guarded send is actually allowed below" — but the code throws at line 1647. There is no "below" that eventually writes the checkpoint; the send is rejected outright.

— qwen3.7-max via Qwen Code /review

[Suggestion] The tryCompress method-level JSDoc (lines 1361-1367) states unconditionally that on COMPRESSED the method "recorded the event to chatRecordingService (if wired)" — but with this new deferChatCompressionRecord option, that's no longer true. When the option is set, recording is intentionally skipped inside tryCompress and deferred to the caller.

Consider updating the JSDoc to note the exception, e.g.:

* history, recorded the event to `chatRecordingService`
* (if wired, unless `options.deferChatCompressionRecord` is set), and

This prevents a future reader of the method signature from assuming the recording always happens inside tryCompress and introducing a double-write.

— qwen3.7-max via Qwen Code /review