From fda90af4c59e59f667db5544578d194811d78009 Mon Sep 17 00:00:00 2001 From: 0thernet Date: Sun, 27 Sep 2026 00:25:17 -0400 Subject: [PATCH] Correct facts in SEO program copy Introducing Wordcell said every graph result that hits a limit is marked as truncated. Only row or proof truncation is marked (exit code 4); a query that exhausts its work budget fails (docs/graph-authority.md). Co-Authored-By: Claude Opus 5.5 --- site/app/blog/articles.ts | 1 + site/app/blog/blog.generated.ts | 2 +- site/content/blog/introducing-wordcell.md | 2 +- 3 files changed, 3 insertions(+), 2 deletions(-) diff --git a/site/app/blog/articles.ts b/site/app/blog/articles.ts index 7fd70f5..b68675b 100644 --- a/site/app/blog/articles.ts +++ b/site/app/blog/articles.ts @@ -118,6 +118,7 @@ export const blogArticles = [ "The published release record (site/published-release.json, 0.22.4) trails package.json (0.22.5) on main at 7b6cb5e, so a version typed from package.json or the README install line would claim a release the site has not recorded.", "The Oh adoption preparer in src/oh-adoption.ts always returns status \"prepared\" and renders Markdown that calls itself a review candidate; nothing in that path opens a vault or writes a note, so outside memory can only enter Wordcell through a person authoring Markdown.", "2026-09-26 editorial pass: reordered the post to lead with the claim and moved the release status and KB rename history next to what they qualify; no fact, command, link, or version changed. By then site/published-release.json recorded 0.22.5, so the gap in the first observation had closed, and npm still lists @hraness/kb only through 0.19.2.", + "2026-09-27 fact review (AI, Claude Opus 5.5): the 2026-09-26 pass had said every result that hits a limit is marked as truncated. docs/graph-authority.md says only row or proof truncation is marked (exit code 4) and work exhaustion fails, so the Limits paragraph now says both.", ], scores: { readerUtility: 2, diff --git a/site/app/blog/blog.generated.ts b/site/app/blog/blog.generated.ts index ecb1482..361b60c 100644 --- a/site/app/blog/blog.generated.ts +++ b/site/app/blog/blog.generated.ts @@ -1,6 +1,6 @@ // Generated from content/blog/*.md by scripts/sync-blog.ts. Do not edit. export const blogHtml: Readonly> = { - "introducing-wordcell": "

Wordcell keeps decisions, plans, and sources as Markdown files beside your code, and lets coding agents find them and cite the file each answer came from. Agents search by exact words, by meaning with an optional local model, or by the file they are about to change. Wordcell also builds a graph from the links you wrote. The files stay where they are, in a format Obsidian, Git, and any text editor can read, and every index can be deleted and rebuilt from them.

\n

Take a rule like "parser retries stop after three attempts." It gets decided once and then lost: in a chat that closes, a commit message nobody searches, or a note on someone's laptop. The next coding agent to touch the parser starts from the code and never sees it. With Wordcell, the rule is a note the agent can find and cite.

\n

Latest release: v0.23.0. Install the versioned archive from GitHub Releases or the npm mirror with Bun 1.3.14 or newer and Git; the documentation has the commands.

\n

Every answer points back to a file

\n

Wordcell reads a folder of Markdown notes. Unlike some agent memory tools, it does not move them into a database of its own. Everything it builds on top can be rebuilt from the files: exact search, optional search by meaning, backlinks, graph queries, and published sites. None of these writes back into your notes, so deleting one costs you a way to look things up and leaves the notes as they were.

\n

That makes each answer checkable. An exact search result names the note and the line that matched. A graph result names the note that wrote a link, the note it points to, and the line where the link appears, plus a proof tied to the version of the file it was read from. When an agent cites a Wordcell result, you can open the file and read the sentence yourself.

\n

The same rule covers material from other tools. Wordcell's SDK can turn a verified set of Oh records into a Markdown review candidate, but that step never opens the vault, writes a note, or marks anything as reviewed. A person reads the candidate and decides what to write.

\n

Who it suits

\n

Wordcell is for people who keep decisions, sources, and plans in Markdown or an Obsidian vault and work with coding agents such as Claude Code, Codex, Cursor, or GitHub Copilot. It helps most when the notes explain code: why a module rejects a tempting shortcut, which plan introduced a constraint, which source backed a decision.

\n

Some people need less. A small set of notes may be fine with plain Markdown and a text search. If you only want local document retrieval, QMD is a good fit on its own; Wordcell uses it for its optional search by meaning. If you want a service that records everything an agent does without being asked, Wordcell is the wrong tool, because only what you save becomes a note.

\n

From one saved rule to a cited answer

\n

Wordcell is a command-line tool and TypeScript SDK that runs on Bun, with Git. Once it is installed, saving one rule and searching for it looks like this:

\n
wordcell init kb\nwordcell note create notes/parser-contract \\\n  --title "Parser contract" --type concept \\\n  --body "Parser retries stop after three attempts." --root kb\nwordcell search "parser retries" --root kb --mode exact\n
\n

The result points to notes/parser-contract, an ordinary Markdown file you can open and edit. Exact search needs no model, account, or network request. You can also run the same search on a vault you already have, without initializing or converting it.

\n

Links you write become the graph. A plan that mentions [[notes/parser-contract]] shows up when you ask what depends on the rule:

\n
wordcell graph query --program backlinks --note notes/parser-contract --root kb --json\n
\n

Each row names the source note, the target, and the line of the link. Wordcell answers graph queries with Oh, an embedded engine that needs no separate account or service. By default the graph lives in memory for one query and then closes. How Wordcell uses Oh covers what the proofs contain and what they leave out.

\n

To tie a note to code, list the paths it explains in its frontmatter:

\n
repository_scopes:\n  - packages/parser\n
\n

An agent about to edit a file in that package can then ask for the notes and repository rules that apply to it:

\n
wordcell context packages/parser/src/index.ts --root kb --repo .\n
\n

The result lists current notes and plans separately from finished or superseded ones, and includes the AGENTS.md files that govern the path. Wordcell's agent workflow asks agents to run this for the path they are changing before they try a broad search.

\n

A public Agent Skill teaches compatible agents these commands. Installing it adds instructions only; it does not create a vault, change your notes, or give an agent access to other accounts. xcb can bind one vault you choose and give its workers read-only exact search over it with citations, and saving a note back is always a separate step, as How xcb uses Wordcell explains.

\n

Clipped pages and PDFs land in the same folder

\n

Sources you read become files in the vault too. wordcell clip saves a web page as a Markdown bundle with its images and a record of how the page was fetched, and wordcell pdf keeps the original PDF beside the extracted text. Search and the graph read them alongside your notes, and the vault's rules keep captured text marked as source material, apart from your conclusions.

\n

Some of what people read sits behind their own logins: a newsletter they subscribe to, a member article, a page already open in their browser. Wordcell can save those pages for the person who is signed in. It can read the tab you have open without navigating it, open a page with a browser profile you select, or use your browser's cookies for that site when the page needs nothing else. A profile given by its folder path runs from a temporary copy, so the profile itself is unchanged.

\n

Capture only reads. It does not post, like, follow, send, delete, or submit anything. When a site answers with a login wall, paywall, or CAPTCHA, Wordcell stops instead of looking for an archived copy elsewhere. For a public page that no direct route can read, it may make one read-only lookup of that URL on Archive.today, which tells that service the URL. Screenshots can include private notifications, so review a bundle before you share it.

\n

Limits

\n

Wordcell does not write answers. It returns notes, snippets, and graph rows, and your agent writes the answer from them. A graph proof shows that a file said something at a given version, not that the note is correct. Graph queries accept vaults of up to 4,000 notes, and a result that hits a limit is marked as truncated. Search by meaning downloads a local model the first time you use it. An optional reranking step sends the query and note snippets to a paid hosted provider and is off by default.

\n

Wordcell was called KB until version 0.20.0, and the vault format keeps its kb names, so an existing vault needs no migration. Releases up to 0.19.6 use the package name @hraness/kb: npm carries them through 0.19.2, and the later 0.19.x versions exist as GitHub Release archives. Newer releases use @hraness/wordcell, but older install notes and lockfiles may show the old name.

\n", + "introducing-wordcell": "

Wordcell keeps decisions, plans, and sources as Markdown files beside your code, and lets coding agents find them and cite the file each answer came from. Agents search by exact words, by meaning with an optional local model, or by the file they are about to change. Wordcell also builds a graph from the links you wrote. The files stay where they are, in a format Obsidian, Git, and any text editor can read, and every index can be deleted and rebuilt from them.

\n

Take a rule like "parser retries stop after three attempts." It gets decided once and then lost: in a chat that closes, a commit message nobody searches, or a note on someone's laptop. The next coding agent to touch the parser starts from the code and never sees it. With Wordcell, the rule is a note the agent can find and cite.

\n

Latest release: v0.23.0. Install the versioned archive from GitHub Releases or the npm mirror with Bun 1.3.14 or newer and Git; the documentation has the commands.

\n

Every answer points back to a file

\n

Wordcell reads a folder of Markdown notes. Unlike some agent memory tools, it does not move them into a database of its own. Everything it builds on top can be rebuilt from the files: exact search, optional search by meaning, backlinks, graph queries, and published sites. None of these writes back into your notes, so deleting one costs you a way to look things up and leaves the notes as they were.

\n

That makes each answer checkable. An exact search result names the note and the line that matched. A graph result names the note that wrote a link, the note it points to, and the line where the link appears, plus a proof tied to the version of the file it was read from. When an agent cites a Wordcell result, you can open the file and read the sentence yourself.

\n

The same rule covers material from other tools. Wordcell's SDK can turn a verified set of Oh records into a Markdown review candidate, but that step never opens the vault, writes a note, or marks anything as reviewed. A person reads the candidate and decides what to write.

\n

Who it suits

\n

Wordcell is for people who keep decisions, sources, and plans in Markdown or an Obsidian vault and work with coding agents such as Claude Code, Codex, Cursor, or GitHub Copilot. It helps most when the notes explain code: why a module rejects a tempting shortcut, which plan introduced a constraint, which source backed a decision.

\n

Some people need less. A small set of notes may be fine with plain Markdown and a text search. If you only want local document retrieval, QMD is a good fit on its own; Wordcell uses it for its optional search by meaning. If you want a service that records everything an agent does without being asked, Wordcell is the wrong tool, because only what you save becomes a note.

\n

From one saved rule to a cited answer

\n

Wordcell is a command-line tool and TypeScript SDK that runs on Bun, with Git. Once it is installed, saving one rule and searching for it looks like this:

\n
wordcell init kb\nwordcell note create notes/parser-contract \\\n  --title "Parser contract" --type concept \\\n  --body "Parser retries stop after three attempts." --root kb\nwordcell search "parser retries" --root kb --mode exact\n
\n

The result points to notes/parser-contract, an ordinary Markdown file you can open and edit. Exact search needs no model, account, or network request. You can also run the same search on a vault you already have, without initializing or converting it.

\n

Links you write become the graph. A plan that mentions [[notes/parser-contract]] shows up when you ask what depends on the rule:

\n
wordcell graph query --program backlinks --note notes/parser-contract --root kb --json\n
\n

Each row names the source note, the target, and the line of the link. Wordcell answers graph queries with Oh, an embedded engine that needs no separate account or service. By default the graph lives in memory for one query and then closes. How Wordcell uses Oh covers what the proofs contain and what they leave out.

\n

To tie a note to code, list the paths it explains in its frontmatter:

\n
repository_scopes:\n  - packages/parser\n
\n

An agent about to edit a file in that package can then ask for the notes and repository rules that apply to it:

\n
wordcell context packages/parser/src/index.ts --root kb --repo .\n
\n

The result lists current notes and plans separately from finished or superseded ones, and includes the AGENTS.md files that govern the path. Wordcell's agent workflow asks agents to run this for the path they are changing before they try a broad search.

\n

A public Agent Skill teaches compatible agents these commands. Installing it adds instructions only; it does not create a vault, change your notes, or give an agent access to other accounts. xcb can bind one vault you choose and give its workers read-only exact search over it with citations, and saving a note back is always a separate step, as How xcb uses Wordcell explains.

\n

Clipped pages and PDFs land in the same folder

\n

Sources you read become files in the vault too. wordcell clip saves a web page as a Markdown bundle with its images and a record of how the page was fetched, and wordcell pdf keeps the original PDF beside the extracted text. Search and the graph read them alongside your notes, and the vault's rules keep captured text marked as source material, apart from your conclusions.

\n

Some of what people read sits behind their own logins: a newsletter they subscribe to, a member article, a page already open in their browser. Wordcell can save those pages for the person who is signed in. It can read the tab you have open without navigating it, open a page with a browser profile you select, or use your browser's cookies for that site when the page needs nothing else. A profile given by its folder path runs from a temporary copy, so the profile itself is unchanged.

\n

Capture only reads. It does not post, like, follow, send, delete, or submit anything. When a site answers with a login wall, paywall, or CAPTCHA, Wordcell stops instead of looking for an archived copy elsewhere. For a public page that no direct route can read, it may make one read-only lookup of that URL on Archive.today, which tells that service the URL. Screenshots can include private notifications, so review a bundle before you share it.

\n

Limits

\n

Wordcell does not write answers. It returns notes, snippets, and graph rows, and your agent writes the answer from them. A graph proof shows that a file said something at a given version, not that the note is correct. Graph queries accept vaults of up to 4,000 notes. A result cut off by its row or proof limit is marked as truncated, and a query that runs out of work fails instead of returning a partial answer. Search by meaning downloads a local model the first time you use it. An optional reranking step sends the query and note snippets to a paid hosted provider and is off by default.

\n

Wordcell was called KB until version 0.20.0, and the vault format keeps its kb names, so an existing vault needs no migration. Releases up to 0.19.6 use the package name @hraness/kb: npm carries them through 0.19.2, and the later 0.19.x versions exist as GitHub Release archives. Newer releases use @hraness/wordcell, but older install notes and lockfiles may show the old name.

\n", "how-wordcell-uses-oh": "

Every Wordcell graph answer comes with a proof you can check against your notes. Wordcell hands its graph work to Oh, and Oh returns each row with the file that supports it, a fingerprint of that file's contents, and the rule that joined the pieces. When Wordcell says a retry plan depends on your parser rule, you can read the line in the plan that makes the link and confirm that the line still reads as it did when the answer was computed.

\n

The Markdown files stay the record. The graph is a copy Wordcell can delete and rebuild from them.

\n

What Oh is

\n

Oh is a memory framework that applications embed as a library. It stores typed records, derives new facts from rules, and returns each derived answer with the chain of facts and rules that produced it. Wordcell uses the part that stores records and answers graph questions. There is no Oh account to create and no service to run. Wordcell pins one released version of Oh and upgrades only by changing that pin.

\n

Oh writes every record in one exact text form, which it calls canonical JSON, and names the record by the SHA-256 fingerprint of that text. Two programs holding the same record produce the same bytes and the same fingerprint, whatever order they assembled its fields in, so a fingerprint in a proof names exactly one record.

\n

How a query turns notes into rows

\n

When you run a graph query, Wordcell reads the whole vault as it is at that moment:

\n
    \n
  1. It fingerprints the text of each Markdown file.
    2. \n
  2. It collects what you wrote: links, typed relationships, tags, and the code paths a note declares under repository_scopes. Each becomes a fact tied to the note it came from, and links keep their line.
    3. \n
  3. It stores each note's facts as an Oh record in canonical JSON, and fingerprints the whole snapshot as one revision.
    4. \n
  4. It turns the named query you asked for into a small set of Oh rules, and Oh evaluates them over that snapshot.
    5. \n
\n

By default all of this lives in memory for one query and then closes. Nothing is written into the vault and no cache file appears. Here is the smallest case, a note that links to a rule and a query for what points at the rule:

\n
wordcell note create notes/retry-review --title "Retry review" --type concept \\\n  --body "Use [[notes/parser-contract]] when changing retry behavior." --root kb\nwordcell graph query --program backlinks --note notes/parser-contract --root kb --json\n
\n

The row names notes/retry-review as the source, notes/parser-contract as the target, and the line where the link was written. Its proof names the source note, the fingerprint of that note's contents, and the fingerprint of the Oh record built from it. A longer answer, such as everything reachable within three links, adds the rule applied at each step and the facts it used. Six named queries are available: backlinks, reachability, relation-closure, scope-route, shared-tags, and shared-concepts.

\n

To keep a graph on disk, wordcell graph rebuild writes one to a .wordcell/oh.sqlite file that Git ignores, checks it by replaying it, and only then replaces the previous file. Deleting that file loses nothing, because Wordcell can rebuild it from the notes. A fresh rebuild returns the same rows and source proofs, though the stored graph's own history identifiers can differ.

\n

What a proof guarantees

\n

The same files give the same answer. Equal snapshots of your notes produce equal rows and equal source proofs. An in-memory graph uses a fixed logical start time so the result can be reproduced in a later session; that time says nothing about when a note was written.

\n

An edit invalidates the old proof. A proof carries the fingerprint of each file it relies on, taken over the file's exact text. Change the file, even its spacing, and the fingerprint changes, so the old proof no longer matches. A Wordcell session holds one snapshot for its whole life, so reopen it after editing. From code, you can re-check any result against its session:

\n
import { openKnowledgeBase } from "@hraness/wordcell";\n\nconst kb = await openKnowledgeBase({ root: "kb" });\ntry {\n  const result = await kb.graphQuery({ program: "backlinks", note: "notes/parser-contract" });\n  console.log(await kb.graphVerifyResult(result)); // false for modified, foreign, or stale evidence\n} finally {\n  await kb.close();\n}\n
\n

Answers never write back. A query never adds a link or an inferred relationship to a note. With wordcell percolate --proofs, Wordcell can show shared tags or shared concepts as evidence beside a suggested connection, but whether two notes should link stays your decision, made by editing the Markdown.

\n

A proof shows that a file said something at a given version. It does not show that the note is right.

\n

Why the Rust and TypeScript encoders must agree

\n

Oh ships its canonical encoder and its query engine twice: a TypeScript reference and a Rust version compiled to WebAssembly. Wordcell's graph queries use the Rust engine when it loads and fall back to TypeScript when it does not, with the same source revision and the same limits either way. If the Rust engine is unavailable, the notes are unchanged and give the same answers.

\n

Two encoders are only safe if they agree on every input, because one differing character changes a fingerprint and breaks every proof that cites it. The rule they share is short. Object keys are sorted, array order is kept, there is no extra whitespace, and numbers are written the way JavaScript's JSON writer writes them:

\n
import { canonicalJson } from "@hraness/oh";\n\ncanonicalJson({ b: 1, a: [2, 1] }); // '{"a":[2,1],"b":1}'\n
\n

Wordcell's own tests hold the Rust encoder it loads from Oh to that rule. They confirm that the WebAssembly bytes Wordcell loads match the SHA-256 recorded in the Oh package, then generate random JSON values, including nested arrays and objects and very large and very small numbers, and require the Rust and TypeScript encoders to return the same text and the same fingerprint for each. Fixed cases such as 1e21, 5e-324, an empty key, and an emoji key are checked on every run. Oh runs its own version of this test, described in Oh holds its Rust encoder to the TypeScript reference byte for byte.

\n

Oh records become notes only when a person writes them

\n

Wordcell does not keep an agent's memory in Oh. Its SDK can turn selected records from an Oh memory store into a Markdown review draft that lists the source records and their fingerprints, and fingerprints the draft itself with Oh's Rust encoder, again with a TypeScript fallback. Preparing that draft never opens a vault or writes a note. Whether any of it becomes a note is a separate decision a person makes.

\n

What Oh does not do for Wordcell

\n

Wordcell runs only its six named queries; there is no free-form query language. Absences, orphan notes, and counts are computed by Wordcell from the complete snapshot, not proved by Oh. Graph queries accept a vault of up to 4,000 notes, 100,000 facts, and 64 MiB of text, and a query that runs out of work fails instead of returning a partial answer as complete. A truncated result says so in its JSON and exits with code 4.

\n

Wordcell's search does not use Oh. Exact search and optional local search by meaning are Wordcell's own, so Oh's memory benchmarks say nothing about Wordcell's search or answers.

\n

Latest release: v0.23.0. For the full query reference, see Query the derived graph in the Wordcell documentation. Oh is the library behind the graph.

\n", "free-local-agent-memory": "

Wordcell now serves a Markdown vault to local Model Context Protocol (MCP) clients, imports Supermemory exports, and gives agents a workflow for saving what a session decided as a note. The memory stays in files you can read, diff, and commit, with no hosted service, no account, and no usage bill.

\n

On Monday a coding agent works out why the release script pins an older compiler. On Tuesday a new session opens in the same repository and starts without that reason, unless someone wrote it where the agent looks. Wordcell keeps that kind of record as Markdown notes in a folder you control, and this launch lets agents read and write those notes through their own tools.

\n

Latest release: v0.23.0. The migration page starts with the release install, and bunx skills add hraness/wordcell#v0.23.0 --skill wordcell adds the skill from that release.

\n

An MCP server, a Supermemory importer, and a session-memory workflow

\n

wordcell mcp --root <vault> serves a vault over standard input and output to local MCP clients such as Claude Code, Claude Desktop, Cursor, and Codex. Agents search, list, and read notes, follow links and backlinks, create notes, replace a note body at the revision they read, and add relations between notes. With --repo, the server also returns context for a repository. Every write goes through the same checks as the command line, and --read-only leaves the write tools out. The MCP server reference lists each tool and shows how to connect a client.

\n

wordcell import supermemory <export.json> turns documents and memory entries saved from the Supermemory API into notes. Each version of a memory becomes its own note, linked newest to oldest by supersedes relations. Running the import again updates notes you have not edited, skips unchanged ones, and reports notes you changed yourself as conflicts without touching them. The importer reads export files only and makes no network calls. Import from Supermemory lists the fields and where each kind of item lands.

\n

The wordcell skill includes a session-memory workflow. When you ask, the agent saves what the conversation decided as a dated session note, links it to the notes it changed, and keeps a profile note with a Stable section and a Recent section. Wordcell extracts nothing on its own: the agent writes the note, and you can read it before anything depends on it. The steps are in the session-memory reference.

\n

Two guides cover the rest of a move. Migrate from Supermemory exports your data, imports it, and lists what does not transfer. Sync a vault with Git keeps one vault current on several machines through a private repository.

\n

Wordcell has measured payload size and one search study

\n

Across four queries on a seven-note public vault, packed snippets used 79.98% fewer UTF-8 bytes than the same notes in full: 12,126 bytes against 60,584 bytes, measured with Wordcell 0.21.3. That is payload size only. It does not measure tokens, answer quality, speed, or an advantage over another search tool.

\n

On 300 BEIR SciFact queries over 5,183 public scientific abstracts, exact search put a relevant abstract first for 33.7% of queries. Optional Jev reranking, which sends each query and candidate snippets to a paid provider, raised that to 53.7% in a study run on September 19, 2026. The study searched without the graph or Git history, and it does not establish answer quality. Neither study measures a large vault of notes your agents wrote and linked, or the graph, search by meaning, or the MCP server at that size. The benchmarks page has both studies with raw results.

\n

Oh’s benchmark results describe Oh, not Wordcell

\n

Wordcell builds its graph with Oh, memory for agents that stores each fact with its sources and history. Oh also has its own memory-retrieval API and publishes conversation-memory results for it. LoCoMo is a benchmark of questions about long conversations held over many sessions. In Oh’s LoCoMo run, published September 10, 2026, Oh’s semantic retrieval had 84.4% of 1,540 answers judged correct with GPT-5 mini as the reader and 81.0% with GPT-5 nano. BM25, a keyword-search baseline over the same conversations, scored 81.6% and 78.1% with the same two readers. A GPT-4o mini judge graded every answer. Oh’s conversation-memory benchmarks evaluate its own memory-retrieval API, reader models, and evaluation protocols. Those scores do not transfer to a Wordcell vault merely because it uses the same library.

\n

The run covered 10 conversations once, with no confidence interval, and every question had been seen before: 1,226 in earlier evaluations and 314 during development. The result file records no run date, so the date above is when Oh published it. Oh’s result file says the figures “do not establish fresh confirmation, statistical superiority or benchmark saturation”.

\n

LongMemEval-S is a benchmark of questions about long chat histories. Oh’s study of all 500 of its questions, completed September 26, 2026, gave Oh’s semantic retrieval and BM25 the same byte budget and the same reader, GPT-5 mini, which answered every question three times. A GPT-4o judge graded the answers with LongMemEval’s own prompts. Oh’s semantic retrieval had 88.87% of answers judged correct and BM25 86.13%. On the measure Oh chose before the run, questions answered correctly in at least two of the three runs, Oh minus BM25 came to +2.8 percentage points, with a 95% interval from 0.0 to +5.6. That interval reaches zero, so the study does not rule out a tie. Earlier Oh studies had scored all of these questions, and this one reported no Supermemory result.

\n

Before that study, Oh ran a smaller pilot of its API against Supermemory, dated September 24, 2026. It used 60 questions from LongMemEval-S, and Oh had seen those questions during development. Supermemory answered 75.00% of the 60 questions correctly, Oh 71.67%, and BM25 68.33%. Oh and BM25 each did not finish three of the questions, and those count as misses. GPT-4o wrote and judged the answers, called through a gateway name that is not pinned to one model version. Oh minus Supermemory came to −3.33 percentage points, with a 95% interval from −13.33 to +6.67. The interval includes zero, and Oh’s pilot report says “the paired primary comparison does not separate Oh from Supermemory”. Supermemory ran with one fixed profile and was indexed per session, while Oh and BM25 were indexed per turn, so the pilot says nothing about Supermemory’s defaults or best configuration. The benchmarks page sets out all three studies, and its comparison section lists figures other memory systems publish.

\n

Supermemory extracts memory for you; a Wordcell agent writes it as files

\n

Supermemory builds user profiles automatically through ingestion: a model reads your content for facts about you and adds, updates, or removes them. Its graph memory goes further and “infers a fact you never stated in one place, from patterns across memories” (graph memory and user profiles, checked September 26, 2026). That suits an application that wants memory built for it. It also means a stored fact can come from a step you never saw.

\n

In Wordcell the agent writes the memory as Markdown, and the file is the memory. You can read a note, diff it, and revert it with Git. update_note_body applies an edit only at the revision the agent read, so an edit based on an older copy is refused instead of overwriting a newer one. A supersedes relation keeps the older claim readable beside the newer one. Supermemory marks the latest fact for retrieval, and its documentation says the history “can remain for audit” (graph memory, checked September 26, 2026). Graph answers carry a proof that names each source note and a digest of its content, so an edited note no longer matches the proof (Query the derived graph). Search by meaning uses an embedding model that runs on your machine. When a memory is wrong, it is a line in a file you can find and fix. Markdown memory for coding agents covers the approach.

\n

When Supermemory fits better

\n

Wordcell itself has not been measured against Supermemory; the pilot above tested Oh’s API. Wordcell is a command-line tool over a folder, not a hosted memory service for your product’s users. Choose Supermemory when you want extraction and connectors run for you: its documentation points to the hosted platform for “connectors, MCP, and the best-tuned extraction pipeline” (self-hosting overview, checked September 26, 2026). When Supermemory fits better lists more cases.

\n

Price does not separate the two. Wordcell is MIT licensed, and the commands above run on your machine without an account. The same self-hosting overview says Supermemory’s self-hosted edition is free and open source.

\n

To move an existing Supermemory account, start with Migrate from Supermemory.

\n", }; diff --git a/site/content/blog/introducing-wordcell.md b/site/content/blog/introducing-wordcell.md index fee7341..66b85fa 100644 --- a/site/content/blog/introducing-wordcell.md +++ b/site/content/blog/introducing-wordcell.md @@ -67,6 +67,6 @@ Capture only reads. It does not post, like, follow, send, delete, or submit anyt ## Limits -Wordcell does not write answers. It returns notes, snippets, and graph rows, and your agent writes the answer from them. A graph proof shows that a file said something at a given version, not that the note is correct. Graph queries accept vaults of up to 4,000 notes, and a result that hits a limit is marked as truncated. Search by meaning downloads a local model the first time you use it. An optional reranking step sends the query and note snippets to a paid hosted provider and is off by default. +Wordcell does not write answers. It returns notes, snippets, and graph rows, and your agent writes the answer from them. A graph proof shows that a file said something at a given version, not that the note is correct. Graph queries accept vaults of up to 4,000 notes. A result cut off by its row or proof limit is marked as truncated, and a query that runs out of work fails instead of returning a partial answer. Search by meaning downloads a local model the first time you use it. An optional reranking step sends the query and note snippets to a paid hosted provider and is off by default. Wordcell was called KB until version 0.20.0, and the vault format keeps its `kb` names, so an existing vault needs no migration. Releases up to 0.19.6 use the package name `@hraness/kb`: npm carries them through 0.19.2, and the later 0.19.x versions exist as GitHub Release archives. Newer releases use `@hraness/wordcell`, but older install notes and lockfiles may show the old name.