SpaceXAI

A note on the name first, because it moved recently and the old one is still in circulation: the public brand is SpaceXAI, the legal entity is X.AI LLC, and the developer documentation now carries the new name throughout. The coding product is Grok Build.

Scope note: this series covers tools engineers use to write software, not putting a model inside a shipped product.

Grok Build — a command-line coding agent with a dedicated enterprise deployment guide.

• Client — one primary command-line agent, with documented modes, commands, and keyboard shortcuts
• Features — permissions, sandboxing, layered settings, tool servers, plugins
• Monitors — a facility that turns each line a script prints into a notification in the conversation; useful for watching a build or a deployment
• Models — a coding-specialized model with a large context window, plus the general flagship at a wider context and higher rate
• Distribution — a shell-script installer or a package-registry install
  • The registry path matters for locked-down environments; see § 06

Narrower surface than the other three labs — one primary client rather than an editor extension, a desktop app, a web surface, and a hosted cloud runner.

• No first-party editor extension is documented. The peers ship into Visual Studio Code and the JetBrains family at minimum; this is terminal-first

• Engineers who work primarily in an editor get the agent through a terminal pane rather than inline in the buffer

• Cuts both ways: less to review and less to govern, but fewer places to meet engineers who do not live in a terminal

The weakest-documented dimension. Treat that as a finding rather than working around it.

• Published — per-token pricing, clearly, for both the coding model and the general flagship
  • Each with a step up above a large prompt threshold
  • For an organization authenticating with a key and paying for consumption, that is a complete answer
  • Makes a pilot unusually easy to scope and cost
• Not published — the seat-based plan and its floor
  • Enterprise documentation covers deployment thoroughly: identity, policy, network, sandbox
  • It does not state which subscription tier unlocks it, or the seat minimum
  • Enterprise identity, single sign-on, and managed configuration are documented capabilities; the commercial terms carrying them are not
  • Invoiced monthly billing is noted for enterprise customers, suggesting the usual quoted-contract path at the top end
• A personal Grok subscription is not a company seat — same distinction, same shadow-rollout risk, as everywhere else in this series

Strong on the deployment boundary, thin on the seat table. That is an unusual shape, and it favours starting with metered usage rather than a seat commitment.

• Practical consequence — the metered path validates capability, fit, and cost with no commercial negotiation
  • Do that first, and enter the seat conversation with usage data rather than an estimate

• Tiered by prompt size, not flat — rates roughly double above a large prompt threshold
• Why that matters specifically for coding agents — agents accumulate context
  • A long session crosses the threshold and the effective rate changes partway through the work
  • Model that explicitly rather than multiplying an average rate by expected volume
  • Two teams with identical token counts but different session lengths produce different bills
  • Context management becomes a cost lever, not only a quality one
• Cached input is priced separately and lower — rewards workflows that reuse a stable prefix
• Also documented — cost tracking, rate limits, and batch and deferred completion modes for non-interactive work
  • The usual levers for moving expensive non-urgent work off the interactive path

Four questions a legal team asks, in the order it asks them. The governing document is the enterprise terms of service, and it is the most recently revised in this series.

1 — Who owns the output?

• Customer retains all right, title, and interest — including all intellectual-property rights — in the Input
• Customer owns all right, title, and interest in the Output in perpetuity, and SpaceXAI assigns its interest to the customer, excluding the underlying technology
• The most explicit ownership grant of the four. In perpetuity is doing real work in that sentence

Two qualifications:

2 — Does the source train the model?

• No. SpaceXAI will not use customer content to train foundation models, large language models, or other AI systems, or to develop any new products, services, or features
• The "new products or features" clause is broader than the training-only language used elsewhere
• One thing to notice — outside zero retention, SpaceXAI may create de-identified and aggregated data derived from the customer's use, irreversibly anonymized, and owns that derived data for any lawful purpose
  • Not customer content, and not recoverable as such. But it is a right the customer gives up by not electing zero retention, and it belongs in the comparison

3 — Could generated code carry someone else's licence?

