(feature) death loops and what can we do about them

[Zireael]

Description

Death loops happen to the best of us, but is there anything we can do to minimize risk of their appearing and mitigate impact?
Could this user save some money in the future if he starts using AFT/Magic Context?
https://www.reddit.com/r/cursor/comments/1szupca/agent_got_stuck_in_a_loop_and_spent_over_2000_in/

Usually it's model and/or harness issue, but I think there are ways to address the symptoms at plugin level

Have a look at this initial draft with some ideas:
aft-magic-context-loop-governor-prd-v2.1.md
Implementation plan graph:
aft-magic-context-loop-governor-beads-v2.1.json

Use case

Preventing, detecting and/or mitigating death loops.

[cschanhniem]

Two concrete detection signals that might fit at plugin level:

Repeated tool-call fingerprinting: hash (tool_name + normalized_args) for each step. If the same hash appears 3+ times within a sliding window of N steps, that's a strong loop signal. Normalized args matters — strip line numbers and timestamps so near-identical writes don't evade the check.

Output convergence check: compare the file (or AST node) being written across the last K edits. If the diff between edit N and edit N-2 is near-zero (or identical), the agent is thrashing in place.

For mitigation, a graduated response beats hard abort: warn on first detection, inject a brief summary of what's been attempted on second detection, and halt with a structured error on third. The structured error can include the loop trace so the user (or a supervising agent) can decide next steps rather than losing session context entirely.

The PRD mentions budget checks — pairing that with a token-spend rate alarm (spend/turn > threshold) would catch runaway loops that aren't syntactically identical but are semantically stuck (e.g., regenerating different but equally wrong code).