YOLOs-CPP: one C++ API across the whole YOLO family

The problem is version fragmentation, not missing models

The pitch for YOLOs-CPP is that the YOLO ecosystem has become fragmented at the C++ level, and the project's answer is a single API.

The three problems the documentation names are specific. Each YOLO version has different C++ implementations, so there is no single library that keeps up. The interfaces differ between tasks, so detection, segmentation and pose each need their own code. And most implementations lack proper error handling, testing and optimization, which is the gap that matters when the same code has to run in production rather than in a notebook.

The unified surface is small:

#include "yolos/yolos.hpp"

// One API for all YOLO versions and tasks
auto detector = yolos::det::YOLODetector("yolo11n.onnx", "coco.names");
auto detections = detector.detect(frame);

A detector is constructed from an ONNX model path and a class-names file, and a frame goes in and detections come out. The same shape holds for the other tasks, with the namespace changing: `yolos::det` for detection, and separate namespaces for segmentation, pose, OBB, classification and depth.

The version coverage in the description is v5 through v12 plus YOLO26, and the feature table states the same interface applies across that range. The header file is a single `yolos/yolos.hpp` include, and the public interface is documented separately in `docs/api/api.md`.

For a team maintaining a C++ vision stack, the value is not that a new model works, it is that the code that consumes the results does not change when the model does.

Task coverage keeps expanding, and each addition lands as a new example

The task list in the documentation is wider than detection, and the changelog in the README shows how it grew.

Segmentation came first for YOLOv8 and YOLO11, including quantized models, on 2025-01-26, with YOLOv9 segmentation following the same day. YOLOv9 object detection was added on 2025-01-29, oriented bounding boxes on 2025-02-11, YOLOv12 object detection on 2025-02-19, and pose estimation on 2025-03-16. Image classification arrived on 2025-05-15.

After that came the two most distinctive additions. YOLOE open-vocabulary detection and segmentation was added on 2026-04-11, with the Model Guide section and the `image_yoloe_seg` and `video_yoloe_seg` examples. And monocular metric depth estimation for YOLO26 arrived in v1.1.0 on 2026-08-02, through `yolos::depth::YOLODepthEstimator` and the `image_depth_inference` example.

The same v1.1.0 release added batch inference with `batchDetect`, `batchSegment` and `batchClassify`, and in-memory model loading across all supported tasks. That last one matters for a particular case the documentation calls out: loading a model straight from memory rather than from a file path, for encrypted stores, network streams and embedded resources.

The `examples/` directory is organised by task and input type, with a file for every combination: `example_image_det.cpp`, `example_video_seg.cpp`, `example_camera_pose.cpp`, `example_image_obb.cpp`, `example_camera_depth.cpp` and so on. Each has a matching shell script such as `run_image.sh`, `run_video.sh` and `run_camera.sh` at the repository root.

One structural note about the repository: the examples cover image, video and camera for every task, but the listing shows no `example_audio` or batch example file, even though the batch API exists in v1.1.0. The batch and in-memory features are newer than the example set.

Parity against Ultralytics is the test strategy

The engine is built on ONNX Runtime and OpenCV, and the way it is tested is the part that tells you how much to trust the numbers.

The feature table describes the test suite as 50 Ultralytics-parity tests plus 57 self-contained tests, running in a CI/CD pipeline. The parity framing is the important part. Rather than asserting that its own output is correct in isolation, the project checks its output against the reference Python implementation, which is the practical way to know that a C++ port has not quietly changed the semantics of a post-processing step.

There is a `benchmarks/` directory at the repository root and a benchmarks section linked from the README navigation, so performance is treated as something to be measured rather than asserted. The performance claims the project makes in its own announcements are qualified: the 530+ FPS figure for NVIDIA GPUs and Jetson comes from a separate repository, YOLOs-CPP-TensorRT, and the sub-2 ms inference latency claim comes from the ros2_yolos_trt ROS 2 package. Neither number is a property of the core engine on its own.

That distinction is worth keeping in mind when reading the project. The core library is the ONNX Runtime path. The faster paths are separate repositories, and there is also a companion multi-object tracking implementation, motcpp, and a ROS 2 integration package, ros2_yolos_cpp, all from the same author.

The `tests/` and `src/` directories, the `CMakeLists.txt`, the `Doxyfile` for API documentation and the `mkdocs.yml` for the documentation site complete the picture. The docs are built with mkdocs and the guide files live under `docs/guides/`, including `getting-started.md` and `models.md`.

Building it needs a C++17 toolchain and fetches ONNX Runtime for you

The prerequisites are specific and the build script handles the awkward part.

A C++17 compiler is required, with GCC 9 or later, Clang 10 or later, or MSVC 2019 or later. CMake 3.16 or newer is needed. OpenCV 4.5 or newer with the Core, ImgProc and HighGUI modules. And ONNX Runtime 1.16 or newer, which the documentation notes is auto-downloaded by the build script.

