How developers should set spend caps and drawdown limits for trading agents in 2026

A spend cap is a hard ceiling on the total capital an agent can deploy, and a drawdown limit is the maximum peak-to-trough loss you are willing to accept. Together they form the outer boundary of what an agent can risk, regardless of how confident its model is. In 2026, the correct way to set them is to treat them as infrastructure-level invariants, not as polite instructions inside a prompt.

What is the difference between a spend cap and a drawdown limit?

A spend cap controls the total notional value that an agent can put to work. It answers the question of how large the agent is allowed to trade. If you set a spend cap of ten thousand dollars, the agent cannot open positions with a combined notional exposure exceeding that amount. This is important because an agent that sizes orders in plain US dollars may still accumulate overlapping exposures across multiple markets. The API normalizes venue-specific contract math, but the developer must still decide the aggregate boundary.

A drawdown limit, by contrast, controls the loss from a peak value. It answers the question of how much of the allocated capital can disappear before the agent must stop. If the account reaches a peak of ten thousand dollars and you set a ten percent drawdown limit, the agent must halt or flatten when the equity drops to nine thousand dollars. This limit is about preserving capital, not about controlling position size.

You need both because they guard against different failure modes. An agent can stay within a spend cap and still bleed the account slowly through a series of small losses. An agent can also respect a drawdown limit while taking positions so large that a single gap move destroys the account before the drawdown logic can react. The two limits work together. One manages exposure, the other manages erosion.

Where should these limits live in the stack?

The most common mistake is to place these constraints inside the agent's prompt. A prompt-based limit is a suggestion, not a boundary. A model that is misaligned, confused, or jailbroken can ignore it. In 2026, limits belong at the infrastructure layer, enforced by the API and the scoped key that connects the agent to the markets.

Application-level enforcement, such as a check inside the agent's Python script before calling the API, is only slightly better than a prompt. If the script crashes, is patched, or encounters a race condition, the check disappears. Network-level enforcement means the API gateway itself holds the budget state. The request either carries sufficient budget or it is dropped. This is the only architecture that survives bugs in the agent logic.

Felix implements this through budget caps and position limits that are attached to the key itself. The agent can request trades, but the infrastructure rejects any request that would breach the cap. This means the agent never holds the power to exceed its mandate. Even if the underlying model is compromised, the key simply does not have permission to spend more than the owner authorized. This architecture is non-custodial by construction. Funds sit in a wallet the owner controls, and the agent can spend within limits but can never withdraw to itself. Withdrawal addresses are owner-approved only.

If you want to understand the broader safety model, read How to run an AI trading agent with real money, safely. For the specific mechanics of configuring these boundaries, see How to set spend caps and drawdown limits for trading agents. Developers should also think about the order sizing layer. Because Felix normalizes order input to plain US dollars, you do not need to write venue-specific contract math in your agent logic. You still need to decide how many dollars each signal deserves. The article How to size orders in dollars when building a trading agent covers that decision in detail. The spend cap is the aggregate ceiling; the per-order size is the allocation method.

How do you size a spend cap for an agent that trades multiple markets?

An agent that trades across stocks, crypto, perps, options, and prediction markets faces a complex exposure map. A spend cap must be global, not per venue. If you allow five thousand dollars for stocks and five thousand dollars for crypto, the agent can still concentrate ten thousand dollars in correlated risk during a macro downturn. The simplest approach is to set a single aggregate spend cap in US dollars and let the API enforce it across all connected markets. This prevents the agent from hiding leverage in one venue while appearing conservative in another.

Correlation risk is subtle. Suppose your agent holds a long stock position in a technology company and a long perp position in a broad technology index. On paper, these are different markets and different instruments. In practice, a single macro event can move both in the same direction. If your spend cap is partitioned by market type without a global ceiling, the agent can inadvertently construct a concentrated directional bet that exceeds your total risk tolerance. Always ensure the global cap binds first, and use sub-limits only to shape allocation, not to permit leakage.

• ·Correlation risk. Two positions in similar assets on different venues add up to one concentrated bet.
• ·Margin versus notional. A perp might require only a fraction of its notional value in margin, but the spend cap should reflect the full notional risk.
• ·Options asymmetry. A short option can carry theoretically unlimited risk in some underlyings, while a long option is capped. The spend cap should account for the worst-case notional, not the entry cost.
• ·Prediction market binary outcomes. These resolve to zero or one, so the notional at risk is the full position size, regardless of current mark price.

Suppose you allocate a twenty thousand dollar spend cap to an agent. You might decide that no more than thirty percent can sit in options, no more than fifty percent in perps, and no more than twenty percent in prediction markets. These are not prompts. They are scoped constraints enforced by the key. The agent does not get to choose whether to obey them.

