Autoclicker and aim detection: why a CPS limit catches almost nobody

Ask a server owner how their anticheat handles autoclickers and you will usually hear a number. Sixteen clicks per second, maybe twenty. Anything above it gets flagged.

That number is doing almost no work. It punishes a handful of legitimate players and stops nobody who is paying attention, for the same structural reason a scaffold rate limit fails: it publishes its own threshold, and the tool on the other side has a slider.

Speed is the weakest signal available

Set an autoclicker to fourteen clicks per second and a CPS cap will never see it. Fourteen is plenty. The advantage in a fight comes from consistency far more than from raw rate, so the cheater gives up nothing by staying under your limit.

Meanwhile butterfly and drag clicking put real humans well into the twenties on their good days. Those are the players who care most about your server's PvP, and a cap is the check most likely to punish them for being good at it.

So the cap costs you players you want and stops nobody you do not. It survives because it is trivial to implement and produces a satisfying number for a config file.

What a human hand actually does

The signal is in the distribution, not the mean.

A person clicking fast produces intervals that scatter. They drift over the course of a fight as the hand tires. They stutter when attention shifts. Butterfly clicking alternates two fingers and leaves a visible alternating pattern in the gaps. Drag clicking produces bursts with ragged edges. All of these are messy in ways that are consistent with a body doing the work.

A macro produces intervals drawn from a much narrower distribution. Even one deliberately randomised gives itself away, because the randomisation is usually uniform and human timing is not. Fatigue does not appear. The alternating structure of a real two-finger technique is absent, or present in a form too regular to be muscles.

What a check should be measuring, then, is the shape of the interval distribution over a window: how wide it is, whether the outliers look like a hand or like a random number generator, and whether it changes over the length of a fight the way a person's would.

None of that requires a threshold on speed. It works just as well against a macro running at eight clicks per second, which is exactly the case a cap cannot touch.

Aim has the same structure

Rotation follows the same logic and is often easier to read.

A human tracking a moving target overshoots and corrects. The correction is visible as a small reversal after the initial movement. Acceleration ramps up and eases off rather than switching on and off. Between engagements the crosshair drifts, because holding a mouse perfectly still is something people cannot do.

Assisted aim tends to arrive rather than travel. The rotation lands on target in one movement, with no overshoot to clean up, and the transition between "not aiming at them" and "aiming at them" is sharper than a wrist produces. Snap behaviour between multiple targets is the strongest version of this: the gap between finishing with one target and being precisely on the next is shorter than a person can physically produce.

The nuance is that assistance sits on a spectrum. Full snapping is obvious. Gentle smoothing that nudges an already-decent aim is genuinely hard, and any vendor claiming to catch all of it reliably is overselling. This is a place where honest coverage beats a confident claim.

Where this goes wrong

Two traps are worth knowing about before you turn anything up.

Input hardware varies more than you would expect. Mice with adjustable polling rates, controller input through a translation layer, and various accessibility setups all produce rotation traces that are smoother than a bare mouse. Smooth is not the same as automated, and a check that treats it that way will flag players who are doing nothing wrong.

Server conditions leak into the data. Packet timing measured on a server that is behind on ticks tells you about the server, not the player. Click and rotation analysis has to work from when actions were performed, not when they were processed, or your first lag spike becomes a wave of alerts.

Both of these are reasons to run this family of checks alert-only for a while, watch what your own population looks like, and only then decide what to act on.

How Sheriffguard approaches it

ClickSpeedLimiter and ClickPatterns split the two questions rather than collapsing them into one number: the first covers the crude high-rate case, the second looks at the shape of the intervals, which is where a tuned macro actually shows up. AimAssist and the broader Heuristics checks cover rotation, including the snap-between-targets case.

Alongside those, a trust model scores each player continuously and flags where its judgement and the heuristics disagree. That disagreement is the useful part. A player the heuristics dislike but the model trusts is usually just good, and that is precisely the case you want a human to look at rather than a threshold.