I turned Unix talk from 1983 into the interface for my AI by leaving the original talk client completely untouched and swapping out what answers on the other end. Instead of ringing a person logged into another terminal, the call now rings a small Python bridge that hands your typed line to a local model and streams the reply back into the same split screen, one character at a time, the way talk has worked since 4.2BSD shipped it. No new client, no browser tab, no chat bubbles — just the 1983 protocol pointed at a robot.
Short answer: Keep the real
talk/ntalkclient, but replace the daemon on the receiving end with a bridge that forwards each completed line to a local Ollama model and writes the streamed reply back onto the same TCP socket, one character at a time. The split-screen terminal is unchanged from 1983 — only what answers your ring is new.
I built this over a weekend after getting annoyed at how much chrome sits between me and an LLM's actual words — sidebars, model pickers, a send button I have to click. The talk command has none of that: two panes, a cursor, and text appearing as it's typed. In my testing, pointing that interface at a local Llama model instead of a coworker was closer to how BBS-era chat actually felt than any modern chat app I've used, and it forced me to read every character instead of skimming a wall of text that appears all at once.
What you'll need
A Linux box (I used a Debian 12 VM), root access, and the ntalk package, which installs both the talk client and the in.ntalkd daemon — on Debian/Ubuntu that's sudo apt install ntalk. You'll also need Ollama running locally with a small model already pulled; I used llama3.2:3b because it answers fast enough to keep the illusion of a live conversation. Python 3 with the standard socket and urllib modules is enough for the bridge script — no extra libraries required. Budget an hour if you've never touched inetd/xinetd service configs before, and know that this is a LAN or localhost project, not something to expose to the open internet.
Step-by-step: turning talk into an AI interface
1. Prove the 1983 protocol still works
Before changing anything, run the real thing. Open two terminals as two different local users and run talk user2@localhost from one, talk user1@localhost from the other. Accept the ring, and you'll see the classic split screen: your half on top, theirs on the bottom, both live-typed. If this doesn't work first, per IANA's own service registry talk listens on UDP port 517 and ntalk on UDP port 518 for the initial ring, then opens a separate TCP stream for the actual conversation — check sudo ss -lun for both ports before debugging anything else.
2. Stop routing the daemon to a login shell
in.ntalkd normally just opens the ring and hands the connection to whatever process the OS logs you into. Disable that in /etc/inetd.conf (or the xinetd equivalent) so the daemon stops auto-answering for a human account you're not using.
3. Write the bridge script
The bridge does three things: accepts the TCP stream in.ntalkd hands off after a successful ring, buffers incoming keystrokes into completed lines, and posts each line to Ollama's local API at http://localhost:11434/api/generate with "stream": true. I kept mine under 80 lines of plain Python — no framework needed.
4. Stream the reply back one character at a time
This is the part that makes it feel like 1983 instead of a modern chatbot. Rather than writing Ollama's response to the socket in one burst, write it character by character with a small delay (I used roughly 25ms per character). talk was built to show typing live, so writing the full answer instantly looks wrong on that screen — it reads like a fax, not a conversation.
5. Ring your own AI
From a second terminal, run talk ai@localhost. The bridge answers the ring the same way a person would, and your screen splits exactly like step 1. Type a question into your half and watch the model's answer crawl across the bottom half.
6. Tune the model for the medium
If the reply doesn't start appearing within a couple of seconds, the talk client just sits there with no "thinking" indicator — that's a protocol limitation, not a bug in your bridge. In my testing, llama3.2:3b started streaming its first characters in under two seconds on a mid-range laptop CPU; a 13B model I tried first took closer to nine seconds before the first token, which felt broken inside talk's silent screen.
Example prompts you can copy
These are close to what I actually typed into my own talk ai@localhost session while testing the bridge:
explain how the talk protocol handshake works in three sentenceswrite a bash one-liner that greps a log file for lines with a timestamp older than 1 hourwhat's a reasonable ollama model to run on 8gb of ramsummarize this paragraph in one sentence: [paste text]give me three follow-up questions I should ask about this topic: [paste topic]
Keep prompts short and self-contained. talk has no scrollback worth trusting and no way to paste a multi-paragraph block cleanly, so anything long is better composed elsewhere and pasted as a single line.
Common mistakes to avoid
The mistake that cost me the most time was leaving in.ntalkd bound to UFW's default-deny UDP rule — the ring never arrived and I spent twenty minutes debugging my Python code before checking sudo ufw status and finding ports 517/518 blocked the whole time. Second, I initially forwarded every keystroke to Ollama instead of buffering to a completed line, which meant the model tried to answer a half-typed sentence more than once. Third, don't pick the biggest model that fits your RAM — a slow first token inside talk's blank screen looks identical to a dead connection, and I hung up on my own bridge twice before I switched to a smaller model. Fourth, this protocol has zero authentication and predates any concept of encryption, so don't bind it to anything but localhost or a trusted LAN interface — a stranger who can reach your talk port can ring in exactly like a real person could in 1983. Fifth, remember talk only renders plain text; code blocks, markdown, and long numbered lists all come out as a flat wall of characters, so it's a poor fit for anything you'd want formatted.
Talk protocol vs. a modern AI interface
| Unix talk (1983) | ChatGPT/Claude web app | ollama run in a terminal |
|
|---|---|---|---|
| First released | 1983, with 4.2BSD | 2022–2023 | 2023 |
| Transport | UDP ring (ports 517/518) + raw TCP | HTTPS | Local loopback HTTP |
| Reply appears | Character by character, live | Token by token, rendered as words | Token by token |
| Account required | No | Yes for a saved account (free tier exists) | No |
| Works fully offline | Yes, with a local model behind it | No | Yes |
| Both sides visible while typing | Yes, split screen | No, turn-based | No |
| Setup effort | You write the bridge yourself | None | ollama run <model> |
Tools that make this easier
Ollama is the piece doing the actual thinking here, and running models locally is unlimited and free — the paid Ollama Cloud plans, starting at $20/month for the Pro tier, only cover their hosted cloud models, not anything running on your own hardware, per Ollama’s pricing page, checked August 26, 2026. The ntalk package itself is free and open source on every mainstream Linux distribution, and ytalk is worth trying if you want a version that already supports more than two parties instead of writing that yourself. If your machine can't comfortably run even a 3B model, my AI at home guide covers checking whether old hardware you already own clears the bar before you buy anything, and my free AI tools roundup and how to use ChatGPT for free guide are the faster path if you'd rather skip local hosting entirely. For picking which model to run behind the bridge, best AI models compares the current options side by side, and if you'd rather point this setup at coding questions specifically, best AI tool for code and how to use Claude AI both cover models that hold up well in a plain-text, no-formatting interface like this one.
My take
This is a novelty project, and I'd tell anyone building it not to expect a daily driver — no scrollback, no code formatting, no way to paste a long prompt cleanly. But it taught me something I didn't expect: forcing an AI's answer to appear at reading speed, on a screen designed in 1983 for two humans, changed how carefully I actually read it. I stopped skimming. If you want a weekend project that makes you understand both a 40-year-old protocol and how thin the "interface" layer of a modern chatbot really is, this is a good one. If you just want a fast, formatted answer, use a normal chat app instead.
Frequently Asked Questions
Is turning Unix talk into an AI interface free?
Yes. ntalk is free and open source on every mainstream Linux distribution, and running a model locally through Ollama is unlimited and free — you only pay if you choose Ollama's optional hosted cloud plans instead of your own hardware.
How long does it take to set this up?
About an hour if Ollama and a model are already installed: 15 minutes to confirm the real talk protocol works between two local accounts, and the rest to write and test the bridge script that answers the ring instead of a login shell.
What's the easiest way to do this?
Start with a small model like llama3.2:3b and a plain Python socket bridge rather than trying to reimplement the full talk protocol yourself — let the real in.ntalkd handle the ring/handshake, and only take over the TCP stream after the connection opens.
Is it safe to leave this running?
Not on the open internet. The talk protocol has no authentication and no encryption, so anything beyond localhost or a trusted LAN should stay firewalled off — a stranger who can reach the port can ring in exactly like a real person could in 1983.
Does this still work over the real internet the way talk did in the 1980s?
Technically, if you forward UDP 517/518 and the matching TCP port through your router, but most ISPs and firewalls block it by default now, and the complete lack of encryption makes that a bad idea regardless. Keep it local.