It arrives on its own
The memory is in context before reasoning starts. There is no tool for the agent to call, no moment where it must notice something is missing, and nothing for it to forget.
NEW
GRM 6.1 + Hivecode — the memory and the coordination, both shipping
Your agent knows before it thinks.
Your agent knows before it thinks.
And it stops overwriting the one working beside it.
Agents forget when the session ends, and run two on one codebase and they overwrite each other. These are the two halves of the same missing layer, and both are built. GRM is the memory — no tool to call and nothing to remember to do, it finds what you already settled and puts it in context before the first token of reasoning. Hivecode is the coordination — several agents and you in one live codebase, each fenced to the folders you chose.
Free to install and use • 20–30 ms recall • No API key, no model call, no metering.
Zero-config in
Claude Code
Cursor
Antigravity
VS Code & Windsurf
Any terminal, through a local proxy
> why did we bind the licence key to the machine instead of just an expiry date
## From memory (recalled by the memory engine)
[2026-08-14] GRM licence keys are machine-bound as of 15 Aug 2026, built
because Ganesh asked what stops a buyer posting their key online
where thousands use it free until expiry with no way for us to know
[2026-08-14] The id is FNV-1a over the system volume serial and hostname,
salted, printed as 12 hex characters — derived locally, never
transmitted, and not reversible into anything about the machine
[2026-08-14] trials | a key with no machines runs anywhere, which is correct
for a trial shipped inside the download and wrong for anything sold
--- from the source code ---
[File: pm-rs\src\license.rs, Block: 3]
/// The date inside a key is absolute, so a 7-day trial key minted
/// today is dead on the 22nd for everybody -- including the person
/// who downloads it on the 21st and gets four hours.
pub const TRIAL_DAYS: u64 = 7;
cues: bind licence key machine instead expiry date
Real output, captured from a live install — a decision from an earlier session
and the source that implements it, delivered without the agent asking for anything.
(The [2026-08-14] timestamp is recorded in UTC, which is why the conversation text inside reads 15 Aug 2026 after midnight in Indian Standard Time.)
GRM · the memory
One Rust binary, about 1 MB, running on your machine. It reads the history already on your disk and puts the relevant part into context before the agent starts reasoning. Nothing in it calls a model — no API, no embeddings, no GPU — so a recall costs nothing and works the same in any agent rather than one vendor's.
How it works →Hivecode · the coordination
Several agents and you in one live codebase, with no push and no pull. You watch every edit as it lands, an agent only ever receives the folders you fenced it to, and when two of them change the same file the merge reads the structure of the code rather than the lines. Open source, MIT.
See it running →01 / How it works
Two things decide whether a memory is worth having: whether it turns up unasked, and what it costs to keep running.
Memory that arrives, and never leaves
Nothing to call, nothing to configure per project, and no bill that grows with how much you use it.
It works on a three-word prompt
ok do it gives a search nothing to search on. At the end of the previous turn the agent already said what it was about to do, and the answer was fetched then and set aside.
Exact identifiers, not approximations
The precise filename, function name, error string or compiler flag you asked about. No near-misses, and no invented detail presented as fact.
It knows when to stay quiet
Across 715 recorded decisions it said nothing 297 times rather than crowd your context with a guess. Silence is what makes the rest of it trustworthy.
No model, no embeddings, no GPU
The ranking is arithmetic over words you already wrote. That is why there is nothing to meter, nothing to rate-limit, and no per-query bill — ever.
Your memory is a file you own
One document on your disk. Read it, copy it, back it up, delete it. Uninstalling takes all of it with you and leaves nothing behind.
02 / Watch it
Recordings and a screenshot, all off this machine. Nothing staged and nothing removed. One cut below compresses idle time only, and says so on screen while it does.
Watch it check its own memory against the repo
A brand-new session, told to answer only from memory — no file reads, no grep.
Then told to prove every claim with git and the ordinary tools any
agent already has.
Claude Code
memory, then verified on disk
19 files +1351/−253,
api/webhook.js:102, 44 assertions — every one exact.
And then it does not stop there. It lists three things it got
wrong: a sixth failure it never reported, a test count that was right
at that commit and is stale today, and a line range off by two. The
last thing on screen is the agent diagnosing its own miss — recall kept
returning prose about the commit and never the commit message
itself, and it read that absence as weak evidence and talked itself out
of a correct answer.
1 min 46 s.
Two more ways it reaches an agent
The memory reaches an agent two ways. On the left it is asked and answers. On the right nobody asked — it was already there.
Antigravity IDE
asked for it
Memory [recall]
fires and dated blocks come back. Then the agent ends its own answer with
[[next: …]], writing down what it expects to need. On the
following turn the answer arrives marked
“pulled from the pre-fetched context, no recall call needed.”
46 seconds.
Claude Code
nobody asked
Neither of these was re-shot for this page. Both were typed at working speed, typos and all — the model reads intent, not spelling.
03 / Measured
Every decision the engine made was logged as it happened, then scored afterwards against what was actually written next.
Numbers from real work
Not a benchmark. Two months of one developer's real history, searched by the automatic half of the memory — the part that speaks without being asked.
24,625
memories held
56.7%
of what it volunteered was used in the work that followed
92%
carried something the agent did not already have
100%
stays on your machine
| Words of conversation and source | 2,005,699 |
| Characters, as 24,625 memories | 13,694,306 |
| Distinct words | 32,323 |
| Blocks of source code | 2,404 |
| Days without a gap | 66 |
| Recorded decisions | 715 |
| Times it spoke | 418 |
| Times it stayed silent | 297 |
How the 56.7% is counted. An engine cannot be asked whether it helped — hand any model an answer that agrees with what it already thinks and it will say yes. So it is not asked. Every volunteered memory is compared against what was written afterwards, and counts only if material from it appears there. Anything the memory quoted back to itself is excluded.
It averages two very different days. One scored 74.6%, the other 34.3%. The high day moved between unrelated pieces of work; the low day was one long unbroken session on a single subject, where the answer to almost everything was already a few screens up. On that day the share of memory genuinely new to the session fell with it, 27.6% to 20.0% — there was simply less left to tell.
One way the measure is unfair to itself. A memory only scores when its words turn up in what gets written next, so hours spent writing code and shell commands score low however useful it was. The real figure is better than the one shown. It is reported this way on purpose.
None of it comes from the search tool. This scores only what arrived unasked. Memory the agent deliberately went looking for is not counted.
04 / Not that kind of tool
Why the familiar retrieval scores cannot be run against this, and what is published instead.
There is no benchmark for arriving uninvited
The standard memory scores are retrieval scores. They were built for a different job, and running them here would flatter the half of this product that matters least.
Retrieval answers. This interrupts. Retrieval-augmented generation is given a question and asked to find the passage that answers it. That is a real problem and it is well measured. It is not this problem. The half of GRM that does the work is never given a question — it decides, before you have finished typing, that something settled weeks ago bears on what you are about to do, and says so unprompted. Nobody asked. There is no query to score.
A held-out set needs a question to hold out. Every retrieval benchmark is built the same way: a query, a passage that should be found, an answer that should come out. Point that at GRM and you can only grade the search tool it also happens to have — the part an agent calls deliberately. The measured page above excludes that part entirely, on purpose. What is scored there arrived without being asked for.
The corpus is you. Public benchmarks ship a fixed body of documents so that everyone competes on the same ground. This one's corpus is your own history, and it is never uploaded anywhere — that is the product, not an implementation detail. A score earned on somebody else's documents tells you nothing about your Tuesday.
Different definition of success. Retrieval asks whether the right passage came back. This asks whether what it volunteered turned up in the work that followed. The first measures the fetch; the second measures the consequence. A tool can be excellent at the first and useless at the second, and only the second changes your day.
Different shape entirely. No model runs. No index is built from your code by a third party. Nothing is sent anywhere, so there is no per-query bill and no latency floor set by somebody else's API. Comparisons drawn against cloud retrieval services are comparing two things that do not share a failure mode.
We publish no head-to-heads. Numbers gathered by us, on a corpus we chose, against products we chose, in our own favour, are worth nothing to you — and everyone in this category has a table proving they win. So there isn't one here. What is published instead is the section above: every decision logged as it happened, scored against what was written next, with the counting method and the days it did badly printed alongside.
The only comparison that settles anything. It runs for seven days without a card. Point it at your own history and read the numbers off your own machine.
05 / When it fails
A memory that has broken looks exactly like a memory that knows nothing. Telling those apart is a feature.
The failure you cannot see
Staying quiet is the right answer most of the time. That is what makes this hard. When something does go wrong it produces the same silence, and nothing in the agent's reply tells you which of the two you just got.
Every decision is written down, including the silences. Not only what was injected, but why nothing was: the engine was not running, no history matched, too few usable words in the question, or it ran out of time. Those need four different fixes. A product that records them all as “nothing found” cannot point at any of them.
One command reads that log and gives a verdict. grm doctor checks
the licence, the memory file, the journal, whether the engine answers a real query
rather than merely accepting the connection, whether the watcher is running,
whether your code folders actually resolve, and whether the editor hooks are both
registered and able to start — which is not the same thing, and has been
the difference before.
It reports its own slowness as a fault. On 17 August 2026, on the machine
this was built on, 15% of lookups were running out of time and returning nothing —
and doctor said everything checked out, because it counted those as
the memory being discreet. It now names the rate and calls it a warning. A memory
that is unreliable one time in seven is a different product from one that is quiet
on purpose, and the tool that reports on it should not be the last to notice.
Nothing here is sent anywhere. The log is a file on your own disk. Nobody
else can read it, us included — which is the reason doctor has to be
this thorough. It is the only thing that is ever going to look.
06 / The other half
Memory fixes one agent forgetting. This fixes several of them working at once. Same missing layer, other end.
Several agents in one codebase, without a merge at the end
The industry's answer to running two agents at once is to give each its own git worktree. That does not solve the collision, it postpones it to a merge where git compares lines and does not care whether the result still runs. Hivecode puts them in the same file instead, and makes the collision visible while it is happening.
Hivecode
three agents, one codebase, live
What is actually holding it together
Six mechanisms. None of them require the agents to cooperate, which is the point — an agent behaving badly should not be able to damage anything it was never handed.
One connection per file
A room is not one document. Every file is its own live channel, so an agent
working in api/ holds open exactly the files it was fenced to and
nothing else. The isolation is structural rather than a filter applied after
the fact.
Scopes enforced at the relay
Out-of-scope access is refused at connect with a 403, by the server, before any content is sent. An agent outside your fence is not blocked from writing the file — it never receives the file at all. The client runs the same check locally, and the relay does not trust the client's answer.
Claims that expire
An agent claims a file before working on it and everyone else sees the claim. Claims carry a lease and die on their own, so a crashed agent cannot leave a file locked forever. Coordination without a lock nobody can clear is the difference between this and every checkout system that failed.
Merging on structure, not lines
When two agents change the same file, the merge parses both versions and
reconciles functions, imports and blocks against each other. If it cannot parse
a side it refuses to merge rather than guessing — so it never hands back
a file that no longer compiles. The engine is its own MIT package,
icr-merge, usable without the rest of this.
Signed history and instant rollback
Every write is recorded with its author, its parent version, a hash of the content and the stated intent. Any version is addressable, so undoing a bad change means naming the version you want rather than reconstructing it. You can always answer which agent wrote a line, and what it said it was doing.
Silent forks get caught
A character-level merge always converges — which means two agents
writing return 2 and return 3 can converge on
return 23. It is valid code, it errors nowhere, and nobody wrote
it. Because both versions were signed against the same parent, the history
still holds the truth the merge destroyed, and the room says so instead of
letting it through.
Load-tested on this machine. Five agents, 55 concurrent edits and three collisions on the same line. All twelve files ended byte-identical on all five peers.
Where it runs. Free and MIT on GitHub and npm, with a VS Code extension and an MCP server so an agent in a plain terminal joins a room the same way. Point it at the hosted relay, or run the relay yourself and nothing leaves your network.
One honest difference from GRM. GRM makes no network calls at all. Hivecode is a shared workspace, so the files in a room reach the other people and agents in that room and pass through whichever relay you point it at. If that is not acceptable for a codebase, self-host the relay — it is the same MIT code, and that is the reason it is published.
07 / Install
No account, no sign-up, no API key. The trial licence is inside the download.
Running in about a minute
One binary, three commands, then quit your agent and open it again. That is the whole procedure on every platform.
01
Initialize GRM in 1 command
Run the universal initializer. It automatically downloads the high-performance native binary, configures hooks across Claude Code, Cursor, and Antigravity, and starts the in-RAM daemon.
# ── 1-Command Universal Setup (All Platforms) ──────────
npx getgrm init
# Or install globally via npm
npm install -g getgrm
grm start
02
Check that it is actually running
One command tells you where the memory lives, how many blocks are in RAM, whether the watcher has caught up with your transcripts, and which ports the daemon is answering on. Real output from this machine:
grm status
memory home ~/.grm
snapshot graph.grm (16.93 MB)
journal 0.00 MB, last written 92s ago
ingest ok - caught up with 222 transcripts
hook daemon :8791 listening
http/cors :8792 listening
stream proxy :8000 listening
blocks in RAM 26,700
daemon version 6.1.8, uptime 3h 12m
03
Name the projects you want it to read
Your conversations are picked up automatically — every Claude Code, Cursor and Antigravity session already on the machine is read during the install. Your code is not, until you say which folders. The installer leaves an empty code_roots.txt beside the memory file; put one project path on each line. Keep it short — a handful of real projects beats every folder on the disk.
# code_roots.txt — one path per line
C:\Users\you\code\my-project
C:\Users\you\code\other-project\src
04
Fully quit your agent, then open it again
Closing the window is not enough — an agent reads its configuration at launch, so a session already open has not seen any of this. After that it is on, and there is nothing else to run. grm doctor checks every part of it and names the fix for anything that is down.
grm doctor
GRM 6 System Health & Diagnostics
[ ok ] Active snapshot: ~/.grm/graph.grm (16.93 MB)
[ ok ] Canonical path: one graph for every IDE on this machine
[ ok ] Ingest: watcher is caught up
tracked transcripts: 222
heartbeat: 1s ago, 0 failure(s)
[ ok ] Blocks indexed: 26,700 (live daemon)
version 6.1.8, uptime 3h 12m
[ ok ] TCP hook daemon: :8791 answering
[ ok ] HTTP/CORS server: :8792 online
[ ok ] Journal size: 0.0 KB
GRM diagnostics completed: all checks passed.
One command checks every part and names the exact fix for anything it finds. It is also the first thing to send us if you get stuck. Real output, captured from a live install.
08 / Plans & Pricing
GRM has no server behind it, so it is sold per machine. A Hivecode room needs a relay, so that is sold per person. Agents are never charged for.
Priced on what it costs to run
GRM is a local binary with no marginal cost, so the licence is the whole price and there is nothing to meter. Hivecode is open source and free to self-host; you pay only when you want the relay run for you. Everything is sold by the year.
Free
For one developer, on one machine, with as many agents as you like.
$0
/ forever
- GRM, complete and local: no cap on memories, no metering
- 20–30 ms recall with no API key and no model call
- Claude Code, Cursor, Antigravity, VS Code, Windsurf — anything else through the local proxy
- Hivecode, MIT: full source, run the relay yourself
- VS Code extension and MCP server included
- GitHub issues
FOR ONE DEVELOPER
Pro
For a solo developer who wants rooms hosted rather than run, and a licence that covers commercial work.
$99
/ machine / year (₹2,999)
- Everything in Free
- Hosted Hivecode rooms — nothing to deploy
- Commercial licence for GRM
- Encrypted memory backup and cross-machine restore
- Priority builds and direct email to the person who wrote it
Team
For a team running agents together on one codebase, where somebody has to be able to say who is allowed to touch what.
$30
/ developer / month, billed yearly — agents free
- Everything in Pro, for every developer
- Relay-enforced folder scopes: an out-of-scope agent never receives the file
- Approval gates and instant rollback to any past version
- Signed history: which agent wrote it, against which parent, and why
- Control Room — every agent and every edit in one view
- Shared memory across the team's machines
Agents are free on purpose. Everyone else charges per agent seat, which taxes exactly the behaviour they are trying to sell. A team that adds a fifth agent should pay nothing more; they should pay when they hire a sixth engineer. That way the bill tracks headcount, which finance already budgets for.
$30 is deliberately under the agent itself. Cursor Business is $40 a seat and Copilot Business is $19. This is the layer that stops those agents overwriting each other's work, and it should not cost more than the thing it protects.
Enterprise: the relay inside your own network, SSO, an exported audit log of
every write, and an annual contract.
Email support@getgrm.tech — you reach the engineer who built it, usually the same day.
09 / Questions
The things people ask first
If something here is not answered, mail us — you reach the person who wrote both of these, not a support queue.
Does my code or my conversations ever leave this machine?
GRM: no, and there is nothing to configure to make that true. No cloud service, no embedding API, no vector database, no telemetry. The binary makes no network calls of any kind. Your memory is one file on your disk.
Hivecode is different and it would be dishonest to lump them together. A room is a shared workspace, so the files in it reach the other people and agents in that room and pass through whichever relay you point at. Use the hosted relay and your room's files transit it. Run the relay yourself — it is MIT, and that is why it is published — and nothing leaves your network. GRM on its own is unaffected either way.
What does it actually store?
Sentences you and your agent already wrote, and blocks of code from folders you point it at, each with a date. Nothing is summarised by a model and nothing is sent anywhere to be processed.
What happens if the background process stops?
The memory goes quiet and your agent carries on. The hook gives up within a quarter of a second rather than making you wait, restarts the background half, and tells the agent plainly that memory was unavailable — so a fault is never mistaken for you having no history.
Do I need an API key, or a model provider?
No. GRM does not call a model to store, to summarise or to retrieve — the retrieval is arithmetic on a graph, not inference. There is no key to supply and no usage to meter, so the licence is the entire cost of running it. A memory that bills per query is a memory you think twice before using.
What are the requirements?
About 1 MB, one file. No Python, no Docker, no database, no runtime to install — it imports nothing but the operating system's own libraries. Windows and Linux on x86-64, macOS on Apple Silicon.
How long before it is useful?
Immediately. It reads the history already on your machine during install, so it knows your past work from the first question — you do not have to use it for a month first.
Do I need both?
No. They are useful separately and most people start with one. GRM is worth installing if a single agent keeps forgetting what you settled last week. Hivecode is worth it the day you run a second agent on the same repository. Together, the agents in a room can also share what the room already knows.
Why not just give each agent its own git worktree?
That is the standard answer and it does not fix the problem, it postpones it. Two isolated agents still edit the same functions, and you find out at the merge — where git compares lines and has no opinion on whether the result runs. Hivecode makes the collision visible while it is happening, and when a merge is unavoidable it reads the structure of the code rather than the lines, and refuses to produce a file it cannot parse.
What stops an agent touching a folder I did not give it?
The relay. Every file in a room is its own connection, and one outside an agent's scope is refused at connect with a 403 before any content is sent. It is not that the agent is blocked from writing — it never receives the file. The client runs the same check, and the relay does not trust the client's answer.
How do I remove it?
Delete the folder and the .grm directory in your home folder. Hivecode is an ordinary npm package and a VS Code extension — uninstall them the usual way. That is all of it. Nothing else is written anywhere that matters.