FluxDown: A Rust-Based Download Manager That Doubles as an AI Agent Endpoint
FluxDown is a media downloading and processing utility with resumable transfers, queue management, and local automation controls.
At a glance
- What is it?
- FluxDown is an open-source, multi-protocol download manager with a Rust engine, a Flutter UI, and a built-in MCP server. It targets users who want IDM-style segmentation without Windows lock-in, plus AI agents that need programmatic download control.
- Who is it for?
- Adopt FluxDown if you need a cross-platform, local-first download manager that handles BitTorrent and eD2K alongside HTTP, and if you want AI agents to control downloads through a standard MCP endpoint. Avoid it if you require a stable 1.0 release, if you cannot accept the AGPL-3.0 license for your use case, or if you need a tool with a mature ecosystem and long-term support guarantees.
- Can I use it commercially?
- Yes, with strict conditions. AGPL-3.0 is a network copyleft licence: if people use a modified version over a network, for example as a hosted service, you must offer them its source code under the same licence.
- Is it still maintained?
- Yes. The repository last received commits 6 days ago.
- What is it written in?
- Mainly Rust, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 14, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
What FluxDown Actually Solves
FluxDown is a download manager for people who are tired of IDM's Windows-only, paid, closed-source model. It solves the problem of managing large or numerous downloads across multiple protocols from a single interface, with the ability to pause, resume, and queue tasks. The target user is someone who downloads files from HTTP, FTP, BitTorrent magnets, eD2K links, or streaming formats like HLS and DASH, and who wants that capability on Windows, macOS, Linux, Android, or a NAS. The README explicitly positions it as a free and open-source IDM alternative, but it goes further by adding BitTorrent and eD2K, which IDM lacks. It also targets AI-agent users: the built-in MCP server lets Claude, Cursor, or other clients add, pause, and monitor downloads programmatically. That is an unusual feature for a download manager, and it suggests the project is aimed at developers and power users who automate their workflows, not just casual downloaders.
Architecture: Rust Engine, Flutter UI, and a Hub in Between
The architecture is split into three layers. Flutter renders the UI, a Rust engine does the downloading, and a component called the hub acts as an FFI adapter between them. The two sides communicate through Rinf signals, which is a Rust-Flutter bridge that avoids the overhead of traditional FFI calls. The browser extension, built with WXT, connects via Native Messaging to a separate process called fluxdown_nmh, which then talks to the hub over a named pipe or Unix socket. This design keeps the downloading logic in Rust, where memory safety and concurrency are easier to manage, while the UI stays in Flutter for cross-platform rendering. The README claims a zero-FFI Rust engine, which means the Rust code does not make direct foreign function calls into other languages; instead, it uses Rinf's signal-based messaging. That is a clean separation, but it also means every UI update and command has to cross a message boundary, which could add latency. For a download manager, that is probably acceptable, but it is worth noting if you expect real-time segment visualization without any delay.
Getting It Running: Installers, Docker, and the MCP Endpoint
Installation is straightforward if you use the prebuilt packages. Windows gets a setup.exe or a portable zip, macOS gets a dmg or tar.gz, Linux gets an AppImage, deb, or Arch package, and Android has per-ABI APKs. For headless NAS or server use, there is a Docker image at ghcr.io/zerx-lab/fluxdown-server, plus Synology, QNAP, OpenWrt, Unraid, and CasaOS packages. The browser extension is available for Chrome, Edge, and Firefox, and it is supposed to take over downloads automatically. To enable the MCP server, you go to Settings, then API Service, and toggle the MCP endpoint. A token is generated automatically, and the headless server enables it by default. The endpoint is http://127.0.0.1:17800/mcp, and you authenticate with a Bearer token in the Authorization header or an X-FluxDown-Token header. The README gives a JSON configuration for MCP clients, which is a standard mcpServers block. That is all you need to get an AI agent talking to the download manager. One caveat: the README says the endpoint is local-only by default, but it does not explain how to change that if you want remote access. You would have to dig into the server configuration yourself.
The MCP Server: A Genuine Differentiator with Limits
The MCP server is the most distinctive feature. It exposes 12 tools over Streamable HTTP, which is a JSON-RPC 2.0 protocol on a single POST /mcp endpoint. The tools cover the basics: add, list, get, pause, resume, remove, and pause or resume all downloads. There are also tools for managing named queues and RSS subscriptions. The RSS tools are notable because they let an AI agent subscribe to a feed and poll it on a schedule, which turns the download manager into a kind of automated ingestion system. The MCP layer sits on top of the same ApiHost trait that powers the REST API and an aria2-compatible JSON-RPC interface, according to the README. That means the MCP server is not a separate hack; it is a first-class API surface. However, the README does not document the exact JSON-RPC methods or the REST endpoints, so you have to trust that the tool names match what an MCP client expects. Also, the token is shared with the management API, which is convenient but means anyone with the token can control everything. The local-only default is good for security, but it limits remote AI agents to the same machine unless you reconfigure.
Protocol Coverage and the Segmentation Engine
FluxDown supports HTTP/HTTPS, FTP, BitTorrent (with DHT, UPnP, and magnet links), eD2K (with Kad DHT source finding and MD4 verification), HLS with AES decryption, and DASH. That is a wide range, and it puts it ahead of most download managers, which typically stop at HTTP and FTP. The segmentation engine is described as IDM-style dynamic segmentation: segments split at runtime, and idle threads can rescue slow segments. The README claims up to 10x faster downloads, but that is a marketing number with no benchmark methodology attached. You should treat it as a claim, not a verified result. The resume feature stores every byte's state in SQLite with WAL mode, which is a solid design for crash recovery. The rate limiting uses a token bucket, which is a standard algorithm for controlling bandwidth. The engine is written in Rust and Tokio, which gives it memory-safe concurrency, but the README does not provide any performance data beyond the 10x claim. You will have to test it yourself to see if the dynamic segmentation actually improves throughput on your network.
Browser Integration: Three Layers of Interception
The browser extension is a core part of the workflow. It uses a three-layer download interception engine, which likely means it hooks into browser download events at multiple levels to catch direct downloads, streaming media, and maybe right-click actions. The README mentions streaming media sniffing, Alt+Click bypass, and right-click send. The Alt+Click bypass is a useful feature: it lets you force the browser's default download behavior instead of sending the file to FluxDown. The extension connects to the native host via Native Messaging, which is a standard mechanism for Chrome and Firefox extensions to talk to local processes. The native host is fluxdown_nmh, which then communicates with the hub over a named pipe or Unix socket. This setup is more complex than a simple local HTTP server, but it avoids exposing a network port for the browser connection. The README does not specify which browsers are supported beyond Chrome, Edge, and Firefox, and it does not mention Safari. If you are on Safari, you are out of luck. Also, the three-layer interception might cause false positives, where the extension grabs downloads you did not intend to route through FluxDown. The Alt+Click bypass helps, but you will need to configure the extension's behavior to match your preferences.
Licensing and Maintenance Reality
FluxDown is licensed under AGPL-3.0. That is a strong copyleft license, and it has implications if you plan to use the server component in a commercial setting. AGPL requires you to offer the source code to users who interact with the software over a network. For a download manager that runs locally, that may not be a practical concern, but if you deploy the headless server on a NAS and expose it to other users, you could be required to provide source code. The README does not discuss this, so you should consult a lawyer if that matters to you. The maintenance situation is active: the last push was in August 2026, and there are recent release candidates for the main app, the server, and the mobile app. The project is not archived, and it appears in several awesome lists, which suggests community interest. However, the version numbers are all release candidates (v0.4.8-rc.5), which means the project is still pre-1.0. That is a warning sign for production use: APIs can change, and features may be unstable. The README does not provide a changelog or migration guide, so upgrading between release candidates could break your configuration. You should check the changelog on the website before each update.
Alternatives and the Right Tool for the Job
The most direct alternative is aria2, which is a command-line download utility that also supports HTTP, FTP, BitTorrent, and Metalink. aria2 has been around for over a decade, is written in C++, and is stable. It does not have a built-in GUI or a browser extension, but it has a JSON-RPC interface that is widely used. FluxDown explicitly mentions an aria2-compatible JSON-RPC, which means you could potentially migrate from aria2 to FluxDown without rewriting your automation scripts. That is a smart compatibility move. The difference is that aria2 is a headless daemon; you bring your own frontend. FluxDown gives you a polished Flutter UI and an MCP server out of the box. Another alternative is JDownloader, which is Java-based and has a huge plugin ecosystem for hoster sites, but it is heavier and has a different focus. For AI-agent integration, FluxDown's MCP server is a unique advantage; neither aria2 nor JDownloader has that natively. However, if you only need HTTP downloads and you are comfortable with a terminal, aria2 is lighter and more battle-tested. FluxDown is the better choice if you want a modern UI, multi-protocol support, and the ability to let an AI agent manage downloads without writing custom glue code.
Editorial conclusion
Adopt FluxDown if you need a cross-platform, local-first download manager that handles BitTorrent and eD2K alongside HTTP, and if you want AI agents to control downloads through a standard MCP endpoint. Avoid it if you require a stable 1.0 release, if you cannot accept the AGPL-3.0 license for your use case, or if you need a tool with a mature ecosystem and long-term support guarantees. Before deploying, verify the current release candidate's stability, test the MCP token authentication on your network, and confirm that the browser extension's three-layer interception works with your specific browser version. The project's frequent release candidates suggest active development, but also that the software is not yet production-hardened.
Community notes