

















One pattern we keep seeing: teams set a max budget or max iterations, but the expensive part usually starts earlier, when the agent keeps retrying without new evidence.
A better stop rule seems to be: before another retry, the agent should show what changed, what verifier passed, and what would make the next attempt stop.
MartinLoop solves the messy part of AI coding agents: they move fast, but they can also loop, waste tokens, change the wrong files, and leave you unsure what happened. MartinLoop adds budgets, safety checks, rollback, and receipts so every run is controlled, explainable, and easier to trust.
The next improvements are a cleaner team dashboard, more agent integrations, stronger run analytics, and better cost reporting so teams can see exactly where AI agent spend is creating value or waste. (It's on the roadmap, coming soon)
The alternatives are mostly coding agents, IDEs, observability tools, or internal scripts. They help generate code or inspect activity, but MartinLoop was built specifically to control agent runs before they become expensive, messy, or unsafe.
Found MartinLoop through a thread on Hacker News where someone was venting about a Claude Code run that estimated $2.40 and ended up burning $65 in retries before they noticed. Felt that pain personally so I clicked through and gave it a try. Spent the last 2 weeks running it as a wrapper around my Codex and Claude Code workflows for a side project. The whole "give the agent a finish line" concept clicks immediately when you've ever watched an agent loop on itself overnight.
The killer features for me are the hard budget caps and the verifier gates. You set a dollar limit before the run, point it at your test suite (like npm test), and the agent stops when it hits either the budget or a clean verifier pass. No more "wake up to a $300 OpenAI bill because the agent kept retrying a typo." The JSONL run records are also surprisingly useful when something does go sideways. You get a clean receipt of what changed, what passed, what failed, and exactly where the spend went.
Where it gets rough: setup is CLI-only right now, no hosted dashboard yet (it's on the waitlist for Pro tier). Side effects that escape the repo boundary, like DB migrations or external API calls, still need manual fencing through safety policy. Not a deal breaker but you do need to think about scope upfront. Apache 2.0 license and npm install -g martin-loop to get started means there's zero friction to try it. For anyone running coding agents in production or even just for side projects, this fixes a real problem that nobody else is addressing seriously
The biggest gap right now is the dashboard. CLI-only is fine for solo devs but engineering managers and finance teams need a visual way to see cost trends, run history, and per-agent ROI without parsing JSONL files. Side effect handling beyond the repo (migrations, external APIs, third-party calls) also needs more native policy controls rather than relying on operators to manually fence everything off. And honestly, the moat could be stronger if MartinLoop became the standard run record format that CI/CD pipelines and billing systems all plugged into. Right now it's a really sharp CLI tool, but the leap to "industry standard control plane" requires winning that integration battle fast before someone else commoditizes it.
The verifier gated admission rule is the part that separates this from a spend cap with a nicer dashboard. Capping tokens is easy. Refusing the next attempt until something actually changed is the rule that kills the “busy” loops. Where I would push: rollback evidence and a JSONL trail are clean when the only artifact is a file diff, but a real coding run also fires migrations, seeds data, and calls external APIs that git cannot undo. How does MartinLoop treat side effects that escape the repo boundary? Does the safety policy let me declare which actions are irreversible so the gate refuses to even attempt them unattended, or is fencing those off still on the operator?
@zimasilevuyo
That’s exactly the right push. Git rollback is only half the story.
The real danger is everything that escapes the repo: migrations, writes to external services, secrets use, emails, payments, queue publishes.
Our view is that those need to be declared up front as action classes, not discovered after the fact. Then the runtime can do three things: block some classes entirely when unattended, require explicit approval for others, and leave a receipt for the ones it does allow so you can reconstruct what happened later.
So no, I would not treat repo rollback as enough. The safety layer has to know which side effects are reversible, which are recoverable, and which are simply too risky to run on autopilot.
@zimasilevuyo Good question. Today MartinLoop can gate migrations, config and dependency changes, destructive commands, and outbound network access. Repo changes also get rollback evidence.
For arbitrary external writes, enforcement still depends on the runtime or integration boundary.
We want to make irreversible actions explicit so MartinLoop can refuse them unattended before they happen.
@artstavenka1
both.
The JSONL captures the full governed run, including rejected/blocked paths, failed verification attempts, and the final committed path.
That way you can see not just what shipped, but what the agent tried along the way and why certain paths were stopped.
we've shipped over 30+ releases since we launched, so its much improved and lot better now, still open source.
This is cool. Personally, I think I just built trust over time with the tools as I learned how to better use them and slowly started to run them for longer sessions and then progressed to overnight. I wouldn't say I've been tracking the cost (although perhaps I should do more of that) as much as the quality that I see. So if an agent went off course for a long run, I try to understand what happened and update my control plane around it for future runs to mitigate that in the future. I do think this is a nice additional layer to have.
@lavaman131 That makes a lot of sense. Most people build trust exactly that way, by extending the leash as the agent proves itself.
What we are trying to add is a system around that learning. When a long run goes wrong, MartinLoop gives you the evidence to see why, then lets you tighten the rules so the same failure is less likely next time.
Cost matters, but quality and repeatability are the bigger goal.
One thing I would genuinely love feedback on from launch-day testers: what proof would you want before trusting a coding agent overnight? Budget receipt, verifier result, rollback path, or a file-level diff trail? MartinLoop is built around making those runs inspectable instead of just fast.
Good question. The useful receipt should show both the committed path and the rejected ones. If you only keep the final successful branch, you lose the story of why the run got expensive or risky. The operator should be able to see which paths were blocked, which verifier failed, and why the next attempt was or was not admitted.
One lesson from testing coding agents: cost usually spikes after the first failure, not before it. If the agent can't show a receipt for done, the next retry should get harder, not easier: cap the spend, require a verifier check, and stop when the same mistake repeats. If you've seen a failure mode we should test before launch, I'd love that feedback.


thanks Nolan, yes we're shipping at a fast clip right now over 40+ releases in less than 60 days, and we do have the dashboard and some great new features coming that other teams have asked for, look out for it soon or sign up on the website for updates when it launches. martinloop.com