What happens when an agent hits its limit?

The behavior at the boundary matters as much as the boundary itself. When a spend cap is reached, the API should reject new orders. The agent may still hold existing positions, but it cannot increase notional exposure. This is a hard stop. The agent should receive a clear error indicating that the budget is exhausted, and it should not retry the same order in a loop.

A drawdown limit requires a more nuanced response. If the limit is breached because of open position depreciation, simply blocking new orders is not enough. The account is still bleeding. The correct response is to flatten positions and revoke trading authority until the owner reviews the strategy. This is where the panic and kill switch becomes essential. It is the final line of defense.

Some developers prefer a softer approach, allowing the agent to close positions but not open new ones. This can be reasonable for a human trader, but for an agent it creates ambiguity. The agent may start churning, closing and reopening slightly smaller positions to stay under a technical threshold. Hard flattening removes that ambiguity. The owner can then reset the limit, reauthorize the key, or adjust the strategy. The transition from normal trading to a halted state should be observable. Your webhook or MCP client should log the rejection or flattening event immediately. If the agent is running autonomously, it needs to know that its session is over. Continuing to compute signals while unable to trade wastes resources and can create queue backlogs. Design the agent to enter a passive monitoring mode when the key returns a cap error.

How should you test limits before authorizing live trading?

Paper trading exists for testing, and you should use it to verify that your agent respects infrastructure-level caps. However, paper trading does not simulate the emotional and liquidity realities of live markets. It is a plumbing test, not a proof of safety. The article Why paper trading misleads beginners who build AI agents explains this distinction in depth.

1. 01Verify that an order exceeding the spend cap is rejected by the API, not by the agent's internal logic.
2. 02Simulate a drawdown by manually adjusting the mock equity curve if possible, and confirm that the kill switch triggers.
3. 03Test repeated cap breaches to ensure the agent does not spam retry requests.
4. 04Validate that sub-limits for different market types are enforced when the agent attempts to shift allocation.
5. 05Confirm that revocation of the key prevents all trading, including cancels or modifications.

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

{
  "key": "YOUR_KEY",
  "spend_cap_usd": 5000,
  "drawdown_limit_percent": 5,
  "market_scope": ["stocks", "crypto", "perps", "options", "prediction_markets"],
  "panic_action": "flatten_and_revoke"
}

This is illustrative. The actual fields and endpoint paths are documented at /docs. The principle is that the limit configuration is a property of the key, not a variable inside the agent's reasoning loop. When you graduate to live trading, start with a spend cap that represents no more than a few percent of your intended allocation. Observe how the agent behaves when it approaches the limit. Does it gracefully reduce size, or does it attempt to find edge cases? Some agents, especially those built on general reasoning models, may try to interpret the cap as a soft guideline. The infrastructure must treat it as a hard wall. Only after a week of clean live behavior should you consider raising the ceiling. This staged approach is tedious, but it is far less costly than recovering from a single uncapped session.

Why do drawdown limits need a kill switch companion?

A drawdown limit checked only at order time is insufficient. Markets can gap. A position opened within the spend cap can move against the agent while everyone sleeps. By morning, the drawdown limit may be violated even though no new orders were placed. Without an automatic kill switch, the limit is just a retrospective observation.

The kill switch serves two functions. First, it flattens all open positions, converting market risk into cash or stable value. Second, it revokes the key so the agent cannot trade again until the owner explicitly reauthorizes. This is the only reliable way to stop a runaway process. An agent that loses money is not necessarily malicious, but it is dangerous. A misaligned model may double down on a losing strategy, convinced that the next trade will recover the loss.

Some developers hesitate to use automatic flattening because they fear missing a recovery. This is a human bias that does not belong in agent design. An agent that has breached its drawdown limit has already demonstrated that its strategy or its environment is not behaving as expected. Hope is not a safety control. The kill switch removes the agent from the market so the owner can diagnose the problem with a clear head and a stable account balance. The kill switch must be outside the agent's control. If the agent can disable its own safety mechanism, the mechanism is decorative. In a non-custodial system, the owner holds the revocation power. The agent never sees the private key that controls the wallet. It only holds a scoped API key that the owner can invalidate in seconds. Trading can lose money, including everything. Limits and kill switches do not guarantee profitability. They guarantee that the agent cannot lose more than the owner predefined. That is the difference between a controlled experiment and an uncontrolled liability. Set the drawdown limit conservatively, pair it with a kill switch, and treat every live deployment as a test of the safety system first and the strategy second.