Idea: A "dam" for looping reasoning: adaptive buffering, safe interruption, and bounded recovery

[KouzakiUmi]

Summary

I'd like to share an idea and a reference implementation for stopping visible reasoning loops before they consume an entire response: a small adaptive buffer that behaves like a dam, combined with safe call-local interruption and a finite continuation allowance.

Technical reference: https://github.com/KouzakiUmi/dsh-cot-loop-guard

• Detailed design — English
• 详细设计 — 中文
• Validation and limitations

This is a technical reference repository, not an installable plugin or a generic patch kit. I'm sharing the reasoning, source snapshots, and trade-offs for discussion—not claiming compatibility with arbitrary DSH versions or asking users to patch their installations.

The failure mode

Sometimes the model repeatedly says things like “I should read the file”, “execute now”, and “stop looping and use the tool”, but never actually emits the tool call. Sentences reorder, short interjections recur, and longer sentences change slightly.

This is different from repeating an identical tool call: an advisory post-tool reminder may never get a chance to help. Pure exact-copy detection can also miss it because no whole passage is identical. On the other hand, aggressively deleting near-duplicates could destroy legitimate analysis, changed identifiers, counters, or negations.

There is related user feedback about repeated searches in #9180. The focus here is the streamed reasoning/output boundary, including loops that occur before a useful tool call exists.

Proposed mechanism

1. Separate the right to delete from the right to stop

Two detectors have different responsibilities:

• Exact-copy filter: suppress only copies supported by exact original-text evidence. Do not normalize changed numbers, identifiers, or negations into equality.
• Visible-stall detector: use combined recurrence evidence to decide whether a call is stalled. Once confirmed, stop the call and discard only the uncommitted suffix. Do not turn fuzzy similarity into sentence deletion or rewrite text already delivered.

The visible-stall detector observes the original stream, before exact-copy suppression, so it does not depend on how many copies another detector managed to remove.

2. A dam that is normally open

Illustrative reference defaults, measured in UTF-16 code units, not tokens:

Stage	Behavior
Normal	Deliver immediately while observing a rolling window starting at 1024 code units
Suspected	After one qualifying observation, withhold subsequent output and expand the observation window toward 8192
Recovered	Release unproven pending text in order after two consecutive nonqualifying observations
Confirmed	After three consecutive qualifying observations, interrupt and discard the still-uncommitted tail
At the ceiling	Decide using current evidence; do not periodically release an obviously continuing loop just because the buffer filled

The first qualifying observation already counts toward confirmation. Checks occur every 128 code units; these are observations, not three provider chunks or three disjoint full windows. Interruption can happen well before 8192.

In the reference, an observation needs all of:

• At least 16 complete sentence units.
• Recurring-unit occurrence share ≥ 0.5.
• Recurring-unit character share ≥ 0.15.
• Reused exact 8-code-unit fragment coverage ≥ 0.6, with sufficient separation between occurrences.

The character-mass condition prevents a tiny repeated filler from dominating a window whose substantive sentences keep making progress. Hash matches are verified against original characters; hash collisions are not equality.

Fenced code suspends this visible-stall branch. A fence or settlement barrier may also release pending output without proving repetition decreased; that distinction matters for both state naming and UI wording. Released text may still pass through the independent exact-copy filter.

8192 bounds this detector's retained raw window, not total application memory or CPU cost. The exact-copy filter has its own bounded state.

3. Make accepted output the single downstream truth

Filtering must happen before live delivery and durable commit—not merely as a display cleanup afterward.

Accepted reasoning should drive live rendering, the assembled assistant message, persistence, and replay. A completed provider reasoning block must not reintroduce the original unfiltered text and resurrect suppressed copies.

4. Gate editing by the actual adapter capability

Enable the editing policy only when the same prepared call explicitly supports editable plain-reasoning replay. A model/provider name alone is insufficient.

Unknown, signed, encrypted, or opaque replay routes must remain unedited. Dropping signatures to make an incompatible response look editable is not an acceptable fallback. This is about adapter-supplied visible reasoning, not access to hidden model state.

5. Interrupt one call, then recover only within a budget

Use a call-local cancellation signal rather than cancelling and recreating the entire user task:

