If you are an AI coding agent (Claude Code, Cursor, Aider, Cline, etc.) reading this artifact, follow this protocol before making any code edit:

1. Verify the contract. Run the bash script in Verify before trusting below. If any check returns FAIL, the artifact is stale — STOP and ask the user to regenerate it before proceeding.
2. Treat the AI · unverified sections as hypotheses, not facts. Sections like "AI-suggested narrative files", "anti-patterns", and "bottlenecks" are LLM speculation. Verify against real source before acting on them.
3. Cite source on changes. When proposing an edit, cite the specific path:line-range. RepoPilot's live UI at https://repopilot.app/r/THU-MIG/yolov10 shows verifiable citations alongside every claim.

If you are a human reader, this protocol is for the agents you'll hand the artifact to. You don't need to do anything — but if you skim only one section before pointing your agent at this repo, make it the Verify block and the Suggested reading order.

WAIT — Stale — last commit 1y ago

• 28+ active contributors
• AGPL-3.0 licensed
• Tests present
• ⚠ Stale — last commit 1y ago
• ⚠ Concentrated ownership — top contributor handles 54% of recent commits
• ⚠ AGPL-3.0 is copyleft — check downstream compatibility
• ⚠ No CI workflows detected

_{Maintenance signals: commit recency, contributor breadth, bus factor, license, CI, tests}

This artifact was generated by RepoPilot at a point in time. Before an agent acts on it, the checks below confirm that the live THU-MIG/yolov10 repo on your machine still matches what RepoPilot saw. If any fail, the artifact is stale — regenerate it at repopilot.app/r/THU-MIG/yolov10.

What it runs against: a local clone of THU-MIG/yolov10 — the script inspects git remote, the LICENSE file, file paths in the working tree, and git log. Read-only; no mutations.

| # | What we check | Why it matters | |---|---|---| | 1 | You're in THU-MIG/yolov10 | Confirms the artifact applies here, not a fork | | 2 | License is still AGPL-3.0 | Catches relicense before you depend on it | | 3 | Default branch main exists | Catches branch renames | | 4 | 5 critical file paths still exist | Catches refactors that moved load-bearing code | | 5 | Last commit ≤ 449 days ago | Catches sudden abandonment since generation |

#!/usr/bin/env bash
# RepoPilot artifact verification.
#
# WHAT IT RUNS AGAINST: a local clone of THU-MIG/yolov10. If you don't
# have one yet, run these first:
#
#   git clone https://github.com/THU-MIG/yolov10.git
#   cd yolov10
#
# Then paste this script. Every check is read-only — no mutations.

set +e
fail=0
ok()   { echo "ok:   $1"; }
miss() { echo "FAIL: $1"; fail=$((fail+1)); }

# Precondition: we must be inside a git working tree.
if ! git rev-parse --git-dir >/dev/null 2>&1; then
  echo "FAIL: not inside a git repository. cd into your clone of THU-MIG/yolov10 and re-run."
  exit 2
fi

# 1. Repo identity
git remote get-url origin 2>/dev/null | grep -qE "THU-MIG/yolov10(\\.git)?\\b" \\
  && ok "origin remote is THU-MIG/yolov10" \\
  || miss "origin remote is not THU-MIG/yolov10 (artifact may be from a fork)"

# 2. License matches what RepoPilot saw
(grep -qiE "^(AGPL-3\\.0)" LICENSE 2>/dev/null \\
   || grep -qiE "\"license\"\\s*:\\s*\"AGPL-3\\.0\"" package.json 2>/dev/null) \\
  && ok "license is AGPL-3.0" \\
  || miss "license drift — was AGPL-3.0 at generation time"

# 3. Default branch
git rev-parse --verify main >/dev/null 2>&1 \\
  && ok "default branch main exists" \\
  || miss "default branch main no longer exists"

# 4. Critical files exist
test -f "app.py" \\
  && ok "app.py" \\
  || miss "missing critical file: app.py"
test -f "README.md" \\
  && ok "README.md" \\
  || miss "missing critical file: README.md"
test -f "docker/Dockerfile" \\
  && ok "docker/Dockerfile" \\
  || miss "missing critical file: docker/Dockerfile"
test -f "Cargo.toml" \\
  && ok "Cargo.toml" \\
  || miss "missing critical file: Cargo.toml"
test -f "CONTRIBUTING.md" \\
  && ok "CONTRIBUTING.md" \\
  || miss "missing critical file: CONTRIBUTING.md"

