Beacon: Open-Source Memory That Follows You Across Claude Code, Codex and Cursor

Beacon is a new open-source tool that tries to give your coding agents a shared memory. It records what happens in Claude Code, Codex, Cursor, OpenCode and more than 20 other harnesses, converts it into one trace format, and turns the lessons you approve into skills that any of those agents can load later. The project is MIT-licensed, lives at Asymptote-Labs/agent-beacon on GitHub and was posted to Hacker News as a Show HN on October 21, 2026.

The pitch from the founders, written in the HN post, is blunt: they kept switching between coding agents whenever a usage limit hit or a better model shipped, and had to re-explain tasks, workflows and mistake patterns each time. Their argument is that "your agent data is yours to own and should not be locked behind any frontier lab's ecosystem."

This article covers what Beacon does, how to try it, where it overlaps with the memory approaches we have already covered, and the privacy questions you should answer before turning it on.

Quick answers

What problem does Beacon solve?

Every coding agent keeps its own history, in its own format, in its own place. A correction you gave Claude Code on Tuesday ("never run migrations against the shared database") is invisible to Codex on Wednesday. Memory features built into one harness, such as the cross-session memory we covered in Grok Build, stay inside that harness by design.

Beacon sits one layer below. The README describes a loop: run agents, capture session history, evaluate what worked, extract useful knowledge, review and approve it, and reuse it across future agents. The examples it gives are practical rather than abstract: the right way to run a migration, a debugging path that finally fixed an obscure issue, a testing convention agents keep getting wrong, a repository-specific workflow, or a correction you have given several agents.

The pattern is the same one behind harness engineering: the model is only part of the system, and the surrounding scaffolding decides how much of your accumulated context survives from one session to the next. Beacon's bet is that this scaffolding should be neutral and portable instead of owned by whichever lab's harness you happen to be using today.

How does Beacon work?

Capture: hooks, OTLP and polling

Beacon collects data where agents actually run. According to the support matrix in the README, the collection method varies by harness: hooks for Cursor, Kiro, Qwen Code and others; OpenTelemetry (OTLP) export for Gemini CLI and Codex Desktop; plugins for Cline and OpenCode; and a combination of OTLP, hooks and polling for Claude Code and Codex CLI. Everything is normalized into a common OpenTelemetry-based event model.

The captured signals can include sessions, prompts and responses, tool calls, shell commands, file activity, approvals, MCP interactions and token usage. Not every harness exposes every signal. For example, the matrix marks approvals and MCP activity as unavailable for some tools, so the "exact session replay" claim is strongest for harnesses with full hooks, such as Claude Code.

Beyond terminal agents, Beacon also covers browser chat (a Chromium and Firefox extension for Claude.ai and ChatGPT that writes to a local OTLP collector), cloud agents (Claude Code, Cursor and Devin cloud agents via sandbox hooks or API polling), CI jobs through beacon ci exec, and SDK instrumentation for Anthropic, OpenAI, the Claude Agent SDK and the Vercel AI SDK.

Distill: from raw traces to reviewed lessons

Raw traces are not memory. The distillation step looks for repeated workflows, corrections and debugging patterns, and proposes them as reusable knowledge. Per the README, a human approves what gets promoted. The Beacon site describes this as a "dreaming process", and some community posts it displays say a scoring model called Jev picks which corrections become reusable skills. Those are secondhand testimonials, not Beacon's own documentation, and we have not seen a published evaluation of how well the selection works.

Reuse: MCP and Agent Skills

Approved knowledge reaches agents two ways. The first is Agent Skills, installed as a plugin in Claude Code, a package for Pi, a Power for Kiro, or through npx skills add asymptote-labs/agent-beacon for harnesses that support the skills CLI. The second is MCP: beacon mcp connect registers a managed MCP server in Claude Code, Codex CLI, Cursor, VS Code, Gemini CLI and OpenCode, with OAuth sign-in on first use. A separate local MCP server, beacon mcp serve, never touches the network.

If those terms are new, our explainers on agent skills and the Model Context Protocol cover the mechanics.

Moving boxes crossing a bridge, picturing agent session history migrating between coding agents with Beacon cross-harness memory

How do you install and try Beacon?

The README gives three platform paths. On macOS:

brew update
brew trust asymptote-labs/tap
brew tap asymptote-labs/tap
brew install beacon
beacon endpoint install

On Linux, a script downloads the right .deb or .rpm, checks it against the release checksums.txt, and installs it with apt-get or dnf. The README suggests reading the script before piping it to your shell, or downloading the package and verifying it yourself, and notes that you can verify build provenance with gh attestation verify. On Windows, you download the x64 MSI from the releases page.

Then use your agents as normal. To look at what was captured:

beacon traces

This opens a local terminal browser for traces, event timelines, token usage and retained content, and the README says nothing is sent anywhere. A local read-only web view is available with beacon endpoint dashboard, and the raw event stream sits in ~/.beacon/endpoint/logs/runtime.jsonl. That open JSONL file is the part worth caring about: even if you drop Beacon, you keep a harness-neutral record of your sessions.

The site also offers a "Copy setup prompt" button that hands the install to your coding agent. That is convenient, and also a reminder to read what an agent is about to install on your machine before approving it.

