clother turns provider switching into a launcher name

One install produces a launcher per provider

The design choice that makes Clother different from a config file is that selection happens in the command name. Installing it puts a set of clother prefixed commands on your PATH, so moving between your own subscription, Z.AI, Kimi, MiniMax or a local backend is typing clother-native instead of clother-zai rather than editing environment variables, endpoints and launcher scripts. Under Homebrew the formula drops every launcher directly into $(brew --prefix)/bin, so they are usable the moment the install finishes with no further setup, and brew upgrade clother is enough to keep the whole set current. The same idea appears in the maintenance commands: clother install creates or refreshes the symlinks, clother status reports on the installation, clother list shows the profiles you have, clother info takes a provider name and shows its details, and clother test checks connectivity. The plain clother command plus its subcommands handle configuration, so the pattern holds for both the one-shot launchers and the ongoing management surface. The problem being solved is stated plainly at the top: switching providers by hand means changing env vars, endpoints, models and launcher scripts, and Clother replaces all four with a different first word. Two flags show what the launchers pass through, since clother-zai --yolo skips permission prompts and clother-ollama --model qwen3-coder runs a local backend with a specific model. Removal is symmetric, with clother uninstall taking everything away, which matters more than usual given how many commands land on your PATH.

Two install routes with different update semantics

There are two supported routes and they do not behave identically afterwards. The Homebrew path is the recommended one on macOS:

# 1. Install Claude Code CLI
curl -fsSL https://claude.ai/install.sh | bash

# 2. Install Clother via tap
brew tap jolehuit/tap
brew install clother

# 3. Start using it
clother-native
clother-zai
clother-zai --yolo
clother-kimi
clother config

The curl path covers macOS and Linux and installs from a script in the repository:

# 1. Install Claude Code CLI
curl -fsSL https://claude.ai/install.sh | bash

# 2. Install Clother
curl -fsSL https://raw.githubusercontent.com/jolehuit/clother/main/scripts/install.sh | bash

# 3. Start using it
clother-native
clother-zai
clother-zai --yolo
clother-kimi
clother-ollama --model qwen3-coder
clother config

Both start by installing the Claude Code CLI itself, since Clother launches that binary rather than replacing it. The difference shows up at update time: clother update routes to brew upgrade clother when Homebrew is in charge, and downloads and installs the latest release for curl installs, refreshing the provider symlinks either way. Both routes finish the same way too, with clother config setting up the providers you intend to use, and the curl installer fetching from the main branch of the repository, so a fork needs its own URL changed.

Launchers land next to claude, or in a guessed directory

Where the commands end up is decided by a small piece of lookup logic, and this is the step most worth checking after install. By default Clother installs launchers into the same directory as your existing claude binary when claude is already on PATH. Failing that, macOS gets ~/bin and Linux gets ~/.local/bin, which the documentation names as the XDG standard location. If the directory it settles on is not on your PATH, clother install prints a warning naming the exact directory to add, so the failure mode is visible rather than a silent command not found, and it tells you where to add it instead of editing a shell profile for you. Both defaults can be overridden, either with the flag or with an environment variable:

# Using --bin-dir flag
curl -fsSL https://raw.githubusercontent.com/jolehuit/clother/main/scripts/install.sh | bash -s -- --bin-dir ~/.local/bin

# Using environment variable
export CLOTHER_BIN="$HOME/.local/bin"
curl -fsSL https://raw.githubusercontent.com/jolehuit/clother/main/scripts/install.sh | bash

The curl install also sets up resume compatibility for claude --resume, and Clother is explicit that claude --resume keeps working with Clother features after installation rather than being replaced by them.

Tier aliases and the [1m] suffix decide when compaction kicks in

Each launcher ships with a default model and a mapping from Claude Code's own tiers. The mapping covers opus, sonnet, haiku and fable, and each of those resolves to whatever the provider calls its equivalent, so a request for haiku does not arrive at Z.AI as a model name that provider has never heard of. The default for Z.AI is written as glm-5.3[1m] with haiku mapped to glm-5.3-flash[1m], and the MiniMax plan default is MiniMax-M3[1m]. You can override in two ways:

# One-time: pass --model through to Claude CLI
clother-zai --model glm-5.3-flash
clother-zai --model haiku

# Permanent: configure the provider and pick a different default
clother config zai

A concrete model ID pins every tier, while a tier alias resolves through the mapping, and clother info shows the resolved model and tiers so you can confirm which one you got. The [1m] suffix is the subtle part: it tells Claude Code the model has a 1M token context window and gets stripped before the model ID is sent, and without it Claude Code compacts sessions on a model it does not know at 200K tokens. The catalog applies the suffix wherever the provider documents that window.

