How developers can paper trade safely with AI agents

Paper trading is a simulated environment where an AI agent submits orders against live market prices without committing real capital. It lets developers validate strategy logic, API integration, and safety controls before authorizing a live key. The goal is not to prove the agent will make money, but to confirm it behaves exactly as intended when connected to real data.

What is paper trading and why use it?

Paper trading on Felix works like a controlled shadow system. The agent connects through the same MCP tools or REST endpoints that it would use for live trading, but the orders are tagged for simulation. Balances are virtual, and no funds leave the owner’s wallet. The agent still receives real market data, so its logic is tested against actual prices, spreads, and volatility. This matters because an agent that misinterprets a signal in paper will misinterpret it in live trading. The difference is that in paper, a mistake costs simulated dollars rather than real ones.

Developers should treat paper trading as a rigorous engineering stage. It is the place where you verify that your prompt engineering produces the intended outputs, that the API normalizes venue-specific contract math correctly, and that your safety controls are wired properly. Because trading can lose money, including everything, paper trading is the safest place to discover a bug in position sizing, a loop in error handling, or a misaligned prompt. Felix requires explicit owner authorization to move from paper to live, so the simulation window acts as a deliberate buffer against premature deployment. You can test across stocks, crypto, perps, options, and prediction markets from the same integration, which reduces the surface area for market-specific bugs.

Traditional automated bots follow rigid deterministic rules. AI agents, by contrast, interpret natural language prompts and can exhibit non-deterministic outputs. A prompt that instructs the agent to reduce exposure could be interpreted as closing half a position or closing the entire position depending on context. Paper trading exposes these ambiguities before they become expensive errors. You can observe how the agent reasons under different market conditions and refine the prompt until the behavior is repeatable. This iterative refinement is difficult to do safely in live markets where every test has a cost.

How do you set up a paper trading environment?

Start by generating a scoped API key that is restricted to paper mode. Even though the balances are fake, you should configure the same spend caps, position limits, and exit plans that you intend to use live. This lets you test whether the API enforces those boundaries before any real capital is at stake. If your agent will trade multiple market types, set up the paper key to access all of them. The API normalizes order sizing in plain US dollars across stocks, crypto, perps, options, and prediction markets, so your agent logic can remain consistent and readable.

Connect the agent through MCP if you are using Claude, Cursor, or another MCP client, or through the REST API if you are building a standalone service. The connection method does not change the safety model. The agent operates under the same scoped permissions in paper as it will in live. You should also design your prompts to reference the current mode explicitly so the agent knows it is in simulation. How to design prompts that keep trading agents within bounds covers techniques for keeping the agent aligned with owner intent regardless of environment.

Some developers mistakenly treat paper trading as a demo environment with loose constraints. This is a mistake. If you allow the agent to trade ten thousand simulated dollars without a cap, you learn nothing about whether your safety limits work. Configure the paper key with the same scoped permissions you plan to enforce live. If the agent is meant to trade only perps and options, restrict the key accordingly. If it is meant to hold no more than three positions at once, set that limit in paper and watch what happens when the agent tries to open a fourth. These tests reveal whether the API boundaries are effective or whether the agent can coax its way around them.

Before you run the first session, define what success looks like. A common mistake is to start paper trading without a checklist. Decide which markets you will test, what position sizes the agent should use, and which errors you expect it to handle gracefully. Write down the expected behavior for the kill switch, the spend cap, and the drawdown limit. If you do not define these expectations in advance, you will find yourself rationalizing bad behavior after the fact.

{
  "market_type": "perps",
  "side": "buy",
  "usd_size": "150.00",
  "key": "YOUR_KEY",
  "mode": "paper"
}

What should you test before going live?

Use a structured checklist rather than intuition. The following areas are essential:

• ·Order correctness. Verify that the agent maps its internal signals to the correct side, market, and USD amount. A single malformed field can turn an intended hedge into an unintended directional bet. Check that the agent understands the difference between market and limit instructions if your strategy uses both.
• ·Safety control enforcement. Confirm that spend caps and drawdown limits trigger halts when thresholds are reached. How to set spend caps and drawdown limits for an MCP trading agent explains how to configure these boundaries so they protect owner funds in both paper and live modes.
• ·Error handling. Introduce failures deliberately. Disconnect the network briefly, send an invalid symbol, and exceed rate limits. The agent should pause and log, not retry aggressively or fall into an infinite loop.
• ·Kill switch response. Test the panic button. It should flatten open positions and revoke the key immediately. What beginners get wrong about kill switches for trading agents describes common configuration errors that leave agents exposed when they should be halted.
• ·Multi-market allocation. If your strategy spans a stock broker and a perps venue, confirm that the agent splits capital according to your plan and does not double-allocate the same nominal USD balance.
• ·Audit logging. Every simulated order, rejection, and safety trigger should leave a trace you can review later. Observability in paper is practice for incident response in live.