Observability dashboard eye over bars, illustrating Beacon agent memory traces and token usage views

What are the privacy and security trade-offs?

An always-on recorder of agent sessions is a sensitive thing to run. Prompts, tool outputs and command history routinely contain file contents, internal URLs and, occasionally, secrets. Four details in the README matter.

1. Cloud is preselected in the interactive wizard. Setup signs in through beacon.sh and preselects Beacon Cloud, with an explicit Local opt-out. The README states that signing in does not enable forwarding, but confirming the cloud option does, and the confirmation screen names the account, the operator (Asymptote Labs), the destination and the capture mode. Read that screen. Choose Local if you only want to try it.
2. Privacy modes exist. Beacon Cloud enrollment offers Standard or Metadata-only privacy. Metadata-only is the safer starting point for work on private repositories.
3. System, package, MDM and CI installs are non-interactive and account-free, which suits managed fleets but means an administrator decides the destination.
4. Lenses run custom HTML. Session pages can show "lenses", single HTML files in a sandboxed frame. The README itself warns that the sandbox cannot block every way a browser can send data out, so install only lenses you trust with your traces.

Beacon also lists SIEM and log destinations (Splunk, Datadog, Elastic, Microsoft Sentinel, CrowdStrike Falcon LogScale, Sumo Logic, Wazuh, S3, GCS, CloudWatch), and its repo topics include agent security and detection engineering. That points to a second audience beyond individual developers: security teams that want an audit trail of what coding agents ran. If your concern is stopping a dangerous agent action before it happens rather than reviewing it afterwards, that is a different layer; AgentBeam is the agent security platform from the explainx.ai team built for that job. Our guide to agent safety around AI-assisted pull requests shows why teams want both visibility and guardrails.

What are developers saying on Hacker News?

The Show HN thread had 16 points and 11 comments when we read it, so treat the sample as small. The reactions were thoughtful rather than hostile.

• "A markdown file." User loveparade said they built something similar for themselves, "I call it a markdown file." It is a fair baseline: a hand-curated AGENTS.md costs nothing and is fully understood by its owner.
• Forgetting. User KartikB101 worried about an agent remembering too much: a workaround from six months ago may no longer matter, and they asked how a stored skill gets deleted. The README describes review and approval, but we did not find a documented expiry policy, so that question stands.
• Blank slates are a feature. User sejje said they do not want agents to remember much; projects should remember, and a blank-slate agent gives more reliable output. They keep one orchestrator with long-term memory instead.
• Team value. User udpatil suggested the compounding value is larger across teams, since one engineer's agent often solves a problem another engineer's agent later hits again.
• Founder reply. User jqdsouza, who signs as Justin and says they are one of the creators, thanked the thread and said the project had hit number one trending on X news. That is a self-reported claim and we did not verify it.

These are individual reports, not benchmarks. They do show where the real debate sits: whether agent memory should live in curated project files or in an automatic, cross-tool layer.

How does Beacon compare with other memory approaches?

We have covered several memory designs recently, and they solve different parts of the problem.

Beacon is less a memory algorithm than plumbing: capture, normalize, review, serve. That is its strength (it is neutral and works with what you already use) and its limit (the quality of the distilled lessons depends on a classifier and your approvals, neither of which we have independently tested).

A reviewer's hand receiving a bead from a mechanical gripper, standing for the human approval step in Beacon agent memory

Should you try it?

A reasonable trial plan, based on the documented behavior:

1. Install it in Local mode on a personal machine or a throwaway repo, and run your usual agents for a day.
2. Open beacon traces and check what was retained. If prompts or outputs contain anything you would not paste into a ticket, stop and tighten settings before going further.
3. Look at the lessons Beacon proposes. If they are things you would have written in AGENTS.md anyway, keep them; if they are noisy or stale, the approval gate is doing its job by letting you reject them.
4. Only then consider the cloud tier or SIEM forwarding, and use Metadata-only privacy for private code first.

The case for it is strongest if you switch harnesses often because of usage limits or new models, run several agents on the same repo, or need an audit trail of agent activity. The case is weakest for a solo developer with one agent and a tidy project file. The wider context is the same one running through Shrivu Shankar's argument that the harness is the company: as models converge, the durable value moves to the layer that holds your context. Beacon is an attempt to make that layer open.

What is still unverified?

Several claims in the project's own material are the vendor's and not independently confirmed. Community posts say Jev scores which corrections are reusable; we have seen no published precision numbers. The social posts on the Beacon site are testimonials that the project chose to display. The star count and the "trending" claims are snapshots. And the README advertises cross-harness learning ("Your Cursor sessions can improve Codex"), which depends on how reliably the skills it writes are interpreted by each harness. None of that makes Beacon a bad idea; it means the evidence so far is a repo, a README and a handful of early user reactions.

Related reading

• What is harness engineering for AI agents?
• Hindsight: open-source memory that makes agents learn
• Shared markdown memory between Claude Code and Codex
• Cognition's Devin dreaming memory and open spec
• What are agent skills? A complete guide
• What is MCP? The Model Context Protocol guide
• The harness is the company
• Official: Beacon repository and beacon.sh

Details reflect the Beacon README and site as read on October 22, 2026. Supported harnesses, install commands and privacy defaults change quickly, so check the repository before you install.