How CPU Concurrency Detection Works in JavaScript Challenges

CPU concurrency detection in JavaScript challenges works by running a set of parallel tasks in the browser and measuring how many threads execute them and how quickly. Real human browsers with normal hardware produce consistent, varied timing across those tasks. Automated browsers, headless scripts, and virtual machines often complete them too fast, with too many threads, or with a pattern that does not match the device they claim to be. That mismatch becomes one piece of evidence that a visit may not be human.

Bot detection systems like BotRefund treat this concurrency check as one of many independent signals. They do not rely on it alone because privacy tools, corporate networks, and unusual devices can create false positives. Instead, they cross-check it against browser, network, device, and behavior data before making a verdict.

Why JavaScript Challenges Use Concurrency Checks

JavaScript challenges are small tests a website runs in the visitor's browser to see if the environment behaves like a real person's browser. They often ask the browser to perform tasks that a human would not notice, but that reveal the underlying automation.

CPU concurrency checks are useful because they tap into hardware information that is hard to fake consistently. A normal browser reports a number of logical processors via navigator.hardwareConcurrency. It also allocates Web Workers and runs parallel tasks. Bots that run in emulated or virtualized environments often report a CPU core count that does not match the actual execution time of those tasks. For example, a virtual machine might claim 8 cores but finish a heavy parallel workload in a millisecond, which a real 8-core device cannot do.

How the Concurrency Check Works Step by Step

Here is the typical process a JavaScript challenge uses to detect CPU concurrency anomalies:

1. Start the challenge. The page loads a script that first reads basic hardware properties such as navigator.hardwareConcurrency and the user agent string.
2. Create parallel tasks. The script spawns multiple Web Workers or uses Promise.all to launch a set of CPU-heavy computations simultaneously. These tasks might involve hashing, matrix operations, or other workloads that take measurable time.
3. Measure completion time. The challenge records how long each task takes and the time between tasks. It also observes how many workers actually run at the same time.
4. Compare against expected behavior. The system has a model of what a real browser on that device type should do. If tasks finish several times faster than the reported CPU speed, or if the number of active threads does not match the reported core count, it flags the mismatch.
5. Check for additional inconsistencies. The concurrency data is combined with other signals like GPU rendering, font availability, and mouse movement. BotRefund calls this the "CPU Concurrency Lie" check because it looks for a mismatch that a real session would not create.
6. Send the result to a prediction model. The challenge does not make a final decision alone. It sends the concurrency evidence to a machine learning model that weighs all signals together and decides whether the visit is bot or human.

Signals That Commonly Trigger a Flag

Bot detection systems look for specific patterns in concurrency data. Not every anomaly is a verdict, but these are the strongest indicators:

• Reported core count does not match performance. A browser says it has 8 cores, but the parallel tasks complete faster than a real 8-core device could.
• Task times are too consistent. Real human sessions have natural variation - some tasks start later or finish unpredictably. Automated browsers often produce identical timing every run.
• Web Worker startup fails or behaves oddly. Some bot environments disable workers or run them in a degraded mode.
• Virtual machine fingerprint. The concurrency check may reveal that the browser is running inside a VM even though it claims to be a high-end physical device.
• Interaction timing contradicts concurrency. For example, a session might spawn many workers but show no mouse movement or scrolling, which is not how a human interacts.

BotRefund's own documentation says the CPU Concurrency Lie check "looks for a mismatch that a real browsing session does not normally create." This is why a single anomaly is not enough to ban a visitor.

Limitations and When the Check Might Be Wrong

Concurrency detection is not foolproof. There are legitimate reasons a real user might fail it:

• Power-saving modes. Laptops may throttle CPU speed dynamically, causing slower task completion.
• Browser extensions. Extensions can block Web Workers or add overhead, changing timing.
• Corporate VPNs and proxies. These can affect network calls but usually not CPU work, yet they may combine with other signals to look suspicious.
• Old or low-end devices. A phone with a weak processor might complete tasks slower than the model expects.
• Privacy tools. Some privacy browsers spoof hardware concurrency values to protect fingerprinting. This can cause false mismatches.

This is why a robust system does not trust a raw rule. BotRefund explicitly states that "a single anomaly is not a bot verdict" and keeps this signal as evidence that is cross-checked against independent browser, network, device, and behavior data.

Key Facts About CPU Concurrency Detection

How BotRefund Implements Concurrency Detection

BotRefund uses the CPU Concurrency Lie check as part of its bot detection system. The logic is straightforward: it runs a small JavaScript challenge on the visitor's browser and collects the concurrency data. This data becomes one of many inputs to a prediction model.

Because the system cross-checks concurrency evidence with independent signals like GPU fingerprinting, font lists, and behavioral patterns, it avoids the trap of blocking a privacy-conscious human. BotRefund's own documentation stresses that the check adds "one objective fact about the visit" but is not a standalone verdict. This approach helps reduce false positives while still catching bots that try to hide inside virtual machines.

Frequently Asked Questions About CPU Concurrency Detection

What exactly does a JavaScript challenge measure?

It measures how many processor threads the browser can actually run at once and how long parallel tasks take. It also records the reported hardware concurrency value from navigator.hardwareConcurrency.

Can a real user ever trigger a false positive?

Yes. A laptop in battery saver mode, a browser extension that limits workers, or a privacy tool that spoofs CPU cores can all produce unusual results. Good systems like BotRefund use this signal as evidence, not as a final verdict.

Does this detection method work on headless browsers?

Headless browsers like Puppeteer or Playwright often fail because they run in a simulated environment. They may report a core count that does not match their actual performance, or they may not support Web Workers at all.

How long does the JavaScript challenge take to run?

The detection script is designed to be fast and invisible. It typically finishes in under a second and does not interrupt the user's browsing experience.

What happens after the concurrency check is flagged?

The system does not instantly block the visitor. It combines the concurrency result with other signals and feeds everything into an AI model. Only when the overall pattern strongly matches a bot is the visit rejected or flagged for further review.

Can a bot spoof the concurrency check?

It is difficult because the check looks for a mismatch between claimed hardware and actual execution. A bot would need to emulate realistic CPU speeds and task timing simultaneously, which is complex. That is why the check remains useful as part of a multi-signal system.