Thank you, this is exactly the kind of cross-platform, real-line data the page needs, and a Windows + cable + Western Europe sample is a different point in the space from the dev host. I pulled your three runs into two charts first, both carrying the same line-limited caveat your data deserves (you are on cable, not fiber, so these are not provider rankings).

Your results as a pass / fail map across the three payload sizes, with the down / up speed inside every cell that completed:

And the throughput on your line at 10 MiB, for the providers that completed it:

Now the point by point.

On benchmarking API/OAuth drives from the GUI. You read it right: the GUI Speed Test deliberately runs at the raw-protocol layer and only accepts ftp / ftps / sftp / s3 / webdav. That is why it can compare your WebDAV and S3 profiles but not the API/OAuth-native drives (native MEGA, Google Drive, Dropbox, OneDrive, native pCloud/Filen, etc.). The full provider path, including every API/OAuth backend, is what aeroftp-cli benchmark exercises, because it goes through the same provider DAG the app uses for real transfers. So yes: please do repeat this on the CLI, it will cover the providers the GUI cannot. Surfacing API/OAuth coverage in the GUI (Speed Test or Debug Panel) is a fair ask and I will track it as a separate enhancement.

Filen S3 cross-confirmation. Your 100 MB Filen S3 failure (local.s3.filen.io:1800 unreachable) reproduced on my side in the 2026-06-07 CLI round (127.0.0.1:1800 not reachable). Same root cause on both OSes: the local Filen S3 bridge was not up. I then started Filen Desktop with Network Drive > S3 enabled and re-ran the full 1M/10M/100M matrix with --pre-delete: it passes clean, 15/15 runs, zero errors, including the 100 MB upload and download. So this one is confirmed not a transfer regression: it only needs Filen Desktop running. Worth noting in the docs that the Filen S3 preset is useless without Filen Desktop live, which is easy to forget.

Koofr WebDAV. Consistent 404 Not Found on upload across all three sizes in your run. That looks like a real path/target bug on the Koofr WebDAV writer, not a size limit. Tracking it for v4.0.5; if you can share the Koofr profile shape (root path vs sub-path) it will speed up the repro.

Yandex Disk WebDAV. Two distinct symptoms in your data: connection failures to webdav.yandex.ru at 10/100 MB, and an upload throughput that collapses to ~0.13 Mbps at 1 MB while download stays normal. That points at the WebDAV upload path specifically. Also tracking for v4.0.5.

OpenDrive. The 100 MB failure matches the documented free-tier limit, so that one is provider-side, not ours. The flat ~1.6 Mbps at 10/1 MB looks like OpenDrive throttling rather than a client cap. Good call on documenting per-provider max sizes: I will add a max-file-size column to the Chunking notes referenced in #272.

Used-storage scan failed: List recursive failed (400 Bad Request). Thanks for isolating this in the Activity Log. That is the quota/used-storage scan, separate from the transfer path, and 400 on a recursive LIST points at a provider that rejects the recursive form we send. Tracking it for v4.0.5.

Speed Test window cannot reach Export / Run again. Confirmed, this is the same layout problem as #133: the dialog overflows the viewport and the footer buttons fall off the bottom. The scrollbar is a workaround, not a fix. I will treat the footer reachability as a blocker for the Speed Test dialog.

On repeating elsewhere and opening a dedicated report. Yes please, a CLI round from your line would be very welcome, and a dedicated Community Benchmark Report is the right home for the raw JSON. We can keep the discussion here and link it. Expect the WebDAV-on-Koofr/Yandex rough edges above until the v4.0.5 fixes land; your data is what lets us tell a real gap from a ghost one.

I'm nearly certain that I had Filen Desktop up and running the local S3 server.
I think it's more likely that there was some problem with 100MB because it was too much for it, than me forgetting.

For Koofr, I use(d) a / Remote Path and an empty Local Path.

Good question, and worth clearing up: that comparison table was a summary I typed by hand for this thread, not raw tool output. I ran the benchmark separately on each profile and kept only the files/s column, so the "higher = better" header and the "S3 -" labels were my own formatting.

Your note was the nudge to fix this in the tool itself rather than by hand, so two things changed on main for the next release.

First, the single-run report is now rendered as proper tables, split into a single-file section and a many-small-files section, each headed "higher is better":

Single-file throughput (Mbps p50/p95, higher is better)
  operation    size  runs      p50      p95           Mbps
  ────────────────────────────────────────────────────────
  upload     1.0 MB     1  172.5ms  172.5ms  48.63 / 48.63
  download   1.0 MB     1  113.9ms  113.9ms  73.63 / 73.63
  list            -     1   50.8ms   50.8ms              -

Many small files (files/s, higher is better)
  operation       size  runs      p50      p95  files/s         Mbps
  ──────────────────────────────────────────────────────────────────
  upload-all    8.0 KB    10  232.2ms  811.1ms      3.0  0.29 / 0.69
  list-dir           -     1   50.8ms   50.8ms    197.0            -
  stat-all           -    10   49.3ms   55.8ms     19.8            -

Second, the cross-provider comparison you saw is now a real CLI feature instead of something I assemble by hand. aeroftp-cli benchmark --compare "S3 Backblaze,S3 Storj" runs the same workload on each profile and prints the comparison automatically. Here is a genuine run:

