Compared to the Hati-R 8K, the Hati-R Pro 8K tries to justify its "Pro" moniker mostly in two ways. First, instead of the 28 g of the Hati-R 8K, the Hati-R Pro 8K weighs 25 g. This has been achieved by using the same design principles, albeit with another layer of sophistication added. For instance, the plastic assembly holding the side-button PCB is now clipped to the shell instead of screwed, and where the Hati-R 8K was still using a bottom shell to which the PCB is screwed, the main PCB of the Hati-R Pro 8K is almost exclusively affixed to the top shell right away, and the only sort of "bottom shell" is a horizontal stab running across the sensor lens. Since the PCB once again has been extended in such a way that it supports structural integrity, the Hati-R Pro 8K still manages to be exceptionally sturdy. On my sample, there is no rattle when shaking, no creaking or flexing of the shell when applying lateral pressure, and the side buttons cannot be actuated by pressing below them regardless of force used.

The second way in which the Hati-R Pro 8K differs from the non-Pro is the shape. The main difference is the rear, which effectively has been chopped off. The only remnant is a flat extension whose only purpose consists in providing something to attach a pair of skates to. Front and grip width are unchanged, but the hump sits marginally lower on the Hati-R Pro 8K to accommodate the shorter length. As a result of these changes, the Hati-R Pro 8K essentially is limited to fingertip grip, whereas the Hati-R 8K allowed at least those with smaller hands to apply a more aggressive claw grip. On the other hand, the lower hump makes any palm interference less likely on the Hati-R Pro 8K. Overall, there is no good and bad here, but rather a shift in terms of preference.

As far as internals go, nothing has changed. The main button switches come from Huano and are of the blue transparent shell, pink plunger variety. Compared to the Hati-R 8K, these are implemented in a much nicer fashion on the Hati-R Pro 8K, however. Pre-travel is still moderate, but post-travel very low, and button response as a whole is firm and snappy. Some lateral movement can be provoked still, although it remains unnoticeable during actual use. The side buttons are outfitted with surface-mounted Omron switches, which of course limit how satisfying feedback can be. Still, pre- and post-travel are remarkably low, and having side buttons on a mouse this size is commendable to begin with. While the side buttons are still located effectively in the same spot, the fact that the Hati-R Pro 8K is shorter than the non-Pro renders their position more natural, in that they now sit right in the middle. For the scroll wheel, G-Wolves has opted for an encoder from TTC, more specifically of the blue/yellow core variety. Tactility is great on this, as each step is clearly defined, allowing for very controlled scrolling, and noise levels are surprisingly low. There is no doubt that this is also subject to variance, but based on my sample at least, the scroll wheel is plain excellent. Much like on previous G-Wolves releases, the bottom lacks indents for feet, allowing one to apply feet of non-default sizes and shapes, though given the limitation in available real estate, one is inevitably bound towards smaller skates. Aside from the dot feet installed by default, two sets of larger feet are included with the mouse, along with another set of dots. They're all made of pure PTFE, and glide very well.

Much like the Hati-R 8K, the Hati-R Pro 8K utilizes PixArt's PAW3395 sensor along with a Nordic nRF52840 MCU. Whereas the Hati-R 8K managed to display no CPI deviation whatsoever, the Hati-R Pro 8K doesn't fare as well in this regard. Since the firmware is identical, we can infer that this is entirely a function of sensor height, resulting in a positive deviation of 5%. While correcting this isn't difficult, it would of course preferable to not have it in the first place. General tracking shows no issues, irrespective of whether MotionSync is enabled or not. In terms of polling, all is well, as not a single poll is missed even at 8000 Hz, and all other rates are perfectly stable, too. Motion delay will differ depending on the firmware used. Firmware version 01.00.36 and later have been specifically optimized for battery life, which is why motion delay is slightly higher than on the older 00.00.17 firmware, as instead of the 1.0 ms lead the Hati-R 8K had on that firmware over the Logitech G403 (control subject) at 4000 Hz in wireless operation, the Hati-R Pro 8K on the more recent firmware is only ahead by 0.7 ms. Much like before, 8000 Hz posts worse numbers presumably due to a larger buffer for retries being used. Notably, the firmware versions behave differently in terms of motion delay over time, as on the older firmware, the Hati-R 8K was ahead of the G403 consistently throughout the entire motion, whereas on the newer firmware, the Hati-R Pro 8K is initially behind the G403, and only gets ahead after first the first few milliseconds of the motion. In practice, these differences are miniscule of course, and for those who value raw performance above all, using the 00.00.17 firmware version is always an option. For everyone else, the improved battery life afforded by the newer firmware will likely be appreciated, however.

