How spend caps and drawdown limits work for AI trading agents

A spend cap restricts the total amount of capital an agent may commit to open positions, while a drawdown limit restricts the maximum unrealized loss from a defined peak equity value. Together they form a hard boundary around the agent that operates independently of any strategy or prompt. Through a single API, an owner can apply both controls consistently across stocks, crypto, perps, options, and prediction markets without managing venue-specific margin math.

What is a spend cap and why does it matter?

A spend cap is a hard ceiling on the total notional value an agent can deploy into the market at any given time. It is not the same as the cash balance in your wallet. Instead, it is a subset of that balance that you are willing to expose to trading risk. If you hold $50,000 in a self-custodial wallet and set a $5,000 spend cap, the agent may only open positions that sum to $5,000 in total exposure. It cannot open a sixth thousand dollars of exposure even if the wallet contains far more cash. Because the system is non-custodial, the funds remain under your control. The spend cap is a permission, not a transfer. The agent can commit the funds to a trade but cannot move them to an unapproved address. This distinction matters because the cap is a line of code enforced by the infrastructure, not a legal agreement with a venue. This matters because deployment is the precondition for loss. An agent that cannot deploy more than $5,000 cannot lose more than $5,000 on a single directional bet, though market gaps and leverage can still cause losses to exceed the deployed amount. The cap also prevents the agent from accidentally overconcentrating in one asset or opening positions across multiple venues that add up to a larger sum than you intended. The API expresses this in plain US dollars, which means you do not need to think in terms of contract multipliers, lot sizes, or margin fractions. You state a dollar amount, and the system normalizes the rest. A spend cap is essentially the portfolio-level version of that idea. It is the outer perimeter of how an AI agent trades within a hard budget it cannot exceed.

How do drawdown limits differ from spend caps?

While a spend cap limits how much capital enters the market, a drawdown limit limits how much value can disappear after it is deployed. Drawdown is measured from a peak equity value to a subsequent trough. If your agent starts with $5,000 deployed and the value rises to $5,500, a 10 percent drawdown limit would trigger when the portfolio value falls to $4,950. It does not wait for the account to go to zero. It intervenes at the boundary you define. This is a dynamic control. It moves with the equity curve. A spend cap is static. You set it once and it remains until you change it. A drawdown limit constantly compares current value against the highest value achieved during the trading period. You can configure it as an absolute dollar amount or as a percentage of peak equity. You can also set it to evaluate continuously, daily, or since the agent began trading. Some owners confuse drawdown with a stop loss. A stop loss is attached to a single position. A drawdown limit is attached to the entire agent portfolio. If you run a multi-agent system, each agent can have its own drawdown limit while the portfolio as a whole might have a separate limit. This granularity lets you isolate failure. The two controls answer different questions. The spend cap answers, 'How much am I willing to put at risk?' The drawdown limit answers, 'How much am I willing to lose from my best point?' Suppose your agent deploys $5,000 and immediately loses $500. The spend cap is untouched because the exposure is still $5,000, but the drawdown limit has registered a 10 percent loss and may halt trading. This prevents a slow bleed that eventually consumes the entire spend cap through many small losing trades.

How does the API normalize enforcement across five market types?

Stocks, crypto, perpetual futures, options, and prediction markets each use different margin systems, contract sizes, and leverage rules. A perps venue might require initial margin in one token and maintenance margin in another. An options venue prices contracts in implied volatility and delta. A stock broker may restrict short selling differently than a crypto exchange handles perpetuals. If you had to implement spend caps and drawdown limits separately for each venue, you would need to maintain five different accounting engines. The API abstracts this by tracking every position in a common unit: US dollars of notional exposure and US dollars of unrealized profit and loss. When an agent opens a position, the API converts the venue-specific contract into a dollar value. When the market moves, the API updates the unrealized PnL in dollars. The spend cap and drawdown limit are therefore evaluated against a single ledger that aggregates all five market types. The normalization also handles currency conversion. If an agent holds a stock position denominated in euros and a crypto position denominated in ETH, the API converts both to USD for the purpose of limit checking. This happens in real time as market data flows in. The owner sees a single equity curve and a single set of limit statuses. This means you can set one spend cap for an agent that trades both stocks and prediction markets, and the API will know when the combined exposure crosses the threshold. The agent does not need to understand lot size, tick size, or collateral tokens. The owner does not need to write custom logic for each venue. The exact request schema is in the docs; the shape looks like this.

