Skip to content
← All posts
4 min read

How to choose a Minecraft anticheat: the questions that actually matter

Detection-count marketing tells you nothing. A checklist for evaluating any Minecraft anticheat: packet-level vs event-level, mitigation design, reversibility, platform support and what happens when the vendor's servers go down.

buying guideserver operations

Anticheat marketing has converged on the same three claims: a big number of checks, the phrase "packet-level", and a promise of no false positives. All three are close to meaningless as written. This is a list of questions that produce useful answers instead, whichever anticheat you end up choosing.

Is it actually packet-level, and does it matter here?

"Packet-level" means the anticheat reads the raw protocol stream rather than only Bukkit events. It matters, but not for the reason it is usually sold.

Bukkit events are lossy. PlayerMoveEvent does not fire for a rotation-only change, so an event-level anticheat cannot see the rotation pattern that gives away most aim assistance. Attack events give you "player hit entity", not the exact positions and look angles at the moment of the hit, so reach measurement becomes an approximation. Working from packets means the check sees what the client actually sent.

The question to ask: which specific checks read packets, and which read events? Plenty of anticheats do combat at packet level and everything else at event level, and describe the whole product as packet-level.

What happens on an uncertain detection?

This is the single most informative question you can ask, and the answer separates serious products from the rest.

A ban-first anticheat converts every uncertain case into a decision it might have to apologise for. A mitigation-first anticheat converts it into a setback, a cancelled hit, or a nerf. The cheat stops working, the honest player sees a moment of rubber-banding, and the violation counter keeps accumulating until the case is not uncertain any more.

The question to ask: can I configure the response per check, and what is the default? If mitigation is all-or-nothing, or if it only exists as "ban after N violations", you will be tuning with a blunt instrument.

Can the cheat authors read it?

This one is rarely discussed and it decides how long any detection stays effective. If the anticheat ships as an ordinary jar, a cheat developer runs a decompiler, reads the thresholds, and tunes their client to sit underneath them. Everything it detects, they can see it detecting.

What you want to know is simply whether the detection logic is readable once the file is on disk. A vendor that has thought about this will tell you that it is not. A vendor that has not will hand you a jar you can open in a decompiler and read end to end.

The question to ask: is your detection logic readable in a decompiler? You are entitled to a yes or no. You are not entitled to the details, and a vendor who publishes them is helping the wrong people.

What is the false-positive process, not the false-positive promise?

Nobody can promise zero false positives (we wrote about why they happen). What a vendor can tell you is their process:

  • Do new checks ship enabled, or alert-only?
  • Are false-positive-prone checks off by default?
  • Can you run the whole thing in alert-only for a week before it punishes anyone?
  • When a check is wrong, is the fix a config value you control, or a vendor update you wait for?

The question to ask: what did you turn off by default, and why? A vendor with a good answer has been burned before and learned. A vendor who says nothing is off by default has not been running long enough.

Which platforms and versions, honestly?

Version support is usually stated as a range like "1.8 – 1.21+". What that range hides:

  • Folia is the real differentiator right now. Folia's threading model forbids reading world state off the owning region thread, which is exactly what movement and combat checks do. Most anticheats respond by disabling those checks on Folia, sometimes silently. Ask directly whether movement, scaffold and reach checks run on Folia, or only the packet-timing ones.
  • Geyser/Bedrock players have a different movement model. Running Java-tuned checks on them produces constant false positives. The correct behaviour is to skip them entirely, not to raise thresholds. Ask which one it does.
  • Proxy setups (Velocity, BungeeCord) change how player identity and IP arrive. Ask whether it needs a separate proxy plugin.

What happens when the vendor's infrastructure goes down?

Any anticheat with cloud features (licensing, offloaded analysis, cross-server tracking) has made your server's protection depend on somebody else's uptime. That is a reasonable trade for what the cloud buys, but you should know the failure mode.

The questions to ask: Does the plugin fail open or closed if licensing is unreachable? Is there more than one endpoint? Does the client fail over automatically, or do I edit a config and restart during an outage? A single hardcoded endpoint is a single point of failure between you and your players.

What you are actually buying

Strip out the marketing and a paid anticheat is three things: detection quality, which you can only judge on your own server; the vendor's judgment, visible in what they turned off by default and how they ship new checks; and maintenance, because Minecraft updates and cheat clients do not stop.

The check count on the pricing page is not on that list. Run any candidate in alert-only on your own traffic for a week before you pay for a year, including ours.