1. Once the guard decides, publish the real local interruption immediately—before potentially slow iterator/transport cleanup.
2. Abort the current call and await cleanup.
3. Settle only its accepted safe prefix as interrupted; do not execute undispatched tools.
4. If allowed, persist a separately attributed continuation prompt asking for a different approach, then make another call in the same activity.

The reference uses a REASONING_LOOP failure and a dedicated reasoning-loop-recovery message source. The latter is intentionally model-visible, while detection-status notifications are not. The visible-stall continuation says an unconfirmed repetitive tail was discarded; it does not falsely claim every removed character was a proven duplicate.

Recovery is finite per Agent/turn/policy instance: default one continuation; three is a configuration choice, not an unlimited retry loop. Exhaustion remains an error and must not escape into ordinary unconditional retry. Native child agents follow the same bounded principle.

User/parent cancellation, policy disposal, cleanup failure, or rejected settlement must prevent continuation. These counters are in-memory policy state, not a durable cross-process global quota. Local abort also does not prove the provider immediately stopped billing.

6. Respect tool settlement

After a complete real protocol tool block, repetition alone should no longer arbitrarily cancel its settlement. Incremental arguments must never become executable merely because a guard recognized text.

A separate output-volume budget bounds the remaining unfinished settlement. In the reference, exceeding that budget fails the call, dispatches none of its tools, and does not automatically continue. Output-volume limits are not a replacement for an adapter's idle timeout.

Visibility is part of the design

A guard that silently shows “stopped”, replaces the old thinking with new thinking, or reveals its recovery only after switching sessions is hard to trust.

The reference therefore treats these as explicit states:

• suspected repetition → buffering/checking;
• pending text released → continue output;
• confirmed repetition → cutting the call;
• cleanup complete → bounded recovery, with the actual ordinal/limit;
• exhausted budget or user cancellation → the real terminal outcome.

A single notice updates on transitions, not on every token. Presentation stages carry attempt identity/revision, are excluded from model tokens and durable token history, and the latest active stage is included in reconnect state. Actual interrupted settlements and recovery prompts remain durable.

The UI retains earlier interrupted prefixes instead of overwriting them with a later call in the same Step. “Cutting” must be visible before cleanup finishes; “recovering” should not pretend a new request has started before cleanup/settlement permits it.

Evidence and limitations

For the reference publication, 275 related tests across 10 files passed in the original source workspace, covering detectors, policy integration, incremental/replay projection, stream bridging, and plain-reasoning capability boundaries. The repository records source fingerprints and representative tests.

That is not an accuracy benchmark or an independent build of the reference repository. I did not rerun live-model or real-browser interaction validation for the publication. Legitimate repetition and repetition that would eventually self-recover can still trigger early intervention; loops without enough sentence/fragment evidence can be missed. The reference also documents cause-label granularity limits on some protected release paths.

The thresholds are tunable heuristics—not claims of zero false positives, fixed latency, or universal provider support.

Questions for maintainers and the community

1. Would a pre-commit assistant-output policy seam be a useful extension point for DSH, independently of these particular heuristics?
2. How should adapters expose editable replay capability so signed/opaque routes fail closed without relying on model-name lists?
3. Which false-positive, language/terminator, code-scaffold, and CPU-budget cases would be most important before considering broader use?
4. Is the separation between transient detection stages and durable interruption/recovery facts the right observability model?

I would appreciate feedback on the architecture and safety boundaries, rather than suggesting these defaults should simply be enabled for every model.

---

中文简述

我想分享一种“水坝式”可见推理循环守卫：正常立即放行，发现疑似重复后才暂存；证据回落则释放，确认持续循环才丢弃尚未提交的尾巴、取消本次模型调用，并在有限次数内要求换一种方式继续。它把“有证据才能删除精确副本”和“组合启发式可以判断停滞并停止调用”分开，同时保留已显示前缀。

重点不是给所有模型强加自动重试，而是：调用级取消、明确的可编辑重放能力门、工具结算保护、取消优先、有限续跑，以及无需切换会话就能看到的缓冲/放行/截断/恢复状态。

