Testing /goal Mode in Grok Build

I’ve been testing the new /goal mode in Grok Build CLI on a fairly big project. This particular goal was a deep dive into a cybersecurity audit of a new project. I was watching changes happen deep in the system, and it wasn’t exactly the kind of work where you want things to suddenly crash or go sideways halfway through. The core idea behind /goal is solid. You throw one objective at it and the agent plans the work, spins up subagents when it makes sense, runs its own verification steps, and keeps going until it’s done. That hands-off capability is genuinely useful, especially on longer tasks where you don’t want to babysit every change. xAI clearly built this with real development workflows in mind, and I appreciate that. The fact that it can run for 40+ minutes and handle its own checklist is a step in the right direction. That said, the experience got a little stressful. I started the goal and watched the context usage climb. It got up to 182k out of 200k at one point. I’ll be honest, I was sweating a little watching that number keep rising. Because this was security audit work with changes happening deep in the project, I really didn’t want the session to blow up or get into a bad state mid-process. I tried using the control commands a few times. I sent /goal pause twice and then /goal status. Nothing happened right away. The commands just sat in the history while the agent kept working through its steps. Eventually the system auto-compacted on its own and brought the context way down, which was a relief. But the bigger surprise came later. Those pause and status commands I sent earlier were finally processed after a delay of about 10 to 15 minutes. By the time they actually took effect, the agent had already moved past the long-running verification step I was trying to interrupt.

What Needs Improvement The control commands feel half-finished right now. When you’re running a long autonomous goal, you need to be able to check in or pause it without wondering if your input is just going into a black hole. Right now it seems like the commands only get processed when the agent hits a natural idle point, which can take a while. That’s not great for something designed to run unattended for extended periods. xAI should probably be more upfront about how these commands actually behave during active execution. A little clearer documentation on the timing and limitations would help a lot. Also, some kind of visible feedback when a command is queued versus when it actually takes effect would reduce the guessing game.

Lessons Learned If you’re going to use /goal right now, here’s what I’d suggest based on what happened to me: Scope your goals smaller than feels natural. The longer it runs, the more chance you have of control commands getting delayed or ignored. Don’t assume /goal pause will stop things immediately. In my case the commands took quite a while to even register. Keep an eye on the context usage, especially on bigger tasks. The auto-compaction helped, but I got uncomfortably close to the limit before it kicked in. If you need to stop a goal quickly, /goal clear seems more reliable than pause based on what I’ve seen so far. Once commands finally start processing again, you can use /goal resume to pick things back up if you had successfully paused it.

Bottom Line /goal has real potential. The autonomous execution part works well enough that I’ll keep using it, but I’m going to be much more careful about how I structure goals until the control commands become more responsive. The feature is powerful, but right now it still feels like it needs some polish on the steering side. I was genuinely relieved when those commands finally processed and I could see what was actually happening. Just would’ve been nice if it hadn’t taken that long, especially when you’re in the middle of security work you’d rather not have to restart.