The myth — "Jagex scans your client"
There's a persistent belief in the OSRS community that Jagex detects bots primarily by scanning for modified clients or injected code — that detection is essentially an antivirus, looking for known bot signatures in memory. This belief drives people toward elaborate client obfuscation, custom launchers, and code-packing techniques in the hope of staying invisible.
The reality is more nuanced. Client-type detection does exist. Jagex reported banning over 3,000 accounts for "illegal client usage" in a single 30-day period in 2024. But this category — client-level detection — is a small fraction of their overall anti-bot operations. The primary detection system is behavioral, not client-scanning.
Jagex's own description of Botwatch, their automated banning system, says it "profiles accounts and determines whether or not they are using botting software" by monitoring "an account's actions" — not by analyzing the bot software itself. The system watches what you do in-game and decides whether your behavior looks human.
This distinction matters enormously. It means that what you do matters far more than what you're running. Vanilla RuneLite with a sideloaded plugin is no riskier from a client-detection perspective than any other RuneLite installation — because from the outside, it is one. But it also means there's no client-side silver bullet. You can't hide behind a legitimate client if your in-game behavior screams automation.
The rest of this article breaks down what public reverse-engineering research has actually revealed about how the detection pipeline works.
What vmcall actually discovered — the mouse hook
In April 2021, a security researcher known as vmcall published detailed findings from reverse-engineering the native OSRS client — the C++ client that replaced the Java client and is now the only official Jagex-distributed client. The research revealed several mechanisms that had been speculated about for years but never publicly confirmed.
The low-level mouse hook. Shortly after launch, the native client installs a system-wide Windows mouse hook — the same mechanism used by keyloggers and accessibility tools. This hook intercepts all mouse events on the entire operating system, not just those directed at the game window. However, there's a critical filter built in: mouse events that occur outside the RuneScape window are discarded entirely. Only events inside the game window are logged and processed.
The purpose of this hook is telemetry collection. The client is gathering detailed data about how the mouse moves and clicks within the game — at the operating system level, below what the game's own window management can see.
Two separate event streams. The research revealed that the client maintains two distinct buffers of input data, both of which are transmitted to Jagex's servers:
The first is the "hook source" — events captured by the system-wide hook described above. These represent raw OS-level mouse data: where the cursor moved, when it clicked, the exact timing and trajectory.
The second is the "client source" — events that the game's own window received through normal input processing. These are the standard mouse events that any Windows application receives when the user clicks on its window.
The server receives both streams simultaneously. The existence of two independent input channels is the key finding — it allows the server to cross-reference whether inputs that reached the game window also appeared at the OS level. Synthetic inputs, such as those generated by Java's Robot class or injected via Windows message posting, might appear in the client source (because the game window received a click) but not in the hook source (because the OS-level hook never saw a real mouse movement). This discrepancy is a potential detection signal.
Important caveat for RuneLite users. This system-wide mouse hook is installed by the native C++ client. RuneLite is a Java application running in its own JVM process — it does not and cannot install this particular hook. RuneLite-based bots operate in a fundamentally different detection context. The server still receives heuristic data from RuneLite, but it comes through Java's own input handling system rather than the OS-level hook. The dual-stream cross-checking mechanism described above applies specifically to the native client.
This doesn't mean RuneLite is unmonitored — far from it. But it means the specific detection vectors are different, and the input data the server receives has different characteristics.
The AFK gate — the most important finding
If there's one discovery from the vmcall research that reshaped community understanding of bot detection, it's this one.
During his research, vmcall patched out the function responsible for sending heuristic data to the server. With the telemetry pipeline disabled, something unexpected happened: his account was logged out after exactly five minutes — the standard AFK timeout — even though the game was fully playable and he was actively executing actions through the network layer.
The client was sending game actions (clicking objects, walking, interacting with NPCs) successfully. The server processed them. But because the server wasn't receiving the accompanying heuristic data — the mouse movements, the click timings, the behavioral telemetry — it treated the account as if the player was away from the keyboard.
He then built a bot that operated purely through network packets. It never generated any mouse events at all. It completely suppressed the heuristic pipeline. And he ran this bot, in his own words, "24 hours a day, seven days a week, without ever moving my mouse" — for thousands of hours. The account was never banned.
His conclusion: the server-side bot detection pipeline appears to be gated by the client-transmitted heuristic data. If the server doesn't think you're actively playing — because it's not receiving heuristic input — it doesn't run anti-bot analysis. It simply treats you as AFK and eventually logs you out.
What this tells us about the architecture: The heuristic pipeline serves a dual purpose. It's both the primary data source that feeds the machine learning models and the trigger that activates them. No heuristic data means no analysis, which means no detection. The system is fundamentally designed to analyze how you interact with the game, not what software you're running. Behavioral telemetry isn't just one input to the detection system — based on this research, it appears to be the foundation the entire system is built on.
An important caveat: This research was published in 2021. Whether this exact mechanism still exists in the 2026 client is unknown — Jagex has had five years of updates, internal restructuring, and anti-cheat investment since then. The specific functions vmcall patched may have been refactored, the AFK gate may have been supplemented with additional checks, and the heuristic pipeline may have been hardened against the exact technique he described. But the architectural principle — that behavioral telemetry is the foundation of detection, not client scanning — is consistent with everything else we observe about how Botwatch operates.
Botwatch — server-side ML and what it profiles
Jagex's automated banning system, Botwatch, has been running since September 2012. It replaced the earlier BotNuke initiative and has been continuously updated since. A former anti-cheat team member who worked at Jagex for seven years publicly reported applying over 12 million offences during his tenure — giving some sense of the scale at which the system operates.
Based on community analysis, detection-theory discussions, and the feature set of the Bot Detector plugin (a community-built tool that successfully identifies bots using similar techniques), the evidence strongly suggests that Botwatch uses machine learning models trained on labeled datasets of confirmed human and confirmed bot accounts. The plausible feature set includes:
Click inter-arrival time distributions. Not just "how fast do they click" but the statistical distribution of delays between clicks. Humans produce a natural Gaussian-like distribution with occasional outliers. Bots using uniform random delays produce a distinctive flat distribution. Bots using poorly implemented Gaussian delays often have an unnaturally tight standard deviation.
Mouse path geometry. The shape of the cursor's path between two points. Straight lines at constant speed are a dead giveaway. Human movements follow curved paths with variable acceleration, slight overshoot near the target, and micro-corrections on final approach.
Session length distributions. How long does the account play in a single sitting? How consistent are session lengths over time? How long are breaks between sessions? Accounts with perfectly regular 8-hour sessions and 15-minute breaks every day look nothing like real players.
XP rate consistency. Is the player hitting near-theoretical-maximum rates for hours on end? Even elite players show natural variance in efficiency. Sustained tick-perfect performance is a statistical anomaly that stands out clearly in the data.
Camera rotation behavior. How often does the player move the camera? In what directions? Is camera movement correlated with upcoming actions (looking toward where they're about to click) or completely absent? Bots that never touch the camera emit a distinctive behavioral signature because humans unconsciously rotate the camera constantly.
Movement path repetition. Does the account walk the exact same path between the bank and the fishing spot every single trip? Real players show natural variance in pathing — slightly different routes, occasional detours, varied starting positions.
Cross-account behavioral clustering. This is the big one. Jagex doesn't just analyze individual accounts in isolation — the evidence strongly suggests they detect clusters of accounts exhibiting identical behavioral fingerprints. When a public script is used by thousands of players with default settings, those thousands of accounts share click timing distributions, mouse path characteristics, session patterns, and action sequences. This cluster becomes a target. Once Jagex identifies and verifies a behavioral fingerprint against one confirmed bot, they can sweep for every account matching that fingerprint.
This is why public scripts with large user bases consistently show higher ban rates than private scripts or well-configured premium plugins. It's not that the code is worse — it's that the behavioral fingerprint is shared across enough accounts to become statistically detectable and worth Jagex's time to target.
Account trust scoring
The detection system doesn't appear to apply the same thresholds to every account. Community experience consistently shows that older, more established accounts can sustain more automated play before triggering a ban — while fresh accounts botting from level 3 get caught much faster.
Based on observable patterns, factors that appear to raise an account's detection tolerance include:
Account age. An account that's existed for months or years with legitimate play history has a behavioral baseline that a brand-new account doesn't. The detection system can compare current behavior against historical behavior — a sudden shift from varied human play to robotic repetition is suspicious, but a lesser deviation from baseline may not cross the threshold.
Total level and XP distribution. An account with XP spread across many skills looks more like a real player than one with 99 Woodcutting and level 1 everything else. The Bot Detector plugin explicitly includes "Stats Too Low" — a gross skill-distribution mismatch — as a prediction category in its ML model, confirming that statistical profile features are weighted in detection.
Quest points completed. Quest completion requires varied, non-repetitive gameplay involving dialogue, navigation, combat, and puzzle-solving. A meaningful quest point total is a strong signal of real play.
Historical non-automated sessions. If the server has records of past sessions with clearly human input patterns, it has a positive baseline to compare against. Accounts with no human baseline have nothing to give them the benefit of the doubt.
Social engagement. Friends list entries, clan membership, and chat activity are all signals that a real person is behind the account. Bots almost never engage socially.
Membership status. Paying accounts appear to face less aggressive detection. The likely reasoning: real payment information provides a partial identity signal, and the business incentive to aggressively ban paying customers is lower than for free accounts. This is consistent with the observation that F2P worlds — where the bot population density is highest — use more aggressive detection thresholds.
None of this means established accounts are immune to detection. It means the system likely uses a sliding threshold rather than a binary trigger, and account history shifts where that threshold sits.
Trade graph and RWT detection
Bot detection doesn't stop at the account doing the botting. Jagex removes approximately 900 billion GP per week from the OSRS economy through bans — a number that reflects not just bot accounts but the downstream wealth they generate.
Mule detection — identifying the accounts that collect and transfer botted wealth — relies on trade pattern analysis that operates at a completely different level from behavioral detection. The evidence suggests this includes:
Unusual trade patterns. Large, one-directional wealth transfers — one account consistently giving items or gold to another without receiving anything in return — are a clear signal, especially when the source account has a suspicious activity profile.
Grand Exchange manipulation. Buying or selling patterns that don't match normal player behavior — such as consistently listing items at specific prices that facilitate wealth transfer between accounts.
IP and device linkage. Accounts that share IP addresses, hardware fingerprints, or login patterns with known bot accounts inherit suspicion. This is why separating bot infrastructure from your main account's access patterns matters.
Graph analysis across the trade network. Jagex can trace the flow of wealth across multiple hops. Even if you trade from your bot to a mule to a second mule to your main, the graph connection exists. The more hops and the more time between transfers, the weaker the signal — but the connection can still be traced.
The practical implication: even if your botting account survives indefinitely, how you move wealth off it can trigger bans on both the bot and the receiving account. Wealth transfer is its own detection domain with its own set of risks.
What this means for plugin-based automation
Understanding the detection pipeline isn't academic — it directly informs how automation should be engineered.
The heuristic stream is what Jagex analyzes. Based on the vmcall research, the behavioral telemetry transmitted by the client is the foundation of detection. This means realistic input patterns — mouse movement, click timing, camera behavior, session structure — matter more than any client-level obfuscation. You can't hide from a system that's watching your behavior by disguising your software.
RuneLite-based plugins operate in a favorable detection context. You're running a legitimate, widely-used client process. There's no system-wide mouse hook to cross-reference against. The server receives heuristic data through Java's input system, which is the same path used by every legitimate RuneLite user. But "favorable context" is not immunity — you still need to emit realistic heuristic data through realistic input behavior.
Cross-account behavioral clustering is the mechanism behind ban waves. Plugins with per-user randomization — where each installation produces genuinely different behavioral fingerprints — are structurally safer than shared public scripts where thousands of users look identical to the detection system. This is an architectural advantage, not a marketing claim.
Account trust scoring is real and actionable. Warm-up procedures, varied play, quest completion, and social engagement genuinely shift where the detection threshold sits for your account. The time invested in building account legitimacy compounds over the account's lifetime.
Understanding the detection pipeline is step one. Using plugins engineered around it is step two.
Further reading: How to minimize the risk of getting banned → · RuneLite vs custom clients for botting in 2026 →