Plexo: a download manager that splits one file across every network adapter you have

Bandwidth aggregation only works when the links are really separate

Plexo is a download manager built around one idea: a single TCP connection is limited by the path it travels, so if the machine has more than one way out to the internet, the file should be split across all of them.

The README's own troubleshooting section states the condition more bluntly than any marketing would. Plexo adds speed only when each network reaches the internet through its own connection. Wi-Fi from a home router plus a phone tethered over USB works. Wi-Fi and Ethernet plugged into the same router does not, because both share one connection and the total stays the same. That is the whole design in one sentence, and it is the sentence to keep in mind before installing anything.

The connection list comes from the operating system. Plexo can use any connection your operating system shows as a network adapter, which means virtual, VPN and isolated adapters appear in the app too, and the README advises checking each network's latency and speed in the app to find out which are real.

The audience is desktop users on macOS, Windows and Linux whose speed problem comes from having more bandwidth available than a single connection can use. The topics attached to the repository cover the same ground, with bandwidth-aggregation, multiconnection, parallel-downloads and downloadmanager among them, and the project describes itself as combining Wi-Fi, Ethernet, mobile networks and other available connections.

A torrent client is part of the scope too, which puts Plexo in a different category from a plain accelerator. It handles direct links, magnet links and .torrent files, lets you select which files in a torrent to take, and pauses and resumes supported downloads across restarts.

Chunking, balancing and racing the slow tail of a download

The mechanism has several parts, and they are worth separating because they solve different problems.

Chunking is the core. Plexo downloads file chunks in parallel across connections, and it balances chunks across connections so that faster networks handle more of the download. That is the difference from simply opening several connections to the same server: the work is distributed by measured throughput rather than split evenly, so a slow link does not hold up a fast one.

The stream count is not fixed. Plexo automatically adjusts parallel streams to network, server and disk performance, and the troubleshooting section explains what that means in practice: if downloads to a hard drive are slow, leave Streams on Auto in New download, because Auto lowers the streams when the disk cannot keep up while a fixed number does not. That is a genuinely useful design decision, since the bottleneck is often the write side rather than the network.

The last piece is the slow tail. Plexo races slow chunks on idle connections to avoid a slow finish. In a parallel download the total time is set by the last chunk, so a few stragglers can dominate the wall clock even when the average speed is good. Reassigning those stragglers to a connection that is free is what stops the tail from ruining the result.

The user-facing side is the same idea made visible. The app shows live speeds, time remaining and per-network progress, networks can be enabled or disabled during a download, and you can rename networks and customise their colours, which is how you keep track of which physical link is which.

Browser capture with your existing authenticated session

The second major feature set is browser integration, and the mechanism behind it is the reason the feature exists.

Plexo can capture downloads or send individual links to the app, and it can download files using your browser's authenticated session. That last point is the significant one. A link that needs a login, a cookie or a one-time token usually cannot be fetched by a separate download client, because the client has no session. Handing the request to a browser extension that runs inside the logged-in session means the fetch carries the credentials, and the file arrives anyway.

The extension is visible in the repository layout, which has an extension/ directory at the top level alongside src/ and e2e/, and package.json carries a dedicated script for it, build:extension, which runs node extension/build.mjs.

The capture path also has controls that matter for daily use. You can exclude specific websites and skip small files, so the extension does not intercept every image on every page. The download management side adds queueing with configurable concurrent downloads, bulk pause, resume, retry and removal, automatic reconnection of downloads after the system sleeps, and replacement of expired links without losing progress.

The expired link case is worth a note because it is the one that would otherwise lose work. Download URLs that carry a signature or a token expire, and a manager that restarts such a download from zero has thrown away everything it fetched. Plexo replaces the link and keeps the progress, which is a small feature that decides whether a tool is usable over a long download.

Bandwidth controls, allowances and scheduled downloads

The third feature area is about being a good citizen of your own connection, which is what a download accelerator needs if you also make video calls.

You can set global and per-network speed limits, which means the tethering link used for a large file can be capped without slowing the Wi-Fi link you are streaming on. There is a Slow mode for calls and streaming, and the README describes it as switching to that mode when you need the bandwidth for something else. Data allowances can be set daily, weekly or monthly, so a metered mobile connection can be given a hard ceiling, and downloads can be scheduled by time and day.

That combination of features is what makes this usable as a daily driver rather than a one-off trick. An accelerator that can only go faster is a toy. One that can be told to stop, to cap itself, and to run at three in the morning is a tool.

The limits are per-network as well as global, which pairs naturally with the balancing behaviour. If you have a slow tethering link you do not want to carry much traffic, the speed limit and the chunk balancing reinforce each other, because a network that is capped will be given less of the work.

