DEV Community: Pranab Sarkar

49 Minutes Chasing a Silent SSE Hang in mcpier, and the CRLF Regex Behind It

Pranab Sarkar — Thu, 05 Nov 2026 16:02:56 +0000

At 21:30:27 UTC on 2026-04-17 I committed what I thought was the fix, and v0.1.7 was on npm thirty seconds later. The SSE stream still didn't move. No error, no stack trace, just a client waiting on frames that never arrived. Finding the actual problem took another 49 minutes and five more commits, and it turned out to be a regex that assumed the wrong line ending.

To be precise about that number: the hang had been in the code since 13:25 that afternoon and on npm since 21:18. The 49 minutes is how long the hunt took once I was actually hunting.

What mcpier is

mcpier ("Pier," tagline "MCPs, simpler") is a self-hosted control plane for MCP servers. If you run Model Context Protocol servers on more than one machine, you end up with your OpenAI, Gemini, and GitHub keys in plaintext in ~/.claude.json on every box, and rotating one means editing N files by hand. Pier keeps one YAML manifest on a homelab server, encrypts secrets at rest with AES-256-GCM, and hands clients a URL instead of a key. The CLI is npm i -g mcpier (binary pier); the server runs from ghcr.io/spranab/mcpier on port 8420. MIT, one maintainer, me. Code is at github.com/spranab/mcpier, the CLI at npmjs.com/package/mcpier.

The night before

The first session started at 20:34:48 UTC on 2026-04-16 with v0.1.1 and ran until 01:50 the next morning. v0.1.2 went out at 20:49. v0.1.3, at 20:59:45, fixed a bug where every unmatched route, including a plain 404 on /api/whatever, came back as:

{"statusCode":500,"error":"Internal Server Error","message":"reply.sendFile is not a function"}

I'd registered fastifyStatic with decorateReply: false, so Fastify never attached sendFile to the reply, and then my 404 handler called reply.sendFile("index.html") anyway. I found it by running the published CLI against the public ghcr image.

After midnight, the commit message for the 01:12:13 fix calls it the "first production brainstorm-mcp call." brainstorm-mcp declares four optional API-key secrets (required: false), the user had only set a subset, and Pier answered with 500 {"error":"missing secrets: gemini_key, anthropic_key"}. The proxy's secret check didn't carry the required/optional metadata at all. Now it injects an empty string for anything missing and lets the MCP subprocess decide what it needs, which is what the local-install path already did.

v0.1.4 was a real feature, not just a fix. Commit 89fbad505 at 01:21:06 added an activation resolver: workspace config beats user profile, which beats a formula's advisory auto-activate triggers, so Pier stops dumping every installed MCP's tools into the agent's context. The commit message frames it as fixing "the token-budget explosion from a dynamic catalog," and it came with 11 new tests, 27 passing total. It also says the design was "validated by a real GPT-5.4 + DeepSeek brainstorm through this very Pier," so Pier helped design part of itself.

The publish didn't go through. tsup had bundled yaml straight into the CLI, yaml does require('process') internally, and the binary crashed on startup with Dynamic require of "process" is not supported, pointing at ../../node_modules/yaml/dist/compose/composer.js. CI's tarball check (install the packed tarball fresh, run the binary) caught it before anything reached npm. Commit e2b7bf3d0 at 01:23:20 made yaml a real dependency, I moved the v0.1.4 tag onto that commit, and 0.1.4 published at 01:24:34. Nothing on the npm registry shows the first attempt ever happened.

v0.1.5 (c58220f87, published 01:39:28) came from trying to sync a config into a live Claude Code session. The writer emitted "transport"; Claude Code reads "type". Before: {"transport": "sse", "url": ".../mcp/foo"}. After: {"type": "sse", "url": ".../mcp/foo/sse"}, because the URL also needed a /sse suffix. Separately, spawning a Python MCP server in the k8s pod failed with spawn uvx ENOENT since the runtime image only had Node. Installing uv fixed it and added roughly 40MB I didn't love adding.

The last commit of that session was 63c6d0bba at 01:50:09, a cache pre-warming change. Then nothing for about eleven and a half hours.

The afternoon feature

At 13:25:33, commit f3a1226f2 added the thing that broke. Some upstream MCP servers send an event: endpoint SSE frame carrying an upstream-relative path for the client's follow-up POSTs. Pier forwarded that path verbatim, so the POST went around the proxy instead of through it. I wrote a rewriteSseEndpoint stream transformer to fix the path in flight. It went out as v0.1.6 at 21:18:28, almost eight hours after the commit.

The hunt

My first guess (47147871f, 21:30:27) was framework plumbing. Node's native fetch hands back Response.body as a WHATWG ReadableStream, Fastify's reply.send() doesn't know what to do with one, so maybe the headers just never flushed. I wrapped it in Readable.fromWeb() and published v0.1.7. Same silence.

Second guess, also plumbing (8f366d724, 21:41:21). I kept the fromWeb wrap and added a hijack of reply.raw, Fastify's escape hatch to the socket, piping straight into it. That's the pattern the stdio-SSE path already used, and that path worked. Server-only change, so no version bump, just a new ghcr image.

Then three commits of looking instead of guessing. One of them, ffd7301c7, moved the hijack ahead of writeHead as well as adding logging, so it wasn't pure instrumentation. At 21:59:57 I turned the rewriter off to check whether the raw plumbing worked on its own, and at 22:09:16 I turned it back on with logging on the read side.

At 22:19:19, 8c8fec5d7 had the answer. The upstream I was testing against, my own yantrikdb deploy, sends CRLF. The rewriter assumed LF. [^\n]+ captured the data value up to the \n, which dragged a trailing \r into the capture, and the terminator pattern \n\n never matched the real terminator, \r\n\r\n. A failed match isn't an exception. The transformer just never emitted anything.

# frame shape on the wire from a CRLF upstream
event: endpoint\r\ndata: <path>\r\n\r\n

# before                      # after
data value:  [^\n]+           data value:  [^\r\n]+
terminator:  \n\n             terminator:  \r?\n\r?\n

The fix also preserves whichever line ending the upstream actually used, and the debug logging came out in the same commit.

Whose name is on which commit

Four commits in this story carry Co-Authored-By: Claude Opus 4.7 (1M context): f3a1226f2 (the rewriter), 47147871f and 8f366d724 (both wrong guesses), and 8c8fec5d7 (the real fix). The plain bugfixes from the night before (88a35376f, e38692c9b, e2b7bf3d0, c58220f87) don't have it. Neither do the three debug commits.

So the AI pair shows up on the feature that broke and on every attempt to fix it, and it's missing from the stretch where I was reading logs. I don't think the lesson is that the model wrote a bad regex. I approved it. My read is that the two co-authored fix attempts were both confident theories about Fastify and web streams, written before anyone had looked at the bytes coming in, and that order of operations is what cost the time. Log the input first, then theorize. I'd hold any pair to that, human or not.

Still on 0.1.7

npm view mcpier version still says 0.1.7. publish.yml only runs on a published GitHub Release, and the workflow comment says it plainly: "Only a GitHub Release publishes to npm. Tags on their own do nothing." The ghcr job in ci.yml runs on every push to main and tags each image twice, latest plus a short git SHA. So the server does get an identifier per commit, just not a number anyone chose on purpose, and the CRLF fix lives in the server image under one of those SHAs.

That's fine by me. The npm package has no proxy code in it at all; its dependencies are commander, kleur, inquirer, and yaml. CLI 0.1.7 isn't half-fixed, it just tells you nothing about the state of the server, and cutting a CLI release for a server bug would have been noise.

What I think was actually sloppy is the testing. The repo had tests before any of this: config.test.mjs, crypto.test.mjs, manifest.test.mjs, smoke-test scripts, and a CI job running npm test plus a Docker smoke test. The activation resolver got 11 new tests the same night. The SSE rewriter got none. I checked the full tree today, 2026-11-05, and nothing covers rewriteSseEndpoint or the CRLF case, then or since. The one piece of code in this whole stretch that fails without saying anything is the one piece with no test. The only thing that proved the fix was a manual run that night against my own deploy. Config parsing has fixtures. A regex sitting between every SSE upstream and every client doesn't.

For scale: as of today mcpier has 1 GitHub star, 0 forks, 0 open issues, and 24 npm downloads in the last 30 days, 17 of them in the past week. The last push was 2026-09-05.

Pranab Sarkar, Independent Researcher

A contributor found the live twin of a namespace bug I'd filed as low priority

Pranab Sarkar — Thu, 29 Oct 2026 15:16:07 +0000

The test store had two namespaces. Into "alice" went ALICE-SECRET der Server steht in Berlin. Into "bob" went BOB-SECRET der Server steht in Wien. The test then handed both memories the same hand-built embedding vector, which pins their cosine similarity at 1.0 whatever the words say, and let the engine run its trigger checks. The trigger that came back named both namespaces, and its payload read "text_a":"BOB-SECRET ...","text_b":"ALICE-SECRET ...","similarity":1.0.

Forcing the vectors takes the embedding model out of the experiment. What's left is the question the check should have been asking and wasn't: do these two memories belong to the same owner? It never looked. Any cross-namespace pair that cleared the threshold got written down with both texts in full, next to each other.

Hugo Gundlach (Huy3ko on GitHub) wrote that test against engine 0.23.3 and posted its output on an issue I had opened six weeks earlier about almost exactly this shape of bug. I had marked my issue low priority.

I maintain YantrikDB, a Rust memory engine that AI agents embed so facts and decisions survive between sessions. The core README describes the embedded engine as single-tenant, one file per user, and that is still its main shape. Every memory row also carries a namespace column, though, and integrations like the Hermes plugin use it to keep several agents or users apart inside one store. The engine treats that column as a hard boundary in several places. consolidate_cluster errors out with "consolidate_cluster: members span namespaces ('{}' vs '{}' at {rid}) — a cluster must be consolidated within one namespace", and the claim-conflict scans join on e1.namespace = e2.namespace.

The check

check_redundancy lives in crates/yantrikdb-core/src/cognition/triggers.rs. It runs by default as part of think(), the background pass that does consolidation plus redundancy and conflict detection. Before the fix, its query was:

SELECT rid, text, embedding FROM memories
WHERE consolidation_status = 'active' AND embedding IS NOT NULL
ORDER BY created_at DESC LIMIT 30

That's the 30 most recent active memories in the whole store, each compared against every other. A pair above the threshold became a redundancy trigger, or a potential_conflict trigger through a sibling branch when the two shared an entity. Both kinds carry context.text_a and context.text_b holding the full source text with no length cap, and both get persisted to trigger_log. So a cross-namespace match is one person's memory sitting in a table row beside another person's.

The threshold has its own, older bug. It's meant to come from config.consolidation_sim_threshold, default 0.6, and the function ignored that and used a hardcoded let threshold = 0.85;. The fix PR left it alone and listed it as out of scope.

Issue #242, which I wrote

I'd come at this from a different direction in September. A user filed yantrikdb-hermes-plugin #87: on the embedded backend, think() silently never did any maintenance. The plugin always passes a namespace key in the think() config dict, think() whitelists its config keys, and namespace is only on recall()'s whitelist. Recall and remember worked; think did nothing, and the only evidence was a DEBUG-level think(): unknown config key "namespace".

While tracing that I read find_clusters() and noticed it never checks namespace at all. On 2026-09-17, on engine 0.23.0, I opened issue #242: "find_clusters() has no namespace check; cross-tenant merging is prevented only by the caller's grouping." Its caller, find_consolidation_candidates_page, groups memories by namespace before handing them over, and I confirmed that grouping held on 0.23.0. I proposed enforcing the rule in commit_consolidation, the chokepoint every consolidation path goes through, so it wouldn't depend on callers remembering. Then I wrote: "Low priority — no user is affected today. Filing it so the invariant is written down somewhere other than the caller's control flow."

The diagnosis was right as far as it went. Where I went wrong was treating find_clusters as the whole problem. I had just found a function that reads memories with no namespace predicate and is safe only by accident of its caller, and I didn't go looking for other functions that read the table the same way without any caller protecting them. check_redundancy was one.

Late on the 27th

