For those who want docs it is at https://moven.dev/docs
so this is a weird origin story but bear with me. last month i was in a physics lecture, half asleep, and the prof is up there drawing copper wires talking about how fuses melt on purpose so your house doesn't burn down when current spikes. and my brain just... wandered off to two days before that when i left an agent running and went to get coffee.
came back and it had called read_file with the literal exact same params 47 times in a row. 47! if you're running gpt luna or bs or sonnet for stuff like this you already know how fast that adds up. it's not like it errored out either, it just sat there happily burning money.
and that's when it clicked — there's no fuse for this. max_iterations = 25 is basically just "let it waste 24 calls before i notice," it's not actually protecting you in real time. so if your agent starts calling the same tool with the same args 5 times in 10 seconds, why is nothing stopping that immediately?
anyway couldn't stop thinking about it so i built moven. open sourced it.
it's a sync wrapper you drop around your tool calls (moven-sdk), sits in the hot path and runs a handful of checks in under a ms before anything actually executes. the main things it does:
works fully local if you don't want a backend involved at all. there's also a dashboard if you want live traces / replay, that part's optional though.
if you want to poke at it:
npx moven-ai-cli init
or just
npm install moven-sdk
site's here: https://moven.dev sdk repo: https://github.com/Moven-AI/moven-node-sdk cli repo: https://github.com/Moven-AI/Moven-CLI
genuinely curious if anyone else has had an agent go off the rails like this, feels like it has to be a common problem. also happy to get roasted, first real open source thing i've shipped so i'm sure there's stuff to fix.
For those who want docs it is at https://moven.dev/docs
Sir, this is a subreddit for local ai.
[deleted]
Fair point, the cost angle doesn't really apply if you're not paying per token. For local it's more about the loop itself: agent stuck calling the same tool 47 times still means your GPU is pinned and hot for no reason, and if it's a longer running setup that's real time and power wasted for zero progress. The repeat/no-progress detection is the part that's actually relevant here, the dollar ceiling stuff was really aimed at API users. Should probably make that clearer instead of leading with cost.
My local agent sometimes does the same call 37 times, and I'm just watching and saying: "It's gonna snap out of it anytime". I mean, time is money.
Agent harnesses already does it by default but I may be wrong
You're right that some agent loops already have step caps, and a few frameworks catch basic repeats. What most don't have is a short sliding window (5 identical calls in 60s trips it, not "25 steps total"), an actual dollar cost ceiling instead of just a call count, and a cheaper-model fallback instead of just killing the run. If your setup already does all that you probably don't need this, genuinely. Mostly built it after max_iterations let an agent burn through 47 identical calls before anything noticed. Curious what harness you're using if it already handles this well.
Any decent harness has some heuristics to detect a tool calling loop. Your “time window” based approach seems a bit too defensive unless you’re comparing tool response hashes as well.
It does compare response hashes, that's the no-progress check I mentioned in the original post, might not have come through in this thread. It's separate from the sliding window one. Window catches identical args back to back, hash check catches the case where args vary slightly but the tool keeps returning the same or equivalent output with no actual progress. Both run together. Curious what you'd consider a better signal though, if there's something more reliable than output hashing I'd rather use that.
Max_tool_rounds not same thing?
No, max\_tool\_rounds is just a hard ceiling on total calls, it doesn't know or care if those calls are actually repeats. You can hit a loop at call 3 and it'll still let you burn through the other 22 before it stops you, or you can have 25 totally legitimate calls and it kills the run anyway even though nothing was wrong. The window check is specifically looking at whether the same tool with the same args is firing repeatedly, and the hash check is looking at whether the output is actually changing. Both are trying to catch "this is stuck" as early as possible instead of just "this has happened a lot."
Yeah, fair, this might genuinely be redundant if your harness already does response-hash comparison on top of a step cap. I built this scratching my own itch, not because I did a survey of every harness out there. If it turns out this is standard already, that's on me for not checking closer before posting, appreciate you all pushing on it.
The output state hash that detects "moving but not progressing" is the right idea , most loop detectors only catch identical tool calls, but agents frequently loop with slight parameter variation while making zero real progress on the task
Violates Rule Four: Self-promotion Probably violates Rule Three: LLM-generated content without disclosure or justification given.