参考仓库仅用于技术交流，包含设计、源码快照和限制说明，不是可安装插件或通用补丁包：https://github.com/KouzakiUmi/dsh-cot-loop-guard

[argszero]

This is the most carefully specified loop-guard design I have read in this tracker, and two of its choices are ones I would keep verbatim:

1. Separating the right to delete from the right to stop. "Only the exact-copy filter removes proven copies" while the stall detector may use combined evidence but may discard only the uncommitted suffix — that is the correct cut, and it is the one most implementations blur.
2. The stall sees the original stream, before suppression. Routing the observer upstream of the copy filter, so detection cannot depend on how many copies another detector managed to remove, is the detail that decides whether a micro-variation loop is caught at all.

One seam note, if this ever becomes installable

Your layer diagram routes through AssistantStreamAttempt, i.e. the agent/assistant-stream event (packages/core/agent-loop/src/agent.ts:449 on Core 0.2.1-rc.2). That event does not exist on dsh 0.1.2-rc.1 — issue #1 on our own guard is the record of that: a v0.1.0 that listened there installed cleanly on rc.1 and silently never fired, which is the worst failure shape a guard can have, because "loaded" and "working" look identical.

llm/stream (packages/llm/llm/src/index.ts:75) exists on both 0.1.2-rc.1 and 0.2.1-rc.2 and carries the same three delta kinds. It is a waterfall around every streaming model call, so a listener still sees chunks in order and can still steer/inject/cancel the live agent via options.sessionId → ctx.agents.get(...). Nothing in your design needs the newer event. If the dam ever ships as something a user mounts rather than reads, that is the seam that covers the wider installed base at no cost in capability.

An installable sibling, in the same space

@argszero/cordis-plugin-thinking-loop-guard — npm latest 0.3.1 (0.3.2 is on GitHub, pending publish). It is a different mechanism from yours: no buffering and no copy suppression; it tallies each call and, on a detected shape, breaks the call and re-fires with a notice rather than latching. So it is a much smaller machine than your dam, and it cannot retract anything because it never withholds — the trade is that its action is coarse (the whole call ends; that is safe only because the loop re-fires and the step is retried).

Where it is directly adjacent to your Purpose 2: the reasoning channel. We measured a collapse shape the visible breaker cannot reach at all — under the deepseek-vision channel with a flash-tier model thinking in Chinese, the thinking block degenerated into self-replication of the shortest standalone sentence (好。好。好。), longest repeated fragment run 7298, the reply swallowed and the session unusable. Two things follow that your document already implies but are worth having as data:

• The visible-output breaker never receives a reasoning delta, and the post-call judgement reads reasoning only after the call has spent its whole budget. An inverted shape: the worst call of the session is the one nothing can interrupt. Pre-commit withholding — your dam — is the only placement that fixes that ordering.
• Count whole units, never substrings. In the reported text the substring 好。 occurred 4 times while the text contained 3 sentence units, because 完好。 ("intact") contains 好。 inside an ordinary word. A substring rule reports repetitions no reader can see; your R_units is defined over whole trimmed units, so it is already on the right side of this — I am citing the case because it is the one that costs a reviewer an hour.

Its per-line claim is measured rather than asserted: npm run test:probe-lines installs each claimed dsh line into its own tree with every dsh peer pinned to that line, then runs tsc and the suite. Twenty-two lines from 0.1.2-rc.1 through 0.2.1-rc.2; 0.1.2-rc.1 re-measured today at 135 tests pass.

The measurement gap you named

Your validation record says plainly that no false-positive rate is given, and that is the honest thing to write — but it is also the number a reader needs before installing anything. For what it is worth, here is how ours is calibrated, since it transfers:

• The nuisance measure is density over whole sentence units (distinct / total), not a repetition count, because the shapes that get reported are not periodic at all: one was twenty sentences cycled in a fixed order (period 489, far past any tail-scan cap) and another was the same twenty in an irregular order, where no period exists.
• Measured: reported loop shapes score 0.0001 and 0.0043; real text — 60 recorded reasoning blocks plus 3,983 long assistant messages from one project's own session history — bottoms out at 0.885, seventeen times above the 0.05 threshold; generated-document negatives (a JSON dump, generated CSS, a markdown table, a log listing) all stay at or above 0.35.
• The unit floor is pinned from both sides rather than chosen: at 8 characters a JSON dump measures 0.35, and at 10 the floor swallows the record ids' shorter neighbours so the same dump measures 0.025 and falsely fires.

