Repository navigation
Cline spent $20+ across multiple sessions going in circles without resolving visual glitch — introduced broken code along the way #9816
Description
Plugin Type
VSCode Extension
Cline Version
3.72.0
What happened?
User asked Cline to diagnose and fix visual glitchiness/stutter in a React Native carousel animation (react-native-reanimated-carousel with parallax transitions). Across multiple sessions (costing $15+ in a prior session, then $20+ in this continuation session), Cline made numerous changes but:
- Never resolved the original issue — the visual stutter/glitch during movie playback transitions persisted after all changes.
- Introduced broken code — In the process of optimizing, Cline changed
useAtomtouseSetAtomforshowControlsAtomandcurrentSlideIndexAtombut left multiple references to the now-nonexistent reactive variables (showControls,currentSlideIndex) throughout the file, breaking TypeScript compilation. - Required a continuation session just to fix its own mistakes — This session was entirely spent fixing broken references that Cline itself introduced in the previous session, rather than making progress on the actual glitch.
- Excessive token consumption on tangential work — Much of the cost went to: removing debug console.logs, extracting analytics hooks into isolated components, cleaning up atom subscriptions — all reasonable optimizations but none of which addressed the core visual stutter the user reported.
What the user expected: A focused diagnosis of the visual glitch root cause and a working fix, ideally within a single session at reasonable cost.
What actually happened: Multiple expensive sessions of incremental changes, broken intermediate states, and the original problem remaining unresolved.
Steps to reproduce
- Ask Cline to fix a complex visual performance issue (e.g., "check these logs, what could be causing the glitchiness?" in a React Native carousel playback feature)
- Cline begins making changes across multiple files (debug log cleanup, render optimization, atom subscription changes)
- Cline partially completes changes — e.g., changes
useAtomtouseSetAtombut doesn't update all references to the removed reactive variables in the same file - Session runs out of context window (80%+ used)
- Continuation session is needed just to fix Cline's own broken code from the previous session
- Original issue (visual glitch) still not resolved after $20+ spent across sessions
Provider/Model
cline / google/gemini-3.1-pro-preview
System Information
Cursor: 1.105.1, Node.js: v22.22.0, Architecture: arm64
Activity
linear commentedon Mar 15, 2026
CLINE-1535
Sagargupta16 commentedon Mar 16, 2026
This is a common pain point with AI coding tools burning through tokens in loops. While this is a Cline-specific issue, many of the same cost optimization principles apply across tools:
I maintain a collection of cost optimization strategies for Claude-based coding tools that covers these patterns in detail: https://github.com/Sagargupta16/claude-cost-optimizer
The cheatsheet has 15 ranked strategies by impact: https://github.com/Sagargupta16/claude-cost-optimizer/blob/main/cheatsheet.md
disarticulate commentedon Mar 18, 2026
There does need to be some kind of agent/tool call that evaluates the context to give a determination by another LLM. Something like a
tailcall; or perhaps a simple CPU-efficient RAG based vector model that keeps a running vectorized input/output/diff of the session and if it determines some cosine similarity, it ejects/rejects context and asks for user direction.But as @Sagargupta16 states, this is just what an LLM is; a real life example are ant death spirals. Language is tricky and it's easy to loop through failed tasks.
I'd say that auto-compaction needs an auto-kill-loop companion that attempts to identify these switchback loops and automatically adds some negative context to the user's command to avoid. Perhaps .clinerules ephemeral to a given task. Similar to how StableDiffusion can use negative prompts.
Keep in mind though, at a high level, this is just the halting problem.
raye-deng commentedon Mar 19, 2026
This is a pattern we see more and more with AI coding agents: the agent "helpfully" refactors surrounding code while trying to fix the original issue, and introduces regressions that look clean in isolation but break when you look at the full file.
In this case, switching
useAtomtouseSetAtomis a valid optimization in isolation — but leaving dangling references toshowControlsandcurrentSlideIndexthroughout the file is exactly the kind of cross-reference inconsistency that humans catch in code review but AI agents consistently miss.The frustrating part is that traditional quality gates do not help here either. ESLint would not flag it (the variables were still in scope from somewhere). TypeScript might catch it eventually, but only if the type narrowing is strict enough. SonarQube has no rule for "this variable was just orphaned by an AI refactor."
We have been working on detecting this specific class of failures — where AI-generated changes pass surface-level checks but introduce cross-file or cross-reference inconsistencies. The pattern is surprisingly common: AI tools optimize one thing and silently break three others because they lose context across the file.
For anyone wanting to add a safety net for this kind of issue:
npx @opencodereview/cli scan . --sla L1— it specifically checks for context-drift patterns that traditional linters miss.feat: add doom loop detection for repeated identical tool calls
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection
feat: add repeated tool call loop detection (#9933)
ClineXDiego commentedon Mar 24, 2026
Thanks for the report. PR #9933 was just merged — it adds loop detection for repeated identical tool calls, which should help prevent the kind of circular behavior you experienced. Expect the fix in the next release. Feel free to reopen if you still see it after updating.
feat: add repeated tool call loop detection (cline#9933)