Burton Lancaster PRO

Thank you. The MCP server and the VS Code extension are the same system.

Black Window indexes a local folder once. It splits the files into passages, embeds them with the 33M-parameter model on your CPU, and stores the vectors next to the source. Later questions, whether typed in the extension or sent through an MCP client, retrieve the nearest passages and return the file path, the line range, and the text itself.

The VS Code extension is the interface for that index. Qwen-coder (or any other model you load) can ask the weave for context the same way Claude Code or Cursor can. The command in the post is the one that registers it:

claude mcp add weave -- npx -y blackwindow-weave-mcp --folder /path/to/repo

The same npx line works in the VS Code MCP configuration.

Example run on my own Sunstone repository (57 files, 1,367 passages) took 20.2 seconds. All subsequent searches on the same index returned in 6 ms. After the model is cached, no further network requests are made.

The source, the model card, and the npm package are linked in the post. If a particular step is unclear (how the index is built, how a query is turned into passages, or how the extension surfaces the result), say which one and I will walk through it. Thank you for early adoption, please leave a review in marketplace if you find it useful!

Every figure you give reproduces from those files. On the 411: 207 against 158 at 8234be7 (69 and 20), 221 against 194 at a3738ff (59 and 32, sign p 0.0061), and 230 against 192 on the published path. Taking the bonus out returns 55 bge-small instances to rank 1 and costs 19, with 17 of the 55 coming back from rank 2; for Motherlode it is 28 and 14, and 11 of the returns are shared. The median raw spread of the top 10 hits at 8234be7 is 0.072 against 0.13. So 22 of the post's 49 was the bonus.

The post went up at 01:36 UTC on the 29th, while the page and Sunstone 0.1.5 still ran 8234be7's tool path. a3738ff, committed at 02:32, took the bonus out; Sunstone 0.1.6 went live with it at 02:46 and the page moved the same night. So "as it ships" held for about an hour. The card gives 221 against 194 as the shipped row, and the post now does too.

Both halves of your question, run on the 411 before writing this:

• After centring. The decomposition already holds it: without the raw rerank, the bonus goes on the centred dot the published path sorts on. It costs more there, not less: Motherlode 227 to 207 (12 better, 32 worse, sign p 0.0037) and bge-small 191 to 153 (17 and 55, sign p 0.00001).
• Scaled by spread. Registered before the run, with the rule that it comes back only if it helps both readers at sign p below 0.05: each query's bonus multiplied by that query's gap between its 1st and 10th raw cosines, over 0.14, so the full bonus lifts a passage at most from 10th to 1st for either reader. Motherlode goes 221 to 215 (5 better, 11 worse, sign p 0.21) and bge-small 194 to 190 (6 and 10, sign p 0.45). Motherlode leads 215 to 190.

So your mechanism holds: in each query's own units the bonus costs the two readers about the same, 6 and 4 files, where the fixed bonus cost them 14 and 36. Scaled or centred, it helps neither reader, so it stays off. On the weave's own questions it moved none of 54 in or out of the top 8.

Files: evidence/engine_bonus_scale_2026-09-29 in the evidence dataset, repair.json for your figures and summary.json for the scaled run, written by gates/engine_bonus_scale.py, whose docstring carries the rule.

The Weave never evicts. Only the window does, and it is rebuilt from scratch every turn rather than trimmed. Every turn is embedded as it ends, so it stays retrievable as a memory:turn <n>#<i> passage for the life of the session. What changes is whether a turn sits in front of the model verbatim or comes back as a retrieved passage.

Sizing happens per turn, in pickWindow. The cap is min(HISTORY_BUDGET, promptBudget() - NOTES_RESERVE() - (this message + 700) - attached file lengths), where promptBudget() is (CTX - REPLY_TOKENS - 48) * 3.8 on desktop and * 3.3 on mobile, and NOTES_RESERVE() is 2800 desktop, 1400 mobile, which is what six notes take on a desktop and four on a phone. The last turn is always kept, because a follow-up points at it, and then it walks backwards adding older turns while they fit under the cap.

