How do I set a spending limit for an AI agent?
A spending limit for an AI agent is three settings, not one: a cap on any single action, a cap per billing cycle, and a list of action types that must stop and ask you before they run. If a product gives you only a monthly total and a bill you read afterwards, that is a spending report rather than a spending limit — by the time you see it, the money is already gone. Setting this up for your own assistant is a sequence: write down which actions actually cost money, put the irreversible ones behind an explicit approval, set the cycle cap at an amount you can afford to lose rather than the amount you expect to use, and reconcile the line-item record once a week.
You cannot cap what you have not counted, and most assistants spend in more than one currency: model tokens or compute credits for thinking, per-call fees for outside tools it reaches for, and real money if it is allowed to buy anything. Make this list yourself instead of trusting a single “usage” number, because a cap on the meter you can see does nothing about the two you cannot. If the product will not tell you which of your actions draw down which meter, you have already learned something about how much control it is offering.
Split that list in two: things you can undo, and things you cannot. Money leaving an account, a message sent to another person, a booking made, a file deleted — these do not become safe by being cheap, and a number is the wrong instrument for them. Require the agent to stop and ask before each one individually, and check that the prompt tells you what it is about to do and on what basis, not merely that it wants permission. A cap protects your budget; an approval protects the things a refund cannot fix.
The common mistake is setting the cap at expected usage plus a margin. Expected usage is the number you plan with; the cap is the number that decides how bad the worst week can get, and those are different questions with different answers. Pick the amount you would be annoyed but not harmed to lose if the agent ran in a loop overnight, set the cap there, and raise it deliberately when the work outgrows it. A cap that has never triggered is not evidence that it is well calibrated — it may only mean nothing has gone wrong yet.
Once a week, open the line-item record and check that each charge maps to something you asked for. Three things are worth looking for specifically: a charge with no matching request, one request that produced several charges (usually a retry), and a slow climb in the routine baseline. The total tells you whether you are over. Only the lines tell you why, and only the why is fixable.
The number you typed in only matters if the product enforces it somewhere specific. Five questions separate a limit that holds from one that is merely displayed, and you can run them against anything, including us.
Every setting above is paid for in something other than money. A cap tight enough to protect you will eventually interrupt work you wanted done, usually at the least convenient moment — that interruption is the mechanism working, not a defect in it. An approval prompt returns you to doing the task by hand, one confirmation at a time; put too many actions behind approval and you will start clicking yes without reading, which is worse than never having asked, because now there is a record showing you agreed. Per-action limits have the fewest blind spots and the most configuration, and configuration decays: a set of limits tuned once and never revisited will be wrong within a few months, either blocking routine work or leaving a whole category unwatched. No arrangement is both frictionless and hard to overspend under, so the real choice is which failure you would rather have.
The failures repeat, and they are unglamorous. Capping the visible meter and not the others leaves the unwatched category to absorb everything that gets squeezed out of the watched one. One flat cap for every kind of action gives routine work the same allowance as the expensive kind, so it is either too tight for one or too loose for the other, and usually both at different hours. Treating the approval prompt as a formality — approving in a batch, without reading — removes the only check that irreversible actions ever had, while leaving evidence that you consented. And the quiet one: the agent whose job grew. It was set up for small errands, it now handles real work, and the limits are still the ones from the first week, so they either block the new work or fail to bound it.
Two of these questions have no settled answer, and anyone who tells you otherwise is selling a preference as a principle. The first is whether hitting the cap should suspend the agent or only warn you: suspension guarantees the ceiling holds, but it can strand a half-finished task in a state that costs more to clean up than the overage would have cost to absorb. The second is whether limits belong in one central number or per action type: a single number is the only setting most people will actually maintain, while per-action limits are more accurate and more likely to be abandoned within a year. Which side you land on follows from how much you can afford to lose weighed against how much interruption you can absorb — so your answer may reasonably differ from ours, and from your own answer six months from now.
Run the five questions against us and we pass some of them and not all, so here is the split rather than a summary.
What runs today is the approval half and the record half. A delegated task in OneOneTalk carries an autonomy level with a matching ceiling, and the policy layer decides action by action whether a step needs your explicit confirmation; steps it judges high-risk block before they run rather than being reported after, and each one leaves a receipt. On the accounting side, One — the in-product credit and compute metering unit — has a line-item ledger. Grants and clawbacks happen only inside a database transaction, so the balance and its ledger line move together or not at all, and a top-up counts as delivered only once the order reaches an explicit granted state, not when a payment interface returns success. That distinction is there because “the interface said OK” is the most common way a balance and a bill quietly stop matching.
What does not run yet is the first question on the list, and you should hear it here rather than find out later. Programmable spending caps and whitelists — an agent wallet that refuses an over-limit action at the moment it is attempted — are being built and are not shipped. Until they are, the honest description is reconcilable, not capped: you can read every line and stop the agent yourself, but there is no number you can type in that we will enforce on your behalf. Anything involving regulated money movement sits further out again, and would run through licensed partners rather than through us.
More on the product in the English overview.
The public primary material this page is built on. We do not restate their conclusions as our own evidence — they are listed so you can check for yourself.