How to set spend caps and drawdown limits for trading agents

Spend caps and drawdown limits are the two primary numerical guardrails that keep an agentic trading strategy from consuming more capital or losing more money than its owner intends. A spend cap is a hard ceiling on the total capital the agent can deploy, while a drawdown limit is a threshold of cumulative loss that triggers an automatic halt. Together they convert an owner's risk appetite into enforceable, non-custodial controls that the agent cannot override. These limits sit at the boundary between the agent's reasoning and the actual movement of funds, which means they must be set with precision before any live key is authorized.

Trading can lose money, including everything, and these limits exist to make sure that if an agent fails, it fails within a box of the owner's choosing.

What is a spend cap and why does it matter?

A spend cap is a maximum budget, expressed in plain US dollars, that an agent is allowed to commit to open positions. It is not a suggestion or a soft alert. Once the cumulative notional exposure reaches this ceiling, the agent cannot place new orders that would increase risk until the owner resets the limit or the agent reduces exposure by closing trades. The cap applies across all market types, so an agent trading stocks, crypto, perps, options, and prediction markets through a single API still operates under one unified budget number.

The cap is enforced at the infrastructure level, not inside the agent's logic. This matters because an agent that reasons poorly, receives bad data, or encounters an edge case in its strategy cannot talk its way around a hard limit. The owner defines the cap during key setup, and it is bound to the scoped credential that the agent uses to sign orders. If the owner wants to change the cap, they revoke the old scoped key and issue a new one. This design is part of why the system remains non-custodial. The agent can spend within limits, but it can never withdraw funds or raise its own budget. The owner approves withdrawal addresses in advance, so even if the agent behaves erratically, it cannot move capital outside the owner's control.

Spend caps also simplify mental accounting. Because the API normalizes venue-specific contract math, the owner does not need to translate between lot sizes, margin requirements, or token denominations. A $5,000 spend cap means the same thing whether the agent is buying shares of a stock, opening a perp position, or taking a side in a prediction market. This normalization reduces the chance of accidental over-leverage that comes from misreading a contract multiplier. For a broader view of how these guardrails fit into the full safety stack, see how to build guardrails for a trading agent.

How do drawdown limits differ from spend caps?

If a spend cap controls how much capital enters the game, a drawdown limit controls how much the agent is allowed to lose while playing. Drawdown is measured as the decline from a peak equity value to a subsequent trough, expressed either as a percentage of the allocated budget or as a fixed US dollar amount. When the drawdown limit is breached, the system halts trading and invokes the exit plan.

A spend cap is static. It does not care whether the agent is winning or losing. It simply counts deployed capital toward the ceiling. A drawdown limit is dynamic. It tracks the high-water mark of the agent's performance and watches for deterioration. An agent could hit its spend cap while profitable, which would stop new entries but leave winning positions open. An agent could also remain well below its spend cap while bleeding money on every trade, which is when the drawdown limit becomes essential.

The two limits answer different questions. The spend cap asks, "How much can you risk?" The drawdown limit asks, "How much can you lose before we stop?" An owner who sets only a spend cap is saying, "I am comfortable with this much exposure," but is not saying, "I am comfortable with this much loss." An owner who sets only a drawdown limit is saying, "Stop if you lose too much," but is not preventing the agent from taking on a massive position that could gap past the limit in a single move. Both are necessary because each covers a failure mode the other ignores. In fast-moving markets, a large position can lose more than a drawdown limit in the time it takes to flatten, so the spend cap acts as a preventive brake while the drawdown limit acts as a reactive one.

How should you size a spend cap in practice?

Sizing a spend cap starts with the owner's total liquid capital and works downward, not the other way around. The goal is to define a number that represents the maximum loss you can absorb without changing your broader financial plan.

1. 01Decide how much of your total balance you are willing to expose to automated strategies in general.
2. 02Decide how much of that automated allocation goes to a single agent.
3. 03Check whether that agent will concentrate its activity in one market or spread it across several. Correlation matters. An agent trading both a stock and an options position on the same underlying may be taking one directional bet with two instruments.
4. 04Set the spend cap to reflect the economic risk, not the number of tickets.

Suppose you have $500,000 in a self-custodial wallet and you are willing to automate 20 percent of it. That gives you $100,000 for automated strategies. If you run five agents, a naive split might suggest $20,000 per agent. But if three of those agents trade correlated strategies, you may want to group them under a shared sub-cap or reduce their individual limits. A single agent with a volatile strategy might deserve a smaller allocation than a single agent that rebalances a broad portfolio slowly. There is no universal formula, but the principle is that the cap should be sized for the worst case, not the best case.

The Felix API normalizes all orders to plain US dollars, so you do not need to think in terms of contract multipliers, margin fractions, or lot sizes. If you set a $10,000 spend cap, the system counts the notional value of a $2,000 stock purchase, a $2,000 crypto spot position, and a $2,000 notional perp the same way. Options require slightly more care because the notional value of the underlying can differ from the premium paid, but the API still reports the economic exposure in dollars. Set the cap at the maximum loss you can accept, not at the amount you hope to make. Trading can lose money, including the entire allocation, and the spend cap should be sized with that possibility in mind.

Many owners find it helpful to tie the spend cap to a time window. A daily spend cap of $5,000 and a monthly spend cap of $15,000 can coexist. The daily cap prevents a burst of activity in a single session, while the monthly cap prevents the agent from grinding away a small loss repeatedly until it becomes large. Layering windows this way adds complexity, but it also catches a broader range of failure modes. For a complete checklist on moving from paper to live trading, see how to run an AI trading agent with real money, safely.

