BoxMOT: pluggable multi-object tracking for AABB and OBB detections

What BoxMOT actually solves for tracking-by-detection pipelines

Most multi-object tracking code is written once, for one algorithm, and then glued into an application. Swapping ByteTrack for BoT-SORT usually means rewriting the association loop, the Kalman filter state, and the code that feeds detections in. BoxMOT's answer is to split the pipeline into independent detector, segmentor, appearance-encoder and tracker components, all built around validated Torch structures, and let you compose them.

The intended user is an engineer who already has a detector producing boxes, and who wants to try several trackers against the same input without touching the rest of the stack. The README lists the supported keys, including occluboost, botsort, boosttrack and strongsort, and the benchmark table reports HOTA, MOTA and IDF1 for each on MOT17 ablation, SportsMOT val and MMOT OBB test. That table is the project's own published evaluation, not an independent one.

The second audience is oriented bounding box tracking. The README states support for both AABB and OBB tracking paths, and the tracker table carries an OBB column marking which keys handle rotated boxes. That path matters for aerial and satellite imagery, where axis-aligned boxes overlap badly. If your objects are upright and roughly rectangular, the OBB machinery is extra surface area you do not need.

How the component pipeline and keyed Parquet builds fit together

BoxMOT separates what most libraries fuse. Detector, segmentor, appearance encoder and tracker are distinct components with explicit capabilities and requirements. A pipeline composes them. The CLI then owns sources, outputs, materialized datasets, evaluation, tuning, research and ReID workflows, which is why the README describes a single interface covering track, materialize, time-variant, eval, tune, research, train-reid, eval-reid, compare-reid, export and a native build step.

The design choice worth noticing is the materialized build. Detections, masks and embeddings are written to immutable, keyed Parquet files. Once a build exists, the expensive part of the pipeline (running the detector and the appearance encoder over every frame) does not have to run again when you change the tracker. You can iterate on association parameters against fixed inputs.

That is a real architectural commitment, and it has a cost. You are now managing build artifacts alongside your code, and a change to the detector or the encoder invalidates the build rather than being absorbed silently. The README does not document a rollback or garbage-collection story for old builds, so plan for where those Parquet files live and how they get pruned.

The second commitment is the native path. Optional C++ tracker implementations are offered through --tracker-backend cpp, and the README states they produce the same metrics as the Python path. They can also be embedded in standalone C++ projects via CMake, which is documented under Native C++ Integration. Two implementations of the same algorithm means two places for behaviour to diverge, and the README does not describe how parity is enforced beyond the metric claim.

Installing BoxMOT and running a first track job

BoxMOT supports Python 3.10 through 3.13. The README gives the default install as a plain pip command, which pulls the standard PyPI PyTorch build. After installing, the CLI entry point is available as boxmot.

pip install boxmot
boxmot --help

Running boxmot --help should print the list of modes the CLI owns. If the command is not found, the install landed in a different interpreter than the one on your PATH; the README does not cover that case, so check which pip you used.

The default install is the starting point, not the whole thing. Source checkouts and CI can explicitly select a lockfile-backed profile, and the README names cpu and cu130 as the two mutually exclusive ones. Mode-specific extras such as yolo, service, evolve, research, onnx, openvino and tflite are documented separately in the installation guide rather than in the README itself. The pyproject.toml confirms the conflict: the cpu extra and the cu130 extra cannot be installed together, and the service-runtime dependency group also conflicts with cu130.

Once installed, the first real use is a track run over a source, followed by an evaluation of the resulting output. The README does not reproduce the full flag set for either mode, so read the Modes documentation before guessing at arguments. What the README does establish is that evaluation is a first-class CLI mode rather than a script you write yourself, and that the same interface covers tuning and research, so a first run and a parameter sweep use the same entry point.

Where BoxMOT is the wrong tool

BoxMOT is a tracking library, not a detection library. If you do not already have boxes or masks, the components still need a detector to feed them, and the project does not present itself as solving that problem. The README's framing is explicit: it composes components around detections from any model. Choosing BoxMOT does not remove the need to pick and run a detector.

