Neverclick's repository holds one file, and its own FAQ says detection hallucinates

The repository contains a README and nothing else

The published tree has exactly one entry, the README file. There is no source directory, no build configuration, no license file and no manifest of any kind, and the language field for the repository is unresolved. What the repository does carry is a release history: three tagged versions in the last six weeks, at 0.3.1, 0.4.0 and 0.4.1, with the newest tagged one second after the last commit to the branch.

So the repository is a distribution point and a manual, not a project. The installer is fetched from a separate website, and the tagged releases appear to carry the product rather than a build recipe, since there is nothing here that could produce one. Nothing in the tree is auditable, nothing is forkable in any useful sense, and the absence of a license file is the sharpest gap of the three. Even the terms of use are conveyed only indirectly, through a line in the manual saying it is free to download and use with no accounts, subscriptions or trials, which is a statement in a document rather than a grant in a license.

A reader who found this repository hoping to check how the detection works, or to fix a hint that lands in the wrong place, has nowhere to go.

The accuracy answer is one sentence, and it is the important one

The manual answers a dozen questions about size, speed and platforms. The accuracy question gets the shortest answer in the whole document: it is really good, but it hallucinates occasionally, and the author says work will continue on it.

That sentence matters more than the highlights do, because of how the system is built. The manual defines three pieces of geometry for every detected element: a bounding box drawn as a rectangular outline, a hint which is the label, and a target which is where the mouse action is actually executed, placed in the centre of the box by default and movable afterwards. Every action in the application is therefore aimed at a point inside a rectangle that the detector produced. If the detector invents an element, the rectangle is drawn somewhere plausible and the action lands there.

The speed claims sit next to this without qualification: instantaneous, no perceptible delay, even on ten year old hardware, and no GPU required. Those two facts together are the design. The reason it feels instant is that it reads pixels directly rather than waiting on an application to expose its structure, and the cost of that choice is exactly the hallucination the author names.

Two detection backends, and only one of them can read your code

There are two real detection modes and one fallback, switchable while hints are on screen. The default reads raw pixel data. It is described as extremely fast, able to detect text well enough to be useful for editing text and coding, supporting the full screen mode, and tunable through detection settings. The second reads the operating system's accessibility tree instead. That one is significantly slower, can be unpredictable, works only on the foreground window with no full screen mode, cannot detect text in text editors at all, has no tunable settings, and is only credited with producing cleaner boxes for buttons in certain applications. It is offered as a backup, and one key switches to it while hints are up.

The practical consequence is that the two modes are not alternatives for the same job. If you are writing code, the mode that reads text cannot help you, so you are locked into the pixel mode and its hallucination rate for exactly the task the pixel mode is praised for. The third mode, reached by another key, spaces hints evenly across the screen and exists for the cases no detector handles, such as right-clicking empty desktop.

Tuning is one-sided as well. Detection settings can be adjusted for the pixel mode and not at all for the accessibility mode.

Installing into Program Files is what buys administrator-level clicking

There is no portable version, and the manual explains why in one sentence: Windows requires the application to install into Program Files for it to register as an accessibility tool, and that registration is what lets it perform mouse actions on applications that are themselves running as administrator.

Read that as a single trade with two sides. On one side, the application can drive elevated windows, which is genuinely rare for a utility and is probably why it needs a system-level install rather than a folder you can put on a memory stick. On the other, the user cannot choose where it lives, cannot run two copies with different configurations, and cannot carry a configured setup to another machine without reconfiguring it, because there are no configuration files to carry.

The scope of that capability is worth being explicit about. An accessibility tool that can move a pointer inside a window running with administrator rights is a component in any privilege boundary you have on the machine, so where you install it and who uses the account matters. The manual does not discuss that; it presents the Program Files requirement purely as a Windows formality.

A hint is three objects, and the number row places the target between them

The targeting model is finer than click anywhere on a detected element, and the extra precision is where most of the design effort went. Movement within an element uses the arrow keys, or a four-key cluster, to snap the target to an edge of the bounding box rather than its centre, which is how you reach the start or end of a word inside a text field. The number row, one through nine, positions the target in the gap between two adjacent hints, so you can act on the space between two controls rather than on either of them.

Selection has three modes layered on the same key. One press enters a dual mode that selects two hints at once, adding the shift key enters a multi mode for any number, and adding the control key enters a path mode where selecting two or more hints automatically selects everything between them. Enter finishes in every case.

Window management is separate from hint selection and works through the letter cluster with shift held: one combination switches between windows directly, another cycles through windows that overlap, and another moves to the window behind the active one. A single key toggles between a windowed mode and a full screen mode, so the same vocabulary covers both layouts.

There are no config files, so everything lives in a settings window

The manual is explicit that there are no configuration files and that hotkeys are set in a graphical interface instead. That decision has consequences worth spelling out. Nothing about your setup can be committed, diffed, shared with a colleague or restored after a reinstall, and there is no documented way to move a configuration to a second machine.

The vocabulary inside that window is small and worth learning, because the same terms decide what a key does. A hotkey triggers either a tool or an action. Tools are interactive overlays, named examples being the left click tool and a sticky hints tool that saves hints for repeat clicking. Actions are one-off commands that execute immediately, with scroll and move window given as examples. Keybinds are the narrower set of things you can do while a tool is active, and they are assigned on an interactive virtual keyboard rather than by pressing keys.

There is one piece of tuning that is genuinely adjustable: the key priority map, which decides which letters get which hints. The application favours letters in the centre of the keyboard, and that map can be reordered interactively, which is the closest thing in the product to a preference file.

Windows only, no portable build, and about 40 megabytes

The support matrix is short and has two gaps that matter. It is Windows only for now: Linux, macOS, and Windows on ARM are all listed as unsupported. It is also free to download and use, with no accounts, subscriptions or trials, and there is no portable version for the reason described above.

Input handling is the better part of the story. Hints use the keyboard's language, so a non-English layout shows non-English hints, while the settings interface itself is English-only. Alternative layouts are supported natively, with Dvorak and Colemak named and others covered by the same mechanism, on the condition that the layout is set in Windows. That last condition is the important one: the application reads the layout from the system rather than carrying its own, so a layout set at the application level rather than the system level is not the one the hints will follow.

The resource answers are modest. About 40 megabytes of disk, no GPU, and around 200 megabytes of memory on a typical 1080p monitor with the figure rising for more monitors or higher resolutions, and multimonitor support and both 4K and 8K are answered yes. The idle question gets a clean answer too: the application does not run in a continuous loop when it is not being used.

Two features are labelled as coming rather than shipped, text highlighting between two hints and dragging items, with the drag example being files between folders or rearranging browser tabs.

Editorial conclusion

Use it if you want mouse actions from the keyboard inside arbitrary Windows applications and you accept a detection layer that can invent a control that is not there. Do not adopt it expecting to audit it, patch it or script it: there is no source in the repository, no license file, and configuration happens in a graphical interface with no config files to version or share. Before you install, decide whether registering as a Windows accessibility tool is a trade you want, because that registration is what lets it click into applications running as administrator and it is also why there is no portable build. On a laptop, check the ARM question first, since ARM Windows is listed as unsupported, and test the default pixel mode rather than the accessibility mode when you work in a text editor.

Frequently asked questions

Official sources

1. Issues
2. LazoVelko/neverclick on GitHub
3. Project website
4. README
5. Releases