Grok Bot: xAI’s AI Teammates Get Their Own Shared Computer

Grok Bot launched in beta on August 11, 2026 — xAI’s entry into the “AI teammate” category, pitched as “AI teammates you can give real work to.” The launch page’s central promise is that “Bots have their own computer.” xAI’s own documentation, published the same day, says something different: all of your Bots share one persistent cloud computer, and separate Bots should never be treated as a security boundary.

That gap between the marketing page and the docs is not a nitpick. It is the difference between “I can give my bookkeeping Bot and my inbox Bot separate credentials and contain the blast radius” and “everything every Bot can reach lives in one shared place.” For a product whose whole pitch is signing into your tools and doing real work unsupervised, the security model is the product — and at launch, xAI’s two descriptions of that model do not match.

This guide covers what actually shipped, the shared-computer architecture as the docs describe it, a side-by-side matrix of where the marketing pages and the documentation disagree, the Cursor-gated pricing, the credential-handling flow xAI did document, and what teams evaluating Grok Bot should do about all of it. Every claim about the product below is sourced from xAI’s and Cursor’s own pages, read at the time of writing; the one secondary source cited, in Section 05, appears only as an example of how the contradiction is spreading.

Grok Bot is a distinct product line — an “AI teammate” app for desktop and iPhone, not a terminal coding agent and not a prompt-to-app builder. xAI now ships three separately named agent products, and conflating them muddles every claim about any of them:

The launch post frames Grok Bot as something you staff rather than something you operate: message a Bot from your phone or desktop in the same thread, hand it a job, and let it run. Bots “can independently message each other and share context in threads,” and can be placed “in a group chat where they can coordinate on their own... pass work, assign ownership, and only pull you in for judgment calls.” According to the launch post, the product began as an internal prototype that spread across the merged SpaceXAI operation — used internally for sales outbound, marketing campaigns, office operations, and bug fixes — before being opened to outside users. Separately, xAI shipped Grok 4.5, its coding and office agent model, in July; xAI does not name the model behind the Bots (more on that open question in Section 04).

The most operationally interesting capability is learning by demonstration. Ask a Bot to follow along while you do a job once; it “saves your workflow as a routine, takes your corrections, and runs it on its own next time.” The docs formalize the split: a skill “describes how to perform a task,” while a routine “assigns a workflow to one Bot and tells it when to run — on a schedule or, where supported, after an event.” A “Teach a task” recording is capped at ten minutes, the rollout “may be gradual,” and the docs sensibly recommend testing a skill on a real one-off task before promoting it to a routine. Where demonstration-taught agents fit against explicit workflow builders is a bigger question than one launch — we compare the two automation paradigms separately.

Availability at launch is narrow: a beta for SuperGrok Heavy, Cursor Ultra, and Cursor “Teams Premium” subscribers on desktop and iOS, with enterprise access behind a waitlist and team rollout described as gradual, varying by organization. Section 04 unpacks what those tiers cost — and why even their names are unstable.

The launch page’s own words: “Bots have their own computer. They sign into the tools you already use and work across apps, inboxes, and more. They finish jobs end to end, and only come back when something needs your approval.” The same framing appears on a second marketing surface — x.ai/bot’s Cursor Ultra tier lists “Grok Bot’s own computer” as an included feature.

The documentation describes a different architecture. Per the Grok Bot overview page: “All of your Bots use the same persistent cloud computer.” The docs continue: “The computer is isolated to your account, not to an individual Bot,” and each Bot gets its own screen on that computer so several Bots can drive browser and desktop tools in parallel — “without getting separate security boundaries.” The shared machine is a persistent cloud VM with a browser, a filesystem, and a terminal, and one Bot can run one computer-use task on its screen at a time.

In case a reader misses the implication, xAI states it outright — on two separate documentation pages, the FAQ and the approvals-and-security page, in the same words:

Read plainly: “own computer” is a statement about screens and parallelism, not about isolation. Every login, file, and session any Bot establishes lives on one machine scoped to your account. The security page is explicit: “All of your Bots share one cloud computer assigned to your user account. Files, browser sessions, and command line credentials on that computer are available across your Bot roster.” That is a defensible engineering choice — it is what makes Bots able to pass work to each other cheaply — but it is the opposite of what a reasonable buyer infers from the phrase “their own computer.”

