Capping an AI agent's credits: keeping the cost under control

It is the nineteenth of the month, 11:40 in the morning. The support lead opens a notification saying three quarters of the monthly AI credit is gone, and is left with two questions: who burned it, and what happens over the eleven days left? The dashboard answers most of it in one place. The research agent set up last week to "look into every incoming request and summarise it" has run a full research pass on every new lead, including the ones dropped in by form spam. The agent did not misbehave; it did the job it was given. What was missing was a ceiling on what that job could cost.

This piece is about building that ceiling. We start with why consumption stays invisible until mid-month and what a single run actually spends. From there: which level the cap belongs at, how to pick the first number, what should happen when it is hit, how to strip out spend that produces nothing, and which settings make an agent cheaper before you cap it at all. The last sections tie the cap to a monthly routine and mark where it is the wrong instrument entirely.

Why does credit consumption stay invisible until mid-month?

Conventional software spend is fixed. Seats are known, the monthly figure is known, nothing surprises you. Agent spend is a variable cost line and it tracks demand. If inbound leads double one month, your licence invoice does not move but the credits your agent consumes do. Most budget owners have no habit for that: the cost grows on someone else's volume, not on your decision.

The second reason is that unit cost is counter-intuitive. What a run consumes depends on how many steps the agent takes and how much context it reads at each step. The same agent can spend three credits on one conversation and fifteen on another the next day, and both are correct work. An estimate built on the average hides the weight carried by the outliers. As with ownership cost, the expenses sitting outside the subscription figure need their own row here too.

The third reason is that accumulation is quiet. Thirty runs a day raises no alarm; the same thirty across twenty working days can eat half the budget. Consumption arrives as a steady gradient, not a spike, so the sense that something is wrong shows up well after the threshold was crossed.

What does a single agent run actually spend?

A credit is not the price of one thing. Four items accumulate in a run: the context the agent reads, the reasoning steps it takes, the tools it calls and the answer it produces. The first is missed most often. Agent memory is valuable because it carries the earlier conversation forward, but a long customer history is re-read on every run and every read burns credit. A short answer does not mean a cheap run.

Tool calls are the second large item. The 74 autonomous actions on the product side let the agent open a task, update a lead status or draft a quote on its own; every action is a step, and every step costs time and credit. A job solved in five steps costs half of the same job solved in twelve, so "how many moves it took" is as much a cost question as "what it did".

Do not estimate that breakdown by feel. The AI usage and credit dashboard splits consumption by agent and category and keeps daily usage next to an end-of-period projection; agent insights pull from the run logs which action fires how often and where it gets stuck. Those two screens produce the data that decides your cap — the same logic you use to work out what it costs to serve a single customer: take total spend, divide by the unit that produced it.

Should the cap sit on the account or on each agent?

A single account-wide cap is easy to set and almost useless. When the total is exhausted it does not tell you which agent caused it; it stops all of them. The invoicing agent goes quiet not because of month-end reporting but because a research agent was greedy. That is not cost control, it is an arbitrary outage.

A per-agent credit cap fixes the problem at source. You set a separate monthly limit for each agent, and a run that would exceed the cap is stopped before it starts — nothing is left half-finished, because the run never began rather than being cut off mid-way. Putting an experimental agent into production therefore stops being a budget risk: the worst case is written down in advance.

In practice you want both levels. The per-agent cap keeps one agent from running away; account-level tracking keeps the total visible as it approaches the plan limit. Treat the first as insurance and the second as a gauge — use insurance as your gauge and you only find out once it has blown.

Where should the first cap number come from?

Do not guess the first figure — measure for two weeks. Run the agent under a generous cap rather than none, watch consumption on the dashboard, then fix the cap at the observed weekly average plus a margin. The margin depends on seasonality: wider for a support agent whose volume swings, narrower for a reporting agent on a fixed schedule.

The real question is not "how much can I afford" but "what does this agent produce". A research agent that raises the count of qualified leads is judged against the contribution those leads make — the same ratio thinking you apply when working out acquisition cost. An absolute figure is neither expensive nor cheap on its own; it means something once you divide it by what it returns.

Agent type	What drives consumption	Where to start the cap	Signal to watch in month one
Lead research / enrichment	Volume of inbound records	Four times the measured weekly average, narrow margin	Qualified leads per run
Support triage	Conversation volume and out-of-hours pile-up	Busiest week's consumption, wide margin	Human handover rate
Scheduled reporting	Run count is fixed	Run count multiplied by measured unit cost	Any drift means context bloat
Ad budget control	Campaign count and check frequency	Fixed against daily check count	Check cycles that change nothing
Agent still in trial	Unknown	An amount you can afford to lose	How often it hits the cap

The table reduces to one rule: if outside volume drives consumption, keep the margin wide; if your own calendar drives it, keep it narrow. For an agent still in trial the right question is not "is this enough" but "would losing this amount hurt".

What should happen the moment the cap is hit?

