On June 22, 2026, xAI shipped a mode called /goal inside Grok Build, its terminal coding agent. You hand it one instruction, such as migrating an auth module, and it plans an approach, builds a checklist, edits and runs code, and keeps working until it can verify the result. Verification takes three forms: reviewing its own code, inspecting webpages, and running scripts. You steer it with status, pause, resume, and clear, and you can keep adding instructions while it runs. Access needs a paid SuperGrok or X Premium Plus plan, and the underlying model, grok-build-0.1, has a 256,000 token context. The capability is real and documented. The parts to treat with care are the vendor performance claims and any consumer dollar figure, since xAI's pricing page is not machine-readable.
If you have ever asked a coding agent to do something real and then spent the next hour babysitting it through every edit, xAI's newest addition is aimed squarely at you. On June 22, 2026, xAI added a mode called /goal to Grok Build, its terminal coding agent. The pitch is simple: give it one instruction, walk away, and come back to finished, verified work. The capability is real and documented on xAI's own site. Some of the numbers and comparisons floating around it are not settled yet. This piece keeps those two things apart.
What xAI actually shipped
Grok Build is xAI's coding agent and command-line tool for software engineering. It first appeared in May 2026 as a terminal-native agent: you point it at a project directory, describe a task in plain English, and it inspects the repository, finds the relevant files, and proposes and applies changes. That much has been true since launch.
What changed on June 22 is the addition of /goal, which xAI describes as a long-running, autonomous execution mode. Instead of the usual back-and-forth where you approve one change at a time, you give the agent a single higher-level goal and it runs the whole loop itself. MarkTechPost, which covered the release the day it landed, summed up the behavior as: the agent "plans an approach, builds a checklist, executes, and verifies until complete."
The example xAI leads with is a migration. You type something like a request to move the auth module to a new API, and /goal treats that as the finish line rather than a single edit. It works out the steps, changes multiple files, runs the code, checks whether the goal is met, and keeps going if it is not. Crucially, xAI is explicit that /goal is a mode within Grok Build, not a separate product. You are not learning a new tool, you are unlocking a new gear in one you may already run.
So the confirmed core is short and specific: a new mode, shipped on a known date, that turns a one-line instruction into a self-driving plan-execute-verify loop inside an existing agent. Everything else below either expands on that or flags where the public information gets softer.
How the plan-execute-verify loop works
The most useful way to understand /goal is as three repeating phases rather than a single action.
First, it plans. When you hand it a goal, the agent does not start editing immediately. It works out an approach and turns that approach into a checklist. This matters because it gives the run a structure you can inspect. Instead of a wall of edits with no visible logic, there is a list of intended steps that the agent is working through, which is far easier to trust and to interrupt sensibly.
Second, it executes. The agent modifies files, and it does so across as many of them as the task needs. A migration or a refactor is rarely one file, and /goal is built for exactly the multi-file, multi-step work that makes single-shot prompting frustrating. It edits, it runs, and it moves down its checklist.
Third, it verifies, then loops. This is the part that separates /goal from a fancy autocomplete. The agent does not assume its edit worked. It checks, and if the check fails, it goes back and tries again. The loop continues until the goal is actually satisfied, not until the model runs out of things to say. Developers Digest, in its Grok Build guide, describes the mode as one where "the agent plans work, executes until the condition is met, and verifies the result," which lines up with xAI's own framing.
The design point underneath all of this is patience. A normal chat-style agent is optimized to give you a response. /goal is optimized to reach a condition. Those are different objectives, and the second one is what you want when the task is "make this true," not "tell me about this."
The three ways it checks its own work
Verification is where autonomous agents usually fall down, so it is worth being precise about what /goal actually does. According to the launch coverage, the agent's verification can take three forms.
It may review the code it produced. This is the lightest check, a read-back of its own changes to confirm they match the intent of the step.
It may inspect webpages to confirm behavior. For anything that renders or runs in a browser, the agent can look at the resulting page rather than trusting that the code should work. That is a meaningful step up from static self-review, because it tests the outcome, not the intention.
It may execute scripts to test the result. This is the strongest of the three. If your project has a test suite or a script that proves the goal, the agent can run it and read the outcome. A goal phrased as making the test suite pass becomes something the agent can objectively confirm, because the script either passes or it does not.
The honest read here is that verification quality tracks the quality of what you give it. If your repository has real tests, /goal has a hard signal to aim at and its self-checking is genuinely useful. If it does not, the agent is left with the softer forms of verification, and you should treat "done" with more caution. This is not a knock on the feature. It is the same truth that applies to any autonomous system: it can only confirm what your project makes confirmable.
What you need to run it, and how to start
Grok Build is a command-line tool, and /goal lives inside it, so the setup is the setup for Grok Build itself.
On macOS and Linux you install it with a single shell command that pulls the installer from x.ai and pipes it to bash. On Windows the equivalent runs through PowerShell. Both routes are published in xAI's own installation instructions and repeated across the independent guides, so the install path is not in dispute.
Access to the agent is gated behind a paid xAI plan. The coverage points to SuperGrok or X Premium Plus as the qualifying consumer plans, and Grok Build can also authenticate with an xAI API key for developers who work against the API directly. On the specific dollar amounts, hold your certainty. xAI's consumer pricing page is not reliably machine-readable, and third-party write-ups have quoted plan prices that shift between sources. The only figure worth banking is the one you read yourself on x.ai at the moment you subscribe. Treat any secondhand monthly number, including the ones in developer guides, as a prompt to go and check rather than a fact to budget on. [VERIFY PRICE against x.ai/pricing]
Once you are in, the steering commands are the part you will use constantly. You get a status view that shows live progress against the checklist. You get pause, which stops the work while keeping the goal intact. You get resume, which picks it back up. And you get clear, which abandons the goal entirely. Just as important, xAI says you are not locked out while a goal runs. You can keep feeding the agent extra instructions mid-flight, which turns the run from a black box into something you can nudge without killing and restarting.
Where /goal fits: the model and the API underneath
None of this floats free of xAI's model lineup, so it helps to place it.
The default engine behind Grok Build is grok-build-0.1, an agentic coding model with a 256,000 token context window, per xAI's official model documentation. That context size is the practical constraint that matters for autonomous runs: it sets how much of your codebase and history the agent can hold at once while it works through a multi-step goal. For tasks that need heavier reasoning, Grok Build can be pointed at a larger flagship model with a wider context instead, so /goal is not welded to a single model, it is a mode that runs on whatever coding-capable model you configure.
On the developer side, the economics are clearer than the consumer side because the API rates are published. grok-build-0.1 is listed at 1.00 dollar per million input tokens and 2.00 dollars per million output tokens in xAI's model docs. That is the number to reason about if you are running Grok Build against the API rather than a consumer plan, and unlike the subscription prices, it is an official figure you can cite. A long autonomous run naturally consumes more tokens than a single prompt, since planning, execution, and repeated verification all add up, so the API rate is the right lens for anyone estimating what heavy /goal use would cost at scale.
Grok Build also supports the Model Context Protocol, which lets it plug into external tools and services rather than living only inside your local files. That extends what a goal can reasonably cover, because the agent can reach the systems your work actually touches instead of being boxed into the repository alone.
What is confirmed versus what is still a claim
This is the section to read slowly, because the gap between the two categories is where people get burned.
Confirmed and safe to repeat: /goal exists, shipped on June 22, 2026, and runs as a mode inside Grok Build. It plans, executes, and verifies. Verification can mean reviewing code, inspecting webpages, or running scripts. The control commands are status, pause, resume, and clear. You can add instructions during a run. The default model is grok-build-0.1 with a 256,000 token context, and its API rate is 1.00 and 2.00 dollars per million input and output tokens. All of that is either on xAI's own pages or consistent across the independent coverage.
Treat with care: any consumer dollar price, including the monthly plan figures quoted in secondhand guides. Also treat with care any claim about a specific two-model internal pipeline or a named companion model driving the planning, since that detail appears in some write-ups but is not consistently confirmed and is not something xAI states plainly in the material we can read. And treat with the most care any performance comparison that says /goal or Grok Build beats a named competitor at autonomous coding. Those framings tend to originate from vendor messaging or enthusiast benchmarks, not from independent, reproduced tests. The feature can be genuinely good and still not have earned a leaderboard claim yet. Keep the capability and the scoreboard in separate mental boxes.
The reason for this discipline is not pedantry. Autonomous coding is exactly the area where a confident wrong claim costs you real time, because you delegated the work and stopped watching. The safer posture is to trust the documented mechanics, verify the prices yourself, and let independent benchmarks catch up before you repeat any "best in class" line.
Should you turn it on yet
Here is the answer-first version. If you already pay for a qualifying xAI plan and your projects have real tests, /goal is worth trying today on a contained task, because the verification loop has something solid to aim at and the steering commands mean a bad run is cheap to stop. If you do not have tests, or you are weighing a subscription purely on secondhand price quotes, slow down: confirm the current price on x.ai yourself, and start /goal on low-stakes work where you can eyeball the result, until you have seen how it behaves on your codebase.
The bigger picture is that xAI is clearly pushing Grok Build from an assist-you agent toward a do-it agent, and /goal is the clearest signal of that direction so far. It sits alongside the rest of xAI's recent developer moves, from the Grok Build agent itself to the wider API build-out, as part of a steady push into autonomous tooling rather than a one-off feature. Whether it becomes a daily driver depends on how well the self-verification holds up on messy, real repositories over the coming weeks, which is precisely the thing no launch post can tell you and only hands-on use will. Try it small, keep the price check honest, and let the independent benchmarks settle the bragging rights.
Questions readers ask
What is /goal in Grok Build?
It is a long-running autonomous mode xAI added to Grok Build on June 22, 2026. You give the agent a single goal, such as making a test suite pass, and it plans the work, builds a checklist, edits and runs code, and continues until it can verify the result. It is a mode inside Grok Build, not a separate product.
How does /goal check its own work?
Verification takes three forms. The agent can review the code it wrote, inspect webpages to confirm behavior, and execute scripts to test the result. It keeps iterating until one of those checks passes for the goal you set, rather than stopping after a single edit.
What do I need to run it?
Grok Build is a command-line tool you install on macOS, Linux, or Windows, and /goal runs inside it. Access to the agent needs a paid xAI plan such as SuperGrok or X Premium Plus, or an xAI API key. Confirm the current plan requirements and any price on x.ai before you commit, since consumer prices change and are not always machine-readable.
Which model powers Grok Build?
The default model is grok-build-0.1, an agentic coding model with a 256,000 token context window. For heavier reasoning you can point Grok Build at a larger flagship model instead. On the developer API, grok-build-0.1 is billed at 1.00 dollar per million input tokens and 2.00 dollars per million output tokens per the official model docs.
Can I interrupt a running goal?
Yes. You get status to see live progress, pause to stop while keeping the goal, resume to continue, and clear to abandon it. You are not locked out during a run either, so you can keep giving the agent extra instructions while it works.