There are two teletypes on your screen and one keyboard between them. Type a line and both machines hammer out a reply at ten characters per second: all caps, 72 columns, paper rolling upward. One of them is running ELIZA, the 1966 program. The other is wired to a small modern language model running on three CPU cores of a cheap VPS. You don’t know which is which. When you think you do, you press a button and lock in your guess before the answer is shown.

That’s the whole product. It’s called 33talk, it runs in a browser, and you can play it right now at 33talk.buildx100.cc. I’d suggest doing that first, actually, because everything below is one long spoiler.

The obvious objection: surely you can tell. Ask both machines for a limerick about Kubernetes and the mystery dies in a single round. True, and it’s exactly what the teletype takes away. The Model 33 is a great equalizer. 72 columns. Uppercase only, because there is no lowercase on the type drum. No backspace; the carriage moves forward or it returns, those are the options. Ten characters a second, because that’s what 110 baud buys you. Under those constraints both parties are reduced to the same thing: short lines of shouted text, arriving slowly. The question stops being whether a 2026 model can write an essay. Of course it can, and at ten characters a second an essay is a punishment. The question becomes one I genuinely couldn’t answer before building this: is sixty years of progress still legible at twenty words a turn?

The README lists the rules that make the test fair. This post is about how each rule got there, which is mostly a list of my mistakes.

Everything leaks

Simulating the teletype turned out to be the easy half. The hard half was stopping the system from answering the question for you. A blind test is only as good as its blinding, and this machine wants to snitch.

Start with time. ELIZA runs entirely in the browser and answers in zero milliseconds, give or take zero. The model’s reply crosses a network and takes one to three seconds. If each machine printed when its own answer arrived, you’d win every round without reading a word. So neither prints until both replies have resolved. There’s a gate in the code, and it is the only path from a host to the paper. ELIZA finishes instantly, then waits, politely, for 2026 to catch up.

Then length. My first version had no system prompt at all, in the name of fairness, and the model answered a gentle Rogerian opener with 430 characters of perfectly even-handed essay. At ten characters a second, that’s forty-three seconds of printing. You could score the round from across the room. So both hosts now get the same one-line job description: you’re a therapist, reply in a single short sentence that invites them to say more, never advise, never list. What the prompt deliberately doesn’t contain is any mention of ELIZA, or 1966, or “sound old-fashioned.” That would turn this into an impersonation contest, which is a different and much less interesting experiment. It also says nothing about uppercase or ASCII, because I tried putting formatting rules in the prompt and a 0.6B model spends its entire attention budget on them and starts parroting your input back. Formatting is the code’s job.

My favorite tell was punctuation. Parse the 1966 DOCTOR script and count: across all 199 reply templates, ELIZA’s complete punctuation vocabulary is the apostrophe (34 of them), the comma (13), the dash (5), and a single period. Zero question marks. Not one, anywhere in the script. The most famous question-asking program in the history of computing never once typed a question mark. Its questions simply end: IN WHAT WAY. The model, meanwhile, closes nearly every sentence with one. That’s a one-character tell; you could win every round by glancing at the last glyph on each roll. So a shared post-processor now folds both hosts into the 1966 vocabulary. Double quotes become apostrophes, which is how ELIZA quotes anyway: WHY DO YOU SAY ‘AM’. Question marks and exclamation points become periods. And then trailing punctuation is stripped from everything, because 197 of the 199 templates end on a letter or a digit. The other two end on an apostrophe (WHY ‘NO’), so the apostrophe is spared.

Replies are also capped at twenty words, and that number is not taste. I logged ELIZA over a real conversation and its longest reply came out at nineteen. The templates top out at thirteen, but the engine splices your own words back into them, so real output runs well past what the script suggests. Twenty is ELIZA’s measured ceiling, plus one. The trimmer then spends the budget back to the last clean sentence or clause break rather than chopping at word twenty, because a mid-sentence amputation is a louder tell than the length it removes.

The bug that annoyed me most in the whole project lived right there, and it was, of all things, an em dash. I was folding em dashes and ordinary hyphens down to the same bare -, which quietly welded phrases like NOW-WHETHER into single words. The trimmer stopped seeing clause boundaries and one reply in four ended on an ugly hard cut. Putting the spaces back around dash punctuation took that to zero. It also happens to match the 1966 script, which typed its dashes spaced: NAMES - PLEASE CONTINUE.

And then the leak I actually shipped. ELIZA cannot fail; it’s local, it has no network to lose. The model can: timeouts, rate limits, a server that’s down. In the first version, when the model failed, its teletype printed an apology while ELIZA’s printed a normal reply, and it took me embarrassingly long to notice that the tell wasn’t the error text. It was which roll the error appeared on. One machine apologizing names the model outright. The fix is deliberately wasteful: if either host fails, both machines print the identical error line. A perfectly good ELIZA answer goes in the bin so that you learn nothing. Four tests pin this behavior now, including one asserting the paper looks the same no matter which side actually broke.

The tell I left in

There’s one tell I couldn’t fix, and eventually decided not to. Over twenty exchanges, ELIZA opens its replies 95% distinctly; 199 hand-written templates and cycling reply pointers will do that. The model manages 23%. One system prompt and a sampling distribution, and it falls into ruts almost immediately, opening turn after turn the same way.

