How to paper trade with an AI agent without giving up custody

Paper trading with an AI agent means the agent places orders, tracks positions, and reacts to market data, but no real money moves. On Felix, paper mode uses the same API infrastructure, the same wallet, and the same non-custodial controls as live trading, with the only difference being that the execution layer simulates fills and updates a virtual balance instead of debiting real funds. This lets you validate strategy logic, safety guardrails, and dollar-normalized sizing across stocks, crypto, perpetuals, options, and prediction markets without exposing capital to loss. Because the simulation is stateful, you can observe how the agent behaves over days or weeks, track virtual profit and loss, and refine prompts or parameters before any actual capital is committed.

What is paper trading for an AI agent?

For an AI agent, paper trading is not a separate sandbox with fake data. It is a stateful simulation layer that mirrors the live order path. When your agent sends an order, the API checks the same scoped key, the same budget cap, and the same position limit that would apply in live mode. If the order passes those checks, the paper engine records a simulated fill at the prevailing market price, updates virtual balances, and emits the same webhooks or MCP tool responses that live trading would emit. The agent cannot tell the difference unless you inspect the mode flag. This fidelity matters because it lets you test not just the strategy but the entire automation stack, including error handling, logging, and retry logic. You can observe how the agent responds to partial fills, rejected orders, and balance updates exactly as it would in production. The paper engine also tracks fees and margin requirements using the same normalization rules as live trading, so your virtual PnL reflects the cost structure you will face later. The API normalizes orders in plain US dollars, which means your agent can specify a five hundred dollar position without calculating contract sizes, tick values, or margin multipliers. In paper mode, this normalization runs through the same logic as live trading, so you can verify that a five hundred dollar order in perpetual futures produces the same expected position shape as a five hundred dollar order in stocks. When the paper engine returns a fill, it includes the executed dollar amount, the simulated fees, and the updated virtual balance. Your agent can parse these fields and update its internal state exactly as it will in production. This consistency is what makes paper trading useful for integration testing rather than just strategy brainstorming. You can leave a paper trading agent running continuously. The virtual portfolio accumulates simulated positions, and the API continues to enforce daily or weekly budget caps just as it would with real money. If your agent is designed to rebalance a portfolio every hour, you can let it run for a full week in paper mode and review the virtual trade history for anomalies. This longitudinal testing is hard to replicate with manual backtests because it includes API latency, rate limit handling, and the idiosyncrasies of your hosting environment.

How does paper trading stay non-custodial?

Non-custodial design means your funds remain in a wallet you control, and the agent can only spend within limits you set. Paper trading preserves this model exactly. You do not deposit funds into a custodial paper account. Instead, the paper engine reads your wallet balances to compute available buying power, then tracks virtual positions against those balances. Because the API never takes custody, there is no risk of the agent withdrawing simulated profits to itself. The same owner-approved withdrawal addresses and panic kill switch remain in effect. If you revoke the key, paper access dies along with live access. This continuity is important for developers who want to test automation without creating a security gap. Even in paper mode, the system enforces that the agent cannot request a withdrawal, cannot change the destination address, and cannot escalate its own permissions. These constraints are hardcoded, not policy-based, so they hold in both simulation and reality. If you connect your agent through MCP tools, the non-custodial guarantees still hold. The MCP server cannot bypass the scoped key permissions, and it cannot see the wallet seed or private keys. It only receives the same responses that the REST API would send. In paper mode, this means the LLM can call a trading tool, receive a simulated fill, and update its context, all without any risk to your funds. You can test aggressive prompt strategies or let the model explore tool usage without fear that a misunderstood instruction will drain your wallet. The paper layer is a strict boundary. Your wallet remains under your control throughout. You can inspect balances on chain or at your stock broker independently of the API. If you decide to stop paper trading, you simply revoke the key. There is no withdrawal process from a custodial paper account because there was never a deposit. This eliminates the settlement delays and counterparty risk that often accompany paper trading on traditional platforms. The funds never leave your possession, and the agent never gains the ability to move them. A practical checklist for non-custodial trading beginners covers the wallet setup in more detail.

Why test safety controls in paper mode?

Safety controls are only useful if they trigger correctly before real money is at stake. Paper mode lets you verify that your scoped key, budget cap, position limit, and exit plan behave exactly as intended. For example, if you set a maximum position size of one thousand dollars in options, the paper engine should reject a simulated order for two thousand dollars. If it does not, you have a configuration error to fix before going live. The same applies to kill switches. You should test flattening positions and revoking access in paper mode to confirm the latency and sequence of events. This validation is especially critical when using MCP tools, because the LLM may interpret tool responses differently than a raw REST client. Testing the full loop, from prompt to simulated fill to safety trigger, surfaces integration bugs that unit tests miss. You can also test edge cases, such as what happens when the agent sends an order that exceeds the daily budget cap after a series of smaller trades. Watching the paper engine reject that final order gives you confidence that the live budget will be respected. Exit plans deserve explicit testing in paper mode. If your strategy includes a take-profit or stop-loss condition, configure the exit plan in the API and let the agent trigger it. Watch the sequence: the agent sends the exit order, the paper engine checks the plan, simulates the fill, and updates the virtual balance. If the exit plan is misconfigured, you will see the error in the logs before the error costs you money. This is also the moment to test what happens when multiple safety controls conflict. If a position limit and a daily budget cap both apply, the paper engine should reject an order that breaches either threshold. Observing these interactions in simulation lets you tune the hierarchy of controls without financial stress. Kill switches are the last line of defense. In paper mode, trigger the panic switch manually and measure how long it takes for the agent to receive a revocation notice and for the virtual positions to flatten. You should see a clear sequence: the switch flips, open orders cancel, positions close at market, and the key loses all trading authority. If any step lags or fails, you have a bug to fix. This is not paranoia. It is engineering discipline. The goal is to make the safety path as reliable as the trading path. How a single API keeps AI trading agents safe across every market explains the underlying model.