The instrument is an offline replayer that reads both durable attempt formats — assistant/chunk for session format v1 (dsh ≤ 0.1.2-rc.1) and assistant/attempt for v2 (dsh ≥ 0.1.5) — and runs the shipping decision rule rather than a transcription, reporting its own parse coverage so that a zero over an unreadable file cannot be mistaken for health. If it would help you publish the numbers you currently disclaim, I am happy to run your thresholds through it on the same corpora, or to describe the corpus shape so you can build the equivalent.

Two things I would like to ask

1. Does the dam govern reasoning characters, or only released visible output? Your data-flow section places VisibleStallWatch under "reasoning output policy" and Purpose 2 is explicitly about CoT contamination, which reads as reasoning; but the thresholds (minUnits, shingleChars) are described in terms of output. The answer changes the failure mode: governing reasoning prevents the contamination at its source, while governing output only prevents the leak.
2. Your ceiling is a decision point, not a stop. When pending reaches maxWindowChars with evidence still positive, you interrupt — and when the call is protected by a real tool block you release and reset instead. What happens to a model that alternates: five qualifying observations, one tool block, five more? The tool boundary resets the state machine rather than the call, so is the loop bounded in practice by the continuation allowance alone, or is there a cumulative budget across resets?

[spacexm406-web]

OSARETIN PRIME — Technical Review

The two questions expose important design boundaries. My recommended resolution is to make the dam an upstream, pre-commit guard with separate reasoning and visible-output policies, and to enforce a cumulative interruption budget that cannot be reset by tool boundaries.

1. Does the dam govern reasoning or visible output?

Recommendation: distinguish the two explicitly.

The design should define two separate enforcement points:

Layer Responsibility Permitted action
Reasoning-stream observer Detect repetition and degenerative patterns in reasoning deltas Flag, count, and trigger intervention
Reasoning pre-commit guard Prevent confirmed pathological reasoning from being committed downstream Withhold the uncommitted suffix and interrupt when necessary
Visible-output observer Detect repetitive user-facing output independently Flag suspicious output patterns
Exact-copy filter Identify and remove proven duplicate units Remove only verified copies
Tool-boundary handler Preserve legitimate tool execution while maintaining loop accounting Release permitted content without erasing cumulative history

The critical distinction is that detecting a problem is not the same as having permission to delete content.

The reasoning observer should operate before the relevant content is committed. However, whether the underlying runtime exposes reasoning deltas to an authorized extension must be verified for each supported version.

If reasoning deltas are inaccessible, the guard cannot honestly claim to prevent reasoning contamination at its source. It can only intervene at a later boundary.

Implementation rule: Never describe a visible-output filter as a reasoning guard unless the reasoning stream itself is observable and the enforcement point is upstream of commitment.

2. What happens when a model alternates between repetitive output and tool calls?

Your example exposes a potential reset vulnerability:

5 qualifying observations → tool block → reset → 5 qualifying observations → tool block → reset

If each tool boundary resets all counters, a model might repeatedly approach the interruption threshold without ever reaching it.

The solution is to separate local detection state from cumulative safety state.

State variable At a legitimate tool boundary
Current repetition window May reset
Local consecutive-observation counter May reset
Total intervention count Must persist
Cumulative suspicious-unit count Must persist
Remaining continuation allowance Must not increase
Overall execution deadline Must not extend automatically
Session-level safety status Must persist until explicitly cleared under defined rules

A tool boundary should be treated as a change in execution phase, not proof that the loop has ended.

Proposed cumulative budget

Track these quantities for each execution:

• B_max: maximum permitted continuation attempts.
• I_max: maximum permitted interventions.
• S_max: maximum cumulative suspicious units.
• T_deadline: absolute execution deadline.
• E_epoch: execution generation, used to distinguish valid state transitions from stale updates.

The guard interrupts when any configured hard limit is exceeded.