Comparison: many small files (files/s, higher is better)
  profile        upload-all  list-dir  stat-all  download-all  delete-all
  ───────────────────────────────────────────────────────────────────────
  S3 Blackblaze         4.4     143.4      21.5          17.7        21.1
  S3 Storj              3.5     136.8      23.7           7.3        17.8

There is also a benchmark -i interactive picker to choose which saved profiles to compare from a checklist. So the per-file-overhead signal you predicted is now something anyone can reproduce in one command, with the tool writing the table rather than me.

A quick preview of the interactive side before 4.0.6 ships, in case you spot anything worth changing.

aeroftp-cli benchmark -i opens a checklist of the saved profiles. Space toggles a profile, Up/Down and PgUp/PgDn move, Home/End jump, a/n select all or none, Enter runs the comparison on the checked ones. It scrolls within the terminal so a long server list stays on one clean screen, with an "x-y of N" position and a selected count at the bottom.

After you pick, it runs the same workload on each profile and prints the per-profile reports followed by the comparison tables, here on three profiles at once:

If anything about the layout, the keybindings or the columns feels off, this is the moment to say so before it goes out.

1. If it's a TUI, it should consistently raise the -tui flag instead of -i like we want with aero profiles -tui. I suggest keeping a -i option as well, but it should act like it, so the usual typing of profile names and/or index numbers with a space separating them.

2. I have also been thinking about reserving some letters for aero profiles -i/aero profiles -tui such as Benchmark(B)|Mount(M). So that can be another way to trigger these.

3. Also, I don't understand how you select and deselect specific profiles. Left and right keys?
   I'd like to have some key that toggles, and other keys that are always just set a profile as ticked or unticked.
   Maybe Space to toggle, Backspace or Delete to untick, Insert or V to tick, etc.

4. Maybe also make use of the Tab and Shift+Tab keys for navigation.

🟢 All four picker points are in on main for 4.0.6.

The full-screen checklist is now under --tui (consistent with the planned aero profiles --tui), so aeroftp benchmark --tui opens it. Note clap shorts are single character, so the flag is the long --tui (a -tui short is not valid).

-i is kept but now acts inline exactly like you described: it prints a numbered list of saved profiles, then you type the profiles to compare as names and/or index numbers separated by spaces. Multi-word profile names are best selected by their index number, since spaces separate the tokens.

Tick and untick now have dedicated keys in the full-screen picker, as you suggested: Space toggles, v or Insert always tick, Delete or Backspace always untick. The footer spells it out: [Space] toggle [v/Ins] tick [Del/Bksp] untick [Tab] move [a] all [n] none [Enter] run [q] cancel.

Tab and Shift+Tab now navigate the list: Tab moves down, Shift+Tab moves up (arrows and PgUp/PgDn still work too).

On reserving action letters like Benchmark(B) and Mount(M) inside aero profiles -i/--tui: good idea, noted separately for the profiles menu. That surface is its own interactive shell, so I am tracking it there rather than bundling it into this benchmark pass.

Commit: 6dbb0ee04 (#277).

I forgot to add: I prefer ✓ over x. I don't know if it's too much to ask to switch to ✓ or somehow have that as an option.

Note clap shorts are single character, so the flag is the long --tui (a -tui short is not valid).

I did wonder why -P in rclone sync only has one dash... Thanks for letting me know.

I fixed this in v4.1.0. The "Pick profiles to compare" title no longer flickers: the picker used to clear the whole screen on every frame and repaint it, so each up/down keypress blanked the view and the title appeared to shake. I changed it to repaint in place (it overwrites each line and clears only the rows that actually change), so the title stays put and the list scrolls smoothly. The checkmark over the x for a selected profile I shipped earlier as you suggested.

I tried this in v4.1.0 and can confirm that it still flickers when the [Space] toggle to [q] cancel row wraps to a second line, namely in split-screen. You only removed the flickering when there's no wrapping, namely in fullscreen. Please try to drag the right or left edges of a terminal window horizontally, and you'll see what I mean when pressing Up and Down in aero benchmark --tui.

Fixed for v4.1.1: the picker now disables terminal line-wrap, so the footer help row can no longer wrap onto a second line and scroll the view in split-screen. Thanks for pinning it to the wrapping case.

Done for v4.1.1. aero benchmark --all is the opt-in you described: it benchmarks every saved profile, so you never have to list them with --compare or tick them in the -i/--tui picker. Profiles that fail to connect are reported as skipped, not fatal. You can also combine it with --group to run all members of a group. Thanks.

Maybe --all-protocols? To make it clear.

Imagine if there's a group of profiles that you like to frequently benchmark with each other, but don't want to constantly have to select them manually each time. You should be able to create a group for them and just use a --group flag.
You can even stack multiple such flags, which will be additive and exclude all the other profiles of a user.
Or maybe a single --groups flag that will separate these with a comma? At any rate, the menu that shows up to select profiles from will only show members of these groups. Then the user can just press a, maybe untick some with a spacebar press, and then press Enter. It should also be possible to work exactly like this on the GUI, with selecting groups to benchmark.

Done for v4.1.1. aero benchmark now takes --group <NAME>, repeatable and comma-aware (--group A --group B or --group A,B): it benchmarks the members of those My Servers groups, and with -i/--tui the picker is restricted to just those members. Membership is the same group blob the GUI uses. Your follow-up is exactly the flow this enables: make a group of the profiles you like to benchmark together, then run --group <that group> without re-selecting each time. The Benchmark(B) menu entry inside aero groups/aero users and the GUI group-select are the natural next step, noted for a follow-up. Thanks for the idea.