ByteRover CLI (brv): a versioned context tree for coding agents

The problem ByteRover CLI solves for coding agents

An agent that starts each session with an empty context rediscovers your codebase every time. It reads the same files, asks the same questions, and forgets the decision your team made last week about JWT expiry. ByteRover CLI, invoked as brv, is aimed at that gap. The README describes it as a portable memory layer: you curate project knowledge into a context tree, sync it to ByteRover Cloud, and share it across tools and teammates. The intended user is a developer running an autonomous or semi-autonomous coding agent, not someone who wants a general note-taking app. The README states that brv works with 22 or more AI coding agents, naming Cursor, Claude Code, Windsurf and Cline, so the memory is meant to outlive any single editor or agent. The project was formerly called Cipher, which explains why older search results and issue threads use that name. One design choice stands out: memory is curated rather than captured automatically. You decide what enters the tree, which keeps noise down but puts a maintenance burden on the team.

How the context tree, curate and query fit together

The mechanism is a local knowledge store plus a version control layer over it. According to the README, running brv in a project directory starts an interactive REPL powered by an LLM of your choice, and that agent reads your codebase through what the README calls an agentic map. Knowledge enters through curate, which takes a statement and optional file references, and leaves through query. The README shows both as REPL commands: /curate "Auth uses JWT with 24h expiry" @src/middleware/auth.ts and /query How is authentication implemented?. The @ reference ties a claim to a file, which is the part that makes the store auditable rather than a pile of prose. On top of that sits a git-like layer exposed under brv vc: init, add, commit, branch, checkout, merge, clone, push, pull, fetch, remote and reset. That means the context tree can be branched alongside a feature branch and merged back, and curate operations can pass through a review workflow with pending, approve and reject states before they land. The README also lists a web dashboard (brv webui) as the primary UI and says most users only need that command. Two sync paths exist, and the README marks one as legacy: brv push and brv pull are described as legacy, with brv vc push and brv vc pull recommended going forward. The paper linked from the README reports LoCoMo at 96.1 percent overall accuracy over 1,982 questions and LongMemEval-S at 92.8 percent over 500 questions, both measured as LLM-as-Judge accuracy. Those numbers come from the project's own evaluation, so treat them as the authors' claim rather than an independent result.

Installing ByteRover CLI and running a first curate

There are two install paths. The shell script bundles everything and needs no Node.js; the npm package requires Node.js 20 or newer. The README lists the supported platforms for the shell script as macOS ARM64, macOS x64, Linux x64 and Linux ARM64, which means Windows users go through npm.

curl -fsSL https://byterover.dev/install.sh | sh

The alternative is the global npm install, which is the path for Windows and for anyone who already manages Node versions.

npm install -g byterover-cli

Confirm the binary is on your PATH. The README uses this as the verification step, and it should print the installed version.

brv --version

Now move into a real project and start the REPL. The README states the REPL auto-configures on first run with no setup needed, and that typing a forward slash lists the available commands.

cd your/project
brv

Inside the REPL, store one fact and then ask for it back. The first line below is the README's own example; the second is the query form.

/curate "Auth uses JWT with 24h expiry" @src/middleware/auth.ts
/query How is authentication implemented?

What you should see is a confirmation that the curate operation was recorded, and an answer to the query that draws on the stored statement. If your project has the review workflow enabled, the curate lands as a pending operation; the README lists brv review pending, brv review approve and brv review reject for that case. For a shell-based check outside the REPL, brv status reports project and daemon status. Signing in for cloud sync is a separate step: run brv login with an API key from the ByteRover Cloud settings page. Everything is described as working locally by default, so cloud is optional.

Where ByteRover CLI gets in your way

The licence is the first thing to check. The README badge says Elastic 2.0, but GitHub reports the licence as NOASSERTION for this repository, and the README does not explain the discrepancy in the text available. Elastic 2.0 is source-available, not an OSI-approved open source licence, and it restricts offering the software as a managed service. If your organisation has a blanket policy of OSI-only dependencies, this project fails that test before you evaluate anything else. The second constraint is operational: a curated context tree is only as good as the curation. Nothing in the README describes an automatic ingestion path that keeps the tree in step with a moving codebase, so a stale entry about authentication can be confidently returned months after the code changed. The review workflow exists precisely because curate writes are consequential, which also means someone has to approve them. Third, the surface area is large for what many users need. The README lists 20 LLM providers, 24 built-in agent tools, a hub and connectors ecosystem, an enterprise proxy mode and both a TUI and a web dashboard. The README itself concedes that most users only need brv webui and that the command list is for advanced users and automation. Finally, the sync story is mid-migration: brv push and brv pull are labelled legacy in favour of brv vc push and brv vc pull. Documentation and scripts written against the older pair will keep working for now, but the README does not state when the legacy commands will be removed.

How ByteRover CLI differs from plain MCP memory servers

The obvious alternative is a memory server built on the Model Context Protocol, which ByteRover CLI also supports. A typical MCP memory server exposes a small set of tools for writing and reading facts, and the agent decides what to store. The difference here is governance rather than capability. ByteRover puts version control in front of the store: branches, commits, merges, remotes and a review queue. That matters when two people are curating the same project, or when you want to see what the agent knew at the time it made a decision. A plain memory server gives you none of that history. The trade-off runs the other way too. A single-file memory server has no daemon, no cloud account and no CLI to learn; ByteRover CLI asks you to adopt a workflow. If your team is one developer on one machine who just wants the agent to remember a preference, the version control layer is overhead. If the knowledge is shared, reviewed, or has to survive a laptop replacement, the branch and remote model is the reason to pick this over a minimal alternative. The README's claim of working with 22 or more agents also points at a portability goal that a per-editor memory feature does not have.

Maintenance status, upgrade cost and licence implications

The repository is not archived. Its last push was on 2026-06-25, which is under three months before today, so the project is being worked on. The most recent release listed is v3.16.1 from 2026-05-27, with v3.16.0 and v3.15.1 in the same month, and package.json carries version 3.16.1. That cadence suggests frequent minor releases, and the dependency list explains why upgrades deserve attention: the project pins a wide set of @ai-sdk provider packages, the Model Context Protocol SDK at 1.26.0, oclif core, and two GitHub-hosted dependencies, @campfirein/brv-transport-client and @campfirein/byterover-packages. GitHub-hosted dependencies are fetched from a branch or tag rather than a registry, so a global npm install depends on those repositories staying reachable. The repository ships an @oclif/plugin-update dependency, which is the oclif mechanism for self-update, though the README does not document an upgrade command. On licensing, the README badge names Elastic 2.0 while GitHub reports NOASSERTION; read the LICENSE file at the repository root before you ship anything built on top of this, and treat the cloud service as a separate arrangement governed by ByteRover's own terms rather than by the repository licence. This is a description of what the files say, not legal advice.

Editorial conclusion

Adopt ByteRover CLI if your agents lose project knowledge between sessions and you want that knowledge reviewable, branchable and shareable rather than buried in prompt history. Skip it if you need an OSI-approved licence, if you cannot run Node.js 20 or newer and are not on one of the four bundled platforms, or if your team will not maintain the context tree. Before committing, verify which of the 20 LLM providers you will actually configure, run brv --version and brv status in one real repository, and read the LICENSE file at the repository root, because GitHub reports NOASSERTION while the README badge says Elastic 2.0.

Frequently asked questions

Official sources

1. campfirein/byterover-cli on GitHub
2. Issues
3. Project website
4. README
5. Releases