xAI's Grok 4.6 Launch Funnels You Into Grok Build. It Was Quietly Uploading SSH Keys There a Month Ago.

On August 12, xAI — the company now doing business as SpaceXAI — shipped Grok 4.6, a new flagship model tuned for long-running agent work, and paired the release with a first-week promotion: double the included usage for anyone routing traffic through Grok Build, xAI's terminal-based coding agent, or through Cursor, which added the model on day one.

That promotion is the part worth stopping on. Grok Build is the same tool that, a little over a month earlier, was caught quietly shipping entire developer repositories — commit history, and in at least one documented case SSH keys — to a Google Cloud bucket xAI controlled. xAI's fix was a server-side flag, not a code removal, and its trust-rebuilding gesture was to publish the source under a license that explicitly does not accept outside contributions. None of that appears anywhere in the Grok 4.6 launch material. The model announcement and the tool it's being pushed through are, at the moment, two very different stories, and developers evaluating the model are mostly only hearing one of them.

What actually shipped on August 12

Grok 4.6 is a 500K-context model xAI is positioning explicitly for "long-running agents" — tasks that span dozens or hundreds of tool calls rather than a single completion. xAI's own framing is that the model "stays with complex tasks across many steps," whether that's researching a topic, working across a codebase, or turning a rough product brief into a working first version of an app. On longer trajectories, xAI reports the model does more self-testing and verification along the way, checking its own output before moving to the next step rather than running the whole plan open-loop.

On Artificial Analysis's Intelligence Index, Grok 4.6 scores 61 — up five points from Grok 4.5, and enough to pass Moonshot AI's Kimi K3. That score also ties OpenAI's GPT-5.6 Sol Max and sits two points behind Anthropic's Claude Opus 5. The tie is worth qualifying before you treat it as a headline: it holds on the nine-benchmark composite Artificial Analysis publishes, but in xAI's own ten-row comparison table, Claude Fable 5 wins more individual rows than Grok 4.6 does. A composite score compresses a lot of variance into one number, and here the variance is doing real work — Grok 4.6 is reported strongest on knowledge work and legal reasoning, and weakest on terminal use, which is an odd soft spot for a model whose flagship delivery vehicle is a terminal application.

Pricing held flat at $2 per million input tokens and $6 per million output tokens — the same headline rate as Grok 4.5. That's unusual; frontier releases typically ship a capability bump and a price bump together. But the flat number is a headline, not the full rate card. Cross a 200K-token prompt and the entire request — not just the overage — gets billed at $4 in / $12 out. Cached-input pricing rose 67% in the same release, from $0.30 to $0.50 per million tokens. For a model marketed on its ability to sustain long agentic sessions, both changes land exactly where the heaviest users of that feature will feel them: the developers running the biggest contexts and the most cache-heavy multi-turn sessions are the ones who trip the cliff and absorb the cache increase. The model is available through the xAI API, OpenRouter, Vercel, and Cloudflare, in addition to Cursor and Grok Build.

What Grok Build actually is

Grok Build isn't new — it's been in beta since May 2026 — but the 4.6 launch is the moment xAI is pushing it hardest. It's a terminal UI coding agent: fullscreen, mouse-interactive, and built to read files, edit code, and run shell commands directly in a developer's environment. It can run interactively via the TUI, headlessly in scripts and bots, or embedded in other applications through the Agent Client Protocol. It also has a distribution feature most competing agents don't: because Grok has live access to X/Twitter data and web browsing, it can pull current information mid-session instead of working from a training-data snapshot.

The codebase is a substantial release — a Rust workspace north of a million lines covering the agent loop, the file-editing and shell-execution tools, the terminal UI itself, and an extension system for skills, plugins, hooks, MCP servers, and subagents. It also supports a genuinely useful local-first mode: teams can compile it themselves, point it at their own inference endpoint, and drive the whole thing from a local config.toml — which matters directly for any organization whose security policy prohibits sending proprietary source to a third-party cloud.

That local-first option exists, not coincidentally, because of what happened in July.

The incident the launch doesn't mention

In mid-July, a security researcher using the handle Cereblab ran mitmproxy against Grok Build CLI version 0.2.93 and found an undocumented storage channel. The client was uploading data — 5.1GB across 73 chunks in the observed session — to a Google Cloud Storage bucket named grok-code-session-traces. What was going up wasn't telemetry or crash logs. It was full Git bundles: every tracked file plus the repository's complete commit history. If a developer's repo had ever had an API key, database password, cloud token, or SSH key committed at any point — even if it was later removed from the working tree — that credential was in the history, and the history went up whole.

A privacy toggle in the client did not stop the behavior; researchers who tested it reported the uploads continued regardless of the setting. xAI's response was to flip a server-side flag on July 13 that halted new uploads. The upload code itself stayed in the shipped binary — disabled at the server, not removed from the client. Around the same window, xAI published Grok Build's full source on GitHub under an Apache 2.0 license as xai-org/grok-build, which read, reasonably, as a transparency move in response to the backlash.

It's a genuine transparency move, but it's worth being precise about what it isn't. xAI's own contributing guidelines say external pull requests aren't accepted — this is source-available, not community-governed — and security issues are routed through HackerOne, not filed as public GitHub issues. You can read the code that runs on your machine. You can't meaningfully audit or influence what runs in xAI's cloud, and you can't submit a fix upstream if you find something. Given that the original problem was an undocumented cloud upload path, "you can now read the client-side source" answers a narrower question than "can I trust what this tool does with my code."