• No public-code matching filter is documented, as with two of the other three labs
• The terms place responsibility squarely on the customer: solely responsible for independently evaluating the accuracy, completeness, and suitability of any Output before relying on or distributing it, including through human review where appropriate
• Consequence for evaluation — prevention is the organization's own control. Licence and dependency scanning on agent-authored changes

4 — Who defends the company if a third party sues?

• SpaceXAI will defend the customer and its affiliates against a third-party claim alleging that the customer's authorized use of the Services infringes third-party intellectual-property rights, and indemnify resulting losses including reasonable fees
• Mitigation ladder — procure the right to continue, replace or modify the affected Services, or terminate and refund a pro-rata portion of prepaid fees
• Exclusions to read closely — unauthorized use or modification; combination with third-party or open-source components not approved by the vendor; anything bundled or integrated by the customer; trial, beta, preview, or no-charge services; Input; training data the customer supplied; and, notably, Output that was intentionally or recklessly prompted to be infringing
• The reciprocal clause matters as much as the indemnity. The customer indemnifies SpaceXAI against allegations that its use or distribution of Outputs infringes, to the extent those allegations would not have arisen but for the customer's own specific prompts, instructions, or modifications
  • So prompting matters contractually. "Write this the way library X does it" is not a neutral instruction
• The hard limit — the terms state this section is SpaceXAI's entire liability and the customer's exclusive remedy for any intellectual-property claim
• Liability is capped at twelve months of fees, with indemnification obligations and intellectual-property obligations carved out of the cap

How long is it kept?

• The most generous default in this series — all user content is automatically and permanently deleted no later than 30 days after the end of the session in which it was submitted, unless a different period is agreed, required by law, or needed for a safety or abuse investigation
• Zero retention goes considerably further — content exists only transiently, and is deleted on the earlier of one hour after the inference request completes or delivery of the response, with no logs, backups, or persistent copies retained for any purpose including safety, debugging, or legal compliance

Zero retention here has a documented legal cost: once deleted, content cannot be produced under any circumstances — including subpoenas, regulatory requests, or legal process.

• The terms are unusually candid about that trade, and spell out three acknowledgements the customer must accept:
  1. The customer is solely responsible for preserving any copies it wants to keep, including for legal or regulatory compliance
  2. Once deleted, content cannot be recovered or produced by the vendor under any circumstances
  3. Using zero retention may limit the customer's ability to respond to legal proceedings or audits requiring historical data
• Evaluation consequence — this is the only vendor in the series that states the discovery cost of zero retention on the record. Legal and security may want opposite answers here, and that conflict should surface during evaluation rather than during litigation
• Health data requires both a business-associate agreement and use of the zero-retention interface

Where does it run?

• Governing law is Texas, with exclusive jurisdiction there, plus class-action and jury-trial waivers
• The default subscription term is one year, auto-renewing, with 30 days' notice to stop; fees are payable in advance and non-refundable

• Authentication — standard authorization and identity endpoints, with enterprise federated identity supported
  • An organization allows its own identity provider's domain alongside the vendor's authentication host
  • Developers sign in through the corporate directory
• What the public documentation does not detail at the same depth — the lifecycle layer the other labs describe explicitly
  • Automated directory provisioning
  • Group synchronization
  • Role models
  • The deprovisioning path when someone leaves
• Federated sign-on gets most of the way — disabling the account at the identity provider cuts access
  • But "most of the way" is not automated seat reclamation and group-based entitlement
• For an evaluation — this belongs on the vendor question list rather than being scored from public pages
  • Same shape as the seat-table gap: strong deployment story, thinner commercial and lifecycle story, both answerable in a conversation

The strongest section, and the most specific documentation of its kind in this series.

The network table. Most vendors answer "what does it connect to" with a paragraph. This one answers with a table separating required from optional hosts and stating the consequence of blocking each optional one.

• Transport — everything over standard secure transport on one port
  • A memory-safe library rather than the usual system dependency
  • Root certificates from the operating-system trust store
  • No option to disable it
  • For traffic-inspecting environments, the documented answer is installing the inspecting proxy's certificate authority into the trust store — the correct answer stated plainly instead of discovered through a support ticket