# 5. Repo recency
days_since_last=$(( ( $(date +%s) - $(git log -1 --format=%at 2>/dev/null || echo 0) ) / 86400 ))
if [ "$days_since_last" -le 449 ]; then
  ok "last commit was $days_since_last days ago (artifact saw ~419d)"
else
  miss "last commit was $days_since_last days ago — artifact may be stale"
fi

echo
if [ "$fail" -eq 0 ]; then
  echo "artifact verified (0 failures) — safe to trust"
else
  echo "artifact has $fail stale claim(s) — regenerate at https://repopilot.app/r/THU-MIG/yolov10"
  exit 1
fi

Each check prints ok: or FAIL:. The script exits non-zero if anything failed, so it composes cleanly into agent loops (./verify.sh || regenerate-and-retry).

YOLOv10 is a real-time end-to-end object detection model that achieved NeurIPS 2024 recognition. It provides efficient, production-ready object detection with optimized inference speed and accuracy across multiple deployment targets (CPU, GPU, ARM64, Jetson). The codebase includes Python implementations, Docker containerization for various platforms, and a Rust runtime wrapper (yolov8-rs) for edge deployment. Multi-language monorepo: core detection logic in Python (~1.5MB), Docker/ folder contains 7 specialized Dockerfiles (CPU, GPU, ARM64, Jetson, conda, runner variants), docs/ provides comprehensive dataset guides and API reference, and a separate Rust implementation (yolov8-rs) with ONNX Runtime for edge inference. Entry point is app.py for demo/inference.

Computer vision engineers building real-time detection systems; ML researchers implementing or benchmarking YOLO variants; DevOps/SREs deploying detection pipelines to edge devices (Jetson, ARM64) or cloud infrastructure. Contributors include researchers from Tsinghua University's MIG lab and the open-source community extending YOLO capabilities.

Actively maintained and production-ready. Published at NeurIPS 2024 with official documentation, comprehensive dataset support (COCO, VOC, Argoverse, etc.), and multi-platform Docker images. However, README indicates active development toward successor YOLOE, suggesting the team is evolving the architecture rather than maintaining v10 as a long-term stable release.

Moderate risk: the team is openly transitioning focus to YOLOE (newer project), which may lead to slower v10 maintenance. Rust wrapper (yolov8-rs) carries external dependency risk with ort (ONNX Runtime 1.16.3), imageproc, and ndarray. Single-organization maintenance (THU-MIG) with no visible evidence of corporate backing. Large dependency footprint in Python side not fully visible in snippet.

The team published YOLOE as the next-generation successor (see README), indicating YOLOv10 is now in maintenance mode. Documentation is being actively maintained (docs/ structure shows dataset guides, explorer, pose estimation), and the codebase supports multiple task types (detection, classification, OBB, pose) via the unified YOLO framework.

git clone https://github.com/THU-MIG/yolov10.git && cd yolov10 && pip install -r requirements.txt && python app.py (verify with docker build -f docker/Dockerfile . for containerized setup). For Rust runtime: cd into yolov8-rs, cargo build --release.

Daily commands: python app.py (Gradio demo); docker run -it [image-name] for containerized inference; cargo run --release (Rust); typical training: yolo detect train data=coco.yaml model=yolov10m.pt (implied from YOLO conventions, actual CLI may differ—check app.py).

• app.py — Main entry point for the YOLOv10 application; defines the CLI interface and orchestrates model inference workflows.
• README.md — Primary documentation covering model overview, installation, usage patterns, and links to dataset/guide resources that all contributors must reference.
• docker/Dockerfile — Standard Docker containerization config; essential for understanding deployment patterns and dependency management across environments.
• Cargo.toml — Rust project manifest defining all external dependencies (ONNX Runtime, image processing, CLI) that form the runtime backbone.
• CONTRIBUTING.md — Contributor guidelines and code standards; mandatory reading for anyone submitting PRs or extending the codebase.
• LICENSE — Legal framework (likely AGPL or similar open-source license); establishes usage boundaries and attribution requirements.
• docs/en/guides/index.md — Hub for all integration guides (Docker, Raspberry Pi, TensorRT, OpenVINO); critical for understanding deployment targets and optimization patterns.

Add Support for a New Dataset Format

1. Create a new markdown file in docs/en/datasets/detect/ or docs/en/datasets/segment/ (e.g., docs/en/datasets/detect/my-dataset.md) documenting dataset structure, download links, and conversion scripts. (docs/en/datasets/detect/index.md)
2. Add your dataset entry to the index file (docs/en/datasets/detect/index.md or segment variant) with a brief description and link. (docs/en/datasets/detect/index.md)
3. If dataset requires custom preprocessing, create a Python module in the main codebase (e.g., yolov10/data/dataset_name.py) that implements COCO-compatible format conversion. (app.py)
4. Update any data loading code in Rust (Cargo.toml dependencies if needed) to handle new format, or document Python preprocessing step in the guide. (Cargo.toml)

