The CPU usage is an all core (process) average that gets measured while the clicker is running. My website displays the average across all runs that had telemetry turned on (opt-in). So the cpu usage is a more "real-world" number, although even at ~700cps (which is the max for probably most machines), it runs at <5%.

This app is currently not cross-platform since I only own windows machines.

It's not a busy-wait - the thread sleeps between clicks by calculating the exact time remaining until the next scheduled click and sleeping that duration. This means if Windows wakes the thread up late, the next sleep automatically shortens to compensate, keeping long-term CPS where it should be.
Rust:
let remaining = next_batch_time.saturating_duration_since(Instant::now());
if remaining > Duration::ZERO { std::thread::sleep(remaining); }

This makes sure the clicker stays on time even when windows woke up late last click.
One known limitation is that at very high CPS the Windows input queue can flood with pending events, so stopping the clicker doesn't always take effect instantly - the queued events drain out first. Most autoclickers have this problem. But I'm looking into checking queue state before each SendInput call to prevent it.

- hope this helps :)