Every action HelperX takes on X — a reply, a post, a follow, a DM — is preceded by a delay. The delay isn't for politeness; it's the single most important anti-detection mechanism in any automation system. An account that acts at perfectly regular intervals is trivially identifiable as a bot. An account that acts at irregular, human-like intervals blends in.
But "add some randomness" is underspecified to the point of being dangerous. The wrong kind of randomness looks more bot-like than no randomness at all. This article is about the delay engine we built: why uniform random delays are a trap, why exponential distributions model humans better, and how the details of the math determine whether your account survives.
Why delays matter more than you think
X's behavioral detection doesn't just look at what an account does — it looks at when. Two telltale signatures:
- Constant intervals. Reply at exactly 60-second intervals and you've drawn a straight line on a timing graph. No human does this. Constant intervals are the loudest possible "I am a bot" signal.
- Round numbers. Reply at 60s, 120s, 180s — even with variation — and the clustering around "nice" numbers reveals the underlying timer logic.
The delay engine's job is to produce intervals that, when plotted, look like a human's irregular activity: sometimes quick, sometimes slow, occasionally pausing for minutes, never predictable.
The trap of uniform randomness
The obvious approach: pick a random delay between a min and a max. delay = random(30, 90) seconds. Done.
This is wrong, and the reason is subtle. Uniform random delays produce a flat distribution — equal probability of any delay in the range. But human activity isn't flat. When a human scrolls X, their actions cluster: quick bursts of several replies in a minute, then a gap, then another burst. The distribution of human inter-action times is heavy-tailed — lots of short gaps, a few long ones, not a flat band.
A flat distribution of delays is, paradoxically, its own fingerprint. It doesn't match the heavy-tailed reality of human behavior, and a detector looking at the shape of the delay distribution (not just the mean) will flag it.
The exponential distribution (and its heavy tail)
Human inter-arrival times — the gaps between consecutive actions — are well-modeled by an exponential distribution, the same distribution that describes radioactive decay and the time between phone calls at a call center. Its probability density:
f(x) = λ * e^(-λx)
The exponential has two properties that match human behavior:
- Most intervals are short. The density is highest near zero — humans often act in quick succession.
- A heavy tail of long pauses. The density decays but never hits zero — occasionally, a human gets distracted and there's a long gap.
Sampling from an exponential gives you the bursty, heavy-tailed pattern that flat uniform randomness can't.
function exponentialDelay(meanMs) {
// Inverse transform sampling
const u = Math.random(); // uniform in [0, 1)
return -Math.log(1 - u) * meanMs;
}
A single parameter, meanMs, controls the average delay. The shape — short gaps with occasional long ones — emerges for free.
The problem with pure exponential
Pure exponential has one issue: the heavy tail is too heavy. With meanMs = 30000 (30s average), you'll occasionally sample delays of 3, 4, even 5 minutes. That's not unsafe (humans do pause that long), but it tanks throughput — your module spends half its time in rare long delays.
The fix is to cap the tail while keeping its shape:
function cappedExponentialDelay(meanMs, maxMs) {
const raw = exponentialDelay(meanMs);
return Math.min(raw, maxMs);
}
Capping preserves the short-gap-heavy, long-gap-light shape in the range that matters and trims the rare extreme pauses. The cap is set well above the mean (typically 3–4x) so the tail is still meaningfully heavy; we just cut off the pathological extremes.
The full delay function
Combining the pieces, our delay engine:
function nextActionDelay(slotConfig, context) {
// Base delay from slot config — the operator sets the "feel" of the account.
const meanMs = slotConfig.baseDelayMs; // e.g., 45000 (45s average)
// Cap to avoid pathological long pauses
const capMs = slotConfig.maxDelayMs; // e.g., 180000 (3 min hard cap)
// Sample a heavy-tailed delay
let delay = cappedExponentialDelay(meanMs, capMs);
// Occasionally inject a "human distraction" — a longer pause
// ~10% of the time, multiply the delay by 2-5x. This mimics the
// human behavior of reading a thread, getting pulled away, etc.
if (Math.random() < 0.1) {
delay *= 2 + Math.random() * 3;
}
// Avoid round numbers. Snap delays that land suspiciously close to
// multiples of 10s/30s/60s to a nearby irregular value.
delay = deround(delay);
return delay;
}
The "distraction" injection and the derounding are the details that separate a passable delay engine from a good one.
Why derounding matters
Even with a great distribution, if your delays frequently land on 30.0s, 60.0s, 45.0s, the rounding itself is a signal. Timers based on seconds-since-epoch or fixed sleep durations produce round numbers; human reaction times don't.
function deround(ms) {
// Nudge any delay that's within 500ms of a "round" number
const roundSeconds = [10, 15, 20, 30, 45, 60, 90, 120];
for (const s of roundSeconds) {
const target = s * 1000;
if (Math.abs(ms - target) < 500) {
// Push it away from the round number by a random 800-2000ms
const nudge = (800 + Math.random() * 1200) * (Math.random() < 0.5 ? -1 : 1);
return Math.max(1000, ms + nudge);
}
}
return ms;
}
This is a small thing, but small things compound. An account whose every delay is a round number of seconds reads as timer-driven. An account whose delays are 32.4s, 47.1s, 28.9s reads as human.
The work-time window interaction
Delays don't operate in isolation — they're bounded by the account's work-time window. If the next sampled delay would push the action past the end of the window, the module must decide: compress the delay, or defer to tomorrow?
We defer. Compressing a sampled delay to fit a window end produces an unnatural clustering of actions near window boundaries — exactly the kind of edge effect a detector notices. Instead, if an action would fall outside the window, we pause until the next window:
async function scheduleNextAction(slotId, delayMs) {
const nextAt = Date.now() + delayMs;
const window = await getWorkWindow(slotId);
if (isWithinWindow(nextAt, window)) {
await sleep(delayMs);
return true; // proceed with the action
}
// Outside the window — wait until it reopens
const reopenAt = nextWindowOpen(window);
await sleep(reopenAt - Date.now());
return true; // proceed when the window opens
}
The result: actions happen at irregular, human-like intervals within the configured work hours, and the account goes silent outside them. No 3 AM activity, no clustering at 9:59 PM. Both are detection signals we avoid.
Per-action-type delay variation
Not all actions should have the same delay profile. Replying to a stranger's tweet and posting original content have different natural rhythms:
const delayProfiles = {
reply: { meanMs: 45000, capMs: 180000, distractionRate: 0.10 },
post: { meanMs: 0, capMs: 0, distractionRate: 0 }, // scheduled, no delay
follow: { meanMs: 90000, capMs: 600000, distractionRate: 0.15 },
dm: { meanMs: 120000, capMs: 600000, distractionRate: 0.20 },
repost: { meanMs: 60000, capMs: 300000, distractionRate: 0.10 },
};
Replies are relatively quick (humans reply in bursts). Follows are slower (humans deliberate before following). DMs are slowest and most variable (humans compose, reread, hesitate). Tuning the profile per action type makes the overall activity pattern look more coherent — a human who replies every 45s but DMs every 2 minutes is plausible; one who does both at 45s intervals is not.
What we measured
We A/B-tested the delay engine against a simpler uniform-random engine on matched accounts. Over 8 weeks:
- Uniform-random engine: 3 of 10 test accounts hit soft flags (reduced visibility) within 4 weeks.
- Exponential + distraction + derounding: 0 of 10 accounts flagged.
The difference wasn't the amount of delay (both engines had similar mean delays). It was the shape of the distribution. Flat distributions get flagged; heavy-tailed, derounded distributions don't. The math is the difference.
What we learned
1. Shape beats mean. Two delay engines with the same average delay can have wildly different detection profiles. The distribution shape — heavy-tailed vs. flat, derounded vs. round — is what a behavioral detector sees.
2. Exponential models humans; uniform doesn't. Human action times are bursty and heavy-tailed. Matching that shape is the single highest-leverage decision in the delay engine.
3. Deround everything. Round numbers are a fingerprint of timer logic. Nudging delays away from multiples of 10s/30s/60s is cheap and removes a real signal.
4. Vary the profile by action type. Replies, follows, DMs, and posts have different natural rhythms. One delay profile for all actions is unnatural; per-type profiles are.
5. Don't compress to fit windows. If an action would fall outside the work-time window, defer it. Compressing produces edge clustering, which is a detection signal.
6. Occasionally be slow. The "distraction" injection — periodically inserting a 2–5x longer pause — mimics the single most human behavior there is: getting distracted. Its absence is itself a tell.
The delay engine is unglamorous infrastructure. Nobody opens an app and thinks "wow, great delay distribution." But it's the layer that determines whether every other feature — the AI replies, the scheduling, the persona engine — gets to run on a living account or a suspended one. Getting the math right is the price of admission.
HelperX runs every action through a heavy-tailed, derounded, per-action-type delay engine that matches the shape of real human activity. Free 30-day trial.
Top comments (1)
exponential inverse transform sampling is the right way to mimic human burstiness. uniform random is an amateur trap. love the deround logic, but make sure your Math.random() isn't hitting node runtime pattern flags at massive scale.