Conceptually:

def on_tool_boundary(state):
state.local_window.reset()
# Preserve execution-wide safety accounting.
# Never replenish budgets merely because a tool ran.
if (
state.continuations >= state.max_continuations
or state.interventions >= state.max_interventions
or state.suspicious_units >= state.max_suspicious_units
or now() >= state.deadline
):
return INTERRUPT
return CONTINUE

This is illustrative pseudocode, not a verified implementation against either dsh version.

One additional safeguard matters: a legitimate tool block should not automatically cause pending content to be released if that content has already been classified as pathological. Tool execution and content-release decisions should remain independent.

3. The compatibility seam

The llm/stream event you identified is the stronger integration candidate because your measurements indicate that it exists across both version lines.

Before shipping, verify three things:

1. Compatibility: The observer receives the expected delta types on every supported version.
2. Ordering: Detection occurs before the content reaches the relevant commitment boundary.
3. Control: Cancellation and intervention actually affect the active execution rather than merely recording an event.

A successful installation or passing type check does not establish any of these runtime properties.

The version-specific test should deliberately generate a repetitive stream, confirm that the guard fires, and verify that the offending suffix is not released.

4. False-positive validation

Your corpus-based approach is a useful starting point, but I would distinguish three measurements:

• False-positive rate: The proportion of legitimate test cases incorrectly flagged.
• False-positive density: The number of false flags relative to legitimate units or messages.
• Detection rate: The proportion of known pathological cases successfully detected.

These are different quantities. A low observed false-positive density does not establish a low false-positive rate without a defined sampling method and denominator.

I would test the thresholds against ordinary prose, code, structured output, multilingual reasoning, long documents, periodic loops, irregular repetition, and tool-interleaved loops.

The reported separation between your loop and legitimate-text corpora is encouraging, but the available figures alone do not establish generalization to unseen workloads.

Final engineering decisions

I would lock in these four principles:

1. Observe upstream: Detect repetition before suppression can distort the observer’s input.
2. Separate detection from deletion: Only the authorized exact-copy mechanism removes proven copies.
3. Persist cumulative budgets: Tool boundaries may reset local windows but cannot replenish execution-wide allowances.
4. Verify the real enforcement boundary: Tests must establish that pathological content is actually withheld, not merely detected or logged.

One final architectural question remains: should reaching a cumulative budget terminate only the current model call, or should repeated violations also quarantine the entire session until an explicit recovery action? My recommendation is interrupt the current call immediately, then quarantine the session when a separately configured session-level threshold is reached. This preserves recoverability without allowing repeated retries to defeat the guard.

[KouzakiUmi]

Thank you both for the detailed feedback, especially for identifying the distinction between observing a stream and enforcing a safe commitment boundary.

I would like to clarify several points about the reference implementation and its intended policy.

1. The dam currently governs reasoning

It processes reasoning-delta, not merely the final user-facing text. “Visible” means reasoning actually exposed by the adapter, not hidden model state. The name can understandably suggest a narrower, answer-only scope, so this distinction deserves clearer wording. The pinned policy actively governs only its first selected reasoning index, not every reasoning block in a call.

2. The control seam and notification seam are different

The current implementation obtains its pre-acceptance policy through agent/output-policy. AssistantStreamAttempt and agent/assistant-stream carry accepted output and presentation state downstream. This output-policy seam includes Core changes introduced for the reference; it is not assumed to exist in every unmodified DSH release.

I agree that llm/stream is a valid integration candidate, especially for older installations. However, receiving the same delta types does not by itself establish equivalent call-local cancellation, accepted-prefix settlement, replay eligibility, final-block consistency, or recovery accounting. A middleware implementation may achieve those properties, but they need explicit verification.

This repository remains a technical reference, not a claim of an installable package supporting every DSH release.

3. Tool boundaries do not replenish the current call’s settlement allowance

The allowance is initialized once after the first complete protocol tool block; subsequent events continue spending it. Further tool blocks do not refill it. Within the same installed policy scope and Agent/turn, recovery counting survives creation of another per-call ReasoningOutputPolicy. Reinstalling the policy or restarting the process does not preserve that in-memory map.

