Path discovery and profiling
Detects eligible Linux network interfaces and measures throughput, latency, jitter, loss, stability, and metered status for each path.
Linux prototype · Product in development
PROJECT SOURCE · PROTOTYPE
GetFast
At a glance
What it is
A Linux-first desktop utility that splits eligible ranged HTTP(S) downloads across multiple independent network paths while preserving explicit safety controls and rollback.
Capabilities
What it does today
Implemented capabilities from the project-owned source.
Segmented multi-path downloads
Splits range-capable HTTP(S) files into verified chunks, weights work by measured throughput, retries failed chunks, resumes partial work, and reports per-interface contribution.
Desktop control surface
Provides a Tauri and Svelte desktop interface for connection status, path tests, managed downloads, routing modes, diagnostics, and safety controls.
Safety and recovery
Uses scoped route ownership, pause and safe modes, clean rollback, crash recovery, diagnostics, and private debug exports without flushing the main route table.
Metered-path consent
Excludes mobile and metered paths by default and requires explicit permission before they contribute to a managed download.
In detail
Detailed project context
GetFast is a local-first Linux network utility for eligible large downloads. It measures each usable connection, then lets its managed downloader divide a range-capable file across independent paths such as Ethernet and Wi-Fi.
What is implemented
The repository contains a Rust daemon and command-line tools, a Tauri and Svelte desktop application, path measurement, traffic classification, a segmented downloader, per-path contribution reporting, metered-connection controls, diagnostics, and recovery behavior.
The managed downloader requires an HTTP(S) server that supports byte ranges. It verifies chunk sizes, reassigns failed work, resumes retained parts, assembles the result in order, and can verify a supplied SHA-256 digest. Unsupported transfers fail closed instead of being intercepted or silently routed through a different mechanism.
Current evidence
Two-path hardware validation was completed on July 25, 2026 using independent Ethernet and USB Wi-Fi uplinks. Across three interleaved 100 MB rounds, the documented medians were 125 Mbps over Ethernet, 189 Mbps over Wi-Fi, and 271 Mbps with both paths. The combined result was 1.43 times the fastest single path and the completed file matched a direct-download SHA-256 digest.
That result is evidence for the tested Linux rig and ranged download, not a universal speed promise. Performance depends on independent upstream paths, the remote server, current path quality, routing, and whether a transfer can be segmented.
Safety boundary
GetFast does not flush or replace the main route table. Its privileged helper is limited to a reserved rule and table range, while the daemon itself remains unprivileged. Pause, safe mode, cancellation, shutdown, watchdog handling, and crash recovery are designed to remove GetFast-owned routing and return to a captured stable state.
Hardware testing also covered cancellation and an uncontrolled daemon kill during a transfer. The documented recovery kept normal default routes intact, cleared GetFast-owned rules, forced safe mode after restart, and retained partial download data for an explicit resume.
Limits and access
GetFast remains a prototype rather than a public release. The current implementation is Linux-first, the repository is private, and there is no supported public download. Windows support remains planned.
Direct ranged HTTP(S) files are the supported managed-download workflow. Servers without byte-range support return a clean unsupported error. Arbitrary application traffic, DRM media, and universal connection bonding are not supported. Browser handoff and Steam integration remain bounded compatibility work rather than a promise that every application download can be accelerated.
Build log
Updates
Open an entry for the complete note.
milestone · Cancellation and crash recovery checked on hardware
Recovery result
Cancellation settled cleanly, kept partial chunks, and produced no incomplete output file. Repeating the same download resumed retained work.
After a forced daemon kill and restart, GetFast reported crash recovery, entered safe mode, and cleared its owned routing state while both normal default routes remained intact. Remaining watchdog, shutdown, three-path, and physical path-loss checks stay in the roadmap.
progress · Slow probe hosts no longer disable healthy paths
What changed
Hardware validation exposed a case where a congested measurement server made healthy interfaces appear unusable. GetFast now retries the throughput probe once and uses the independent latency and loss result to keep a healthy path eligible at a conservative rating.
A path whose latency test also fails remains excluded.
milestone · Two-path hardware aggregation confirmed
Test boundary
The result came from three interleaved 100 MB rounds on one Linux rig with independent Ethernet and USB Wi-Fi egress paths.
- Ethernet median: 125 Mbps
- USB Wi-Fi median: 189 Mbps
- Combined median: 271 Mbps
- Combined result: 1.43x the fastest single path
The file matched the direct-download SHA-256 digest. This is evidence for that hardware and server, not a guarantee for every connection or download.
Next sequence
Roadmap workflow
Select a node to inspect the plan without crowding the workflow.