The eviction order that matters is in fitPrompt, and it is not recency. Files that fit whole go first, since they are the question's material. Then the retrieved notes. Then a long file's opening last, with whatever is left. The opening sits below the notes because of a failure we measured: asked for a code word on line 20000, the model answered from line 0, because the opening had crowded out the passage that actually contained it. An opening is context, not the answer.

Two details that were not obvious until they bit. Room left over after the notes goes back to the transcript, most recent first, and any recalled memory:turn note whose turn has just returned to the window is dropped from the note set, because otherwise the same turn is in the prompt twice and the retrieved copy is the stale one. And turns stay in RAM for three budgets' worth after they leave the window (trimHistory, while size > HISTORY_BUDGET * 3), so a later turn with few notes can take them back cheaply; past that they live on as memory only.

On mobile Safari we landed where you did. WebGPU decode runs in llm_worker.js for exactly the reason you hit: a long token loop on the main thread trips the iOS watchdog that surfaces as "a problem repeatedly occurred". Media decode is a second worker, and it loads a plain build under WebKit.

The check grows. All three of your points were the same failure the check was
written to catch, one level up, and it is rewritten rather than patched.

Coverage is now the default. It walks to any object holding a numeric oracle
at any depth instead of matching d["arms"], and takes the bounded set as every
numeric sibling not exempt for a stated reason instead of an allowlist. Your
count was 266 of 1,373. It now judges 2,501 cells across 23 files.

Per file, old against new on the shapes you listed:

verifier/exec_guided.json 0 -> 148
verifier/results.json 0 -> 666
hivemind_census.json 0 -> 60
he_k32_k_scaling.json 0 -> 72

exec_guided is the one that makes your second point concrete. It was on the
allowlist as a file name, its columns are exec and exec_verifier, and
neither was on the list, so the file printed a line and judged nothing. All
five dead names are gone; there is no list of judged columns any more, only a
list of exempt ones, and each carries its reason: subset rate, count, model
size, difference between two columns, ranking score, or outside [0, 1].

The closing line now names its own scope:

scanned 746, carried an oracle 22, judged 2501 cells, skipped 930
no column scored over all problems exceeds its oracle in any file scanned above

--verbose prints the 930 by reason. Largest are 936 floor, which is now
judged rather than skipped and is bounded by construction, 188
consensus_on_covered, 82 n, 81 gain_over_floor, 78 on_resolved_only, 42
headroom_captured.

Your subset-rate counts reproduce exactly on the current files: verifier
chat_consensus 6, chat_consensus_mbpp 1, consensus 12, consensus_mbpp 1;
verifier_1024 chat_consensus 3, consensus 7, consensus_mbpp 1. Zero violations
on any all-rows column, which is also what you found by hand across all 660
cells the old shape could not reach.

Your third point paid for itself immediately. artifacts/nla/q4/ one_forward_pass_probe.json has been unparseable since 24 August: Python
implicit string concatenation inside a .json file, from a paste. The old
check caught the exception, returned None, printed nothing, and closed with
"no all-rows selector exceeds its oracle in any current file", exit 0. Three
weeks of runs called the repo clean without reading it. It now prints
UNREADABLE and the file is fixed; all 1,035 artifacts under artifacts/ parse.

paper_hivemind 881 said "one pass over every results file" when the pass was
two shapes wide. Rather than narrow the sentence, the paragraph now states what
the first version did, 266 cells and a silent return, and what the current one
does with the scanned/judged/skipped counts above.

Both, and both are in now. Commit 0480553c on space-bacon/SRT, card updated on RiverRider/srt-hivemind.

You were right that 879-880 read as shipped when it was a recommendation. As of d56e1a8f the fix was in consensus_select.py and the check was not anywhere.

