For low-bit BTC puzzles, I use my own experimental, slower version that I wrote in C++ loosely based on Bitcrack, but with heavily optimized CUDA kernels where its sequential scanhashing is from 80% up to 120% faster, depending on the Nvidia GPU model and architecture, than the original Bitcrack.

My Nvidia GPUs go like this with it, depending on card OC, at 100% power limit up to:
GTX 1080 Ti, 950 Mkey/s
RTX 2080 Ti, 1800 Mkey/s
RTX 3090, 3700 Mkey/s
RTX 4090, 6800 Mkey/s

In addition to significant optimization speed-up per GPU, my version has also modified scanhash search logic to be able to run in "skipping approach" and "forced pattern(s)" mode, where the search is sequential but only on given data candidates. In this mode it doesn’t go one-by-one, one key after another with 1 stride, but instead keys are preselected in real-time over and over again on the fly during running, eliminating certain patterns from hexadecimal "strings" being based on tune-able parameters.

I realize the fact that BTC puzzle keys were generated using a Deterministic wallet randomly, meaning there is no real pattern behind them to search for; however, the purpose of my version of Bitcrack is something else. It is to eliminate very unlike private keys, not compute something that is very unlike. Such as in a 17-character hexadecimal long key range, the ending of the BTC puzzle key #67, which is randomly generated, it is so unlikely that it will contain only "letters" (0x6AFDCBEDCABEFDA) or only "numbers" (0x40124579147074121) that you can put your hand in the fire for the fact.

This is what my own version of Bitcrack can do on my GPUs. It can be ordered by various parameters prior start to skip, or oppose forcibly require, or both at once unlimited times by parameters, puzzle keys that meet fine-tunable criteria, for example to skip numbers only ('0..9') or letters only ('a..f'), skip hexadecimal "string" candidates that go one after another, exact "strings" 0xFF, 0xAAA, 0xCCCC, or exactly unknown "strings" letter-number-letter, or letter-letter-number-number, whatever of this letter-number sort, anywhere in hexadecimal representation of key at any position and any offset, even on multiple locations or unknown locations and offsets, or reverse it can be ordered and forced to do only wanted "strings", various thresholds, equal, less, higher, non-equal to whatever parameter set and much more.

I already described it in my previous post some time ago:
https://bitcointalk.org/index.php?topic=1306983.msg62088633#msg62088633

As I said, I fully realize puzzle keys are in fact random, but to do it this way is still much more fun than by simple one-by-one, 1 stride scanhashing.

I use even more approaches than these, in my experimental solver I simply try algorithmically manipulate chances, moving chances of finding a solution to my side, and skipping non-interesting candidates that are very unlikely without any hashing to balance the risk of skipping the right solution and to balance out this way a low count of GPUs I have. As ruling out key candidates like this results in hardware computational speed-ups that are tens, hundreds, or even thousands multiples of the original speed of the device when searching whole/given range, but naturally depending on parameters greatly increase the risk of skipping the right solution.

Anyway, if I solve some low-bit BTC puzzle with my version and finally the price will arrive to my BTC wallet without being robbed during cashing-out by a bot run by a thief, I will publish my version of Bitcrack, including source code, so anyone can have fun with it then.