compare the assistants
honeycomb 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.
see all assistantsthe six
Claude Code
the reference connection. wired through a marketplace plugin, lifecycle hooks, and memory tools. honeycomb 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. honeycomb 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 quiet helper on your machine. what differs is how it plugs in. this table is factual: each row is taken from honeycomb's integration documentation.
| Claude Code | Cursor | Codex | Hermes | pi | OpenClaw | |
|---|---|---|---|---|---|---|
| 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 honeycomb integration documentation (the harness support matrix and the hook-coverage tables), captured June 2026. "live event" means the assistant fires a session-start event honeycomb listens for; "static block" means recall is read from a standing instructions block. a blank capability is a property of the assistant, not a honeycomb limitation: the same notes still land in the shared store.
three ways to connect, one helper behind them
every assistant reaches honeycomb 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 quiet helper, which is the only thing that touches your store.
read how it worksa 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 honeycomb 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, honeycomb 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 helper, so you should use whichever assistant you prefer to work in.
where do these capability claims come from?
from honeycomb own integration documentation: the harness support matrix and the hook-coverage tables, captured June 2026. the comparison asserts only capabilities those tables support.