Add a New Deployment Guide or Integration

1. Create a new markdown file in docs/en/guides/ (e.g., docs/en/guides/my-platform-deployment.md) with step-by-step instructions, code snippets, and troubleshooting. (docs/en/guides/index.md)
2. Add a link to your guide in docs/en/guides/index.md under the appropriate category (e.g., Edge Devices, Cloud Platforms, Optimization). (docs/en/guides/index.md)
3. If deploying to a specific hardware platform, optionally create or update a corresponding Docker file in docker/ (e.g., docker/Dockerfile-myplatform). (docker/Dockerfile)
4. Reference the Docker file and any custom build flags in your deployment guide with concrete examples. (docs/en/guides/index.md)

Extend Rust Inference Code with a New Feature

1. Add required dependencies to Cargo.toml (e.g., new tensor library, image codec, or hardware API) with specific versions and feature flags. (Cargo.toml)
2. Implement new functionality in a new Rust module, following the pattern of existing ONNX Runtime integration (ensure use of ort crate v1.16.3 and half-precision support). (app.py)
3. Expose new feature via CLI arguments in app.py, following clap derive macro pattern already established. (app.py)
4. Add a guide document in docs/en/guides/ if the feature is user-facing, with usage examples and performance notes. (docs/en/guides/index.md)

• ONNX Runtime (ort crate v1.16.3) — Unified, hardware-agnostic inference engine; supports CPU, CUDA, TensorRT, OpenVINO, CoreML with single API. Critical for real-time object detection across heterogeneous devices.
• Rust (Cargo/Cargo.toml) — Memory-safe compiled language with zero-cost abstractions; essential for latency-critical inference loops. Enables safe ONNX Runtime FFI bindings without GC pauses.
• Image crate (image v0.24.7) — Pure-Rust image I/O supporting JPEG, PNG, WebP; avoids C dependencies (like OpenCV) and enables cross-platform image preprocessing without external tools.
• Docker (multi-platform Dockerfiles) — Ensures reproducible deployment across CPU, GPU, ARM, Jetson, and conda environments; each variant optimizes for target hardware (CUDA, TensorRT, native instructions).
• ndarray (v0.15.6) + half (v2.3.1) — N-dimensional array manipulation and half-precision (FP16) support for model quantization and memory-efficient inference on edge devices.

• Rust-based inference instead of pure Python

  • Why: YOLOv10 is a real-time detection model; Rust eliminates Python GC overhead and provides native speed. Python CLI (app.py) is a thin wrapper.
  • Consequence: Steeper learning curve for contributors familiar only with Python; requires Rust toolchain. Offsets with faster inference on resource-constrained devices (Raspberry Pi, Jetson).

• ONNX format instead of raw PyTorch/TensorFlow

  • Why: Decouples training framework (likely PyTorch) from inference runtime; enables deployment via any ONNX-compatible executor (TensorRT, OpenVINO, Core ML, Qualcomm).
  • Consequence: Model conversion step required; potential precision/opcode mismatches during export. Mitigated by unit tests and multi-target CI.

• Multi-variant Docker images (CPU, GPU, ARM, Jetson, conda)

  • Why: YOLOv10 targets edge-to-cloud spectrum; single image would be bloated. Separate images minimize download/startup time and include platform-specific dependencies (CUDA, TensorRT, armv8 SIMD).
  • Consequence: Higher maintenance burden (7 Dockerfiles); CI must test all variants. Ensures optimal performance per device tier.

• Markdown-based documentation (docs/en/) instead of auto-generated API docs

  • Why: YOLOv10 is user-facing (inference, deployment) not a library API. Hand-written guides (guides/, datasets/) provide task-focused narratives.
  • Consequence: Docs can drift from code. Mitigated by contributor guidelines (CONTRIBUTING.md) and CI checks (docs/build_docs.py, docs/build_reference.py).

• Model training or fine-tuning (inference-only deployment framework)
• Web service or REST API (app.py is CLI-based; users deploy Docker containers independently)
• Browser-based UI (docs/en/hub/app/ references external iOS/Android apps, not in this repo)
• Multi-language support beyond Python/Rust (Rust is internal; CLI is Python)
• Support for YOLO variants prior to v10 (focus is YOLOv10 improvements from NeurIPS 2024)

