grok-cli

Sub-agents are on by default, and that is the trait you feel by the second session: a large task gets split without you asking, and the main thread stays readable while the pieces run. Most terminal agents make you opt into that and most people never do.

What you give up is polish and any sense of a support contract, because this is a community build with a small maintainer surface. Pick it if you have the API bill anyway and enjoy being early. Pick Claude Code if you want the same shape from a team that will still be shipping it next year.

The failure mode is uneven confinement. Resource limits are documented as requiring Apple Silicon and macOS 14 or later. Run the identical command on an Intel machine or a Linux box and those limits are simply absent, while the agent's reach over the working tree is unchanged. A safety property that depends on your laptop's processor is not a safety property, it is a coincidence.

What it does right: lifecycle hooks fire on session and subagent events, which gives an operator a real interception point for logging or refusal rather than trusting the prompt.

1. Retrieval is live. Real-time social and web search feed the same context that the code tools populate, so two identical prompts a day apart are not the same experiment. That is useful for questions about the world and corrosive for anything you intend to measure.

2. No benchmark is published, and documentation is a single repository page, so claims about behaviour rest on the feature list rather than on a demonstration. 3. There is no described procedure for deciding an edit was correct before it is written.

There is no business here, and the project says so: it is community-built and unaffiliated with the lab whose endpoint it consumes. That is honest and it is also the whole risk. The upstream can change terms, rate limits or model naming, and the maintainers absorb it for free, which is a volunteer arrangement rather than a supply chain.

Moat: none, by design. Likely path: absorption into a maintainer's larger product, or a quiet archive when the novelty of the endpoint fades. Position: use it, do not depend on it, and keep your prompts portable to another client.

The finance side is trivially good: nothing per seat, and consumption lands on an API account finance can already see. That is the end of the good news.

Everything procurement asks about is absent. No administrative console means no provisioning, no central audit trail and no way to enforce a policy across sixty machines. There is no supplier to answer a security questionnaire, because the supplier is a repository. Onboarding is an afternoon for an engineer who already lives in a terminal, and support is an issue tracker. Not yet.

This is my kind of tree. MIT licence, a bun add -g grok-dev install, and a terminal layer built on OpenTUI rather than a proprietary renderer, so the parts I would want to rip out are ordinary TypeScript. MCP servers plug in and behave.

The wall is the backbone. It talks to one model family and the row records no choice of provider, so the freedom stops exactly where the inference starts. I can rewrite the interface and I cannot swap the brain. A fork survives the maintainer easily. It does not survive the endpoint.