Grouping by Working Directory
Ctrl+S groups sessions by their working directory. If you are running agents across multiple projects simultaneously — say, a Next.js frontend, a Go API service, and a Python data pipeline — grouping by directory visually clusters each project’s agents together.
Sub-agents launched by a parent session roll up under that parent row, not as separate entries. This is a deliberate choice: if a single Grok Build session spawns three sub-agents to handle three parallel subtasks, the dashboard shows one row for the parent with the sub-agent work rolled underneath it. The list reflects the work you dispatched, not the fan-out of internal parallelism.
The distinction matters for cognitive load. A 5-session dashboard stays comprehensible. A 5-session dashboard that explodes into 20 rows because each session has 3–4 sub-agents is not navigable. The roll-up keeps the view readable.
Parallel Agents: 8 Simultaneous Coding Agents
The headline feature. Grok Build exposes two model tiers in the Parallel Agents panel:
You can mix models. Send a single prompt to one Grok Code 1 Fast agent and three Grok 4 Fast agents simultaneously if the task justifies it. The two models run in parallel, not sequentially.
The use case this was built for: sending a single coding prompt to multiple agents and comparing the outputs. xAI calls this Arena Mode in earlier Grok Build documentation — the Agent Dashboard is effectively Arena Mode with proper session management layered on top.
Whether you actually want to compare outputs across 8 agents for every task is a different question. For most development work, you want one correct implementation, not eight variations to evaluate. The parallel pattern is most useful in three specific scenarios:
First: tasks where the implementation approach is genuinely uncertain. If you are prototyping a new caching strategy and you are not sure whether to implement it as middleware, a decorator, or a service layer, running three agents with different approach constraints and comparing the resulting code is faster than thinking through each approach manually.
Second: independent tasks that are naturally parallel. If you need to write tests for five different modules and each module has no dependency on the others, five parallel test-writing agents finish in roughly the time it takes one agent to handle one module. There is no reason to serialize that work.
Third: exploring failure modes. Run the same prompt across two models — Grok Code 1 Fast and Grok 4 Fast — and compare where they fail. The cheaper model’s errors show you where the task exceeds its reasoning capability. The expensive model’s successes show you the correct approach. The comparison is educational.
What parallel agents are not good for: tasks with shared state. If all eight agents are editing the same file, you will have merge conflicts. The Agent Dashboard does not coordinate file locks between sessions. Each agent works on the codebase from its own context snapshot. If you dispatch eight agents to the same monorepo without careful task partitioning, you get eight partial implementations of conflicting changes.
The safe pattern: partition tasks by file or directory before parallelizing. Agent 1 handles src/auth/, Agent 2 handles src/payments/, Agent 3 handles src/notifications/. No overlap, no conflicts, clean merge when each finishes.
How This Compares to Claude Code’s Multi-Agent View
Claude Code shipped a 21-agent multi-agent view in May 2026. The comparison is direct — both tools now have a dedicated UI for managing multiple coding agents simultaneously. They work differently.
Claude Code’s 21-agent view is integrated into the terminal session model — sub-agents are spawned by the parent agent via tool calls, and the multi-agent view shows the tree of active work. Grok Build’s Agent Dashboard is a separate management plane that exists outside individual sessions, which gives it a different set of affordances.
The Claude Code model fits better with orchestration patterns where a single orchestrator agent coordinates many workers. The Grok Build model fits better with independent parallel work where a human is dispatching multiple sessions manually and wants a control tower to manage them.
Neither approach is strictly better. They reflect different assumptions about where the coordination intelligence lives: in the model (Claude Code’s orchestrator pattern) or in the human operator (Grok Build’s dashboard pattern).
Token Cost Reality for Parallel Sessions
Running 8 agents simultaneously does not cost 8x a single session. It costs 8x the token usage over the same time period. That is the same number either way — but the billing hit is front-loaded.
A rough cost estimate for a 30-minute parallel session across 8 agents at moderate usage (~15,000 tokens per agent per session):
During beta, all Grok Build usage is free. Post-beta pricing is not announced. Based on current Grok API rates, 8 parallel agents at sustained use is not cheap if you run it all day. The smart pattern during beta: run your workload now, measure actual token consumption, and you will have real data to evaluate post-beta pricing when it lands.
Use our AI API cost calculator to model Grok 4 Fast vs. Grok Code 1 Fast token costs against your specific usage patterns before the beta ends.
Installation Prerequisite
The Agent Dashboard requires Grok Build 1.2.0 or later, which shipped alongside the June 15 announcement. If you installed Grok Build during the May 2026 beta, update first:
npm update -g @xai/grok-build
grok-build --version # should show 1.2.0+
The dashboard command will not exist on earlier versions. The xAI API key requirement and beta waitlist are unchanged from the original launch.
What This Signals About the Coding Agent Market
Three terminal coding agents now have meaningful multi-agent views: Claude Code (21 agents, orchestrator model), OpenAI Codex Cloud (cloud-parallel, no dashboard), and Grok Build (8 agents, dashboard model). The single-session coding agent was the entire market nine months ago. It is now the entry-level product.
The next differentiation frontier will be inter-agent coordination — agents that share state, hand off work, and reconcile outputs without human intervention at each step. Grok Build’s Agent Client Protocol (ACP) is xAI’s bet on the protocol layer for that. Claude Code’s orchestrator-worker pattern is Anthropic’s. The technical approaches are different; the destination is the same.
For now, the Agent Dashboard is a practical shipping feature. It solves a real problem (managing multiple coding sessions) with a clean interface. Whether the parallel agents can actually coordinate their work at the product layer is the next question — and that answer comes from running it on your codebase, not from the press release.
For developer tooling templates, MCP server starter kits, and coding agent setup guides, browse the WOWHOW developer tools collection. The Grok Build beta guide has the full initial feature breakdown and comparison with Claude Code and Codex from the June 5 launch.
Comments · 0
Beta: comments are stored locally on your device and not visible to other readers.
No comments yet. Be the first to share your thoughts.