QuantConnect LEAN

Platform

Trading engine and managed cloud platform

License

Apache-2.0 for LEAN. QuantConnect Cloud and data licenses are separate

Pricing

Free open-source engine with separate cloud compute and data plans

Live trading

Paper and live execution through supported brokerages

Best for

Testing and trading across many markets, either locally or through QuantConnect's managed platform

QuantConnect combines the open-source LEAN engine with a paid cloud platform. LEAN is an event-driven engine for backtesting across many markets, and it can connect the same algorithm to paper or live brokerage accounts. The cloud platform handles much of the data and hosting work. You still need to check the historical data, fill models, costs, and live behavior.

The engine and the cloud product are different. LEAN's source code is available under Apache-2.0 and can run on your own computers. QuantConnect Cloud adds hosted notebooks, datasets, cloud computers, collaboration, and live nodes under separate paid terms.

What can LEAN model?

LEAN is an event-driven C# engine with Python and C# strategy APIs. A QCAlgorithm receives time-ordered data slices, scheduled events, corporate actions, and order events. The engine supplies modular data feeds, transaction handling, portfolio accounting, brokerage models, and statistics. Python is a strategy interface over the C# runtime, not a standalone Python backtester.

The current asset-class documentation covers US and India equities, equity and index options, indexes, futures, futures options, forex, CFDs, crypto, and crypto futures. That list describes engine coverage. Historical depth, resolution, live data, and tradability still depend on the selected dataset, market, and brokerage.

How do you write a small Python algorithm?

The example makes its execution assumptions visible. It selects the Interactive Brokers margin brokerage model for fees, supported orders, and buying power, then overrides that model's default zero-slippage behavior with a volume-share slippage model. It submits one ten-share SPY market order only after a daily bar arrives and logs the fill event.

from AlgorithmImports import *


class RealityModelExample(QCAlgorithm):
    def initialize(self) -> None:
        self.set_start_date(2024, 1, 2)
        self.set_end_date(2024, 1, 10)
        self.set_cash(100_000)
        self.set_brokerage_model(
            BrokerageName.INTERACTIVE_BROKERS_BROKERAGE,
            AccountType.MARGIN,
        )

        security = self.add_equity(
            "SPY",
            Resolution.DAILY,
            data_normalization_mode=DataNormalizationMode.RAW,
        )
        security.set_slippage_model(
            VolumeShareSlippageModel(volume_limit=0.025, price_impact=0.10)
        )
        self.symbol = security.symbol
        self.order_sent = False

    def on_data(self, slice: Slice) -> None:
        bar = slice.bars.get(self.symbol)
        if bar is None or self.order_sent:
            return

        self.market_order(self.symbol, 10, tag="single API-check order")
        self.order_sent = True

    def on_order_event(self, order_event: OrderEvent) -> None:
        if order_event.status == OrderStatus.FILLED:
            self.log(
                f"{order_event.symbol}: {order_event.fill_quantity} "
                f"shares at {order_event.fill_price}"
            )

Put the code in a Python project's main.py and run lean backtest "Reality Model Example", or run it in QuantConnect Cloud. The exact market-data snapshot affects the reported price. This example was checked against the current Python API and compiled for Python syntax, but it was not executed here because the environment had neither the LEAN CLI nor a LEAN Docker image and the required SPY data. It is an API and reality-modeling example, not evidence that buying SPY has an edge.

The explicit raw-price setting avoids silently relying on LEAN's default adjusted US-equity series. Raw data requires correct handling of splits and dividends. The equity data-normalization guide explains the adjusted, split-adjusted, total-return, raw, and scaled-raw choices.

Which execution assumptions require review?

LEAN calls fees, fills, slippage, buying power, settlement, and related components "reality models." A brokerage model sets compatible defaults for a target broker, but defaults remain simulations.

• The default brokerage model uses NullSlippageModel, and the Interactive Brokers brokerage model also defaults to zero slippage. Set and calibrate another model when zero is not defensible.
• Built-in fill models assume complete fills. Partial fills require a custom model.
• LEAN's reconciliation guide states that market impact is not modeled by default. Large orders can therefore receive optimistic simulated prices unless you add an impact-aware model.
• A bar exposes only aggregate prices and volume. It does not reconstruct the intrabar path or queue position. Scheduled intraday orders against coarse data can also fill from stale prices.
• Short-borrow cost is not simulated by default. Borrow availability, margin interest, funding, and other carrying costs need separate review when the strategy depends on them.

Use the same brokerage model, account type, data normalization, market hours, resolutions, and custom models that you intend to test. Record these settings with the result. A high-fidelity engine cannot infer missing depth, undisclosed borrow constraints, or the market's response to your order.

What changes between a backtest and live trading?

LEAN lets the same algorithm class run in backtest and live modes, but identical code does not imply identical behavior. The official live reconciliation guide documents differences in data timing, slice construction, custom-data timestamps, corporate actions, fill timing, brokerage rules, and scheduled events. It also notes that live orders travel to a brokerage while simulated orders use the backtest's available price and models.

Live algorithms must recover state, reconcile existing holdings and open orders, and tolerate restarts and provider outages. QuantConnect's live-trading key concepts explicitly state that live strategy state is not managed automatically. Rebuild indicators from history or warm-up data and persist the state that cannot be reconstructed safely.

Broker support varies by asset class, order type, account, country, and data feed. Check the current brokerage matrix and the selected adapter's documentation before designing around a connection.

What does local use actually require?

The LEAN CLI local backtest runs the engine in a Docker container and stores results in the project directory. QuantConnect currently requires membership in a paid organization tier to use the CLI. Building LEAN directly from its Apache-licensed source is a separate path, with more configuration work.

Either local route needs historical data. QuantConnect's local data guide requires a local data directory, and Dataset Market files have their own licenses. Some data is free, while other data has cloud or download fees and redistribution limits. You can also integrate compatible external data, but then schema conversion, corporate actions, symbol mapping, quality control, and point-in-time correctness become your responsibility.

QuantConnect Cloud pricing is organized around tiers, seats, compute nodes, live nodes, add-ons, and datasets. These inputs change, so inspect the current pricing and resource configuration rather than budgeting from an old fixed-price summary.

When is QuantConnect LEAN the wrong fit?

LEAN is a substantial system. A smaller bar-based library is easier when the job is one local dataset and a simple strategy. An array-oriented engine can also be more convenient for broad signal or parameter screening before event-level simulation matters.

Running LEAN locally is not a shortcut if the goal is to avoid maintaining data imports, containers, brokerage adapters, and live processes. QuantConnect Cloud handles much of that work but adds plan, compute, data-license, and platform dependencies. Choose based on which setup and maintenance work you are willing to handle, not on the assumption that an event-driven backtest will automatically match live execution.