The limitation is its scope: settlement allowance is per call, while recovery allowance is per Agent/turn/installed-policy scope. Neither is a session-wide cumulative resource guarantee. Your question usefully highlights that distinction. Multiple normally settled calls that never trigger the guard do not acquire a task-wide resource ceiling merely because recovery is finite.

Content acceptance is a separate trade-off that my earlier wording did not explain fully:

• A previously made interruption is not revoked by a later tool block, and its discarded tail does not return.
• Once tool-protected, pending text may still be released even when repetition evidence reaches the ordinary confirmation threshold. That does not mean the evidence has fallen back. Released text still goes through independent exact-copy suppression; proven suppressed copies are not resurrected.
• This preserves a settlement opportunity for the tool protocol at the cost of potentially admitting more repetitive reasoning. The settlement allowance bounds further consumption; it does not guarantee that all repetitive content stays out of history. Changing that release policy would need separate protocol and settlement validation.

4. User control is the governing principle—not mandatory automation or mandatory quarantine

One interrupted call does not establish that a model or conversation is permanently unrecoverable. A strictly limited continuation can be a useful attempt when the user has enabled it.

The current reference permits bounded automatic continuation, defaults to one recovery, and supports zero recoveries for stop-only behavior. I am not claiming that those defaults have changed.

The intended boundary is that the user chooses whether automatic recovery is allowed and within what allowance. The guard executes the authorized protection; it should not silently acquire authority to compact context, change models, migrate conversations, or quarantine the entire session.

When recovery is disabled or exhausted, an explicit stop and a suggestion to review, compact, or prepare a handoff may be the appropriate outcome. Suggestions should remain suggestions. Additional cumulative limits could be optional policies without making the conversation inaccessible to its user. I understand the session-level threshold proposed above as a separately configurable option, not a requirement to lock every session.

5. Calibration and replay fidelity deserve separate attention

Your corpus measurements and whole-unit counting are useful contributions. I would borrow the evaluation discipline rather than directly transplant numerical thresholds between different statistics.

Your analyzer already updates novelty per reasoning delta and remembers an intermediate threshold crossing; that is useful, and I do not mean that every rule is final-tail-only. For this reference, we also need the data.stream field on assistant/message events, separate attempts even when turn/step match, and each rule’s actual decision positions/cadence. In particular, a final periodic-tail statistic is not equivalent to reproducing intermediate decisions.

There is also an input-evidence boundary: persisted streams are already accepted output. Adding format support cannot recover a tail the guard withheld or discarded. Post-guard records can verify prefix/recovery persistence; original detector positions, withholding and premature-interruption evaluation need complete ordered pre-guard input or controlled synthetic streams, including later content when testing whether a sample would have recovered. A useful collaborative next step would be to align a small de-identified, attempt-aware fixture format before comparing thresholds. Sharing additional real traces remains a separate privacy/authorization decision.

On our side, this review also exposed a concrete coverage issue: the current sentence-unit metric does not treat ASCII periods as terminators. That needs targeted evaluation, without implying that the separate exact-period detector also fails.

Follow-up: standalone experimental prototypes and tests now explore sentence boundaries, explicit user-authorized recovery and per-attempt replay. The 104 passing checks include 24 historical-integrity checks. These are not integrated Core fixes: the original 23 source snapshots and fingerprints remain unchanged.

Overall, I see these approaches as adjacent rather than interchangeable: proactive stop-loss, optional bounded recovery, and user-directed next steps. The aim is to preserve options before repetitive reasoning consumes the remaining context and resources—not to take ownership of the user’s task.

[SeanTolstoyevski]

An LLM’s memory is fundamentally its context window, the tokens it has generated. If you arbitrarily truncate a portion of a model's CoT, you induce amnesia regarding that pruned information, leading to the following state:

50 lines of clean CoT + synthetic recovery draft message

Left in this state, the model is blind to what went wrong. It will question its own context:
What did I actually repeat? What was the failure mode? I was just reading file Y in project X...

Because it lacks the negative trace of its failed attempt, it cannot understand why the execution was interrupted, making it prone to retrying the exact same dead-end hypothesis from scratch.

