How to run a trading agent from an AI code editor: a practical checklist

Running a trading agent directly from an AI code editor means the model can read market data, write orders, and execute trades through a single API that normalizes stocks, crypto, perps, options, and prediction markets. You remain non-custodial because funds stay in a wallet you control, and the agent can only spend within limits you set. Before any live trade occurs, you need a practical checklist that covers environment setup, scoped keys, safety limits, paper testing, and explicit owner authorization. This guide walks through each step in order.

What do you need before you open your editor?

Start with a wallet you control. The Felix infrastructure is non-custodial by construction, which means your funds sit in an owner wallet and the agent can never withdraw to itself. You must decide exactly how much capital you are willing to lose, because trading can lose money, including everything. Write down a hard budget cap in US dollars and a per-position maximum before you write any code. You should also decide which market types the agent will access first. It is tempting to enable all five immediately, but a narrower scope reduces the surface area for mistakes. A beginner agent might start with one market type, such as perps or prediction markets, until the logic is stable. You should also document the strategy in plain language so the editor has a clear prompt to follow. Finally, verify that your editor supports MCP tools or that you are ready to use the REST API directly. Both paths work, but MCP lets the model discover trading tools natively without you writing custom wrappers.

• ·An owner-controlled wallet with the exact amount of capital you are willing to risk.
• ·A written budget cap and per-position maximum loss in plain US dollars.
• ·A decision on which market types to enable first, rather than all five at once.
• ·Familiarity with dollar-based order sizing so you can express trades in US dollars instead of contract units.
• ·A plan for whether to start in paper trading or move quickly to live key authorization.

You should also prepare a simple decision log. Write down why you chose a specific market type, what the target risk-reward looks like, and under what conditions you will shut the agent down. This document is not for the model. It is for you, so that you have a reference when emotions run high during live trading. Sticking to a prewritten plan is easier than making decisions in real time while the agent is placing orders.

How do you connect the editor to the trading API?

Felix exposes one API and one key for five market types. AI editors such as Claude and Cursor connect through MCP, which presents the agent with a set of discovered tools for balances, orders, and positions. You do not need to write separate wrappers for a stock broker, a crypto venue, a perps venue, an options venue, and a prediction market. The API normalizes venue-specific contract math, so you size orders in plain US dollars and the system handles the conversion. This normalization matters because a contract on a perps venue is not the same size as an options lot, yet the agent reasons in dollars. If you prefer, you can call the REST API directly from code the editor writes. Either way, the agent acts through the same scoped key, and the safety model stays identical. The connection step is usually the fastest part of the setup, but it is worth testing a single read-only call before you allow order creation.

The exact request schema is in the docs; the shape looks like this for a generic REST call.

curl -X POST https://api.felix.trade/... \
  -H "Authorization: Bearer YOUR_KEY" \
  -H "Content-Type: application/json" \
  -d '{"market_type": "perps", "dollar_size": 500, "side": "buy"}'

For MCP users, the configuration is usually a JSON block in your editor settings that points to the Felix MCP server. Once connected, the model sees tools such as get_balance, place_order, and list_positions. The agent then reasons in natural language, decides on a trade size in dollars, and invokes the tool. Because the API is unified, switching from perps to options later only requires changing a parameter, not rewriting the integration.

What if your editor does not support MCP?

You can still run the agent by writing REST calls directly in the editor. The AI assistant will generate HTTP request code, and you can review it before execution. This gives you more visibility into the raw JSON but requires you to handle the normalization logic yourself. The safety controls work the same way because they are bound to the key, not the transport method.

Which safety guardrails should you configure first?

