1.The High Cost of a Cluttered Context Window

Working with AI coding agents can be frustrating. You've probably experienced it: your coding agent suddenly becomes slow, token costs explode, or a task fails due to a context window limit. While you might blame the model, the real issue is often a cluttered agent context window.

Imagine a construction worker who, for every single task, must first inspect every tool in their toolbox. Before hammering a nail, they examine the saw, the wrench, and the screwdriver. After each hammer strike, they repeat the full inspection. This is how many AI agents operate. They are forced to load the definitions for every single available tool into their limited context window for every step of a task.

This inefficiency stems from the standard for connecting agents to tools: MCP. While powerful, the standard implementation loads everything upfront and confuses the agent with too many tools that it won’t need all for any single task.

2. Why Byterover Is Moving from MCP to CLI

Put simply, CLI is the best way for agents to interact with context as agents are natively fluent in CLI thanks to heavy pretraining on shell commands.

Anthropic has already called this out in their latest blog (Code execution with MCP: building more efficient AI agents \ Anthropic). Visually, in this example below, we only added three MCP servers (Byterover, Linear, and Notion), but they already ate up 26% of my context window).

In our own rebuild of Byterover, we also ran into the practical side of this: MCP installation and tool triggers were not consistent across IDEs, extensions, coding CLIs, or LLMs. Put simply, MCP heavily relies on models’ tool call capabilities and we also have to compete with users’ other installed MCPs for an already limited context window.

Anthropic’s proposed direction - code execution - flips that pattern. Instead of pre-defined tool calls, the agent writes code to interact with tools, letting the deterministic code do the heavier work in a sandbox outside the context window. The rationale behind it is simple: LLMs are good at writing code and they do it only when needed (no “40+ tools” added straight up to context). 

This maps almost perfectly to one interface agents already “know”: the command line. A good CLI is effectively a compact, discoverable code API - the one the model is natively fluent in thanks to heavy pretraining on shell commands.

A CLI-first, code-execution surface is the cleanest way to keep agents lean and effective so we are shifting to CLI.

👉 Sign up for the Beta CLI now →

👉 Read documentation →

⚠️ A side note:

This version is still in beta. We recommend trying it first on personal or side projects.

Now, here’s what that unlocks:

3. Four Breakthroughs We Unlocked with Byterover CLI

Adopting a CLI-first methodology for our agent's tools didn't just solve the context problem; it unlocked several fundamental improvements that are simply not feasible with MCP.

3.1. Progressive Disclosure: Stop Drowning Your Agent in Context

Progressive disclosure is the principle of providing information only when it's needed (we also see this in Agent Skills). The standard MCP, as discussed earlier, does the opposite, pre-loading every tool definition into the context window whether the agent needs it or not.

A CLI, by contrast, is built for progressive disclosure. An agent doesn't need to know every possible command and flag upfront. It can start with a single command and discover more functionality on-demand using familiar flags like --help. This allows the agent to load only the specific tool definitions required for the current task into its context.

This diagram shows, for the same task steps (S0→S4), how a Byterover CLI keeps the agent’s context lean by adding only the active command/output—brv retrieve → brv add → brv complete—while the hypothetical MCP begins preloaded with all tool schemas and descriptions, leading to heavier token use.

3.2. Native Fluency: Agents Already Think in Commands

Models are extensively pre-trained on codebases, of which shell commands constitute a large part, making it a foundational skill. In contrast, tool-calling is often a capability added in post-training, which represents a less ingrained behavior.

By presenting tools via a CLI, we tap models’ pretraining on shell commands—agents “think in commands” by default. That native familiarity makes execution reliable and consistent across providers and avoids the “it works on my agent” problem caused by model-specific tool-calling quirks, especially on lower-tier LLMs.

Another key win: no more agent-specific MCP setup. Install byterover-cli, run brv login and brv init, and you’re done—one interface that works across all your agents/LLMs, without per-agent configs or duplicate installs.

In short: with Byterover CLI, you get a uniform, command-first interface that models already know how to use well.

3.3. Sophisticated Memory: Treat Context Like Code with Git-like Operations

While a standard context window is ephemeral—forgotten once the session ends—Byterover makes context persistent and structured, essentially Git for agents’ context. 

Its core memory operations are analogous to Git commands, making context management as intuitive as version control:

• brv add (like git add): This command stages new knowledge into playbook.json. The agent can add detailed instructions, code snippets, or best practices under a specific section, creating a structured knowledge base.

• brv add --bullet-id (like git commit --amend): This is how knowledge is updated. By re-running the add command with an existing bullet ID, the agent can overwrite or refine a specific piece of information.

• brv push (like git push): Uploads local playbook.json changes (new/updated bullets) to the remote Byterover space so teammates and agents can retrieve them.

• brv retrieve (like git pull): This command pulls relevant, version-controlled context from Byterover memory store. 

• brv status (like git status): Shows a quick snapshot of your project’s context state—what space you’re in, whether you’re authenticated, and what’s changed in playbook.json since the last update.

A Git-based memory turns context into a trustworthy, auditable system of record—something pure MCP retrieval/storage can’t match—so teams can rely on their agents’ knowledge the same way they rely on versioned code.

3.4. Comprehensive Awareness: A Project-Wide Brain, Not Just Single-Task Memory

Because the Byterover CLI lives directly within your project, it can manage context holistically rather than just for a single, isolated task. This is powered by the Agentic Context Engineering (ACE) workflow, triggered by the brv complete command.

When a task is completed, the ACE workflow automatically executes three phases:

1. Executor: Saves the details of the task, including the goal, the reasoning, and the final outcome.

2. Reflector: Analyzes what happened during the task, tagging related entries in the playbook.

3. Curator: Creates and applies an update to the playbook.json file, adding the new knowledge gained from the task.

This workflow captures everything: the files that were read and edited (--tool-usage), the response from the environment (--feedback), and even insights learned from failures. Over time, this process transforms Byterover memory space file from a simple list of notes into a comprehensive, project-wide "brain" that learns, evolves, and improves with every task.

Conclusion

Byterover is moving from MCP to a CLI-first surface for one simple reason: it keeps agents lean and effective. MCP front-loads definitions and pushes every step through the context window; our CLI embraces progressive disclosure, so agents load only what they need, when they need it, running faster, costing less. 

Beyond speed, CLI gives teams durable, auditable context and project-wide awareness. With Git-like memory and the ACE workflow, everyday work is captured, reflected on, and curated into reusable knowledge so your agents stay sharp and your shipping velocity goes up.

Get started now

Currently, we are rolling out Byterover CLI (in beta). We hope to gather as many as feedback as possible from you all to improve this beta until the official GA.

👉 Sign up for the Beta CLI now →

👉 Read documentation →

⚠️ A side note:

This version is still in beta. We recommend trying it first on personal or side projects.

We hope that this CLI version will unlock a new effective way for developer teams to work with context. Please share with us your feedback as you try it out.

• 💬 Email: andy@byterover.dev

• 📅 Book a quick call: cal.com/andy-nguyen/15min