Grok CLI vs Grok Build: Two Agents, One `grok`

If you searched for Grok CLI you may have landed on either of two unrelated projects. Grok CLI is superagent-ai/grok-cli, a community agent that is explicitly not affiliated with xAI. Grok Build is xai-org/grok-build, xAI's own. Both install a binary named grok into $HOME/.grok/bin, so they overwrite each other. Their Linux ARM64 support is exactly inverted. Here is which one you actually want, and what breaks when you mix them up.

Which Grok is which?

The confusion is structural, not careless. The community project was created on 2025-07-14. xAI created theirs on 2026-07-14, exactly one year later, and named the command the same thing. Search results from 2026 mix the two freely, and a lot of tutorial content written for one silently applies the other's install instructions.

Every number below was read first-hand on 2026-07-20 with gh api, the npm registry, and HTTP probes against the published release assets. Star counts and versions on both projects move within days, so treat the date as part of the fact.

One shortcut that always works: if the install command starts with curl -fsSL https://x.ai/cli/, it is xAI's. If it starts with curl ... raw.githubusercontent.com/superagent-ai/ or bun add -g grok-dev, it is the community one.

The collision: same command, same directory

Both projects put a file called grok in $HOME/.grok/bin. Neither installer checks whether the other is already there. Install one after the other and the second silently replaces the first, leaving your shell history, your aliases, and your muscle memory pointing at a different program than you think.

Two checks disambiguate an existing install. grok --version on Grok Build prints a version plus a short commit hash, like 0.2.106 (ab5ebf69ac). The community CLI reports its npm version, 1.1.7. And ~/.grok/install.json is written only by the community project's install.sh.

If you want both, install one with its directory override rather than hoping. Grok Build honours GROK_BIN_DIR; Grok CLI's installer takes --binary <path> and --no-modify-path. We would rather rename one binary outright than keep two programs racing for the same six letters.

The ARM story is exactly backwards between them

This is the part that costs people an afternoon. The two projects have opposite ARM64 Linux support, so every sentence you read about "running grok on ARM" is correct for one and wrong for the other.

We probed every published release asset for both projects on 2026-07-20. The raw log, including the exact commands so you can re-run it, is committed here: the full architecture probe capture from 2026-07-20. The result:

Grok CLI's install.sh maps aarch64 to arm64 in its arch case, then downloads grok-linux-arm64, a file that does not exist. On Termux, which is aarch64, the documented install cannot finish. Note the reason carefully: the artifact was never published. This is not the glibc-versus-Bionic dynamic-linking problem that blocks other prebuilt CLIs, and borrowing that explanation would be wrong. Our Termux comparison covers where that distinction matters for other tools.

Could npm i -g grok-dev route around it? Maybe. That is the escape hatch that gets Node-based agent CLIs onto Termux, and grok-dev declares engines: node >=18 with no CPU restriction. But it depends on @opentui/core and agent-desktop, which ship native components, and the project targets Bun rather than plain Node. We have not tested that path on aarch64, so we are not going to tell you it works. Unverified is the honest answer until someone runs it.

Running either one with a phone as your only machine

Neither project has an iOS or Android build. Grok CLI's installer accepts Darwin, Linux, and Windows and exits 1 on anything else; Grok Build's does the same. Nobody is shipping a coding agent that runs natively on iOS.

Grok CLI's Telegram remote control is the closest thing to a phone story, and it is worth being precise about what it is. The README's framing is to keep the CLI running while you ping it from your phone. Something of yours stays awake, and your phone is a messaging front-end to it. That is a relay, and we have a whole guide on relay apps versus cloud containers and why the difference matters when your laptop lid is shut.

The other shape is to put the agent on a Linux machine that is already awake and reach that from the phone. Ours is an Ubuntu 24.04 x86_64 container on Azure AKS, which we reach from native iOS and Android apps. The relevant detail here is boring and load-bearing: it is x86_64, so the linux-x64 asset that Grok CLI actually publishes resolves normally, the same binary its own installer cannot find on an ARM phone. We installed Grok CLI 1.1.7 into a clean Ubuntu 24.04 x86_64 container and grok --version reported 1.1.7 against a 117 MB binary.

We do not pre-install either Grok agent. We ship Claude Code, Codex CLI, OpenCode, and Gemini CLI; adding Grok is a one-line install you run yourself. And one honest limit: we would not host Grok CLI's grok daemon --background scheduler or its Telegram pairing as an always-on service. Pro is 120 hours of compute a month with hibernation after ten minutes idle, and a hibernated container is a daemon that stopped answering. If you need something listening at 3am, that is a VPS job.

Which one should you actually install?

Install Grok Build if you want xAI's own agent with support behind it, you are on ARM Linux and need a binary that exists, or you need browserless sign-in. grok login --device-auth prints a code you approve on another device, which is the flow that works over SSH or in a container. It also has far more momentum: 20,734 stars in six days against the community project's 3,314 in a year, and its last push was today while Grok CLI's was 2026-07-06.

Install Grok CLI if you want search_x, which queries live X posts from inside the agent loop. No other agent CLI we track does this, and for debugging a library that changed last week it is a real edge. It also gives you sub-agents by default, a --batch-api mode for cheaper unattended runs, structured --format json output, and a hackable TypeScript agent loop that is far easier to modify than a 146 MB Rust binary. If you want to read the code your agent runs, this is the one.

One opinion, stated plainly because we think the star counts are misleading people: the community CLI is the more interesting piece of software, and it is losing on distribution, not on merit. X search is a genuinely novel capability. The missing ARM64 artifact is a CI configuration gap, not a design decision. Picking on stars alone means picking the newer project because it has a bigger logo on it.

For where either fits among the agents that do have a phone story, see the pillar on AI coding agents on mobile, or the walkthrough for running Grok Build on a phone.

Frequently asked questions