In terms of click latency, differences exist between the 00.00.17 and 01.00.36 firmware versions on the one side and the 01.00.37 firmware version on the other. With the former, the Hati-R Pro 8K will average no more than 0.3 ms in wireless operation regardless of polling rate setting, provided debounce time is set to 0 ms. Setting debounce time to the lowest value has no immediate downsides as long as there is no double-clicking, as a slam-click prevention algorithm is present, adding additional debounce whenever the mouse has been lifted, such that no accidental button actuation occurs when resetting the mouse. However, this algorithm is flawed on the former group of firmware, in that the first click after lift-off will have the full ~16 ms added applied, even when the mouse has already been landed again. Firmware version 01.00.37 fixes that, but also increases click latency to 0.5 ms in the process. This is likely unintentional, but even if it weren't, marginally higher average latency is always better than inconsistency in my book, as is the case with some clicks having upwards of 16 ms of latency, just because the mouse has been lifted right before. Once again, the choice is ultimately given to the user here.

G-Wolves doesn't cite any battery life numbers, and even though the web driver includes a percentage-based (increments of 5%) battery life indicator, it proved unhelpful during the review, as it didn't budge one bit. Still, given the battery capacity of 250 mAh, it is reasonable to assume that the Hati-R Pro 8K sits somewhere in the 70–80 hours range at 1000 Hz, and accordingly less at higher polling rates. Charging isn't all that speedy on the Hati-R Pro 8K, but decent enough, though playing while charging won't be an option with the included cables anyway. The first one isn't all that flexible to begin with, but more importantly seriously short at 1.25 m, whereas the second one is a bit longer at 1.45 m yet even stiffer. As such, it is best to keep the Hati-R Pro 8K charged at all times to minimize forced downtime.

Much like on the Hati-R 8K, configuration on the Hati-R Pro 8K is done through a web driver. Due to using WebHID, this web driver will only work in Chromium-based browsers such as Chromium or Edge. Hence, for those not already using these browsers, being directed towards a web driver requires installing an additional browser, which of course comes with its own resource footprint, much like a regular peripheral software would. In addition, if G-Wolves were to go defunct, or decide to no longer host the web driver, configuration would become impossible, as a local copy unfortunately won't work. This is doubly problematic in that the Hati-R Pro 8K doesn't even have a CPI button, so even something basic as changing CPI requires a configuration driver. As such, I consider the web driver a step back compared to the previous standalone application featured on earlier G-Wolves mice, and would welcome G-Wolves also releasing a desktop version of their web driver in the future. As for the driver itself, I couldn't find any major bugs, and all the relevant options are present. The only minor issue is that setting changes can still be made after the mouse has entered sleep mode, yet won't be applied, which isn't communicated through the UI. An additional oddity is that any adjustment to the debounce settings will only take effect after the mouse has been lifted and reset once.

At $169.00, the Hati-R Pro 8K costs $20 more than the Hati-R 8K, without offering much in return. The changes to the shape are a matter of taste, and the 3 g weight reduction is small to where telling it in a blind test may prove difficult, though for fingertip grip in particular, lower weight is always better and appreciated during longer periods of use regardless. Improvements to the buttons are present but not all that noticeable, and everything else is the same between the two. Still, it would be incorrect to call the Hati-R Pro 8K a lackluster release, as on its own, it is a perfectly fine mouse, though given the choice, I'd always opt for the Hati-R 8K for its lower price alone. As an alternative for those who enjoyed the Hati-R 8K but disliked its length, the Hati-R Pro 8K still serves a purpose, however, and clutches our Recommended award, along with our somewhat elusive But Expensive badge.