A viable way to address this would be offloading the repetitive context (along with relevant runtime signals) to a secondary, lightweight LLM to synthesize a concise failure summary or re-anchor the task focus (e.g., "An attempt to inspect file Y stalled; do not retry that path").

Manipulating the CoT through blind truncation severely degrades the model’s continuity, inducing context deformation and triggering self-questioning loops that defeat the purpose of the recovery mechanism.

[KouzakiUmi]

An LLM’s memory is fundamentally its context window, the tokens it has generated. If you arbitrarily truncate a portion of a model's CoT, you induce amnesia regarding that pruned information, leading to the following state:

50 lines of clean CoT + synthetic recovery draft message

Left in this state, the model is blind to what went wrong. It will question its own context:
What did I actually repeat? What was the failure mode? I was just reading file Y in project X...

Because it lacks the negative trace of its failed attempt, it cannot understand why the execution was interrupted, making it prone to retrying the exact same dead-end hypothesis from scratch.

A viable way to address this would be offloading the repetitive context (along with relevant runtime signals) to a secondary, lightweight LLM to synthesize a concise failure summary or re-anchor the task focus (e.g., "An attempt to inspect file Y stalled; do not retry that path").

Manipulating the CoT through blind truncation severely degrades the model’s continuity, inducing context deformation and triggering self-questioning loops that defeat the purpose of the recovery mechanism.

I disagree with the technical premise behind this objection. The guard’s objective is to limit the accumulation of repetitive reasoning so that the remaining context can support useful work. Recovery does not inherently require the model to first diagnose its own previous generation.

1. Context dependence does not imply a requirement to reconstruct the interruption.