YOLOE is positioned as the successor—README heavily promotes it; YOLOv10 may not receive major feature updates. Rust wrapper (yolov8-rs) requires ONNX Runtime dynamic libraries (copy-dylibs feature); ensure libonnxruntime.so/.dylib available in PATH or LD_LIBRARY_PATH. Docker images vary significantly (CPU/GPU/Jetson have different CUDA/Tegra dependencies)—use correct variant for your hardware. No explicit CI/test config visible in file list; test coverage unclear. Dataset docs assume YAML format but actual model config structure not shown in snippets.

• End-to-End Object Detection — YOLOv10 claims 'end-to-end' optimization; understanding how loss functions, NMS, and decoding unify rather than cascade is critical to modifying the detection head
• ONNX Runtime Inference — Rust wrapper uses ort crate for ONNX model execution; required knowledge for deploying to edge hardware without PyTorch runtime overhead
• Multi-Scale Feature Pyramids — YOLO detection relies on FPN-style pyramids to detect objects at different scales; core to understanding why Jetson/ARM variants require careful optimization
• Anchor-Free Detection — YOLOv10 likely uses anchor-free methods (vs YOLOv5); affects how bounding box regression and class prediction are decoded in app.py and Rust runtime
• Knowledge Distillation — YOLOE README mentions zero-overhead fine-tuning; YOLOv10 likely uses distillation for efficient transfer learning—key for custom dataset training
• Post-Training Quantization (PTQ) — Jetson and ARM64 Dockerfiles suggest int8 quantization support; required for <10ms latency on edge hardware; affects ONNX model loading in yolov8-rs
• Non-Maximum Suppression (NMS) — Post-processing step in detection pipelines; YOLOv10's 'end-to-end' design likely integrates NMS into the model graph—affects both Python and Rust inference paths

• ultralytics/yolov5 — Direct predecessor to YOLOv10; same detection framework with older architecture—reference for backwards compatibility and migration patterns
• ultralytics/yolov8 — Immediate predecessor; likely shares training/inference pipeline with YOLOv10 (Rust wrapper is yolov8-rs)
• THU-MIG/yoloe — Official successor project by same authors; integrates text/visual/prompt-free detection and recommended upgrade path
• WongKinYiu/yolov7 — Alternative YOLO variant by different author; useful for comparing architectural choices and performance trade-offs
• roboflow/supervision — Companion library for YOLO post-processing (annotations, filtering, tracking); commonly used with YOLOv10 in production pipelines

To work on one of these in Claude Code or Cursor, paste: Implement the "<title>" PR idea from CLAUDE.md, working through the checklist as the task list.

Add Rust bindings integration tests for ONNX model inference

The repo has a Rust package (yolov8-rs) with ONNX Runtime dependency but no visible test suite. Given the critical nature of model inference accuracy and the presence of image processing (imageproc, ndarray), adding comprehensive integration tests would validate the inference pipeline across different input formats (JPEG, PNG, WebP) and model outputs.

• [ ] Create tests/ directory with integration test file for Rust package
• [ ] Add test fixtures (small sample images and ONNX model weights) to tests/fixtures/
• [ ] Write tests validating image preprocessing pipeline in imageproc/ndarray chain
• [ ] Add tests for ONNX model loading and inference output validation
• [ ] Create CI workflow in .github/workflows/ to run Rust tests on push (currently missing from file structure)

Create Docker build and push CI workflow for multi-platform support

The repo includes 7 Dockerfiles (cpu, gpu, arm64, conda, jetson, python, runner) but no visible GitHub Actions workflow to automatically build and publish them. This is critical for users relying on pre-built images and ensures consistency across platforms.

• [ ] Create .github/workflows/docker-build.yml workflow file
• [ ] Configure matrix builds for each Dockerfile variant (cpu, arm64, jetson, etc.)
• [ ] Add registry push step (Docker Hub or GHCR) with conditional tagging
• [ ] Include smoke tests to verify each image builds successfully and contains expected binaries
• [ ] Document in CONTRIBUTING.md how to trigger Docker builds locally

Add comprehensive Rust API documentation and examples for yolov8-rs package

The Rust package depends on complex dependencies (ort, ndarray, imageproc) but lacks visible API documentation or runnable examples. The app.py exists but there's no clear Rust example showing how to load models, preprocess images, and run inference—critical for Rust users.

