-S, or --slow-candidates, builds each complete password candidate on the host and sends it to the device, instead of sending a small base and expanding it on the device.

That sounds like a step backwards, and for a fast hash it is. It earns its place where the device is not the bottleneck:

• slow hashes, where the card spends a long time on each candidate anyway
• fast hashes with many salts, for the same reason
• a small wordlist expanded by a large ruleset, where the device-side expansion has little base material to work from

In that last case the fully expanded candidates give hashcat enough independent work to keep every device busy, which a one-word wordlist cannot do on its own.

It works in attack modes 0, 1, 3, 4, 5, 6, 7, 8 and 12, and forces the backend vector width to 1. It cannot be combined with --stdout, with benchmark mode, or with candidates arriving on stdin.

In the PCFG attack it also selects the host generator in place of the device-side one.

A brain client switches it on by itself when candidate checking is enabled, which is the default. Feature 2 asks for keyspace coordination alone and leaves generation on the device.

The old way was to pipe one hashcat's --stdout into another. That costs you an exact ETA and straightforward keyspace distribution, and it complicates running under an overlay such as Hashtopolis. -S keeps the generator inside the same session.

• docs/slow-candidates-mode.md