In the autoregressive inference path being discussed, subsequent tokens are generated conditionally on the supplied context: "P(next token | current context)". That context includes instructions, task information, intermediate reasoning, and tool results—not merely text the model previously generated. This is the basic "autoregressive mechanism" (https://arxiv.org/html/1706.03762v7#S3).

CoT can function as a scratchpad that carries intermediate computations forward, as demonstrated in "Show Your Work" (https://arxiv.org/abs/2112.00114). That explains why useful intermediate state matters. It does not establish that every generated passage must be retained, or that omitting part of a stalled generation necessarily causes confusion and renewed looping.

The relevant question is whether the retained context contains the information needed for the next valid action. A requirement to reconstruct why the model previously stalled does not follow from the architecture.

2. A failed generation is not automatically corrective feedback.

Calling a passage a “negative trace” does not make it an effective negative example. Reintroducing it supplies additional conditioning text; it does not automatically penalize the behavior that produced it. Whether the model uses it to correct course or continues the same unproductive pattern depends on the content and the model.

There is empirical evidence for the latter risk: "Learning to Break the Loop" (https://proceedings.neurips.cc/paper_files/paper/2022/hash/148c0aeea1c5da82f4fa86a09d4190da-Abstract-Conference.html) found that, in the models and settings studied, increasing previous sentence repetitions in context increased the probability of further repetition. This does not prove that a concise summary would worsen this guard’s recovery, but it does invalidate the assumption that preserving more of the failed narrative necessarily helps.

Context is a finite working resource. Recovery material should earn its place by helping the model carry out the task.

3. A stalled generation does not establish a failed task approach.

Your file-inspection example makes this distinction especially important. If the model repeatedly says it will read file Y but never dispatches the tool call, the execution record does not establish that reading Y failed or that this approach is a dead end. Reading Y may still be exactly the next action required.

A summary that tells the model not to take that path would introduce an unsupported task constraint.

I understand that you propose a second model producing a concise summary, including runtime signals. However, compression does not validate a diagnosis. "CoT explanations can misrepresent the reasons for a model’s prediction" (https://arxiv.org/abs/2305.04388), and another model’s interpretation of those explanations is not automatically a reliable account of what failed. Verified execution facts and speculative explanations need to remain distinguishable.

4. The retained prefix is not the clean history assumed in your example.

As "the design explicitly documents" (https://github.com/KouzakiUmi/dsh-cot-loop-guard/blob/main/docs/DESIGN.en.md), detection requires accumulating evidence, so early repetitions may already have entered the accepted prefix. That prefix is not retrospectively sanitized. The guard discards an uncommitted suffix when it intervenes, retains accepted history and existing tool records, and supplies an explicit interruption reason.

I acknowledge that an intervention can lose useful pending information. That is a real trade-off to evaluate. But it is different from assuming that recovery requires preserving or reconstructing the entire failure narrative.

A summary grounded in actual execution evidence may be worth testing as an optional recovery policy. Its value should be demonstrated through useful progress, reduced recurrence, information preservation, and total cost.

The design is intended to protect the context needed to continue working. Requiring a generated explanation of the stall as a prerequisite for recovery is an additional proposal, not a requirement imposed by how CoT works.

[KouzakiUmi]

Additional technical context: self-reinforcing loops and KV-cache feedback

I would like to add one further technical point to my previous reply. The concern is not merely that repetitive CoT wastes context tokens. Repeated generation can become self-reinforcing through the model's own conditioning and attention dynamics.

This is not just a theoretical possibility. Several studies have investigated the mechanism directly.

1. Repetition can reinforce its own continuation.

Xu et al., Learning to Break the Loop ("NeurIPS 2022" (https://proceedings.neurips.cc/paper_files/paper/2022/hash/148c0aeea1c5da82f4fa86a09d4190da-Abstract-Conference.html)), experimentally found that repeated sentences in context can increase the probability of generating those same sentences again.

The relevant implication is that previously generated text is not automatically corrective evidence. Under the studied conditions, additional repetitions strengthened the behavior that produced them.

2. Reasoning loops can involve attention-level positive feedback.

Duan et al., Circular Reasoning: Understanding Self-Reinforcing Loops in Large Reasoning Models ("arXiv:2601.05693" (https://arxiv.org/abs/2601.05693)), identify a failure mode in which generated reasoning becomes a premise for its own recurrence.

Their analysis finds that semantic circularity can precede literal repetition, and that attention concentrated on recent repetitive content can sustain the cycle.

This matters because pathological reasoning is not necessarily just redundant text. It can be part of a self-reinforcing generation trajectory.

3. KV-cache dynamics provide a more concrete account of loop persistence.

Xu et al., LoopGuard: Breaking Self-Reinforcing Attention Loops via Dynamic KV Cache Intervention ("arXiv:2604.10044" (https://arxiv.org/abs/2604.10044)), report that attention heads can become concentrated on narrow repetitive suffixes. Reusing the corresponding KV states during decoding can stabilize this degenerate pattern, while attention-based cache-retention policies may further amplify it.

Their experiments show that targeted removal of repetitive KV-cache tail spans can substantially reduce loop incidence under their benchmark conditions.

Two mechanisms must be distinguished here:

• Within a generation: repetitive tokens and their cached representations continue participating in subsequent attention computations, potentially sustaining a feedback loop.
• Across generation attempts: when repetitive CoT is retained in conversation history and supplied again, those tokens condition the next generation. Their KV representations may be recomputed during prefill or reused through an implementation-specific caching mechanism.

The second case does not require literal reuse of the same KV-cache allocation across calls. The relevant risk is reintroducing the same pathological conditioning content.

These studies do not establish that every repeated passage causes a loop, or that every shortened context improves recovery. Nor do they prove that a concise, independently generated failure summary necessarily causes recurrence.

However, they provide a concrete reason not to assume that preserving or reintroducing pathological reasoning is inherently beneficial to continuity.

My guard operates at the Harness output-acceptance boundary, not inside the model's attention implementation. It does not directly manipulate KV caches or claim to repair the model's internal dynamics. Its narrower purpose is to limit how much pathological reasoning is admitted into durable history, while preserving accepted task context and tool records.

A secondary model may still produce a useful recovery summary, particularly when it can rely on verified execution events rather than speculative interpretations of CoT. That is a valid optional mechanism to evaluate.

But such a summary must be judged by its effect on subsequent execution—not by assuming that a model needs a reconstructed account of its previous generation to function.

The engineering question is whether the proposed recovery material improves task progress and reduces recurrence without introducing unsupported constraints or unnecessary conditioning.

That requires comparative evidence. It is not a requirement implied by CoT or KV-cache mechanics.