bench reports time to first token and skips unconfigured providers

The benchmarking subcommand is the only part of the tool that measures anything, and it measures latency rather than quality:

clother bench
clother bench zai kimi
clother bench --prompt "Write a haiku"

With no arguments it hits every configured provider, named arguments narrow it, and the prompt is replaceable. Results come back sorted fastest first with two numbers per provider, time to first token and total response time, plus a short preview:

  Provider           Model                      TTFT    Total   Preview
  ──────────────────────────────────────────────────────────────────────────────
  kimi               k3-256k                    180ms    0.9s   "Hello!"
  zai                glm-5.3                    312ms    1.2s   "Hello!"
  deepseek           deepseek-flash             890ms    3.1s   "Hello!"

Two selection rules matter when you read that table. Only providers with a configured API key are included, so a profile you never set up silently does not appear and cannot be mistaken for a slow one. Local providers are skipped entirely, which means Ollama backends will never show up here however responsive they are. The preview column exists so you can confirm a fast provider returned real text rather than an empty body before you trust its position in the ranking. The sample values in the documentation are illustrative output rather than a measurement of anything.

Resume rewrites thinking blocks and puts the file back

Session resume is where the tool touches your data, and it is the one feature that modifies a Claude Code file. After a provider-launched session, Clother prints a provider-aware reopen command such as clother-kimi --resume with the session id, so the session comes back through the same provider that created it rather than through whatever is now your default. The documented behaviour to be aware of is the cross-provider case: when you resume a non-Claude session into native Claude, Clother temporarily sanitizes incompatible non-Claude thinking blocks for the duration of that single launch, and then restores the original session file afterwards. The command it prints for that is provider aware, for example clother-kimi --resume followed by the session id, so the session reopens through the provider that created it. That is a bounded edit, scoped to one launch and undone at the end, but it does mean a session file is written to during the run, so a read-only or concurrently edited session file is the case to watch.

The provider table is cut off after three cloud rows

The provider reference is where the documentation stops being useful, because the Cloud table is cut off partway. What survives is enough to show the shape of each entry. clother-native maps to Anthropic with Claude and takes your subscription as the credential rather than a key, which is why it is the one launcher that needs nothing configured. clother-zai is the Z.AI GLM Coding Plan with a default of glm-5.3[1m] and haiku mapped to glm-5.3-flash[1m], keyed from z.ai. clother-minimax is the MiniMax Token Plan defaulting to MiniMax-M3[1m], keyed from minimax.io. The opening claim is wider than those three rows: one install and one command pattern across Claude, Z.AI, Kimi, Alibaba, OpenRouter, local backends, China endpoints and many other Anthropic-compatible providers. Because every extra provider is another launcher and another row, the way to know what you can actually select is to read the table yourself or run clother list on your own install rather than trust a summary. The table of contents also promises Troubleshooting, VS Code Integration, Platform Support and Under the Hood sections whose contents are not visible here, so editor integration and platform limits are worth reading directly before you commit to a setup.

A Go module with a shell script and its own test at the root

The repository layout explains why the install route differs by platform. The module is github.com/jolehuit/clother requiring Go 1.23.0, with cmd, internal, scripts and docs directories, and the curl installer lives at scripts/install.sh, which is the URL the curl instructions point at. Alongside those, the root carries clother.sh and clother_sh_test.go, so the shell side of the project has its own test file next to the script rather than living only inside the Go tree. Other root entries are .github, .gitignore, LICENSE and README.md, on the main branch. Licensing is MIT with a single LICENSE file at the root. Release history shows steady patch level movement rather than feature drops: v3.0.11 on 2026-09-22, v3.0.10 on 2026-07-25 and v3.0.9 on 2026-03-28, with the last push landing on 2026-09-22 and the repository not archived. A tool that installs many binaries onto your PATH from a shell script is exactly the kind of project where having the script tested separately from the Go code is worth noticing.

Editorial conclusion

It fits a person or team that already runs Claude Code and pays for more than one provider, since the saving is not the models but never editing env vars and endpoints again. It does not fit anyone wanting a chat client, a routing layer with failover, or per-request model choice, because the unit of selection here is the whole process. Before you rely on it, confirm two things: which bin directory the launchers landed in, and what your provider's real context window is, since a missing [1m] suffix means Claude Code compacts at 200K tokens on a model it does not recognize.

Frequently asked questions

Official sources

1. Issues
2. jolehuit/clother on GitHub
3. License: MIT
4. README
5. Releases