The January 2026 earthquake — Jagex killed the Java client
On 28 January 2026, Jagex fully retired the Legacy Java Client. For over a decade, the Java client had been the architectural foundation that every major injection and reflection bot was built on. That foundation is now gone.
Jagex was explicit about the motivation. During research into who was still using the Legacy Java Client, they found "quite a lot of malicious activity going on" and stated the shutdown was "part of our ongoing efforts to reduce illicit activity such as botting." This wasn't a routine deprecation — it was a deliberate move to cut off the ecosystem that powered the majority of OSRS automation.
RuneLite and HDOS — Java-based but approved third-party clients that run alongside the C++ client rather than replacing it — were explicitly exempted from the shutdown. They connect through the Jagex Launcher and remain fully supported.
The immediate impact was seismic. Every bot client that required injecting into or reflecting against the Java client stopped working on that date. Some adapted by building compatibility layers that run scripts inside vanilla RuneLite. Others pivoted to native approaches targeting the C++ client directly. Others are still catching up, months later. The landscape didn't just shift — it was rebuilt from the ground up.
The five types of OSRS bots — a brief taxonomy
To understand what changed and what didn't, it helps to know the technical categories that OSRS bots have historically fallen into:
Color bots read the screen pixel-by-pixel and simulate mouse and keyboard input at the operating system level. They don't modify the client at all — they interact with it the same way a human does, just by looking at what's on screen and clicking. Hardest to detect from a client perspective, but extremely fragile when graphics change, UI elements shift, or game updates alter visual appearance.
Injection bots injected code directly into the Java client's bytecode at runtime. This gave them deep access to the game's internal state — inventory contents, NPC positions, player stats — without needing to parse the screen. They were the most powerful category but also the most detectable, because bytecode modification leaves fingerprints. Dead since the Java shutdown.
Reflection bots read the Java client's internal state without modifying it — essentially a read-only mirror of the game's class fields and methods. Historically considered harder to detect than injection because they didn't alter the client code, only observed it. Also dead since the Java shutdown.
Packet bots bypass the client entirely and send game-action packets directly over the network. Most were killed years ago by protocol encryption. However, a 2021 security researcher demonstrated they're still technically feasible after reverse-engineering the native client's networking layer — though building and maintaining one requires deep technical expertise.
Plugin-based bots run as plugins inside an approved client — typically RuneLite — using the client's own public API to interact with game state. They don't modify the client, don't inject code, and don't need to reverse-engineer anything. They leverage the same hooks and methods that legitimate RuneLite plugins use. This is the category Pluginscape operates in.
The Java shutdown eliminated categories 2 and 3 entirely. What remains in practice is color bots (fragile and maintenance-heavy), native C++ approaches (technically demanding and narrow), and plugin-based approaches running inside RuneLite (the current sweet spot of capability, stability, and safety).
What survived — and what the landscape actually looks like
The only approved third-party clients are RuneLite and HDOS. The official client is the native C++ client launched through the Jagex Launcher. Everything else is, by definition, an unapproved client.
Most post-Java "bot client" content online comes from vendors claiming their product uniquely survived the transition and emerged stronger. Treat these claims with healthy skepticism. Specific numbers like "99.2% ban-free" or "mobile-specific detection contributed 13,811 bans per week" are vendor-reported, not corroborated by Jagex or any independent research. Every vendor has a direct commercial incentive to frame their approach as the safest — that's marketing, not evidence.
The practical reality is straightforward: if a bot runs as its own separate process — with its own executable name, its own network fingerprint, its own process signature — it is distinguishable from what legitimate players run. It may not be detected through this distinction (Jagex's primary detection is behavioral, not client-scanning), but it's distinguishable. And Jagex explicitly banned 3,000+ accounts for "illegal client usage" in a single 30-day period in 2024. Client fingerprinting may not be the primary detection vector, but it's clearly still in use.
The question isn't "which bot client survived the Java shutdown." The question is: "what does my setup look like from Jagex's perspective?"
Why vanilla RuneLite sideloading is the safest architecture
Running automation as a plugin loaded into unmodified, vanilla RuneLite has several structural advantages that no standalone bot client can replicate.
Client hash matches the official approved build. Unlike a forked RuneLite JAR — where even minor modifications change the build hash — a plugin loaded into stock RuneLite means the client binary is identical to what millions of legitimate players run. If Jagex performs any form of hash-based client verification, stock RuneLite passes. A fork doesn't.
Process signature matches real players. The running process is genuinely RuneLite. Same process name, same memory footprint baseline, same network traffic patterns during normal operation. There's no separate "bot.exe" or custom executable to fingerprint in the process list or via system-level monitoring.
No injection into the C++ client. RuneLite runs as its own Java application alongside the C++ native client, connected through the Jagex Launcher. There's no process attachment, no DLL injection, no bytecode manipulation of either the Java or C++ runtime. The client integrity remains untouched.
The C++ client's system-wide mouse hook doesn't apply. As documented in the vmcall research, the native C++ client installs a low-level Windows mouse hook that captures all mouse events at the OS level. RuneLite, being a Java application running in its own JVM, doesn't install this hook. RuneLite-based automation operates outside this particular telemetry layer — the dual-stream cross-checking that the C++ client enables simply isn't present.
Access to the full RuneLite ecosystem. A RuneLite user has access to hundreds of legitimate quality-of-life plugins — quest helpers, agility highlights, inventory tags, ground item overlays. These plugins provide the same kind of game-state awareness that automation needs but in a context that millions of legitimate players also use. The boundary between "helpful plugin" and "automation plugin" is architectural, not behavioral.
Trust and transparency. RuneLite is fully open source. Every line of code is auditable on GitHub. When you run stock RuneLite, you know exactly what you're running because the community has verified it. The only code you need to trust is the plugin itself — and that's a much smaller surface area than an entire custom client.
The shim approach — how it works
The most sophisticated approach to RuneLite-based automation is the "shim" model. A shim is a thin compatibility layer that lets automation scripts designed for a specific framework — like Microbot — run inside stock RuneLite without forking the client.
Here's the architecture at a high level: the shim loads as a standard RuneLite plugin. It wires up the framework's convenience APIs — bank interaction, NPC finding, pathfinding, inventory management — against vanilla RuneLite's injected client objects. These are the same objects that legitimate RuneLite plugins (like quest helpers or ground item overlays) use to read game state. The shim just exposes them through a different API surface.
From the client's perspective, it's just another plugin — no different from the hundreds of plugins on the RuneLite Plugin Hub. From the server's perspective, the client process is genuine, unmodified RuneLite connected through the Jagex Launcher.
This is the approach Pluginscape uses. Buyers run stock RuneLite downloaded from runelite.net — no custom client fork, no modified JAR, no separate executable, no trust problem. You don't need to download anything from us except the plugin file itself. You don't need to evaluate whether our custom client is safe, because there isn't one.
The heuristic stream still matters
Here's the important nuance that this entire discussion needs to land on: "safe client" does not mean "safe behavior."
Even inside vanilla RuneLite, the client sends heuristic data — mouse movement patterns, click timing distributions, session activity metrics — to the server. Jagex's ML-based detection system, Botwatch, analyzes this data regardless of which approved client generated it. RuneLite is approved and trusted, but the behavioral telemetry it transmits is still subject to the same analysis pipeline.
A RuneLite-based bot with poor input humanization — linear mouse paths, perfectly regular click timing, no camera rotation, no idle periods — will be detected just as reliably as one running in a standalone bot client. The client choice eliminates one class of detection risk (client fingerprinting, process signatures, hash mismatches), but behavioral detection at the server level remains fully active and fully capable.
This is why plugin quality matters as much as client choice. The architecture gets you in the door. The behavioral patterns keep you there. A well-architected client with bad humanization gets banned. A well-humanized plugin on a safe client survives.
The two layers are complementary, not substitutable. You need both.
Pluginscape plugins run on vanilla RuneLite — no custom client fork, no modified JAR. You download RuneLite from runelite.net, load our plugin, and you're running the same client as every other legitimate player. But we don't stop at the client layer: every plugin includes randomized input profiles, session management, and behavioral humanization, because the architecture is only half the equation.
Further reading: How Jagex actually detects bots → · How to minimize the risk of getting banned →