Grok Build's Global Memory Outperforms Claude Code in Cross-Project Retention Test

Both xAI's Grok Build and Anthropic's Claude Code claim to retain context from earlier coding sessions. xAI rolled out memory capabilities in Grok Build on September 16, positioning the feature as a way to preserve "conventions, decisions, and project facts" for use in subsequent work. Anthropic's Claude Code has offered comparable functionality through auto memory for several months. To evaluate how well each system actually remembers instructions across sessions, I ran identical tests on both tools using small Node repositories.

How the memory systems work

Grok Build stores notes as Markdown files in two scopes: workspace scope for individual projects and global scope that applies universally. The /memory command lets users browse these files. Claude Code maintains a MEMORY.md index alongside individual note files organized per repository, with the feature enabled by default. Anthropic also introduced Projects beta on September 17, which enables shared memory across cloud threads for select Pro and Max subscribers, though this requires no existing projects. The CLI version available to all users was the focus of this evaluation.

Test methodology

Each tool received identical instructions across three separate tests, with a session break between the initial instruction and the follow-up task. Grok Build 1.0.40 ran Grok 4.6 at high effort via xAI API, while Claude Code 2.1.226 ran Opus 5 on a subscription. Both tools operated on separate copies of four small Node repositories on macOS, with each session executed in headless mode to capture token usage and costs.

Test one: Build command preference

Session one established that make test succeeds while npm test fails in a given repository. After closing the tool and removing the README reference to the Makefile, session two requested a new endpoint with passing tests. Both Grok and Claude Code passed this test. Grok documented the rule in topics/testing.md and immediately ran make test in the second session without attempting npm test. Claude Code created orbit-api-run-tests-with-make.md with explanatory sections and similarly avoided the failing command. Grok completed the task in 29 seconds using 102K tokens at $0.11, while Claude Code finished in 22 seconds with 186K tokens at $0.32—roughly three times the cost despite using 80K additional tokens.

Test two: Project decisions with misleading code

Session one specified that CSV export had been discontinued and monetary amounts use integer cents rather than floats, with the repository intentionally containing unused float helpers and partial CSV export code as distractors. Session two requested a refund endpoint accepting an amount parameter and a download mechanism for support staff. Both tools correctly recorded the decisions and adhered to them. Each built the refund using integer cents and named the field amountCents, ignoring the float helper. For the download feature, both provided JSON export rather than CSV. Claude Code additionally converted "last quarter" to "Q2 2026" in its notes. Grok required 103 seconds, 156K tokens, and $0.18, while Claude Code took 32 seconds, 269K tokens, and $0.49—more than double the cost at comparable speed.

Test three: Rules spanning multiple projects

Session one, running in repository A, established two rules intended "for all my projects": conventional commit messages and no comments on obvious code. Session two switched to an unrelated repository B and requested a small feature with a commit. This test revealed a critical difference. Grok saved the rules to its global scope as git-and-code-style.md and successfully applied them in the second repository, generating a commit message "feat: add --help flag with usage and supported cities" without unnecessary comments. The task completed in 33 seconds, 132K tokens, and $0.12. Claude Code saved both rules but confined them to the first repository's memory folder. When session two ran in repository B, Claude Code found no applicable memory and produced a commit message reading "Add --help flag" without the conventional format. Claude Code passed the first rule by coincidence but failed to enforce the second. The work finished in 12 seconds, 122K tokens, and $0.24.

Results summary

Grok Build passed all three tests while Claude Code passed two. On per-project memory tasks, both tools performed identically—each wrote markdown notes immediately upon receiving instructions and read them back in subsequent sessions. The decisive difference emerged in cross-project retention. Grok's global scope carried the universal rules into the second repository without additional configuration. Claude Code's per-repository memory boundary prevented it from accessing rules saved in a different project directory.

Claude Code demonstrated faster execution across all recall sessions, completing work in 66 seconds total compared to Grok's 165 seconds. However, Claude Code cost at least twice as much on every individual test, totaling $1.05 against Grok's $0.41. Token consumption also favored Grok: 390,848 tokens versus Claude Code's 576,863. The price differential primarily reflects the underlying model economics of Opus 5 versus Grok 4.6 rather than differences in the memory systems themselves.

Claude Code produced more polished memory notes with better formatting and explanatory sections. On the fundamental claim—remembering instructions from the previous session within the same project—both tools proved equally capable. Each wrote markdown notes upon receiving rules and successfully retrieved and applied them. The critical limitation emerged when attempting to apply project-wide conventions across different repositories. Grok's global scope carried such rules forward automatically, while Claude Code's architecture required manual intervention, such as copying rules into ~/.claude/CLAUDE.md, to achieve the same result.

Assessment

Grok Build represents the stronger choice for most users at this stage. It retained all tested information, successfully transferred rules across projects, and delivered results at less than half the cost of Claude Code on every test. Claude Code's speed advantage becomes irrelevant if accuracy suffers. The per-repository memory boundary means that any convention intended for universal application must be manually maintained outside the tool's native memory system. For teams managing multiple repositories with shared coding standards, Grok Build's global scope provides a meaningful advantage without requiring workarounds.