Model or dataset
jolehuit/clother avatar
jolehuit/clother

Clother: one CLI for switching Claude Code providers

Use multiple Claude Code–compatible LLM providers from one CLI, switching profiles instantly with simple clother-* commands.

430 stars44 forksGoMIT

At a glance

What is it?
Clother is a Go tool that installs a family of clother-* launchers so you can move between Anthropic, Z.AI, Kimi, Moonshot and other Anthropic-compatible endpoints without editing environment variables by hand. The install path is short; the provider coverage is the reason to look at it.
Who is it for?
Adopt Clother if you already run Claude Code and want to compare Anthropic-compatible providers from one command pattern instead of maintaining shell scripts per endpoint. Skip it if you only ever use the Anthropic subscription, or if you need Windows support, which the README does not claim.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 31 days ago.
What is it written in?
Mainly Go, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The problem Clother solves for Claude Code users

Claude Code reads its endpoint, model and credentials from environment variables and launcher arguments. Every additional Anthropic-compatible provider therefore means another set of exports, another wrapper script, and another place for a stale key to hide. Clother replaces that with a naming convention: one binary per provider, installed as clother-native, clother-zai, clother-kimi, clother-minimax, clother-moonshot and so on. The README frames the goal plainly, saying Clother gives you "one install and one command pattern across Claude, Z.AI, Kimi, Alibaba, OpenRouter, local backends, China endpoints, and many other Anthropic-compatible providers."

The audience is narrow but real. You need Claude Code already installed, and you need a reason to point it at something other than Anthropic: cost, latency, regional access, or a local model. If you fit that description, the tool removes a class of copy-paste mistakes. If you do not, it adds a layer you will never exercise.

How the launcher scheme and profiles fit together

Clother is a Go module (go.mod declares module github.com/jolehuit/clother on Go 1.23.0), and the repository splits into cmd/, internal/, scripts/ and a clother.sh entry point. The install step does not wrap Claude Code in a proxy. It places small launcher binaries next to your existing claude binary, or in ~/bin on macOS, or in ~/.local/bin on Linux, and each launcher sets the provider-specific environment before handing control to Claude Code.

Configuration lives behind clother config, which writes per-provider profiles holding the API key and the default model. The launcher resolves that profile at start time, so switching providers is a matter of invoking a different command rather than re-exporting variables. clother list shows the profiles you have, clother info <provider> shows the resolved model for one of them, and clother status reports where the installation actually landed. That last command matters because the default bin directory depends on what is already on PATH.

One detail worth noting: the README states that resuming a non-Claude session into native Claude makes Clother temporarily sanitize incompatible non-Claude thinking blocks for the duration of that single launch, then restore the original session file afterwards. That is a real compatibility shim, not a cosmetic feature, and it tells you the session format differences between providers are significant enough to need handling.

Installing Clother and running a first provider session

Homebrew is the recommended path on macOS. The README's sequence installs Claude Code first, then taps the repository, then runs a launcher. The formula installs every clother-* launcher into $(brew --prefix)/bin, so no extra setup step is required after the brew install finishes.

bash
curl -fsSL https://claude.ai/install.sh | bash
brew tap jolehuit/tap
brew install clother
clother-native
clother-zai
clother config

On macOS or Linux without Homebrew, the curl installer does the same work and additionally wires up resume compatibility for claude --resume. Note the local Ollama example in the same block, which passes a model through to Claude Code.

bash
curl -fsSL https://raw.githubusercontent.com/jolehuit/clother/main/scripts/install.sh | bash
clother-kimi
clother-ollama --model qwen3-coder
clother status

If the chosen bin directory is not on PATH, clother install prints a warning naming the exact directory to add. You can override the destination with the --bin-dir flag or the CLOTHER_BIN environment variable, and the README shows both forms.

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

After that, the useful first check is connectivity rather than a full session: clother test exercises the configured providers, and clother bench compares them. The README shows bench output with TTFT (time to first token) and total response time, sorted fastest first, and states that only providers with a configured API key are included while local providers are skipped. A missing provider in that table means a missing key, not a broken endpoint.

Where Clother stops being the right tool

The platform claim is macOS and Linux. The README's badge says exactly that, and no Windows installation path appears in the documentation. If your team develops on Windows, this is not a candidate.

