nectar vs smith
Head-to-head with Smith (attckdigital). Sourced from the nectar prior-art corpus (captured 2026-06). Smith is the closest single prior art; credit it generously. Brand voice: lowercase wordmarks, sentence case, mono for ids, paths, and commands, no emoji.
nectar vs smith
Page: compare-nectar-vs-smith | Slug: compare/nectar-vs-smith | Version: 1.0 | Date: July 2026 | Status: Draft for approval
Head-to-head with Smith (attckdigital). Sourced from the nectar prior-art corpus (captured 2026-06). Smith is the closest single prior art; credit it generously. Brand voice: lowercase wordmarks, sentence case, mono for ids, paths, and commands, no emoji.
#The short version
smith is the closest thing 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.
#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. our per-version
describe_statusis smith's hash-mismatch flag. - commit the descriptions so teammates inherit them. our committed map is smith's committed description layer.
- batch the work to keep the cost low.
#Where nectar fills the gap
| dimension | smith | nectar |
|---|---|---|
| file identity | none; descriptions are keyed by path, so a move loses them | a stable tag minted once; the description follows a rename or move |
| where descriptions live | sidecar files next to your source | a durable store you own, projected to one committed map |
| touches your source | yes; it writes into files like CLAUDE.md |
never; the one file it writes is its own map |
| freshness | manual; you run the index command | continuous; a background watcher reacts after you pause editing |
| fuses with memory | no; it is a standalone navigator | yes; code recall joins session and skill recall in one query |
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.
#When to pick which
- pick smith if you want a lightweight, self-contained per-file description layer committed alongside your code.
- pick nectar if you also need descriptions that survive refactors, a store you own, source that is never modified, and code recall fused with your assistant's memory.
#Sources
from smith's public materials and the nectar prior-art survey, captured 2026-06. written in our own words and dated.
- button: get the apiary → /install
- back to how nectar compares