Where the trade-off sits: all of this control is local to the app. Plexo shapes how the operating system's connections are used by this application, and it cannot change what the router, the ISP or the server on the other end allows. The speed it reports is a speed of the links you have, not of the service you are downloading from.

An Electron app with a browser extension and a release candidate tag

The engineering shape of Plexo follows from what it does. The primary language is TypeScript, and the repository is an Electron application: package.json names electron-vite as the dev and build driver, electron-builder as the packager, and the main entry point is ./out/main/index.js. The scripts show a fairly conventional desktop app pipeline with format, lint, four separate typecheck targets for node, web, e2e and extension code, and separate build targets for Windows, macOS and Linux.

The project also has a browser extension, an e2e directory, a Playwright configuration and a playwright.config.ts file, so the test story covers the app rather than only the extension. The top level of the tree includes build/, docs/, resources/, patches/, scripts/ and an electron-builder.yml, plus a SECURITY.md and a CONTRIBUTING.md.

A detail in the build scripts shows the packaging is not trivial. The postinstall step runs patch-package, then install-electron, then electron-builder install-app-deps, and the dependencies include native modules such as fs-chunk-store, koffi and bittorrent-peerid. fs-chunk-store is a piece of the on-disk story: a chunked download needs somewhere to put the pieces before they are assembled, and the app bundles its own store for that.

The release state is what a buyer should weigh most heavily. The three most recent releases are v1.0.0-rc.15 on 2026-10-11, v1.0.0-rc.14 on 2026-10-07 and v1.0.0-rc.13 on 2026-10-04, and package.json still carries the version 1.0.0-rc.15. A release candidate weeks before a final release is not a stable channel to build a workflow on. The repository is not archived and the last push was on 2026-10-18, so the code is moving fast, which cuts both ways.

The licence is MIT, which is about as permissive as software licences get, and the project links a Ko-fi page for funding. MIT means you can vendor, modify and redistribute it without obligations beyond keeping the notice, and there is no copyleft condition that would affect how you ship a build.

Two failures worth knowing before you start a large download

The troubleshooting section in the README is the most useful part of the documentation, and it names four specific situations where things do not work as expected.

The first is the aggregate speed problem already described, where two adapters share one router and therefore one bottleneck. The second is a network that does not appear at all. On macOS an iPhone over USB needs the iPhone USB network option in System Settings to have Disable unless needed turned off, an Android phone needs TetherKit installed, and on Windows the phone maker's driver has to be present for the phone to show up in Network Settings.

That TetherKit dependency is worth spelling out, because macOS has no driver for RNDIS, the protocol Android USB tethering uses, so the phone charges but no network adapter appears. TetherKit is an open source app that adds one without a kernel extension, and the README gives the install as a single command:

brew install XiaoMiku01/tap/tetherkit

The rest of the sequence is to connect the phone over USB, turn on USB tethering in the phone's hotspot settings, open TetherKit, approve its helper with your password on first run, and pick the phone and connect.

The third failure is operating system policy rather than application logic. If Windows turns Wi-Fi off when Ethernet is plugged in, the fix is in the Group Policy Editor, gpedit.msc, under Computer Configuration, Administrative Templates, Network, Windows Connection Manager, where the setting for minimising the number of simultaneous connections to the internet or a Windows domain has to be set to Disabled. The README notes that if both connections stay up but one sits idle, Windows may be routing its traffic out the other adapter, and asks for such setups to be added to issue 65.

The fourth is mundane but easily misdiagnosed. If a network stays idle after a phone reconnects, pause the download and resume it.

One more limitation sits outside the app entirely. On Windows the installer is not code-signed, so Windows shows a Windows protected your PC warning, and the README instructs the user to click More info and then Run anyway. That is a normal first-run step for unsigned builds, and it is also the moment to decide whether you are comfortable running unsigned installers on your machine at all.

Editorial conclusion

Plexo fits a user with two genuinely separate internet paths, such as home Wi-Fi plus a phone tethered over USB, who downloads large files and torrents and wants the second link to carry real weight. It is the wrong tool for a single-connection machine, where it can only add overhead, and for anyone unwilling to install an unsigned Windows build, since the README states the installer is not code-signed. Before you rely on it, read the SECURITY.md file in the repository, check that your operating system actually keeps both adapters connected, and note that version 1.0.0-rc.15 is a release candidate, so the download path itself may still change between releases.

Frequently asked questions

Official sources

1. anmolkapil/plexo on GitHub
2. License: MIT
3. Project website
4. README
5. Releases