/goal evaluator has no circuit breaker — unsatisfiable conditions burn unlimited tokens
Problem
The /goal evaluator runs after every assistant turn with no iteration limit or circuit breaker. If the goal condition becomes unsatisfiable, the evaluator fires indefinitely. Only the user can clear it with /goal clear. The assistant cannot clear or modify a goal programmatically.
Incident
A /goal was set to find a specific genealogy source online. After exhaustive searching, the source turned out to already be documented. The user acknowledged this in conversation ("it was probably the burial and we never got the death") but didn't run /goal clear. The evaluator kept firing the same "condition not satisfied" feedback on every turn for 200+ iterations over 5 hours, consuming approximately 50% of weekly token budget. Each turn processed the full conversation context even though the assistant produced empty responses.
Root cause
- No max-iteration limit on goal evaluation
- No detection of repeated identical evaluations
- No way for the assistant to clear or modify a goal
- No automatic escalation or warning to the user after N failed evaluations
Suggested fixes (any of these would help)
- Max iteration config: Add a configurable max evaluation count (default ~20). After N consecutive "not satisfied" results, auto-clear the goal and notify the user.
- Duplicate detection: If the evaluator returns the same reason N times consecutively (e.g., 5), auto-clear with a warning.
- Allow assistant to clear goals: Let the assistant call a tool or command to clear an unsatisfiable goal, perhaps requiring explicit justification.
- Turn limit syntax: Support
or stop after N turnsin the condition (reportedly works already but isn't prominently documented). - Budget guard: Halt goal evaluation if token spend in the current session exceeds a configurable threshold.
Workaround
The only current workaround is for the user to remember to run /goal clear. This fails in practice because:
- The user may step away after setting the goal
- The distinction between
/goaland/loopis not obvious -- "stop the loop" doesn't clear a goal - The assistant cannot intervene
Environment
- Claude Code CLI
- Model: claude-opus-4-6 (1M context)
- Platform: Linux
4 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Workaround that worked for me on a similar /goal loop a few weeks back: a Stop hook that compares the last N evaluator outputs and exits 2 if they're all identical. Bounds the worst-case spend to N × per-turn-cost. Not a fix (the runtime still has no iteration cap), but it's the only thing I've found between a stuck
/goaland the bill.The dedup-bot flagged this as duplicate of #58348 / #58465 / #58334, but the mechanisms are different. #58348 is skill-resolution-driven (loop because a referenced skill doesn't resolve). #58465 is post-approval-driven (loop continues even after the user approves an override). #58334 is
/goal clearitself being broken. Yours is specifically about cost amplification when the evaluator behaves "correctly" by spec, just without an iteration limit. Different roots, same missing circuit breaker.Worth keeping open separately, IMO — the cost-quantification framing (200+ iterations, 5 hours, 50% weekly budget) is the contribution. If it auto-closes as a dupe of the mechanism failures, the cost angle gets lost.
This issue was fixed as of version 2.1.143.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.