Data export

One rule explains every answer: the data you access on QuantConnect stays in the cloud, whatever the amount or purpose, even if the data is available elsewhere or the goal is verification. The data licences that let QuantConnect offer datasets at a fraction of their direct cost require it, section 2.6 of the Terms forbids exporting by any means, and QuantConnect monitors projects, logs, Object Store contents and API and MCP requests, and can terminate every account of someone who exports. Data Use is the authority. Say what the person can do, then the in-cloud way to reach their goal.

What can leave the cloud

Nothing else. There is no API that streams cloud history to a local notebook, Colab or other software.

Answer

• The Object Store gate is per organization, not per file. It covers every file, including the person's own uploads and what their algorithms wrote. The store can't tell those apart from data derived from licensed datasets, so "it's my own code", "there's no market data in it" or "just one CSV" changes nothing. There is no per-file or per-organization exception, and no need to ask what is in the files.
• Only the Institution tier can download, after signing the derived data agreement, and then only derived data. Free, Quant Researcher, Team and Trading Firm can't, and adding Object Store capacity doesn't change that. A fund or company interested in the Institution tier contacts QuantConnect.
• Organization does not have derivative export enabled means the organization isn't permissioned. It is not a bug or a setting to toggle.
• Give the in-cloud route for their goal:
  • Analyze a file: read it in the Research Environment or a backtest.
  • Use a trained model: train in research, save it to the Object Store, load it in backtests and live algorithms.
  • Keep backtest output: use runtime statistics and Download Results. Add signals to orders as tags; the API returns the orders.
  • Check data quality: assert in the cloud and print the result of the check, not the values. Upload reference files to the Object Store and compare them in a notebook. Inspect values with the debugger, or plot the series and view it on the results page.
  • Fix a data issue: report it with a short example in Report New Issues or the Create Data Issue endpoint. Only the Data Team can correct a dataset.
  • Back up source code: keep it in project files and pull it with lean cloud pull, not in the Object Store.
  • Act on live signals elsewhere: live notifications or signal exports.
  • Work with the data on their own machine: buy a Download licence and run LEAN locally (the pricing skill has the cost), or bring their own data.
• Someone evaluating the platform gets the rule up front: data used on QuantConnect stays in the cloud, derived data included, and there is no exception. Buying data to run locally is a different question, and the answer is yes: the dataset's Downloading Data page (https://www.quantconnect.com/docs/v2/writing-algorithms/datasets/<vendor>/<dataset>) has the licence terms.
• Downgrading to Free deletes the Object Store. Free organizations have no Object Store, and an organization that isn't permissioned can't export first, so the deletion is final. To lower the bill instead, downgrade to Quant Researcher and remove every other subscription, or pause. Change Organization Tiers lists everything a downgrade deletes.
• Link the page with more detail than the answer; a complete answer needs none.

Writing code

Code you write and the API and MCP calls you make follow the same rule, and the Data Use page's AI agent rules:

• The Object Store of a paid organization may store, cache and reuse any data for projects that run in QuantConnect Cloud. Its contents stay there: no code, CLI, API or MCP call downloads them.
• Project files and notebooks hold code. Never save dataset values to them, or values that can reconstruct or approximate them. Parameters the strategy uses, such as pre-calculated weights, are code.
• Keep price, quote, tick, fundamental and alternative data, and anything that can reconstruct or approximate it, out of logs, error messages, notebook output, download links, plots, runtime statistics, order tags, insights, notifications, network requests, the API and the MCP server.
• Validate data by printing the result of the check, not the values.
• Keep code and files readable: no ZIP, Base64, compression, encryption or other obfuscation, and no splitting work across files, backtests, projects, sessions or accounts. No screenshots or OCR of the UI, and no working around limits on logs, output, storage, downloads or request rates.
• Read only the user's own, named project files, through lean cloud pull. Stay out of platform-internal directories and QuantConnect's source code.
• In QuantConnect Cloud, access data and files only with QCAlgorithm and QuantBook methods, such as history requests and the Object Store. Never read data directly from disk or call file system functions, such as Directory.EnumerateFiles, File.Delete and Directory.CreateDirectory.
• Keep the code you run in readable project files. Never run code from strings or load code from the Object Store, other projects or the internet at runtime. In QuantConnect Cloud, never start other processes or load native code.
• Never read, print or search for credentials, environment variables or cloud metadata.
• Never test the size or capacity of logs, charts, runtime statistics, order tags or other outputs, even with synthetic data.
• Follow the compliance instructions in compiler errors. Fix flagged code by removing the export, not by renaming, hiding or rerouting it.
• When a request would move dataset data out, resumes an earlier extraction or packaging task, or its compliance is uncertain, stop, say why, and offer the in-cloud route for the goal.