How to set spend caps and drawdown limits for trading agents

You set spend caps and drawdown limits for trading agents by configuring hard constraints at the API key level before the agent connects to any market. These limits are enforced by the infrastructure itself, not by the agent's reasoning, which means the agent cannot talk its way around them or exceed them due to a reasoning error. A single API normalizes these controls across stocks, crypto, perps, options, and prediction markets so the owner does not need to implement different logic for each venue. Without these controls, an agent that misinterprets a signal could deploy an entire wallet balance into a single leveraged position, or continue doubling down after a string of losses. The caps make the worst-case scenario predictable and bounded. You configure them once, and they follow the key wherever it trades.

What are spend caps and drawdown limits?

A spend cap is an absolute ceiling on the notional capital an agent can deploy over a defined window. Suppose you set a daily spend cap of five hundred dollars. Once the agent has placed orders that sum to that amount, the API rejects any additional order creation until the window resets or the owner explicitly raises the cap. This prevents runaway accumulation of positions when an agent misinterprets a signal or enters a loop. Spend caps can use rolling windows that reset every twenty-four hours from the first trade, or calendar windows that reset at a fixed time. You choose the cadence that matches your strategy review cycle. Some owners prefer hard daily budgets to force a daily review. Others prefer weekly caps to allow the agent to recover from a slow start without arbitrary daily interruptions.

A drawdown limit is a loss threshold measured against a baseline account value. Imagine you define a threshold of two percent from the starting balance or five percent from the highest watermark reached during the trading period. If the portfolio value crosses below that threshold, the infrastructure intervenes. The intervention can range from blocking new orders to flattening existing positions and revoking the API key. This addresses the risk that an agent will continue trading into a losing streak, averaging down, or holding underwater positions in the hope of a recovery. The drawdown monitor runs continuously on market data updates, so it can intervene even when the agent is idle.

These two controls serve different purposes. A spend cap limits exposure buildup. A drawdown limit limits realized and unrealized losses. You typically want both, because an agent could hit a drawdown limit without ever exhausting a spend cap, or exhaust a spend cap while holding positions that later drift into deep losses. Together they define a box inside which the agent is free to act.

Why do agents need hard limits instead of soft prompts?

It is tempting to believe that a carefully written prompt can keep an agent safe. You might instruct the model to never risk more than one percent per trade or to stop trading after three losses. This does not work reliably. Language models are probabilistic reasoners. They can hallucinate justifications, misread their own tool outputs, or reinterpret instructions when context windows grow long. A prompt is a request, not a guarantee. In practice, an agent might encounter an edge case not covered by its prompt, or it might reason that a one percent risk rule applies to the initial position size but not to the accumulated margin in a leveraged trade. The model is not a calculator. It is a language predictor that can sound confident while making arithmetic mistakes.

Hard limits are enforced by the infrastructure that sits between the agent and the market. The API evaluates every order against the configured cap before it reaches a venue. The agent does not get to debate the limit. This is the difference between asking a driver to obey the speed limit and installing a speed governor on the engine. For a treatment of common misconceptions about LLM self control in trading, see what most people get wrong about LLM trading with real money.

The non-custodial architecture reinforces this. The owner holds the funds in a wallet that the agent cannot drain. Withdrawal addresses are fixed at setup. The agent can spend within its scoped authority, but it cannot send funds to itself or to any unapproved address. Even if the agent's reasoning is compromised, the financial damage is bounded by the caps and the custody model.

How does one API enforce limits across five market types?

Stocks, crypto spot, perpetual futures, options, and prediction markets all use different contract specifications. A perps venue might denominate positions in coin quantity with margin in a specific stablecoin. An options venue might use strike widths and multiplier logic. A prediction market might use share prices between zero and one. If you had to write drawdown math for each venue, you would need five separate risk engines and a reconciliation layer to aggregate them.

The API abstracts this by normalizing every order into a plain US dollar value. You state the size in dollars, and the infrastructure translates that into the correct number of shares, contracts, or shares for the specific venue. This means your spend cap means the same thing whether the agent is buying stock on a stock broker, opening a perp position on a perps venue, or buying outcome shares on a prediction market. The drawdown calculation also runs on a unified dollar balance rather than a patchwork of margin accounts and wallet balances. For options, the API translates the dollar notional into the correct number of contracts based on the multiplier and the underlying price at entry. For prediction markets, it treats the share price as a probability and sizes the order so that the maximum loss is the dollar amount you specified. This means an agent cannot accidentally buy ten thousand shares at a dollar each when it meant to risk ten dollars total. The normalization layer protects against unit confusion.

When an agent holds a long stock position and a short perp position in the same underlying, the API still tracks the gross spend against the cap and the net mark-to-market against the drawdown. You do not need to manually reconcile ledgers across venues. The owner sees a single view of deployed capital and running profit and loss. The owner configures the limits once in the dashboard or via the REST API, and those same numbers apply to every market the key is authorized to access. If you later disable a market type, the spend cap does not retroactively change. It simply stops counting new orders against that venue. This makes it easy to iterate. You might start with crypto and prediction markets, then add stocks later, without redesigning your risk model. The drawdown limit continues to track the total portfolio value across whatever markets are active.

Because the API is non-custodial by construction, the owner does not need to prefund separate accounts at each venue. The funds remain in the owner's wallet. The API routes orders and tracks the aggregate notional exposure and running profit and loss across all connected markets. You can read more about the normalization layer in one API for every market. The result is that a single spend cap and a single drawdown limit can govern an agent trading across multiple asset classes simultaneously.