The installation sequence is short:

# Clone
git clone https://github.com/Geekgineer/YOLOs-CPP.git
cd YOLOs-CPP

# Build (auto-downloads ONNX Runtime)
./build.sh 1.20.1 0   # CPU build

The version argument to `build.sh` is the ONNX Runtime version, and the second argument is a build variant flag where 0 selects the CPU build. The repository also has `build.bat` and `build.ps1` for Windows, so the same entry point exists on all three desktop platforms.

That auto-download is the pragmatic choice and also the main supply-chain consideration. The build script reaching out to fetch a binary means your build depends on network access to the ONNX Runtime release endpoint, and it means the version being pulled in is the one you name on the command line rather than something your distro package manager pins. If you need a reproducible build, you have to pin that argument deliberately and mirror the artefact yourself.

The repository also has a `Dockerfile` and a separate `Dockerfile.cpu`, plus a `Dockerize.md`, and the feature table lists Docker among the supported platforms alongside Linux, Windows and macOS.

The Docker image builds against CUDA and expects a GPU runtime

The container path is worth reading because it shows the intended production shape and makes a couple of assumptions explicit.

The Dockerfile is a multi-stage build. The builder stage is based on `nvidia/cuda:12.2.0-devel-ubuntu22.04`, with `DEBIAN_FRONTEND=noninteractive` set, and it installs the build toolchain: build-essential, cmake, git, wget, unzip, pkg-config, ca-certificates and libopencv-dev. It then downloads ONNX Runtime itself, using a build argument `ONNXRUNTIME_VERSION` that defaults to 1.20.1, pulling the linux x64 GPU package from the ONNX Runtime releases and unpacking it into `/opt/onnxruntime`. The source is copied in, CMake is configured with `CMAKE_BUILD_TYPE=Release` and `-DONNXRUNTIME_DIR=/opt/onnxruntime`, and the build runs with `make -j$(nproc)`.

The run stage is a separate layer, which is the point of the multi-stage layout: the compiler toolchain stays in the builder and does not ship in the runtime image.

The GPU assumption is visible in the base image and in the ONNX Runtime package chosen. The build comment at the top of the file gives the run commands, and a separate line shows the GPU variant passing `--gpus all` to `docker run`, so the default invocation is the CPU path and the GPU one is opt-in at run time. The `Dockerfile.cpu` exists for a CPU-only image without the CUDA base.

For a team that has to reproduce the same inference environment on a build server, this is a reasonable reference. The caveat is the CUDA version: 12.2.0 is pinned in the base image, so a fleet running a different driver will need that changed.

AGPL-3.0 is the price of the unified engine

The licence is AGPL-3.0, and it is the single most consequential fact about this project for anyone outside a research or hobby context.

AGPL is the copyleft licence that extends the source-sharing obligation to network use. The obligation it creates is that if you modify the library and let other users interact with your modified version over a network, you have to offer them the corresponding source of your modified version. For a C++ inference library that gets linked into a service, that is a materially heavier requirement than MIT or Apache-2.0, and unlike LGPL it does not have the usual dynamic-linking escape route.

The practical test before you adopt this is straightforward. If you are building an internal tool, a research pipeline or an application you distribute with the library's own licence unchanged, the friction is low. If you are building a commercial inference service and you intend to modify the engine, the obligation to publish your modifications is real, and that is a decision for your legal team rather than for this article.

This is a licensing observation rather than legal advice, and the `LICENSE` file in the repository is the text that governs.

The rest of the maintenance picture is unremarkable and healthy. The repository is not archived, the last push was on 2026-08-23, and the release history shows v1.0.0 on 2026-01-18, a v1.0.0-onnx-tuned-models tag on 2026-01-20 and v1.1.0 on 2026-08-02. The project ships a `RELEASE.md`, a `scripts/` directory, `models/` and `quantized_models/` directories for the weights, and `data/` and `results/` for sample assets.

Editorial conclusion

YOLOs-CPP fits a C++ team that has to ship one object detection stack across several YOLO generations, or that needs segmentation, pose, oriented boxes, classification and depth behind the same interface without maintaining separate implementations per model version. It does not fit a team that cannot accept AGPL-3.0 terms for a linked library, and it does not fit a project that needs the newest hardware-specific inference path, since the repository's own companion projects cover that and the TensorRT figure the project quotes comes from a separate repository. Verify first that the task type you need is in the supported list rather than only detectable in a demo, that your ONNX model and its output layout match what the engine expects, since parity is tested against Ultralytics rather than against your own exported model, and that the licence terms are acceptable before you link it, because AGPL-3.0 obligations attach to distribution and network use.

Frequently asked questions

Official sources

1. Geekgineer/YOLOs-CPP on GitHub
2. License: AGPL-3.0
3. Project website
4. README
5. Releases