x-cli, a Rust rewrite whose repository still describes the Ruby tool it replaced

The repository metadata still describes the Ruby tool

Three pieces of repository level information disagree with the code. The description reads `A command-line power tool for Twitter`, the recorded primary language is Ruby, and the homepage is the documentation site of a tool named `t`. What is actually in the tree is Rust: `Cargo.toml`, `Cargo.lock`, `rust-toolchain.toml`, `src/`, `tests/`, and an `x-api/` path dependency, and a `legacy/` directory. The manifest describes the project as `Command-line interface for the X API` at version `6.0.0` on edition 2024, and the page underneath it agrees, opening with a single word as its title. So the code, the manifest and the page agree with each other, and the repository level fields are the ones left over.

The binary is named x while the homepage still serves t

The package, the library and the executable are all called `x`. The library entry points at `src/lib.rs` and the binary at `src/main.rs`, so the command you type is `x`, not `t` and not `x-cli`, even though the repository is named `x-cli`. The development commands confirm the shape:

cargo test
cargo run -- version
cargo run -- accounts --profile /path/to/.xrc

That last one is also the shape of a real invocation: `accounts` is a command, and `--profile` points at a config file rather than relying on the default location in your home directory. The homepage field is the remaining loose end, since it still resolves to the old tool's documentation site.

The release recipe is written down, and no release exists yet

The repository has no GitHub releases, while the manifest is at version `6.0.0` and the page documents the whole tagging procedure. Tagging a new `v*` release is said to trigger GitHub Actions to build binaries for six targets: Linux on x86_64 and aarch64, macOS on x86_64 and aarch64, and Windows on x86_64 and aarch64. The release metadata is in the manifest, where `publish` is `false`, so nothing goes to a registry, `tag-name` is `v{{version}}`, and `tag-message` is `Release {{tag_name}}`. A `pre-release-hook` fetches tags from `origin` first. Driving it needs one tool installed by hand:

cargo install cargo-release --locked

followed by `cargo release-tag`, which tags the version already in `Cargo.toml`.

Two API versions with automatic fallback, and two stream mechanisms

The page claims V1.1 and V2 API support with automatic fallback, which means a command can work against either generation without the caller choosing. Streaming is split rather than unified. `stream all` and `stream matrix` use the OAuth2 sample stream, while `stream search`, `stream users`, `stream list`, and `stream timeline` use V2 filtered stream rules plus the stream itself. Both are described as persistent HTTP streaming. There is one knob for it: `X_STREAM_MAX_EVENTS` limits how many events are emitted, and the page says that is useful for tests and automation. The command families themselves are `cli`, `delete`, `list`, `search`, `set`, and `stream`, plus the local ones.

~/.xrc is the config, with ~/.trc read once and migrated on write

The default profile is `~/.xrc`. When that file is missing, `~/.trc` is used as a read fallback and migrated on write, so an old profile from the previous tool keeps working for reads and is converted the first time anything is written. Config parsing goes through `serde_yaml_ng`, so the file is YAML. The development example passes an explicit path with `--profile /path/to/.xrc`, which is the way to test against a config that is not your own. Authentication supports both OAuth 1.0a and OAuth 2.0.

ruler appears in the status list with nothing said about it

The local command list is `accounts`, `set active`, `delete account`, `version`, and `ruler`. The first four explain themselves by name, and `version` is what the development section runs. `ruler` does not appear anywhere else on the page: not in the feature list, not in the command families, not in the examples. There is no sentence anywhere describing what it reads, what it writes, or which part of the account it touches. The same gap exists for the rest of the tree, since `man/`, `etc/`, `x-api/`, and `tmp/` all appear in the root listing while the page covers none of them, and the man pages in particular are not linked even though `clap_mangen` is a dev dependency and therefore the tool that would generate them.

Blocking HTTP plus a repo root that holds a tmp directory

The HTTP dependency is `reqwest` with the `blocking` feature enabled, while the streaming commands are described as persistent HTTP streaming. The path dependency `x-api` holds the HTTP, auth and retry primitives, including the automatic retry with backoff for transient API errors, and it is referenced by path rather than pulled from a registry. The root listing also carries a `tmp/` directory next to `src/`, `tests/`, and `legacy/`, which is an unusual thing to keep in version control and is not explained anywhere.

Editorial conclusion

This fits a developer who wants the X API from a terminal with OAuth 1.0a and 2.0 both available, YAML config, retries with backoff and streaming, and no runtime beyond a Rust toolchain. Before you rely on it, check three things. The recorded primary language is Ruby and the homepage is the old tool's docs, so do not trust the repository metadata over the manifest. There are no published releases, so there are no prebuilt binaries to download; the README's development commands build and run it from source with `cargo run`. And `~/.xrc` is the config to create, with `~/.trc` accepted only as a read fallback that gets migrated the moment anything is written.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. sferik/x-cli on GitHub