Terms of service and anti-cheat¶
This is the most consequential page in the documentation, because it is the one where being vague would do actual harm.
Read it before pointing this software at any game you did not write yourself.
The short version¶
This project automates play. For a single-player or offline game, that is between you and the game, and we think it is unambiguously fine.
For an online game it is very often prohibited by the terms you agreed to when you made the account, frequently regardless of whether anyone is harmed by it, and the consequence — a suspended or terminated account — lands on you and not on us.
We do not attempt to hide from detection, and we will not add features whose purpose is to make automated play harder to notice.
What this software actually does¶
Being precise matters here, because the category invites assumptions that are wrong in both directions.
The agent captures the target window through the Windows screen capture API, the same one a screen recorder or a video call uses. It synthesises mouse and keyboard input through the standard input injection API, the same one an accessibility tool or a remapping utility uses.
That is the whole surface. Specifically, it does not:
- load a kernel driver, or any driver
- inject code into the game process
- hook any function, in the game or anywhere else
- read or write the game's memory
- modify game files
- draw inside the game's rendering pipeline
- intercept, modify or forge network traffic
- present itself as a physical input device
This is an architectural commitment, not a current state of the implementation. It is recorded as a decision, it is enforced by the design of the process topology, and a contribution that violated it would be rejected on that basis alone.
What anti-cheat systems detect¶
Broadly, three families, and it is worth understanding which ones apply.
Integrity checks. Kernel-level protection systems look for injected modules, patched function prologues, unexpected handles to the game process, modified files, and drivers known to be used for cheating. These are the checks our architecture is designed around. An agent operating entirely outside the process does not trip them, because there is nothing in the process to find.
Input provenance. Windows marks synthesised input. Any process that installs a low-level input hook can see a flag saying an event was injected rather than generated by hardware. This is not obscure and it is not difficult.
Behavioural analysis. Timing distributions, reaction times, session length, path efficiency, the statistical fingerprint of how a player moves. A system that plays for eight hours with no bathroom break has a shape that is visible in aggregate regardless of how the input arrives.
We do not defeat the second and third¶
This is the part that matters, and it is where most projects in this space are dishonest.
Injected input is detectable. There is a flag. Any game that wants to look can look. We do not obscure it, and there is no setting that does.
Human-like mouse movement is not camouflage. The agent moves the mouse along a curved path with a realistic velocity profile, varies its key hold durations, and pauses irregularly. That is in the design for functional reasons that have nothing to do with detection:
- Games that read raw input deltas for camera control ignore a cursor that teleports, or clamp one enormous movement into nothing. Without a sequence of plausible small movements, camera control does not work at all.
- Many interface elements activate on hover before they accept a click. Arriving and clicking in the same frame means the click lands before the hover state exists and is discarded.
- A great deal of game input code debounces, and a key press with no measurable duration is filtered out.
The movement synthesis exists because without it the agent cannot play. We are stating that plainly here so that nobody mistakes it for a stealth feature, and so that no future contributor tries to tune it into one.
Behavioural detection is not something we address. The mitigation for it is not to run the agent on games where that matters.
So what is the posture for?¶
Not evasion. Defensibility.
Every operation this software performs is an operation that ordinary, uncontroversial software performs: a screen recorder captures windows, an accessibility tool synthesises input, a macro utility replays key sequences. A project that stayed out of kernel space and out of the game's address space can be reasoned about, audited, and argued for. A project that injected code could not, whatever its intentions.
It also means the failure mode is honest. If a game's protection notices the agent and acts, that is the system working as intended. We do not consider it a defect and we will not accept a fix for it.
The terms of service question is separate, and usually stricter¶
Detection is a technical question. Permission is a legal one, and they come apart.
Most online games' terms prohibit automation outright, in language that does not care how the automation is implemented or whether it confers an advantage. "Do not use bots, scripts or automation" covers this software regardless of the fact that we do not call it a bot and regardless of it operating only through public APIs.
Three things follow.
A game may prohibit this even though it will never detect it. Undetectable and permitted are different properties.
Detection may not be the consequence. Reports from other players, anomalous account statistics, and manual review all exist.
The consequence lands on your account. Not on the software, not on the project, not on us. An account you have spent years on can be terminated over an afternoon of automation, and there is frequently no appeal.
Where we stand¶
The supported use is single-player, offline, and self-hosted games — the case where nobody else is affected and the terms rarely prohibit it.
For online games, the software is technically capable and we do not block it, because drawing that line for someone else's account is not ours to draw and a block would be trivially circumvented anyway. What we do instead is refuse to pretend the risk is not there: the interface says so at the point of use, not only in a document nobody reads.
There are categories where we think using this is clearly wrong, regardless of terms:
- Competitive multiplayer, where automation takes something directly from another player.
- Anything involving real money — trading, marketplaces, gambling mechanics, anything that converts to currency.
- Accounts that are not yours.
- Generating goods or currency for sale.
We will not build features that serve these, and this is not a use case we accept contributions for.
If you are going to do it anyway¶
We would rather you did it informed.
Read the actual terms for the specific game — not a forum summary, and not the terms of a similar game. They vary more than people expect.
Assume detection is possible, and decide whether you would accept losing the account. If the answer is no, do not run it on that account.
Use the safety limits. A time budget and an action budget are there so that a session that goes wrong goes wrong small.
Do not let the agent talk. Chat is off by default and should stay that way. It is also the main route by which another player could try to manipulate the agent through text on screen.
Watch the first session. The agent is at its least predictable on a game it has just met, which is exactly when a dry run costs you nothing.