Model or dataset
shy3130/tick-stock-panel avatar
shy3130/tick-stock-panel

TSP: A Self-Hosted A-Share Quant Workbench That Routes Data by Capability

TSP自托管、零运维的 A 股「选股 + 监控 + 回测」量化工作台 | LLM能力驱使策略定制+个股分析+复盘 | 自由接入第三方数据源与个性化扩展数据 | 个人开源 ,非第三方官方项目

4,717 stars1,158 forksPythonMIT

At a glance

What is it?
TSP (tick-stock-panel) is a self-hosted, Docker-deployed workbench for A-share screening, monitoring, and backtesting. It routes data requests to pluggable sources by capability and leans on LLMs for strategy generation and review, but it is not a trading terminal and explicitly refuses to be one.
Who is it for?
Adopt TSP if you are a developer or quant hobbyist who wants a self-hosted, Docker-based A-share workbench with pluggable data sources, Polars-accelerated screening, and LLM-assisted research, and you accept that it is not a polished commercial tool. Do not adopt it if you expect a zero-configuration trading terminal, need official data support, or require a stable API for production trading.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 1 day ago.
What is it written in?
Mainly Python, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

What TSP Actually Solves

TSP targets a specific pain: running a quant workflow for A-shares without depending on a single data vendor. The README describes a self-hosted, zero-ops workbench that combines stock selection, monitoring, and backtesting. The intended user is not a casual retail investor. The project banner warns '小白请绕路' (beginners, detour), and the author states clearly that it does not aim to compete with Tonghuashun or Tongdaxin, and does not include AI stock recommendations or limit-up prediction. So the audience is someone who can read code, run Docker, and tolerate rough edges. The value proposition is that you own the entire pipeline: data ingestion, feature enrichment, strategy execution, and backtesting all run on your machine. That is different from a SaaS screener because you control the data sources and can extend them, which matters for A-share data that is often fragmented across providers.

Capability Routing: The Core Mechanism

The central architectural idea in TSP is capability routing. Instead of assuming one data source provides everything, the system maintains multiple datasets: daily K-line, ex-rights, real-time, minute, order book, and financials. Each dataset is routed independently to a source that can supply it. The README calls this a 'capability routing matrix' and shows it in the settings page with capability detection and tier badges. You can combine sources arbitrarily. For example, you might get daily K-lines from one plugin and financial statements from another. This is a response to a real problem in A-share data: no single free source offers complete, reliable data for all fields. The routing is not just a facade. The docs include a dedicated file, custom-data-source.md, which explains how to add a new source. The design also supports extending data fields into first-class pages, so a custom field can appear alongside built-in data in analysis views. That level of flexibility is rare in open-source quant tools, but it comes with complexity: you must understand each source's strengths and configure routing accordingly.

Polars and the Screening Pipeline

Screening in TSP is built on Polars, a DataFrame library that is faster than pandas for many operations. The README claims 'millisecond-level' scanning of the entire A-share market using 25 built-in strategies plus minute-level strategies and custom signals. The screening engine also supports AI-generated strategies, though the details of how AI generates them are not in the README. The indicator pipeline enriches raw data into a Parquet file with 68 columns of indicators and signals, including MA, EMA, MACD, RSI, KDJ, Bollinger Bands, and volume ratio. The enriched Parquet is written once and reused, which avoids recomputing indicators on every scan. That is a sensible design for repeated screening and backtesting. The use of Parquet as a columnar storage format aligns with Polars' strengths. However, the README does not specify how often the enrichment runs or whether it is incremental. For a self-hosted tool, you would need to schedule the pipeline yourself, likely as a post-market job. The claim of millisecond scanning is plausible only if the enriched data is already in memory or on fast storage, and if the strategy logic is vectorized. The README gives no benchmark numbers, so treat that as a design goal rather than a measured result.

Backtesting with A-Share Constraints

The backtesting module is more than a simple price simulator. It includes four research views: factor backtesting, strategy backtesting, minute-level strategy backtesting, and validation. The strategy backtest respects T+1 settlement, which is a legal constraint in A-shares where shares bought on a day cannot be sold until the next trading day. It also models transaction fees and slippage, and supports stop-loss. The minute-level backtest replays signals day by day and enters at the minute close, which is realistic for intraday strategies. The factor backtest computes IC/IR, layered returns, and long-short portfolios, and it filters factors through a catalog of 62+ factors to remove ineffective ones. One notable feature is factor attribution for scoring strategies: it compares factor values on winning versus losing entry days. The validation view offers parameter sensitivity and rolling out-of-sample tests. Backtest results can be exported to CSV, saved as candidates, and reloaded for re-testing. This closed loop is practical for iterative research. The README mentions SSE streaming for progress during backtests, which is a nice touch for a web UI. But the backtest engine is not described in terms of its event loop or data structures, so you cannot judge its performance or correctness from this material alone.

Factor Platform and Mining: Guardrails on Automation

TSP includes a factor platform with a domain-specific language (DSL) that lets you define factors using 25 operators selected through an editor. The editor supports point-and-click construction, trial calculation, and versioning. Factors can be tested with IC, layered returns, and Newey-West adjustment. The platform links factors to strategies in both directions: you can generate a ranking strategy from a factor library, and strategy triggers can reference factor conditions. The mining module goes further: it searches for multi-factor rank combinations using nested out-of-sample evaluation. During mining, it re-estimates factor direction on a training interval, removes correlated factors, and searches for rank combinations. The key guardrail is that mining results go into a candidate library and are published only after explicit confirmation. The README states that candidates are 'never automatically promoted'. That is a deliberate design choice to prevent overfitting from silently entering live use. This is a mature approach compared to tools that auto-tune without supervision. However, mining is computationally expensive by nature, and the README does not give any runtime estimates or hardware recommendations. You would need to test on your own machine to see if it is practical.

