Ask HN: How are you keeping AI coding agents from burning money?

My agents retry a bit more than it should, and there goes my bill up in the sky. I tried figuring out what is causing this but none of the tools helped much.

and the worse thing for me is that everything shows up as aggregate usage. Total tokens, total cost, maybe per model.

So I ended up hacking together a thin layer in front of OpenAI where every request is forced to carry some context (agent, task, user, team), and then just logging and calculating cost per call and putting some basic limits on top so you can actually block something if it starts going off the rails. It’s very barebones, but even just seeing “this agent + this task = this cost” was a big relief.

It uses your own OpenAI key, so it’s not doing anything magical on the execution side, just observing and enforcing.

I want to know you guys are dealing with this right now. Are you just watching aggregate usage and trusting it, or have you built something to break it down per agent / task?

If useful, here is the rough version I’m using : https://authority.bhaviavelayudhan.com/

3 points | by bhaviav100 5 hours ago

4 comments

  • maxbeech 21 minutes ago
    the retry loop problem is distinct from the cost-per-token problem and most tooling conflates them.what's helped: track wall-clock time per meaningful step, not turn count. if the agent hasn't produced a file change or git diff in N minutes, it's stuck - not thinking. token count just tells you it's running; it doesn't tell you it's looping.the other piece: watchdog lives outside the agent process so a hung agent can't block its own shutdown. a hung agent shouldn't be able to veto its own termination.i built something for this actually - openhelm.ai schedules and runs claude code jobs with per-run timeouts and status checkpoints. the checkpoint pattern (agent writes state at each major step) is what gives you "where did it get stuck" not just "it failed at some point".
  • DarthCeltic85 4 hours ago
    I had gotten a student/ultra code for antigravity promo for three months, so I was using that, but that finally ran out this month. Currently Im using windstream and flipping between claude as my left brain and code extraction and the higher context but cheaperish models there.

    honestly though, im getting to a point where im running custom project mds that flip between different models for different things, using list outputs depending on what it finds and runs. (I have two monorepo projects, and one thats a polyglot microengine that jumps using gRPC communication.)

    The mds are highly specialized for each project as each project deals with vastly different issues. Cycling through the different pro accounts and keeping the mds in place over it all is helping me not kill my wallet.

    [-]
    • bhaviav100 4 hours ago
      hmm interesting model routing + specialized MDs makes sense for cost efficiency.

      I’m seeing a different failure mode though that even with good routing, agents are looping or retrying and burning my money.

      [-]
  • rox_kd 4 hours ago
    In what settings do you mean - there are multiple strategies, I think building your own compaction layer in front seems a bit over-kill ? have you considered implementing some cache strategy, otherwise summary pipelines - I made once an agent which based on the messages routed things to a smaller model for compaction / summaries to bring down the context, for the main agent.

    But also ensuring you start new fresh context threads, instead of banging through a single one untill your whole feature is done .. working in small atomic incrementals works pretty good

    [-]
    • bhaviav100 4 hours ago
      yes, compaction and smaller models help on cost per step.

      But my issue wasn’t just inefficiency, it was agents retrying when they shouldn’t.

      I needed visibility + limits per agent/task, and the ability to cut it off, not just optimize it.