How do real-time answer bots solve exam questions during the test?
How the pipeline works
The setup has three parts. A capture tool reads the exam: screen OCR, accessibility APIs, or a browser extension that extracts the question text and answer options from the page. A solver turns the question into an answer: a paid API call to a language model, a lookup against a harvested question bank, or a human solver on the other end of a chat for high-stakes exams. A delivery channel gets the answer to the test-taker: an overlay on a second monitor, a phone on the desk, or audio through an earpiece.
The whole loop runs in seconds for straightforward questions. Multiple-choice and short-answer formats are the easiest targets because the solver only needs to pick or produce a short string. The test-taker's job is reduced to transcribing answers at a plausible pace, which is why timing analysis matters more than answer correctness for detection.
Why it is hard to see
The cheating happens outside the exam's view. Lockdown browsers control the exam window, but the solver runs on a second device the proctoring software cannot see. Webcam proctoring watches the test-taker's face, but reading an answer off a phone held below the camera line looks like thinking. The exam platform sees a normal session: reasonable timing, no tab switches, no suspicious processes.
Question randomization helps but does not solve it. Solvers handle any question text they receive, so shuffling the order or pulling from a bank only slows the pipeline slightly. The defense has to move from watching the device to analyzing the session: answer timing, revision patterns, and performance discontinuities that do not match the test-taker's history.
The timing signatures
Real-time solving leaves timing traces. Answers arrive in bursts: a hard question answered as fast as an easy one, because the solver does not find hard questions hard. Pauses cluster around the solver's latency rather than the question's difficulty. And the test-taker rarely revises, because the delivered answer feels authoritative even when it is wrong.
Compare against the test-taker's own baseline. A student who struggled through practice modules and then answers the final exam's hardest section faster than its easiest section is not having a good day. Per-question timing relative to the individual's history is the most reliable signal, because it does not depend on knowing what the solver is.
What actually raises the cost
No single control stops real-time solving. The working stack is layered: question formats that resist quick lookup, like applied problems with unique figures instead of textbook multiple choice; per-question timing analysis against individual baselines; second-device detection through network and audio signals where the assessment setting allows it; and exam designs where the questions are generated per test-taker so harvested banks go stale.
The deeper fix is assessment design. Exams that measure what a solver can look up are exams that solvers will defeat. Performance tasks, oral defenses, and questions tied to the test-taker's own prior work raise the cost of cheating beyond what the pipeline can handle. Technology buys time; assessment design buys integrity.
Can lockdown browsers stop real-time answer bots?
Not on their own. Lockdown browsers control the exam device, but the solver usually runs on a second device outside their reach. They are one layer, useful against casual cheating and essential for session integrity, but they do not see the phone on the desk.
Does AI text detection catch solver-assisted answers?
Unreliably. The test-taker transcribes or paraphrases the delivered answer, and short exam answers carry too little signal for detectors to judge. Timing and behavior analysis are more dependable than trying to detect the answer's origin.