It scores contradictions instead of naming a bot
Anti-Mage returns a 0 to 100 score in steps of 10 after asking whether a browser's own claims agree. A screen size can be checked against its viewport, a reported browser version against supported capabilities, and graphics or decoder readings against the device being claimed. Five determinations cover coherent, discrepant, instrumented, insufficient, and not evaluated results. The response is deliberately small enough to feed into a policy without exposing a tuning guide.
This is narrower than identity fingerprinting. Anti-Mage does not tell you which commercial browser, extension, or automation package produced the readings. Its strongest determination says the environment appears modified. The README explicitly includes privacy, accessibility, and content-blocking tools among possible sources of modification. That distinction matters if a score could block an account or payment. A competent integration should combine it with other evidence and give uncertain results somewhere to go besides automatic rejection.
The server accepts local browsers only
The included page starts on 127.0.0.1:8787, caps payloads at 1 MB, and uses a 30-second request timeout. go run . prints the URL and serves an embedded collector. The browser requests scan inputs, measures itself, and posts observations back. A nonce ties the response to inputs recently issued by the server, while the server supplies the clock and control values.
That 30-second server is not a deployment template for a public edge. Its address check rejects every non-loopback listener, including a normal container interface. This is a useful safety boundary for a diagnostic page, but a remote service needs architecture that this repository does not provide. You would have to collect observations in your own client, transport them through your application, and call the assess package under controls you own. There is no documented proxy, authentication layer, tenant model, or retention policy.
What happened when we ran it
Our measurement setup was a fresh unprivileged Debian container with 3 CPUs and 8 GB of RAM. Our sandbox installed Anti-Mage in 10 seconds and installed 1 package. The build completed successfully in 24 seconds. We ran go test in 13 seconds, with 10 passed and 0 failed out of 10. On the measured commit, no hidden service or credential appeared in the run.
We measured a checkout of 87 files, about 17,637 lines of source, and 0.6 MB before build outputs. We found 0 CI workflow files, no Dockerfile, and no tests directory. Go test files do exist beside the packages, which is consistent with the 10 passing tests; the signal only means there is no separate directory named for tests. The project declares Go 1.24 and no external module dependency in go.mod.
Those results cover repository mechanics, not detection accuracy. We did not reproduce the README's browser sample table, compare real fraud traffic, or measure false positives in our sandbox. The successful 13-second test run says the code's available checks passed in the stated 3-CPU, 8 GB Debian container. It does not validate a blocking threshold for your users.
A zero score means agreement, not humanity
Anti-Mage's 0 to 100 score carries a warning that matters more than its exact value. A result of 0 means the readings that reached the scorer did not contradict one another. It does not mean the environment is untouched, and it does not establish that a human is present. Too few useful readings produce an insufficient determination, while unknown probe IDs are ignored so newer collectors can still talk to older servers.
The Go 1.24 in-process API is the better fit for serious evaluation. assess.Evaluate takes observations, controls, offset dates, elapsed milliseconds, and optional findings. The function has no clock, filesystem, network access, or global state. That makes a decision repeatable and keeps caller-owned controls out of hostile JSON. The HTTP decoder reads observations and the echoed nonce, then the server restores its own inputs before scoring.
The published browser evidence is Windows-only
The author reports 100 Windows samples for each listed browser. In that table, stock Chrome, Firefox, and Edge stayed at 0 across every sample, Brave had a median of 10, and four anti-detect browsers had medians from 60 to 80. Those are the project's published results, not figures we reproduced. They show the intended use, but they do not establish behavior on macOS, Linux, mobile browsers, uncommon hardware, or production traffic.
Reference tables carry a source and a verified flag, and an unverified table cannot count as evidence. That is a sensible constraint when browser versions and hardware support change. The project also withholds reading-level explanations from the assessment response, which makes evasion harder but complicates appeals and debugging. Before enforcing a threshold such as the README's example score of 30, a team should collect its own labeled traffic, study privacy-tool effects, and decide what an inconclusive result does.
An August 2026 codebase has little maintenance history
The repository was created on August 22, 2026 and its measured commit was pushed on August 30. GitHub showed 1,254 stars, 0 open issues and pull requests, no tags, and no latest release. The two closed pull requests were both opened and merged by the owner, and GitHub listed one contributor. Current activity is obvious, but issue response and outside contribution cannot be judged from eight days of history.
The clean 10-second install and 10 passing tests make Anti-Mage easy to inspect. Its modest scope is also its limit: it gives Go teams a consistency score, not a hosted anti-fraud product or a claim about the visitor behind the browser. Trial it locally, read the scoring code, and validate it against the environments your users actually run before any score affects access.