How the CPU Concurrency Check Catches Bots That Simulate Human Threading

The CPU Concurrency Lie check—one of 106 independent checks BotRefund uses—detects bots that manipulate CPU concurrency by searching for a specific mismatch: a device claims certain hardware, graphics, fonts, and operating-system details, but its processor behavior tells a different story. A real browsing session naturally produces varied, irregular thread scheduling and execution timing; automated browsers and virtual machines often produce patterns that are too uniform or too perfect.

The check does not act as a standalone verdict. Instead, it records the concurrency signal as evidence and cross-checks it against browser, network, device, and behavior data. If the concurrency anomaly is supported by other independent signals, the prediction AI weighs the whole pattern and can classify the visit as bot or human with 99% accuracy, according to BotRefund.

What the CPU Concurrency Lie check actually measures

Modern CPUs allocate time across multiple threads and cores. A human user's browser triggers many concurrent tasks—rendering, input handling, network requests—but these tasks are not perfectly synchronized. There is natural jitter, context-switching overhead, and variance in how long each operation takes.

Bots, especially those running in headless browsers or virtual machines, often use concurrency tricks to mimic human-like parallelism. They may spawn multiple workers or deliberately throttle operations to look slower. But even then, the thread scheduling tends to be too regular or too precise. The CPU Concurrency Lie check looks for those telltale signs:

• Thread timings that are suspiciously uniform across samples
• Context-switch intervals that never vary within a natural range
• Core usage patterns that do not match the reported hardware (e.g., an 8-core CPU acting like a single-threaded process)
• Execution speed that changes in a cyclical, scripted way rather than randomly

It also checks whether the reported CPU model and core count align with observed performance. A spoofed profile might claim a high-end processor, yet the timing measurements suggest a low-end virtual CPU.

Why CPU concurrency is hard for bots to fake

A human session generates real, unpredictable OS-level scheduling. Even the same user on the same device will see different task completion times because of background processes, thermal throttling, and system load. Bots rarely replicate that variance because it is expensive to model and can degrade their performance.

Instead, bots often:

• Use a single thread for all browser automation, making concurrency flat
• Throttle with setTimeout or Promise.delay in regular, fixed intervals
• Run inside a VM that shares the host's CPU but reports a different architecture

That is why a mismatch between the reported hardware and the observed concurrency pattern is a strong signal—it is genuinely hard to fake without building a full OS emulation layer.

How the check fits into the 106-signal system

The CPU Concurrency Lie check is never used alone. BotRefund treats every signal as one objective fact about the visit. According to the source, “A single anomaly is not a bot verdict. Privacy tools, travel, corporate networks, and unusual devices can produce unexpected behavior for genuine people.”

The full process works in three stages:

1. Independent evidence – The check adds one hard measurement about CPU concurrency.
2. Cross-checked context – BotRefund tests whether other signals (e.g., window.open tampering, impossible tab speed, mouse behavior) support the same story.
3. AI prediction – A model weighs the complete pattern, not a raw rule, to decide if the visit is human or automated.

That corroboration is why the accuracy claim is 99%—it comes from combining many imperfect signals, not from any single check.

Step-by-step: how the check runs on a visit

When a visitor lands on a protected page, the bot-detection script executes a sequence of timing tests. Here is a practical view of how the CPU concurrency check runs:

1. Probe execution – The script runs short, CPU-bound loops and measures how long each takes.
2. Record thread scheduling – It captures timestamps around setTimeout, requestAnimationFrame, and worker messages to observe context-switching latencies.
3. Compare to hardware profile – It checks reported navigator.hardwareConcurrency, device memory, and CPU model against the measured concurrency and speed.
4. Look for regular patterns – It computes variance and autocorrelation. If timings are too regular (e.g., every delay is exactly 5.00 ms), that is a red flag.
5. Store as evidence – The result is saved as a boolean or scaled score, but it is not used alone to block the user.
6. Send to prediction model – The score is combined with dozens of other signals (pointer movement, session duration, network fingerprint) to produce a final bot probability.

One common mistake in implementing similar checks is to block immediately on a single concurrency anomaly. That will generate false positives for users on unusual devices or with privacy extensions. The correct approach, as BotRefund uses, is to treat it as evidence and require corroboration.

What to do if you suspect bot traffic on your site

If you see abnormal CPU usage or suspicious clicks in your analytics, do not manually block IPs. Instead, run a structured audit:

• Look at session durations and click speeds (e.g., clicks under 1ms, no mouse tremor).
• Check for grid-aligned pointer paths or superhuman input speeds.
• Examine whether conversion events have no preceding scroll or dwell time.
• Compare your Google Ads or Meta spend against expected click patterns.

BotRefund offers a free bot audit that analyzes these signals and provides video proof for each bot click. With that evidence, you can file refund claims with Google and Meta for invalid clicks dating back to 2017.

Limitations and when the check does not apply

The CPU Concurrency Lie check will not catch every bot. Bots that run on real user devices via malware (e.g., clickjacking or residential proxies) may have genuine CPU concurrency because they are using the user's actual browser. Also, reputable privacy tools, corporate VPNs, and low-powered devices can produce anomalies for humans.

The check works best against headless browsers and virtual machines used by commercial botnets. It is unreliable when applied to mobile devices with aggressively power-saving CPUs, where timings are throttled regardless of concurrency tricks. In those cases, the false-positive rate rises, so BotRefund's cross-checking becomes essential.

Key facts

FAQ

Why do bots use CPU concurrency tricks at all?

Bots try to simulate human-like delays to avoid simple rate-limit rules. By adding concurrent tasks or artificial threading, they attempt to make their execution look irregular and busy, much like a person multitasking in the browser.

Can a bot fake real CPU concurrency perfectly?

No, not perfectly. Even with advanced emulation, the OS-level scheduling from a real browser session includes random jitter caused by background processes, power management, and hardware interrupts. Reproducing that accurately inside a virtual machine or headless browser is cost-prohibitive for most bot operators.

What happens if the check flags a false positive?

BotRefund treats the anomaly as evidence, not a verdict. It cross-checks other signals before making a decision, which reduces false positives. A privacy extension or corporate network might trigger the CPU check, but it will usually be overridden by matching behavior from a real user.

How does BotRefund use the CPU check in refund disputes?

BotRefund packages the concurrency signal along with video evidence and other behavioral flags into an audit-ready report. That report is submitted to Google or Meta as proof of invalid traffic, which supports refund claims for ad spend.

Does the CPU check work on mobile devices?

It is less reliable on mobile, because power-saving features throttle CPU timings in unpredictable ways. The check is mainly effective for desktop browsers and server-side bot emulation.

How many signals are needed before a bot is blocked?

There is no fixed number. The prediction AI weighs the whole pattern, so a very strong concurrency mismatch combined with zero mouse movement and superhuman input speed may block a bot with just a few signals. A weak anomaly alone will not trigger a block.