curl -X POST https://api.felix.trade/v1/limits \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "spend_cap_usd": 5000,
    "drawdown_limit_usd": 500,
    "scope": "agent_id_123"
  }'

What happens when an agent hits a limit?

When an agent reaches its spend cap, the API rejects any new order that would increase total notional exposure. Existing positions remain open. The agent can still reduce exposure by closing positions, which frees up capacity under the cap. This prevents accidental overtrading without forcing an immediate exit of trades that may still be valid. There is also a difference between hitting a cap and hitting a limit. Hitting a spend cap is a neutral event. The agent simply has no more budget to deploy. Hitting a drawdown limit is a negative event. It signals that the strategy is losing money. The API logs both events, and you can subscribe to status updates to monitor them in real time. When an agent hits its drawdown limit, the API rejects new orders and may trigger the exit plan if one is configured. An exit plan can flatten positions, convert everything to cash, or simply halt and notify you. The exit plan you build to automate take profits and stop losses can work in tandem with drawdown limits to create a coordinated response. If you have also configured the panic switch, you can manually flatten and revoke the agent's access at any time. It is important to understand that these limits are safety rails, not profit guarantees. Trading can lose money, including everything. A spend cap and drawdown limit reduce the speed and scale of loss, but they cannot predict market gaps or eliminate counterparty risk. They are best understood as circuit breakers that give you time to review the agent's behavior before more capital is exposed.

How should you set these limits for a new agent?

The safest approach is to start in paper trading, where the agent executes against market data without real money. Once the behavior is stable, move to live trading with a spend cap that represents an amount you are genuinely willing to lose. A common mistake is to set the cap too high because the total wallet balance is large. The cap should reflect the risk budget for this specific agent, not your net worth. For drawdown limits, a reasonable starting point is often 5 to 10 percent of the spend cap. This is tight enough to catch a broken strategy early but loose enough to avoid stopping the agent during normal market noise. If the agent is stopped out by drawdown repeatedly, the issue is usually the strategy, not the limit. Tightening the limit further rarely fixes a flawed edge. Another consideration is the frequency of limit evaluation. Some owners check drawdown continuously, while others check it at the close of each trading day. Continuous checking is safer but may trigger more often in volatile assets. Daily checking reduces noise but allows larger intraday losses. There is no universally correct setting. It depends on the time horizon and volatility of the markets the agent trades. You should also think about how the agent receives instructions. How designing prompts for trading agents differs from writing manual rules covers the behavioral side of this problem. A prompt might tell the agent to be conservative, but the spend cap and drawdown limit are the mechanical enforcement of that instruction. They do not depend on the agent's interpretation. Before going live, review the practical checklist for non-custodial AI trading to confirm that caps, keys, and withdrawal addresses are configured correctly.

How do these limits interact with other safety controls?

Spend caps and drawdown limits are one layer in a larger safety model. Scoped API keys restrict which markets and instruments the agent can access. Position limits restrict the maximum size of any single trade. The panic switch flattens everything and revokes access instantly. Non-custodial architecture means the agent can trade within its limits but can never withdraw funds to an unapproved address. These controls work together through defense in depth. A scoped key might allow the agent to trade only prediction markets. A spend cap might allow it to deploy $2,000. A position limit might cap any single bet at $200. A drawdown limit of $200 might stop it if the bets go wrong. The exit plan might close positions automatically. The kill switch might cut access entirely if you notice something unexpected. Because the API is unified, you configure all of these controls through the same interface. You do not need to log into a stock broker, a perps venue, and an options venue to set separate limits. The single API pushes the constraints down to each venue while keeping the master ledger in one place. This reduces operational complexity and the chance that a misconfigured rule on one venue creates a hole in your risk model. Finally, remember that these controls are only as good as the key management that surrounds them. If your API key is leaked or your prompt is manipulated, the spend cap and drawdown limit still apply. An attacker who gains agent access cannot withdraw funds to their own wallet because withdrawal addresses are owner-approved only. They cannot spend beyond the cap because the API enforces it at the infrastructure layer. This is why non-custodial design and hard limits are complementary. One protects the funds from theft; the other protects the funds from bad trades.