Developers often assume that an LLM will naturally respect a budget, but an agent follows instructions and tool schemas, not intuition. You must enforce boundaries at the infrastructure level. Scoped API keys let you restrict the agent to specific market types and prevent any withdrawal or key management action. Budget caps and position limits are denominated in US dollars, so you think in the same currency you use for risk management. An exit plan can be attached to the key so the system closes positions automatically if a threshold is breached. You should also confirm that the panic switch is available outside the editor, because you may need to flatten and revoke access instantly if the model behaves unexpectedly. This is especially important when the agent is running autonomously while you are away from the keyboard. The guardrails evaluation guide provides a deeper framework for testing these settings before real capital is exposed.

• ·Scope the key to only the market types and actions the agent needs.
• ·Set a hard budget cap in US dollars that the API enforces independently of the model.
• ·Define a per-position maximum and a total exposure limit across all market types.
• ·Configure an automated exit plan with drawdown or time-based triggers.
• ·Place the kill switch outside the editor so you can revoke access even if the IDE is closed.

It is worth noting that these controls are not suggestions the model reads in a prompt. They are enforced by the API infrastructure, which means a misinterpreted instruction or a tool hallucination cannot bypass the budget cap. This separation between model reasoning and hard limits is what distinguishes an agentic setup from a simple script. You should still write clear prompts, but you should never rely on them for safety.

How do you test the agent without risking real money?

Paper trading exists for exactly this purpose. Before you authorize a live key, run the agent through a complete trading cycle in the paper environment. Force it to check a balance, size an order in dollars, submit the order, receive a simulated fill, monitor the open position, and close it. Repeat this across every market type you intend to trade, because the contract math for a perps venue differs from that of an options venue even though the API accepts the same dollar size. Paper testing also reveals whether the editor is calling MCP tools correctly or hallucinating parameters that would be rejected by the API. Developers frequently misunderstand how one API abstracts every market, so validating the behavior with fake money is not optional. You should also test the guardrails in paper mode. Trigger a budget cap and confirm the order is rejected. Simulate a drawdown and verify the exit plan closes the position. Treat paper trading as a rehearsal for live authorization, not as a guarantee of future profits.

What is the final step before authorizing live trades?

Live trading requires explicit owner authorization of a scoped key. Until you take this step, the key is blocked from real markets even if the agent tries to trade. Perform a final checklist review. Confirm the wallet holds only the capital you allocated. Verify that withdrawal addresses are owner-approved and that the agent cannot change them. Double-check the budget cap, position limits, and exit plan in the dashboard. Ensure your panic switch is reachable from your phone or another device. You should also schedule the first live session for a time when you can watch the agent continuously. Once you authorize, the agent can trade real money, and outcomes are real. Trading can lose money, including everything, so authorization should be a deliberate act, not an accident. The guide to running an agent safely covers what to watch during the first live hours and how to respond to unexpected behavior.

How do you handle errors and halts gracefully?

Agents will encounter errors. A venue may reject an order for insufficient margin, or the MCP tool may return a timeout. Your prompt should instruct the agent to pause and ask for clarification rather than retry aggressively. You should also set a maximum retry count in the editor or in your wrapper so that a loop cannot burn through the budget with repeated failed orders. When an error occurs, review the log to see if the model misunderstood the tool schema or if the market condition changed. Halts should be manual at first, and you can automate them only after you have observed the agent long enough to trust its error handling.

What should you monitor after the agent goes live?

The first live session is not the end of the checklist. Watch the order log in real time to confirm that sizes in dollars are translating to the expected venue contracts. Monitor the total exposure across market types to ensure the agent is not concentrating risk in a single instrument. Check that the automated exit plan triggers when you expect it to, and verify that the kill switch works by testing a revocation and reauthorization in a low-stakes moment. Keep a log of every unexpected behavior, because LLMs can drift in reasoning even when the tools stay the same. You may find that the model interprets a prompt differently after a context window shift. If the agent exceeds its scope or budget, revoke the key immediately, fix the prompt or the guardrails, and return to paper trading before reauthorizing. Long-term success depends on treating the setup as a controlled system with feedback loops, not as a one-time configuration.