Both xAI’s Grok Build and Anthropic’s Claude Code have introduced persistent note‑taking for their terminal coding agents, allowing the tools to recall facts across separate CLI sessions. For engineers who automate code generation, the way these memories are scoped, the token overhead they incur, and the cost impact directly affect CI pipelines, developer productivity, and budgeting.
Memory Model Differences
Grok Build stores notes as Markdown files in two locations: a per‑project workspace and a global workspace that applies to every repository on the machine. The /memory command can list these files. Claude Code uses an MEMORY.md index plus one Markdown file per note, all confined to the directory of the repository where the agent was invoked. The documentation states that this memory is enabled by default.
In practice, Grok’s global scope means a rule written in one repo is automatically visible in any other repo on the same host. Claude’s per‑repo store isolates notes, so a rule saved in repository A does not appear when the agent runs in repository B unless the user explicitly copies the files.
Recall Speed and Token Consumption
Both agents were exercised on four small Node.js projects using scripted headless sessions. Each test consisted of a “plant” session that recorded a fact, followed by a “recall” session that required the fact without restating it.
- Test 1 – test command selection: Grok took 29 seconds, consumed 102 K tokens, and cost $0.11. Claude took 22 seconds, consumed 186 K tokens, and cost $0.32.
- Test 2 – project decisions with a trap: Grok required 103 seconds, 156 K tokens, $0.18. Claude required 32 seconds, 269 K tokens, $0.49.
- Test 3 – rule across projects: Grok required 33 seconds, 132 K tokens, $0.12. Claude required 12 seconds, 122 K tokens, $0.24.
Overall, Claude Code completed the three recall sessions in 66 seconds, used 576 K tokens, and cost $1.05. Grok Build required 165 seconds, used 391 K tokens, and cost $0.41. The token and cost differences align with the underlying model versions (Opus 5 vs Grok 4.6) rather than the memory implementation itself.
Cross‑Project Rule Propagation
The third test highlighted the practical impact of scope. A rule stating “use conventional commit messages and omit comments on obvious code” was saved in the first repository. When the agent ran in a second, unrelated repository, Grok automatically applied both parts of the rule because its global memory file (git-and-code-style.md) is consulted regardless of the current repo.
Claude, however, warned that its memory store is scoped to the project directory. In the second repository it found no applicable notes, so it obeyed only the “no comments” part (which is Claude’s default) and omitted the commit‑message convention. This resulted in a partial pass (2 of 3 tests) for Claude.
Related CloudNinjas coverage: AI engineering.
What This Means For Practitioners
When choosing an AI‑assisted coding agent, consider the following actionable points:
- Scope of memory matters. If you rely on shared conventions across many micro‑services or mono‑repo components, a global memory store (Grok) reduces duplication and ensures consistent enforcement without extra scripting.
- Token and cost budgeting. Claude’s faster recall comes at a higher token count and roughly three times the cost per session. For high‑frequency CI runs, Grok’s lower token usage can translate into measurable savings.
- Operational simplicity. Both agents write human‑readable Markdown notes, which can be inspected or version‑controlled. Grok’s global files live alongside project files, while Claude’s per‑repo notes stay within each repository, simplifying cleanup but requiring manual propagation for cross‑repo policies.
- Performance trade‑offs. Claude’s recall steps are quicker, but the overall test suite time was dominated by the work the agents performed (e.g., generating code). The speed advantage may be less noticeable in larger pipelines where code generation dominates runtime.
In short, for teams that need consistent policy enforcement across many codebases and are cost‑sensitive, Grok Build currently offers a more practical memory model. Teams that prioritize raw recall speed and are comfortable managing per‑repo memory files may find Claude Code acceptable, provided they do not depend on cross‑project rule sharing.