Randomness Lab

Tap left and right at random. The oracle commits a guess before each press and catches ~70%. The goal: push it back to 50%, where it cannot read you at all.

hit rate pure guessing = 50% ↖ lower is better
Memory -gram
Taps 0
Lowest

Why can't you be random? Because "trying" is itself a pattern. When deliberately generating randomness, people do two consistent things: they switch sides too often (a fair coin switches 50% of the time; humans exceed 70%), and they avoid runs longer than three or four. The oracle just counts which side you prefer after each short context. The harder you try to fool it, the better it gets — because the strategy of "fool it" is itself a pattern.

The good news: you can verify everything. Open the model panel to see the live probability table. The current context row is highlighted — you can derive the oracle's next guess before you tap, then tap the other side, confirming it is not peeking. If you keep beating it that way, your "always flip" strategy itself becomes a pattern, the hit rate falls to 0% and stays there. Not a bug you found — the blind spot of any counting model: it bets its counts, you invert its counts, it never catches up. Which is why 0% does not mean you were random; it means you were the oracle's mirror. To measure yourself, close the panel.

This game has an ending, and the ending is real. A first run usually lands around 70%. Once you know to let your runs get longer it tends to drop into the low 60s. Going lower means fighting your own urge to switch, tap by tap — that is the thing this tool actually trains. When a run is long enough to prove it (roughly four hundred taps), the screen tells you that you pushed the oracle back to the chance line. 50% is the ceiling, not a fault: a model that only counts has nothing to find in input that has no pattern. Your own runs stay on screen, and no population figure is printed anywhere — the only honest comparison is your last run.

The oracle is a 5-gram model, doing the same job a language model does when it predicts the next token. The differences are context length (5 taps here vs tens of thousands of tokens for GPT-4) and parameter count. So what you feel in your thumb — it reads context, bets the next step — is exactly what an AI does, just at a wildly different scale. To see how tokens are actually cut, visit token-visualizer.

Quick guide

Use cases, answers, and nearby tools

Compact below-tool notes that help first-run users and repeated visitors move faster without changing the main interface.

Chinese search: 隨機、亂數、隨機實驗、人類無法隨機、電腦猜你下一步、預測下一步、真隨機 假隨機、下一個 token

How to use

Run a clean first pass

  1. Two big pads — left and right. Tap them as randomly as you can. Before each tap, the oracle already committed a guess; the tape inks the result the moment you press.
  2. After 100 predicted taps, your run counts toward your personal best and the oracle quotes the pattern it exploited — for example, 'After L→R→L you tap R 71% of the time (17/24)'.
  3. Suspicious it's peeking? Open the model panel — the live probability table is right there. Compute its next guess yourself before you tap. Switch to recognition mode to try spotting which of two sequences is genuinely crypto-random.

Examples

Real jobs this page helps with

  • The oracle catches ~70%Most people land between 65–75%. The randomness you produce has more structure than you think: humans avoid long runs and switch sides too often. The oracle learns your habit in a few dozen taps.
  • Recognition mode flips the intuitionGenuine crypto randomness clumps — it runs five in a row regularly. Most people pick the evenly-spread sequence as 'more random'. That is the fake one. The verdict shows both sequences' longest run and switch count.
  • It is doing what a language model doesThe oracle is a 5-gram model: read the last five taps, count which side follows most often, bet that side. A language model predicts the next token the same way — just at a wildly different scale of context and parameters.

FAQ

What people usually want to know

Is it peeking at my current tap?

No, and you can verify it without trusting us. Each prediction is a function only of your previous taps, and it is committed before you press — it is already written in the empty slot drawn ahead of the trace. Open the model panel to see the live probability table and current context, then compute the next guess yourself before tapping. The test suite also has an explicit purity assertion: flip step N and the prediction for step N must be byte-identical.

Why does trying harder to be random make it worse?

Because 'trying' is itself a pattern. When deliberately generating randomness, people do two consistent things: switch sides too often (a fair coin switches 50% of the time; humans exceed 70%) and avoid runs longer than three or four. The oracle just counts which side you prefer after each short context. The strategy of 'beat it' is itself a regularity it learns.

Why does the genuinely random sequence look less random?

Because true randomness clumps. Flip a fair coin 40 times and a run of five identical results is common — but it looks broken. The human-shaped fake is suspiciously even and short-runned, which matches people's intuition of what 'random' should look like. After a wrong answer the verdict shows both sequences' longest run and switch count.

What does this have to do with AI?

The oracle is a 5-gram model: read the preceding context, count which outcome follows most often, predict that. A language model predicts the next token the same way — context length and parameter count differ by orders of magnitude, but the shape of the job is identical. That is why it feels like it 'understands' you: prediction does not need understanding, only statistics. See token-visualizer for what a token actually is.

What is a good hit rate?

Lower is better — 50% would mean the oracle is guessing at pure chance and cannot predict you at all. No population norm or percentile is printed here: screen, mood, and tapping speed all shift the number, and the only honest comparison is yourself against yourself. A run must reach 100 predicted taps to count; otherwise a 3-tap 0% would trivially win every session.