How spend caps and drawdown limits protect your funds while an agent trades

Spend caps and drawdown limits are owner-controlled constraints that tell an agent exactly how much capital it can deploy and how much it is allowed to lose before trading stops. Because Felix is non-custodial by construction, these limits are enforced by the infrastructure around your wallet, not by moving funds into someone else's custody. You set the ceiling, the agent operates within it, and the system halts activity automatically if the cap is reached.

What do spend caps and drawdown limits actually do?

A spend cap is a hard ceiling on the total notional value an agent can have open at any single moment. It is measured in plain US dollars across all markets, so a cap of one thousand dollars means the agent cannot hold more than one thousand dollars in combined position value, whether it is trading stocks, crypto, perps, options, or prediction markets. This includes the sum of absolute notional exposure. If the agent is long five hundred dollars of one asset and short five hundred dollars of another, the total open exposure is one thousand dollars, and the cap is reached. The spend cap prevents the agent from concentrating too much of your capital in a single idea, from opening overlapping trades that stack risk, or from accidentally doubling its intended size due to a misinterpreted signal.

A drawdown limit is a relative boundary tied to the starting equity of the agent's allocation. You pick a baseline value and a maximum percentage decline you are willing to tolerate. If the agent's allocated portfolio drops by that percentage, the system stops the agent from opening new positions. The drawdown limit is not a stop loss on a single trade. It is a portfolio-level circuit breaker that protects the allocated budget from a sequence of losing trades, from a strategy that is not working in current conditions, or from a sudden market dislocation that the agent is not equipped to handle. The baseline is typically set when the agent first begins trading, and it serves as the high-water mark for the allocation.

Together, these two numbers form a bounded box. The spend cap controls how much can be put at risk at once. The drawdown limit controls how much of that allocation can evaporate before the agent is pulled offline. They are not suggestions or guidelines. They are hard constraints enforced by the system. Neither requires you to hand the funds to a custodian. The wallet remains yours. The agent simply receives permission to trade within the lines you draw.

How does the system enforce limits without taking custody?

Non-custodial trading means your private keys and funds stay under your control. The agent does not hold your assets. Instead, it receives a scoped key that can sign orders but cannot sign withdrawals. Withdrawal addresses are owner-approved only, so even if the agent were compromised, it could not send funds to itself or to an unknown wallet. The funds sit in a wallet you control, and the agent can spend within the limits you define, but it can never steal the underlying capital. This architecture is described in more detail in How developers can start self-custody algorithmic trading.

The enforcement of spend caps and drawdown limits happens in the policy layer that sits between the agent and the trading venues. This layer is part of the Felix infrastructure, not a local script on your machine. That means the limits are enforced even if your server restarts, your MCP client crashes, or your network connection drops. When the agent asks to open a position, the request first hits the Felix API. The API checks the current open notional exposure against the spend cap. If the new order would push the total above the cap, the request is rejected before it ever reaches a venue. The rejection is immediate and automatic. The agent does not get a chance to send the order to the market and hope it is not filled.

The same logic applies to drawdown. The system tracks the mark-to-market value of open positions across all connected markets and compares it to the baseline equity. If the decline meets or exceeds the drawdown limit, new orders are blocked. The monitoring happens continuously, not just at the moment of order entry. This is important because market prices move even when the agent is not trading. A position that was within bounds when opened might drift into a drawdown breach while the agent sleeps. The policy layer catches this and halts the agent before it can add more risk.

Because orders are sized in plain US dollars, the API normalizes venue-specific contract math for you. A perps venue might use coin-margined contracts with inverse pricing, an options venue might use delta-adjusted notional, and a stock broker might use share quantities with margin requirements. The API converts these into a single dollar value so the cap is easy to reason about. You do not need to calculate contract multipliers, tick sizes, or margin tiers. The limit is a single dollar number, and the system enforces it uniformly across all five market types. For a deeper look at the security model, see How the Felix architecture keeps AI trading agents secure.

Where do these limits live in the stack?

The limits do not live in the agent's prompt. A prompt-based rule can be misread, ignored, or bypassed by a creative model. A prompt that says only spend five hundred dollars is a request, not a guarantee. Instead, spend caps and drawdown limits are baked into the scoped key that you create when authorizing the agent. You configure them in the Felix console or through the API, and they travel with the key. The agent can request trades, but it cannot request a change to the cap because the key does not carry that permission. Even if the agent is an advanced large language model that reasons in natural language, its final action is a structured API call. That call is evaluated by the policy engine before any market interaction occurs.