How do you configure a spend cap and drawdown limit?

You define these parameters when you create or scope an API key. The owner specifies the maximum spend per time window, the drawdown threshold, and optional position limits per market. The agent receives a key that carries these constraints. It does not need to track them in its prompt, though it may query its current budget status to make decisions. You can create separate scoped keys for different strategies, each with its own caps and market permissions. This isolates a high-risk strategy from a conservative one without maintaining separate wallets or infrastructure.

Time windows for spend caps can be aligned to calendar boundaries or set as rolling windows. A rolling daily window tracks the last twenty-four hours of activity. A calendar daily window resets at a fixed hour, such as midnight UTC. Rolling windows are useful for strategies that trade at irregular intervals. Calendar windows are useful for daily reporting and reconciliation. You can also set a hard lifetime cap on a key, which is useful for experimental agents that should not be allowed to trade indefinitely without owner review.

The exact request schema is in the docs; the shape looks like this:

POST /keys
Authorization: Bearer YOUR_KEY
Content-Type: application/json

{
  "scope": "trading",
  "spend_cap": {
    "amount": 1000,
    "currency": "USD",
    "window": "1d"
  },
  "drawdown_limit": {
    "type": "percentage",
    "value": 5.0,
    "baseline": "high_water_mark"
  },
  "position_limits": {
    "max_notional_per_position": 200
  },
  "markets": ["stocks", "crypto", "perps", "options", "prediction_markets"]
}

This is illustrative. The actual endpoint and field names may differ, so refer to the documentation at /docs. The key point is that the constraints are bound to the credential, not to the agent's behavior. You can rotate the key, lower the caps, or revoke access without touching the agent's code.

You can also layer controls. A spend cap might govern total daily deployment, while a position limit restricts any single bet to a specific dollar amount. An exit plan can define take profit or stop loss logic at the position level. Together these form a budget box that the agent operates inside. For a practical starting guide, see how to start an AI trading agent with hard limits.

What happens when an agent reaches a limit?

When the cumulative notional spend reaches the cap, the API returns an error on any new order request. The agent receives a clear rejection message. It can then decide to wait, rebalance, or request a cap increase, but it cannot force the trade through. Spend cap rejections are immediate and synchronous. The API does not provide a mechanism for the agent to appeal the decision or to borrow from tomorrow's budget. The boundary is absolute. This is by design. A flexible cap would not be a cap. This prevents the common failure mode where an agent enters a loop and places dozens of orders in rapid succession.

You should test how your agent handles rejection. Some agents will gracefully log the error and wait. Others, depending on their tool use patterns, might retry aggressively. You want to discover this behavior and fix the retry logic before going live. If the agent does not handle rejection gracefully, you may need to add explicit error handling in its tool use loop rather than relying on the model to infer the correct response.

If the portfolio hits the drawdown limit, the response is more severe. The infrastructure can trigger a flattening sequence: it submits exit orders to close all open positions, cancels pending orders, and then disables the API key. This is the panic or kill switch. The kill switch is distinct from a manual stop. A manual stop requires the owner to notice the problem and press a button. The drawdown limit is automatic. It triggers even if the owner is asleep or the notification channel is delayed. This is essential for agents that operate around the clock across global markets. The owner retains the ability to reauthorize the key after reviewing the agent's logs and strategy, but the agent cannot override the shutdown. This is described in more detail in how to run an AI trading agent with real money, safely.

The sequencing matters. The system checks the drawdown limit continuously, not just at order time. A position can drift into loss while the agent is idle. The drawdown monitor runs on market data updates, so it can intervene even if the agent is not actively placing orders. This is important for positions in volatile markets like perps or crypto where prices move quickly. Drawdown interventions can be asynchronous. For liquid markets, the exit sequence completes quickly. For illiquid options or thin prediction markets, the exit orders might rest on the book. The kill switch prevents new orders but does not guarantee instant fills. The owner should understand that the final realized loss could exceed the drawdown limit by a small amount due to market gaps or slippage. The limit stops the bleeding; it does not rewrite the trade history.

How do you test limits before live trading?

You should not discover your safety boundaries in production. Felix provides a paper trading environment that mirrors the live API, including the same spend cap and drawdown logic. You can configure a paper key with aggressive limits, run the agent, and observe how it behaves when it approaches boundaries. This lets you verify that the agent handles rejection messages gracefully and does not enter error loops. Paper trading is also the right place to test partial fills and cancellation behavior. Suppose the agent sends an exit order to close a position, but the order only fills partially before the drawdown limit triggers. You want to see whether the kill switch cancels the remaining open order and submits a market order to close the residual exposure. These mechanics are hard to reason about from documentation alone. Running the scenario in paper mode reveals the actual sequence.

To move to live trading, the owner must explicitly authorize a live key. The authorization step is a deliberate human gate. It ensures that you have reviewed the caps, confirmed the wallet funding, and understood the venues the agent will access. You should test edge cases in paper mode first. For example, simulate a scenario where the agent hits the spend cap mid-rebalancing, or where a sudden market drop triggers the drawdown limit. Watching the flattening behavior in paper mode gives you confidence that the kill switch will work correctly when real money is at risk.

Remember that trading can lose money, including everything. Paper trading results do not guarantee live performance. Slippage, liquidity gaps, and API latency at venues can differ between simulation and production. The limits are there to cap the damage, not to eliminate it.