Grok Build Memory: How Cross-Session Memory Works for Coding Projects
2026-09-18
xAI added memory to Grok Build on September 16, 2026. Notes on conventions and project facts carry across sessions, managed with /memory and /dream.
xAI shipped memory for Grok Build on September 16, 2026, and the feature targets a problem anyone who codes with an AI assistant knows too well. Close the session and the context resets.
Grok Build memory is the answer to that reset. It carries conventions, decisions, and project facts from one session into the next, which means the details you'd normally re-explain every time survive the session boundary. Grok Build gets better the more you use it, and that improvement comes from the notes it keeps, not from a model swap.
How Grok Build Memory Captures a Session
The mechanism is deliberately quiet. After a turn completes, Grok reviews it in the background and records anything durable. Capture runs on every completed turn, and it never interrupts the session or blocks your next prompt.
What counts as durable is a narrow set. Grok Build cross-session memory holds the details most likely to matter later: how your team writes and reviews code, decisions and the reasoning behind them, and steady facts about the project. Where a subsystem lives. Which command actually runs the test suite.
Just as important is what it leaves out. Task state, tentative conclusions, secrets, and anything the repository or its docs already cover don't get written down. That's a sane line, and it's the difference between a memory that helps and one that clutters every future session with stale guesses.
The capture is per project, plus a global set for preferences that apply everywhere. So your personal style rules follow you across repos, while project-specific conventions stay scoped to the project they belong to.
What Grok Build Remembers and What It Skips
The practical value shows up in the mundane details. A concrete example from xAI's own walkthrough: you try cargo test, watch it fail against a Postgres connection, and tell Grok the project uses just test instead because it starts the test database first. That single correction becomes a note. On a later session, when you ask for a retry with backoff on the webhook sender, Grok reads the testing note before it runs anything and reaches for just test instead of repeating the mistake.
One correction now. Nothing to retype later.
That's the whole proposition in one loop. One correction now saves the same correction forever after.
The scope of Grok Build features leans practical rather than clever. It remembers how the team works, the decisions behind the code, and durable project facts. It doesn't try to remember your mood, your half-formed ideas, or a task you were midway through. A memory that tried to hold all of that would degrade fast, because task state goes stale the moment you stop working on the task.
/memory and /dream: Two Commands That Manage It
Two commands give you control over what's stored, and the split between them is clean.
/memory opens a read-only browser of every memory file, grouped by scope, with a preview of the selected file. It's how you see what a session actually produced and find the exact file to edit when a note is wrong. There's a search filter, and the file list shows sizes and timestamps, so you can spot a note that just landed.
Read-only by design. You edit the file, not the browser.
/dream does the organizing. It merges new observations into the topic they belong to, folding scattered notes into topic files with one subject per file. Over time each project ends up with a small set of references instead of a pile of fragments. Dream also runs on its own periodically in the background, so the consolidation doesn't depend on you remembering to trigger it.
Under the hood, Grok Build project memory is markdown. Notes are files, one topic per subject, and you can open them, read them, and edit them outside the tool. That's a reassuring design choice if you've been burned by opaque memory systems you couldn't inspect.
Reading Notes Back in Later Sessions
Capture only matters if the other half works, and the read-back is where Grok Build earns its keep.
So what happens when a note is wrong or out of date?
Before starting related work, Grok reads the topics that cover the area and applies them. There's a subtle detail in xAI's description: this includes sessions where the subject never comes up. So if you're working on a webhook change, Grok may still apply the project's testing conventions, because the notes that cover testing are relevant even when "testing" never appeared in your prompt.
One rule governs conflicts, and it's the right one. Instructions in the current conversation take precedence over anything in a note. If you tell Grok something that contradicts a stored convention, the live instruction wins. Memory informs, it doesn't override. That keeps you in control when a project's direction changes and the old notes haven't caught up yet.
Turning Memory On and What It Applies To
Grok Build update details on availability are specific. Memory is live in Grok Build now, and it applies to new sessions. Run /new or start a fresh grok, and notes begin after the first completed turn.
Installing the CLI takes a single command, and the tool runs in a terminal, so this is a developer workflow rather than something you point a browser at. To download it, run the installer script from xAI's site, or install the package from the vendor directly. The memory layer sits on top of the same coding assistant you'd already use, adding continuity rather than changing how you interact with it.
The one caveat about timing: sessions started before you enable memory won't have notes, and a session needs at least one completed turn before anything is captured. So the benefits accumulate rather than appearing on the first prompt.
Benefits and Limitations of Cross-Session Memory
The upside is straightforward. You stop repeating yourself. Conventions you've already stated get applied without a reminder, decisions stay consistent across sessions, and the knowledge you build about a project compounds instead of resetting. For long-running work, that's a real reduction in overhead, and it's why the "gets better the more you use it" pitch holds up as more than marketing.
The limits are worth stating plainly. Memory depends on the quality of what gets captured, and a wrong note that nobody edits will keep steering future sessions. The read-back happens per project, so moving between repos means each one builds its own notes from scratch. Global preferences cross over, but project facts don't.
There's also a privacy dimension. Notes are stored as files, which means secrets shouldn't land there, and xAI says secrets are excluded by design. That's a safeguard, not a guarantee, so it's still on you to keep credentials out of prompts where the assistant might reasonably record context. If your work involves sensitive material, check what's in the note files before you assume it was filtered.
And the memory doesn't replace real documentation. It records what came up in conversation, which means a project's unwritten assumptions are only captured if someone mentioned them. A codebase with weak docs and weak conversation will produce weak memory.
Bottom Line
Grok Build memory solves a specific, annoying problem in AI-assisted coding: the reset button that wipes your context every session. The design choices are sensible, from background capture that never blocks you to markdown files you can read and edit.
If you already run Grok Build on an active project, turning memory on costs nothing and starts paying back within a few sessions. Keep an eye on the notes, especially early on, because memory rewards projects whose conventions are clear and punishes ones where a stray comment becomes lasting policy.
NEWS
REVIEWS
HOWTO