This means the enforcement is deterministic. The agent, whether it connects through an MCP client like Claude or Cursor or through a direct REST integration, sends a trade intent. The policy engine evaluates the intent against the live portfolio state and the key's constraints. If the intent would violate the spend cap, the engine returns an error. If the portfolio has already breached the drawdown limit, the engine returns a halt. The model can interpret the error and try a different action, such as reducing position size, but it cannot override the boundary. The limit is a property of the infrastructure, not a property of the model's reasoning.

This separation of concerns is important for safety. The model handles strategy, signal generation, and reasoning. The policy layer handles risk, limits, and authorization. You should not rely on the agent to police itself. You rely on the infrastructure to say no. The scoped key also carries other constraints, such as allowed markets, maximum position sizes per symbol, and time windows. You can read more about this separation in How to set hard limits that stock trading agents cannot cross.

What happens when an agent reaches its limit?

When a spend cap is reached, new orders are simply rejected. The agent receives an error explaining that the cap would be breached. Existing positions remain open according to the exit plan you configured. The agent can still reduce exposure by closing positions, which frees up capacity under the cap, but it cannot add new risk until the total open notional drops below the limit or you manually raise the cap. This creates a natural asymmetric behavior: the agent can reduce risk but cannot increase it. If the strategy is designed to scale out of losers, it may still do so, but it cannot pyramid into larger losses.

When a drawdown limit is hit, the behavior depends on the configuration you chose during setup. By default, new orders are halted while existing positions remain open. This gives you a chance to review the situation manually. If you enabled an automated exit plan, the system may begin flattening positions according to the rules you set, such as closing all positions immediately or scaling out over a defined period. If you enabled the panic or kill switch, the system will close all positions, revoke the scoped key, and sever the agent's connection. This is useful if you suspect the strategy is broken, the model is behaving erratically, or the market environment has shifted in a way the agent cannot handle. You can learn more about configuring these exits in How to control risks in autonomous trading systems that use MCP.

In all cases, the underlying funds remain in your wallet. The halt is immediate and automatic. You, as the owner, receive a notification via webhook or dashboard alert. You can then review the agent's logs, adjust the strategy, lower the cap further, or revoke the key entirely. The agent never has the power to restart itself, create a new key, or move funds to a new address. The kill switch is a true revocation, not just a pause. If you decide to resume trading, you must generate a new scoped key and explicitly authorize it.

How should you choose your first cap and drawdown limit?

Start with a number you can afford to lose entirely. Trading can lose money, including the full amount allocated to an agent, so the cap should be sized as a small fraction of your total capital rather than the majority of it. You might allocate five or ten percent of your trading wallet to a single agent and set the spend cap at that same amount. This leaves the rest of the wallet untouched and available for other strategies, manual trading, or simply as a reserve. If the agent performs poorly, the damage is contained.

For the drawdown limit, apply it to the agent's allocated budget, not to your total net worth or total wallet balance. If you give an agent one thousand dollars, a ten percent drawdown limit means trading stops if the value falls to nine hundred dollars. That is a clear, bounded loss. Do not set a drawdown limit so wide that it becomes meaningless. A fifty percent drawdown on a small test allocation is still a painful loss if you are learning how the agent behaves. You might start with a drawdown limit of five or ten percent for new agents and only widen it after extensive observation.

Paper trading exists for exactly this calibration. Before you authorize a live key, run the agent against market data with paper balances. Observe how aggressively it enters positions and how quickly it might approach a cap. Use those observations to set a live cap that matches your risk tolerance. Increase caps only after you have seen consistent, controlled behavior over days or weeks. Scaling up gradually is safer than giving a new agent a large budget on day one. You can also simulate a drawdown scenario by observing how the agent behaves when the paper portfolio declines.

You can also set a tiered approach. Allocate a small budget and a tight drawdown limit for the first month. If the agent respects the boundaries and the strategy performs as expected in paper tests, you can raise the cap and loosen the drawdown limit slightly. Keep the limit tight enough that a single bad session cannot erase the allocation. The goal is to survive long enough to evaluate whether the strategy makes sense. Consider these steps when you start:

1. 01Run the agent in paper trading with a one thousand dollar cap and a five percent drawdown limit.
2. 02Observe for one to two weeks, noting how often it approaches the cap and how it responds to rejection.
3. 03Authorize live trading with the same numbers, not larger ones.
4. 04Review weekly and adjust only if the behavior is stable and the market conditions are well understood.