Monitoring and Alerts: Real-Time but with Limits

The monitoring center covers four rule types: strategy signals, individual stock signals, price rules, and abnormal moves. Rules can be scoped to watchlist groups and combined with AND/OR logic. Alerts appear as popups, voice announcements that read the stock name and signal, and push notifications to Feishu (Lark). The abnormal moves module organizes alerts by trading session: auction, intraday, and offset. Auction anomalies pull from Tonghuashun's pre-market wind vane and include a comparison of actual returns on the day and the next day, plus a risk flag for chasing limit-ups. Intraday anomalies aggregate limit-up, limit-down, new highs, new lows, and volume spikes without requiring new data collection. Offset anomalies follow exchange deviation rules: main board 3-day ±20%, ChiNext and STAR ±30%, Beijing Stock Exchange ±40%, plus 10-day and 30-day thresholds. The monitoring system persists trigger records. This is useful for traders who want to react to events during the session. The limitation is that real-time data quality depends entirely on the data source plugins. If your source for real-time quotes is delayed or unreliable, the monitoring will be too. The README does not specify minimum latency or data refresh intervals, so you must verify with your chosen data source.

LLM Integration: Assistance, Not Autopilot

TSP integrates LLMs in several places: AI-generated strategies, a four-dimensional stock analysis (technical, fundamental, financial, and news), financial statement interpretation, and post-market review generation. The review module injects data from the dragon-tiger list and the pre-market wind vane into the prompt, then produces a Markdown report that can be scheduled, pushed to Feishu, or downloaded. The stock analysis is marked as Beta, which is an honest signal that it is not fully mature. The README does not specify which LLM providers are supported or how the AI interface is configured, only that the settings page has an AI interface section. This is a gap. You cannot know whether it works with OpenAI-compatible APIs, local models, or specific Chinese providers. The project's stance is that LLMs assist research, not that they predict stocks. The banner explicitly says the project does not include AI stock recommendations or limit-up prediction. That boundary is important because it sets expectations: the LLM features are for summarization and hypothesis generation, not for trading signals. Still, the quality of AI output will depend on the prompts and the underlying model, and the README gives no examples of output quality.

Deployment, Configuration, and Data Sources

Deployment is Docker-based. The README shows a Docker badge and a Dockerfile, and a CI workflow builds the image. There is no docker-compose example in the README, but the Dockerfile implies a containerized setup. Configuration is done through a settings page, which includes data source and capability detection, AI interface settings, real-time monitoring, extension pages, and menu and system settings. The data source plugins mentioned are TickFlow, fuyao, and stock-sdk, plus YAML-defined custom sources. The README says the project is 'zero-ops', but that is misleading: you still need to run the data pipeline, schedule post-market jobs, and manage storage. The term likely means that once deployed, the system handles the routine data sync and enrichment automatically. But the README does not describe the scheduler or how to configure cron jobs. For a self-hosted tool, you must be comfortable with Python, Docker, and debugging data issues. The license is MIT, which is permissive, but the README states 'for learning and research only, commercial use strictly prohibited'. That is a contradiction: MIT allows commercial use, but the author forbids it. You must respect the author's stated restriction even if the license text permits more. This is a legal gray area that you should consider before using it in any commercial context.

Maintenance and Upgrade Cost

The repository has no recent releases listed, and the last push is dated September 2026, which suggests active development. The README is detailed and organized with links to docs for custom data sources, strategies, features, factor platform, mining, and market phase. That documentation is a positive sign for maintainability. However, the project is a personal open-source effort, not affiliated with any official vendor. That means the maintainer's time is limited, and breaking changes could arrive without notice. The use of Python, Polars, FastAPI, React, and DuckDB in the topics indicates a modern stack, but also a complex one. Upgrading TSP likely means pulling a new Docker image and re-running the data pipeline. The enriched Parquet files may need to be rebuilt if the schema changes. The factor DSL and strategy definitions are stored in some form, but the README does not specify how migrations handle them. Before adopting, you should check the docs for migration notes or a changelog. The absence of a releases section means you cannot rely on semantic versioning. You are essentially tracking the main branch. That is acceptable for a research tool, but not for a system you depend on for live trading decisions.

Editorial conclusion

Adopt TSP if you are a developer or quant hobbyist who wants a self-hosted, Docker-based A-share workbench with pluggable data sources, Polars-accelerated screening, and LLM-assisted research, and you accept that it is not a polished commercial tool. Do not adopt it if you expect a zero-configuration trading terminal, need official data support, or require a stable API for production trading. Before adopting, verify the data source plugins you intend to use (TickFlow, fuyao, stock-sdk) actually cover your needed datasets, confirm your LLM API endpoint works with the configuration, and review the docs for custom data sources and strategy definitions, because the README warns that this is for learning and research, not for commercial use.

Official sources

  1. Issues
  2. License: MIT
  3. README
  4. shy3130/tick-stock-panel on GitHub
Community notes

Community notes