Bug: Watchdog reminder causes excessive token amplification (O(N) growth) #7949

Open
opened 2026-02-16 18:08:45 -05:00 by yindo · 1 comment
Owner

Originally created by @baixiangcpp on GitHub (Jan 29, 2026).

Originally assigned to: @thdxr on GitHub.

Description

Summary

The session watchdog reminder logic causes excessive input token consumption by repeatedly wrapping queued user messages in <system-reminder> tags and inlining the full user text on every loop iteration.

When a user sends multiple messages while the agent is busy, the same user content is duplicated into the model input repeatedly, leading to token amplification and rapid context window exhaustion.

Impact

  • Input token usage grows rapidly during long-running sessions.
  • Context window is exhausted much sooner than expected.
  • Inference costs increase significantly.
  • Agent behavior can degrade due to repeated context bloat.

Root cause

In the session loop (watchdog/interrupt handling path), queued user messages (messages sent after lastFinished) are ephemerally rewritten:

  • The user text is wrapped in <system-reminder> XML tags.
  • The full user text is duplicated into the reminder payload.
  • This happens repeatedly on each loop iteration when step > 1.

This makes token growth effectively O(steps × message_length) in busy-loop scenarios.

Reproduction steps

  1. Start a session with any agent that performs a long-running task (tool execution, multi-step reasoning, etc.).
  2. While the agent is busy, send multiple user messages in short intervals.
  3. Observe that each loop iteration rewrites queued user messages with <system-reminder> and repeats the user’s full text.
  4. Monitor input token count / context size: it grows much faster than the actual conversation content.

Expected behavior

  • User messages should remain intact (no rewriting/expanding user text).
  • The system should remind the agent about queued messages without duplicating user content.
  • Reminders should be deduplicated/throttled to avoid repeated injection during busy loops.

Suggested fix

  • Stop modifying user message parts directly.
  • Inject a concise system reminder (e.g., “There are X queued user messages…”) without inlining user text.
  • Add deduplication and throttling (e.g., exponential backoff) to prevent reminder spam.

Related PR

PR: fix(session): optimize system reminder to reduce token usage
https://github.com/anomalyco/opencode/pull/11136

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

Originally created by @baixiangcpp on GitHub (Jan 29, 2026). Originally assigned to: @thdxr on GitHub. ### Description ## Summary The session watchdog reminder logic causes excessive input token consumption by repeatedly wrapping queued user messages in `<system-reminder>` tags and inlining the full user text on every loop iteration. When a user sends multiple messages while the agent is busy, the same user content is duplicated into the model input repeatedly, leading to token amplification and rapid context window exhaustion. ## Impact - Input token usage grows rapidly during long-running sessions. - Context window is exhausted much sooner than expected. - Inference costs increase significantly. - Agent behavior can degrade due to repeated context bloat. ## Root cause In the session loop (watchdog/interrupt handling path), queued user messages (messages sent after `lastFinished`) are ephemerally rewritten: - The user text is wrapped in `<system-reminder>` XML tags. - The full user text is duplicated into the reminder payload. - This happens repeatedly on each loop iteration when `step > 1`. This makes token growth effectively **O(steps × message_length)** in busy-loop scenarios. ## Reproduction steps 1. Start a session with any agent that performs a long-running task (tool execution, multi-step reasoning, etc.). 2. While the agent is busy, send multiple user messages in short intervals. 3. Observe that each loop iteration rewrites queued user messages with `<system-reminder>` and repeats the user’s full text. 4. Monitor input token count / context size: it grows much faster than the actual conversation content. ## Expected behavior - User messages should remain intact (no rewriting/expanding user text). - The system should remind the agent about queued messages **without duplicating user content**. - Reminders should be deduplicated/throttled to avoid repeated injection during busy loops. ## Suggested fix - Stop modifying user message parts directly. - Inject a concise system reminder (e.g., “There are X queued user messages…”) without inlining user text. - Add deduplication and throttling (e.g., exponential backoff) to prevent reminder spam. ## Related PR PR: fix(session): optimize system reminder to reduce token usage https://github.com/anomalyco/opencode/pull/11136 ### Plugins _No response_ ### OpenCode version _No response_ ### Steps to reproduce _No response_ ### Screenshot and/or share link _No response_ ### Operating System _No response_ ### Terminal _No response_
yindo added the bugperf labels 2026-02-16 18:08:45 -05:00
Author
Owner

@github-actions[bot] commented on GitHub (Jan 29, 2026):

This issue might be a duplicate of existing issues. Please check:

  • #7187: Agent stuck in infinite 'SYSTEM REMINDER - TODO CONTINUATION' loop when finishing tasks - This describes the same watchdog reminder looping behavior
  • #10187: Deep clone of entire message history causes 30+ second delay with 200 messages - Related to inefficient session message handling in long sessions
  • #10066: Excessive input token usage with Sonnet on AWS Bedrock - Also describes excessive input token consumption issues

Feel free to ignore if none of these address your specific case.

@github-actions[bot] commented on GitHub (Jan 29, 2026): This issue might be a duplicate of existing issues. Please check: - #7187: Agent stuck in infinite 'SYSTEM REMINDER - TODO CONTINUATION' loop when finishing tasks - This describes the same watchdog reminder looping behavior - #10187: Deep clone of entire message history causes 30+ second delay with 200 messages - Related to inefficient session message handling in long sessions - #10066: Excessive input token usage with Sonnet on AWS Bedrock - Also describes excessive input token consumption issues Feel free to ignore if none of these address your specific case.
Sign in to join this conversation.
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: anomalyco/opencode#7949