Testing these areas prevents surprises. An agent that looks profitable on paper but ignores kill switches or exceeds caps is not ready for a live key. It is a liability wearing the mask of a strategy.

How do you interpret paper trading results?

Do not focus on profit and loss as a scorecard. Paper P&L is a byproduct of simulated fills, not a promise of future returns. Instead, measure behavioral metrics. Look at order accuracy, the ratio of intended actions to executed actions, and the frequency of safety triggers. If the agent hit a spend cap three times in one week, that is valuable data about its aggression or a flaw in its sizing logic. If it placed orders outside of allowed market hours, that reveals a prompt or scheduling bug.

Understand that paper environments typically assume idealized fills. A limit order may execute in paper when the live market would leave it unfilled due to spread or queue position. Slippage on market orders is often understated. This means a strategy that appears robust in paper may still struggle in live markets. Latency is also idealized; paper infrastructure may respond faster than live paths during periods of high volatility. The absence of market impact means paper cannot teach you how large positions affect low-liquidity options or prediction markets.

One useful technique is to pre-record a set of market scenarios and manually determine what the agent should do in each case. During paper trading, compare the agent's actual decisions against this expectation matrix. Discrepancies are not failures; they are signals that the prompt, the tool definition, or the data feed needs adjustment. This approach shifts the evaluation from financial performance to specification compliance, which is a healthier metric for engineering teams.

Keep a detailed log of every paper session. Note the market conditions, the agent’s decisions, and any anomalies. When you later authorize live trading, you will need a baseline for comparison. If live behavior diverges sharply from paper, the logs will help you identify whether the cause is market friction, a prompt drift, or an API difference. Good records are the bridge between simulation and reality.

When should you authorize a live key?

Authorization should be a deliberate decision, not a gradual drift. The owner must explicitly approve the live key after reviewing paper results. Before that happens, confirm that the agent has demonstrated consistent behavior across multiple sessions and market conditions. A single profitable run is not enough. You need evidence that the agent respects scoped permissions, handles errors, and responds to safety controls every time. Consistency is more important than simulated returns.

Live keys should start with conservative boundaries. Use the same non-custodial structure: funds remain in a wallet the owner controls, withdrawal addresses are owner-approved only, and the agent can spend within limits but never withdraw to itself. How algorithmic traders can automate without giving up custody outlines why this architecture matters for automated strategies. You may choose lower spend caps for the first live week than you allowed in paper, then scale gradually as the agent proves itself under real execution conditions.

Remember that trading can lose money, including everything. Paper trading removes financial risk during development, but live trading reintroduces it immediately. Authorize only when you are confident that the agent’s behavior is predictable, its safety nets are tested, and the owner understands the downside. The transition from paper to live is a commitment, not a formality.

What are the limits of paper trading?

Paper trading is a powerful testing tool, but it cannot replicate every aspect of live markets. Be aware of the following constraints:

• ·Fill simulation. Paper orders often execute at the mark price or last traded price. Live markets involve spread, depth, and partial fills that simulation may not capture.
• ·No market impact. The agent’s simulated orders do not affect the order book or price. In live trading, larger orders may move the market, especially in low-liquidity options or prediction markets.
• ·Infrastructure differences. Paper endpoints may have different latency profiles or uptime characteristics than live execution paths during high load. An agent that depends on millisecond timing may behave differently.
• ·Custody flows. Because Felix is non-custodial by construction, the agent never controls withdrawals. Paper trading cannot test withdrawal flows because those are owner-approved and separate from execution logic.
• ·Behavioral drift. An agent that behaves correctly in paper may still behave differently in live if its prompt context changes or if it receives unexpected data. Paper testing is necessary but not sufficient for guaranteeing live stability.

Accept these limits and use paper for what it does well: validating engineering logic, safety wiring, and integration correctness. It is the first gate, not the final guarantee.