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 the Paper Trading landing page. 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.