Benchmarking has a documented blind spot. The README states that only providers with a configured API key are included and that local providers are skipped, so the latency table cannot be used to compare a local Ollama model against a hosted endpoint. If local model performance is the question you are trying to answer, clother bench will not answer it.

The resume shim is a second area to treat carefully. Sanitizing thinking blocks for a single launch and restoring the session file afterwards is a write-then-revert operation on your session data. The README does not document rollback if that process is interrupted, and it does not describe what happens when the same session is resumed repeatedly across providers. Test resume on a throwaway session before you depend on it for work you care about.

Finally, Clother is a launcher layer, not a router. It does not appear to fall back to another provider when one fails, and nothing in the README describes retry or failover behaviour. If you need that, you are looking at the wrong category of tool.

Clother compared with hand-rolled wrapper scripts

The obvious alternative is what most people do before finding a tool like this: a directory of shell scripts, one per provider, each exporting ANTHROPIC_BASE_URL and the matching key before calling claude. That approach is fully transparent, has no dependency to install, and works with any provider you can write a curl call for.

The difference is in what you maintain. A script directory has no shared notion of a profile, so the default model for a provider lives in whichever file you last edited. Clother centralises that in clother config and exposes it through clother info <provider>, and it keeps the provider list in one place rather than in your shell history. It also ships the resume compatibility layer, which is the part that is genuinely annoying to reproduce by hand, since it involves rewriting session files rather than setting variables.

The trade-off runs the other way too. A shell script is readable in ten seconds and debuggable with set -x. Clother is a compiled Go binary whose launchers you invoke by name, so when a provider misbehaves you are inspecting generated configuration rather than your own script. If your provider set is stable and small, the scripts may be the better engineering choice.

Maintenance, licence and upgrade cost

The repository is MIT licensed, which permits commercial and private use with the usual requirement to keep the licence notice. That is a permissive choice with no copyleft obligation on your own code. It says nothing about the terms of the providers you point Clother at, and those are separate agreements you accept when you create an API key with Z.AI, Kimi, Moonshot, MiniMax or anyone else.

The last push to the repository was on 2026-08-16, and the most recent release listed is v3.0.10 from 2026-07-25. The release cadence visible in the release list is uneven: v3.0.8 and v3.0.9 landed four days apart in March 2026, then v3.0.10 arrived in late July. Nothing here suggests abandonment, but the version numbering does suggest that provider-specific fixes arrive as point releases rather than on a schedule.

Upgrade cost is low by design. Under Homebrew, clother update routes to brew upgrade clother. For curl installs it downloads the latest release. Both paths refresh the provider symlinks, so a new provider added upstream shows up without manual symlink work. The main ongoing cost is not the upgrade itself but keeping provider keys valid, since a stale key simply drops that provider out of clother bench and clother test without an obvious error.

Editorial conclusion

Adopt Clother if you already run Claude Code and want to compare Anthropic-compatible providers from one command pattern instead of maintaining shell scripts per endpoint. Skip it if you only ever use the Anthropic subscription, or if you need Windows support, which the README does not claim. Before relying on it, run clother status to confirm where the launchers landed, then clother test and clother bench on the providers you actually pay for, because a provider with no configured API key is silently left out of the benchmark.

Frequently asked questions

Is "clothes" a correct spelling?

The README does not discuss English spelling; it presents Clother as the name of the CLI and of its clother-* launcher commands. The project's own description is that it lets you use multiple Claude Code-compatible LLM providers from one CLI.

What is a cloth?

The README does not define the word; the name Clother is used only as the project and command name. What the repository documents is provider switching for Claude Code, not textile terminology.

What is the difference between "clothe" and "clothes"?

The README says nothing about that distinction. Clother is the tool's name, and its documentation covers installing clother-* launchers and configuring providers such as Z.AI, Kimi, MiniMax and Moonshot.

Is it spelled cloths or clothes?

The README offers no guidance on that spelling question. It uses Clother only as the project name and as the prefix for launcher commands like clother-zai and clother-kimi.

Is clother a word?

The README does not treat Clother as an English word; it is the name of the CLI and of the clother-* commands it installs. The repository documents it as a way to use multiple Claude Code-compatible LLM providers from one CLI.

Is clother a Scrabble word?

The README does not address Scrabble validity. Clother appears there only as the project name, with installation via Homebrew or a curl script and configuration through clother config.

Official sources

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

Community notes