twitch-tui and the case for reading chat without a browser

A chat client, and deliberately not a player

twitch-tui is described in one line: Twitch chat in the terminal.

The feature list is short enough to be a complete specification. You can read, send and search messages. You can switch channels. You can create and toggle filters. You get command, channel and mention suggestions. And you can customise the functionality and the appearance using a config file, with a default-config.toml in the repository root as the reference.

That last item is where the project puts its weight. A terminal client that hard-codes its keybindings and colours is a client for one person, but a client with a documented TOML file is a tool you can make your own, and the presence of a default-config.toml at the root rather than buried in documentation suggests the config is a first-class surface.

The scope boundary is worth stating plainly, because the README makes the point: combine this application with streamlink to rid the need of a browser while watching streams. So the intended arrangement is a terminal with the video in one pane and the chat in another, or the video handled by streamlink and the chat handled by this. If you came looking for a video player, this is the wrong project.

The audience is a developer who lives in a terminal, and the pairing with streamlink is the standard way to use it.

The dependency list tells you it is a real terminal application

The Cargo.toml is more informative than the README here, because the dependency list is the architecture.

The user interface is ratatui, and it is specified per platform: on non-Windows targets it pulls in the crossterm, serde and underline-color features, and on Windows it takes crossterm and serde only. That split is a small detail with a real consequence, since the underline-color feature is how the interface renders underlines, and Windows terminals handle those differently.

The networking is two libraries for two different jobs. tokio-tungstenite with native-tls is the WebSocket client, and reqwest with the json feature is the HTTP client. Chat arrives over a WebSocket while channel metadata and authentication go over plain HTTP, and the split between the two libraries reflects that.

Then there is the text handling stack: unicode-width for measuring, unicode-segmentation for grapheme clusters, textwrap for line breaking, and memchr for fast searching. For a chat client this is not over-engineering, because chat contains emoji, and rendering a message containing a multi-cell emoji in the wrong place is the single most visible bug such a program can have.

Input handling is rustyline, which gives line editing, history and completion, and fuzzy-matcher plus regex back the suggestion and search features.

The remaining entries are the ordinary Rust application furniture: clap for argument parsing with derive, serde and serde_json for config and API payloads, toml for the config file itself, chrono for timestamps, tracing and tracing-subscriber for logging, colour-eyre for error reporting, dialoguer for prompts, directories for config paths, webbrowser for opening links, and image, base64 and tempfile for handling emotes and avatars.

The binary is called twt, not twitch-tui

The Cargo.toml declares the package as twitch-tui but the binary block gives it a different name:

[[bin]]
bench = false
path = "src/main.rs"
name = "twt"

So the command you run is twt, not twitch-tui. The package name is what you use with cargo install, the binary name is what ends up on your PATH.

The package version is 3.0.0-alpha.4, the edition is 2024 and the minimum Rust version is 1.85.0. The licence is MIT OR Apache-2.0, with both LICENSE-APACHE and LICENSE-MIT in the repository root.

The alpha marker is the thing to weigh. The release history shows v3.0.0-alpha.4 from 2026-10-11, v3.0.0-alpha.3 from 2025-09-05 and v3.0.0-alpha.2 from 2025-08-09. The project says it follows the guidelines of Semantic Versioning, and it does, but a 3.0.0 alpha is pre-release by that scheme, which in practice means the interface and behaviour may still change between builds.

The repository, though, is not idle. The last push was on 2026-10-15, days after the alpha.4 tag, so work is landing on main while the tagged version stays in alpha.

Safety and reproducibility tooling in a chat client

Three directories in the repository root describe how the project is run rather than what it does.

The unsafe-forbidden badge points at the rust-secure-code safety-dance project, and the badge is styled as a success. That is a claim that the crate forbids unsafe Rust, which for a client that parses text from the internet and renders it in a terminal is a reasonable posture. The same directory holds deny.toml, the configuration for cargo-deny, which is the tool for checking dependency licences and advisories, so the project is checking its own dependency tree rather than trusting it.

There is a .pre-commit-config.yaml and a badge for pre-commit.ci, so formatting and linting run before a commit lands rather than in CI afterwards, and rustfmt.toml fixes the formatting rules. A flake.nix and flake.lock mean the project is reproducible through Nix, and a .devcontainer directory gives a consistent development environment. A .cargo/ directory at the root is where cargo configuration lives, which is where a project puts settings for offline builds, vendored sources or a shared target directory.

The book/ directory is the documentation, and the README links a documentation site and a setup page within it. Since the project is a TUI whose usability is entirely about keys and layout, documentation of that kind is not a nicety, and the fact that it is versioned alongside the source in the same repository is the right arrangement.

Where the browser-free arrangement breaks down

The limitations are honest ones.

The first is that a chat client without a player is a partial tool. The streamlink pairing works, but it means running two programs and managing two panes, and streamlink itself is a separate dependency with its own failure modes. If your workflow is a browser tab, this does not simplify it, it relocates it.

The second is the alpha line. Nothing in the repository suggests the 3.0.0 series has stabilised, and the release history shows long gaps between alpha builds, with roughly a year between alpha.3 and alpha.4. For a program people run casually that is tolerable. For anything scripted, a version number that moves in large steps and an interface that may change is a maintenance cost.

The third is what a terminal can and cannot show. A chat client has to render messages, which means wide characters, emoji, combining marks, links and the occasional emote image. The dependency set above shows the author thought about this, with unicode-width, unicode-segmentation, memchr and the image and base64 crates for emotes. But a terminal is a grid of cells, so a well-formatted client message is still not a rich client message, and there will always be chat formatting that does not survive the trip.

The fourth is that this talks to Twitch. The scope of the project is one platform, and the readme does not describe any other service.

Editorial conclusion

twitch-tui is a good fit for a developer who watches streams alongside a terminal and wants chat in the same place, especially when paired with streamlink, because the two together remove the browser from the watching loop entirely. It is a poor fit if you need the video as well, since this is a chat client and not a player, and a poor fit if you need a stable release, because the published versions are 3.0.0 alpha builds and the last tagged one is from October 2026. Before adopting, read the setup guide in the documentation book, and note that the crate is installed under a different binary name, twt, which is what you will actually type.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. Xithrius/twitch-tui on GitHub