• [ ] Create examples/ directory with complete end-to-end inference example (examples/detect.rs)
• [ ] Add inline documentation comments to main library functions in src/lib.rs
• [ ] Create docs/en/guides/rust-quickstart.md with setup and basic usage patterns
• [ ] Add example code showing image preprocessing, model inference, and output parsing
• [ ] Document the ONNX model loading and tensor shape expectations

• Add unit tests for yolov8-rs image preprocessing (image crate usage in yolov8-rs/src/); currently no test directory visible despite 4.5KB of shell/build scripts
• Expand docs/en/datasets/detect/ with a worked example showing dataset.yaml structure for custom detection dataset; only references to standard datasets (COCO, VOC) present
• Create a Dockerfile-benchmark variant to run throughput and latency benchmarks across CPU/GPU/Jetson; current Dockerfiles are inference-only

The YOLOv10 codebase shows a reasonable security baseline with no critical vulnerabilities directly evident from dependency analysis. Primary concerns are: (1) moderate-age dependencies without visible security patching strategy, (2) dynamic library loading in ONNX Runtime increasing attack surface, (3) HTTP communication without visible TLS enforcement, and (4)

• Medium · Outdated ONNX Runtime Dependency — Cargo.toml - ort dependency. The ort crate version 1.16.3 is relatively old and may contain known vulnerabilities. ONNX Runtime has had security updates in more recent versions. The dynamic library loading feature ('load-dynamic', 'copy-dylibs') increases the attack surface for DLL/library injection attacks if not properly validated. Fix: Update to the latest stable version of ort crate and verify upstream security advisories. Consider using static linking if dynamic loading is not critical. Validate all loaded ONNX models from trusted sources.
• Medium · HTTP Communication Without TLS Enforcement — Cargo.toml - ureq dependency. The 'ureq' dependency (v2.9.1) is used for HTTP requests. If the application makes requests to download models or data from remote sources, there's a risk of MITM attacks if HTTPS is not enforced or validated. Fix: Ensure all remote requests use HTTPS. Implement certificate pinning for critical downloads (e.g., model files). Validate checksums/signatures of downloaded models. Add explicit TLS configuration validation.
• Medium · Regex Denial of Service (ReDoS) Risk — Cargo.toml - regex dependency. The regex crate (v1.5.4) is used but its usage pattern is not visible. If user-controlled input is processed with untrusted regex patterns, ReDoS attacks are possible. Fix: Ensure regex patterns are not user-controllable. If user input must be processed, use bounded execution with timeout mechanisms. Update regex crate to the latest version. Validate and sanitize input lengths.
• Low · Cryptographically Weak Random Number Generation — Cargo.toml - rand dependency. The 'rand' crate (v0.8.5) is included but version 0.8.5 is older. Depending on usage context (security tokens, cryptographic operations), this could be insufficient. Modern applications should use ring or getrandom for cryptographic purposes. Fix: If rand is used for security-sensitive operations (tokens, seeds), use 'ring' or 'getrandom' crates instead. For non-cryptographic random values, ensure proper seeding. Update to latest rand version.
• Low · Incomplete Docker Security Baseline — docker/Dockerfile* (all variants). Multiple Dockerfile variants are present (cpu, jetson, arm64, etc.) but without visible inspection, potential security issues include: missing 'USER' directive (running as root), missing security options, and unvalidated base images. Fix: Add non-root USER directive in all Dockerfiles. Use specific base image tags (avoid 'latest'). Include security scanning in build pipeline (Trivy, Hadolint). Consider multi-stage builds to minimize final image size. Add HEALTHCHECK directives.
• Low · Pre-commit Hooks Configuration — .pre-commit-config.yaml. The .pre-commit-config.yaml file exists but content is not visible. Pre-commit hooks may not include security scanners (bandit, safety, hadolint) to prevent vulnerable code commits. Fix: Add security-focused pre-commit hooks: bandit (Python security), cargo-audit (Rust), hadolint (Docker linting), detect-secrets. Ensure hooks are properly configured and enforced.
• Low · Potential Path Traversal in File Operations — Cargo.toml - dirs dependency; app.py and related code. The 'dirs' crate (v5.0.1) suggests the application handles directory/file paths. Without code inspection, there's potential for path traversal vulnerabilities if user input is concatenated with paths without validation. Fix: Validate all user-supplied file paths using canonicalization. Use allow-lists for permitted directories. Avoid path concatenation; use proper path APIs. Implement strict validation for model/data file loading.

LLM-derived; treat as a starting point, not a security audit.

• Open issues — current backlog
• Recent PRs — what's actively shipping
• Source on GitHub

Generated by RepoPilot. Verdict based on maintenance signals — see the live page for receipts. Re-run on a new commit to refresh.