How I would build an AI paper-trading agent with Codex and Alpaca

The idea of connecting an AI agent to a trading account interests me. I want to understand how it could read market data, assess a decision, and return to its work several times a day, with a record I can inspect afterward.

Here is how I would approach a paper-trading experiment with Codex, a model such as GPT-6 Astra, and an Alpaca connection. I would start with a virtual USD 10,000 budget and seven trading days of testing. This is a proposed setup, not an account of trades I have made.

Before the first order, I would test a simple failure: the agent submits a buy request, then loses the connection before the response arrives. I want the next run to check whether the order was accepted before trying again.

I would start with a paper account

My starting point would be Paper Trading. Alpaca says a free paper-only account is available globally with an email address. Orders remain in a simulation, and paper and live accounts use separate credentials and API endpoints. Alpaca paper trading documentation.

First, I would ask the agent to retrieve data, explain a possible decision, and record it. Once that works, I would add paper-order handling.

A positive simulated result would not convince me that the system is ready for real money. Paper trading does not fully reflect market impact, latency-related slippage, or order queue position. Before any live use, I would also need to check the account's buying power and its trading, margin, and settlement restrictions.

I would put the rules in writing

I would not leave the assignment at "make money this week." I want to define the instruments, entry conditions, position limits, and stopping rules before scheduling the agent.

I would let it research a strategy, while keeping changes to the operating rules subject to my review. A proposed idea is not permission to put it into use.

This is the opening instruction I would give:

Prepare a paper-trading project. Do not submit orders yet. Describe the strategy assumptions, the data required, and the conditions for taking no action. Propose position and loss limits, a schedule, and a recovery procedure for interrupted requests. Keep credentials out of the conversation and logs, and wait for approval of the operating rules.

I would use the response to assess the assumptions and risks. A well-written prompt does not establish a profitable strategy.

How I would connect Alpaca

Alpaca's official MCP server exposes market data, account information, and trading operations to an AI client. I would check which tools are available at each stage, since the connection is not inherently read-only. Alpaca's MCP overview.

For the research stage, I would start with these settings:

ALPACA_PAPER_TRADE=true
ALPACA_TOOLSETS=assets,stock-data,news

This leaves out the trading toolset. I would supply ALPACA_API_KEY and ALPACA_SECRET_KEY through the client's supported secret or environment mechanism. The example is part of the configuration, not a complete installation command; I would follow the current server documentation for setup.

Before enabling paper-order tools, I would verify the account and environment the connection actually reaches. A "paper only" instruction cannot repair a live connection. Real credentials would stay out of chats, screenshots, and the repository.

I would give each run a specific job

For this experiment, I would use six checkpoints with a clear assignment for each. Here is an illustrative schedule in US Eastern time:

1. 08:45: read the news, inspect the account, and prepare a watchlist.
2. 10:30: check for a trade that meets the rules I approved.
3. 12:00: review positions and consider the day's last new entry.
4. 14:00: manage existing positions.
5. 15:15: close remaining positions according to the experiment's rules.
6. 15:45: verify that the account is flat and record the result. I am using these times to explain the workflow, not to recommend buying or selling at a particular hour.

The NYSE's core session runs from 09:30 to 16:00 Eastern time. I would add checks for holidays and shortened sessions, because a weekday timer does not know whether the exchange is open. NYSE trading hours.

I would schedule in America/New_York and display local times in Asia/Jerusalem. That lets the software calculate the difference for each date instead of assuming a fixed offset throughout the year. Monitoring information outside the session does not make every instrument and order type available around the clock.

I want each run to know what happened before it

I would keep the runs in one conversation for easy review and maintain separate records in the project. These are the four files I would suggest:

• strategy.md: the rules I approved and their version.
• account-state.json: the last account snapshot and its timestamp.
• journal.jsonl: a log of decisions, requests, and broker responses.
• handoff.md: unresolved issues and the next run's assignment. These filenames are my proposed way of organizing the project, not requirements imposed by Codex or Alpaca.

At the start of every run, I would require the agent to compare its records with the broker's positions and open orders. If the local file says there is no position but the broker shows one, I want that discrepancy resolved before another action.

I would record the request and its identifier before submission. If the response never arrives, the system needs to check the broker's order record before retrying. I would also prevent overlapping runs from acting independently on the same account. These controls belong in execution code or a separate control layer; a prompt alone cannot enforce them.

I would test what happens when the computer is off

For tasks that depend on a local project, OpenAI's documentation says to keep the computer on and the desktop app running. Cloud tasks use a different environment, so I would separately check access to files, connections, and model settings. OpenAI scheduled tasks documentation.

For routine monitoring, I would add a midday report and an after-close report, for example in ClickUp. I would want positions, open orders, the day's result, and failed actions in each report. A decision to make no trade should appear there too.

One test would deliberately cover a missed closing run. The next run needs to inspect the account and current market session without assuming the missed step happened.

Before paying for data, I would check the feed

Alpaca's Basic plan provides real-time stock data from IEX. Its documented Algo Trader Plus plan offers broader US exchange coverage and is listed at USD 99 per month. Alpaca market-data plans.

I would choose a subscription based on the experiment's data requirements. Before the agent uses a price, I want to know where it came from and when it was updated. Paying for more data does not guarantee a better strategy.

What I would check for use from Israel

For learning, I would start with paper trading under Alpaca's global paper-account documentation. Before applying for a live account, I would confirm eligibility and the required documents with the company.

Alpaca's current country-support page directs applicants to support and does not guarantee approval for every Israeli resident. Its international guidance describes identity checks, generally including a tax ID, photo identification, and address information. Country availability, international onboarding.

Israel appears among the deposit regions for Funding Wallets, but that page concerns Broker API infrastructure. I would not take it as proof that every funding route is available to a personal Trading API account. Alpaca also documents USD wire funding for international users. Before a transfer, I would check the approved account's instructions and the bank and currency-conversion costs. Funding Wallets, international funding.

I would also read the fee schedule behind "commission-free." Alpaca notes that regulatory fees and different partner arrangements may apply, alongside data and transfer costs. Alpaca fees.

What I would measure after the week

I would review returns alongside missed runs, rejected orders, stale data, and rule changes. For a performance comparison, I would use the same dates, include costs, and examine the largest decline during the experiment.

Seven trading days could help me find problems in the workflow. They would not establish that a strategy can hold up over time.

Before considering real money, I would want to see the system recover from missing data, an absent order response, and two runs starting together. I want to be able to open the journal and understand why each decision was made.

I am describing an approach to learning and automation design, not offering personalized investment advice or recommending that anyone hand real money to an AI agent. Product details and official sources were checked on September 9, 2026.