Torrent client compatibility matrix
What each torrent client actually does with LLM Torrents content — magnet links, .torrent files, webseeds, hybrid v1/v2 torrents, rechecking files you already have, path mapping, and DHT/PEX — plus recommended settings for seeding. Every cell below is labeled with how we know it, not just what the answer is.
How to read this table
Every cell in the matrix carries one of three evidence labels. We do not present documented behavior as something we've verified — if we haven't run it ourselves, the cell says so.
- Tested by us — we exercised this ourselves against the client. Currently this covers only qBittorrent and qBittorrent-nox, via the WebUI API add-paused → recheck → resume flow used in our swarm seed-health scanning work.
- Documented behavior — drawn from the client's own documentation, not independently verified by us. This is most of the table: we cannot run every client from our infrastructure.
- Unknown / not yet tested — we don't have reliable documentation or first-hand testing for this combination. Treat it as an open question, not a "no."
Per-client compatibility
qBittorrent (desktop — Windows/macOS/Linux)
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Full native support: resolves metadata via DHT/trackers/PEX. | Documented behavior |
| .torrent handling | Full native support: add via file picker or the WebUI upload endpoint. | Documented behavior |
| Webseed (BEP-19) | Supported on recent libtorrent-backed builds; HTTP/FTP webseed URLs in a torrent are honored alongside peers. | Documented behavior |
| Hybrid v1/v2 torrents | Supported on builds using the libtorrent 2.x backend. Older builds on libtorrent 1.2 are v1-only — use a current release. | Documented behavior |
| Recheck existing files | Confirmed: add torrent paused with an existing save path, Force Recheck, then resume — files that already match are marked complete with no re-download. | Tested by us |
| Path mapping / content layout | "Default Save Path" plus a per-torrent "Set location" and content-layout choice (Original / Create subfolder / Don't create subfolder). | Documented behavior |
| DHT / PEX | Both on by default; toggle under Options → BitTorrent. | Documented behavior |
| Recommended settings for seeding | Enable DHT, PEX, and LSD; cap global upload to roughly 50–80% of measured upstream (see the seeding safety guide); leave "Keep incomplete torrents in" unset when seeding in place. | Documented behavior |
qBittorrent-nox (Docker)
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Full native support, same libtorrent engine as desktop; add via WebUI or command line. | Documented behavior |
| .torrent handling | Full native support via WebUI upload or the local filesystem inside the container. | Documented behavior |
| Webseed (BEP-19) | Supported — same engine as the desktop build. | Documented behavior |
| Hybrid v1/v2 torrents | Supported on images built against libtorrent 2.x (most current linuxserver.io / official builds). Pin a current image. | Documented behavior |
| Recheck existing files | Confirmed: this is the exact flow exercised in our swarm seed-health scanning — add-paused via the WebUI API, Force Recheck, resume — against a container with pre-existing files bind-mounted in. Files that match are recognized without re-download. | Tested by us |
| Path mapping / content layout | The client's own save-path/content-layout options work the same as desktop, but the practical gotcha is the Docker bind mount: the path qBittorrent sees inside the container (e.g. /downloads) must be mapped to the host path holding your existing files, or a recheck against "the right folder" will fail to find them. | Documented behavior |
| DHT / PEX | Both on by default, same as desktop; ensure the container publishes/forwards the DHT UDP port if you want inbound DHT. | Documented behavior |
| Recommended settings for seeding | Same caps/DHT/PEX guidance as desktop qBittorrent. Mount your existing model directory straight in as the download path so it seeds in place instead of copying (see the seeding safety guide's Docker recipe). | Documented behavior |
unRAID (qBittorrent community container)
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Same underlying qBittorrent/libtorrent engine as the -nox container; full native support expected. | Documented behavior |
| .torrent handling | Same engine; full native support expected via the container's WebUI. | Documented behavior |
| Webseed (BEP-19) | Same engine as qBittorrent-nox; expected supported, not independently verified on the unRAID community template specifically. | Documented behavior |
| Hybrid v1/v2 torrents | Depends on which community template/image is installed and how current its libtorrent backend is — check the specific template's changelog. | Unknown / not yet tested |
| Recheck existing files | Same underlying recheck mechanism as qBittorrent-nox (Force Recheck against an existing save path), but we have not run this specifically against the unRAID Community Applications template — only against a generic qBittorrent-nox container. | Documented behavior |
| Path mapping / content layout | unRAID maps a share (e.g. an appdata/media share) into the container's download path via the template's path settings. Point the container's download path at the same share your inference tooling reads from to seed in place. | Documented behavior |
| DHT / PEX | Both on by default in the underlying engine; confirm the template forwards/exposes the DHT UDP port on the unRAID host. | Documented behavior |
| Recommended settings for seeding | Set the container's download path to the share holding your models, set upload cap and DHT/PEX per the qBittorrent guidance above; for VPN routing, check the specific community template's own VPN-binding option (several qBittorrent+VPN template variants exist). | Documented behavior |
Transmission
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Full native support. | Documented behavior |
| .torrent handling | Full native support, via GUI, transmission-remote, or the RPC API. | Documented behavior |
| Webseed (BEP-19) | Basic HTTP webseed support has existed since early Transmission 2.x releases; treat it as present but minimal compared to libtorrent-backed clients. | Documented behavior |
| Hybrid v1/v2 torrents | v2/hybrid support maturity varies significantly by Transmission version and we do not have a reliable current answer — check your specific version's release notes before relying on it. | Unknown / not yet tested |
| Recheck existing files | "Verify Local Data" re-hashes files already on disk against the torrent's piece hashes before seeding, without re-downloading matched pieces. | Documented behavior |
| Path mapping / content layout | Default download directory (GUI preferences, or -w for transmission-daemon) plus a per-torrent "Move data file to..." option. | Documented behavior |
| DHT / PEX | Both supported and toggleable in preferences. | Documented behavior |
| Recommended settings for seeding | Set the default download directory to your existing model folder, cap upload speed under the Speed tab, and leave DHT/PEX enabled (see the seeding safety guide for the VPN-binding caveat). | Documented behavior |
aria2c
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Supported via its BitTorrent extensions (--enable-dht); aria2 is primarily a download-focused tool rather than a long-running seeding daemon, so magnet resolution works but ongoing swarm participation needs an explicit seed-time/ratio configuration. | Documented behavior |
| .torrent handling | Full support, including loading a local .torrent file or metalink-style combined jobs. | Documented behavior |
| Webseed (BEP-19) | Strong support — combining a .torrent with HTTP(S)/FTP mirror URLs as webseeds is one of aria2's more distinctive features. | Documented behavior |
| Hybrid v1/v2 torrents | We do not have a reliable current answer on aria2's BitTorrent v2/hybrid support; historically this has been a known gap, but check current release notes rather than relying on this page. | Unknown / not yet tested |
| Recheck existing files | --check-integrity verifies existing on-disk pieces against the torrent's hashes before resuming, avoiding re-download of pieces that already match. | Documented behavior |
| Path mapping / content layout | -d/--dir sets the target directory per download; aria2 is CLI/RPC-driven and has a lighter concept of "content layout" than GUI clients — you point it at a directory rather than choosing subfolder options. | Documented behavior |
| DHT / PEX | DHT supported via --enable-dht; peer exchange supported via --enable-peer-exchange. | Documented behavior |
| Recommended settings for seeding | aria2 does not seed indefinitely by default — set --seed-time to a large value (or loop a resume via cron/systemd) if you want it to keep seeding after download completes, and use --dir to point at your existing model folder to seed in place. | Documented behavior |
Deluge
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Full native support. | Documented behavior |
| .torrent handling | Full native support via GUI, console UI, or the Web UI. | Documented behavior |
| Webseed (BEP-19) | Supported via its libtorrent backend. | Documented behavior |
| Hybrid v1/v2 torrents | Supported on Deluge 2.1+ (libtorrent 2.x backend). Deluge 1.x on libtorrent 1.x is v1-only — use a current release. | Documented behavior |
| Recheck existing files | "Force Recheck" re-verifies files already on disk against the torrent's hashes, the standard libtorrent-backed recheck behavior. | Documented behavior |
| Path mapping / content layout | Default download location in preferences, plus a per-torrent "Move Storage" option. | Documented behavior |
| DHT / PEX | Both supported and toggleable in preferences. | Documented behavior |
| Recommended settings for seeding | Point the download location at your existing model folder, cap upload speed in preferences, and leave DHT/PEX enabled. | Documented behavior |
BiglyBT
| Facet | Behavior | Evidence |
|---|---|---|
| Magnet handling | Full native support. | Documented behavior |
| .torrent handling | Full native support. | Documented behavior |
| Webseed (BEP-19) | Supported — BiglyBT descends from Vuze/Azureus, which had HTTP webseed support early on. | Documented behavior |
| Hybrid v1/v2 torrents | BiglyBT uses its own Java BitTorrent engine (not libtorrent); we do not have a reliable current answer on its v2/hybrid maturity. | Unknown / not yet tested |
| Recheck existing files | A "Force Recheck" action is available; general behavior is expected to match other clients (verify on-disk data before seeding), but we have not independently verified the specifics on BiglyBT's own engine. | Documented behavior |
| Path mapping / content layout | Per-torrent save path plus move-on-completion rules in preferences. | Documented behavior |
| DHT / PEX | Both supported. | Documented behavior |
| Recommended settings for seeding | Point the save path at your existing model folder and cap upload speed in preferences. BiglyBT is Java-based and generally heavier on memory/CPU than lighter native clients — size accordingly if running headless. | Documented behavior |