I shipped v0.23.3 at 20:38 UTC on 2026-10-27, closing out a partial fix for the consolidation-seed bug (#253) and a long-pending bundled-embedder cache-dir fix (#252). About three hours later, at 23:49 UTC, Huy3ko committed his fix. He opened PR #256, "fix(triggers): keep redundancy pairs inside one namespace," eight minutes after that, and two minutes later commented on #242: "Related, but on a different path — and this one was not latent." The PR body says "Refs #242, does not close it." He wasn't new to the project; he'd had a PR open against the Hermes plugin since 2026-10-17, adding correction chains and historical recall, and it's still open.

The fix has two layers. check_redundancy now first runs SELECT DISTINCT namespace FROM memories WHERE consolidation_status = 'active' AND embedding IS NOT NULL, then calls a new private check_redundancy_in_namespace once per namespace, each with AND namespace = ?1 bound through rusqlite::params![namespace].

Behind that sits drop_cross_namespace_triggers, called inside filter_and_persist_triggers just before anything reaches trigger_log. It resolves the namespace of every source_rid on each trigger and drops, with a tracing::warn!, any trigger whose rids land in more than one namespace. If a rid can't be resolved because its memory has since been deleted, the trigger passes through untouched; the code comment says "guessing ownership there would drop legitimate single-rid triggers for forgotten memories." The commit message gives the reason for the second layer: "the boundary does not depend on every future check remembering to scope itself."

My opinion, which not everyone will share: that second gate matters more than the query fix. The query fix closes this function. The gate at the write path covers whichever trigger check someone adds next year without thinking about namespaces, which is the kind of mistake I'd just demonstrated I make.

The diff was 2 files, 288 insertions, 2 deletions. A new test file, crates/yantrikdb-core/tests/trigger_namespace_isolation.rs, has three tests. no_trigger_payload_carries_two_peoples_text is the Berlin/Wien one above. identical_text_in_two_namespaces_yields_no_cross_namespace_trigger is the plainer case: the same sentence, "Der Mailserver laeuft auf Debian 12 mit Postfix.", with the same vector, in both namespaces. Both fail without the fix. The third, near_identical_text_in_one_namespace_still_raises_redundancy, has to pass before and after, so the fix can't get the first two green by switching redundancy detection off. 2207 tests passed, cargo fmt --check was clean, and clippy reported no new warnings.

The commit message does get one detail wrong. It says think() reaches this check twice per run, once in Phase 1 and again through check_all_triggers. think() calls check_redundancy once, in Phase 1. check_all_triggers is a separate public function, also exposed to Python, that think() never calls. It doesn't affect the fix. Nobody caught it in review, and I didn't catch it when I merged.

Review and merge

The review on the PR came from the delegated reviewer that posts under my spranab account. My local checkout was behind main, so it checked the change through gh pr diff and gh api against the fork branch without running the suite. It confirmed the old query had no namespace predicate and that text_a/text_b carry full source text, calling a cross-namespace row in trigger_log "a genuine disclosure." It checked both out-of-scope claims in the PR: the aggregate trigger checks (check_valence_trend, check_relationship_insight, check_entity_anomaly, check_consolidation_triggers) still compute store-wide but carry no text, and the 0.85 threshold predates the PR. Then it approved and stopped: "Since it's a logic change to the core engine (not docs/data), merge is Pranab's call rather than something I'll action directly — flagging it to him now."

That's the rule I set for it, and this PR is the case the rule exists for. It can check a diff line by line against the code; a change to what the core engine writes to disk is still mine to merge.

I merged at 02:19 UTC on 2026-10-28, 2 hours 22 minutes after the PR opened, and published v0.23.4 at 02:44, about six hours after v0.23.3. From Huy3ko's comment on #242 to a shipped release took under three hours. My release notes:

Behavior change: the redundancy scan now covers up to 30 records per namespace instead of 30 per store. On stores with many namespaces, think() does proportionally more work there and can raise more redundancy triggers.

Existing stores: this release prevents new cross-namespace triggers but does not remove ones already written. If you run multiple namespaces in one store and want to clear old ones, inspect trigger_log for redundancy / potential_conflict rows whose source_rids resolve to different namespaces.

Some people will think a privacy fix should clean up after itself on upgrade. I'd rather a patch release didn't delete rows from someone's database without asking, and tell them exactly which rows to look at instead.

I thanked him on the PR: "the write-up made it quick to review: the control test, and the out-of-scope items measured and named rather than left out." The fix commit's author field reads "Vela vela@localhost", an address not linked to any GitHub account, so GitHub doesn't credit him. A same-night commit to CONTRIBUTORS.md records the credit by hand, along with wolf-crazy and antonius888. I don't know where the name Vela comes from.

Still open

242 is still open. `find_clusters` still relies on its caller's grouping, and the four aggregate checks still compute across the whole store. They carry no text, so they can't leak the way `check_redundancy` did, but the boundary isn't enforced everywhere yet. PR #256 fixed one function and its payload, and added a gate in front of the log.

I'd like to say a quick grep would have found check_redundancy in September. It wouldn't have. Searching the core engine's source for FROM memories lines with no namespace on the same line returns roughly 277 of 319, most of them fine, scoped by a bound parameter a line further down or correctly store-wide by design. Finding the bad ones means reading each query and asking who owns the rows it returns. That reading is what I skipped when I verified one caller and wrote "no user is affected today."

Pranab Sarkar, Independent Researcher

The seed is just the oldest record, and other things I got wrong about a YantrikDB merge bug

Pranab Sarkar — Thu, 22 Oct 2026 15:09:07 +0000

On 2026-10-16, antonius888 opened issue #253 on YantrikDB, the Rust memory engine for AI agents I maintain. In one think() consolidation pass, five memories from four unrelated topics (two delegated-task prompts, a fact about DPI community tools, two Bitwarden facts) were folded into one consolidated record whose text began "Hermes dashboard autostart: TWO mechanisms...". None of the five had anything to do with dashboard autostart.

yantrikdb-hermes-plugin runs the engine in-process as a memory backend for the Hermes agent framework, and its on_pre_compress hook writes a "compression gist" into the store before a conversation chunk gets trimmed: importance 0.75, metadata {"source": "compression_summary", "pre_compression": true, ...}. antonius888's gists ran over 1,300 characters, up to about 1,400.

What they posted:

Consolidation multiplies an absorbed record's importance by 0.3 (consolidate.rs:1191), so a 0.6 record comes out at 0.18. Their absorbed records landed between 0.18 and 0.24.
Over many think() passes (the engine only commits a handful of consolidations per pass by default), the store had built up 84 distinct consolidation targets: {2: 31, 10: 22, 3: 8, 1: 5, 6: 5, 4: 4, 5: 3, 8: 3, 7: 2, 9: 1}. The 22 at exactly 10 are sitting on the max_cluster_size hardcoded at the call site, consolidate.rs:774.
Ten pending "redundancy" triggers, urgency 0.988 to 0.997. Of the three quoted with scores, the 0.9973 one paired a gist with an unrelated 1C ERP fact written in Russian. The 0.9915 one was two different "Strata install" gists, which might honestly be near-duplicates, and the 0.9890 one was also gist against gist.

They proposed four fixes (exclude summaries from clustering, cap a gist's similarity influence, promote the pre_compression tag to a column, cap gist length) and had already added a local env var, YANTRIKDB_COMPRESSION_GIST, to turn the write off.

Two things I had wrong

I replied the same day, on engine 0.23.2, with a theory for why the entity-overlap guard in find_clusters didn't stop this. That guard has been in the engine since April (commit a27ab9f, the v0.4.2 to v0.4.4 core sync). It skips a candidate when both records have extracted entities and the sets share nothing, which keeps "Alice is CEO" from merging with "Sarah is CTO". My theory was that a gist's entity set covers everything it summarized, so it's never disjoint from anything and the guard can't fire.

That describes a record the plugin doesn't write. Here's the end of _compose_compression_gist on the plugin's main:

intent = (first_user or "").strip().replace("\n", " ")[:200]
outcome = (last_assistant or "").strip().replace("\n", " ")[:200]
n = len(middle)
if outcome:
    return (
        f"[compression-summary, {n} turns] "
        f"intent: {intent} | outcome: {outcome}"
    )

First 200 characters of the first user turn, first 200 of the last assistant turn, inside a fixed template. Nothing from the middle of the conversation gets read. That tops out around 450 characters on main, and v0.27.0, the release antonius888 was running, has the same cap. So 1,300-character gists match neither. I asked in the thread whether their copy of the hook had been modified. I still don't know.

The second mistake was one I'd been carrying around in my head, and I only caught it re-reading the Rust for this post. I'd been picturing the engine choosing the gist as a cluster's seed because it sits near so many other vectors. Seed choice has nothing to do with similarity:

// Sort by creation time (return indices)
let mut indices: Vec<usize> = (0..memories.len()).collect();
indices.sort_by(|&a, &b| memories[a].created_at.total_cmp(&memories[b].created_at));

let mut used = HashSet::new();
for (seed_pos, &i) in indices.iter().enumerate() {
    if used.contains(&i) { continue; }
    let mut cluster = vec![i];
    used.insert(i);
    // ... candidates are later records in time order, checked against
    // time window, entity-overlap guard, then cosine similarity

The earliest unused record becomes the next seed. A gist seeds a cluster only when it happens to be the oldest unused record in its neighborhood.

Where the merged text comes from matters more. The consolidation target is a brand-new record built by extractive_summary, which sorts members by importance, highest first, and leads with the top one's text. Ordinary facts in a store like this sit around 0.5 to 0.6. A gist is 0.75, so whenever one lands in a cluster, as seed or member, its text will very likely open the merged record.

The "Hermes dashboard autostart" record from the top isn't a gist (gists always start with the literal [compression-summary,), so I'm not pinning that one on gists. Same mechanism, though: the highest-importance member named a cluster that was mostly about other things.

The embedder

On 2026-10-17, a day after my first reply, I posted a partial correction: the gist is a real but secondary factor, and I think the main cause is the embedder.

I'd installed the published yantrikdb==0.23.2 wheel into a clean venv and, on a fresh store, scored text modeled on the report by calling the engine directly, once with the default embedder and once with potion-multilingual-128M:

pair	default embedder	potion-multilingual-128M
unrelated Russian↔Russian (1C/Bitwarden/gist/FoodTorg)	0.83–0.93	0.14–0.47
unrelated English↔English	0.04–0.23	0.21–0.33
Russian gist ↔ English gist	0.17	0.46

The default, potion-base, is the static, English-only model bundled in the wheel. Unrelated Cyrillic text scores 0.83 to 0.93 against other unrelated Cyrillic text, well over the 0.6 clustering threshold. That alone is enough to explain the gist-to-1C trigger, clusters filling to the size-10 cap, and the importance loss.

The last row is where the gist does contribute. Under the multilingual model, a Russian gist and an English gist still score 0.46, and the only thing they share is the [compression-summary, N turns] intent: ... | outcome: ... scaffolding. Every gist carries it, which gives gists a similarity floor with each other that ordinary facts don't have, and is a likelier story for the two gist-to-gist triggers than anything in their content.

Switching embedders has its own wall. On a store that already holds data, set_embedder_named() refuses and points you at db.reembed(), which isn't callable from Python (#241). My test also bypassed the plugin's config path, so I can't vouch for it end to end. Through the plugin, YANTRIKDB_EMBEDDER also needs YANTRIKDB_EMBEDDING_DIM set or it raises, and the plugin README documents a second route, YANTRIKDB_EMBEDDER_MODEL2VEC=minishlab/potion-multilingual-128M, which needs the model2vec package. Either way it means a fresh store and a re-import; consolidated originals keep their full text, so nothing is lost.

I committed to three follow-ups: make reembed() callable from Python; warn when stored text is mostly outside the embedder's language instead of degrading silently; and on the plugin side, a config switch for the gist write plus keeping gists out of the seed role.

The question I owed wolf-crazy

wolf-crazy, who already has one merged fix in this repo, picked up the seed-role piece today. Gists stay eligible as members and never become the seed. Their useful find: MemoryWithEmbedding, the struct find_clusters already works on, carries a metadata field filled from decrypted JSON at two construction sites, so there's no schema change and no extra decrypt. The proposed shape is an Option<&dyn Fn(&MemoryWithEmbedding) -> bool> parameter, None by default, so every other caller keeps today's behavior. That includes patterns.rs:327 and the Python binding at py_consolidate.rs:45, the _find_clusters antonius888 named in the report. (Checking that one, I noticed it passes None for the entity map, so the guard my first theory was about doesn't even run on that path.)

Their claims checked out against origin/main at 1d48d09 earlier today — the files involved hadn't changed since before the issue was even filed.

They asked one direct question: key the predicate off the pre_compression tag already in the metadata blob, or promote it to a real column first?

The reply that verified their work, posted under my account, was written as triage and pushed that data-model call to me instead of making it in a comment. When I sat down to write this, I still hadn't answered wolf-crazy.

So here's my answer: use the tag.

The reason sits a few dozen lines above where find_clusters gets called, at consolidate.rs:727-731:

let memories: Vec<MemoryWithEmbedding> = memories
    .into_iter()
    .filter(|m| m.metadata.get("consolidated_from").is_none())
    .collect();

Records tagged consolidated_from are dropped before clustering starts, so the next pass doesn't re-merge a summary with its own sources. A metadata key already decides clustering eligibility in the same file, and reading pre_compression for seed eligibility is the same kind of decision. A column earns its cost once there are enough opt-out knobs to want to query or index them. Right now there are two, both in a blob we already decrypt. If more show up I'll be migrating a live table with encrypted metadata on it, which won't be fun, and I'd still rather pay that later than pay for it now. Someone with more production migrations behind them could fairly call that backwards.

What I don't have an answer for is the other half. Keeping gists out of the seed role changes which record a cluster is measured against. It doesn't touch extractive_summary, which will still put a 0.75 gist at the front of any cluster it joins as a member, and with that template floor, gists join clusters easily. The plugin's source calls 0.75 "higher than baseline; this is a deliberate save." Lowering it, skipping gists when picking the lead, or dropping them from clustering the way consolidated_from records are dropped would each undo something chosen on purpose. I haven't picked one, and wolf-crazy's PR shouldn't wait on it.

Pranab Sarkar, Independent Researcher

I wrote down the cause of this leak two months before anyone reported it

Pranab Sarkar — Thu, 15 Oct 2026 15:08:39 +0000

At 00:19:25Z on 2026-10-13, wolf-crazy opened issue #251 on YantrikDB, the Rust memory engine for AI agents that I maintain. A host running the engine through yantrikdb-hermes-plugin had collected about 60 directories, roughly 490MB, over about eight days. One potion-2M-<pid> directory per process start. None of them ever removed.

The directories come from BundledEmbedder, the zero-setup default. Its model, potion-base-2M, is about 7.9MB of files compiled into the binary with include_bytes!. The loader, model2vec_rs::StaticModel::from_pretrained, reads from a directory, so the first use in every process writes those bytes to disk. This is what the write looked like:

let temp = std::env::temp_dir()
    .join("yantrikdb")
    .join(format!("potion-2M-{}", std::process::id()));
std::fs::create_dir_all(&temp)
    .map_err(|e| format!("create temp dir {}: {e}", temp.display()))?;

A new directory for every PID, and nothing anywhere in the file that deletes one.

PR #128

wolf-crazy's report cross-referenced PR #128, "process-global model init + download retry." That PR fixed a different bug, a race during concurrent model initialisation. Its commit message says "the extraction path is keyed only on process::id()."

I wrote that PR. I merged it on 2026-08-12.

So the mechanism behind this leak had been sitting in my own words, in my own merged commit, for two months. I'd noticed the PID keying while fixing the race, written it down, and done nothing else with it. It took someone else's disk filling up for it to matter to me.

My reply

I answered 15 minutes and 44 seconds after the issue went up. I grepped the file on origin/main at 3dbb86a for remove_dir_all, impl Drop and TempDir, found none of them, and confirmed the bug.

wolf-crazy had proposed two fixes: cache the extracted model in a stable place keyed by model identity, or remove the directory on drop. I picked the cache, under dirs::cache_dir(), because it also gets rid of the one-copy-per-process-start cost instead of only cleaning up after it. I also gave a stopgap for anyone already sitting on a pile of these:

find "$TMPDIR/yantrikdb" -maxdepth 1 -name 'potion-2M-*' -mtime +1 -exec rm -rf {} +

Remove-on-drop turned out to be a non-starter anyway, and the PR body later explained why: "MODEL is a static OnceLock>, so the model lives for the whole process and a Drop on BundledEmbedder never runs. Cleanup-on-drop cannot fire." That OnceLock is the one #128 introduced.

The first version was already safe

wolf-crazy opened PR #252 at 00:49:28Z. The first commit, 7f60cf0, keyed the extraction directory on a fingerprint of the model's contents and left it under std::env::temp_dir()/yantrikdb/. Every process start reuses one directory. The host still only needs a writable $TMPDIR, same as before. That fixes the leak completely and introduces no new requirement.

At 03:55Z wolf-crazy force-pushed a rework, b9cedc1, moving the directory to <dirs::cache_dir()>/yantrikdb/models/potion-base-2M-<fingerprint>. Their comment on the PR: "reworked along the direction you gave on #251."

That rework is where the risk came in, and it came in through my suggestion.

The review

I reviewed b9cedc1 at 04:21:43Z and requested changes. The main point:

The bundled model is the default path, the one that has to work without network access or setup. Today it only needs a writable $TMPDIR. With this PR it needs a writable cache dir, and hosts where HOME is set but read-only would fail on startup where they work now: systemd units with ProtectHome=read-only, containers with a read-only root filesystem and a tmpfs /tmp, and service users with HOME=/nonexistent. dirs::cache_dir() returns Some in all of those, so the existing None fallback doesn't help.

I asked for the fallback to cover the whole extract step, since "a directory that exists but is read-only fails at the write." My issue reply had said nothing about any of this. I didn't see the problem with my own idea until there was code for it, and the first code for it was this commit.

The second request was about the regression test, which checked !s.contains(&std::process::id().to_string()) against a path that also holds a 64-character hex fingerprint and a model name. Any PID whose digits show up somewhere in that string fails the test for no reason connected to the bug. My review listed them: "PIDs 1–9, 17, 18, 20, 25, 36, 42, 57 and 23 others below 100,000."

I recounted that against the real fingerprint while writing this. It's 18 others, 34 in total. I got the count wrong in the comment asking for the test to be exact.

The same review closed with a note that nothing in the PR cleans up directories that had already leaked, and that we'd cover the cleanup from #251 in the release notes.

The second commit

d37c2c5 landed at 06:47:55Z. It moves extraction into a shared extract_into(dir), and init_model() now looks like this:

fn init_model() -> Result<StaticModel, String> {
    let primary = extraction_dir();
    let dir = match extract_into(&primary) {
        Ok(()) => primary,
        Err(e) => {
            let fallback = std::env::temp_dir().join("yantrikdb").join(dir_name());
            extract_into(&fallback).map_err(|e2| {
                format!(
                    "{e}; temp-dir fallback {} also failed: {e2}",
                    fallback.display()
                )
            })?;
            fallback
        }
    };
    StaticModel::from_pretrained(&dir, None, None, None)
        .map_err(|e| format!("model2vec_rs load: {e}"))
}

Any failure on the cache path, at any stage, retries the whole extraction under $TMPDIR with the same fingerprint-keyed name, and if that fails too, the error carries both causes. wolf-crazy tested it with XDG_CACHE_HOME=/proc/self/nope, a cache directory that resolves but can't be written, and the model-dependent tests passed through the fallback. They reported 2204 passing for cargo test -p yantrikdb --lib and 2215 with --all-features. Across both commits the change is +146/-22.

CI on d37c2c5 started around 06:54Z. The Windows leg finished last, at 07:15:05Z. Everything was green: Linux x86 and ARM, Windows, macOS, Python 3.10.

Where the 18 hours went

I approved at 12:30:57Z: "I read the diff but didn't re-run the suite myself. Between that and CI, this looks ready — queuing it for a final merge decision." That was about five hours and sixteen minutes after CI went green.

The merge came at 18:45:39Z, about six hours after that approval, with one last comment: "CI is green across Linux x86/ARM, Windows, macOS and py3.10. Thanks for the careful work and the quick turnaround, @wolf-crazy."

From issue to merge took 18 hours 26 minutes. wolf-crazy's work fits inside two stretches, 00:49 to 03:55 and 04:21 to 06:48, under six hours combined. CI took about twenty minutes. From 07:15, when the last check passed, to 18:45, the PR was green, reviewed and waiting on me. That's eleven and a half hours, the biggest single block of the whole timeline.

I don't think that's a problem, and I know some maintainers would read it as one. A green CI run and an approved diff from a contributor who had already caught his own regression once is exactly the kind of PR that's safe to leave behind a dozen other things for most of a day. The alternative is merging faster than I actually review, and a stale disk-filling bug that sat unfixed in my own PR description for two months doesn't get worse by sitting reviewed-and-green for half a day more.

The release-notes cleanup I promised hasn't been written yet. The last release was v0.23.2 on 2026-10-02, and nothing has shipped since, this fix included. Until there's a release, the find command from the issue is the only cleanup anyone has.

Pranab Sarkar, Independent Researcher

A failed SQLite integrity check on Windows that reported itself as a POSIX lock conflict

Pranab Sarkar — Thu, 08 Oct 2026 15:11:10 +0000

For several hours on 2026-09-30, every memory write from a Hermes Agent install on a Windows 11 machine failed with this:

YantrikDB unavailable: remember failed: refusing to write: another SQLite library has C:/Users/<user>/AppData/Local/hermes/yantrikdb-memory-ml.db open in this process (issue #225 - POSIX locks are per process, so its unlock releases the engine's and the two writers would interleave WAL commits). Close that connection, check integrity and reopen the engine (its close may have unlinked the shared-memory file); use the engine API / a separate process for raw SQL.

The engine refusing those writes was YantrikDB 0.23.1, a persistent memory engine for AI agents that I maintain (Rust core, Python bindings on PyPI). @pawelsu8 filed issue #247 the same day, from Windows 11 build 26200, CPython 3.14.7 and stdlib sqlite3 3.53.1. The title is long, and every clause in it turned out to be accurate: "ForeignSqliteInstance latches writes off on Windows, where the foreign-instance detector is inert: a failed quick_check taints the store but reports as an in-process foreign SQLite library, with no in-process recovery."

The message described something that can't happen on Windows

The error is about POSIX advisory locks. They belong to the whole process, so if another SQLite library in the same process closes the same file, its unlock releases the engine's locks as well. That's the scenario the engine's in-process foreign-SQLite detector, ForeignSqliteGuard, looks for.

On Windows the detector does nothing. ForeignSqliteGuard::new sets shm_path = None on any target that isn't Linux or macOS, so supported() returns false and scan() returns immediately. The module's doc comment says so: "Windows locks are per handle and does not have the problem; there the detector reports supported = false and the mode is inert."

@pawelsu8 checked that against the running system. He dumped stats() on the affected machine and got foreign_sqlite_supported: false, foreign_sqlite_active: false, foreign_sqlite_tainted: false. Then he opened the same store with Python's stdlib sqlite3, read-only and read-write, with and without commits, and none of it ever set active or tainted. The detector was inert exactly as documented, which meant something else was refusing his writes.

Where the refusal came from

check_write() doesn't look at the active flag the detector sets. It refuses on tainted, and tainted has a second writer with no platform gate: note_integrity(). The background materializer tracks SQLite's PRAGMA data_version, and when it notices a commit from outside the engine it runs PRAGMA quick_check(1) on a read connection and hands the result to note_integrity(). A failed check sets tainted.

On Windows that's the only thing that can set it, so every refusal of this kind on that platform was a failed integrity check. Both causes raised the same error type, ForeignSqliteInstance, with the same fixed message. That message described the cause that was impossible on Windows and told him to close a connection that couldn't exist. What had actually happened, a check saying the database might be corrupt, wasn't mentioned anywhere. He called that "a far more serious thing to be told about," and he was right.

Read-only, with no way out

The Python object exposes close(), but there was no reopen() or recover(). Opening the store from a second process got "database is locked." So the message's own advice, reopen the engine, couldn't be followed from inside the running host or from outside it. Restarting the whole application was the only thing that worked.

Reads kept succeeding the whole time, so nothing looked broken. Refused writes meant no commits, no commits meant no checkpoint, and the WAL file grew to 6,344,832 bytes next to a 6,307,840-byte database.

There was one more exit, which he found by reading the source: set_foreign_sqlite_mode("warn"). It resumes writes without re-checking integrity, and the setting persists, so every future open of that store runs with both refusal mechanisms disarmed. He used it cautiously and flagged it in the issue as worse than the docs make it look.

I confirmed the trace and marked it as a bug. My reply opened with: "Thanks for this one — tracing check_write down to decide() and pulling the stats() flags dump to confirm supported=false empirically is the kind of report that gets acted on fast."

Commit 33d0be9

The fix is commit 33d0be9, 15 files changed, +404/-45, released as v0.23.2 (tagged 2026-10-02T07:04:44Z; pip install -U yantrikdb). Most of it maps directly onto the numbered requests at the end of his issue:

A new IntegrityCheckFailed error, whose message carries the actual quick_check result. ForeignSqliteInstance is now raised only by the in-process detector, so the Windows message above can't be produced at all anymore.
stats() shows the cause too. There are new integrity_tainted and integrity_checks_unconfirmed_since_boot keys, and foreign_sqlite_tainted now reflects the detector alone.
The refusal no longer latches. The next quick_check that returns ok resumes writes with no restart. A repair made from another process is itself an outside commit, so the engine notices it and re-checks on its own.
A failing check is re-run once on the writer connection before anything is refused. A one-off failure gets counted and that's all.

The release note ends: "Reported by @pawelsu8 with a source-level trace, stats() evidence from the affected Windows machine, and test-coverage requests that shaped the fix. Thank you."

The lock nobody could explain

Testing the fix turned up a second bug. What I wrote to him: "Testing it turned up a second problem that explains your 'can't open it from another process' symptom."

While writes were refused, the materializer kept retrying its pending work every 100ms, on every worker, forever. Each attempt took the store's write lock and was then aborted at commit. Seen from any other process, the file was write-locked almost continuously, so his attempt to open the store separately got "database is locked" even with a 30-second busy timeout. So would any attempt to repair it.

That changes how the rest of the report reads. The refusal existed to protect the database until someone worked out what had gone wrong, and the engine's own retry loop was locking out every process that could have done the work. The materializer now pauses while writes are refused and picks back up once a check comes back clean.

Two new Python tests damage a store for real from a second process, by writing a row that violates a CHECK constraint (which quick_check reports), and assert that the engine recovers. One of them failed with exactly "database is locked" before the materializer change went in.

Is one retry enough?

The engine now re-runs a failed quick_check once, refuses only if it fails again, and resumes by itself the next time a check passes. Someone could fairly argue that's too permissive. An integrity failure means possible corruption, and possible corruption should stop writes until a person has looked.

I think one retry plus auto-resume is the right setting for this engine. Its job is to be an agent's memory, and #247 is a detailed record of what a refusal that only a human can clear looks like in practice: hours of dropped writes, reads that make everything look fine, a remedy the user can't reach, and finally a workaround that switches the protection off permanently. The one person who hit this found "warn" by reading Rust source, and he's more careful than most users will be. A refusal that names the failure in the error and in stats(), and lifts when a check passes, is one people will leave turned on.

The cost is that the engine now treats a failure that doesn't repeat as a blip. If the storage underneath is bad enough to produce damage that only shows up some of the time, a clean check can resume writes on top of it. And the best evidence for the stricter view is still open on the issue.

Nobody knows why his process got a bad quick_check result in the first place. His offline copy of the same database checks clean. My last note on the issue says: "Still unknown: why your process got a bad quick_check result when your offline copy checks clean. The original result string was lost with the restart. If it happens again on 0.23.2, the error message and stats()['last_integrity_check'] will contain it, and integrity_checks_unconfirmed_since_boot will show whether it was a one-off. We'd be glad to see either."

I also asked him to switch the store from "warn" back to "refuse". Nothing needs the workaround on 0.23.2, and if it stays set, both refusal paths stay disarmed on every open of that file, including the next time a check fails for a reason none of us can explain yet.

Pranab Sarkar, Independent Researcher

My harness logged "duplicates not canonicalized." It was counting page size.

Pranab Sarkar — Thu, 01 Oct 2026 15:05:34 +0000

Hermes Agent's docs have a user-stories page, and two of the Discord quotes on it explain better than I can why people end up writing their own memory layer. From @mibayy, in the community project showcase: "After ~30 turns, context compression silently removes older messages. A constraint decided at turn 5 is gone by turn 50." @lauratom posted in the same showcase, with more swearing than I'll reproduce, that they'd spent 200 to 400 hours writing a memory kernel for Hermes. In a separate dev-workflow thread they described what it does: "It has actual lifecycle management — decay, promotion, and supersession. So if my negotiation tactics evolve, the kernel actively demotes the old info."

yantrikdb-hermes-plugin is my attempt at that problem, a memory provider for Hermes Agent. MIT-licensed, v0.27.0 on PyPI since 2026-09-19, about 92 stars and roughly 1,600 downloads a month as of 2026-09-28. The README opens with a bolded tagline: canonicalizes duplicates, surfaces contradictions, explains recall.

Below that sits a comparison against the other Hermes providers. The first version of that table came from each provider's own plugin.yaml, and tests/comparison/README.md records why I stopped accepting that: "a provider could implement canonicalization, contradiction tracking, or explainable recall without advertising it. Claiming 'YantrikDB has X and the others don't' based only on what they say about themselves is strawmanning, not comparing."

So tests/comparison/ drives each bundled provider through Hermes' real MemoryProvider contract and saves the raw responses. Six of the nine (byterover, honcho, mem0, openviking, retaindb, supermemory) need a cloud key, an account or a server URL the harness doesn't have, and their rows say unknown. I'm fine with six blanks. That rule matters later in this post, because the harness didn't apply it to itself.

95 passing tests and an "Unknown tool"

On 2026-04-14 I ran the plugin inside an unmodified Hermes 0.9.0 install on LXC 129, with DeepSeek driving. Every yantrikdb_* call the model attempted resolved as "Unknown tool," and it fell back to Hermes' built-in memory tool without complaint.

One guard caused it. get_tool_schemas() checked self._client is None and returned [] until initialize() had run, but Hermes asks for schemas in MemoryManager._register_provider, at registration time, before initialize() is ever called. Hermes registered a provider that had no tools.

The fix returns the schema list unconditionally and moves the readiness check into handle_tool_call(). A regression test, test_schemas_available_before_initialize, went in with it. All 95 unit tests that existed then had passed against the broken version, since none of them called things in the order Hermes does.

What DeepSeek did with `why_retrieved`

Once the tools resolved, the same session asked for yantrikdb_recall with query='Pranab Sarkar Rust' and the raw JSON. The top result:

{"rid": "019d8eac-f59b-...", "text": "My name is Pranab Sarkar", "score": 1.404,
 "why_retrieved": ["semantically similar (0.59)", "recent", "important (decay=0.76)", "keyword_match"]}

Two older "benchmark memory" entries ranked near the bottom with why_retrieved of exactly ["recent"].

On 2026-05-09, on the embedded backend (pip install, no server, no token, a 3-line .env), DeepSeek summarised a recall in its own words: "All 3 memories returned, ranked by relevance × recency × importance. Your name ranked highest (semantic match + keyword + high importance + recency), followed by the Rust preference (keyword match), then the YantrikDB project (high importance but no direct keyword overlap)."

I used to describe that as unprompted, which overstates it. The yantrikdb_recall tool description goes to the model with every tool definition, and it says each result "includes a why_retrieved list (semantic_match / graph-connected / keyword_match / important / emotionally weighted, etc.) so the agent can see why each memory ranked." DeepSeek knew the field existed. It couldn't know in advance which reasons a particular memory would get. It read the real ones off the response and turned them into an accurate sentence.

In the current engine source, why_retrieved is a Vec<String> that scoring stages append to as they touch a candidate. Two reasons you'll see now, "multi-lane agreement (N lanes)" and the staleness hedges added by stamp_trust_metadata, landed in August and June respectively, after both sessions. They describe the current engine. They don't explain that April transcript.

The embedded backend is also just faster for a single-agent setup: record_text p50 0.60ms against 13.8ms over HTTP, recall_text p50 2.58ms against 24.0ms.

Rereading the scale probe

On 2026-05-12, again on LXC 129, against Hermes commit 4610551 and plugin v0.4.2, I pointed the harness at 1000 facts and 20 queries.

writing 1000 facts via yantrikdb_remember...
write retries exhausted for fact #257 after 60 attempts
write retries exhausted for fact #258 after 60 attempts
write retries exhausted for fact #259 after 60 attempts
WRITE TIMEOUT at fact #357 after 600.0s
backpressure retries: 6000
writes: 256/1000 ok (failures=100); p50=0.48ms p99=5.13ms
running 20 queries via yantrikdb_recall...
recalls: 20/20 ok; p50=3.78ms p99=32.94ms; precision@K=16/20
shape (first non-empty result): why_retrieved=True('why_retrieved') score=True metadata=False
duplicate-canonicalization: avg results per Q-dup-* query = 5.0 → false

The last line went into findings_scale.yaml as duplicate_canonicalized: false, and I believed it. The first draft of this post repeated it, with a story about bursts outrunning consolidation. A fact-check on that draft opened the raw response for Q-dup-01, whose target is "The user prefers nord as their color scheme in IntelliJ." The five results were nord in Hyper, 13pt in iTerm2, light mode in Terminal.app, Fira Code in Hyper, and nord in Emacs. The target isn't among them, and no two of them are the same fact.

Here's the check, from tests/comparison/probe_scale.py:

dup_returns = [r for r in per_query_results if r["id"].startswith("Q-dup-")]
if dup_returns:
    avg_dup_count = sum(r.get("returned", 0) for r in dup_returns) / len(dup_returns)
    row.duplicate_count_observed = round(avg_dup_count, 1)
    # If each dup query returns >= 2 results that include the duplicated
    # text, that's strong evidence of no synchronous canonicalization.
    if avg_dup_count >= 2.0:
        row.duplicate_canonicalized = "false"

returned is len(items). The comment says "that include the duplicated text," and nothing in the code reads the text. All five Q-dup-* queries ask for top_k=5, so 5.0 means each one got a full page. Any store holding five vaguely related facts gives you 5.0 and a false.

It couldn't have found duplicates anyway. The planted duplicates in corpus_1k.json are ids 901 to 1000, and the write phase stopped around 256. The transcript shows the timeout and then computes a duplicate verdict on the next lines, for duplicates that were never written. The same harness that marks other providers unknown when it can't run them wrote false here.

The 16/20 precision@5 on the facts that did land is a different number from a different check, and I'm not retracting it here — but it's also scored by word overlap on a templated corpus, which I didn't re-audit hit by hit before writing this. What I can say cleanly is the negative: whatever that score means, it says nothing about duplicates.

Why exactly 256

The write failures were real, and the number has a cause. Engine commit f6132e0 on 2026-06-27, "fix(python): spawn materializer + compactor workers in engine constructors," explains it: the pyo3 constructors "wrapped a fresh YantrikDB in an Arc but never spawned its background worker pool. Without the compactor the in-memory delta tier fills to delta_max (256) and every subsequent write returns Backpressure ('ingest queue full') — wedging any long write session... after ~256 records."

It shipped in engine v0.9.0. The plugin's current minimum engine is 0.12.1, so anyone installing it today has the fix. Write throughput was never the problem. A worker pool that never started was.

So the half of the probe that showed up as a crash got chased down in about six weeks. The half that showed up as a clean-looking verdict sat in a findings file I'd been calling reproducible for almost five months, until this article made me reread it.

The file is reproducible. Rerun probe_scale.py against the same setup and you'll get 5.0 again, every time, because the metric can't produce anything else. I'd been treating "reproducible" as if it meant "checked," and it doesn't. I built the harness because I didn't trust copy I'd written about my own plugin, and then I trusted a YAML file I'd generated without ever opening the raw JSON next to it. I don't think a findings file deserves more credit than a README does. A verdict should cite the raw response that backs it, and a verdict computed from a run that never wrote its test inputs should say unknown. The harness already holds the other providers to that rule.

— Pranab Sarkar, Independent Researcher

The embedder I attached got 0 encode() calls during writes

Pranab Sarkar — Thu, 24 Sep 2026 15:26:27 +0000

A brand-new memory store worked fine in one process. In the next one the plugin's init failed, and every Hermes tool call after that came back with YantrikDB is not active for this session. Underneath, the engine had refused to attach the embedder:

this database's vectors were built by potion-base-8M (digest sha256:89dd…, dim 256), and the embedder being attached declares no `fingerprint` or `digest`.
Queries would be encoded in a different space than the vectors they are compared against, and cosine distance still returns a plausible number for unrelated spaces — so the results would look fine and be wrong.
Options: attach the embedder that built them; set `.fingerprint = "sha256:89dd…"` on your embedder if it IS that model; call reembed() to rebuild the vectors in the new space; or pass allow_unverified_embedder=True if you accept the risk.

albertoMartinsen filed that as #84 on 2026-09-16, on plugin 0.25.0, engine 0.23.0, Hermes Agent 0.21.3, macOS arm64 and Python 3.11.15, with minishlab/potion-multilingual-128M configured through the plugin's model2vec option.

YantrikDB is a persistent memory engine for AI agents, a Rust core shipped to Python as the yantrikdb wheel. yantrikdb-hermes-plugin is a memory provider for Hermes Agent whose default backend runs that engine in-process. I maintain both.

An embedder is the model that turns memory text into vectors. The engine attaches a default one at the store's dimension when it has one: potion-base-2M at 64, inside the wheel, or potion-base-8M at 256, downloaded on first use (about 28 MB, SHA-256 pinned) and cached. The plugin lets you configure your own, and the reporter's multilingual model is 256-d too.

The guard works off a stamp. When the engine's own embedder encodes anything for an unstamped store, it records its identity there (one appears in the output further down). A Python embedder can carry the matching digest as .fingerprint or .digest. Attach one that carries neither to a stamped store and the engine can't tell it from any other model of that width, so it refuses. That refusal is the fix for engine issue #117, which I opened on 2026-07-28: a reopened store accepted a different embedder at the same dimension, and every recall after that was wrong with no error. PR #138 closed it in August.

The reporter had noticed the stamp named the engine's default, potion-base-8M, and read that as the store recording the wrong identity. They proposed a stable fingerprint on the plugin's loader wrappers, with the store recording the intended identity at creation, and offered reembed() or allow_unverified_embedder=True as alternatives. About half an hour later I agreed, on the strength of a grep (no .fingerprint on the wrappers, no allow-unverified flag on that call path), and wrote "Real fix is on the plugin side per your suggested directions", which put the bug in the wrong repo.

83, the reporter's other issue that day (an always-empty fleet view), had a similar shortcut in its tests: they mocked `list_records`, the very method that swapped a missing namespace for the base one, so the swap never ran.

Counting encode() calls

About nine and a half hours after that reply I posted a different diagnosis. I'd reproduced their failure, same sha256:89dd… digest, and counted the attached embedder's encode() calls during a write: 0 at 256 dimensions, where the engine had a native embedder, and 1 at 384, where it had none.

I reran it today (2026-09-24) with a script like the one further down, plus a call counter on the embedder: an unfingerprinted embedder, one record_text, a read of db.embedder_identity(), then a reopen and a reattach. set_embedder calls encode() once as a probe, so the counter is zeroed after attaching. Each version got its own venv from PyPI, on Windows 11 with Python 3.13.5. Trimmed (the ##### headers are mine; I cut the digest and the refusal text):

##### 0.23.0 / dim 256
native embedder present before attach: True
my encode() calls during record_text: 0
identity stamped on the store: {'name': 'potion-base-8M', 'digest': 'sha256:89dd9605...', 'dim': 256}
reopen + reattach my embedder: REFUSED

##### 0.23.1 / dim 256
native embedder present before attach: True
my encode() calls during record_text: 1
identity stamped on the store: None
reopen + reattach my embedder: OK

At 64, where the default is the potion-base-2M inside the wheel, both versions behave as they do at 256; PR #240's five tests run at 64. At 384 there's no default and both look like the 0.23.1 block, matching my 09-16 table.

On 0.23.0, at those widths, no write went through the attached object. potion-base-8M had encoded the reporter's records, so the stamp was accurate and the refusal on reopen was the #117 check doing what it was built for. The plugin log said attached embedder model2vec=… (dim=256) throughout. Someone who chose a 256-d multilingual model on 0.23.0 to hold non-English memories would have been getting potion-base-8M vectors instead, with no error while writing. I haven't measured what that does to recall.

With that override in place, the fingerprint plan (the one I'd endorsed) would have stamped the multilingual model's identity at creation and let the reopen pass, over vectors potion-base-8M produced. allow_unverified_embedder=True skips the comparison. Either would have ended the refusal while the native-first order stayed, and the attached model would still have gotten no calls.

That second comment also said a fresh store, or reembed(), would fix stores already written. Minutes later I retracted the reembed() half: hasattr(YantrikDB, "reembed") is False. It's a staged rebuild with crash recovery in the Rust engine that the Python binding doesn't expose. The guard message above lists it among the options. That's engine issue #241, still open.

The override was in the Python binding, crates/yantrikdb-python/src/py_engine/mod.rs. embed_text asked the Rust-native embedder first and fell through to the attached Python object only when there wasn't one. set_embedder(obj) probes the object with encode("__yantrikdb_probe__"), checks the output is numeric, runs check_embedder_identity and stores it, as the fallback. The wheel is built with the embedder-download feature, so at 64, and at 256 whenever potion-base-8M was cached or could be fetched, the native embedder was already there. The fix, abbreviated:

// embed_text, before: native first; the attached Python object was only the fallback below
if let Some(db) = &self.inner {
    if db.has_embedder() {
        return db.embed(text).map_err(map_err);
    }
}

// embed_text, after: the attached object first; the native check follows
if let Some(emb) = &self.embedder {
    let result = emb.call_method1(py, "encode", (text,))?;
    ...
    return ...
}

Two more places in memory.rs made the same choice, the record_text fast path and then the correction path, and each got one clause:

-None if db.has_embedder() =>
+None if db.has_embedder() && self.embedder.is_none() =>

-let use_caller_embed = new_text.is_some() && !db.has_embedder() && self.embedder.is_some();
+let use_caller_embed = new_text.is_some() && self.embedder.is_some();

I think a default the engine picked because the dimension matched should lose to an object the caller attached by hand, and that's the order now; set_embedder still runs the identity check on that object.

PR #240 merged as 49c7aac, 10h31m after the report (+172/-20, 3 files). Its five tests in tests/test_attached_embedder_precedence.py check both that the attached embedder runs and that the native one still runs when nothing is attached; one first asserts that the dimension really auto-attaches a native embedder.

v0.23.1 shipped on 2026-09-19 with a behaviour change, in a patch release: record_text with an idempotency_key and a Python embedder now raises the existing explicit refusal, where 0.23.0 succeeded through the native path. Stores written the old way keep refusing, and the notes say to start a fresh one.

Plugin v0.27.0 went out the same day. Its dependency range, on main and in the 0.27.0 metadata, is yantrikdb>=0.12.1,!=0.15.0,!=0.15.1,!=0.15.2,<0.24.0, so an install already on 0.23.0 keeps the old order until someone runs pip install -U yantrikdb. I said so in a 09-20 status comment, after running the PR's test file against 0.23.1 from PyPI in a clean venv (5 passed), and left #84 open. I haven't run the reporter's exact configuration, potion-multilingual-128M through the plugin's model2vec path.

The reverse case

On 2026-09-22 the reporter confirmed the fix on plugin 0.27.0 and engine 0.23.1 (a brand-new model2vec store, 5 of 5 reopens in fresh processes through make_backend), then posted a three-step repro for the opposite failure, each step a new process. Create a store with the external embedder; its meta has no embedder_* keys. Open it with the default config and do one ordinary recall, which succeeds without a warning and leaves the store stamped potion-base-8M/256. Go back to the external embedder and it's refused, on a file where PRAGMA quick_check still passes.

I traced it through the engine that day. check_embedder_identity sits in the Python binding and runs only while a Python embedder is being attached, through the constructor's embedder= or set_embedder(). On the engine's own encode path, YantrikDB::embed() calls stamp_embedder_identity_once() after every successful embed, and nothing on that path asks whether the vectors already in the store came from a different model. Query text goes through embed() too, so one recall is enough.

Two days later I ran it. The script below does their three steps against the engine only, 0.23.1 from PyPI in a clean venv, same Windows 11 and Python 3.13.5. Theirs went through make_backend with model2vec on macOS; mine uses a hash-based stand-in and three handles in one process, closed between steps. Trimmed (docstring and an unused import removed):

import math
import shutil
import tempfile
from pathlib import Path

import yantrikdb
from yantrikdb import YantrikDB

DIM = 256


class Counting:
    def encode(self, text):
        if not isinstance(text, str):
            return [self.encode(t) for t in text]
        h = abs(hash(text)) % 100_000
        v = [math.sin(h * (i + 1) * 0.001) for i in range(DIM)]
        n = math.sqrt(sum(x * x for x in v)) or 1.0
        return [x / n for x in v]


d = tempfile.mkdtemp()
path = str(Path(d) / "s.db")
print(f"yantrikdb {getattr(yantrikdb, '__version__', '?')}")

db = YantrikDB(path, embedding_dim=DIM)
db.set_embedder(Counting())
db.record_text(text="Dana Okafor leads the ML Platform team.")
print("1. external embedder writes; identity on store:", db.embedder_identity())
db.close()

db = YantrikDB(path, embedding_dim=DIM)  # default config, nothing attached
hits = db.recall_text("who leads ML Platform", top_k=1)
print("2. default open + one recall; identity on store:",
      (db.embedder_identity() or {}).get("name"))
db.close()

db = YantrikDB(path, embedding_dim=DIM)
try:
    db.set_embedder(Counting())
    print("3. reattach the external embedder: OK")
except Exception as e:  # noqa: BLE001
    print("3. reattach the external embedder: REFUSED")
    print("  ", str(e).replace("\n", " ")[:170] + "...")
finally:
    db.close()
shutil.rmtree(d, ignore_errors=True)

yantrikdb 0.23.1
1. external embedder writes; identity on store: None
2. default open + one recall; identity on store: potion-base-8M
3. reattach the external embedder: REFUSED
   this database's vectors were built by potion-base-8M (digest sha256:89dd960591c4fa0c7f7a45ed4cb94167ce4e09886f39bae008b8072b42439ac5, dim 256), and the embedder being att...

Repeating steps 1 and 2 with the same class, then trying the reattach plain and with the flag the guard message offers, gives:

yantrikdb 0.23.1
after default open + recall, identity: potion-base-8M
plain set_embedder: REFUSED
set_embedder(allow_unverified_embedder=True): OK, write succeeded; identity still: potion-base-8M

The plugin doesn't pass that flag on the external-embedder path (my first reply on #84 says as much), so through the plugin that store refuses the embedder that built it on every open. Nothing supported rewrites the stamp either: adopt_embedder_identity refuses when a different digest is already recorded, and reembed() is #241.

The doc comment on stamp_embedder_identity_once covers this, in a paragraph headed "Known over-claim", and argues the stamp "does not create a failure that was not already there". I think that's wrong, and the repro is why. Skip step 2 and the reattach works (the 0.23.1 run at 256 in the first output block). Do step 2 and it's refused. The default-config session does query in the wrong space, as the comment says, but only for that session; the stamp it leaves locks the plugin out of the embedder that wrote the store.

The reporter suggested two fixes: a symmetric check that refuses the native embedder against a store with vectors and no recorded identity, or stamping the external embedder's identity at the first write. It reproduces on 0.23.1 as of 2026-09-24 and only exists as comments on #84 right now. No engine commit since 2026-09-21 touches the stamping; the latest is PR #246, a vault-key change.

Pranab Sarkar, Independent Researcher

I Rebuilt Real-Time Push Six Times in One Evening, Then Quietly Added a Cron

Pranab Sarkar — Thu, 17 Sep 2026 15:07:27 +0000

SwarmCode is an MCP server that lets two Claude Code instances on different machines message each other, so I stop copy-pasting between two terminal windows when one agent needs to hand work to another. Repo: github.com/spranab/swarmcode. npm: swarmcode-mcp. Neither the name nor the architecture it shipped with is the one it started with.

Claude Code has no native "wake me up when X happens" primitive that plays nicely with a human still typing in the same window. There's no interrupt. Anything that feels like push has to be built by bending some other piece of the toolset into the shape of one. On 2026-03-30, pairing with Claude Opus 4.6, I bent six different things into that shape and kept each one just long enough to find out how it broke.

The evening

28c8822 at 14:51 is the initial commit: "Initial release: MCP server for cross-machine Claude Code communication," named agent-bridge, published as mcp-agent-bridge.

The first push attempt was the crudest. By 16:55 (28daad0) the Stop hook was returning decision:block, which forces Claude to process the inbox before it's allowed to end its turn. A hook built for something else, hijacked.

At 17:17 (1d371fa) I switched to MCP sampling, createMessage, the protocol's own mechanism for a server to request a completion from the client. Between 17:26 and 17:44 I added per-workspace Redis channels plus a broadcast channel, then fixed a same-session bug where publish and subscribe were sharing one connection (e4a743b).

Then e8919c5 at 18:19: a one-shot Redis listener. Spawn it as a background Bash task; when a message arrives the listener exits; the exit fires a VS Code task notification; Claude reads it, replies, starts a new listener. Nine minutes on, ee51ded tagged that v1.2.0, "Real-time channel + background listener for true push in VS Code."

a1c4757 at 19:19 is labelled "v1.3.0: Clean architecture," which undersells it. The body opens "Breaking: removed SSE server (server.js rewritten as CLI router)," and that single commit deleted the SSE server, tools.js, redis.js, check-inbox.js, the Dockerfile, .dockerignore, the K8s bridge and ingress manifests, and the express dependency. An entire transport layer, dropped in one go. Thirty-nine seconds later 532d66f pulled the ghcr.io build out of CI, since there was no longer a Dockerfile to build.

21:56, 0ef29bf: a persistent listener plus a queue file, to make message delivery uninterrupted. Let the listener run forever and write incoming messages to a local file (.agent-bridge-inbox) that a hook reads each turn. No restart, no gap between listeners. It survived nineteen minutes. ac1ae4f at 22:16: "Revert to one-shot listener pattern (proven real-time)."

0cadbb7 at 22:23 went the other way entirely, with no client-side process at all. Swap the plain Server for McpServer with experimental task support and register the listener as a real MCP task:

mcp.experimental.tasks.registerToolTask(
  "bridge_listen",
  {
    description: "Wait for the next message from another workspace. ...",
    execution: { taskSupport: "required" },
  },
  {
    createTask: async (extra) => {
      const task = await extra.taskStore.createTask({
        ttl: 600000,        // 10 min
        pollInterval: 1000, // poll every 1 second
      });
      waitForMessage().then(async (msg) => {
        // ...
        await extra.taskStore.storeTaskResult(task.taskId, "completed", result);
      });
      return { task };
    },
  }
);

Two patches followed before 22:36. 41eb1dd dropped taskSupport from required to optional, because the VS Code extension doesn't advertise required task support. 162dd35 handed the server a task store of its own:

+import { InMemoryTaskStore } from "@modelcontextprotocol/sdk/experimental";
...
+const taskStore = new InMemoryTaskStore();
 const mcp = new McpServer(
   { name: "agent-bridge", version: "1.0.0" },
   {
+    taskStore,

Commit message: "VS Code extension doesn't provide a taskStore, but we can provide our own."

By 23:19 (7b73909) I'd walked away from that too. The commit calls its replacement "The proven pattern," and its diff to src/channel.js (the instructions string the MCP server injects into Claude's context) goes back to the background-listener process from five hours earlier and puts a blocking read on top of it:

Step 1: Start the background listener:
  Bash(run_in_background=true, timeout=600000): AGENT_BRIDGE_REDIS_URL=... npx -y mcp-agent-bridge listen

Step 2: Block-wait for the message:
  TaskOutput(task_id=<id from step 1>, block=true, timeout=600000)

When a message arrives, TaskOutput returns the message. ...
This creates a true real-time event loop with zero user intervention.

The same diff demotes bridge_listen, the task-protocol tool from fifty-six minutes earlier, to "(experimental, may not work in all environments)" in the tools list.

Thirty-one minutes after that, aa40a2d at 23:51: "Use task-notification pattern (non-blocking) instead of TaskOutput(block)." Reason given: "TaskOutput blocks all user interaction." Same instructions string, rewritten again:

The listener runs in the background. When a message arrives, you get a task-notification.
When you see the notification:
1. Read the task output file to see the message
2. Call bridge_receive() to mark messages as read
3. Reply with bridge_send(to: "sender", type: "answer", content: "...")
4. Start a new listener (same command as above)

This keeps you free to interact with the user while listening for messages.

"Zero user intervention" at 23:19; "keeps you free to interact with the user" at 23:51. From the first push attempt at 16:55 to that revert is six hours and fifty-six minutes, and what came out the other end — background listener, exits on message, fires a notification, gets restarted — is functionally what already existed at 18:28.

Except that isn't where it stopped

At 00:13:12, twenty-two minutes later, past midnight but the same sitting, 64dbd7d: "Add CronCreate backup polling to MCP instructions."

Instructions now tell Claude to set up both:

Background listener (real-time push)

CronCreate every 5 min (backup polling)

Belt and suspenders — real-time when listener is active, 5-min fallback when it times out or misses.

The listener runs on a ten-minute Bash timeout, and the only thing that restarts it is Claude working through to step 4 of an instructions blob. The commit's stated reasons for the cron are that the listener times out or misses. So what shipped isn't push. It's push with a five-minute floor underneath, and the floor is the half that doesn't depend on a model remembering a numbered list.

That's still how it works. The live src/channel.js opens with "CRITICAL: Do BOTH of these at the start of every conversation," then the listener, then CronCreate(cron="*/5 * * * *", ...).

On MCP's task primitives

registerToolTask looks purpose-built for this problem: a server-side wait that completes when something happens, nothing to babysit on the client. I'd still not reach for it first, and my reason is those two patches. Getting the primitive to exist at all in the environment I was targeting meant finding out that VS Code doesn't advertise required task support, then that it ships no task store, then shipping my own. Twelve minutes of patching before the thing could run, all of it spent on the gap between what the spec describes and what the client implements. That gap is mine to fill every time, and it moves.

That is not an argument about what killed the next attempt. TaskOutput(block=true) freezing the user's session is Claude Code Bash behaviour, and by then I'd already dropped the task protocol; the same diff that introduced the blocking read is the one that demoted bridge_listen to experimental. Two unrelated failures that happened to land within an hour of each other. The registerToolTask code is still in src/channel.js today, renamed swarm_listen, still registered, just no longer mentioned in the instructions anyone reads.

The rename, and a name one hyphen away

e5cd49d, 2026-03-31 07:52:26: "Rename to SwarmCode — the missing networking layer for Claude Code." agent-bridge became swarmcode, tools went bridge_* to swarm_*, env vars AGENT_BRIDGE_* to SWARMCODE_*. At 08:03:19, b131fcc: "npm package name: swarmcode-mcp (swarmcode was too similar to swarm-code)."

npm blocked the bare name for similarity, not because it was taken; swarmcode sits unregistered to this day. The package it was too similar to is real and actively published: swarm-code, "Open-source swarm-native coding agent orchestrator — spawns parallel coding agents in isolated git worktrees," keyworded swarm, coding-agent, orchestrator, llm, cli, agent. I had picked a name one hyphen off a tool in the same corner of the same problem space, and npm's similarity check noticed before I did. The project is swarmcode everywhere in the source and swarmcode-mcp on npm.

The bug, thirty-five hours in

1745bae, 2026-04-01 02:04:31: "Fix hook performance: use global binary, add Redis timeout." The UserPromptSubmit hook that checks the inbox was shelling out to npx -y swarmcode-mcp check on every single prompt. npx resolves the package, and sometimes downloads it, before running anything: 5-10 seconds, against roughly 0.5 for a globally installed binary. Every prompt paid it. Chats were hanging.

   try {
     const { default: Redis } = await import("ioredis");
-    const redis = new Redis(REDIS_URL, { keyPrefix: "swarmcode:" });
+    const redis = new Redis(REDIS_URL, {
+      keyPrefix: "swarmcode:",
+      connectTimeout: 2000,
+      commandTimeout: 2000,
+      maxRetriesPerRequest: 1,
+      retryStrategy: () => null, // don't retry — fail fast
+    });
     const raw = await redis.lrange(`inbox:${WORKSPACE_ID}`, 0, -1);
     messages = raw.map((m) => JSON.parse(m)).reverse();
     await redis.quit();
-  } catch {}
+  } catch {
+    // Redis unavailable — silently skip
+    process.exit(0);
+  }

The fix pointed the hook at the installed swarmcode check binary, added 2-second Redis connect and command timeouts with retries off, cut the hook's own timeout to 3 seconds, and made an unreachable Redis fail silently rather than visibly.

The name that won't die

Four and a half months on, 7d05b94 (2026-08-18): "Add mcp-agent-bridge migration guide and lead with the problem." From the commit message: "The legacy npm name still gets ~6x the downloads of swarmcode-mcp and its npm page links here, so this README is where those users land." It added a migration banner, a bridge_* to swarm_* mapping table, and kept the old env vars working as a fallback so a half-migrated set of machines could still talk to each other mid-switch.

mcp-agent-bridge has gone 143, 118, 76 downloads per month across 2026-08-31, 09-07 and 09-14. swarmcode-mcp went 19, 31, 31. The 6x from August is about 2.4x now. The dead name is fading and still pulls more than twice the traffic of the live one.

Line 112 of that same README, today: "No polling. No cron. True event-driven push in VS Code." Line 122 is a section headed "Backup polling," and it says a 5-minute CronCreate runs alongside the listener as a safety net. Ten lines apart, in the file I rewrote to lead with the problem. I've known about the cron since 00:13 on March 31 and I still haven't fixed the sentence above it.

Pranab Sarkar, Independent Researcher

My README Was Mostly Right. The Number I "Verified" Wasn't.

Pranab Sarkar — Thu, 10 Sep 2026 15:07:51 +0000

saga-mcp is my MCP server for project tracking. SQLite-backed projects, epics, tasks and subtasks, so a coding agent doesn't lose the plan the moment a session ends. It's on npm as saga-mcp. On 2026-09-04 at 14:29 I was doing something unglamorous with it: filing a submission to the Cline MCP marketplace (github.com/cline/mcp-marketplace/issues/2435). The form wants a tool count, and I had the README open to copy one out of.

At that exact commit (698ef81, which was HEAD when I filed) the README said three things. Line 15, the intro paragraph: "exposed as 35 MCP tools." Line 79, a feature bullet: "35 focused tools." Then line 138, buried in the environment-variable reference table, SAGA_TOOLS set to full (the default) "lists all 33 tools," and core "lists only the 12 an ordinary tracking session needs."

Two of those agreed with each other and the third didn't, which is exactly the smell that makes you stop reading documentation and go measure the thing. So I did. I pointed a client at the published package with SAGA_TOOLS set to full and then to core, and both runs came back with 22 tools.

22 matched nothing in the README. I read that as confirmation the file had rotted, put 22 in the marketplace submission as the verified count, noted that rewriting the README was outside the scope of a registry-submission task, and moved on.

What was actually running that day

Writing this up today, I went back and nailed it down properly instead of from memory. The method is one line and anyone can rerun it: pipe a raw MCP stdio handshake, a JSON-RPC initialize followed by tools/list, into npx -y saga-mcp@<version> with DB_PATH pointed at a scratch file, and count what comes back in the response.

The version genuinely live on 2026-09-04 was saga-mcp@1.8.0, published the day before. It returns exactly 35 tools.

So the README's two prominent claims, the ones a reader actually sees, were correct. The stale number was the buried one in the env-var table, 33 and 12, left behind by a couple of releases. My "verified" 22 was further from the truth than the documentation I'd distrusted.

I did eventually find where 22 lives. saga-mcp@1.1.0 and saga-mcp@1.2.0, both published 2026-02-21, each return exactly 22 tools, and both ignore SAGA_TOOLS completely: full and core give you the same 22. That's the fingerprint I saw and misread. Getting the same count twice regardless of the env var looked to me like "the env var is broken too," and it actually meant "you are talking to a package from six months ago."

How a same-day test landed on a February build, I don't know. A stale npx cache is the obvious guess. A globally installed copy shadowing the npx resolve is the other one. I haven't managed to reproduce either, and I'd rather leave it sitting there unexplained than pick whichever story sounds tidiest.

What bothers me isn't the 22 itself. It's that the wrong number sat in a public marketplace submission for four days, and the reason nobody caught it, including me, is that I had measured it myself. Distrusting the docs and going to the source is the right instinct and I'd do it again. It only helps if you also check what you measured. I never got as far as asking which package had answered me.

The fix that did land

The README work I'd deferred shipped four days later: commit 3dd5df5, 2026-09-08 19:18:58 -0500, "Rewrite the README, and test the claims it makes (#51)," co-authored by Claude Opus 5 per the commit trailer. 849 lines touched in the README itself (changed, not final size) plus a new 189-line test/readme.test.js. From the commit message:

The file had grown by accretion across a dozen releases and was wrong in several places a reader would act on... It claimed ~140 tests when there are 298, and quoted the tool surface as ~6,000 tokens dropping to ~2,700 when the measured figures are ~7,200 and ~2,900... Verified by reintroducing seven kinds of drift that had genuinely been in the file — a stale tool count, a stale test count, a renamed tool, a stale version in the release example, a broken anchor, a stale tab count — and confirming eight tests fail.

It says seven kinds of drift and then lists six. A commit about fixing counting errors, undercounting its own list of counting errors. I laughed, then left it in.

test/readme.test.js checks, programmatically: every real tool is documented and vice versa; the advertised tool counts match what the running server reports; the SAGA_TOOLS=core list matches what the code actually restricts to; the tab list matches the web UI's own tabs; quoted test and e2e counts are current; the release example names the current version; no example calls a tool that doesn't exist; every anchor link resolves. The file's own doc-comment puts the motivation plainly: "The README drifts. It claimed ~140 tests when there were 298, quoted a tool surface two releases out of date, and documented sorting behaviour that had since changed — all of it written in good faith and then left behind by the code."

Two days later

Two days is not a long time to trust a new test, so I reran the handshake against npx -y saga-mcp@latest. It resolved to 1.16.0 and printed:

Tracker MCP Server running on stdio (41 of 41 tools listed)

The current README claims 41. The CORE_TOOLS set in source has also grown from 12 entries to 13, with a new tool called tracker_next (essentially a "what should I work on" query), and the rewritten SAGA_TOOLS table says 13. That's precisely the kind of edit that used to silently desync the count.

The download number I don't trust

Separately, the metrics I run across my packages flagged saga-mcp: npm downloads went from 321/month on 2026-08-31 to 1,808/month on 2026-09-07, a 463% jump, with no new registry listings going live that week and GitHub stars flat at 33 across the whole window. It got logged as unverified, watch if it holds.

The daily numbers for 2026-09-01 through 09-10 are 5, 190, 0, 485, 73, 775, 0, 0, 83, 0. My own publish counts for the same days are 0, 1, 2, 5, 0, 5, 0, 2, 0, 0.

The two biggest download days, 485 on 09-04 and 775 on 09-06, are the two days I shipped five releases each. That fits neatly enough that I wanted it to be the whole answer. It isn't: 09-03 and 09-08 each carried two releases and recorded zero downloads. If publishing reliably drove the counter, those days would show something.

My read, and this is where a reasonable person could land somewhere else: a curve that spikes on my busiest publish days and flatlines in between is more likely measuring registry mirrors and dependency scanners refetching new versions than it is measuring people installing the thing. The counter-examples mean I can't prove that, and I'm not claiming the correlation is clean. I am claiming that "up 463%" does not belong in a scorecard on its own, which is inconvenient, because it's a very nice number and nobody would stop me from using it.

The README test now fails the build when the docs and the running code disagree, which is a real improvement over remembering to update things. It would not have caught the 22. Nothing in that suite, or in my head on 2026-09-04, checks whether the process answering me is the process I think I'm talking to.

Pranab Sarkar, Independent Researcher

Twelve Green CI Legs, One Dead SSE Server

Pranab Sarkar — Thu, 03 Sep 2026 15:05:38 +0000

The official mcp Python SDK went to 2.0.0 and deleted mcp.server.fastmcp outright. No shim, no deprecation window that downstream packages got to see. yantrikdb-mcp is a thin MCP server over YantrikDB, my persistent cognitive memory substrate for AI agents, and at 04:08 on 2026-08-04 I did the defensive thing: v0.11.0 (d823b82) pinned mcp[cli] to <2.0.0.

A ceiling like that doesn't stop anyone from installing the package. pip resolves mcp 1.x and moves on. It bites later, in an environment where something else wants mcp>=2.0.0, because then the resolver has to pick a loser and one of the two packages isn't getting installed. That's an acceptable trade for a few hours. It's a bad thing to leave sitting in a published pyproject.toml, so I spent the morning taking it back out.

Scale matters here, because it changes how much a five-hour window costs. yantrikdb-mcp is the fastest-moving package in my download numbers at the moment: 1,688 a month when I logged it on 2026-08-24, 2,137 on 2026-08-31. Up 26.6% in a week, mostly a cluster of registry listings landing close together rather than any single event.

Probing instead of parsing

v0.12.0 (0ca6092, PR #19) shipped at 10:39, six and a half hours after the pin. One file, src/yantrikdb_mcp/_compat.py, became the single import site for every MCP SDK symbol the rest of the package touches, and it resolved them by probing rather than by reading a version string and branching on it:

# _compat.py, trimmed to the shape of the probe
try:
    from mcp.server.mcpserver import Context, MCPServer as Server
    from mcp.server.mcpserver.exceptions import ToolError
    MCP_MAJOR = 2
except ImportError:
    from mcp.server.fastmcp import Context, FastMCP as Server
    ...
    MCP_MAJOR = 1

What actually moved, found by running the suite against 2.0.0 rather than by reading a changelog: FastMCP became MCPServer, Context moved under mcp.server.mcpserver, and ToolError went one level deeper than that, to mcp.server.mcpserver.exceptions. mcp.types.ToolAnnotations stayed exactly where it was, which I would not have guessed given everything around it had shifted. The lifespan dict, request_context.lifespan_context, annotations passthrough, .run(transport=...): all identical across the major bump. Most of a breaking release wasn't breaking for this codebase, and the pin had been treating the entire API surface as suspect when only a slice of it had moved.

One divergence surfaced only by running things. mcp 2.x refuses to register a static resource whose handler declares a Context parameter, and it refuses at import time, which takes the server down before it answers a single request. yantrikdb-mcp had two of those, yantrikdb://stats and yantrikdb://health. Both now reach the engine through a process-singleton and don't ask for a Context at all.

What twelve legs bought

CI got a new axis, mcp-line, with values mcp1 and mcp2, applied across the unit and e2e suites. Twelve legs. Each leg installs its SDK pin after the package installs and then asserts the resolved major, specifically so a compat layer that quietly resolved the wrong way couldn't pass by accident and turn one leg into a duplicate of the other. 214 tests passed on mcp 1.x. 214 on mcp 2.x. The pyproject.toml ceiling went from <2.0.0 to <3.0.0, and --version started reporting the active line: yantrikdb-mcp 0.12.0 (mcp 2.x). I tagged it.

15:42

v0.12.1 went out five hours later: "fix SSE / streamable-http startup on mcp 2.x (v0.12.0 regression)."

The e2e cases, on both legs, all drove stdio. Most of the 214 are unit tests that don't exercise a transport at all. So nothing in the suite touched SSE or streamable-http, which are the two transports yantrikdb-mcp uses for shared network deployments, and v0.12.0 had broken both of them on mcp 2.x.

mcp 1.x configures a network server by mutating shared state (mcp.settings.host, mcp.settings.transport_security.enable_dns_rebinding_protection) and then reading those values back inside server.sse_app(). mcp 2.x's Settings object has no such fields. The old code kept mutating, and on 2.x it raised:

ValueError: "Settings" object has no field "host"

On 2.x those values are arguments to the app factory instead. _compat.build_network_app(server, transport, host, port) is now the only place in the package that knows the difference, and _run_network() delegates to it rather than poking settings.host itself:

# build_network_app(), condensed to the branch that matters
if MCP_MAJOR == 1:
    # 1.x reads its configuration back off the server object
    server.settings.host = host
    server.settings.transport_security.enable_dns_rebinding_protection = False
    return server.sse_app()

# 2.x: the fields don't exist, the factory takes them
return server.sse_app(host=host, transport_security=security)

The streamable-http factory goes through the same branch with a different call. Worth being precise about the failure mode: the server didn't come up misconfigured, it didn't come up. The process died before uvicorn bound a port. A stdio suite is structurally incapable of noticing, because stdio never reaches sse_app().

I found it because I went to upgrade the live SSE box I run, which sits behind bearer-token auth and depends entirely on that path, and I checked it before rolling it forward. Twelve green legs did not catch this bug. A pre-deploy check did, which is the least impressive way there is to find one.

Past the unit tests, I started a real SSE server on mcp 2.x with YANTRIKDB_API_KEY set: uvicorn bound, GET /sse returned 401 with no token and 200 with one. A new file, tests/test_network_transport_compat.py, builds the actual ASGI app for both sse and streamable-http against whichever SDK line is installed, so both legs finally walk the network path. It also carries a source-level guard against _run_network ever reverting to direct settings.host mutation, plus a tripwire assertion that the host field really is absent from Settings on 2.x, so a future 2.x release that quietly restores it fails the suite instead of letting the shim do the wrong thing on both majors at once. Counts after the fix: 218 on mcp 1.x, 219 on mcp 2.x. The asymmetric one is that tripwire, which has nothing to assert on the 1.x leg.

The part I'd argue about

Twelve felt like coverage because twelve is a bigger number than three. What I had was two dependency pins multiplied against one transport. Multiplying an axis against the same assertions doesn't buy a code path, it buys a longer CI run and a wider grid of checkmarks, and I think a great many matrices in a great many repos are built exactly that way: wide where widening is cheap, thin where the interesting failures live. Mine was, until August. Now, before I add an axis, I want to be able to name the line of code it forces the suite through. If I can't name one, the axis is decoration.

The same shape, one size down

A different gate on this repo caps how large the tools/list JSON schema is allowed to get, kept deliberately tight so it doesn't eat into a model's context budget. PR #37 merged with four red CI checks. The gate had passed locally on Python 3.13 and failed in CI on 3.10 and 3.12, because 3.10 renders a hint like str | None into a noticeably fatter anyOf block than 3.13 or 3.14 do: roughly 1,950 extra characters from identical source, against a budget with 197 characters of headroom. PR #38 clawed back 204 characters by trimming a docstring, raised the ceiling from 48,600 to 48,800, and wrote the reasoning into the test file instead of bumping the number silently. There was already a comment in that file warning about this exact interpreter quirk, left there the first time it happened.

Same shape as the SSE regression, one size down: green in the configuration I looked at, red in the one I didn't.

Three weeks later, the probe needed patching too

On 2026-08-25 I had to fix the probe itself (0e170a9, PR #35). mcp 2.1.1 reintroduced mcp.server.fastmcp alongside the canonical mcp.server.mcpserver tree. Read the code block above again: its logic is "if fastmcp imports, we're on 1.x," and on 2.1.x both trees import cleanly, so it confidently answered 1. The fix reads importlib.metadata.version('mcp') directly instead of inferring the line from which modules happen to resolve, adds a second check tying the canonical 2.x tree to MCP_MAJOR, and pins the both-trees-importable shape to 2.x in a regression test. Validated against mcp 1.29.1, 2.0.0 and 2.1.1.

So probing beat parsing right up to the point where upstream did something stranger than I'd allowed for, and the version string I'd deliberately avoided ended up being part of the answer after all.

I Made an MCP Server Stop Calling Any AI API, and It Got More Useful

Pranab Sarkar — Thu, 27 Aug 2026 14:58:41 +0000

v1.0 of brainstorm-mcp shipped with two providers wired up: OpenAI and DeepSeek. Gemini arrived later in v1.2.0 (3690f24, 2026-02-26), and groq, mistral and together are in the list too. You never needed all of them. The provider loader walks the list and skips anything whose env var is missing, so one working key is enough to run a debate.

The catch is which key. Every provider in that list belongs to somebody other than Anthropic. There is no Claude provider in the server and there never was; in API mode Claude's role is to read what the other models said and add its own take, which happens through the host rather than through a key the server holds. So if you're running Claude Code and you install brainstorm-mcp to see what a multi-model debate looks like, the number of usable keys you have is quite possibly zero. The friction was never "go collect N keys." It was "go sign up with a vendor you weren't otherwise using, before you can find out whether this tool is any good."

The inversion

v1.4.0, commit 7906fbf, 2026-03-24: "Add hosted mode for API-key-free multi-model brainstorming" (PR #1, co-authored with Claude Opus 4.6 per the commit trailer; Opus and I worked out the orchestration model together).

Hosted mode isn't a seventh provider or a free-tier proxy. In API mode the server is a caller. It holds keys, hits api.openai.com or api.deepseek.com, returns results. In hosted mode it never calls a model API. It builds the debate prompt for a given round and a given voice, then hands that prompt back to the host as tool output. Claude Code spawns sub-agents on opus, sonnet and haiku to run those prompts, using model access the host already has. Responses come back in through brainstorm_collect, which appends them to the debate and decides what round comes next.

Worth being precise about the mechanism, because it's easy to overstate. The server cannot make the host do any of that. What it returns is a prompt plus instructions, and Claude Code acts on them because acting on tool guidance is what a host does. There's no protocol-level guarantee anywhere in this. A host that ignored the instructions and dumped the prompt text at the user would leave the server sitting on a half-finished session until it timed out. The whole arrangement is cooperative, and I'd rather say so than let it sound like the server is driving.

Mode selection is automatic. If the model names you pass don't carry a provider: prefix (no openai:gpt-5.5, no deepseek:deepseek-chat), the server reads that as hosted mode and assumes you mean the host's own models. No flag, no config file, just the shape of the string.

The same commit brought context injection, so a debate can be grounded in a real diff or file instead of a topic sentence, plus the debate styles (freeform, redteam, socratic) and a synthesis format that closes every debate with Recommendation, Key Tradeoffs, Strongest Disagreement in both modes. brainstorm_respond was already there from v1.1.0 (75c8949, "Add interactive mode — Claude participates as active debater"); 7906fbf touched it by exactly one line, passing session.style through.

The design consequence I care about is what happens once the server stops calling models. It has to hold state: which round the debate is on, which voices have spoken, what's outstanding. That lives in memory with a 10-minute TTL, and calling brainstorm_collect against an expired session returns an error telling you to start a new one.

Two ways it broke, same afternoon

Both of these live in the API-mode calling path, which hosted mode's design doesn't touch. They broke a debate I was running to test hosted mode, so they're part of the same afternoon.

v1.5.6, c9e3d86, 2026-04-27, "drop temperature for gpt-5.x reasoning models." Three-round brainstorm, openai:gpt-5.5 and deepseek:deepseek-chat as the two voices. Every round-1 turn from gpt-5.5 came back as an HTTP 400:

Unsupported value: 'temperature' does not support 0.7 with this model. Only the default (1) value is supported.

The gpt-5.x family and the o-series reject any non-default temperature. deepseek-chat doesn't care what you send it, so the loop ran fine right up to the OpenAI voice, which is why testing hadn't caught it. The code already branched on model family for max_tokens vs max_completion_tokens, tracked by a useNewTokenParam flag, so the fix reused that branch and stopped sending temperature: 0.7 down it. Older gpt-4.x models still get it, since they still accept it. Rechecked against gpt-5.5-2026-04-23: 200 OK, no temperature field in the request body.

v1.5.7, 9af668b, same day, "bump per-call timeout 2m -> 5m." I shipped the temperature fix, reran the same debate, and it stalled at 120 seconds. DEFAULT_TIMEOUT_MS in src/debate.ts was hardcoded to 120_000. gpt-5.5 doing reasoning on a real brainstorm prompt (multi-thousand-word topic, six-option intervention list, redteam framing instructions on top) goes past two minutes routinely. Session 01751c60-256a-489b-88d3-9b954a3edd79, round 1, same wall on retry. One constant, 300_000, done. deepseek-chat and gpt-4.x were finishing well under two minutes and saw no change at all.

Under an hour between the two commits, which is about how long I spent believing the first one had unblocked the debate.

One thing I'm watching now: SESSION_TTL_MS is 600_000 while DEFAULT_TIMEOUT_MS is 300_000 post-fix. Two slow reasoning calls back to back inside a single round could in principle burn most of a session's life before the round finishes. I haven't hit it and I'm not certain the arithmetic works out that way in practice, but it's the next thing I'd expect to go wrong.

What the numbers say

From state/metrics-history.jsonl, npm downloads per month and GitHub stars as recorded:

Date	npm downloads/month	GitHub stars
2026-08-09	286	67
2026-08-18	345	67
2026-08-21	413	67
2026-08-24	427	67

Downloads up about 49% across those 15 days. Stars sat at 67 on every check.

I read that as a property of how this kind of tool gets installed rather than as a problem. You add brainstorm-mcp to an MCP client config and start calling brainstorm_quick. Nothing in that path requires opening the repo. Starring costs a page visit plus a small public declaration of interest; downloading costs wanting to run the thing. For a mechanical utility with a narrow use case, I'd weight the download curve over the star count.

Plenty of people will call that motivated reasoning from someone whose star count isn't moving, and four data points over two weeks isn't evidence of anything. It's four numbers. What it did change is what I bother logging.

Pranab Sarkar, Independent Researcher

The Model Reading My Benchmark Mattered More Than the Memory System Did

Pranab Sarkar — Tue, 25 Aug 2026 20:40:17 +0000

On 2026-08-11 I reran a benchmark I'd already published and changed exactly one thing: the model that reads the retrieved memory and writes the answer. Same memory system, same retrieved context, same judge, same rubric. YantrikDB's own score moved about 9 points on that swap.

Grounding, if you haven't heard of the thing being measured: YantrikDB is a persistent memory system for AI agents — it stores what happened in earlier sessions and hands the relevant parts back on demand. It makes no LLM call at ingest, which is where the 241-second ingest and 80ms retrieval numbers further down come from.

Two weeks before that rerun, Hindsight — a competing agent-memory system — had published a score on the same benchmark 25 points above mine. Nine of those 25 came from a model swap that has nothing to do with either memory architecture. More than a third of a published architectural gap, produced by changing the plumbing.

The comparison that got thrown out

The first version was the lazy one. BEAM-100K, an agent-memory benchmark, rubric-scored: YantrikDB at 0.611, Hindsight's published number at 0.862. My answerer was deepseek-v4-flash, theirs was gemini-3.1-pro-preview, and I filed that as a footnote.

Two adversarial reviews came back on it on 2026-08-11, one from a Codex-family model (gpt-5.6-sol) and one from Qwen (qwen3.8-max), both rejecting it for the same reason. An end-to-end agent-memory score has at least three things stacked inside it: how good retrieval is, whatever an ingest-time LLM does to the data on the way in, and how well the reading model uses what came back. YantrikDB and Hindsight differ in architecture. Hindsight runs an LLM fact-extraction pass at ingest and YantrikDB doesn't. The answerer models were different. Three variables moved together and I'd assigned all 25 points to the one I happen to build.

My first reaction was that this was reviewer pedantry — the reader model is plumbing, the memory system is the interesting part. Then I ran the swap to prove it, got the 9 points, and spent the next two days rewriting the paper instead.

Replaying their own context strings

Hindsight publishes, per query, the literal context string it injects into its answerer — one for a RAG configuration, one for a single-query configuration. Not a description of what its retrieval does; the string itself. So I took those strings unmodified and ran them through YantrikDB's own fixed answerer and judge: deepseek-v4-flash:0731 at temperature 0, the identical pair already scoring YantrikDB's own retrieved contexts. Nothing here calls Hindsight's live system; it's their published artifacts replayed through my scoring pipeline, so the only thing varying between rows is which memory system wrote the context.

Worth being blunt about one detail: the answerer and the judge here are the same model. deepseek-v4-flash:0731 writes the answer and then grades it, and self-grading has an obvious bias risk that I'm not going to dress up. What makes it usable is the frozen-context design — the same reader and the same judge process both systems' contexts under the same rubric, so whatever that model is inclined to reward, it rewards equally in both columns. The residual worry attaches to the absolute score level; the gap between the columns is what gets reported.

400 queries nested inside 20 conversations, all from BEAM-100K. All 400 query_ids matched across systems, so there's no partial-overlap story to explain this away.

System	Mode	Binary accuracy	Rubric score	Context tokens
YantrikDB	RAG	72.2%	0.607	13,673
Hindsight	RAG	71.5%	0.592	23,689
Hindsight	single-query	65.0%	0.563	17,655

The significance test needs a note, because the obvious test is the wrong one. Those 400 queries aren't 400 independent draws — they sit inside 20 conversations, and queries from the same conversation tend to succeed and fail together, so a per-query t-test would count 400 samples where there are really 20. The test therefore works at conversation level: flip the sign of each conversation's mean difference, enumerate every possible assignment, which with 20 conversations is 2^20 of them, a bit over a million, and p comes out at 0.438. The interval is a separate procedure — 4,000 conversation-clustered bootstrap resamples, giving [-0.021, +0.052]. A +0.015 rubric difference with an interval that comfortably straddles zero is a tie, and the paper's own word for it is "equivalent". Against Hindsight's single-query configuration the difference is +0.044, p=0.025, CI [+0.009, +0.077] — real, but single-query is the weaker of their two published configurations, so leading with it would be picking the easy target.

What did survive is cheaper than a win. YantrikDB reached that equivalent rubric score on 13,673 tokens of context against Hindsight's 23,689 — 42% fewer. The paper is careful here and I want to stay careful: part of that 42% is the cost of not carrying event time. Hindsight's contexts carry a median of 117 dates each. YantrikDB's carry a median of 5. "Not a free efficiency" is the paper's phrase, and it's the right call: that's a difference in what the two memory layers choose to emit. YantrikDB's two weakest categories in this eval are event ordering at 0.298 and temporal reasoning at 0.425. Those numbers and the token saving are one fact seen from two sides: a context with fewer dates in it is cheaper to read and worse at time.

Ingest and retrieval move the same direction, for a design reason and not a tuning one:

System	Ingest time	Retrieval (mean)	LLM call at ingest
YantrikDB	241s	80ms	none
Hindsight (RAG)	404s	2,565ms	fact extraction
Hindsight (single-query)	404s	6,379ms	fact extraction

No LLM call at ingest is the choice; 80ms against 2,565ms is what the choice buys.

The part worth stealing

Back to the 9 points, the finding I'd defend hardest. Holding retrieval completely fixed and changing only the answerer moved YantrikDB's own score by more than a third of the entire published gap between two different memory systems. The paper puts it flatly: "The published gap is therefore overwhelmingly a property of the reading model, not of the memory systems." Any end-to-end "our agent memory beats X" number that doesn't name its answerer model and its judge model isn't a comparable number, and may be describing nothing more interesting than a stronger LLM reading the same context better. That's a complaint about how the category reports results, not about Hindsight, whose habit of publishing raw context strings is the only reason this experiment was possible.

A different reader, a different answer

There's a later experiment in the same paper, and leaving it out here would be editing rather than summarising. On 2026-08-15 I ran the rag-mode 2×2 again under an equalized frontier-class reader: moonshotai/kimi-k2.6 answering, meta-llama/llama-4-maverick judging — a different reader/judge pair from the deepseek one above. On 393 paired queries, YantrikDB scored 0.6331 rubric against Hindsight RAG's 0.5982: +3.5 percentage points, bootstrap 95% CI [+0.7, +6.2]pp, excluding zero.

That doesn't overturn the tie, and I'd rather be tedious about it than let anyone read it that way. A different reader model is a different question rather than a rerun of the same one, and the RAG-vs-RAG comparison under the shared deepseek reader stays the honest headline: equivalent. What the frontier run supports is narrower — under one stronger reader, on a slightly smaller paired set, a small edge that clears its own confidence interval. It is not the sentence "YantrikDB beats Hindsight," and writing that sentence would be doing the exact thing the previous section complains about.

Wrong twice, and what's still open

The reader-model confound was the big retraction. There's a second one, smaller, the same shape. I'd had a hypothesis that Hindsight's ingest-time extraction step was quietly discarding evidence later questions needed — an information-bottleneck story, and the one result that would have made YantrikDB structurally better instead of just cheaper. Category by category against their single-query configuration, it looked real. Against their RAG configuration it mostly evaporated. The paper's line: "We are withdrawing the information-bottleneck claim as unsupported by this experiment." That paragraph took longer to write than the whole results section.

Smaller things, in no order. The results page briefly said engine version 0.14.0; the version actually installed in the benchmark's virtualenv, per dist-info at 21:05 on 2026-08-11, was 0.13.4. That number turned out to matter slightly — a 2026-08-16 rerun of the same comparison on engine 0.15.0 scored 72.5% / 0.6375 where 0.13.4 scored 71.5% / 0.6107, a +0.027 rubric delta, bootstrap CI [+0.007, +0.045], small and clear of zero. The deepseek 2×2 is incomplete: YantrikDB's contexts were never run through Hindsight's answerer, so three of the four cells exist. Context length was never controlled either, so the token-efficiency and accuracy-equivalence findings stay two claims sitting next to each other rather than one. The local harness is a fork of vectorize-io/agent-memory-benchmark, which carries no license and can't be redistributed, so the paper's "Reproduce" link points at the upstream repo.

The paper went up 2026-08-12 at yantrikdb.com/papers/beam-frozen-context/ and until this post it hadn't been anywhere but its own domain. Take the boring thing from it: when you publish agent-memory numbers, name the model that read the context and name the model that graded the answer. Without those two names the number doesn't mean much, including when the person publishing it is me.

Pranab Sarkar, Independent Researcher

DEV Community: Pranab Sarkar

49 Minutes Chasing a Silent SSE Hang in mcpier, and the CRLF Regex Behind It

What mcpier is

The night before

The afternoon feature

The hunt

Whose name is on which commit

Still on 0.1.7

A contributor found the live twin of a namespace bug I'd filed as low priority

The check

Issue #242, which I wrote

Late on the 27th

Review and merge

Still open

The seed is just the oldest record, and other things I got wrong about a YantrikDB merge bug

Two things I had wrong

The embedder

The question I owed wolf-crazy

I wrote down the cause of this leak two months before anyone reported it

PR #128

My reply

The first version was already safe

The review

The second commit

Where the 18 hours went

A failed SQLite integrity check on Windows that reported itself as a POSIX lock conflict

The message described something that can't happen on Windows

Where the refusal came from

Read-only, with no way out

Commit 33d0be9

The lock nobody could explain

Is one retry enough?

My harness logged "duplicates not canonicalized." It was counting page size.

95 passing tests and an "Unknown tool"

What DeepSeek did with why_retrieved

Rereading the scale probe

Why exactly 256

The embedder I attached got 0 encode() calls during writes

83, the reporter's other issue that day (an always-empty fleet view), had a similar shortcut in its tests: they mocked list_records, the very method that swapped a missing namespace for the base one, so the swap never ran.

Counting encode() calls

The reverse case

I Rebuilt Real-Time Push Six Times in One Evening, Then Quietly Added a Cron

The evening

Except that isn't where it stopped

On MCP's task primitives

The rename, and a name one hyphen away

The bug, thirty-five hours in

The name that won't die

My README Was Mostly Right. The Number I "Verified" Wasn't.

What was actually running that day

The fix that did land

Two days later

The download number I don't trust

Twelve Green CI Legs, One Dead SSE Server

Probing instead of parsing

What twelve legs bought

15:42

The part I'd argue about

The same shape, one size down

Three weeks later, the probe needed patching too

I Made an MCP Server Stop Calling Any AI API, and It Got More Useful

The inversion

Two ways it broke, same afternoon

What the numbers say

The Model Reading My Benchmark Mattered More Than the Memory System Did

The comparison that got thrown out

Replaying their own context strings

The part worth stealing

A different reader, a different answer

Wrong twice, and what's still open

What DeepSeek did with `why_retrieved`

83, the reporter's other issue that day (an always-empty fleet view), had a similar shortcut in its tests: they mocked `list_records`, the very method that swapped a missing namespace for the base one, so the swap never ran.