Two adapters help only when they lead to two internet connections
Plexo's useful trick is easy to misunderstand. It divides one file into HTTP byte ranges, opens workers on selected network interfaces, and writes each range at its final position in a staging file. Faster interfaces pull more chunks from a shared queue. If your laptop uses home Wi-Fi and a phone's cellular tether, both connections can contribute to the same download.
Wi-Fi and Ethernet plugged into the same router do not create another upstream connection. The README says the operating system will normally favor one route, while both adapters still share the same broadband service. Plexo also needs the remote server to honor range requests. It probes with a 1-byte ranged GET and falls back to one ordinary stream when the server returns 200 OK instead of 206 Partial Content.
Eight-megabyte chunks favor recovery and uneven links
Plexo uses chunks up to 8 MB and can start each interface with 8 connections, increasing to 32 when the server accepts them. The shared queue gives a fast link more work instead of reserving half the file for a slow one. Near the end, an idle connection may race a slow chunk and keep whichever attempt finishes first. That can prevent one lagging worker from holding the whole file open.
Resume handling is more careful than a blind restart. Plexo keeps partial data in a destination-side .plexo file and stores a small manifest in application data. Before continuing, it compares the remote ETag and Last-Modified values. If the source changed, it refuses to combine old and new ranges. Completed data is flushed and renamed in place, avoiding a second full-file assembly copy.
What happened when we ran it
Our sandbox installed commit 1200c96 in 28 seconds with Node 22. The install added 576 packages and occupied 689 MB on disk. The build completed in 15 seconds. Npm audit reported 0 known vulnerabilities: 0 critical, 0 high, 0 moderate, and 0 low in the dependency tree we tested.
The measured repository had 132 files, about 14,554 lines of source, and a 2.4 MB checkout. It included 2 CI workflow files, no Dockerfile, and no tests directory. Our harness found no test script or target at that commit, so it skipped tests. A successful build is useful evidence, but it does not validate range integrity, resume behavior, or traffic distribution across real adapters.
The current README describes Playwright smoke, integrity, and chaos commands, while the current package metadata calls the software 1.0.0-rc.11. Those are project facts, not results from our measured commit. Anyone evaluating the latest branch should run the documented end-to-end suite on the operating systems and adapter combinations they plan to support.
Windows routing can miss the selected interface
Open issue 65 describes the most important current risk. A user tested Ethernet through one router and Wi-Fi through a mobile hotspot. Some traffic worked, but HTTPS connections on Wi-Fi failed while Ethernet was active because binding only the local source address did not always force Windows onto the intended route. The report proposes setting IP_UNICAST_IF with a helper and says that local modification worked.
That issue concerns Plexo's central promise, not a cosmetic corner. The interface list and colored progress grid can show the intended adapter, but the operating system decides the actual route unless the socket is pinned correctly. On Windows, verify public IP or route behavior per interface before assuming the chart represents independent networks. Linux has device pinning, while macOS relies on recognized network interfaces.
Source-only distribution adds platform chores
GitHub reports no published release, and the README tells users to build from source. Plexo targets Windows 10 or 11, macOS, and Linux. The packaging configuration produces Windows installers, macOS disk images, Linux AppImages, and Debian packages for supported architectures, but Windows and macOS local builds are unsigned. That matters on managed systems and for anyone redistributing binaries.
Android USB tethering on macOS needs a separate user-space RNDIS driver called TetherKit because macOS does not expose that phone connection natively. Windows may need the phone manufacturer's driver and can disable Wi-Fi when Ethernet connects unless a policy changes. These are operating-system constraints, yet they determine whether Plexo can see the second route at all.
October activity is fast, and still release-candidate activity
The repository was pushed on October 3, 2026. GitHub showed 1,380 stars and 14 combined open issues and pull requests. Recent work covers stream limits, network changes, direct-to-destination writes, IPv6, Windows packaging, and queue proposals. There is no GitHub release despite the rc.11 package version and release-related pull requests.
Plexo is worth an experiment for a narrow situation: one large ranged download, two metered or independent routes, and a user who can verify both. The 689 MB install and Electron surface are costly beside aria2. What you get in return is a clear per-network view and logic built around unequal links. Prove the route first; the colored squares come second.