The platform
Four layers. One private machine.
Research, engineering, connectivity and operations: the stack a trading desk assembles from vendors and contractors, held in one workspace on your own hardware.
IV · Research
Research that survives its own scrutiny.
Most retail research fails quietly: a look-ahead bias nobody caught, thirty trades mistaken for evidence, a curve fitted to one regime. The research layer is built to argue with you. An idea is restated as rules precise enough for software, run in your own Python on your own machine, and reported with its assumptions beside its results.
Data in, aligned
Fetch one symbol or many and align them on a common index, cached on disk so an iteration loop is not also a download loop. The bundled source is Yahoo Finance history, and we say so plainly. Anything else, a vendor, an exchange or your own database, is connected through the connectivity layer.
Signals checked before they are trusted
The usual indicators, RSI, moving averages, ATR, MACD and Bollinger bands, with signal preparation that handles the shifting and alignment where look-ahead bias creeps in. Diagnostics run over your signals before the backtest does, so the obvious mistakes surface first.
Backtests, grids and honest verdicts
Run a single backtest or a parameter grid and watch results arrive as they complete. The research agent will not call a strategy tradeable on thin evidence: numbers that did not come from a real run are labelled illustrative, and fewer than about thirty trades proves nothing.
Results you can set side by side
Charts, trade tables, statistics and written reports render on the Canvas beside the conversation that produced them, and stay there to be compared with the next run: in sample against out, this parameter set against that one. Any of it prints to PDF.
III · Engineering
Instruction in plain language. Source in your repository.
You describe the strategy, the tool or the report you want. It is written into your project as code you can read, change, version and keep, in the same tree your editor and git history are looking at. The engineering a desk would staff, held in one workspace on your machine.
An AI engineer, on your choice of engine
One engine contract, several engines behind it, switched per conversation. Claude Code and OpenAI Codex are the engines we have driven end to end, and only engines we have verified are offered.
Output is files, not a transcript
Every change lands on disk in your repository, where it can be reviewed and reverted. Nothing you build depends on a hosted runtime you must stay subscribed to.
A real editor and real terminals
Python, TypeScript, Rust, C++ and the rest, with split panes and search across the tree. The terminals are your shell, your PATH and your installed runtimes; the app never intercepts a command.
Version control from the first line
Status, diffs, history, branches, commits, push and pull, in the place you write. Research you cannot reproduce is not research, so the work is versioned from the start.
II · Connectivity
No supported-broker list to be missing from.
Every platform in this category ships a list of supported venues, and yours is on it or you wait. QuantIDE ships the layer beneath that list. Adapters are written against your broker’s and your data vendor’s own APIs, as code in your project, with your keys on your disk.
The adapter is authored, not awaited
Describe the venue and an adapter is written against its API as a Model Context Protocol server in your project. You can read it, fix it, version it, and keep it if you ever leave.
Credentials stay local
Broker and data keys live on your machine and never travel when a workspace is shared. They are not held by us to make anything run.
Servers you already run
The client speaks standard MCP: connect an existing server, list its tools and call them. Anything that already exposes an MCP interface works without being rewritten.
Order routing, built deliberately
Nothing trades live out of the box. Routing orders is something you build here against your venue, with your credentials, and test before it touches capital.
I · Operations
The systems that run while you are away.
A strategy is the smallest part of a trading operation. Around it sit the jobs that fetch overnight, the monitors that watch positions and the alerts that wake you. Here they are written as code in your project and run under supervision on your own machine.
Processes that outlive the window
Long-running sessions are supervised, not tied to the interface. See what is running and on which ports, read back the logs, and stop anything that needs stopping. Close the app and it keeps going.
Monitors and schedules, as code
The jobs around your strategy, scheduled fetches, health checks and alerts, are written into your project like everything else: readable, versioned, and changed by instruction rather than by configuration screens.
Stacks that remember
A Stack packages a working setup, its tools, the instructions that tell the AI how to use them, and a starter project, so a way of working is installed in one action and returned to later instead of rebuilt from memory.
Shared privately, without your keys
Send a Stack to a partner or a colleague and the work travels while the credentials stay behind. Nothing is published anywhere by default.