Grok Build's Memory Outperforms Claude Code in Cross-Project Retention Test
xAI's Grok Build and Anthropic's Claude Code both launched memory features for coding agents this month, but a direct comparison reveals a critical difference: only Grok carries rules across multiple repositories.

When xAI rolled out memory capabilities for Grok Build on September 16, the company promised that its terminal coding agent would "keep notes on the conventions, decisions, and project facts that come up," with "later sessions read those notes before touching related code." Anthropic had already been offering something comparable through Claude Code's auto memory feature for several months, and followed up with a Projects beta announcement on September 17 that adds shared memory across cloud threads for select Pro and Max subscribers.
To determine whether these memory systems actually work as advertised, I ran identical tests on both tools using Grok Build 1.0.40 running Grok 4.6 and Claude Code 2.1.226 running Opus 5. The fundamental question was straightforward: if you tell a coding agent something in one session, close it, and reopen it, will it remember what you said?
How the memory systems work
Grok stores notes as Markdown files in two scopes: a workspace scope that applies to individual projects and a global scope that applies everywhere. Users can browse these notes with the /memory command. Claude Code maintains a MEMORY.md index plus one file per note, organized per repository, with the feature enabled by default.
The three tests
I ran each tool through three separate tests on my Mac, with each tool working on its own copy of four small Node repositories I created. Every session was scripted using each tool's headless mode, which reports token usage and cost.
Test one: The test command
In the first repository, npm test fails while make test passes. During session one, I informed the tool of this fact. After closing the tool, session two asked for a new endpoint with passing tests—but I removed the README line that had pointed to the Makefile, so the tool had to rely on memory.
Both tools passed. Grok wrote topics/testing.md plus two raw observations, while Claude Code created orbit-api-run-tests-with-make.md with "why" and "how to apply" sections. In the second session, both remembered: Grok's reasoning began with "start by reading the memory files" before running make test, and Claude Code read the Makefile and package.json, also choosing make test over npm test. Grok completed the task in 29 seconds using 102K tokens at a cost of $0.11, while Claude Code finished in 22 seconds using 186K tokens at $0.32.
Test two: Project decisions with a trap
Session one established two project decisions: CSV export had been dropped, and money should always be stored as integer cents, never floats. The repository contained a float helper and a half-built CSV exporter as deliberate distractions. Session two asked for a refund endpoint that "takes an amount" and "a way for support staff to download all orders."
Both tools recorded both decisions. Claude Code even converted "last quarter" into "Q2 2026" in its note. In session two, both built the refund using integer cents and named the field amountCents, leaving the float helper untouched. For the download request, both delivered a JSON export. Grok's reasoning noted that the API is JSON-only and therefore would not implement CSV, while Claude Code added a content-disposition header so the JSON downloads as a file. Both passed both decisions, but Claude Code cost more than double the price while matching Grok's speed. Grok took 103 seconds, 156K tokens, and $0.18, while Claude Code took 32 seconds, 269K tokens, and $0.49.
Test three: A rule across projects
Session one, in repository A, established two rules "for all my projects": use conventional commit messages and avoid comments on obvious code. Session two ran in an unrelated repository B and asked for a small feature and a commit. This test revealed the critical difference between the two systems.
Grok saved the rules to its global scope as git-and-code-style.md. In the second repository, it committed "feat: add --help flag with usage and supported cities" and added no comments. Pass, in 33 seconds, 132K tokens, and $0.12.
Claude Code saved both rules, but only in the first repository's memory folder. The tool warned at the time that its memory store "is scoped to this project's directory." In the second repository, it found nothing, and the commit came back as "Add --help flag." No comments were added, but that reflects Claude's default behavior anyway. Claude passed the first rule but failed the second one, and the task still cost twice as much. It completed the work in 12 seconds, 122K tokens, and $0.24.
Results
Grok Build passed all three tests. Claude Code passed two. On the per-project tests, they behaved identically. The split came down to the cross-project rule: Grok's global scope carried the rule into a second repository, while Claude Code's per-repository memory did not.
Claude Code was faster on every recall session, completing all three in 66 seconds total compared to Grok's 165 seconds. However, Claude Code cost at least twice as much on every single test, totaling $1.05 against Grok's $0.41. Token usage also favored Grok: 576,863 tokens for Claude Code versus 390,848 for Grok. The price gap largely reflects the difference between Opus 5 and Grok 4.6 rather than the memory systems themselves.
On the core claim—remembering what you told it last time in the same project—the two tools were indistinguishable. Both wrote a markdown note immediately upon receiving a rule, read it back in the next session, and followed it. Claude Code's notes were better written. But Claude Code failed the third test. Its CLI memory stops at the repository boundary, so a rule given "for all my projects" never reached the second repository. Grok's global scope carried the same rule over without being asked.
The verdict
Grok Build is the better choice for most users right now. It remembered everything, it carries rules across projects, and it cost less than half as much on every test. Claude Code was faster on every session, but that advantage matters only if accuracy is not a concern. Its CLI memory stops at the repository boundary, meaning anything you want it to remember everywhere still requires manual entry into ~/.claude/CLAUDE.md.