How to avoid common mistakes when running a trading agent from an AI code editor

Running a trading agent from an AI code editor without giving up custody means the agent can place orders through a single API while your funds remain in a wallet you control. The editor helps write and debug the strategy, but the live trading key enforces hard limits, scoped permissions, and owner-approved withdrawal addresses that the agent cannot override. You do not need to deposit funds into a third party account, yet you must still configure safety controls because the agent can lose the entire budget you allocate to it. The model generates logic, but it does not enforce discipline. That responsibility stays with the owner.

What does running an agent from an AI code editor actually involve?

AI code editors such as Claude and Cursor connect to Felix through MCP tools or direct REST calls. The editor generates code that defines entry signals, position sizing, and order routing. You review the code, run it locally or on a server, and the agent begins sending requests to the API. One key and one API cover stocks, crypto, perps, options, and prediction markets. The funds never leave your wallet. The agent receives a scoped key that can spend within limits you set, but it cannot withdraw to an unapproved address or steal funds. This is non-custodial by construction.

A common mistake is to assume that because the AI wrote the code, the AI also enforces the safety rules. It does not. The model is a text generator. It does not know your wallet balance, and it cannot see whether its own logic contains a bug. The safety rules live in the Felix key configuration and the API layer, not in the prompt. Many of the errors we see are documented in common mistakes for Claude agents with self custody. You must review the generated code independently, test it in paper mode, and only then authorize a live key with a tight budget.

Another mistake is to treat the editor as a trading platform. It is not. The editor is a development environment. It does not show real time portfolio value, margin requirements, or open position PnL in a unified dashboard. You must build your own monitoring loop or check the Felix API for that data. If you assume the editor will warn you when the agent is overleveraged, you will be disappointed. The editor only knows the text it generates. Market reality lives outside of it.

Why is skipping paper trading the most expensive mistake?

An AI editor can produce a trading script in minutes. The syntax is clean, the variable names are descriptive, and the order sizing is expressed in plain US dollars. The API normalizes venue-specific contract math, so the code looks ready to run. Many traders authorize a live key at this point and skip paper trading entirely. This is the most expensive mistake.

Paper trading exists so you can observe how the agent behaves with real market data and latency without risking capital. The agent might misinterpret a timestamp, loop too aggressively, or send an order size that the API rejects. These flaws are cheap to fix in paper mode and costly in live mode. You should run the agent in paper trading long enough to see multiple signal cycles, not just a single successful trade. A five minute paper run is not validation. It is a glance.

Before moving to live capital, you should also evaluate backtest results carefully. How to evaluate backtest results before letting an AI agent trade real money covers the steps in detail. A backtest is hypothetical, but it reveals whether the strategy logic is coherent. Paper trading reveals whether the agent executes that logic correctly. Only after both steps should you authorize a live key, and even then you should start with a small spend cap. Trading can lose money, including the entire amount you allocate to the agent.

The pressure to go live quickly is understandable. You have a strategy, the code is ready, and the market is moving. Delaying feels like leaving money on the table. This feeling is dangerous. The market will still be there after you have tested. The capital you save by catching a bug in paper mode is worth far more than the hypothetical profit you might miss in the first hour. Patience is a safety control.

Some users also make the error of paper trading with a different key scope than they intend to use live. If the live key has tighter limits, the agent might behave differently when those limits are hit. Always mirror the live scope in paper mode so that the transition is exact. A scope mismatch between paper and live is a hidden source of failure.

Why do prompt instructions fail where scoped keys succeed?

Another common error is to write a prompt that says only trade one hundred dollars per day and assume the agent will obey. An LLM processes instructions probabilistically. It can misread a number, ignore context, or treat the budget as a rough guideline rather than a hard ceiling. A prompt is text. It is not a control system. The model has no memory of your previous session unless you feed it, and even then it might hallucinate a different limit.

The model might also reinterpret your instruction based on training data. If the training set contains examples where traders routinely exceed small budgets for larger opportunities, the model might treat your limit as flexible. It might even generate a comment in the code that says the limit is one hundred dollars while writing a function that calculates a percentage of an unspecified total. The prompt is not a contract. It is a suggestion to a statistical model.

Felix separates strategy logic from execution limits. You set spend caps, drawdown limits, and position limits at the key level. How to set spend caps and drawdown limits for trading agents explains the exact controls. If the agent sends an order that would exceed the cap, the API rejects it regardless of what the prompt said. The key scope is enforced by infrastructure, not by the model's willingness to comply. This distinction is critical. You should never rely on the honor system of a language model.

