Terminal sessions as text event logs, and scripted demo tapes.
asciinema.org ↗repo ↗docs ↗asciinema 3.0 announcement ↗asciinema player API ↗asciinema-player repo ↗asciinema-server repo ↗Charm VHS repo ↗terminal-mcp (records agent sessions to asciicast) ↗
Use asciicast as an export target and VHS-style tapes as a scripting idiom; scene's state-level time travel and take-over are what these byte recorders cannot do.
Complement it: it does a neighbouring job; interoperate.
These two tools are why terminal teaching material looks good. asciinema established, fifteen years ago, that a terminal session should be recorded as text events, not video: recordings are kilobytes, perfectly crisp at any size, copy-pasteable, searchable, and now an open JSON-lines spec with markers that a player can pause on and seek to, plus live streaming in 3.0. VHS made demos reproducible: a tape is a short declarative script you check into git, rerun on every release, and even use as a golden-file integration test via .ascii output. Together they cover recording real sessions and authoring ideal ones, both in formats an agent can read and write today without any special integration. If a terminal teaching story needs a recording format, asciicast is the obvious interchange standard rather than something to reinvent.
| UI as data | 4 scene 5 | Recordings (asciicast JSONL) and tapes are plain data, but they record bytes/keystrokes, not a UI model. |
|---|---|---|
| Agent can drive it | 2 scene 5 | Agent writes tapes or runs CLIs; no control of a live instance. |
| Agent can see it | 4 scene 5 | Complete structured event log and text frames, but after the fact. |
| Small, targeted edits | 2 scene 5 | |
| Time travel | 4 scene 0 | Agent can read whole history and seek by time/marker; no fork/replay-with-changes. |
| Live data rate | 3 scene 5 | asciinema stream relays live terminal output in real time; no numbers. |
| Terminal native | 5 scene 5 | |
| Pixel graphics | 2 scene 4 | VHS renders GIF/MP4 via a headless browser; asciinema player renders in browser; no in-terminal pixels. |
| Teaching | 4 scene 3 | Markers, pause-on-markers, selectable text; viewer cannot take over. |
| Maturity | 5 scene 1 | |
| Openness | 4 scene 4 | Open formats; asciinema CLI is GPL-3.0 (copyleft), VHS MIT, player/server Apache-2.0. |
asciinema + Charm VHS scene now scene planned
CLI and file formats. An agent can write a VHS tape and run `vhs demo.tape` (several Claude Code skills do exactly this), compare .ascii golden output, or run `asciinema rec` around a command and read the .cast JSONL. Third-party MCP terminals (e.g. terminal-mcp) record agent sessions to asciicast. No official MCP server for either.
Low: both are single binaries with text formats; VHS needs ttyd and ffmpeg.
Full: a .cast file is the complete event log (an agent can replay it through a VT parser to get any frame as text); VHS .txt/.ascii outputs give frame text, Screenshot gives PNG. Post hoc, not of a live UI.
Edit tape lines and re-render the whole demo; asciicast events can be edited as JSON lines. No live patching.
The recording is history: seek to time or marker via player API; no fork or branch.
Excellent at turning terminal activity into an open, agent-readable record or a scripted demo; neither controls a live UI.
asciinema records a PTY session as asciicast v3: newline-delimited JSON with a header (terminal size, theme, env, tags) and events [interval, code, data] where codes are o (output), i (input), m (marker), r (resize), x (exit). The player is a terminal emulator in the browser that replays the byte stream, so text stays selectable, and it exposes seek (to a time or marker), play/pause, getCurrentTime and marker/input events. asciinema 3 adds live streaming (local HTTP server or relay via asciinema server) with adaptive buffering, and servers can record streams. VHS instead runs a scripted 'tape' (Type, Enter, Sleep, Wait /regex/, Hide/Show, Screenshot, Source, Env, Require, Set Width/Rows/Cols/Theme) in a headless terminal (ttyd + browser) and writes GIF/MP4/WebM/PNG frames, or .txt/.ascii text output used as golden files for integration tests; `vhs record` turns a live session into a tape, and a built-in SSH server renders tapes remotely.
No published throughput or latency numbers for either tool.
asciinema is the de facto standard for sharing terminal sessions since 2011; VHS is the standard way to script reproducible terminal demo GIFs for READMEs.
Used by: Charm's own READMEs (VHS GIFs), Countless CLI project READMEs and docs (asciinema embeds)
Both mature and slow-moving by design; asciinema got a major Rust rewrite and live streaming in 3.0 (Sept 2025).
Releases: asciinema CLI: v3.0.0 2025-09-15, v3.0.1 2025-10-24, v3.1.0 2026-01-14, v3.2.0 2026-03-01, v3.2.1 2026-06-16. Player: v3.17.0 2026-06-30. VHS: v0.9.0 2025-01-15, v0.10.0 2025-06-17, v0.11.0 2026-03-10, v0.12.0 2026-09-09, v0.12.1 2026-09-24. · Contributors: asciinema CLI ~66; VHS ~63 (GitHub, incl. anonymous) · Recent: Since 2026-07-11: asciinema 7 commits, 0 merged PRs; VHS 10 commits, 8 merged PRs. · Bus factor: low for asciinema (one author); medium for VHS (Charm company, one main author).
Terminal-native recording and replay for teaching; scripted, deterministic demos; text readback of frames.
A replayable terminal recording format with markers and seek, and a scripted demo DSL; asciicast and VHS tapes already exist, are open and widely supported.
Semantic, state-level history: recording messages and serializable State (not bytes), so an agent can read state_at, diff, fork at the playhead and let a learner take over a live UI, including pixel layers; neither tool records UI state or allows take-over.
| 1–7 | home · features · use cases · docs · changelog · under the hood · blog |
| t | light or dark |
| j k | scroll |
| g G | top · bottom |
| ? Esc | this · close |