AI agent API spending controls: tool budgets, limits and approvals
Control operating spend when AI agents call APIs and tools with visible prices, prepaid funds, task limits and human approvals.
By Scrollport
In brief
AI agent API spending controls govern operating costs from tool calls, not purchases made with agent cards. Let the agent inspect each price, run routine work below a human-set threshold and pause larger estimates for approval. A prepaid wallet bounds exposure while holds, captures and releases separate successful work from failed attempts.
An AI agent can inspect API pricing before it runs a tool only when the execution layer exposes a machine-readable billing unit, current price and bounded job estimate. Routine jobs can then proceed beneath human-set limits while exceptional costs pause for approval. Prepaid funds, daily limits and attributable agent connections bound the remaining risk.
API tool spend is different from agent purchasing
This guide covers the operating spend created when an agent calls an API tool: searches, verifications, generated assets and other metered work. It does not cover an agent using a payment card or payment protocol to buy goods and services from outside merchants.
Those purchase systems need merchant, transaction and payment-method controls. API tool execution instead needs a visible billing unit, a bounded estimate, prepaid funds and an approval decision before the external work begins. Treating both as generic “agent payments” hides the different authority and risk in each action.
Start with AI agent spending controls
Start with a visible price, a bounded source of funds, a human-set approval threshold and a revocable agent connection. Then separate the two bills one task can create. Model usage pays for reasoning and generated responses, commonly metered in input and output tokens. Catalog-tool usage pays for external work such as a search, verification, result or generated media asset. The current OpenAI pricing and Anthropic pricingillustrate the model side; Scrollport’s wallet governs published catalog-tool usage.
Keeping the costs distinct prevents an inexpensive model session from hiding a material external action. The live tool catalog, rather than this article, owns each current billing unit and price.
Show the price before execution
The safest time to control cost is before a tool runs. search_tools finds relevant choices and inspect_tool loads the selected tool’s contract, worked example, access state, billing unit and current price. run_tool then estimates the bounded request before execution.
A published unit price and a job estimate are related but different. A price may be per result, verification or generated second; the estimate applies that denominator to the requested quantity. Agents should inspect current pricing instead of relying on a rate remembered from an earlier session. Read theusage-based pricing guide for the model behind those units.
Combine a wallet with approval thresholds
A prepaid wallet bounds the total exposure because funds are present before execution. A human-set per-run approval limit lets predictable tool runs proceed while pausing a larger estimate for an explicit decision. An optional daily limit controls the aggregate effect of many individually small runs.
These are different controls: the per-run limit catches one unexpectedly expensive tool run; the daily limit caps cumulative successful captures and unresolved holds. Agents can read the balance and boundaries through get_wallet, but only a signed-in human can change them. The approval guide explains how a paused run returns to the queue after approval.
Settle success and failure differently
Scrollport reserves the estimate with a hold before provider execution. A successful run captures its measured charge and releases any unused remainder. A failed run releases the full hold instead of charging the wallet for an unsettled result.
- Calculate the estimate and apply approval and daily-limit rules.
- Place a hold when the run enters the execution queue.
- Execute the catalog tool.
- Capture successful measured usage and release the remainder, or release the full hold on failure.
A run waiting for human approval holds no money. Approval checks the balance again before the hold is placed, so an old approval screen cannot silently spend funds that are no longer available. See wallet and spending for the complete ledger behaviour.
Attribute and revoke authority
Every run remains attributed to the agent connection that requested it, whether that connection uses CLI credentials, a harness secret store or MCP OAuth. A readable connection name and stable slug preserve the history without exposing a raw key. This is connection-level attribution, not a claim that one key proves the identity of one model personality.
A human can pause a connection temporarily, resume it or revoke it permanently. Work already executing against a valid hold can settle, while later calls are refused. Together, visible prices, prepaid funds, human-only limits and revocable connections create useful autonomy without unlimited spending authority.