roboflow/trackers: Six Multi-Object Trackers Behind One update() Call

The gap between a detector and a usable track ID

A detector answers where objects are in one frame. Almost every downstream task, from counting people crossing a line to following a ball through a broadcast, needs to know that the box in frame 40 is the same object as the box in frame 12. That association step is what trackers provides, and it does so without shipping or assuming a detector. The README describes the library as plug-and-play multi-object tracking in Python for any detection model, and the intended audience spans researchers comparing algorithms, engineers shipping a pipeline, and hobbyists. The practical boundary is Python 3.10 or newer, stated both in the README and in requires-python in pyproject.toml. If your detector already emits supervision.Detections, the integration surface is one method call.

One update() signature, six association strategies

Every tracker exposes update(detections, frame=None) and returns tracked detections. That uniformity is the architectural point: swapping ByteTrackTracker for another class is a one-line change, not a rewrite. Underneath, each class is a separate re-implementation of a published paper rather than a wrapper around someone else's code, which the README calls clean-room. SORT is the baseline of Kalman filtering plus Hungarian matching. ByteTrack adds two-stage association over high and low confidence detections. OC-SORT adds observation-centric recovery for lost tracks. BoT-SORT adds camera motion compensation, which is why it is the one to reach for when the whole frame shifts. C-BIoU uses cascaded buffered IoU matching for fast or irregular motion. McByte is mask-conditioned: it feeds propagated SAM or Cutie masks into matching as an extra cue. The README publishes HOTA numbers for all six across MOT17, SportsMOT, SoccerNet and DanceTrack at default parameters, and notes that tuning results exist for all but McByte, which the project deliberately benchmarks at defaults only. Those tables are the honest way to choose between algorithms, far more than any prose comparison. The README also states that appearance and ReID branches are not included where the original papers offer them, and that each tracker's docs page defines the exact scope. That single sentence rules out a whole class of use cases, which the next sections cover.

Install trackers and track a video from the CLI

The base package installs from PyPI. The README gives this as the primary path, and notes that Python 3.10 or higher is required.

pip install trackers

If you prefer to build from the repository, the README documents installing straight from git, which pulls the default branch.

pip install git+https://github.com/roboflow/trackers.git

The fastest first run does not require writing Python at all. The trackers track subcommand takes a video, webcam feed, RTSP stream or image directory and handles detection, tracking and annotated output in one command. The README gives this example, using rfdetr-medium as the detection model and bytetrack as the tracker:

trackers track \
    --source video.mp4 \
    --output.video output.mp4 \
    --detection.model rfdetr-medium \
    --tracker bytetrack \
    --show.labels \
    --show.trajectories

What you should see is an annotated video written to output.mp4 with boxes, class labels and trajectory trails drawn on each tracked object. Note the nested flag syntax: output.video and detection.model are grouped options, not flat flags. The CLI depends on jsonargparse, pinned in pyproject.toml to a range below version 5, and the comment in that file explains why: the parser subclasses private ActionYesNo internals, so the cap cannot be raised without re-verification. That is a real maintenance constraint worth knowing before you build tooling on top of the CLI.

Wiring trackers into an existing detection loop

The Python path assumes you already have a detector. The README's quick start uses the inference package as the detector and states plainly that it is not part of the base trackers install, so you install it separately. The loop below is the README example: read frames, infer, convert to supervision.Detections, hand them to the tracker.

import cv2
import supervision as sv
from inference import get_model
from trackers import ByteTrackTracker

model = get_model(model_id="rfdetr-medium")
tracker = ByteTrackTracker()

cap = cv2.VideoCapture("video.mp4")
while cap.isOpened():
    ret, frame = cap.read()
    if not ret:
        break

    result = model.infer(frame)[0]
    detections = sv.Detections.from_inference(result)
    tracked = tracker.update(detections)

