Nobody noticed the agent was spending money

The agent did not crash, and it raised no error. It kept working all weekend, and the bill at the model provider kept growing until someone opened the invoice.

One model call costs little. An agent makes many calls, and it decides how many while it runs. That is the point of an agent. It is also where the money goes.

Three patterns come back again and again when teams describe a cost surprise.

The loop. A tool returns an error. The agent tries again and gets the same error. It tries again. Each attempt often sends the growing conversation back to the model, so later attempts can cost more than early ones. If this starts on a Friday evening, the first person to see it may be the one who reads the invoice.

The quiet retry. A step fails, and a retry setting starts it again from the beginning. In some setups the counter that should stop the run resets with each restart. The run looks busy. In a sense it is.

The fan-out. An agent may start other agents, and each of them may start more. Nothing in the design is wrong. Nothing in it says when to stop, either.

The common cause is not a bad model. The agent spends money, and nobody outside the agent holds the limit.

When the bill comes, it often shows a total per account or per key. It does not say which workflow, which run or which step caused it. A team that runs many agents on one key sees the total jump and cannot say why.

Tracing tools help, because they show what each run did. But check their cost figures against the provider's own bill. An estimate in a dashboard is not the invoice.

The questions you need to answer are simple. Which run cost the most this week? Which step inside that run? Was it a loop, a retry, or normal work that is simply expensive? If you cannot answer these, you cannot fix the cost. You can only complain about it.

The usual reflex is to give the cost problem to finance. Finance can set a budget and read an invoice. Finance cannot see that a tool started to fail in the night and an agent has been calling it since. The people who can act are the people who run the agents.

So treat agent cost like uptime or error rate: something operations watches, with an owner and a routine. Four habits make it work.

Know whose key pays. Every model call goes out on some provider key. If it is one shared key for everything, or a key inside someone else's account, you see the cost late, or only as a line on another party's invoice. A key per team or per workload makes the bill readable.

See cost per run and per step. Total spend tells you there is a problem. Cost per run tells you where it is. Cost per step tells you why.

Put limits where the spending happens. A monthly cap at the provider limits the damage, but it acts late, and it stops the good runs together with the bad ones. Limits close to the work act sooner: a maximum number of steps or tool calls per run, a retry count that does not reset, a maximum number of agents one run may start, and a cost ceiling per run. When a run reaches a limit, it should stop and say so, not start again. Then test the limit on purpose. A limit that counts the wrong thing gives you a feeling of safety and nothing else.

Decide who looks, and how often. An alert that nobody reads is not a control. Name a person. Agree how often that person looks at cost per workflow: daily while a new agent is young, weekly once it is stable. Agree what a normal run costs, so a strange one stands out.

None of this is clever. It is the discipline teams already apply to cloud servers, now applied to a new kind of spender. The difference is speed. A server that is too big costs you slowly. An agent in a loop costs you fast.

Name one person to do this at the end of each week.

1. Find the most expensive run this week. Start from the provider's bill, then find the run behind the total.
2. Find the step inside that run that used the most tokens.
3. Name the cause: a loop, a retry, or normal work that is simply expensive.
4. Check the limits on that workflow: steps, tool calls, retries and run time.
5. Set or lower a limit, and note what a normal run costs, so next Friday a strange one stands out.

What EpicStaff gives you for this review

AI usage in EpicStaff runs on your own provider keys, so the bill comes to you and you can see it at your provider. EpicStaff records how many tokens each run and each agent step used; it does not show a money amount. You can limit how many steps, tool calls and retries an agent may use each time it runs, and how long a run may take. When a run hits its token or time limit, EpicStaff stops it; the reason is stored, but the screen does not always say a limit was hit. EpicStaff connects out only to the providers you configure keys for. Tools do what you tell them: a tool you build or enable that reaches the internet is your choice and your configuration. EpicStaff does not limit how many agents one run may start, so count the agents a run starts when you test the flow. EpicStaff does not alert anyone when a run costs more than usual, so the Friday review is your check.