Recording a terminal is the easy part — every tool here does it. Getting a legible, vertical, still-correct-in-six-weeks demo out the other end is where most of them stop helping. Here's what each is actually for, and where a typed terminal beats recording one.
"Terminal recording tool" turns up a real zoo of options — asciinema, VHS, terminalizer, ttystudio, the built-in `script` command, or just hitting record in OBS. They don't all do the same job, and the differences matter more once you're trying to turn the result into a 60-second vertical Short instead of a GIF for a README. This is what each one is actually for, where they agree, and the one wall every single one of them hits the moment the target is social video instead of documentation.
Before comparing tools, it helps to sort them by what they actually capture, because "terminal recording" quietly covers three different things:
All three produce something you could call a terminal recording. Only one of those three categories is built around the idea that the output should be reproducible — which turns out to be the property that matters most once you're publishing, not just demoing to a teammate over a call.
asciinema records a real terminal session as a compact text file — a timestamped log of the bytes your shell printed — not a video. That's a genuinely good design for its actual use case: the file is tiny, it's copy-paste-able, it plays back crisply at any size because it's replaying characters, not pixels, and you can embed it in a README or a docs site with the official player. If your goal is "let someone watch this command run inside my documentation," asciinema is hard to beat.
It's the wrong tool the moment your target is a vertical Short on YouTube or Instagram, though, for a boring reason: it doesn't export a video file at all. Getting an MP4 or GIF out of an asciicast means a second conversion step through another tool, and what comes out is still shaped like the terminal window you recorded in — usually wide, sized for a desktop, not reflowed for a 9:16 phone frame. You're solving the recording problem and still starting the video problem from zero.
Charm's VHS is the clean example of the second job: instead of recording a live session, you write a small `.tape` script — type this, wait this long, press enter, sleep, screenshot — and VHS drives a real terminal emulator through those exact instructions headlessly, then renders the result to GIF, MP4, or WebM. The output is deterministic: run the same tape twice and you get the same frames twice, because nothing about it depends on how fast your network or your machine happened to be that day. That single property — reproducibility — is what separates this camp from asciinema and plain screen capture, and it's also the closest any of these tools get to the idea a typed terminal takes further: the recording is really a script, and the script is the thing you actually edit.
It still hits the same wall as everything else here, though: the frame is a literal terminal emulator window, typically landscape, themed like a desktop terminal. Reflowing that for a phone screen, or restyling it to match a brand palette, means fighting the renderer's config rather than just changing a component's props.
A cluster of tools — terminalizer and ttystudio are the well-known ones — sit between the two camps above: they record a real session like asciinema does, then render that session out to an animated GIF through a headless browser, with configurable window chrome and color themes. They're a reasonable middle ground if you want a nicer-looking embeddable GIF than the raw asciicast player gives you, and the theming options are genuinely useful for matching a project's brand. What they don't solve is the same thing asciinema doesn't solve: the output is a recording of a specific terminal window, at that window's aspect ratio, and turning it into a legible vertical Short is a second project, not a checkbox in these tools.
Worth naming honestly, because it's what most people actually reach for first: OBS, QuickTime, or any screen recorder pointed at a terminal window. It requires no new tool, no learning curve, and it captures exactly what you saw. It's also the worst of the four options for anything you intend to publish, for reasons that have nothing to do with terminals specifically — it captures your actual desktop resolution and theme, it's one take with no scripting, so a typo or a slow network call means a full re-record, and there's no reflow step at all: whatever aspect ratio your terminal window happened to be is the aspect ratio you're stuck cropping later.
Every tool above, however good, converges on the same result: a rectangle of pixels showing a terminal at whatever size and shape it was recorded at. That's fine for a README or a docs page, embedded at whatever width the page gives it. It stops being fine the moment the destination is a phone screen, for three concrete reasons:
This is the thing our own terminal demo maker does differently, and it's worth being explicit that it's solving a narrower problem than the tools above, not a superset of it. It isn't a session recorder at all — you write the command and the output as text, and the scene types both out on a real 9:16 canvas sized for a phone from the start. There's no live shell underneath it, so there's nothing to leak: no stray output, no flaky network call, no fifteenth take because a package registry was slow. And because the command and its output are just text in a scene — the same layered, editable model the rest of the studio uses — fixing a wrong flag or updating a renamed command is a text edit and a re-render, not a re-take.
The honest tradeoff: you're not recording a real session, so this only works when you already know what the terminal should show — which is true for almost every planned demo (you know the install command, you know the expected output) and false for the cases these other tools genuinely own, covered below.
Take the shape from our README-to-Short post: a CLI's quickstart is one install line and one command that proves the tool works. As a typed scene, that's two beats:
$ npm install -g yourtool
✓ installed yourtool@2.4.0
$ yourtool watch ./logs
▸ tailing 3 sources · press q to stopWritten out like that, it's not a transcript of something that happened — it's the *intended* output, exactly as clean as the real thing looks on a good day, minus the progress bars, the occasional warning, and the six seconds of install time nobody wants to sit through. That's the actual value of typing it: not that it's easier than recording (recording is often just as fast), but that what ends up on screen is the version of the command you'd want a stranger's first impression to be.
Symmetry requires saying where a typed terminal is the wrong tool. If the point of the video is proof that something really happened — a benchmark run, a live deploy, an interactive TUI a viewer needs to see actually respond to keystrokes — a scripted or recorded session is doing real work a typed scene can't fake, and shouldn't try to. VHS in particular is a genuinely good fit for a project's own README GIF, where reproducibility matters (CI can regenerate it on every release) and the audience is already reading docs, not scrolling a feed. And if you're demoing a REPL, a debugger, or anything where the interesting part is the back-and-forth rather than a fixed sequence, none of the typed-terminal approach's advantages apply — you need the real thing.
A short checklist, roughly in the order these questions actually resolve the choice:
If you've got a CLI and a README, the fastest way to see the difference is to point the terminal demo maker at your actual install and quickstart commands and watch them typed out on a real vertical canvas — then decide whether that's the shape you wanted, or whether your case is one of the ones above where a real recording is still the right call. Either way, you'll know in about the time it takes to record one take.
Get one practical MCP-video tip when we publish the next post — no more than that.
Point your agent at a video pipeline that speaks MCP and make one small thing. Free founding-creator pilot — your keys, no watermarks.
Create your studio — free pilot