Sno Station and the shared memory layer for coding agents

The problem is context that dies with the session

Coding agents are good at the task in front of them and bad at carrying state between sessions. You hit a rate limit halfway through a change, the next agent starts from a blank context, and the only way to recover is to paste the earlier conversation back in by hand. Sno Station is built around that specific failure.

The pitch is that the agents you already use become a squad. Codex, Claude Code, Cursor, Hermes Agent and OpenClaw all point at one memory, they can pass work to each other, and either one can review the other's output. The documentation makes the handoff concrete: when one agent hits its cap, you say `sno reach call` from another and it picks the task up from the same memory and the mailbox with context intact. You paste nothing.

The review path works the same way. Ask either agent to `peer-review` the other's work and the reviewer is always a different agent, on the reasoning that an agent reviewing its own output tends to agree with it. That is a small design choice with a plausible effect, and it costs nothing to use.

Who this is for is narrow but real: a developer with more than one agent installed who treats them as interchangeable workers on the same codebase, rather than a team standardising on a single tool. The value shows up when a second agent exists and the first one keeps hitting limits.

Three memory modes, and only one of them keeps your text off the network

This is the part of the project worth reading twice, because the marketing summary of "it stays yours" has conditions attached.

In Local First mode no memory text is uploaded. That is the mode where the claim that memory, messages and skills live on your computer holds without qualification.

In Agent Native mode the work goes to your own agent's model instead of Sno's, which sounds like the same thing and is not. By default, Agent Native still uploads the day's sessions to Sno each night for Self Learning, and it can bring one cloud lesson back on a session's first prompt. Both behaviours can be turned off in `~/.sno/settings.json`.

In REM Enhanced mode your own memory text and the lessons your agents learn go to your own space in Sno's cloud, where a Sno program processes them. The documentation describes that space as working like your own cloud drive, where you can open it, delete things, keep them, or choose to have them processed, and where nothing is deleted automatically. It also states that Sno does not give any of it to another person, company or account. The sharper detail is that in REM Enhanced mode, each time you send a prompt, that prompt and up to 64 of your stored memories are also sent to Sno's reranker, which puts the best matches first.

So the ranker is a separate egress path from the nightly upload, and it is the one that touches your interactive traffic. In Local First and Agent Native the ranking runs on your machine instead.

Memory itself is encrypted with a key that never leaves the machine. That protects the file at rest. It does not protect text that has already been uploaded, which is the distinction the mode settings exist to draw.

Installing it is one command, then one phrase in the chat

The install path has two halves, and the first half is designed so an agent can run it on your behalf. The documentation says the easiest way is to tell your agent `install sno.ai from GitHub`, and the fallback is a single command in any terminal:

sh -c 'sno_installer_body=$(curl -fsSL https://sno.ai/install) && printf "%s\n" "$sno_installer_body" | sh'

That downloads the installer and pipes it to a shell. It installs the `sno` binary, then Sno Station, and connects every agent it finds on the computer. No account and no API key are required for that step, and if you install another agent later, `sno setup` connects it too.

The second half happens inside a conversation. You type this into any Codex, Claude Code, Hermes, Cursor or OpenClaw session:

Sno onboard

The agent walks you through the rest, and the documentation notes that it also starts by itself right after the install. For agents being set up automatically there is a `sno skills onboard` command, which asks the user which engine to run and then asks the user to link the computer to a free sno.ai account. That last step is where the free tier is quantified: an unlinked computer gets one tenth of the free allowance.

Every command starts with `sno`, and the full list lives in `docs/sno-commands.md`. Per-agent step by step instructions are separate documents, one each for Codex, Claude Code, Hermes, Cursor and OpenClaw.

One caution on the shell installer. It pipes a downloaded script straight into a shell, which means you are trusting the remote endpoint to stay what it is today. If that matters to you, read the script first and run it yourself.

REM is the nightly pass that decides what survives

The part of the design that is unusual enough to be worth understanding is the consolidation step. The documentation calls it REM, after the Rapid Eye Movement stage of human sleep, on the reasoning that the brain strengthens memories during it.

Mechanically, REM strengthens the agents' memory across all your sessions at once. It runs at most once a day for each part of your memory: usually overnight, or earlier in the same day once about 100 new memories have piled up. So the trigger is either a schedule or a volume threshold, and it operates per memory part rather than over the whole store in one go.

Self Learning is the second half. It reads the day's sessions, finds the mistakes that keep repeating, and proposes changes to the agents' own skills, so that a repeated slip turns into a better habit. The critical detail is the approval gate: you read the proposals in the morning, and nothing changes until you say yes. The agents do not edit themselves unattended, and the skills they use are not silently rewritten while you sleep.

Forgetting is part of the design as well. The memory is supposed to keep what matters and let go of what is no longer true, and the documentation has a section on memory that forgets on purpose. In practice that means the value is in the consolidation pass, not in raw retention, and a user who expects a verbatim searchable transcript of every session is expecting the wrong thing.

The cost of the whole mechanism is that it needs a machine that is on at night, or at least a threshold of roughly 100 new memories during the day for the earlier trigger to fire.