You should also limit the key to the smallest viable set of permissions. If the strategy only trades stocks and crypto, do not enable perps, options, or prediction markets on the same key. Surface area is risk. A scoped key should match the strategy exactly. If you later want to expand, you can issue a new key with broader scope. It is better to add permissions deliberately than to remove them in a panic.

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

{
  "key": "YOUR_KEY",
  "scope": {
    "markets": ["stocks", "crypto"],
    "max_position_usd": 1000,
    "max_daily_spend_usd": 500
  },
  "withdrawal_address": "OWNER_APPROVED_ADDRESS"
}

This is illustrative. The real fields and endpoints are documented at /docs. The point is that the limits are structural, not conversational.

What happens when agents trade without an exit plan?

AI editors are good at generating entry conditions. A user can ask for a strategy that buys when a moving average crosses upward, and the editor will produce a plausible loop. What users often forget to request is the exit logic. An agent without an exit plan will hold a position until the budget cap is exhausted or until the owner manually intervenes. This is not a strategy. It is a hope.

You need an automated exit plan that defines stop losses, take profit levels, and maximum time in market. How to build your first automated exit plan and take-profit strategy provides a practical checklist. These exits should be part of the strategy code, not an afterthought. A stop loss should trigger a market order or a flatten command, not just a console log message. The agent must act, not merely observe.

Suppose the agent opens a leveraged perp position. Without a stop, an adverse move can consume the entire daily spend cap in minutes. Trading can lose money, including everything you allocated. The exit plan is what keeps a bad entry from becoming a total loss. Define the exit before you define the entry. If you cannot state the maximum loss you are willing to take on a single position, you are not ready to trade live.

Some traders also forget to include time based exits. A position that sits open for days because the agent is waiting for a target that never comes ties up capital and exposes you to gap risk. An exit plan should include a time limit. If the trade has not worked within the expected window, the agent should close it and move on.

Exit plans are especially important in options and prediction markets, where time decay or resolution dates create natural deadlines. An agent that holds an option until expiry without a plan for early exit can lose the full premium. An agent that holds a prediction market position past a key event date might be locked into a resolution that it did not anticipate. The exit plan must account for the instrument's specific lifecycle, not just price levels.

Why should you test the panic switch before every session?

The panic switch, or kill switch, flattens all positions and revokes the key. Many traders configure it once and assume it will work when needed. This is a mistake. API tokens expire, network paths change, and webhook endpoints drift. A kill switch that worked last month might fail silently today. You cannot discover this during a crisis.

Test the panic switch in paper mode first. Verify that it cancels open orders, closes positions, and revokes the scoped key. Then test it in live mode with a position size so small that the round-trip cost is negligible. The confirmation is worth the fee. If the agent begins to act outside its scope, you must be able to stop it within seconds, not minutes. Your reaction time is not a reliable safety layer.

You should also set an automated drawdown limit that triggers the switch without manual intervention. Relying on your own reaction time during a fast market is unreliable. The switch is your final safety layer. Treat it like a smoke detector and test it regularly. The best time to discover a broken kill switch is during a calm market, not during a volatile one.

If the kill switch fails, you are left with an agent that is still trading while you scramble to find the revoke button or manually close positions. In a fast market, those seconds can cost a significant portion of your daily cap. The kill switch is not a luxury feature. It is the emergency brake. You would not drive a car if you knew the brake pads were worn. Do not trade live if you have not confirmed the kill switch works.

How does non-custodial access change what you monitor?

Non-custodial access means the agent cannot withdraw your wallet balance to itself. It does not mean the agent cannot lose the budget you gave it. A common mistake is to check the wallet, see the total balance unchanged, and assume the agent is safe. The agent trades within a scoped allocation. You must monitor the agent's positions, open orders, and daily spend relative to that allocation.

Felix normalizes orders in plain US dollars, so the logs are readable without venue-specific contract math. You should still read them. Automation does not remove oversight. If the agent starts trading a market you did not authorize, or if position sizes drift upward because of a loop bug, that is a signal to revoke the key immediately. The fact that your main wallet is untouched does not mean the agent is performing well.

The AI editor might have introduced an error that increases order size on each iteration. Only hard caps and active monitoring catch this. Review the agent's activity at least once per session when you are still building trust. Over time, you can lengthen the review interval, but never eliminate it. Trading can lose money, including the entire budget, even when the infrastructure is non-custodial. Self custody protects you from theft, not from bad trades.

Some owners set up a dashboard and then never look at it. The dashboard becomes a decorative element. Monitoring requires action. If you see an open position that is larger than expected, you must pause the agent and investigate. If you see orders going to a market that is not part of the strategy, you must revoke the key. Passive observation is not oversight. Oversight means you are ready to pull the plug the moment the data looks wrong.