What Jagex actually records about your mouse
Before diving into algorithms, it's worth understanding what data you're trying to make look human. The server doesn't just see "player clicked on tree" — it sees the full trajectory of how the cursor got there.
The native C++ OSRS client installs a system-wide Windows mouse hook that captures every mouse event inside the game window at the operating system level. It maintains two separate event streams — one from the OS-level hook and one from the game window's own input processing — and transmits both to the server. This dual-stream architecture allows the server to cross-reference OS-level mouse data against what the game window received, potentially detecting synthetic inputs that appear in one stream but not the other.
For RuneLite users, the picture is slightly different. RuneLite is a Java application and doesn't install the OS-level hook. But it still sends heuristic data through its own input system — mouse positions, click coordinates, timing information — which the server's ML models analyze.
The bottom line: every mouse movement, click, hover, and pause inside the game window becomes a data point fed into a classification model. The path your cursor takes from point A to point B, how long it takes, how it accelerates and decelerates, whether it overshoots, whether it wobbles — all of it is signal. The quality of that signal determines whether you look like a human operating a mouse or a program dispatching coordinates.
For the full breakdown of the detection pipeline, see our technical deep dive on how Jagex detects bots.
WindMouse — the physics model that's dominated for a decade
WindMouse is the most influential mouse movement algorithm in the OSRS automation space. Originally published over a decade ago and open-sourced, it remains the foundation that most serious implementations build on. Its longevity is a testament to how well its underlying model approximates real hand movement.
The core insight is elegant: instead of plotting a path and moving the cursor along it, WindMouse models the cursor as a physical object with mass, acted on by two competing forces.
Gravity is a constant-magnitude vector that always points toward the destination. It pulls the cursor toward where you want to click, mimicking the intentional component of hand movement — you're trying to reach a target, so there's always a force pulling you that direction.
Wind is a smoothly-varying random vector that introduces organic deviation from the straight-line path. Crucially, wind doesn't change randomly at every pixel — it evolves gradually, drifting in direction and magnitude over time. This creates the natural, flowing wobble of a real hand rather than the jittery noise you'd get from per-pixel randomization. Think of it as simulating the micro-tremors and imprecise motor control of a human arm and wrist.
The interplay between gravity and wind produces paths that curve toward the target with realistic momentum. The cursor wanders slightly off course, gets pulled back, wanders again, converges. Near the destination, gravity dominates and the path tightens — just like how a real hand slows down and gets more precise as it approaches a click target.
The parameters that matter:
Wind magnitude controls how much the cursor deviates from a straight line. Higher values produce more curved, wandering paths that look like a relaxed or imprecise hand. Too high and the movement looks drunk or aimless. Too low and you get near-straight paths that look mechanical.
Gravity magnitude controls how strongly the cursor converges toward the destination. Higher gravity means faster, more direct paths. Balanced against wind, it determines whether the cursor takes a wandering scenic route or a purposeful arc.
Target area and overshoot are where implementations diverge. Some versions add deliberate overshoot past the target followed by a small correction movement — simulating the natural tendency to slide past a small click target and adjust back. This is especially important for small targets like inventory slots, prayer icons, or minimap clicks, where a real player frequently overshoots by a few pixels.
Speed modeling is the other critical component. Real mouse movements aren't constant-speed — they accelerate from a standstill, reach peak velocity in the middle of the movement, and decelerate as the cursor approaches the target. WindMouse handles this naturally through its force model (the cursor has mass, so it takes time to accelerate and decelerate), but many implementations add explicit speed curves on top to fine-tune the velocity profile.
Bezier curves and recorded-path approaches
WindMouse isn't the only approach. Bezier curves are the other major family of mouse movement algorithms, used by SIMBA and most of its derivatives.
Instead of physics simulation, Bezier paths use control points to define a smooth mathematical curve between start and destination. A cubic Bezier curve uses two control points placed off the direct line — the cursor follows the curve defined by these points, creating a smooth arc. Variable speed along the curve, combined with random control-point placement, produces organic-looking trajectories.
Advantages: Bezier curves are mathematically elegant, computationally cheap, and easy to tune. By adjusting how control points are placed relative to the start and end positions, you can systematically control the curvature, direction bias, and "personality" of the resulting paths. They also make it straightforward to guarantee that the path ends exactly at the destination — important for precise clicking.
Disadvantages: Without careful parameterization, Bezier paths can have a characteristic "smoothness" that's too consistent. Real human mouse paths have micro-irregularities — tiny wobbles, slight hesitations, momentary speed changes — that pure Bezier curves don't naturally produce. A trained classifier could potentially distinguish the signature smoothness of Bezier-generated paths from the noisier reality of human movement. Most serious implementations add noise layers on top of the base Bezier curve to address this.
Recorded human paths are a third approach that some developers have experimented with. The idea: record your own real mouse movements between various positions, then when the bot needs to move the cursor, select a recorded path and transform it — rotate, scale, and mirror — to match the current start and destination positions.
One notable bot developer used this approach for a mining bot, capturing real mouse data and replaying transformed versions. The paths were unquestionably human-shaped, because they were literally human paths. However, the account was eventually banned at 87 Mining — suggesting that path shape alone isn't sufficient without the other humanization layers described in this article. Realistic mouse paths combined with robotic click timing or zero camera movement still produces a detectable fingerprint.
In practice, the best results come from combining elements: a primary path algorithm (WindMouse or Bezier) enhanced with micro-jitter overlaid on the path, speed variation correlated with movement distance, and occasional path corrections that simulate a real hand adjusting mid-movement.
Click timing — why uniform random is a red flag
This is where many scripts fail, even those with excellent mouse paths. You can have the most human-looking cursor movement in the world, but if your click timing is wrong, the behavioral fingerprint is still detectably non-human.
The problem with uniform random. The most common approach in amateur scripts is something like "wait a random delay between 500 and 800 milliseconds." This produces a flat distribution — every delay in that range is equally likely. 501ms is just as probable as 650ms is just as probable as 799ms. Plot a thousand of these delays on a histogram and you get a rectangle.
Human reaction times don't look like rectangles. They produce a bell curve — most responses cluster around a central value, with progressively fewer responses at the extremes. This is a fundamental property of human motor control, documented extensively in psychophysics research. A classifier trained on real human timing data would flag a flat distribution immediately, because no human produces one.
Gaussian (normal) distribution is significantly more realistic. Define a mean (say, 650ms) and a standard deviation (say, 80ms), and most clicks will land near 650ms, with occasional faster or slower outliers following the natural bell-curve shape. The standard deviation controls how "consistent" the player appears — a tight distribution (SD of 30ms) looks like a focused, experienced player; a wider one (SD of 120ms) looks more casual or distracted.
Beyond distribution shape, several other timing factors matter:
Fatigue modeling. Real players slow down over time. After two hours of the same activity, click intervals should be measurably longer than they were in the first 15 minutes. A gradual increase of 5-15% over a multi-hour session matches the natural decline in human reaction time as attention fades.
Context-dependent timing. You react faster to expected events than unexpected ones. When you're woodcutting, you know the tree will fall — your reaction is primed and fast. When a random event appears unexpectedly, there's a noticeable delay before you process and respond. Scripts that use the same timing distribution regardless of context miss this natural variation.
Burst patterns. Real players don't click at a steady rhythm. They click rapidly in bursts during high-interaction phases — banking, gear switching, inventory manipulation — then slow down dramatically during execution phases when they're watching an animation play out. The variance between burst-mode and idle-mode timing is itself a natural feature of human input.
Inter-session variation. Your timing profile shouldn't be identical across sessions. Some sessions you're focused and fast; some sessions you're tired and slow. Mixing multiple timing profiles — essentially giving the bot a "mood" that varies between sessions — adds another layer of naturalism that single-distribution approaches miss.
Camera rotation — the behavior bots forget
Here's a detection vector that most automation completely ignores: camera movement.
Humans constantly rotate the camera in OSRS. To spot monsters before they reach you. To glance at other players nearby. To find a path through obstacles. To check if a resource has respawned. Out of sheer fidgeting while waiting for an animation. Camera rotation is one of the most persistent, unconscious behaviors in normal gameplay — and its absence is conspicuous.
Bots typically don't rotate the camera because the script doesn't need to. The bot knows where every NPC and object is through the client API, regardless of camera angle. It can click things that are off-screen or behind the camera because it's not actually looking at the screen. This creates a tell: an account that executes complex, spatially-distributed actions while the camera sits perfectly still for the entire session.
Camera interaction frequency and variance is plausibly a behavioral feature in Jagex's ML detection models. The game client logs camera state alongside all other interaction data — the data is available for analysis whether or not Jagex currently uses it.
What good camera humanization looks like:
Randomly-triggered rotations at Poisson-distributed intervals. Not a regular timer (rotate every 45 seconds) but stochastic timing where rotations happen at naturally irregular intervals — sometimes two rotations within 10 seconds, then nothing for two minutes. This matches the impulsive, unconscious nature of real camera adjustment.
Variable direction and magnitude. Sometimes a small 15-degree adjustment. Sometimes a full 180-degree spin to check behind you. Sometimes a gentle drift. The distribution of rotation sizes should be heavy-tailed — mostly small adjustments with occasional large sweeps.
Camera movement that precedes action. This is subtle but important. When a real player needs to click something that's off-screen, they rotate the camera to see it first, then click. A bot that clicks invisible off-screen targets perfectly — without ever moving the camera to face them — is exhibiting behavior that's spatially impossible for a human.
Middle-mouse drag. The natural way OSRS players rotate the camera is by holding middle-mouse and dragging. This produces a characteristic input pattern — a mouse-down event, a drag of variable length and speed, and a mouse-up event — that's distinct from arrow-key rotation. If camera rotation is being analyzed, the input method matters.
Occasional zoom changes. Real players scroll-wheel to zoom in and out, often unconsciously. Periodic zoom adjustments add another dimension of natural camera interaction.
Intentional imperfection — misclicks, overshoots, and doing nothing
Here's the counterintuitive principle that ties everything together: perfection is the enemy of believability.
Tick-perfect play with zero errors over an extended session is statistically anomalous. Even the best human players miss ticks, misclick targets, and make small mistakes that they immediately correct. A bot that never makes a single error across four hours of play is exhibiting superhuman consistency that's itself a detection signal.
The imperfections real players exhibit:
Off-target clicks. Clicking one tile off the intended target, pausing briefly, then clicking the correct tile. This happens especially with small or overlapping targets — inventory slots, stacked NPCs, closely-spaced objects.
Double-clicks. Clicking something twice when once was sufficient. Particularly common during rapid inventory interactions where the player is moving quickly and their click registers on the same item twice.
Right-click cancels. Right-clicking to open the context menu, then selecting "Cancel" or clicking away — the player changed their mind or right-clicked by accident. This is a normal part of gameplay that bots almost never simulate.
Hover without clicking. Moving the cursor over an entity or object and pausing without clicking — the player is reading text, checking an item, or deciding what to do. The cursor rests on interactive elements without acting on them, then moves away.
Overshoot and correction. Built into WindMouse as the overshoot parameter, but worth emphasizing: the cursor slides past the target by a few pixels, pauses, then makes a small corrective movement back. This happens more often with longer movements and smaller targets, matching the physics of real hand deceleration.
Wrong-target correction. Clicking the wrong NPC or object when multiple are stacked or nearby, then re-targeting. This happens naturally at crowded fishing spots, bank areas, and anywhere that multiple interactive elements overlap.
Running at 85-90% of theoretical maximum efficiency — not 100% — produces rate distributions matching a very good human player rather than a machine. The remaining 10-15% isn't wasted — it's the natural overhead of being human.
Off-screen behavior — simulating absence
A bot whose mouse coordinates are always inside the game window for the entire session emits a distinctive signature. Real players are constantly multitasking — checking Discord, reading the wiki, replying to messages, watching a video on a second monitor. The mouse leaves the game window regularly and for varying durations.
This matters because the OSRS client's mouse hook explicitly discards events outside the game window. From the server's perspective, when the mouse leaves the window, input simply stops. The absence of input is itself data — and a continuous, unbroken stream of in-window mouse activity with zero gaps across a multi-hour session is unusual for legitimate play.
Simulating this means periodically releasing cursor control. Move the synthetic cursor outside the game window bounds or simply pause all input generation for a period — anywhere from 5 seconds to 2 minutes at random intervals. During this time, the character should either be idle or performing an action that doesn't require input (watching a fishing animation, waiting for a tree to fall, standing in an NMZ session).
The timing of these pauses should follow a heavy-tailed distribution — mostly short glances away (5-15 seconds) with occasional longer absences (1-3 minutes). They should correlate loosely with natural break points in gameplay: after banking, after completing an inventory, while waiting for a respawn.
The goal isn't to do something. It's to do nothing, convincingly. Paradoxically, the moments when your bot isn't acting may be the moments that make it most believable.
Every Pluginscape plugin implements per-user randomized input profiles — WindMouse-based paths with unique parameterization, Gaussian click timing, camera drift, and natural pauses. Your behavioral fingerprint doesn't match anyone else's, because it shouldn't.
Further reading: How Jagex actually detects bots → · How to minimize the risk of getting banned →