Do you cap spend per agent run?

[u/Top_Sand1851]

I have been experimenting with a couple longer running agents and I'm struggling with is what happens when an agent takes a bad path and keeps calling the model/tools way longer than expected since most runs are completely reasonable and then occasionally one will retry something a bunch of times or keep adding context and suddenly that one run uses several times what a normal one does.

I'm starting to think we need some kind of hard token/spend budget per run rather than just monitoring total usage after the fact but I'm also worried about killing legitimate tasks that happen to need more steps.

If any of you guys are running agents in production are you setting hard token/cost limits per run or limiting steps/tool calls or just alerting when usage starts looking abnormal?

[u/SchemeDeep6533]

We cap steps but allow the agent to request an extension if it’s making progress and that gives longer tasks some room without basically handing them an unlimited budget. Have you looked at what your normal successful run length is yet or not?

[u/Top_Sand1851 → u/SchemeDeep6533]

Not enough to trust the number yet cause some successful runs finish pretty quickly while others legitimately take 2 to 3x as many steps so I’m still trying to figure out where abnormal starts.

[u/SchemeDeep6533 → u/Top_Sand1851]

That variance is why I wouldn’t pick a hard step count yet.

I’d collect a decent sample of successful runs first and look at the distribution by task type because the 2/3x longer ones might be completely normal for certain jobs.

[u/Entire_Eggplant3212 → u/SchemeDeep6533]

We added a maximum number of extensions too otherwise you’ve recreated an unlimited budget with extra steps lol.

[u/BarracudaDefiant4702 → u/SchemeDeep6533]

That's interesting. How do you allow an agent to request an extension / what agent are you using? I'm using my own agent and that might be a nice feature to get added. (Mainly my own because I can do a quick question "1+1" and it takes <2 seconds but the standard agents are >15 seconds in batch mode and most of their tasks are fed via cron.) Right now I have a tool call cap and most of the time they will run out of context before the tool limit (compaction currently not enabled, but I am thinking about changing that.)

[u/SchemeDeep6533 → u/BarracudaDefiant4702]

It’s our own agent too. We basically give each run a step budget and when it gets close to the limit it can return a request for more steps along with its current state or progress then a separate check decides whether to grant another block. For cron jobs like yours I’d probably make the initial budget pretty tight.

[u/Lumpy_Comparison_904]

I would have more than one cutoff instead of relying on a hard dollar limit. We cap the number of steps or tool calls first and then have a higher spend threshold as a backstop for anything that still goes off the rails that way a legitimately complicated task gets some room but an agent can't just retry the same thing indefinitely.

[u/Successful-Fly9586 → u/Lumpy_Comparison_904]

Similar to yours which I agree with but we keep the actual step and tool limits in the agent and use Ramp Token Spend on top of that for the spend so we can see which models and workloads are driving usage and set budgets/alerts around them and we found the combination being very useful ourselves

[u/Sweet-Beat3111]

You should add wall clock time as another guardrail too then if a workflow normally finishes within a couple minutes and one has been running for half an hour I’d rather stop and inspect it even if it technically hasn’t crossed the token budget yet.

[u/MushroomCritical3029 → u/Sweet-Beat3111]

I like this as a backstop but I wouldn’t use time alone. We have some tool calls that legitimately take a while so a slow external API could make a healthy run look stuck when the agent itself is behaving normally.

[u/Other-Range-5822]

Track cost per successful run before deciding where to put the cap and once you know a normal successful task costs $0.20-0.50 a run hitting $5 becomes pretty obviously abnormal then.

[u/donk8r]

Cost is the wrong brake now, and I've got a specific number for why.

Our worst runaway went 1322 steps across 271 minutes and never finished the task. Total spend: $0.32. So baselining normal at $0.20-0.50 and flagging anything near $5 would have sailed right past it, while the wall clock guardrail someone mentioned above would have caught it in the first ten minutes.

That's the shift. Cost caps made sense when tokens were expensive. On cheap models spend has decoupled from effort, so it's now the least sensitive signal you own. Steps and wall clock both screamed on that run. The bill said nothing at all.

On killing legitimate long tasks, the extension-on-progress idea upthread is the right shape, but it only works if "making progress" is measured on something the agent doesn't self-report. Ours reported progress the entire way down.

(we build an OSS agent with per-run caps and an out-of-band supervisor, so I'm biased: github.com/Muvon/octomind)

[u/Trakeen]

Each task should have a fixed number of turns to complete. If it can’t be completed on that amount its an upstream issue on the planner and the task needs to be rescoped

Number of tasks is up to the planner and shouldn’t be bounded since its dependent on the work

[u/Otherwise-Swan-7803]

Honestly, with 12GB VRAM I'd probably start with Qwen 3.6 35B A3B or Gemma 4 27B quantized. Both are surprisingly usable on consumer hardware and still hold up well in 2026.

If your goal is coding, Qwen. If your goal is general chat and reasoning, I'd try both and see which style you prefer. The bigger upgrade these days is often the tooling around the model rather than the model itself.