AI coding agents have become part of everyday development, but the first step of installing them is often the painful one: connecting to the npm registry directly can be slow, and installing a CLI with many dependencies takes forever. Linxira's Config Hub compresses "switch the mirror, then install" into two commands. This article is the full walkthrough: why to switch the mirror first, what the six official packages are, and how to install the other terminal agents.
The intended reader is a developer who has installed the system and is setting up the development environment. Nothing in this process touches the system level — mirror configuration and CLI installation both happen in the user environment and can be undone or redone at any time. Even if you only want one of the agents, the mirror section is worth reading: it affects the speed of every npm install from then on.
All of these AI coding agents are distributed through npm, and the official registry npmjs.org is slow or unstable to reach directly from many regions — small packages are fine, but CLIs with large dependency trees like coding agents visibly slow down during install and can even time out. This is not a network bug; it is physical distance. Switching to a reachable mirror source first makes installation dramatically faster.
Linxira's approach is to let Config Hub pick the fastest source automatically, so you never compare mirrors by hand:
linxira-config mirror npm auto # automatically picks the fastest npm mirror (direct npmjs.org access is slow; run this first)This command measures latency and switches to the currently fastest npm source. It manages the npm ecosystem's mirrors; Arch mirrors (linxira-config mirror arch list) and PyPI mirrors (linxira-config mirror pip auto) work the same way, but this article only concerns the npm side.
For npm, a mirror switch is one configuration item: npm reads the registry setting to decide where packages come from, and Config Hub's auto mode measures latency for you and writes the best value. From then on every npm i -g, npm install, and npm update uses the mirror automatically — no per-project configuration. If your network situation changes and the mirror slows down, running auto again re-selects the best one.
What does "slow" actually look like without a mirror? For a small utility, a few seconds of latency is barely noticeable; for an agent CLI with hundreds of dependencies, the install can stall for minutes, retry, and occasionally fail partway, leaving a half-installed tree that npm i -g has to repair. The failure mode is not "one slow download" but "unreliable installs that interrupt your flow at the worst moment". Removing that class of failure is the concrete payoff of running the mirror command first.
After switching the mirror, each of the six AI coding agents installs with a single command (all official npm packages; run only the ones you need):
npm i -g @anthropic-ai/claude-code@latest # Claude Code
npm i -g @openai/codex@latest # Codex
npm i -g @google/gemini-cli@latest # Gemini CLI
npm i -g @xai-official/grok@latest # Grok Build
npm i -g opencode-ai@latest # OpenCode
npm i -g openclaw@latest # OpenClawOne by one (each with its install command in the block above):
Anthropic's official coding agent, built for conversational code modification directly in the terminal. The package is @anthropic-ai/claude-code, and using it typically requires an Anthropic account or API key. It fits developers already in the Claude ecosystem who want their coding assistant in the terminal.
OpenAI's official coding agent, package @openai/codex, aimed at terminal workflows and tied to OpenAI's account system. Like Claude Code, it solves "driving coding tasks with natural language outside the editor".
Google's official command-line agent, package @google/gemini-cli. As the official entry point to the Google ecosystem, it pairs with Google accounts and the Gemini service.
xAI's official CLI, package @xai-official/grok, bringing terminal coding capability within the xAI ecosystem.
The open-source terminal coding agent, package opencode-ai. Unlike the vendor agents above, it is not tied to one vendor's account and can talk to multiple model backends — a fit for users who want to choose their model provider.
The open-source CLI agent, package openclaw, likewise not bound to a vendor ecosystem, providing general-purpose terminal agent capability.
All six packages use the official npm package names from their respective vendors or projects — that matters: what runs in your terminal is vendor-distributed code, not a third-party forwarding script. Which ones to install and how many is entirely up to you; they do not depend on each other and none is required. Installing several is normal — different agents have different strengths, and having both a vendor agent and an open-source one lets you compare them on the same codebase; if one turns out unused, uninstalling it is as straightforward as installing it.
Putting the whole flow together in practice: open a terminal, run linxira-config mirror npm auto once, then run the install lines for whichever agents you actually use. That is the entire setup — no systemd units, no config files to edit, no PATH changes to make. npm's global installs place the binaries where the shell already looks for them, so after install the agent's command is available in the current and future terminals.
Beyond the npm ecosystem, two more terminal agents ship through official install scripts:
curl -fsSL https://hermes-agent.nousresearch.com/install.sh | bash; a mirror (res1.hermesagent.org.cn) is available for some network environments.curl -fsSL https://omp.sh/install | sh.The difference between the install-script model and the npm model is the trust model: npm packages are distributed under official package names with pinned versions; install scripts hand their contents directly to bash. Both are official channels, but if supply-chain detail matters to you, prefer the official npm packages.
Mirrors apply to these two as well: install.sh scripts usually handle their download source inside the script, and if downloads are slow, check the script output or documentation for a mirror parameter — Hermes's mirror is an example of exactly that handling. As a habit, checking the official documentation for the currently recommended install method is far safer than searching the web for an "accelerated" script.
A note on the @latest tag in every install line: it means "the newest published version", which is what you want for a first install of these rapidly evolving agents. It is also worth knowing that a later npm update -g refreshes all of them through the configured mirror, so keeping agents current stays a single command even after you have installed several.
When would you pick a script-installed agent over the npm ones? Mainly when the tool's own distribution is script-based by design — Hermes and Pi / OMP are shipped that way by their projects, so the script is the official channel, not a shortcut. The deciding factor is not "script vs npm" in the abstract but "what does the project itself distribute": if the project's official install is an npm package, use npm; if it is an install script, the script is the source of truth. Either way, get the URL from the project's own documentation.
A few usage reminders:
npm update -g reuses the configured source.This flow comes from step 6 of the quick start guide; after installing the system, walk through the document in order and the signed repository, system updates, and these toolchains are all in place.
A practical heuristic for choosing: if you already pay for one vendor's service, start with that vendor's agent — it will be the most integrated with the account and API you already have. If you are model-agnostic or self-host, start with the open-source ones, which let you point at whatever backend you choose. The ecosystem around an agent — plugins, editor integrations, documentation quality — often matters more than the agent's headline feature, and it is only visible after a few days of real use.
One last suggestion: when you first use an agent, start from its official documentation rather than from tutorial articles — official docs state the currently supported authentication methods and configuration options, while tutorials tend to lag. The mirror solves "can I install it"; "will I use it well" depends on whether the agent matches your workflow: install one of each, try them, then decide what to keep — the cost is a few commands.