The trend this fits is worth naming: agent vendors across the market are converging on anthropomorphic framing — teammates, coworkers, staff — because it sells delegation. But personnel metaphors smuggle in security intuitions (an employee has their own laptop, their own logins, their own accountability) that the underlying architecture may not honor. In Grok Bot’s case, the metaphor and the documented architecture diverge on the pages of the same vendor.

Everything in the table below comes from vendor-published pages — the launch post and pricing page on one side, the Grok Bot documentation on the other. Anyone can reproduce the comparison by reading both. The point is not that marketing simplifies (it always does); it is that on the claims a buyer would build a security review around, the two surfaces are not simplifications of each other — they disagree.

None of these rows requires interpretation or a leak — each cell is a sentence a vendor published. That is precisely why the matrix matters: when the same company’s launch copy and reference documentation part ways on security architecture, platform support, tier naming, and who governs the data, the documentation is the side to build on, and the delta is the size of your due-diligence gap.

Grok Bot has no standalone price. Access at launch comes bundled with SuperGrok Heavy (xAI’s own top plan) or with Cursor’s top tiers — and x.ai/bot is where the numbers live: Cursor Ultra at $200 per month, billed monthly, and a tier the pricing page calls “Cursor Premium Teams” at $120 per seat per month, billed monthly. Enterprise access is a waitlist. Subscriptions “include weekly usage; eligible accounts can add on-demand usage billed from model and token cost” — and no quota figure is published on any page we checked, so treat any specific number you see elsewhere as unsourced.

We cross-checked those figures against Cursor’s own pricing page — not the rendered marketing copy, but the machine-readable structured data (JSON-LD) embedded in the page’s raw HTML. That data lists five offers: Hobby at $0, Pro at $20, Pro+ at $60, Ultra at $200, and Teams at $40 per seat. The $200 Ultra figure is therefore corroborated by both vendors independently. The $120 “Premium Teams” seat price is not — Cursor’s structured data carries no separately priced Premium SKU at all, leaving x.ai’s page as the only source for that number, three times the $40 seat price Cursor lists for plain Teams.

Two smaller data-hygiene findings round out the pricing picture. First, the tier-name drift documented in Section 03: three vendor surfaces, one product — three different names for the teams tier. Second, a genuine research trap on Cursor’s page: the visible tab copy differentiates Pro, Pro+, and Ultra only by usage multiplier, so a summarized fetch of the rendered page can misreport all three Individual tiers at $20 per month. The per-tier dollar amounts surface reliably only in the structured data. If your procurement notes cite Cursor pricing, cite the JSON-LD, not a page summary.

One more absence worth stating plainly, because it is load-bearing for any evaluation: xAI does not say which model powers Grok Bot. Not on the launch post, not on x.ai/bot, not on the four Grok Bot doc pages we checked (overview, FAQ, security, get-started). Whatever you assume about the Bots’ capability ceiling, latency, or cost to serve is an assumption. Why the gating and billing run through Cursor at all is its own story — we unpack the Cursor tier-gating and what it signals in a companion piece.

The documented platform list is clear: macOS on Apple silicon and Intel, Windows on x64 and Arm64, and iPhone on iOS 18 or later. The FAQ states that “Linux desktop, Android, and iPad are not supported at initial launch,” and the get-started page says it in one sentence: “Grok Bot is not currently available as a Linux desktop app.”

The download page muddies it. When we read x.ai/bot with a full JavaScript render at the time of writing, its download section listed a Linux build — a versioned installer named Grok_Bot_0.16.0.deb, labeled for Debian and Ubuntu on x64, served from a downloads.cursor.com URL. We state the two halves at their respective confidence: the docs’ “not currently available” line is verbatim from xAI’s own documentation; the installer listing is what the rendered download page showed when we fetched it. Both cannot stay true for long — either the docs lag a quiet Linux release, or the download page links a build xAI does not yet stand behind.

Credit where due: the part of Grok Bot’s security story xAI did document is genuinely thought through, and it is more interesting told straight than sensationalized. The launch page’s “sign into the tools you already use” promise resolves, in the docs, to a mechanism where the human — not the agent — handles every secret.