Why this matters more than the benchmark number

Treat these as two separate decisions, because the pricing math and the trust math don't move together. On the model: Grok 4.6's real pitch isn't "smartest model available," it's price-to-intelligence — tied-for-third on a composite index at a headline rate that, taken at face value, undercuts GPT-5.6 Sol and Claude Opus 5. If you're mostly running short- to medium-context requests and can live with output that's reportedly stronger on knowledge work than on terminal-heavy agentic tasks, that's a legitimate value proposition, and it's the reason OpenRouter, Vercel, and Cloudflare all lit up support on day one.

On the delivery vehicle: Grok Build is a capable, actively developed agent with a real architectural advantage — the local-first mode is not vaporware, and it directly addresses the exact failure mode that got the tool into trouble in July. But "capable" and "currently trustworthy with a fresh incident un-mentioned in the marketing" are different claims, and the launch promotion is explicitly designed to get more usage flowing through the cloud-connected version, via the same 2x-usage incentive, in the same week the flagship model dropped. A developer who sees "Grok 4.6, day-one Cursor support, double usage this week" and starts a trial has no reason to know about the July incident unless they go looking for it separately, because it isn't referenced in the announcement, the docs, or the pricing page.

For teams making an actual adoption decision, the practical checklist is short: if you use Grok Build at all, use the local-first build against your own inference endpoint, not the hosted cloud path, at least until there's a public accounting of what else the client does with data by default. If you're on the hosted version and were on it in the June/July window, rotate any credentials that ever touched a tracked repository, not just the ones currently in your working files — deleting a secret from disk doesn't remove it from Git history, and that history was exactly what got exfiltrated.

Practical use cases, if you accept the tradeoffs

Long, single-session refactors and codebase-wide migrations are the clearest fit for the 500K-context, self-verifying design xAI is describing — tasks where a model that checks its own work between steps is worth more than one that's marginally smarter per-token but runs open-loop. Cost-sensitive teams already comfortable with OpenRouter or Vercel AI Gateway routing can slot Grok 4.6 in as a cheaper alternative to GPT-5.6 Sol for workloads that don't reliably exceed 200K tokens per request — the moment they do, the pricing advantage partially evaporates. Teams with hard data-residency or IP requirements are the best-positioned to actually benefit from Grok Build specifically, because they're the ones most likely to already require the local-first, self-hosted-inference configuration that sidesteps the cloud-upload question entirely.

What the announcement leaves out

Three things stand out by omission. First, the July incident is absent from every piece of Grok 4.6 launch material — not disputed, not addressed, just not mentioned, even though the launch is actively driving new users toward the same client. Second, the pricing page leads with the flat $2/$6 headline and buries the 200K-token cliff and the 67% cache-price increase in the fine print, which matters specifically because the product being marketed is long-context agentic work — the exact usage pattern most likely to cross that line. Third, early hands-on reports are mixed in a way the benchmark score doesn't capture: some testers report strong broad performance, others report Grok 4.6 underperforming GPT-5.6 Sol in short real-world sessions, which is a normal spread for a week-old release but worth knowing before treating the Artificial Analysis number as a settled verdict.

Competitive context

Grok 4.6 lands into a field where GPT-5.6 Sol and Claude Opus 5 are the incumbents on raw capability, Claude Fable 5 is quietly winning more individual benchmark categories than the composite scores suggest, and Kimi K3 has been the price-competitive open-weight option Grok 4.6 now edges out on the index. On the tooling side, Grok Build is entering a coding-agent market that already includes Cursor (which it's partnering with rather than competing against directly), and cloud-native agents like Devin, where the differentiator xAI is leaning on — real-time web and X data access mid-session — is genuinely distinct rather than marketing language, since none of the major competing agents ship that by default.

The independent read

Grok 4.6 itself looks like a reasonable, price-competitive update — not a leap, but a real one, and the self-verification behavior on long trajectories is a sensible response to the actual failure mode of long agentic runs (compounding small errors across many steps). The problem isn't the model. It's that xAI is using a flagship model launch to drive fresh usage into a tool with an unresolved trust question, without surfacing that question anywhere a developer evaluating the launch would naturally encounter it. A server-side flag that stops uploads without removing the upload code, paired with a source release that explicitly declines outside review, is a narrower fix than "we solved this." Pairing that with a usage-doubling promo the same week a new model drops is a distribution decision, not a security decision, and it's fair to notice that the two are happening at the same time.

Who should try it, and who should wait

If you're experimenting solo or on side projects, Grok 4.6 through the API, OpenRouter, or Cursor is low-risk and worth a look purely on the price-to-intelligence math — just watch your context length against the 200K cliff before you commit a workload to it. If you're evaluating Grok Build for a team, compile the local-first build and point it at your own inference before letting it near a real repository, and treat the hosted cloud path as unproven until xAI publishes something more specific than "we flipped a flag" about what data it does and doesn't retain. If your organization has compliance requirements around source code leaving your environment, wait — not because the model is bad, but because the tool most associated with using it well just had a bad month, and "the code is now public" is not the same claim as "the behavior is now fixed."

What's your line for when a source-available release actually restores trust versus when it's just a PR response to a breach — does read-only transparency without contribution rights or an independent audit clear that bar for you, or does it need more?

Sources: