compare

nectar and smith

How does nectar compare to smith? smith is the closest single tool to nectar's description model, and we learned from it. It keeps a per-file description and re-describes only what changed. nectar takes that idea and adds the three things smith lacks: stable identity, a durable store you own, and recall that fuses with your memory. Close, and we owe it credit, but we go further.

Download How nectar compares

What smith is

smith maintains a small description file next to each source file. It records a hash of the file and the hash it was last described against; when those diverge, the file is stale, and a describe command re-describes only the stale ones. Teammates who clone the repo inherit the descriptions instead of paying the cost again. It is the same lazy, committed, incremental approach nectar uses.

What nectar borrows from smith

We credit smith plainly. Three of nectar's design choices come straight from it: lazy description with staleness tracking, committing the descriptions so teammates inherit them, and batching the work to keep the cost low.

Where nectar fills the gap

nectar

file identity: + minted follows a rename or move
where descriptions live: + a store you own one committed map
touches your source: + never
freshness: + continuous reacts after you pause
fuses with your memory: + yes

smith

file identity: x no keyed by path
where descriptions live: ~ sidecar files
touches your source: x yes writes into files like CLAUDE.md
freshness: ~ manual run the index command
fuses with your memory: x no standalone navigator

	nectar	smith
file identity	yes. minted follows a rename or move	no. no keyed by path
where descriptions live	yes. a store you own one committed map	partial. sidecar files
touches your source	yes. never	no. yes writes into files like CLAUDE.md
freshness	yes. continuous reacts after you pause	partial. manual run the index command
fuses with your memory	honeycomb advantage. yes	no. no standalone navigator

Capability comparison, not a benchmark. From smith's public materials and our survey, captured 2026-06.

The same model, rewritten for a memory stack.

The honest summary: nectar's description model is smith's model, with the identity, storage, source-safety, and recall dimensions rewritten to fit a memory stack. If you want a lightweight per-file description layer committed alongside your code, smith is a fine choice. If you also need descriptions that survive refactors, a store you own, source that is never modified, and recall fused with your memory, that is nectar.

See how nectar works

recall "refresh token rotation"

auth/refresh-token.ts:42 ✓ verified

rotate the refresh token on every use; the old one is revoked server side.

auth/refresh-token.ts:42 personal 0.94

session:2f9c-deploy-staging

staging deploys run from the release branch, never from a feature branch.

session:2f9c-deploy-staging personal 0.89

db/migrations/notes.md:7 ✓ verified

add the column nullable first, backfill, then set not null in a later migration.

db/migrations/notes.md:7 personal 0.82

Common questions

What is smith?

It keeps a small description file next to each source file, tracks staleness by hash, and re-describes only the stale ones. Teammates who clone the repo inherit the descriptions.

What does nectar borrow from smith?

Lazy description with staleness tracking, committing the descriptions so teammates inherit them, and batching the work to keep cost low. We credit it plainly.

Where does nectar go further than smith?

nectar mints a stable identity that survives moves, keeps descriptions in a store you own, never touches your source, refreshes continuously, and fuses code recall with your memory.

Descriptions that survive your refactors.

nectar keeps the map current and the identity stable. Install it with the rest of the stack.

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

Download