Per arm: consensus_select.py and chat_consensus.py now raise on consensus, consensus_strict and chat_consensus above the arm's own oracle, so a bad run cannot write a file. Repo-wide: scripts/check_oracle_bound.py is one pass over every results file under artifacts/nla with per-arm oracle columns. It is column-scoped as you specified: the columns scored over all problems are held to the bound; consensus_on_covered and on_resolved_only are declared subset rates and are reported beside the oracle, not judged. Files with a SUPERSEDED key are printed as such and cannot fail the run.

Its output on today's files is your table:

ok   verifier/consensus.json            72 bounded cells   12 subset-rate cells above oracle
ok   verifier_1024/consensus.json       72 bounded cells    7 subset-rate cells above oracle
ok   verifier_1024/consensus_mbpp.json  20 bounded cells    1 subset-rate cell above oracle
ok   verifier_1024/chat_consensus.json  36 bounded cells    3 subset-rate cells above oracle
no all-rows selector exceeds its oracle in any current file

The 12, 7, 1 and 3 are the counts you found, on the columns you named. Zero violations on any all-rows column, which is what the corrected files should show and what the unguarded invariant would have muted.

The README mismatch is fixed in the card and in the paper: 12 of 36 is the 192-token file, 7 of 36 the 1024-token file, 1 of 10 MBPP. The 192-token pools stay in the repo as superseded evidence; nothing in the paper reads from them any more, and the check treats them accordingly.

Your inverse-Simpson result stands as the cleanest statement in this thread of what the template is not doing, and the corrected selector numbers point the same way. Thank you for pulling the commit and grepping rather than taking the sentence at its word.

It falls back to a pick. srt_select.select() returns replies[0] when nothing runs, so the deployable number is the fallback bound. I now report the strict bound beside it.

You are right, and it reproduces to the digit. consensus_select.py averaged the covered picks and subtracted an all-rows floor from them. 12 of 36 arms beat their own oracle, coverage rank-correlates +0.91 with floor (Pearson +0.79), and your two bounds on the 192-token pools come back 0.3760 and 0.3902. Everything else in the repo (exec_guided_select, verifier_select, chat_consensus, pooled_select, the demo bank) was already scoring every problem. This was one read.

Corrected, every problem scored, unresolved pools falling back to reply 0 as the shipped selector does:

The 1024-token pools are the ones Section 5.4 now carries. The 192-token matrix you read was regenerated the day before your comment after a truncation problem surfaced (43% to 80% of instruct-arm candidates were cut off mid-function), which is why your numbers and the current table differ before this correction. On the 1024 pools the bias is smaller because coverage is higher, mean 148.5 of 164 against 133.6, and no arm exceeds its oracle after the fix.

Agreement stays third of five reads on both benchmarks, behind example-filtering by 6 points on HumanEval and 4 on MBPP. Your formatted-versus-unformatted point holds: on the 1024 pools the captured split goes from 0.887 / 0.613 to 0.489 / 0.405. The verifier's deficit to agreement shrinks from 0.1199 to 0.0752, and the agreement decay slope on MBPP moves from -0.0815 to -0.0830 per decade.

Paper 5.4, the dataset card, srt_select, fig 3 and the census are corrected and pushed to RiverRider/srt-hivemind. The old files are kept as *_covered_only_superseded.json with a SUPERSEDED key, same convention as union_ceiling.json. You are credited by name in the limitations, where this is now the fourth accident that flattered us, and in the acknowledgments. The check that would have caught it costs one line, no arm may exceed its own oracle, and it is in the script now. The article body is being replaced with the corrected paper.

Your inverse-Simpson result is the cleanest statement in this thread of what the template is not doing. 7.9 of 8 effective distinct candidates in both families and zero byte-identical pools means the chat format is not deduplicating anything. It is making the model right more often, which is where the corrected numbers point as well.

You read the files correctly, and I reproduced all of it before answering. Every share value matches to four decimals, the mean is +0.2635, the tuning step is +0.0244, the ratio comes out 10.81. The consensus.json figures check out and so does your retraction: the 30-arm and 36-arm sets are used consistently and nothing is quoted across them.

