QuantDinger Deep Dive: A Self-Hosted AI Trading OS Covering Research to Live Trading

Forum topic · 二一 · 2026-08-23

Summary

QuantDinger, developed by Open Byte Inc., is an open-source, self-hosted AI trading operating system that unifies the full pipeline from AI research and strategy coding through backtesting, paper/live deployment, and monitoring inside a Docker stack the operator fully controls. The backend (Apache 2.0) runs Python 3.12 with PostgreSQL 18, Redis 8, and Celery, while the Vue-based frontend and mobile apps use source-available licenses. It connects to major crypto exchanges (Binance, OKX, Bitget, Bybit, Gate, HTX), stocks via IBKR and Alpaca, and forex, with data via ccxt, yfinance, akshare, and ta-lib. Version 5 splits long-lived trading loops into six dedicated processes, introduces a Strategy API V2 with static manifest verification to prevent backtest/live drift, and enforces layered risk controls. A dedicated Agent Gateway with MCP server locks AI agents behind four gates before live trading. Key caveats: crypto funding fees are not modeled in backtests, the backtest engine is still maturing, and deployment is heavyweight. Best suited for Python-capable independent traders and small teams who want to keep API keys in-house; less suitable for GUI-only chart watchers or HFT use cases.

QuantDinger, developed by Open Byte Inc. (the name nods to Schrödinger — an untriggered strategy is like a cat in a box), is an open-source self-hosted AI Trading OS. Its stated goal: fold the entire chain of "AI research → strategy code → backtest → paper/live deployment → monitoring" into a Docker stack you fully own. Target users are independent traders, Python-literate strategy authors, and small teams who want a GUI and AI assistance without handing strategies or API credentials to any black-box signal service. At the time of writing, the mainline repo OpenByteInc/QuantDinger is at v5.0.17 (Aug 17, 2026) with ~490 commits, 10k+ stars, and ~2.1k forks. Note: the website's "official channel" lists github.com/brokermr810/QuantDinger, which mismatches the mainline repo — worth noting during due diligence (likely a personal fork promoted to an org repo without aligned messaging).

Key points

Stack: Python 3.12 / PostgreSQL 18 / Redis 8 / Docker Compose. Backend is Apache 2.0; frontend (QuantDinger-Vue) and mobile (QuantDinger-Mobile) are source-available licenses without trademark rights. Flask + Gunicorn for HTTP, Celery for retryable tasks, KLineCharts/ECharts in the frontend, Capacitor for mobile.
Markets: crypto (Binance, OKX, Bitget, Bybit, Gate, HTX), stocks (IBKR, Alpaca), forex. Data via ccxt, yfinance, akshare, ta-lib, exchange-calendars, finnhub. AI layer routes through litellm to OpenRouter / OpenAI-compatible / Google / DeepSeek / Grok / MiniMax.

v5 architecture: long-lived work split out of the API

v5's most valuable change is redrawing runtime boundaries into six processes:

migration — runs DB schema then exits
backend — HTTP, auth, validation, persistent commands
trading-worker — strategy runtime, pending orders, broker sessions, reconciliation
scheduler-worker — portfolio, deployment, billing, signal scheduling
celery-worker / celery-beat — finite-retry AI/backtest/report tasks and periodic dispatch

Cache Redis and task Redis are separated with different eviction policies. The production overlay enforces non-root, read-only rootfs, dropped capabilities, and resource limits. The architecture docs honestly list "high-risk legacy files" (trading_executor.py, backtest.py, ai_chat.py, pending_order_worker.py) as refactoring targets — a credible sign of production-grade intent.

Strategy API V2

Strategies use three callbacks: initialize (declarative universe, subscriptions, warmup, leverage — no market access, no orders), handle_data (fires per completed bar), and on_rebalance (periodic portfolio rebalancing). A compile-time manifest extracts universe, subscriptions, frequencies, factors, warmup, and leverage via static analysis; POST /api/strategies/verify returns valid:true plus the manifest, ensuring backtest and live run against identical settings.

Timeframes: 1m/3m/5m/15m/30m/1h/4h/1d/1w (max 8, no monthly). Multi-timeframe is opt-in; only bars whose close is not later than the driving bar's close are visible — a deliberate anti-lookahead rule.
Risk controls are real, running code (strategy_live_guard.py, backtest_limits.py): per-order stop-loss/take-profit/trailing-stop/time-limit; direction modes (spot forced long_only); account-level order rejection by notional, margin, leverage; strict mode pauses same-side entries when manual positions exist.

Backtest vs live: known gaps

Both share the same Order API with point-in-time completed bars; orders fill at next bar open. Important caveats:

Crypto funding fees are not_modeled in backtests — swap strategies will overstate returns unless you adjust manually.
Backtest fills gap-threshold stops at bar open and intrabar triggers at trigger price, with a fixed conservative order: stop-loss → trailing → time-limit → take-profit.
New deployments default to stopped and must be explicitly started.

Agent Gateway and MCP

Distinctive vs older frameworks like Freqtrade: a dedicated agent endpoint /api/agent/v1 plus a separate MCP server (quantdinger-mcp) lets clients like Cursor, Claude Code, or Codex call approved tools without touching broker credentials. State-changing tools require idempotency_key; live trading needs four gates: scoped token + paper_only=false + server-side AGENT_LIVE_TRADING_ENABLED=true + operator limits/whitelists. Emergency stop cancels agent live orders, clears paper orders, and revokes all tenant T-tokens.

Security

Broker credentials and MFA keys are encrypted at rest with CREDENTIAL_ENCRYPTION_KEY; agent tokens are hashed, scoped, and audited; strategy ownership uses lease/heartbeat/fencing tokens to kill orphan processes. Containers run non-root without capabilities; ports bind loopback by default. A check_production_config.py script enforces pre-launch secret configuration. SECURITY.md credits a disclosed JWT bypass (Aug 17) — a past vulnerability, transparently handled.

Comparison and verdict

Compared with peers, QuantDinger occupies the execution/monitoring layer: daily_stock_analysis (~59k stars) is a lightweight daily-analysis push tool; TradingAgents (~94k) is a multi-agent research framework with non-deterministic outputs; Kronos (~34k) is a K-line foundation model with demo-grade fine-tuning; Freqtrade suits CLI-only crypto automation; nautilus_trader suits event-driven/HFT. QuantDinger's edge is engineering completeness of the execution loop; its costs are heavy deployment and an immature backtest engine.

Who it fits: Python-capable traders/teams wanting a self-hosted research-to-live pipeline and refusing to give third parties API keys. Who it doesn't: chart-only viewers (TradingView), simple crypto automation (Freqtrade), HFT (nautilus_trader).

Bottom line: treat it as an execution foundation for research-to-live-trading, not a money-printing black box. Run your target strategy types in paper mode locally before deploying to a server; verify the repo is OpenByteInc/QuantDinger.