The return value is tracked detections in the same supervision shape, so anything downstream that already consumes Detections keeps working. Because the interface is uniform, replacing ByteTrackTracker with another tracker class is the only edit needed to try a different algorithm. Two dependency notes from pyproject.toml matter here: numpy is pinned at 2.0.2 or newer, and supervision at 0.26.1 or newer. If your environment still holds numpy 1.x for another library, resolve that before installing, not after.

No appearance branch, and what that costs you

The clearest limitation is stated in the README rather than buried: appearance and ReID branches are not included where the original papers offer them. For most of the six algorithms that is a fair simplification, since SORT and ByteTrack are motion-only by design. It matters for BoT-SORT, whose published form pairs camera motion compensation with a ReID feature branch, and for any scene where two similar objects cross and motion alone cannot separate them. If your problem is re-identifying a person who leaves the frame and returns, this library is the wrong tool, and no amount of parameter tuning fixes a missing cue. The second constraint is maturity: pyproject.toml carries the classifier Development Status :: 4 - Beta. The API is uniform and documented, but a beta classifier means the project does not promise stability across releases. The third is the dataset skew in the published benchmarks. MOT17, SportsMOT, SoccerNet and DanceTrack cover pedestrians, sports and dance, all filmed with reasonably consistent object appearance. A traffic camera at night, thermal footage, or microscopy sits outside that evidence base, and the HOTA tables tell you nothing about your domain. The honest move is to treat those numbers as a shortlist generator, not a decision.

How trackers differs from BoxMOT

The README names BoxMOT directly as the AGPL-3.0 alternative and frames the licence as the differentiator: with Apache 2.0 you can ship trackers inside a closed-source product. That is a legal and distribution difference, not an algorithmic one, and for many teams it is the deciding factor. The second difference is implementation style. BoxMOT is described in the README's framing as an alternative built around vendored or wrapped code, while trackers re-implements each algorithm from its paper so the association logic is readable and editable in place. If you need to modify matching behaviour for a domain-specific reason, that distinction is practical rather than philosophical. The third difference is ecosystem coupling. Trackers speaks supervision.Detections natively, which is convenient if you are already in that ecosystem and a conversion cost if you are not. The trackers README does not describe BoxMOT's scope, so do not assume it fills the appearance gap. Choose on licence first if you ship closed source, and on whether you want to read and modify the association code second.

Maintenance, tuning cost and licence terms

The last push to the repository was on 2026-09-22, and the most recent release is 2.6.0 from 2026-08-06, titled McByte and dynamic frame rate. Before that came 2.5.0.post0 on 2026-07-09 and 2.5.0 on 2026-06-24, which added pluggable IoU variants and the C-BIoU tracker. That cadence suggests the algorithm set is still expanding, so expect the tracker list to grow and pin your version if you need reproducibility. Upgrading carries a specific risk beyond the beta classifier: the CLI parser depends on private jsonargparse internals, and the pin below version 5 exists because of it. A future jsonargparse release could force a parser rewrite, which would surface as CLI breakage rather than a silent behaviour change. Hyperparameter tuning is an optional extra, installed as trackers[tune], and it uses Optuna-based search through the trackers tune command. Budget for it: tuning against your own scene is the only way to move beyond the published defaults, and the README notes McByte is benchmarked at defaults only by design, so there is no tuning reference point for it. On licensing, the package is Apache 2.0 per the LICENSE file and the pyproject.toml licence field, which permits use in closed-source products. That is a statement about the licence text, not legal advice, and the dependency licences in your own environment are a separate question you should check.

Editorial conclusion

Adopt trackers if you already produce supervision.Detections and want to compare SORT, ByteTrack, OC-SORT, BoT-SORT, C-BIoU or McByte without writing association code, and if Apache 2.0 matters for closed-source distribution. Do not adopt it if your pipeline depends on appearance embeddings for re-identification, since the README states appearance and ReID branches are not included, or if you need a stable API surface, since pyproject.toml still classifies the package as Beta. Verify first that your detector output converts to supervision.Detections and that Python is at least 3.10, then run the same clip through two trackers and compare identity switches before committing to one.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. roboflow/trackers on GitHub