Grok Build Source Course · 12 / 22

Full Comparison: Calibrate Evidence Before Trade-offs

The Grok Build side can drill down into source code; the Claude Code side records only publicly documented behavior. The two columns have different resolution, so blanks are kept blank rather than filled with inference.

Lesson 24 of This SeriesSource vs Public DocsEvidence LevelNo Internal Guessing
01 / OBJECTIVES

Learning Objectives

Establish Evidence Levels

Distinguish source code, repository docs, official public docs, and local snapshot observations.

Complete a Multi-Dimensional Comparison

Compare public capabilities across runtime, tools, context, security, recovery, and ecosystem.

Produce Selection Criteria

Reframe "who is better" as a match of constraints, team capability, and delivery scenario.

S · Grok Source CodeR · Grok README / GuideP · Claude Official Public DocsI · Local Snapshot Observation
02 / CORE VISUAL

Same Question, Two Evidence Perspectives

03 / MATRIX

Full Evidence-Based Comparison

DimensionGrok BuildClaude Code Public Behavior
Implementation & DistributionRust Cargo workspace with functionality split across multiple crates; README provides source build entry point.
R1 · S1		Official entry points include terminal CLI, IDE, Desktop, and Web. Internal language and module boundaries are out of scope for this course's conclusions.
P1
State & ConcurrencySessionActor holds session history and tool context, runs on Tokio LocalSet; background tasks can independently send messages back.
S2		Public docs describe user-observable behavior of sessions, background tasks, subagents, and agent teams; no inference is made about the internal concurrency model.
P5
Tool ContractToolKind enum feeds into capability filtering with compile-time sync assertions for new variants; MCP tools map to Other.
S3		Public permission rules control allow, ask, and deny by tool name and parameter patterns such as Read, Edit, Write, Bash, WebFetch, MCP.
P6
Tool DiscoveryBuilt-in tools are registered directly; MCP metadata enters a snapshot and BM25 index, with lazy discovery via search_tool / use_tool.
S4		Official docs state Tool Search can load MCP tools on demand, with support for deferred connection waiting and failure feedback.
P3
Context CompactionSource includes compaction configuration, segmentation, two-pass, full-replace, and recap auxiliary paths; auto-compaction and recovery are testable.
S5		Public behavior includes auto-compaction, /compact, and compact instructions; internal algorithms are out of scope for this course.
P4
Long-term Memoryxai-grok-memory implements SQLite storage, FTS, embedding, MMR, and a Dream consolidation workflow, integrated by the session memory state.
S6		Public mechanisms include layered CLAUDE.md instructions and auto memory; scope and loading rules are covered by official docs.
P4
HooksSource enumerates 15 events; PreToolUse can block. Explicit deny blocks; Hook crashes, timeouts, and failed output go fail-open. Configuration uses JSON.
S7 · R2		Official Hooks reference documents multiple event types, matcher, if conditions, and command, HTTP, MCP tool, prompt, agent handlers; PreToolUse can return a deny.
P2
MCPSource confirms client role; supports stdio and Streamable HTTP, OAuth, server__tool, dynamic capability refresh, state merging, and restart. No general MCP Server entry point confirmed.
S8 · R3		Official docs document remote HTTP, local stdio, WebSocket, OAuth, dynamic list_changed, Tool Search, and connection management.
P3
Permissions & SandboxToolKind capability filtering, permission prompts, and platform sandbox code combine into multi-layer control; Hook failure policy does not carry mandatory security guarantees.
S3 · S7		Official documentation covers allow, ask, deny rules, managed settings, sandboxed Bash and filesystem, and network isolation configuration.
P6
SubagentSource includes fork, task, worktree pool, and completed subagent worktree snapshot configuration; branch tasks can be placed in isolated worktrees.
S9		Official subagents have independent context, tools, and permissions; can run foreground or background; worktree isolation configurable.
P5
Plugin EcosystemMarketplace supports indexing and directory fallback; install registry preserves source; runtime controls components by scope, enabled flag, and plugin-root trust.
S10 · R4		Official plugin and marketplace docs document skills, agents, hooks, MCP servers, LSP servers, and installation scope.
P7
Recovery & ObservabilitySource includes session persistence, MCP status notifications, 50 ms event coalescing, restart backoff, telemetry enums, and structured events.
S11		Publicly visible behavior includes session resume, verbose/debug, Hooks status, MCP panel, and permission diagnostics; internal persistence topology is not inferred.
P1 · P3
Source Code & GovernanceRepository snapshot makes source public; README notes periodic sync from monorepo, root Cargo.toml is generated, and external contributions are not accepted.
R1 · R5		This column is based on official public product documentation; invisible internal implementation is not used as a comparison fact.
P1
04 / SOURCE

Two Grok Source Anchors

CONCURRENCY ANCHOR

State Ownership in SessionActor

/// An actor representing an ACP session
/// with its own chat history and tool context.
pub struct SessionActor {
    pub(super) agent: RefCell<Agent<ThreadedMvpAgent>>,
    ...
}
crates/codegen/xai-grok-shell/src/session/acp_session.rs
CAPABILITY ANCHOR

Adding a ToolKind Forces Routing

const _: () = assert!(
    ALL_TOOL_KINDS.len() == ToolKind::VARIANT_COUNT,
    "ALL_TOOL_KINDS is out of sync"
);

This kind of assertion turns "add a permission decision after adding a tool" into a compile-time constraint.

crates/codegen/xai-grok-workspace/src/capability.rs
05 / SELECTION

From Comparison Table to Selection

Lean Toward Source Auditability
  • Team is willing to read Rust and multi-crate boundaries
  • Need to trace failures, state, and local data locations
  • Can accept a potential sync gap between the public repository and the actual product
Lean Toward Public Product Workflows
  • Team primarily integrates using official capabilities and configuration
  • Values a consistent entry point across terminal, IDE, Desktop, and Web
  • Internal implementation opacity does not affect procurement or governance requirements

These two sets of conditions can coexist. Real-world solutions can also be combined by project, data classification, or team role.

06 / LAB

Lab Exercise: Evidence-Based Selection Memo

40 MIN

Deliverable
Two-page selection memo

  1. Select six dimensions from the table and copy one Grok source evidence item and one Claude public behavior evidence item for each.
  2. Label evidence levels and rewrite all "stronger, more advanced, safer" claims as verifiable conditions.
  3. Define project constraints: data classification, executable permissions, team stack, recovery targets, extension requirements.
  4. Provide a primary solution, a fallback solution, and the threshold that triggers switching.
  5. List three unknowns and explain how to fill them through PoC — no architecture guessing allowed.
07 / REFERENCES

Evidence Index

GROK BUILD
  1. R1/R5 README.md, CONTRIBUTING.md, root Cargo notes
  2. S2 acp_session.rs, summary.rs
  3. S3/S4 capability.rs, tool_index.rs
  4. S5/S6 compaction directory, xai-grok-memory
  5. S7/S8 xai-grok-hooks, xai-grok-mcp, mcp_dispatcher.rs
  6. S9/S10/S11 fork/worktree, plugins, persistence/telemetry
Takeaway

The lasting skill from this lesson — Lesson 24 of this series — is the ability to separate implementation facts, product behavior, inference, and unknowns. Only when evidence levels are clear do architectural trade-offs have a verifiable foundation.

Source Snapshot Note: The Grok side is based on the local grok-build-main snapshot; the Claude side is based on official public documentation accessible in July 2026, stating only user-visible behavior. Code excerpts are for teaching purposes. Blank cells in the table are intentionally preserved unknowns.