What happens at the ceiling matters as much as the ceiling itself. The worst outcome is a silent stop: the agent goes quiet, nobody notices, customer requests pile up unanswered. If a cap is a budget decision, hitting it is an operational event and it should raise a notification.

The second decision is whether hitting it counts as normal or exceptional. An agent that hits its cap every month means either the cap is wrong or the agent is doing unnecessary work — do not conflate the two. Hitting it once in the last days of the month is usually healthy and shows the limit is genuinely binding. Hitting it on the eighth means the measurement was wrong from the start.

The third is where the work goes once the agent stops. For anything critical the handover path should be defined in advance: smart human handover moves complex or sensitive conversations to the right rep so the customer is never stranded. Build the same path for budget-driven stops. When the jobs you hand to an agent are held as tasks attached to the record, a person picks up exactly where the stopped agent left off.

Which part of the spend is producing nothing?

Before you set a cap, ask how much of the current consumption turns into work. The largest source of waste is records being processed that should never have been touched. An agent working over incomplete, duplicated or abandoned records produces nothing at full price, so the first move in cost control usually sits on the data side: clearing out garbage data recovers more credit than tightening the cap.

The second source is triggers scoped too broadly. Replacing "every new lead" with "leads from a given source with the core fields filled" cuts run count sharply and raises output quality. The same logic applies at the inbox: if you do not want the agent wrestling with noise, stop the noise upstream — a spam and blocking policy reduces agent-side consumption directly.

The third source is dead records. An agent running follow-ups on opportunities that have not moved in months spends credit on deals that will never close. Keeping the pipeline clean does not just fix the forecast, it shrinks the ground the automation runs over.

Which settings lower the cost before you even cap it?

A cap is a safety net, not an optimisation tool. Before you stretch the net, making the agent itself cheaper is the more durable win. The first setting is narrowing context: agent knowledge routing lets you pick, per agent, which knowledge sources it may reach. If the support agent has no business reading the price list, it should not — every source left unread is less credit and less drift.

The second is fixing the number of steps. A step-by-step playbook lets you define the order of actions instead of leaving it to the model, while conditional steps and a side-effect-free dry-run mode make the number of moves visible in advance. Free exploration is expensive, and on a repeating job there is no reason for it to be.

The third is run frequency. Scheduled runs fire the agent on the day and hour you choose; moving a summary agent from hourly to twice a day costs most teams nothing. The fourth is testing and preview: trying the agent against real scenarios in the live test panel before launch stops you learning it was badly configured while it burns credit in production.

How does the cap become part of a monthly routine?

A cap set once becomes the wrong number within three months. Volume shifts, the agent's remit widens, a new agent goes live. So the review needs a calendar, and that calendar should hang off a routine you already run. Adding one line to your month-end close checklist outlasts standing up a separate meeting.

The review looks at three things: which agent hit its cap, which stayed far below it, and which one's cost per run went up. The third is most informative, because it usually means context has quietly bloated. AI analytics surfaces the most expensive conversations as their own breakdown; reading the top three teaches you more than the table does.

Keep the number in the books as well. Agent credit should not disappear inside a generic software expense; tracked as its own row in your income and expense records, nobody asks at month-end where it went. The run trail helps here too: every run's parameters, result, duration and approver are recorded, so a disputed line can be explained after the fact.

When is a credit cap the wrong instrument?

A cap is a budget tool, not a safety tool. Using it to stop an agent doing things it should never do is like putting out a fire with the water bill. The right answer there is defining boundaries declaratively with guardrails and choosing, per action type, whether it runs automatically or waits for approval. The cap answers "how much"; approval control answers "what".

The second misuse is solving a quality problem with budget. An agent burning a lot of credit is usually not expensive but indecisive: it retries the same job, looks at the wrong source, takes redundant steps. Tightening the cap suppresses the symptom and leaves the cause. The right move is to train the agent, narrow its scope, or bind the job to a playbook.

The third is saving at the wrong layer. Cutting agent credit while growing the team's manual work is usually a net loss; the comparison is not credit against nothing, it is credit against human hours. As with choosing between open source and a commercial system, the cheaper-looking option often just moves the cost somewhere else.

To put per-agent caps, approval control and the credit dashboard to work together, start a free Rocketly account and run your first agent under a deliberately tight ceiling.

FAQ

If I set the cap too low, will the agent abandon work halfway?

No. A run that would exceed the cap is stopped before it starts, not interrupted mid-flight. There is no half-created task or half-sent reply; the run simply never began.

When one agent hits its cap, do the others stop too?

The cap is per agent, so only that agent stops. The rest keep working within their own limits. Running out of plan credit at account level is a different situation and needs tracking separately.

Where do I see which agent spent what?

The AI usage and credit dashboard breaks consumption down by agent and category, with daily usage alongside an end-of-period projection. For action-level detail, use agent insights and the run trail.

How often should the cap be reviewed?

Monthly is enough — attach it to your month-end close. Review it off-cycle whenever a new agent goes live or inbound volume changes for good.