the apiary
Download
six assistants, one memory

Compare the assistants

The apiary works underneath six coding assistants today, and they all share one memory. They connect a little differently under the hood, and each connection has its own strengths. Here is each one, how it plugs in, and a side-by-side of what it supports.

Download

The six

Claude Code

The reference connection. Wired through a marketplace plugin, lifecycle hooks, and memory tools. The apiary captures every turn and recalls the right context before the next.

Cursor

Wired through a first-party editor extension, lifecycle hooks, and memory tools. Capture and recall happen in the editor you already use, loopback only.

Codex

Wired through lifecycle hooks and memory tools. Every turn is captured, distilled into source-backed notes, and recalled before the next.

Hermes

Wired through a registered memory-tools server plus shell hooks, so the memory tools appear in its native tool list and recall happens before every turn.

pi

Wired through a managed extension and a static instructions block, with recall available on demand. The apiary captures the work and recalls the right context.

OpenClaw

Wired through a native extension and memory tools. It gathers a session's work and flushes capture in one batch, so the same notes land as everywhere else.

What each connection supports

Every assistant reaches the same one memory through the local daemon on your machine. What differs is how it plugs in. This table is factual: each row is taken from the apiary's integration documentation, captured June 2026.

Claude CodeCursorCodexHermespiOpenClaw
memory tools in native list yes. yes yes. yes yes. yes yes. yes partial. via extension yes. yes
automatic recall at session start yes. live event yes. live event yes. live event yes. live event partial. static block from an instructions block yes. live event
per-turn capture yes. per event yes. per event yes. per event yes. per event partial. batched partial. batched flushed at session end
pre-tool memory browse yes. yes shell intercept yes. yes shell intercept yes. yes shell intercept partial. terminal only no. no no. no
editor extension no. no honeycomb advantage. yes first-party no. no no. no partial. managed honeycomb advantage. yes native
context shown to partial. model only partial. model only yes. you and model yes. you and model yes. you and model partial. model only

Every cell is taken from the apiary's integration documentation (the harness support matrix and the hook-coverage tables), captured June 2026. "live event" means the assistant fires a session-start event the apiary listens for; "static block" means recall is read from a standing instructions block. A blank capability is a property of the assistant, not an apiary limitation: the same notes still land in the shared store.

Three ways to connect, one daemon behind them

Every assistant reaches the apiary through some mix of three surfaces. A connector runs once at install to wire the assistant up. Hooks are the small notices the assistant fires as you work, which drive automatic capture and recall. Memory tools are an on-demand surface the assistant can call to ask for memory explicitly. Some assistants use all three, some use fewer, but all of them are thin clients of the one local daemon, which is the only thing that touches your store.

Read how it works

A closer look at each one

Claude Code is the reference connection. It wires through a marketplace plugin, the full set of lifecycle hooks, and the memory tools, so it is the most complete integration and the one every other connection is measured against.

Cursor brings a first-party editor extension on top of hooks and memory tools. Capture and recall happen right inside the editor, and Cursor's own shell tool is normalized so the same memory-browse behavior applies as on the others.

Codex wires through lifecycle hooks and memory tools, with its context shown to you as well as the model, so you can see the briefing the apiary hands it at session start.

Hermes registers the memory-tools server so the tools appear in its native list, and it adds a short visible mention so the assistant knows they are there. Capture and recall run through its shell hooks.

pi connects through a managed extension and reads its session-start context from a static instructions block rather than a live event, with recall available on demand. The same memory is captured and recalled, just primed a little differently.

OpenClaw gets a native extension and gathers a whole session's work before flushing capture in one batch at the end. The result is the same set of notes the per-event assistants produce, just grouped into one write.

Common questions

Does the memory differ between assistants?

No. There is one shared memory. What differs is how each assistant plugs in, not what it can remember or recall. A note written with one assistant is recalled by every other one.

Why do some assistants batch capture instead of recording each turn?

Because not every assistant exposes a small event for each turn. Where one does, the apiary captures per event; where one does not, such as OpenClaw, it gathers the session and flushes the same notes in one batch. The rows that land are the same either way.

What does context shown to you and model mean?

On some assistants the session-start briefing is visible to you as well as the model; on others it is delivered to the model only. Both deliver the same recalled context; the difference is whether you see the briefing text in your session.

Is one assistant the best connection?

Claude Code is the most complete reference integration, but the differences are shallow. Every assistant reaches the same memory through the same daemon, so use whichever assistant you prefer to work in.

One memory, every tool you use.

Install the apiary with one command and it wires up the assistants you already use.

Windows (PowerShell): irm https://get.theapiary.sh/install.ps1 | iex

Download