xAI's Coding Agent Now Remembers Your Project Between Sessions. It Also Writes That Down.

What happened

xAI added persistent memory to Grok Build, its command-line coding agent. Grok Build is xAI’s tool for writing, editing, and running code by chatting with it in a terminal (a text-only window for typing commands directly to your computer), in the same category as tools like Claude Code or Codex.

Until now, every new Grok Build session started from scratch. You’d have to re-explain how your project’s tests run, which conventions your team follows, or why a piece of code works the way it does, every single time.

With memory, Grok Build now writes notes on that context in the background after each turn (one back-and-forth exchange between you and the agent) finishes. According to xAI, it records conventions, decisions, and project facts, while deliberately leaving out details specific to whatever task was underway, half-formed conclusions, secrets, and anything already documented in the repository (the stored folder holding your project’s code and its history). Later sessions read those notes before touching related code.

Why it matters

The notes are stored as plain markdown files, organized by scope. Project-level notes live in topic files, like one for testing and one for code style, scoped to that specific project. A separate global scope holds preferences meant to apply everywhere you use Grok Build.

Two new commands manage this. /memory opens a read-only view of every stored note, grouped by scope, so you can see exactly what Grok Build has written down about your project. /dream reorganizes recent notes into the right topic files, and also runs periodically on its own in the background.

xAI’s announcement doesn’t say whether these notes are private to you or visible to anyone else with access to the same project workspace (the local folder Grok Build works in), which matters if you work with a team or client on shared infrastructure. It’s a real gap to be aware of, since the whole point of the feature is that it quietly accumulates details about how your project works.

Who should care

This is most useful if you already use Grok Build for a project that spans more than one sitting, where you’d otherwise repeat the same context every session. If you only use Grok Build for quick, one-off edits, there’s less here for you, since memory mainly pays off across repeated sessions on the same codebase.

It’s also worth a look if you’re evaluating coding agents generally. Persistent, file-based project memory is becoming a common pattern across this category, not something unique to one vendor, and it’s worth understanding how each tool you use handles it.

What builders should do next

Run /memory after a few real sessions on a project and actually read what it captured. Confirm it matches what you’d want written down, and that nothing sensitive slipped through despite xAI’s stated exclusions for secrets.

If you want to see whether memory is actually saving you time, compare it directly. Pick a bounded task, like adding a new API endpoint (one specific address your app responds to, such as the one that handles a signup form) that follows an existing pattern in your codebase. Do it once in a session where you manually re-explain your conventions, and once in a session where Grok Build’s memory already has that context from prior sessions.

Compare two things: how many times you had to correct or re-explain something the agent got wrong, and how many turns it took to reach a version you’d actually ship. If memory isn’t measurably cutting down on repeated corrections, it’s not doing its job yet for that project.

End of article