Intelligent Trading Bot: Offline Training and Online Signaling in One Python Pipeline
Intelligent Trading Bot: Automatically generating signals and trading based on machine learning and feature engineering
At a glance
- What is it?
- The project splits machine learning model training from live prediction, using a shared feature definition to keep both paths consistent. It is a pipeline you assemble and run yourself, not a packaged trading app.
- Who is it for?
- Adopt this project if you already write Python features and want a batch-to-stream pipeline where the same derived features feed training and live prediction, and you accept running eight scripts by hand against a config file. Do not adopt it if you need a packaged bot with a UI, extendable data sources, or incremental feature computation on large histories.
- 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 16 days 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
The Split Between Offline Training and Online Signaling
The stated aim is an intelligent trading bot for automated trading, including cryptocurrencies, built around machine learning and feature engineering. The design decision that shapes everything else is an explicit separation between an offline batch mode for training models and an online stream mode for predicting from those trained models. The README names the hard part directly: guaranteeing that the same derived features are used in both modes. This is a real problem in trading pipelines. A feature computed one way during research and another way in production produces a model that looks fine on historic data and behaves differently live. The project's answer is to define features once, in configuration, and reuse those definitions in both paths. The audience is therefore not discretionary traders looking for a finished product. It is Python developers who want to author their own features and labels, train models on their own data, and then run a service that emits signals or executes transactions on a schedule.
How the Batch Pipeline Moves Data From Download to Signals
The offline path is a sequence of scripts in the scripts module, each loading input and writing output files. The README lists the order: download, merge, features, labels, train, predict, signals, output. Data first arrives from one or more sources listed under the data_sources section of the config, each entry carrying a column_prefix so that identically named columns from different sources stay distinguishable. Because the system works with a single data table, the merge script aligns records by timestamp so that one output row combines records sharing a timestamp, and it fills gaps to produce a continuous raster. The features script then appends derived columns according to the feature_sets section. Labels come next, then training, then prediction, and finally signal generation and output. The README notes that not every generated feature has to be used for training: some feed later features, and others exist only for feature selection, with a separate explicit feature list governing the train and predict phases. That is a sensible separation, and it means the config carries more than one notion of which columns matter.
Feature Generation Is the Design Center, and Its Main Cost
Derived features are defined as Python functions, which covers standard technical indicators and arbitrary custom features. The README states that feature generation currently runs in a non-incremental mode, computing features for all available input records rather than only the latest update, and that this can take hours for complex configurations. In online stream mode, the README says features can be computed more efficiently if the feature generator supports it. That conditional is the important part. The efficiency of live operation depends on how each generator is written, so a heavy custom feature that recomputes over the full history will be fine in batch and painful in a service that runs every minute. The project also supports different trade frequencies, described as time rasters such as 1 minute, 1 hour or 1 day, with freq set according to pandas conventions. Frequency choice interacts with the feature cost: the faster the raster, the less time each cycle has to spare.
Running It: Config Keys and the Eight Commands
The README gives the exact invocation pattern. Each script takes a configuration file via -c: python -m scripts.download -c config.json, then the same for merge, features, labels, train, predict, signals and output. Sample configuration files live in the config folder. Common keys named in the README are data_folder, which holds files needed only for batch offline mode; symbol, a trading pair such as BTCUSDT; description, free text explaining the config's purpose; and freq, the data frequency in pandas conventions. The data_sources section lists sources with column_prefix, and the feature_sets section lists feature generators with their parameters. The README states plainly that data sources are not extendable and that only Binance and Yahoo can currently be downloaded from. That is a hard boundary: if your data lives elsewhere, you are writing the download step yourself before the rest of the pipeline can run.
The Online Trading Service and What It Emits
The trading service handles online mode. According to the README, it uses a configuration file to regularly retrieve data updates, perform analysis, and send signals or execute trade transactions. Signal functions are customizable, and the README mentions sending to Telegram channels, an API endpoint, storing in a database, or executing real transactions. The live example is a Telegram channel where the service runs in the cloud, currently configured for Binance, BTCUSDT, at a 1 minute analysis frequency, producing an intelligent indicator between -1 and +1. The README shows two message forms: a score line such as a price followed by a negative score, and a threshold message reading as a buy signal with the indicator value and the 1min frequency. The threshold is described as specified in the model. Backtesting is listed as a project function but the README notes it is more difficult because it requires periodic retraining of the models used, which is an honest admission rather than a solved feature.
Where This Approach Fails, and What It Is Not
Three constraints stand out. First, the non-incremental batch feature computation means the offline path does not scale gracefully with history length; the README says hours for complex configurations, and that is before you retrain for backtesting. Second, data sources are fixed to Binance and Yahoo, so multi-venue or alternative data work starts outside the project. Third, the online path's efficiency is conditional on generator support, which the README does not enumerate per generator. There is also no packaged interface here: the workflow is a series of module invocations against a JSON config, and the repository retrieved no releases, so versioning is whatever you pin from the master branch. As an alternative, Freqtrade takes a different approach: it ships a strategy class with entry and exit callbacks plus a CLI for backtesting, dry runs and live trading, so the framework owns the execution loop and you fill in signals. This project inverts that. You own the scripts, the feature definitions and the schedule, and the project supplies the batch-to-stream structure and the feature consistency guarantee. Choose Freqtrade when you want an integrated runner; choose this when the feature engineering pipeline itself is the work.
Maintenance Burden and Licence Position
The maintenance cost is dominated by the feature definitions, because they are Python functions you write and must keep correct in both batch and stream paths. The configuration file is the contract between the two modes, so changes to feature_sets or the explicit train and predict feature list ripple into retraining and into whatever the online service loads. The README mentions periodic retraining as a backtesting requirement, which implies a recurring batch cycle rather than a one-time setup. The project is MIT licensed, which permits commercial use and modification subject to the licence terms; this is a description of the licence identifier, not legal advice, and you should read the licence text and your own obligations before shipping anything. The README does not describe a migration or upgrade path between versions, so pinning a commit is the practical way to keep a working pipeline reproducible.
Editorial conclusion
Adopt this project if you already write Python features and want a batch-to-stream pipeline where the same derived features feed training and live prediction, and you accept running eight scripts by hand against a config file. Do not adopt it if you need a packaged bot with a UI, extendable data sources, or incremental feature computation on large histories. Before committing, verify that the sample configs in the config folder match your symbol and frequency, and confirm which feature generators support efficient online computation, because the README states that non-incremental batch feature generation can take hours.
Community notes