Where do you measure drawdown?

Drawdown must be measured against the agent's own allocated budget, not the owner's total wallet balance. If an agent is allocated $10,000 and the owner holds another $90,000 in the same wallet for manual trading or other agents, the drawdown limit should trigger when the agent's $10,000 allocation falls to $8,000, not when the total wallet drops by 20 percent. Measuring against the total wallet would make the limit meaningless, because unrelated deposits or withdrawals would create false triggers or dangerous blind spots.

The measurement period also requires a decision. A daily drawdown limit catches intraday blowups but may be too noisy for a slow strategy. A cycle-based limit, measured from the start of a defined trading period, works well for agents that run discrete campaigns. A trailing drawdown limit, measured from the highest equity reached since the cycle began, protects profits but can be harder to reason about. The key is to align the measurement window with the strategy's expected holding period. An agent that holds positions for minutes needs a tighter, more frequent check than an agent that rebalances quarterly.

Because the API reports positions and balances in a single normalized currency, you can set a drawdown limit in US dollars even if the agent trades across a stock broker, a crypto exchange, a perps venue, and a prediction market. The limit is enforced on the combined portfolio value, not per venue. This cross-market consistency is one of the reasons a unified API matters for multi-agent setups. You do not need to manually track equity across five different dashboards and reconcile them in a spreadsheet. The system maintains the high-water mark automatically.

Some owners prefer to set a drawdown limit as a percentage of the initial allocation, while others prefer a fixed dollar amount. A percentage scales if you later increase the budget. A fixed dollar amount is easier to reason about when you are starting out. Both are valid. The important part is to define the limit before trading begins and to avoid moving the goalposts after a loss has started. Moving a drawdown limit deeper into the red during a losing streak is a common human error, and the infrastructure does not prevent the owner from doing it. Discipline is part of the safety model. See one API for every market for how this normalization works in practice.

What happens when a limit is hit?

When a spend cap is reached, new order requests that would increase exposure are rejected. The agent receives a clear error and can either close existing positions to free budget or wait for owner intervention. The rejection is immediate and applies to all market types. The agent cannot circumvent the cap by switching from stocks to crypto or from spot to perps. The unified dollar accounting closes that loophole.

When a drawdown limit is breached, the system invokes the exit plan. The exit plan is a pre-configured sequence that typically includes canceling open orders, flattening open positions, and revoking the scoped API key so the agent cannot trade again until the owner explicitly restores access. The owner defines the exit plan when they authorize the key, and the agent cannot modify it. In some cases, the owner may want the exit plan to close only a subset of positions, or to scale down rather than flatten entirely. The system supports these variations, but the default is a full halt because it is the safest starting point.

There is also a panic or kill switch available to the owner at any time. This flattens positions and revokes the key immediately, outside the normal agent loop. The kill switch is separate from the automated limits, but it uses the same underlying infrastructure. Both mechanisms respect the non-custodial design. The agent cannot cancel the exit plan, cannot revoke the owner's access, and cannot withdraw funds to an unapproved address. Withdrawal addresses are owner-approved only, so even in a halt scenario, the capital remains under the owner's control.

It is important to configure these limits before authorizing a live key. Changing a limit after the agent has already opened positions can create awkward states where the agent is above a new, lower cap or already through a drawdown threshold. The safest workflow is to set the cap and drawdown limit in paper trading, observe how the agent behaves as it approaches each boundary, and only then authorize the live key with the same parameters. Paper trading exists for exactly this reason. It lets you watch the limit logic execute in real time without risking capital.

How do spend caps and drawdown limits work together?

Spend caps and drawdown limits are complementary, not redundant. A spend cap prevents an agent from taking on more risk than the owner planned, even during a period of high confidence or flawed reasoning. A drawdown limit catches strategies that are technically within budget but are steadily destroying value. An agent can hit a spend cap while up 50 percent. An agent can hit a drawdown limit while only half deployed. Both are failure modes worth preventing.

In a multi-agent system, these limits also prevent contagion. If one agent breaches its drawdown limit and halts, the others continue trading within their own scoped budgets. The owner can review the halted agent, adjust its strategy, and issue a new scoped key with a fresh cap without touching the rest of the fleet. This isolation is only possible because each agent operates with its own scoped credentials and its own budget envelope.

The combination of a hard cap and a drawdown limit also changes how the owner thinks about strategy selection. An agent with a high win rate but occasional large losses might be kept in check by a tight drawdown limit. An agent with a low win rate but many small positions might be kept in check by a tight spend cap. The owner does not need to predict exactly how the agent will fail. They only need to decide how much they are willing to lose if it does. The limits handle the rest.

Finally, both limits should be reviewed periodically. A strategy that was safe with a $5,000 cap in a calm market may need a lower cap in a volatile one. A drawdown limit that was appropriate for a small account may be too tight for a larger one if the strategy's natural variance scales with position size. The infrastructure does not change these parameters on its own. The owner must review them, revoke old keys, and issue new ones with updated limits. This manual step is a feature, not a bug. It forces a conscious decision every time the risk envelope changes. For a developer's perspective on building this kind of isolated multi-agent architecture, see how to build a multi-agent trading system: a developer's guide.