The always-approve lock. Every agentic coding tool has a mode where the human stops approving each action. It makes the tool feel fast, and a regulated environment cannot permit it.

• The usual failure — a vendor documents one setting, a developer finds a second route, and the control was never real
• Here, one managed setting disables it across the deployment, and the documentation enumerates what it blocks:
  • The command-line flags
  • The in-session keyboard toggle
  • The slash command
  • The mode-cycling shortcut
  • Settings supplied by a client
  • Catch-all allow rules such as a bare wildcard
  • Deny rules keep applying regardless
• The enumeration is the point — a control described as "disables bypass mode" invites a developer to hunt for the sixth route
  • A control that lists all six and closes each is one an auditor can sign off on, because the vendor already did the adversarial enumeration

The sandbox.

• A non-empty deny list is enforced at the kernel level where the platform allows it
  • Not a suggestion the agent is asked to honour — a boundary the operating system holds
• On one platform, read-denial has a named prerequisite package
  • The sort of dependency that belongs in documentation rather than in a surprise

Configuration precedence — stated rather than implied.

• Enterprise-served defaults sit at machine and user scope
• Project-level configuration is deliberately limited to tool servers, plugins, and permission rules — not full user configuration
  • A repository cannot quietly widen what a developer's client is permitted to do
  • That constraint will annoy someone during a rollout, and it is the right constraint

• The thinnest dimension relative to the others in this series
  • Configuration and network posture are auditable by inspection — a policy file and a firewall rule are both verifiable artifacts
  • The privacy command lets a developer confirm the retention posture in-session
  • What is missing from public documentation — a compliance interface for exporting activity records, and a published attestation package
  • Both belong on the vendor question list

Coexistence — the detail most worth pausing on.

• An organization that already deployed a competitor's managed-settings file through device management does not have to rebuild that policy
  • Grok reads a subset of it: permission rules, tool-server allowlists, several telemetry and feedback flags, and marketplace restrictions
  • Its own requirements file always takes precedence
  • A deployment running only this tool is directed to use the native files instead
• Read what that assumes — the buyer already runs another agent, is not replacing it, and needs both to coexist under one policy
  • A realistic picture of how these tools land; engineering teams end up with more than one, by preference or procurement accident
  • Building for it is more useful than pretending the buyer starts from zero
• For a platform team — a genuine reduction in work; the policy negotiated over months keeps applying
• Whether to take the shortcut is a separate question
  • A single policy source interpreted slightly differently by two vendors is its own kind of drift
  • Safer long-run posture: a native policy file per tool, with the compatibility layer as a migration bridge rather than a destination

Strong fit

• Where a network-security team owns the decision — the host-by-host table with stated blocking consequences, the kernel-enforced deny list, the no-disable transport policy, and the enumerated permission lock together make the shortest path in this series from open evaluation to a firewall rule and a signed-off policy file
• As a second agent in a shop that already runs one — the policy compatibility layer means adding it does not mean rebuilding the device-management policy, lowering the cost of running two tools deliberately rather than accidentally
• For a metered pilot — published token rates and a direct key path mean validation with no commercial negotiation and no seat commitment

Weak fit

• Where procurement needs a published seat table and a comparable per-user cost up front — that information is not public, and an evaluation requiring it will stall
• Where the team does not live in the terminal — the surface is narrower than the other three

Disqualifiers

• Requiring a published attestation package and a documented compliance-export interface before pilot — that cannot be closed from public documentation
• Requiring per-organization rather than team-level retention granularity — confirm the model fits the structure first
• Source cannot leave the network at all — the inference proxy is a required host, and there is no on-premises option

Order to evaluate in

1. Start with the metered path and a real pilot — costs nothing commercially, produces usage data
2. Hand the network table to the security team early — the fastest approval in this series, and it may clear the gate before the commercial conversation starts
3. Take three questions to the vendor — the seat plan and its floor; the identity lifecycle beyond federated sign-on; the attestation and audit-export story
4. Score the answers — come back well and this is a genuinely strong deployment story with a documentation gap. Come back thin and the gap is the answer

The series closes with the Overview — all four labs on one page, the vocabulary for the non-seat paths, and the short version of which question to ask first.