Level-2 and Level-3 replay models queue position
A historical price touching your limit order does not mean you would have traded. HftBacktest reconstructs Level-2 market-by-price or Level-3 market-by-order books, then accounts for feed latency, order latency, and your place in the queue. That is the useful distinction. A market-making idea can look profitable when every touched quote gets filled, yet fail once older orders in front of it consume the available volume.
The framework lets you replace its latency and queue assumptions with your own models. It can replay one or several assets and exchanges, and strategy time can advance at a chosen interval or with incoming events. Python strategies run in Numba JIT functions, while Rust carries the core work. The commit we tested contained about 34,925 source lines across 230 files, so this is a substantial simulator rather than a notebook helper.
Full order-book and trade ticks are the entry price
HftBacktest expects order-book and trade ticks, not a folder of minute candles. You need exchange timestamps, local timestamps where available, tick and lot sizes, and assumptions for the delay between decision and exchange receipt. The documentation links data-preparation guidance and sample Binance Futures data. It cannot tell you whether your own feed preserved every event needed to reconstruct the book.
That requirement changes the setup calculation. Installing 456 packages took only 10 seconds in our sandbox, but sourcing, cleaning, and validating a market feed can take far longer than installing the code. A replay is only as credible as its event ordering and latency inputs. The README makes the right argument here: compare a historical replay with an actual live period before trusting later optimization work.
What happened when we ran it
Our run installed commit 5f3ec40 in 10 seconds, then completed the build in 272 seconds. The fresh container had 3 CPUs, 12 GB of RAM, no secrets, and no elevated privileges. The checkout occupied 72.2 MB before installation. These numbers describe repository setup only. We did not measure trading speed, simulated order throughput, strategy returns, or agreement with a live account.
The test command ran for 248 seconds and exited with code 101. Rust compiled enough of the workspace to emit several warnings, then stopped on hftbacktest/examples/logging_order_latency.rs. That example calls LiveBot::builder(), and the compiler reported that no such associated function or constant exists for LiveBot<CH, MD>. The log does not establish whether the example, API, or selected feature set is wrong, so we will not assign a cause.
A successful 272-second build followed by this failure is still useful evidence. The basic build path works at the measured commit, while the broader test command does not complete cleanly in the supplied Rust image. The repository has 3 CI workflow files, but no Dockerfile and no tests directory. Teams should pin the compiler and features, run the examples they depend on, and add strategy-level regression fixtures before trusting an upgrade.
Issue 316 makes partial-fill regression cases necessary
Open issue 316 describes partial fills that update an order object without reaching the reported position, balance, or fee totals under a partial-fill exchange and probability queue model. The report includes a reproduction and distinguishes the PyPI 2.3.0 behavior from master and py-v2.4.4. We did not reproduce that issue in our sandbox, but its subject cuts directly across the reason to choose this package: realistic fills.
Two September 2026 reports are similarly concrete. Issue 333 says the ROIVector best bid and ask quantity properties return prices, and it gives alternate accessors as a workaround. Issue 334 says repeated file-based create_last_snapshot calls retain the loaded data because the backtest is not closed. Each report has a paired pull request in the open queue, but open code is not the same as a released fix. Pinning and regression tests are the safe response.
Python research is supported, while live trading is Rust-only
The documented Python path requires Python 3.11 or newer and uses Numba for the algorithm loop. Rust users can work directly with the engine, and the repository badge names Rust 1.90. Reusing algorithm logic in a live bot is currently limited to Rust, with Binance Futures and Bybit named in the README. That boundary matters if your research team writes Python but production execution belongs to another service.
For pure research, the tutorial catalog is unusually relevant: latency impact, queue-based market making, Level-3 replay, multiple markets, depth fusion, and pricing models all get dedicated examples. Still, tutorials do not validate your exchange adapter or fee assumptions. With 12 GB available, our sandbox reached a compiler error before the test command finished. A real evaluation should add a small known event sequence whose expected fills and final position can be checked by hand.
Current pull requests outpace the default branch
GitHub reported 4,849 stars and 22 open issues and pull requests on October 5, 2026. The open list contained 7 issues and 15 pull requests. Several September and October submissions address the same quantity, snapshot, and fill-accounting reports discussed above. Contribution is current even though the repository API dates the last default-branch push to December 23, 2025.
The latest release, rust-v0.9.4 and py-v2.4.4, was published December 10, 2025. That combination suggests an active contribution queue with changes waiting outside a year-old default-branch snapshot, not a dead project. HftBacktest remains worth a trial when queue position and latency decide whether the research means anything. Our failed test command and the open accounting reports make independent fill checks part of adoption, not cleanup for later.