Human takeover for secrets

Per the security page: “For passwords, passkeys, two-factor codes, CAPTCHAs, and payment confirmations, the Bot should hand you control of the computer.” You open the agent-computer view, take control, complete the sensitive step yourself, then hand control back and tell the Bot to continue. The docs add a rule worth pinning to every operator’s wall: “Do not send a password or one-time code in ordinary chat.”

The “secure secret request”

For supported connections there is a separate, narrower channel: a secret request that is “masked, excluded from the transcript, and not shown to the model.” The docs immediately bound its scope — it is “not a general-purpose password manager.” Beyond those two documented mechanisms, xAI does not describe how sign-ins work under the hood, and neither should you: any claim about OAuth flows or session storage for Grok Bot is speculation.

Approvals and Auto Review

Actions run through a per-action approval model: on desktop, “Allow once,” “Deny,” or “Always allow” (which saves a matching rule); on iPhone, “Approve once” or “Deny.” A model-based Auto Review layer can apply rules automatically, with a sensible precedence — “Require Approval” rules always beat “Always Allow” rules when both match. And the docs hedge their own feature honestly: “Auto Review is model-based and should complement, not replace, least privilege and explicit approval boundaries.” Access to your local machine is a separate control entirely (Settings → General → Agent → Execution on Local Computer), and its default is “Ask every time.”

The catch is where those well-designed controls sit: on top of the shared computer from Section 02. Approvals gate what a Bot does; they do not partition what the roster has. Once a session or CLI credential lands on the shared machine, it is available across every Bot on the account and can outlive the Bot that created it. Least-privilege review for a product like this has to operate at the account level, not the Bot level — a checklist-shaped problem we work through in our agent tool-access authorization review.

The quietest finding in the docs may matter most for procurement: the product xAI markets under its own brand is governed, at the data layer, by Cursor. Verbatim from the docs: “Grok Bot uses Cursor authentication and account data settings... Grok Bot requires cloud data storage, so Legacy Privacy Mode is not supported... Training opt-out follows the applicable Cursor account and privacy settings.” Backend retention and account deletion likewise “follow the applicable Cursor terms.” Even the desktop installer we observed was served from a downloads.cursor.com URL.

The commercial backdrop makes the arrangement legible. SpaceX agreed in June to acquire Anysphere, Cursor’s maker, in a press-reported $60B all-stock deal that was still pending regulatory approval in the days around this launch — so “Cursor owns Grok Bot’s identity layer” describes an integration between two formally separate companies, not a closed merger. What is checkable today, independent of the deal’s legal status, is the integration itself: authentication, billing, desktop distribution, and privacy terms all run through Cursor’s stack.

For buyers, the practical consequence is simple: a Grok Bot vendor-risk review that only assesses xAI reviews the wrong company for half the questions. Data residency, retention windows, training use, and deletion guarantees are Cursor-side questions. And for readers weighing xAI’s disclosure track record on agent-data handling, the relevant prior chapter is xAI’s earlier Grok Build data-handling incident — a different product, as Section 01 stressed, but the same vendor’s paperwork under stress.

None of the above means “avoid Grok Bot.” It means: evaluate the documented product, not the advertised one. Four calls we would make for a client team this week:

The deeper question a launch like this forces is organizational, not technical: what work should be handed to an always-on teammate at all, and how does managing one differ from running a workflow engine? We take that up in our AI-teammate operating model piece and, more tactically, in what to delegate to an AI teammate first. For the landscape context — how the computer-use agents from other labs structure isolation and permissions — see our computer-use agent matrix and the enterprise automation playbook.

Looking forward: if the teammate framing wins the market — and the speed with which vendors are adopting it suggests it will — the differentiator among these products will not be who has the most charming group chat. It will be which vendor can make the personnel metaphor true at the isolation layer: per-teammate credentials, per-teammate boundaries, per-teammate offboarding that actually removes access. Grok Bot’s docs, to their credit, tell you plainly that today it is not this product. Teams that want the delegation upside now, with the governance questions answered before rollout rather than after, are exactly what our AI transformation engagements are built for — and if the first candidate workload is pipeline and inbox automation, our CRM automation practice starts precisely where the launch post’s own internal examples do.