The repository is an npm workspace with encrypted SQLite at the core

The codebase is TypeScript organised as an npm workspace, and the package manifest shows the shape of the system. Workspaces cover `apps/*` and `packages/*`, with two exclusions, `packages/chunking` and `packages/content-sanitizer`, which are excluded from the workspace list.

The build script is ordered, and the order is the architecture. The first build target is `@snoai/common-core`, then `@snoai/utils`, then `@snoai/embedder`, then `@snoai/observability`, then `@snoai/sqlite-crypto`, then `@snoai/memory`, and only after that the four per-agent packages, `@snoai/mem-claw`, `@snoai/mem-claude`, `@snoai/mem-codex` and `@snoai/mem-cursor`. The per-agent naming maps directly onto the agents the project supports, and the shared memory packages are built before any of them.

The manifest declares `[email protected]` as the package manager, sets the package to ESM, and pins the Node range narrowly:

    "node": ">=22.22.3 <23 || >=24.15.0 <25 || >=25.9.0"

That range excludes several Node lines rather than accepting a broad major, which tells you the project tests against specific releases.

On the storage side, the dependency list includes `better-sqlite3` and `drizzle-orm` with `drizzle-kit`, and there is a package named `sqlite-crypto` among the build targets, which lines up with the claim that memory is encrypted at rest with a local key. There is also `hono` for HTTP, `esbuild` and `tsx` for building and running, `biome` for linting, and `typescript` pinned at a 7.x version. The repository root carries `evals/`, `tests/`, `docs/`, `llms.txt`, `VERSION.yaml`, `VISION.md`, `REVIEW.md`, `CHANGELOG.md` and `THIRD_PARTY_NOTICES.md`, so the evaluation harness and the review process are part of the tree rather than an afterthought.

Where the local-first story breaks down

There are three places where the project's own documentation undercuts the easy version of the promise, and they are worth naming before you connect an account.

The first is the free tier. The onboarding path asks the user to link the computer to a free sno.ai account, and the documentation states that an unlinked computer gets one tenth of the free allowance. The headline claim is that no account is needed, and both are true, but they describe different levels of service, and a reduced allowance is a limit you will hit.

The second is that the installer is a piped shell script, which I mentioned above. It is a normal trade for this kind of tool and a real one for organisations with change control.

The third is the version cadence. The releases show v1.2.4 on 2026-10-08, v1.3.5 on 2026-10-13 and v1.5.1 on 2026-10-18, with the release notes carrying user-facing titles such as "Memory runs quieter" and "Your rules stay with you across agents". A project shipping three feature releases in ten days is moving fast, and the install is a copy of a script that can change under you. The repository has been public since 2026-09-18, and the last push was on 2026-10-20, so the code is current, but a fast moving project with a remote installer and a cloud component is a different risk profile from a local library you vendor and pin.

There is also a documentation gap that matters for an adopter: the visible documentation does not explain how the encryption key is generated, stored, or recovered, and it does not document a rollback if the nightly consolidation produces a bad memory state. Both are the questions a team with a data retention policy will ask first.

Against hand-rolled context files, the difference is who writes the memory

The realistic alternative is not another agent memory product. It is the practice most developers already have: a notes file, a scratch markdown file, a CLAUDE.md, and a habit of pasting the last exchange into a new session when a model changes.

The difference in approach is about who writes the memory. A hand-rolled file is written by you, deliberately, and it is only as good as the moment you chose to write it. Sno Station's memory is written by the agents as they work, then rewritten by a nightly consolidation pass that looks for repeated mistakes and proposes skill changes. The unit of knowledge is the session rather than the note, and the mechanism for improving is a proposal queue rather than your own discipline.

The cost of that approach is the one that matters for anyone outside a solo setup. The agents write to a shared store, which means a hallucinated fact can propagate from one agent to the next, and a peer review by a different agent is not an independent check if both agents read the same memory. The encryption and the local-first mode protect the data at rest and in transit, but neither one can tell you that what is in the memory is true.

If you already keep good notes and the pain is only occasional context loss, the hand-rolled file is cheaper and you control its contents line by line. If the pain is daily, the honest reason to try Sno Station is not the encryption or the peer review. It is the automatic skill proposals, because that is the part you would have to do by hand every morning.

Editorial conclusion

Sno Station fits a developer who runs two or more coding agents on one machine and keeps losing context at rate limits, and who is willing to read the privacy modes before connecting an account. It does not fit a team bound by a strict no-egress policy, because the default Agent Native mode still uploads the day's sessions for Self Learning and REM Enhanced mode sends each prompt plus up to 64 stored memories to a remote reranker. Before adopting, check two things: what `~/.sno/settings.json` disables, since that file holds both upload switches, and what the memory encrypted at rest actually protects, since a key that never leaves the machine does not help if the text has already been uploaded. The Apache-2.0 licence allows modification and redistribution, and the last push was on 2026-10-20 with v1.5.1 released on 2026-10-18.

Frequently asked questions

Official sources

1. License: Apache-2.0
2. Project website
3. README
4. Releases
5. sno-ai/sno-station on GitHub