Grok Bot's shared computer cannot show which Bot held the login

Two Bots on one shared Grok Bot computer leave an audit line naming a person; open-source Kortix gives every session its own machine and a change request.

Grok Bot is a strong hire for one person with saved logins; Kortix is the open-source CompanyOS a team reaches for when two Bots both need reviewing. The design that sends a team looking for an alternative sits further down the product page: every Bot on your account shares one persistent cloud computer, and isolation is per user. Kortix answers it with a machine per session and a change request for anything that leaves that machine.

Grok Bot is a roster of bots on one computer

xAI sells Grok Bot as "AI teammates that finish the work" (x.ai/bot). A Bot signs in to your apps and websites, then uses them the way a person would. It keeps context on how you work and comes back when it needs your approval. Bots run in parallel around the clock, with your laptop closed. One can follow a workflow once, save it as a routine and run that routine alone next time.

Grok is the assistant you talk to. Grok Bot is the product that holds a computer and drives your apps, and both draw on one allowance. "Every tier includes a pool of AI usage shared across Grok and Cursor. Within Grok, the pool covers Chat, Imagine, Voice, and Bot," the pricing page says (x.ai/pricing). A heavy chat month and a heavy Bot month come out of the same pool.

The computer is the part worth reading twice. xAI's product page says every Grok Bot on an account shares one persistent cloud computer, with the files, browser and logins sitting on it (x.ai/bot). Bots on that machine hand work off and keep context, and the page draws the isolation boundary at the person rather than at the Bot.

What the shared computer buys

The hand-off is real. Put a few Bots in one thread and they pass work between themselves, with the project context already loaded. Sign in once and every Bot inherits the session, which is how a Bot drives a tool that never shipped an API. Three costs come with the design. Each is the price of the hand-off xAI built, and for one person it is worth paying.

• A reviewer cannot name the Bot. Grok Bot attributes work to the member, and its docs say so plainly: "Bots act as the signed-in member. A Bot can never hold more access than the person it belongs to, every action stays attributable to a named member, and there is no separate machine identity outside your identity provider to provision, rotate, or audit" (Grok Bot security). Two Bots on one login leave an audit line that names a person. The Bot that ran the send is not in it.
• An approval is not an undo. "An approval controls the proposed action. It does not reverse work already completed" (approvals and privacy). A card that lands after the email went out records the decision without reversing the send.
• The login outlives the task. Files, browser sessions and saved logins sit on one durable disk per person, and "Deleting a Bot does not remove computer files or browser sessions." A Bot handed a project inherits whatever the last one left signed in.

Isolation is per user, and so is the record

Grok Bot runs on Cursor's infrastructure, and the docs do not soften it. "The Grok Bot desktop and mobile apps send each request to Cursor's servers," and "Grok Bot runs only on Cursor-hosted cloud computers. On-premises deployment, deployment inside your own perimeter, and bring-your-own-image deployment are not supported today" (security).

The tightening controls arrive with the enterprise contract. The organization-wide enable switch, Network Controls, Action Recording, audit logs, OpenTelemetry export, an MCP allowlist and SCIM are all enterprise settings, and "Self-serve Teams do not see those settings." A team that never sets a network policy runs on the default: "Teams without a policy default to allow-all."

For a team of eight this may be fine. A reviewer signing off on an agent that holds a CRM login gets a harder answer. The boundary is a hosting contract, the record is per person, and the controls that tighten both sit above the self-serve tier.

A machine per session, in two files

Kortix takes the opposite position on the machine and a similar one on the work. Every project is a repository, and the manifest at its root is called kortix.yaml. The starter manifest is 35 lines and opens with a schema line for your editor (the Kortix starter manifest on GitHub):

default_agent: worker

# Project skills: folders under skills/, registered by name. Each agent then
# enables them with its own `skills:` grant.
skills: {}

agents:
  worker:

    mode: primary
    permission: allow
    prompt_file: agents/worker.md
    tools: all
    skills: all
    connectors: all
    secrets: all
    kortix_permissions: all
    workspace: { project_repository: true }

A worker here holds nothing in a shared account. Its prompt, tools, connectors and secret grants are read from files beside the code. The second file is the one that changes the machine: "The session you're in is an isolated sandbox — an ephemeral branch of this repo, your own /workspace — so you can install, experiment, and recover freely. Only what you commit + push survives" (the worker instructions in the Kortix starter).

Two Bots here become two sessions. One isolated sandbox per session. Each session has its own isolated machine and branch. A hand-off arrives as a commit or a change request. A reviewer reads it as a diff. Session work reaches main through a change request. Merge is default-deny for agents.

One caveat sits in the manifest above. The starter's worker carries kortix_permissions: all, which includes the merge capability. If a second name should own the merge, replace that line with a list that leaves it out. Connector credentials are brokered server-side and never enter the machine.

What each option asks a team to run

Grok Bot prices per subscription. Premium is $30 a month, Super $100 and Ultra $200, and "Grok Bot is included with Premium, Super, Ultra, Teams, and Enterprise" (x.ai/bot); the free tier is Grok chat with limited usage, so Grok Bot starts at Premium. "Grok Bot subscriptions come with weekly usage included, with additional usage billed based on token cost."

Kortix prices the machine instead. The paid plan runs on credits at 100 credits per dollar, so $50 buys 5,000 credits (kortix.com/pricing). The meter runs per second while a session's sandbox is up, and 11 credits is about an hour of the default computer. A team that parks a session between messages pays for the machine it kept, which is the subject of what an agent runtime sells.

The open-source field splits along the same line. Rakazo keeps the roster shape with "Shared Team Computers and isolated Private computers," is self-hosted, and is in beta (Rakazo). Every bot in OpenMausBot's sidebar runs on a separate cloud computer, and the app ships for macOS, Windows and Ubuntu (OpenMausBot). Both are Apache 2.0. Kortix counts a repository and a session instead of a bot and a computer.

When Grok Bot is the right purchase

One person, one assistant, logins already saved, $30 a month and no server to run: Grok Bot is the better buy. No open-source install beats it on a Monday morning.

The arithmetic changes when a second person has to review the work. A third may have to answer where a login lived and which Bot used it. At that point the purchase is a record and a boundary, and a git repository is a cheaper place to keep both.

If chat is the whole job, Grok is already the chat product. A different chat window does not change who reviews what the agent did. The comparison worth running is about the machine and the merge.

What a cloud agent hands back follows a session branch through review. The policy behind the per-session machine covers the stop rule and the meter.