I did try to close it properly, with measurements. I A/B’d the repetition penalties at sixty samples per arm, and higher penalties bought little or no diversity while costing real length. A method note, learned the expensive way: at temperature 0.9, a single ten-turn trial is pure noise. It lied to me three separate times, once showing a median improvement that shrank to a rounding error at n=60. Also, for a while I was tuning against lowercase test sentences when the machine sends uppercase. Same model, noticeably different behavior; every measurement before I fixed that was garbage. The honest conclusion was that this gap doesn’t close with sampling knobs. It closes with a bigger model, which I’m not shipping on three CPU cores.

So it stays, and I’ve made my peace with it, because it points the wrong way. Ask anyone which machine ought to repeat itself and they’ll say the old one. Here, the repetitive, wordier host is the 2026 one. Left in place, the gap makes the test harder rather than easier. And 95% distinct openings is, on its own, a rather remarkable score for a program written the year the Beatles released Revolver.

The ELIZA in the paper

Part of why that score is possible: the ELIZA people remember is not the ELIZA Weizenbaum published. If you’ve met one online, it was probably a keyword table with Math.random bolted on. The 1966 engine is better than its reputation. Keywords carry ranks, and the highest-ranked match wins, not the first one found. Reply lists cycle through a stored pointer, never randomly, which is why the original doesn’t repeat itself two turns running and why the random copies feel subtly wrong without your being able to say why. There’s a memory: things you say about MY get stashed and resurface later when nothing else matches, and that trick does a surprising amount of the illusion’s heavy lifting. Rules can decline a keyword and pass the turn down the stack. And I AM SAD becomes YOU ARE SAD before any rule ever sees it.

I didn’t transcribe any of this. The 436-line script from the CACM appendix is embedded in the source byte for byte, all 12,231 of them, and parsed at load time. Hand-converting it to JavaScript literals would have put 67 keywords and every rank at the mercy of my typing, and one wrong rank is invisible: ELIZA would just feel slightly off, forever, with nothing to point at. Instead a test asserts the embedded copy is byte-identical to the archived transcription. Another asserts that APOLIGIZE, misspelled exactly that way in the 1966 printing, is still misspelled. Fix the typo and the build fails. And npm test replays the famous conversation from pages 36 and 37 of the paper, the one that opens “Men are all alike” / IN WHAT WAY. Ten exchanges, exact match.

The museum half

It isn’t a full emulator. No paper tape, no serial backend; ttyemu and asr33emu already do that, better. The teletype here is the stage, not the show. But the stage I tried to keep honest, because every constraint of the machine is doing pedagogical work.

At column 72 the carriage doesn’t wrap. It stops, and every further character strikes on top of the last one; wrapping was always the host computer’s job, which is half the reason the shared post-processor exists at all. Carriage return takes real time, proportional to how far the head has to travel, which is why real hosts padded NULs after CR: anything sent while the head was still moving was simply lost. The bell rings at column 65 as a warning that you have seven characters left before things start smearing. And @ was never a key of its own. It’s SHIFT+P, which is where Ray Tomlinson found it in 1971 when he needed a character that appeared in nobody’s name. Type PASSWORD on either machine and both stop echoing, which is why your password doesn’t echo in a terminal today; there’s a small pile of these fossils in the README.

The sound is all synthesized live in the browser, no samples anywhere, and my favorite detail lives there: the two machines’ motors hum at 60 Hz and 60.4 Hz, so they beat against each other at 0.4 Hz, which is what two real machines sharing a bench sound like. Wear headphones and you can hear one fall silent while the other is still hammering. The motor defaults to off, though. A page that starts droning the moment it loads doesn’t read as a machine; it reads as a fault.

One deliberate limit: the paper is never translated. The interface does English, Chinese and Japanese, but the type drum carries 64 uppercase ASCII glyphs and physically cannot print anything else. The language buttons change the chrome only, and the help dialog says so in all three languages.

Engine-room notes

The model is qwen3-0.6B under llama-server, in a container that publishes no ports; the only way in is an nginx allowlist of exactly two endpoints, rate-limited to twenty requests a minute. That sounds strict until you notice a human at ten characters a second physically can’t submit more than about six lines a minute anyway. The model is baked into the image, which is against all the usual advice, but a blind test without its model is nothing at all, and the whole thing still comes in at 555 MB. Lessons collected along the way: Docker inserts its firewall rules ahead of ufw, so a “firewalled” container port is in fact open to the internet, and not publishing the port is the only control that works. Debian slim wanted a newer glibc than it carries. And llama.cpp’s CPU kernels are loaded with dlopen, so a missing dependency fails nothing visibly; the check isn’t a log line, it’s tokens per second.

My favorite statistic of the whole project: the model generates about 100 tokens a second on those three cores. The paper prints at ten characters a second, call it 2.5 tokens. The paper is forty times slower than the model. This is the one project where a small, slow, CPU-only model isn’t a compromise. It’s period-correct.

33talk is Apache-2.0, at github.com/buildx100/33talk, and docker compose up --build is the entire deployment. The DOCTOR script itself is CC0: the original MAD-SLIP source was recovered from MIT’s archives and released with the agreement of Weizenbaum’s estate, which still strikes me as slightly miraculous. (”Teletype,” incidentally, is a trademark. Hence the name.)

It’s also part of buildx100, where I’m building a hundred apps in public with Claude Code doing most of the typing — which felt thematically appropriate here. A language model helped build the machine that asks whether you can spot one.

Go take the test. Then tell me your score, and more importantly, what gave it away. I’ve closed every leak I could find, which means whatever’s left is the interesting part.