Lion Cipher Lab

Vote across sampled reasoning paths with self-consistency and find where more samples stop helping

Why it matters

Self-consistency is one of the cheapest reliability tricks for language models: ask the same question several times with sampling switched on, let each run reason its own way to an answer, and take the majority. It works, and the reason it works is easy to forget - the runs have to make DIFFERENT mistakes. This lab measures both halves on 800 answer-keyed alerts and a stub reasoner whose behaviour is written down. Voting lifted easy alerts from 0.835 to 0.995 and moderate ones from 0.695 to 0.925. But on one family of alerts - remote-management tools with a valid signature, a real abuse…

What you'll learn

Steps in this lab

  1. The words first: reasoning paths, sampling, self-consistency, agreement, and the difference between errors that cancel and errors that do not - and the fact that the reasoner here is a stub
  2. Open a terminal and make a scratch folder (Windows, macOS, Linux)
  3. Build 800 answer-keyed alerts: three difficulty bands and one family with a planted blind spot
  4. Write the STUB reasoner: one sampled path, a vote, agreement, and the shared bias written down in full
  5. Sweep N: accuracy and token cost at 1, 3, 5, 9, 15 and 25 sampled paths
  6. Read the curve: big gains where errors are independent, saturation, and where the knee is
  7. The honest negative: on the shared-bias family, more votes made it worse - and more confident
  8. Use agreement as a free uncertainty signal: escalate low-agreement alerts to a human
  9. Adaptive sampling: stop early when the paths already agree, and see where the savings come from
  10. Prove where the failure came from: set the shared bias to zero and re-run
  11. Why this, not that: voting versus one longer chain, a debate, or a different model
  12. When NOT to use self-consistency
  13. The way a pro does it differently, and what to ship

Open the full interactive lab →