The word "same" is a real error and is now corrected. Chasing your count also explained the 30 versus 31: code_select.py globbed every json in the generation directory, so task_ids.json was read as an arm. It has one entry per problem, so it passed the length check, and slicing its task-id strings produced 11 single-character "candidates", which is the k = 11 and the all-zero row. The glob now requires an arm tag. The published artifact is left alone and Section 12 documents the entry, because silently rewriting a result file mid-thread is worse than labelling it.

On the substance, your objection to raw headroom is right and your normalization is where I part company.

share = floor / oracle is very close to a function of competence alone. Regressed on floor_pass1 across the 30 arms it gives r = 0.9840. Holding competence fixed, the format-specific residual is +0.0223 against your headline +0.2635, so competence accounts for 92% of the movement. Per rung, chat minus raw: 0.5B +0.0968, 1.5B +0.0434, 3B +0.0085, 7B −0.0118, 14B −0.0254. Monotone decreasing, sign change at 7B, largest where floor_pass1 is 0.026 and the ratio is least stable.

You suggested matched-competence arms, so I ran it rather than leaving it as a suggestion. Pairs differing in framing with |Δfloor| < 0.03: 42 pairs, mean share difference for the more-formatted arm +0.0010, median +0.0018, 23 of 42 positive. At |Δfloor| < 0.02 it is −0.0003 over 30 pairs, at 0.05 it is +0.0102 over 64.

One caveat against that null. The framings barely overlap in competence, weak framings spanning floor 0.021 to 0.109 and strong ones 0.156 to 0.540, so most matched pairs are cross-rung. Same-rung pairs number 9 to 20 depending on threshold and give +0.0085 to +0.0151. Thin, and not zero.

So the honest range for a format-specific effect on share is 0.00 to 0.02, against your +0.2635. Within-pool convergence is a different claim from 5.4 and this evidence does not establish it. 5.4 says text similarity across models does not imply agreement on correctness, and nothing here touches that. What these numbers show is that the chat template makes the model better, and competence mechanically raises the fraction of pool coverage a single sample captures.

The mechanism underneath your reading is real. The selector eats residual disagreement, so anything that raises competence shrinks the room. We measured that on a separate banked set this week, on a different axis to your ladder. The selector's edge over a pool's own pass rate is +0.44 when two candidates agree and +0.04 when eight do. The format closes the room the same way scale does, by making the model right more often rather than by making it agree with itself.

The mechanisms you name do not fit the measurement. Transport is measured on base checkpoints: Qwen2.5-0.5B and 7B, Qwen3-0.6B-Base, gemma-2-2b, Llama-3.2-1B and 3B, OLMo-2-1B, SmolLM2-360M, pythia-410m. Nine of the eleven models are base, and no chat template is applied anywhere in that experiment. RLHF and DPO never touched those weights, pythia-410m was trained on the Pile and released before the endpoints you name existed, and serving-backend geometry does not reach into pretraining. None of that produces a 0.999 linear map from Qwen2.5-0.5B to OLMo-2-1B.

Your general point is a different matter and it lands. Our lineage control separates same-company from different-company, and a cause operating across the whole industry predicts exactly the small premium we measured, so that number does not argue against you. Shared web-scale pretraining distribution is a live explanation for the transport result and our design does not separate it from a general property of language modelling. That has been inserted into our limitations.

The two results the paper rests on run against the mystical reading rather than for it. Base models do not reach the reported level. Instruction tuning alone adds 0.0786, taking the matched pairs from 0.3649 to 0.4435. Prompting those same tuned weights through their own chat template reaches 0.7272, which is 0.3623 above base, or 0.2837 taken as the marginal step over the untemplated instruct arm. On either contrast the format term is several times the weight term. Our conclusion is that most of the reported hivemind is a prompt convention.

Thank you, I will run a sweep on the repo against your papers soon @AbstractPhil … Any specific recommendations?