How do you set up a paper trading agent?

Setup follows the same path as live trading, with one authorization difference. First, create an API key scoped to the markets you want to test. Second, set a live budget cap of zero dollars. This cap forces the key into paper mode because the system cannot allocate real funds. Third, attach position limits and an exit plan if your strategy requires them. Fourth, connect your agent via the REST API or MCP tools. The agent can then place orders, query balances, and receive market data exactly as it would in production. Developers can connect agents through the REST API or through MCP tools in environments like Claude or Cursor. Both paths support paper mode identically. If you are using MCP, the tools will expose a paper flag or respect the zero-dollar live cap on the key. Your agent should not need to know which transport it is using. The abstraction layer is the API, not the client library. This means you can prototype in a notebook with raw HTTP calls, then migrate the same logic to an MCP server without changing the order logic. The exact request schema is in the docs; the shape looks like this:

curl -X POST ... \
  -H "Authorization: Bearer YOUR_KEY" \
  -d '{
    "market": "perpetual_futures",
    "side": "buy",
    "size_usd": "100.00",
    "mode": "paper"
  }'

After the first simulated order, inspect the response for fill price, fees, and virtual balance impact. Compare these against the market data your agent consumed to ensure the sizing math is correct. If you are using dollar sizing, confirm that the paper engine translated your five hundred dollar order into the correct number of contracts or shares for the venue. This is a good time to test partial fills and rejected orders, because the error shapes in paper mode match the live shapes. You should also run a full trading session where the agent makes decisions autonomously for several hours. This reveals prompt drift, loop errors, and resource exhaustion that manual single-order tests do not catch. Run a closed-loop test. Feed the agent a stream of market data, let it generate a signal, send the order, and verify the virtual balance update. Then feed the next bar of data and repeat. After ten or twenty cycles, inspect the trade log for consistency. Did the agent double-count a position? Did it ignore a partial fill? Did it try to trade a market that was not in the key scope? These are the bugs that paper mode is designed to catch.

When should you switch to live trading?

Switch to live trading only after you have validated the strategy logic, the safety guardrails, and the agent's error handling. A reasonable checklist includes: at least one hundred simulated orders across the market types you intend to trade, successful triggering of every safety limit you configured, and a manual test of the kill switch. You should also verify that your logging pipeline captures paper fills correctly, because live debugging without logs is risky. Once you are satisfied, you do not need to change the agent code. You simply update the key's live budget cap to a non-zero amount and authorize the key for live trading. The agent will now execute real orders against the same wallet. Start with a small live budget, even smaller than your paper testing allocation, because emotional and system behavior can change when real losses are possible. Some agents that behave perfectly in paper mode will behave differently when the API returns real PnL figures. The code is the same, but the downstream actions, such as logging to external systems or alerting you via chat, may reveal latency or rate limits you did not notice before. A small live budget is a production test of your infrastructure under real emotional and financial gravity. You do not need to go live in all five market types at once. If your agent is designed to trade crypto and prediction markets, you can authorize live trading for crypto while keeping prediction markets in paper mode. The per-market scoping lets you stage your rollout. This is useful when one market is more mature in your strategy than another. You can also keep a permanent paper key for experimental strategies while a separate key runs live capital. There is no restriction on the number of keys you can create. How to take an AI trading agent live with real money walks through the authorization step.

What mistakes do developers make with paper trading?

The most common mistake is treating paper trading as a proof of performance rather than a test of infrastructure. Paper results do not predict live profits, because slippage, liquidity, and latency differ between simulation and real markets. Use paper mode to verify that the agent does what you expect, not to prove that a strategy is profitable. Another mistake is skipping safety tests. Developers often assume that a zero-dollar live cap is sufficient protection, but they forget to test what happens when the agent encounters an error or retries aggressively. A third mistake is using different code paths for paper and live. If your agent branches on mode, you are not testing the real execution path. Keep the code identical and let the API layer handle the simulation. Another subtle mistake is assuming that paper fill prices will match live fill prices. In a simulation, the paper engine typically fills at the midpoint or last traded price, depending on the venue connector. In live trading, your fill depends on the order book depth, your order size, and the time of submission. This means a strategy that appears to capture arbitrage in paper mode may fail in live mode because the price moved during execution. Paper trading validates the agent, not the alpha. It tells you whether the agent can execute the strategy faithfully. It does not tell you whether the strategy is profitable after market impact. Poor logging is another mistake. Developers often print simulated fills to the console and assume they will set up proper logging later. When they go live, they have no structured record of what the agent did or why. Set up your logging pipeline in paper mode. Capture the full request, the full response, the agent's reasoning trace, and the safety control state. This discipline pays off when you need to audit a live loss. Finally, some developers forget to test the transition itself. Revoke the key, reauthorize it, and confirm the agent resumes cleanly. These small checks prevent surprises when real capital is on the line. Remember that trading can lose money, including everything, so every hour spent validating in paper mode is a hedge against a costly automation error.