Paper Trading Is Live in CuteMarkets

CuteMarkets paper trading is now live.

The first release adds a local paper trading simulator to the same platform that already serves stocks and options market data. You can create paper accounts, submit Alpaca-shaped orders, track positions and fills, inspect portfolio history, and keep the research-to-paper loop close to the API workflow.

This is a product launch, but it is also a direction statement. Paper trading should not be a detached demo account. For systematic traders and developers, it should be the controlled rehearsal layer between backtests and real execution.

What shipped

The new Paper Trading API supports paper accounts, market and limit orders, positions, fills, cancellations, resets, and portfolio history.

In the dashboard, the Paper Trading tab now gives you:

• multiple paper accounts for separate strategies or experiments
• an order ticket for stock and single-leg option orders
• account equity, cash, buying power, market value, P&L, drawdown, win rate, and open-order metrics
• equity, drawdown, and recent P&L charts
• positions, orders, rejected reasons, and fill history tables
• quick links to the Paper Trading API docs

The API uses Paper-scoped keys and /v1/paper/ endpoints. Orders are shaped to feel familiar to developers who have used broker APIs, but they stay inside CuteMarkets and do not route to a real brokerage account.

Why paper trading belongs next to market data

Paper trading becomes more useful when it can see the same data context that produced the strategy decision.

If a strategy opens a stock order, the account state matters. If a strategy opens an option order, the selected contract, bid/ask spread, quote freshness, DTE window, position intent, and rejection reason matter even more.

That is why the first integrated release focuses on the objects developers need to inspect:

• accounts
• orders
• positions
• fills
• portfolio history
• rejected order reasons
• quote-aware simulated fills

The goal is not to make simulated P&L look clean. The goal is to make each simulated decision easier to audit.

What the simulator does today

The v1 simulator supports stocks and single-leg option orders with conservative fill behavior.

Stock buys fill at the ask and sells fill at the bid. Option buys fill at the ask and sells fill at the bid, using the standard option multiplier. Limit orders only fill when marketable against the latest quote. Missing, stale, crossed, or invalid quotes prevent fills instead of silently inventing a friendly price.

For options, v1 supports buy_to_open and sell_to_close flows. It intentionally rejects unsupported cases such as naked option sells, multi-leg orders, fractional option quantities, stop orders, trailing stops, and extended-hours option routing.

That is a deliberate product boundary. The first version should be narrow enough to be inspectable and strict enough to expose bad execution assumptions.

How to use it

For the product overview, start with Paper Trading. It explains the dashboard, API, supported order behavior, and the next strategy-operations layer.

The fastest path is:

1. Create a Paper API key.
2. Open the dashboard Paper Trading tab.
3. Create a paper account for one strategy or experiment.
4. Submit a small stock or option order from the dashboard or API.
5. Review orders, positions, fills, rejected reasons, and the equity history after every decision.

For automated agents or scripts, use a stable client_order_id, poll orders and positions after each decision, and keep one paper account per strategy run. Reset accounts only when you intentionally start a new generation.

The product direction from here

Integrated paper trading is the base layer. The next product layer is strategy operations.

The features we want to add around paper trading are:

• daily review reports that explain trades, no-trades, rejects, risk checks, and open positions
• saved strategy profiles that attach a paper account to a strategy name, version, ticker universe, DTE window, sizing policy, and fill policy
• backtest-to-paper parity checks that compare the promoted research object with the live paper route
• alerts and webhooks for fills, rejects, drawdown thresholds, and strategy events
• bot runtime templates that help developers run a paper loop with durable logs
• community strategy pages where users can publish, discuss, and fork strategy profiles without exposing private keys or account details

The practical product question is now bigger than order entry. It is whether CuteMarkets can become the system of record for the full research lifecycle: data, backtest, paper run, review, and strategy sharing.

What to read next

Start with the Paper Trading API docs for endpoints and supported order behavior.

If you are building an automated loop, read How to Build a Paper Trading Bot and Paper Trading Bot Backtest Parity Runbook.

If you are deciding what to build after the launch, the answer is review discipline: make every trade, no-trade, reject, and risk-control decision explainable.

The launch note connects to Paper Trading Bot, Paper Trading API, Paper Trading Bot Data Stack, and Paper Trading Bot Backtest Parity Runbook.

How the terminology applies

For Paper Trading Is Live in CuteMarkets, the paper-trading workflow should treat Backtest parity, Paper-scoped API key, Launch contract, Fail-closed data gate, Order lifecycle, and Position state as operational state rather than glossary decoration. That framing keeps the handoff from research to paper execution concrete, with the same state gates visible before an order is simulated.

A developer implementing this Product Update idea should persist Data-feed parity, Paper fill evidence, Live drift, Options data API, OPRA-originating data, and OCC option symbol beside the result, instead of leaving those words in a term card. It also makes live drift easier to diagnose because paper behavior can be compared to the frozen backtest policy instead of a vague promise.

The review artifact for Paper Trading Is Live in CuteMarkets becomes more useful when Bid/ask spread, Midpoint, Quote/trade condition, Quote vs trade semantics, REST snapshot, and WebSocket stream appear in the same body of evidence as the selected rows. When the paper system refuses a route, these fields should show whether the refusal came from data, entitlement, order state, or risk policy.

In production notes for this paper-trading workflow, Entitlement gate, Quote freshness, Timestamp semantics, Pagination cursor, Response envelope, and Rate-limit budget define the checks that decide whether the workflow is reproducible. The result is a paper candidate that can be reviewed daily and shut down cleanly when parity breaks.

For Paper Trading Is Live in CuteMarkets, the practical acceptance test is simple: another developer should be able to read the body, identify the exact inputs, reproduce the request sequence, and explain the accepted and rejected rows without relying on the bottom terminology grid. If a phrase appears in the page vocabulary, it should correspond to a stored field, a validation check, a replay step, or an implementation decision in the paper-trading workflow.

This is also the reason the article should not measure success only by the final chart, table, or headline metric. The better standard is whether the data path, timing model, entitlement state, and evidence trail survive review. When those pieces are written directly into the body, the terminology becomes part of the workflow readers can implement.

Paper fills should keep market evidence

Every paper fill should preserve the market row that allowed it. For stock orders, that means latest quote or trade context, market session, source state, and timestamp. For option orders, it means selected OCC option symbol, bid, ask, bid size, ask size, quote condition, quote freshness, and the side-specific rule that chose ask, bid, midpoint, or reject.

The order lifecycle should also carry the API context: paper-scoped key, response envelope, request id, rate-limit budget, and entitlement state. When a paper order is rejected, the reject should say whether the cause was account state, unsupported order type, missing quote, stale NBBO, wide spread, no bid, or data-feed parity. That turns paper trading into a review system, not just a simulated balance.