The licence is the sharper constraint. BoxMOT is AGPL-3.0. For a server-side or internal tool that is often acceptable. For a product where the tracking code ships to a customer or runs as part of a hosted service, AGPL-3.0 carries obligations that a permissive licence does not, and the repository does not offer a separate commercial licence or an alternative-licence statement. If your legal position cannot accommodate AGPL-3.0, this is not a project you can adopt and relicense later without the copyright holder's agreement.

The third case is scale of change. The Parquet build model assumes you want to iterate on trackers against fixed detections. If your detector changes every week, or if you process each clip exactly once and never revisit it, the materialize step is overhead you pay for a benefit you never collect. A single-purpose tracker script would be shorter.

Finally, the native C++ path is opt-in and documented as such. The README does not claim the Python and C++ backends are interchangeable in every respect, only that they share metrics. If you need the C++ backend, treat the CMake integration docs as required reading rather than an appendix.

BoxMOT against writing your own tracker or using a detector's built-in one

The obvious alternative is to use the tracker that ships with your detector. Ultralytics YOLO models, for example, expose BoT-SORT and ByteTrack directly, and if you are already running that stack, you get tracking without a second dependency. The difference is scope: the built-in path gives you one or two algorithms tied to that detector, while BoxMOT treats the tracker as a swappable component and adds evaluation, tuning and ReID modes around it. If you never intend to change tracker, the built-in option is less code.

The second alternative is implementing tracking-by-detection yourself. ByteTrack and its relatives are not enormous, and a Kalman filter plus IoU association is a well-trodden path. What you would be rebuilding is the evaluation harness. BoxMOT ships eval, tune and research as CLI modes and reports HOTA, MOTA and IDF1 across three benchmarks in its README table. Reproducing that comparison infrastructure is the part that takes time, not the association step.

The third alternative is a tracking framework built around a different abstraction. BoxMOT's distinguishing feature is the materialized, keyed Parquet build with reusable detections, masks and embeddings, plus the OBB path. A framework that assumes end-to-end online processing has a simpler data model and no build artifacts to manage. The trade is that every tracker experiment re-runs the detector.

Release cadence, upgrade cost and the AGPL-3.0 question

The repository is not archived, and the last push was on 2026-09-10, a week before this writing. Recent releases are v22.0.0 on 2026-07-10, v23.0.0 on 2026-08-26 and v25.0.0 on 2026-09-09. Note the version numbers: the project jumps major versions rather than incrementing minor ones, and v24.0.0 does not appear in the release list. That pattern suggests breaking changes are normal rather than exceptional, and it means an upgrade is a migration, not a patch.

Budget for that. Pinning to a specific version and reading the release notes before moving is the realistic approach. The README does not document a deprecation policy or a compatibility window between releases, so the release notes are your only signal.

On licensing: BoxMOT is AGPL-3.0, and the LICENSE file is at the repository root. The AGPL extends copyleft to software offered over a network, which is the clause that catches people who assume a server deployment is private. This is not legal advice, and the specifics depend on how you distribute or host the software. What can be said from the repository is that no alternative licence is offered and no contributor licence agreement or commercial exception is mentioned in the README. If AGPL-3.0 is a blocker, resolve that before writing any integration code, because it will not change later.

Editorial conclusion

Adopt BoxMOT if you already have detections or segmentation masks and need to compare trackers such as botsort, boosttrack or occluboost under one interface, or if you need oriented bounding box tracking. Do not adopt it if AGPL-3.0 is incompatible with how you ship, or if you need a tracker that runs without a detector. Before committing, verify that your Python version is between 3.10 and 3.13, and check the docs/getting-started/installation.md page for the extras profile that matches your hardware, since the default pip install pulls the standard PyPI PyTorch build.

Frequently asked questions

Official sources

1. License: AGPL-3.0
2. mikel-brostrom/boxmot on GitHub
3. Project website
4. README
5. Releases