Grok Build threatens Cursor as an agent platform, not as an editor

If Grok Build really is assembled around Grok 4.5/4.6, Workflows, Grok Bot and Imagine, then Cursor will be competing not with an editor but with a whole agent system. That does not mean Cursor disappears tomorrow: its data may turn out to be not a weakness but xAI's main asset.

The most important part of the story is not the rumours about Grok 4.6 in Arena. The source contains no official card, no separate model ID, no price and no SLA for that model. So it is too early to turn a hidden badge into proof of a new generation.

Far more interesting is what has already been described about Grok Build. This is not merely a terminal with a chat but a harness around the model: repository, shell, file edits, MCP, sandbox, permissions, hooks, plugins and subagents. The agent can not only write code but run it, check the result, receive an error and carry on working.

And that is where the criterion of quality changes. Printing tokens faster does not mean finishing the task faster. It is more useful to count time_to_verified_result: how long it took to reach green tests or a working prototype, counting tool calls, retries and human review.

For Grok 4.5 the source gives around 80 tokens per second, $2 per million input tokens and $6 per million output. In the Coding Agent Index, Artificial Analysis priced a task in Grok Build at roughly $2.49 — cheaper than the GPT-5.5 in Codex and Fable 5 in Claude Code given for comparison. But a low price proves nothing by itself: if the agent breaks the environment and then repairs its own mess, the saving evaporates.

Then comes what "coding" tools usually lack. Workflows can parallelise a large task across 128 agents, with a limit of up to 1,024 claimed for big jobs. Grok Bot works not only with a repository but with a browser, files, the command line and SaaS interfaces that have no decent API.

The idea of skills and routines is especially practical: demonstrate a process once, turn it into an instruction, then run it on a schedule or an event. That way an agent can prepare a list of client risks, gather data from GitHub and Slack, or update a spreadsheet. This is no longer "asking a model to do something" but an attempt to automate a repeatable operational procedure.

Cursor here looks not like the loser but like a supplier of valuable raw material. Cursor confirmed that trillions of tokens of developer–agent interactions went into training Grok 4.5: real repositories, errors, tool calls and fixes. Such a sample teaches a model not to answer elegantly but to drive a task to a result.

But there is an important caveat: Cursor separately acknowledged the risk of contamination. An early snapshot of its codebase may have got into the training data and given Grok 4.5 an advantage on CursorBench; for future models that data was removed. So the phrase "Grok 4.6 was trained on the whole Cursor sample" cannot be treated as confirmed.

The limitations are not decorative either. Access to Grok Bot depends on particular tariffs and trial options, and several bots use one cloud computer where cookies, files, logins and team credentials may be shared. That is not a security boundary. Sensitive processes need approvals, separate service accounts with minimal rights, a read-only mode at the start, and a ban on external sends without confirmation.

So I would not frame the question as "will Grok Build kill Cursor". The real question is different: can xAI turn a set of agents, browser routines, checks and visual tools into a dependable production cycle where the human controls risk rather than repairing the consequences of the model's work.

Choosing for your team today, which matters more: a stronger model in the chat, or an agent that is slower but reliably drives a task to a verified artefact? Source: All articles / Artificial Intelligence / Habr