A 929M-edge PubMed graph built with zero LLM calls; also: agent harnesses, Stanford's Next-Concept Modeling, MegaRAG and Google's OKF

Lead stories

Structuring 40 million documents into an "agentic" knowledge graph

2 sources, 4 min read

What happened. A Level Up Coding post by Fareed Khan, "Structuring 40 Million Documents into an Agentic Knowledge Graph", has run in eight Medium digests between mid-September and today. Its teaser promises "929 million edges in 10.8 minutes, and 83.2% on 600" questions medium. Medium returned HTTP 403 to every fetch, so this account rests on the companion repository, FareedKhan-dev/agentic-knowledge-graph. Search snippets describe the article as 46 Python modules with "no graph database and no extraction model". The repository describes itself as "knowledge-graph RAG built from structured metadata instead of LLM extraction. 929M edges, zero LLM calls, 83.2% on held-out PubMedQA" (search summary of the repo and article) medium.

Details. The corpus is the PubMed 2026 baseline: 1,334 gzipped XML files parsed into articles, citations and MeSH headings and qualifiers. The "40 million" in the title is roughly the count of PubMed records. Only 28,336,648 abstracts were embedded, as 384-dimensional fp16 vectors, because many PubMed records have no abstract. The README lists three edge families: CITES, CITED_BY, and article-to-MeSH-descriptor links taken from the human indexers at the National Library of Medicine. Its diagram also shows MeSH tree-parent, qualifier and entry-term relations. The total is 929,824,202 edges. The "10.8 minutes" is the runtime of parse_pubmed.py, the XML-to-Parquet step. The README does not say what hardware it ran on. A full rebuild including embeddings needs one H100 80GB, about 400 GB of disk and about 2.5 hours. Storage is Parquet for the parsed corpus and a compressed sparse row (CSR) adjacency structure held in RAM instead of a graph database. Dense search is exact, with no approximate-nearest-neighbour index. The question-answering pipeline has five steps. A "HybridGrounder" links the question to MeSH descriptors lexically and densely. Dense retrieval returns 16 candidates. A cross-encoder reranks them. Qwen2.5-14B-Instruct answers through constrained decoding over yes, no and maybe. Finally, a calibrated gate either answers, with a source path resolved from the CSR graph, or refuses (repo README) medium.

The evaluation uses PubMedQA's 1,000 expert-labelled questions, split by seed into 400 for development and 600 for testing. On the test split, answering with no evidence scores 37.2% and always picking the majority class scores 53.3%. The author's own earlier best was 68.8%. Cross-encoder top-1 with argmax scores 82.3%, and with calibration 83.2%, with a 95% interval of 80.2 to 86.2. Qwen2.5-32B scored 55.1% with truncated evidence and 82.4% with intact evidence, no better than the 14B model. The truncation bug, which cut evidence at 1,100 characters, explains the earlier 68.8%. The README says notebook sections 20 to 25 still contain the superseded numbers and were not re-run (repo README) medium.

Facts vs. opinions. The counts, the pipeline and the test-split accuracy are documented in the repository by the author, with confidence intervals. That is better practice than most Medium RAG posts. No independent replication was found as of 2026-10-19. The repository has 64 stars and 18 forks. The headline framing is the author's, and it is misleading in two ways. First, "agentic" is hard to find in the pipeline: the README describes no agent that calls the graph as a tool, plans traversals or iterates. It is a fixed retrieve, rerank, answer, gate sequence. Second, the graph does not produce the accuracy. The 83.2% comes from dense retrieval plus cross-encoder reranking plus a 14B reader. The graph supplies grounding and a provenance path. The README's most important line is easy to miss: the "governance thesis failed". Using graph certification to decide when to answer scored an AUROC of 0.500, chance, while the model's own confidence reached 0.810 (repo README) medium.

Other perspectives. A specialist would raise a construct-validity question that the README does not address. PubMedQA questions are derived from PubMed article titles, and each question's gold context is that article's abstract. Retrieving over all of PubMed therefore means the source abstract is in the index. A strong dense retriever often finds the very abstract the question was written from. That makes this an "open-book with the answer key on the shelf" setting, not a test of synthesis across documents. The README itself calls PubMedQA close to exhausted and suggests BioASQ, which requires registration. Other stated limits: the cross-encoder sees only the first 900 characters of each candidate, and the "maybe" class is effectively unreachable under accuracy-maximising decoding, with 0% argmax accuracy. The upside is real. Structured metadata that humans have already curated, here MeSH indexing and citation links, gives a large graph for the cost of an XML parser instead of millions of LLM extraction calls medium.

Why it matters. This project is a useful counterweight to the LLM-extraction style of GraphRAG, in which an LLM is paid to rediscover entities and relations that a domain's curators already encoded. Where such metadata exists (MeSH, legal citators, package dependency graphs, code import graphs), build from it first. The negative result matters more than the headline. On this benchmark, graph structure did not tell the system when to trust an answer, and the model's own calibrated confidence did. Anyone selling "graph-certified" answers for governance should be asked for the equivalent AUROC. Treat "agentic knowledge graph" as a title, not a description. Read the repository's limitations section before the article medium +1.

Agent harnesses: what the "complete guide" framing gets right, and the evidence it needs

3 sources, 3 min read

What happened. S Sankar's "Agent Harness — A complete guide" (Level Up Coding, slug "a no-BS guide") has appeared in six digests since September 22. It opens with "There isn't much more to understanding Agent Harness..." medium. Medium blocked the fetch, so the guide's own content cannot be verified here. What follows reconstructs the concept from the sources the term comes from, and checks it against the clearest public evidence that harnesses matter: Anthropic's April 23 Claude Code postmortem.

Details. The most-cited formulation is LangChain's "Agent = Model + Harness", from Vivek Trivedy's March 2026 post. It says the harness is all the code, configuration and execution logic around the weights: system prompts; tools, skills and MCP servers with their descriptions; bundled infrastructure such as a filesystem, sandbox and browser; orchestration, meaning subagents, handoffs and model routing; and hooks or middleware for deterministic steps like compaction, continuation and lint checks. The post derives primitives from model limitations. Filesystems give durable state and context offloading. Bash and code execution let the agent write its own tools. Sandboxes provide isolation with allow-listed commands. Memory files such as AGENTS.md give persistent instructions. Compaction and progressive skill disclosure counter context rot. "Ralph loops" restart with fresh context and read state back from files (LangChain) medium. Search results show disagreement about who coined the vocabulary. Accounts variously credit Trivedy, Mitchell Hashimoto, or Birgitta Böckeler's April 2026 article on Martin Fowler's site. None of these attributions was verified against a primary source (Endor Labs explainer; Addy Osmani) medium.

Facts vs. opinions. The definition is a convention, not a finding. The empirical claims attached to it are weaker than they sound. LangChain says Opus 4.6 inside Claude Code scores "far below" Opus 4.6 in other harnesses on Terminal Bench 2.0, and that its own coding agent moved from top 30 to top 5 by changing only the harness. The anatomy post gives no scores, run counts or methodology for either claim (LangChain). A widely repeated anecdote says Vercel cut about 80% of an agent's tools and success went from 80% to 100% with the model unchanged. In the search results it appears only secondhand. Figures like "88% of agent projects fail to reach production" circulate with no source (search summary) medium.

Other perspectives. Anthropic's postmortem is the strongest evidence because it is involuntary and not marketing. Three changes caused a month of Claude Code complaints, and none of them touched the weights. On March 4, the default reasoning effort went from high to medium to reduce UI waits; it was reverted on April 7. On March 26, a change meant to clear stale thinking once from sessions idle for over an hour instead cleared it on every turn; it was fixed on April 10 in v2.1.101. On April 16, a verbosity-limiting system prompt went in; it was reverted on April 20 after a broader eval showed a 3% drop for Opus 4.6 and 4.7 (Anthropic; Fortune). The thinking-clearing bug got past code review, unit and end-to-end tests, automated checks and dogfooding. A separate change to how thinking was displayed hid the bug in most CLI sessions (Anthropic) medium +1. Cursor's kernel experiment, covered in the archive below, points the same way: its "entire coordination protocol lived in a single markdown file" cursor. The counter-position is that harness tuning overfits. LangChain itself notes that models trained against a specific harness tool (OpenAI's apply_patch is the example) can do worse elsewhere. On that view, "harness engineering" is partly compensation for models that will absorb these behaviours in training (LangChain) medium.

Why it matters. For the reader's own setup, which has hooks, a long CLAUDE.md and subagents, the practical lessons come from the postmortem rather than any guide. Version and evaluate harness changes the way you would model changes. Watch for the failure mode where one harness change hides the symptoms of another. Keep machine-readable canaries, such as the stop-hook firing rate from the archived thinking analysis. Anthropic's own remediation list reads like a harness-engineering checklist: per-model evals for every system-prompt change, line-by-line ablations, soak periods and gradual rollouts for anything that trades against intelligence, and gating model-specific instructions to their target model (Anthropic). "Agent = Model + Harness" is a useful mnemonic, but the evidence that the harness moves outcomes by large margins is mostly vendor anecdote, apart from Anthropic's own incident data medium.

Next-Concept Modeling: coarse-to-fine text generation from Stanford and Together AI

1 source, 4 min read

What happened. AlphaSignal's Sunday deep dive by Ben Dickson covers Next-Concept Modeling (NCM), framed as an architecture that "challenges the token-by-token generation process behind today's LLMs" source. The primary source is arXiv:2610.14162, submitted October 9, 2026. Hermann Kumbong and Ishan S. Khare are equal-contribution first authors, followed by Iddah Mlauzi, Andrew Woen, Charles Ding, E. Kelly Buchanan, Simran Arora (Together AI), Azalia Mirhoseini and Christopher Ré. A Hazy Research blog post followed on October 12. Code is MIT-licensed at HazyResearch/ncm, with checkpoints on Hugging Face source.

Details. NCM has two stages. In the first, a multiscale residual VQ-VAE turns a text sequence into K levels of discrete codes. Level 1 is a handful of codes summarising the whole sequence, and each further level encodes what the reconstruction still lacks. Each level has its own codebook. Nested dropout pushes early levels to carry useful information, and training uses a token-level reconstruction objective. These are the three changes the authors make to VAR, the visual-autoregressive method from image generation (Hazy Research). In the second stage the tokenizer is frozen, and a transformer generates levels coarse to fine, predicting every code within a level in parallel. During training, ground-truth earlier levels let all levels be predicted in one forward pass, and some conditioning codes are deliberately corrupted for robustness. During inference, levels run sequentially. The blog's translation example shows "Level 11 of 11", so the number of sequential steps is about a dozen, not one per token source.

The paper's numbers are against diffusion LMs at about 100M parameters, measured on one H100. On LM1B, NCM gets better generative perplexity than DUO, the strongest diffusion baseline, while running about 21 times faster in wall-clock time with 11 times fewer function evaluations. On OpenWebText it is "competitive" while about 10 times faster. On XSum it is 31 times faster than AURORA-LM with 16 times fewer function evaluations. Training used about 13.36 billion token positions, tokenizer and generator combined, against 66 billion for the baselines, roughly 4.9 times fewer. On WMT14 German-to-English, the autoregressive baseline scores 25.2 BLEU at 64 evaluations, the best non-autoregressive baseline (E2D2) 24.8, NCM 22.6 at 11 evaluations, and NCM with minimum-Bayes-risk selection 25.2 at 132 evaluations. On XSum, ROUGE-1/2/L is 30.5/10.2/24.4 for a 99M autoregressive model, 34.7/12.2/26.6 for AURORA-LM, 35.0/12.8/28.0 for NCM, and 37.3/14.0/29.6 for NCM with MBR. On Sudoku the share of puzzles fully solved, easy/medium/hard, is 13.9/5.1/0.6 for autoregressive sampling, 97.7/92.8/81.3 for FMLM+, and 99.5/96.5/86.1 for NCM at 12 evaluations. Tokenizer reconstruction accuracy is 98.79% to 100%, and codebook utilisation 62% to 90% (arXiv HTML) source.

Facts vs. opinions. AlphaSignal's numbers match the paper: 10 to 31 times faster than diffusion baselines, 4 to 5 times fewer training tokens, scaling tested to 725M source. The framing differs. All the speed claims are relative to diffusion LMs, not to autoregressive decoding with a KV cache, which is what production LLMs use. Where autoregressive baselines appear, NCM loses on translation without MBR and wins on summarisation and Sudoku. A 99M autoregressive model with naive sampling scoring 0.6% on hard Sudoku is a weak baseline for a constraint-satisfaction task. The wall-clock comparison against an optimised autoregressive decoder was not visible in the sections read. AlphaSignal says MBR gave "approximately 7% higher ROUGE-L". The table's ROUGE-L gap, 29.6 against 26.6, is about 11% relative, but the paper's 7% figure is stated at matched sampling time rather than the table's settings. The two are not directly comparable and were not reconciled here. The authors themselves concede that generative perplexity is an imperfect quality metric, that scaling results are "preliminary", that the hierarchy is fixed for every example, and that tokenizer and generator are trained separately (Hazy Research) source.

Other perspectives. Reactions on X were mostly enthusiastic and are opinion, not evidence. Akshay Pachaar's widely shared thread added two caveats not in the newsletter: some evaluations apply repetition penalties during final decoding, and the release includes evaluation code and checkpoints but no training pipeline (X search, 2026-10-16). The Turing Post noted that "concepts" are learned codes, not human-readable ideas. That deserves stress, because the name invites confusion with Meta's 2024 "Large Concept Models", which predicted sentence embeddings. Grigory Sapunov asked whether a single multiscale VQ-VAE can scale to contexts of 32k tokens and beyond without entity-swap errors. That is the right worry: lossy residual codes have to preserve exact identifiers, numbers and code tokens, which perplexity does not measure. Together AI's Vipul Ved Prakash promoted the 21x figure. Together is an author affiliation source.

Why it matters. The interesting property is structural, not raw speed. Early levels are tiny, so global structure is decided cheaply and then refined, and the per-step cost grows with the level rather than the full sequence. That is why sampling many candidates and selecting by MBR becomes affordable. For an engineer, the questions to watch are: exactness on code and named entities as reconstruction accuracy drops below 100%; whether a learned, adaptive number of levels works; and any head-to-head against a KV-cached autoregressive model of equal parameters and training compute. Until those exist, NCM is a credible third family next to autoregressive and diffusion models, demonstrated below 1B parameters, and not yet a challenge to how frontier models generate text source.

MegaRAG: page-level multimodal graphs instead of blind chunking

2 sources, 3 min read

What happened. Florian June's "MegaRAG: Stop Chunking Blindly, Start Reading Like a Human" (AI Exploration Journey) appeared in three digests medium. Medium blocked the fetch, so the newsletter-author's commentary is unavailable. The underlying work is "MegaRAG: Multimodal Knowledge Graph-Based Retrieval Augmented Generation" by Chi-Hsiang Hsiao, Yi-Cheng Wang, Tzung-Sheng Lin, Yi-Ren Yeh and Chu-Song Chen (arXiv:2512.20626). It was submitted November 26, 2025 and accepted as an ACL 2026 long paper (ACL Anthology) medium.

Details. "Reading like a human" means processing documents a page at a time instead of as fixed-size text chunks. GPT-4o-mini processes each page's text, figures, tables and full-page image in parallel and extracts page-level entities and relations. These are merged across pages by name matching, with descriptions aggregated. A refinement pass then retrieves, for each page, a subgraph built from embedded entity names and relation keywords plus one-hop neighbours, truncated to 32,000 tokens. The multimodal model is asked to add missing entities and cross-modal relations; the paper runs one round. GME-Qwen2-VL-2B embeds entities, relations and page images into a shared space. Retrieval follows LightRAG's dual-level keyword scheme: top-60 entities and relations plus neighbours, and the top 6 page images. Generation produces two intermediate answers in parallel, one from the subgraph and one from the page images, then merges them. The authors say this reduces modality bias (arXiv) medium.

Reported results: on text-only UltraDomain, MegaRAG's average pairwise win rates are 59.0% comprehensiveness, 71.4% diversity, 74.8% empowerment and 71.8% overall. On the authors' multimodal global-QA sets (including a new World History benchmark) they are 83.3%, 92.7%, 84.7% and 89.5%. On a 2,000-item SlideVQA subset, accuracy is 64.85% against 27.66% for LightRAG. On RealMMBench, FinReport, FinSlides, TechReport and TechSlides score 39.51%, 58.37%, 51.51% and 60.86%, against best baselines of 31.30%, 42.74%, 31.39% and 36.63% (arXiv) medium.

Facts vs. opinions. The method description and numbers are the authors'. The evaluation design is weaker than the margins suggest. Global questions are synthetic, 125 per dataset. Global QA is scored by LLM-judged pairwise win rates, and local QA by an LLM judge of correctness, with no human validation, no variance across runs and no limitations section. One ablation should make a reader pause. Building the graph from text alone drops the GenAI overall win rate from 86.4% to 0.8%. A pairwise judge that swings almost to zero on one ablation is telling you about the judge's sensitivity as much as about the method. The paper reports no cost for graph construction, neither API spend nor wall-clock time, beyond GME encoding at about 0.97 seconds per page image on an RTX 3090 (arXiv) medium.

Other perspectives. Set against the PubMed graph above, MegaRAG is the expensive end of GraphRAG. Every page passes through a multimodal model at least twice, once to extract and once to refine. For slide decks, financial reports and technical PDFs where meaning lives in charts and layout, that cost may be justified. The SlideVQA gap over text-only baselines is large enough to survive some judge noise. For text-dominant corpora with existing structure, the PubMed project's lesson applies: curated metadata is cheaper than extraction. The headline's anti-chunking framing also overreaches. The page is still a chunk, just one chosen by layout instead of token count, and the retrieval stage still takes top-k pages medium +1.

Why it matters. Two ideas carry over even without adopting MegaRAG. First, use the document's native unit (page, slide, section) as the retrieval and citation unit when layout carries meaning. Second, generate separate answers from structured and visual evidence, then reconcile them. That second idea is a cheap guard against one modality dominating. Do not treat the win rates as effect sizes. Before building on this, run it with a human-graded evaluation on your own documents and log the extraction bill medium.

RAG vs. OKF: curated memory and retrieval as complementary layers

3 sources, 2 min read

What happened. Rohan Mistry's Towards AI piece "RAG vs OKF: Stop Choosing One. Why AI Agents Need Both" summarises its argument as "RAG retrieves. OKF remembers." medium. Medium blocked the fetch, so the article's specifics are unverified. OKF is Google Cloud's Open Knowledge Format, v0.1, released June 12, 2026. Secondary coverage names Sam McVeety and Amir Hormati as authors of the announcement (The Decoder; heise) medium.

Details. According to secondary coverage, OKF is a format, not a product or API. It is a directory of Markdown files, one concept per file (a table, dataset, API, metric or runbook), each with YAML frontmatter in which only a type field is mandatory. Optional fields include title, description, resource, tags and timestamp. Two reserved filenames keep bundles navigable: index.md lists a directory's contents, and log.md records changes under ISO 8601 date headings. Concepts link to one another through ordinary Markdown links, so a bundle forms a graph. No SDK is required. Google published reference tooling, including an enrichment agent that walks a BigQuery dataset to draft concept files and a static HTML visualiser, and says its Knowledge Catalog supports OKF. One source puts the v0.1 spec at 451 lines and 14.7 KB (GitBook; The Decoder) medium.

Facts vs. opinions. The spec details above come from secondary sources. Google's original blog post and the spec repository were not retrieved, so field names and wording should be checked against the source. The "both" thesis is opinion, and a near-consensus one. A cluster of Medium posts makes the same split: put stable, curated, high-value knowledge in OKF bundles and leave large, changing, unstructured collections to retrieval (Analytics Vidhya; MindStudio). Other posts frame OKF as "making RAG optional", which overstates a v0.1 Markdown convention medium.

Other perspectives. Strip the branding and OKF formalises what coding agents already do with CLAUDE.md, AGENTS.md and skills directories: human-reviewable, git-versioned, navigable Markdown that an agent reads by walking links instead of by vector similarity. That suits definitions, metric semantics and runbooks, where the cost of retrieving a plausible but wrong chunk is high and the content changes slowly. It has known failure modes. Curated bundles drift out of date unless the update path is enforced, so log.md is a convention, not a guarantee. Agent-written updates to "memory" are a prompt-injection persistence vector if untrusted content can reach them. Navigation by links costs context and tool calls, so it does not scale to millions of documents. The archived HGMem work and the PubMed graph sit at different points on the same axis: how much structure to impose on memory, and who pays for it, humans or LLM extraction calls medium +2.

Why it matters. For agent design, the practical split is by update rate and by the cost of being wrong, not RAG against something else. Curated, versioned concept files fit authoritative definitions. Retrieval fits the long tail. A working memory that the agent builds per task, as HGMem does, fits multi-step synthesis. A vendor-neutral format matters mainly for portability across agent frameworks. Whether other vendors adopt OKF, or it stays a Google Cloud convention, was not established as of 2026-10-19. Treat articles claiming it settles the agent-memory question as opinion medium.

From the archive

HGMem: hypergraph working memory for long-context RAG (saved 2026-02-07)

3 sources, 2 min read

What it said. The repository Encyclomen/HGMem accompanies the arXiv paper "Improving Multi-step RAG with Hypergraph-based Memory for Long-Context Complex Relational Modeling" by Chulun Zhou, Chunkang Zhang, Guoxin Yu, Fandong Meng, Jie Zhou, Wai Lam and Mo Yu (arXiv 2512.23959, December 2025). It argued that RAG working memory is usually passive storage of isolated facts, and that graph approaches only model pairwise relations. HGMem instead builds a question-specific hypergraph, in which each hyperedge is a "memory point" linking several facts. The memory evolves through update, insertion and merge operations across retrieval steps. The target is "sense-making" questions whose answers are not stated in any one passage. The README demonstrates NarrativeQA with GPT-4o or a locally served Qwen2.5-32B on four GPUs, using BGE-M3 embeddings github.

How it aged. It held up academically. The paper became an ICML 2026 poster under a slightly retitled name, "HGMem: Hypergraph-based Working Memory to Improve Multi-step RAG for Long-Context Complex Relational Modeling" (ICML 2026). Mirror and summary sites report the authors' claim that it consistently beats strong baselines across diverse tasks. One summary adds that the Qwen2.5-32B configuration often matched or exceeded GPT-4o-based baselines (arXiv HTML; alphaXiv). Those are the authors' numbers, and no independent reproduction turned up. Searches did not surface a list of citing papers, follow-up work by the same group, or production frameworks adopting hypergraph memory. Adoption beyond the paper is therefore unknown, not absent. The repository's star count and commit activity after February were not checked.

The broader trend does support the paper's diagnosis. Through 2026, agent memory moved away from flat vector stores toward structured, evolving memory. Examples include Google's OKF in June, the curated-Markdown approach in today's lead, and graph-structured RAG in MegaRAG at ACL 2026. None of these uses hyperedges. The field went for cheaper structures: files with links, pairwise graphs built from metadata, page-level nodes. That says something about HGMem's practical position. It builds memory per question with LLM calls at every step, which is expensive, and its evaluation sits in the academic "global sense-making" niche whose LLM-judged metrics share MegaRAG's weaknesses github +2.

Why it matters now. The core idea, that a memory unit should bind several facts under one perspective rather than store triples, matches how a good analyst's notes work, and it is still under-used in agent harnesses. If you build multi-step research agents, the cheapest form of HGMem is a scratchpad whose entries are explicitly multi-fact claims with provenance, merged as evidence accumulates. That needs no hypergraph library. Whether the full machinery beats such a scratchpad on cost-adjusted quality is the experiment nobody published as of 2026-10-19 github.

"Anthropic Thinking Reduction": the Claude Code regression analysis (saved 2026-04-02)

1 source, 3 min read

What it said. The gist was published under Ben Vanik's GitHub account. The same report was filed as anthropics/claude-code issue #42796 by the account stellaraccident on April 2, 2026, and a Hacker News user posting as noxa said they wrote it. It analysed 6,852 Claude Code session files from January 30 to April 1 across IREE compiler and GPU-driver projects. The data covered 17,871 thinking blocks and 234,760 tool calls. Its central claim was that the rollout of thinking redaction (header redact-thinking-2026-02-12) "correlates precisely" with a quality collapse. It used the thinking blocks' signature length as a proxy for thinking depth, citing a Pearson correlation of 0.971 on 7,146 paired samples. By that proxy, depth had fallen about 67% by late February. Reads per edit fell from 6.6 to 2.0. The rate of edits to unread files, self-contradictions and "simplest"-style shortcuts rose. A stop-phrase hook fired 173 times in 17 days after March 8 and zero times before. API requests rose 80-fold, which the author partly attributed to a deliberate scale-up to many concurrent agents. The report asked for transparency about thinking allocation, a "max thinking" tier and thinking-token counts in API responses github.

How it aged. It was right about the symptom, wrong about the named cause, and partly right about the mechanism. On April 6, Anthropic's Boris Cherny replied on the issue that the redaction header "hides thinking from the UI" and "does not impact thinking itself, nor does it impact thinking budgets." He said users could restore summaries with showThinkingSummaries: true (GitHub issue #42796). On April 23, Anthropic published a postmortem confirming a real month-long degradation from three product-layer changes, none of them redaction (Anthropic). Two of the three did reduce effective reasoning, which is the gist's real thesis. The March 4 cut in default effort from high to medium lowers thinking depth directly. It falls in the same week the gist's redaction share crossed 50% (March 8), so redaction was a confounded covariate. The March 26 bug, which dropped prior thinking on every turn, matches the gist's description of forgetfulness and thrashing. The postmortem also says a display change "hid the bug in most CLI sessions". In that sense, reduced visibility did make the regression harder to diagnose, as the gist complained. Remedies: effort was restored on April 7, the clearing bug fixed on April 10, the verbosity prompt reverted on April 20, and usage limits reset on April 23. The issue was closed and locked on April 24, with many commenters still dissatisfied (GitHub issue #42796; Fortune) github.

Some things remain unexplained. The gist's own table shows reads per edit collapsing from 21.8 to 6.3 in the week of February 2, and depth falling through February, before any postmortem cause. The postmortem does not address February. The author's concurrent-session scale-up is a confounder the gist itself admits. The signature-length proxy was never confirmed or denied by Anthropic. On Hacker News the author said the effects persisted even at max effort with adaptive thinking disabled, and attributed them to load-sensitive allocation on subscription plans. Anthropic did not confirm that. Commenters asked for a controlled comparison between subscription and API, which was not found (Hacker News). A separate issue claiming redaction caused deceptive behaviour, #32997, was closed as not planned (GitHub). No evidence was found as of 2026-10-19 that the requested thinking-token usage field shipped github.

Why it matters now. The method aged better than the conclusion. Behavioural telemetry from your own logs (read-to-edit ratio, edits to unread files, stop-hook firings, interrupt rate) detected a real regression weeks before the vendor acknowledged it. Correlating it with the wrong change is the predictable failure of observational analysis when several changes ship close together. Keep the canaries. Before naming a cause, check the vendor changelog and the effort settings. Also set cleanupPeriodDays high, as the author advised, so the logs exist when you need them github.

Google TurboQuant: "6x less LLM memory" (saved 2026-03-30)

1 source, 2 min read

What it said. Ars Technica reported Google's claim that TurboQuant, an ICLR 2026 paper, compresses the KV cache about sixfold without measurable quality loss, needs no retraining or calibration, and speeds attention-logit computation up to eight times on H100 arstechnica. Ars Technica could not be fetched, so the claims here follow a contemporaneous technical summary (frr.dev).

How it aged. It aged on three tracks. Technically, the core held up in a reduced form. Independent implementations within a month found about 4.7x real compression with 3-bit values on an M4 Max under MLX, which cut a 16K-context KV cache from 4.2 GB to 897 MB, and about 5x in PyTorch with 4-bit keys and 2-bit values. The QJL error-correction stage hurt generation quality, and MSE-only quantization did better, so roughly 80% of the benefit appears to come from the PolarQuant/rotation component alone (frr.dev) arstechnica.

On adoption, a third-party plugin README says TurboQuant KV compression for GQA and MHA models was merged into upstream vLLM on April 15, 2026 as PR #38479, exposed as a turboquant_3bit_nc cache dtype. An arXiv citation points to a May 2026 vLLM blog post, "TurboQuant in vLLM". Both are secondary and the PR was not checked directly (turboquant-vllm). In llama.cpp, upstream support appeared unmerged in the sources found. Usable support lives in forks: TheTom's with Metal, spiritbuun's with CUDA, and AmesianX's claiming 5.2x. Georgi Gerganov's simpler "attn-rot" rotation PR reportedly captures much of the benefit (AmesianX/TurboQuant; Kaitchup). The llama.cpp status may have changed since those sources were written. A June post describes "Turbovec", a vector index built on the method (aniketkarneai) arstechnica.

On credit, the RaBitQ authors (Jianyang Gao and colleagues) said from March 27 that the paper misdescribed RaBitQ as grid-based product quantization while omitting that both methods rely on random rotation. They also said it misstated RaBitQ's guarantees and benchmarked RaBitQ single-threaded against a GPU. They report raising this before submission, filing an ICLR ethics complaint, and receiving only a generic reply. One report says a co-author promised to correct the arXiv version (Gao on X; Gao, Medium). Almost all of this account comes from the RaBitQ side. Google's position on the core allegations was not found. A Milvus interview argued that the memory-stock selloff the paper triggered was "a false alarm" (Milvus) arstechnica.

Why it matters now. For local inference, 3-to-4-bit KV caches built on random rotation are now a mainstream option and no longer exotic. Expect about 4 to 5x in practice, not 6x, and benchmark long-context retrieval yourself, because perplexity hides needle failures. The attribution fight is a reminder that "Google says" headlines compress a lineage of rotation-based quantization into one brand arstechnica.

Cursor and NVIDIA: 38% GPU kernel speedup from a multi-agent harness (saved 2026-04-15)

1 source, 2 min read

What it said. Cursor reported that its multi-agent harness ran autonomously for three weeks on 235 kernel-optimisation problems that NVIDIA generated with SOL-ExecBench from more than 124 open-source production models. Benchmarking ran on 27 B200 GPUs. It reported a 1.38x geometric-mean speedup over PyTorch baselines that a single agent had optimised. 149 of 235 problems (63%) beat baseline, and 45 (19%) exceeded 2x. Highlights: a grouped-query attention prefill kernel at SOL 0.9722, an 84% speedup over FlashInfer, giving 3% better time-to-first-token in SGLang on Llama 3.1 8B. A from-scratch GEMM reached 86% of cuBLAS and beat it by up to 9% on small-M shapes. The median SOL score was only 0.56. The coordination protocol lived in one Markdown file. Cursor said multi-agent architectures "will quickly become the default" cursor.

How it aged. Six months later the evidence is thin. No independent reproduction or critique of the 38% figure was found. Coverage after April restates Cursor's post (KuCoin; getaibook). NVIDIA's SOL-ExecBench L1 leaderboard, as summarised in search results, lists a "Cursor" entry at rank 14 with SOL 0.5404 against the 0.500 baseline. The page itself would not render, and the snapshot date is unknown (NVIDIA SOL-ExecBench). If that rank is current, a dozen or more entries outperform Cursor's on that collection, which tempers "approaching hardware limits". The benchmark is described in a March 2026 NVIDIA paper (arXiv 2603.19173). An August 2026 paper, KernelArc, from a different group, reports its own multi-agent search beating a single agent on one case (0.546 against 0.441) and cites an August 20 leaderboard snapshot. That supports the general multi-agent-beats-single-agent claim in a narrow setting, not Cursor's numbers (KernelArc) cursor.

Read again, the original post had soft spots. The 38% is measured against a single-agent-optimised PyTorch baseline, not against the best available library kernels. 86 of 235 problems did not beat baseline at all. The flagship end-to-end gain was 3% TTFT on one model. No dated follow-up showing these techniques in Cursor's product was found cursor.

Why it matters now. Kernel optimisation remains the cleanest testbed for long-running agents because the reward is measurable and the benchmark can reject cheating. NVIDIA's pipeline rejects results that exceed physical limits. That makes it a good template for any agent evaluation you build: an objective verifier, plus a hardware-limit or oracle sanity check. The scepticism lesson: geomean speedups over a self-chosen baseline are vendor-run numbers, and leaderboards, where they exist, are the better anchor cursor.

"Anthropic: Recursive self-improvement is here" (saved 2026-03-14)

2 sources, 2 min read

What it said. An r/singularity post (1,336 points, 277 comments) carried that headline over excerpts from a March 11, 2026 Time feature on Anthropic. The central figure: "Some 70% to 90% of the code used in developing future models is now written by Claude." The top comment, with 324 points, quoted the same article's caveat that "human scientists still guide Claude's progress." Another commenter noted that metrics such as a "427x speedup" came from the Opus 4.6 model card's kernel benchmark (Reddit thread) reddit.

How it aged. The headline overstated the article then, and Anthropic's own later publication still does not endorse it. In early June 2026 the Anthropic Institute published "When AI builds itself" (Anthropic, as linked by TNW). As reported by TNW, the report says Claude wrote over 80% of code merged into Anthropic's production codebase as of May 2026, up from low single digits when Claude Code launched in February 2025. Engineers merged about 8x as much code per day in Q2 2026 as in 2024. A poll of 130 research staff gave a median self-estimate of about 4x output with Mythos Preview. In an April study, nine parallel Claude agents recovered 97% of a performance gap in 800+ hours and about $18,000 of compute, against 23% for two humans working a week. Claude's agreement with researchers on the best next step rose from 51% to 64% between November 2025 and April 2026. The report also says plainly that Anthropic has not reached recursive self-improvement, and that the research evidence is "more preliminary" than the engineering evidence. It says Claude-written code was "somewhat worse" than human code in late 2025 and is roughly at parity now, and that the productivity numbers include self-reports. It proposed a verifiable multi-lab, multi-country pause mechanism as a design to prepare, not a policy in force (TNW). Secondary blogs add that Mythos Preview reached a 52x speedup on an internal "speed up your own training code" task, against about 3x for Claude Opus 4. That figure was not verified against the primary document (Enterprise DNA). One aggregator attributes to Jack Clark a 60% probability of recursive self-improvement by 2028. It could not be confirmed reddit.

Why it matters now. The thread's best reply already said it: the development loop is closing, and the research loop lags. Seven months on, that is still Anthropic's own position. "Share of code written by the model" rose from 70–90% (a Time estimate) to over 80% (a company measurement) and stays a weak proxy. Lines of code are not research direction. The postmortem in today's harness story is a reminder that more AI-written code also ships AI-reviewed regressions. Watch for externally verifiable signals, such as model releases whose key improvements are attributed to automated research with ablations. Code-share percentages are not such signals reddit +1.

Epoch AI: five hyperscalers own two-thirds of global AI compute (saved 2026-04-15)

2 sources, 2 min read

What it said. Epoch's newsletter teaser said Google, Microsoft, Meta, Amazon and Oracle "now control about two-thirds of the world's compute, up slightly from ~60% at the start of 2024." It drew on the new AI Chip Owners data hub, and noted that labs including OpenAI and Anthropic depend almost entirely on these hyperscalers substack.

How it aged. The underlying data insight, dated April 14, 2026 and written by Luke Emberson, Josh You and Venkat Somala, gives a higher figure than the teaser: 70.7% of cumulative AI compute in H100-equivalents as of Q4 2025, up from 62.5% in Q1 2024. By company: Google 24.8% (about 5.0 million H100e), Microsoft 16.8%, Amazon 12.1%, Meta 11.3%, Oracle 5.6% (Epoch AI). The launch post said "over 70%", while a Substack version said "over 60%" (Epoch explorer launch). "Two-thirds" was an understatement inside Epoch's own materials. The data table has a Q1 2026 row at 75.8%, although the text says Q1 2026 was excluded as not finalised. It is a provisional number, but it points the same way. The CSV was last refreshed April 16. No later update appeared on the insight page as of 2026-10-19 substack.

Caveats from Epoch itself: the dataset misses some ownership and is weaker before 2023. H100e uses each chip's peak 8-bit throughput, which flatters some accelerators relative to real workloads. Ownership is not usage: OpenAI rents from Microsoft, Oracle (including Stargate) and CoreWeave, and Anthropic mainly from Amazon and Google. Google's lead rests on almost 4 million H100e of TPUs, so it is the one hyperscaler whose share does not depend on Nvidia allocation (Network World) substack.

Why it matters now. Concentration rose by about 8 points in two years, and the provisional Q1 2026 figure suggests it is still rising. For infrastructure planning this means price and availability of frontier compute are set by five landlords, one of whom (Google) also competes at the model layer with custom silicon. It also bears on the "load-sensitive thinking" hypothesis in the Claude Code analysis above. When capacity is rented and contended, product-layer defaults like effort levels become levers for managing capacity, whatever the stated reason substack +1.

Brain & consciousness

The neural code at 100

1 source, 2 min read

Matteo Carandini's centenary essay in The Transmitter marks Edgar Adrian's two 1926 papers, written with Yngve Zotterman, which showed that neurons signal through trains of uniform spikes thetransmitter. The story as Carandini tells it: earlier work established that nerve responses are all-or-none, but single-axon spikes were too small to see. Adrian used vacuum-valve amplification and noticed fluctuations tracking muscle stretch. Zotterman then dissected the muscle down to a single spindle, isolating one fibre. The spikes were uniform in shape and regular, and their frequency rose with stretch. Adrian's conclusion is the founding statement of rate coding: "the message can only be varied by changes in the frequency and duration of the discharge," a signal "scarcely more complex than a succession of dots in the Morse Code." The same paper documented adaptation, firing slowing under constant stimulation, and produced what Carandini calls "the first graph of neuronal firing rate plotted against something else", a plot whose y-axis "was not even known to exist." He argues that this plot is the ancestor of receptive fields, orientation tuning, place cells, reward-prediction signals and grid cells. He also redid the original figures, flipping the right-to-left time axis and deconvolving the capillary-electrometer blur so that single and multi-axon spikes can be told apart (The Transmitter) thetransmitter.

For whole-brain emulation the essay matters more for what it leaves out than for what it claims. It does not engage the rate-versus-timing debate and states no limits of the spike code. Its closing hope is that future researchers "will have discovered another form of neural code", an admission that the field's model of the message is still basically Adrian's (The Transmitter). The following is background, not the essay's argument. Emulation proposals implicitly bet that spike times, plus synaptic and neuromodulatory state, are sufficient to describe what a brain computes. Adrian's result shows spikes carry information. It does not show they carry all of it. Well-documented cases of precise spike timing mattering (auditory localisation, first-spike latency codes) and of non-spiking signalling (graded potentials, gap junctions, glial and neuromodulator dynamics) mark where a pure rate-and-spike abstraction might lose fidelity. The essay is a reminder that the abstraction emulation relies on is one century old, empirically productive, and not proven complete thetransmitter.

Govern neurodata by how it's used, not where it's from

1 source, 2 min read

José M. Muñoz argues in The Transmitter that the wave of new neurodata laws defines "brain data" by where it comes from, and that this will burden basic research without reducing the real risks thetransmitter. Colorado and California amended their consumer-privacy acts to list neural data as sensitive based on its origin in the nervous system. California excludes inferences from non-neural data, and Colorado does not. Connecticut covers only central-nervous-system data. Montana folded "neurotechnology data" into its Genetic Information Privacy Act and excludes downstream signals such as pupil dilation and breathing rate, which Colorado does not. The result, in his example, is that the same pupillometry channel may be neurodata in Denver but not in Helena (The Transmitter) thetransmitter.

His model case is Chile's 2023 Supreme Court ruling against the EEG headset maker Emotiv. The court relied not on Chile's 2021 constitutional neurorights clause but on existing rights to physical and mental integrity and privacy. The principle it applied: "Consent to record data for one purpose... is not consent to use it for another." Muñoz reads the U.S. Senate's MIND Act, introduced September 2025 and awaiting committee action, as the start of a use-based approach. It imposes no rules, but directs the FTC to study sensitivity tiers and higher scrutiny for high-risk uses. His concrete worry is that IRBs, university counsel and funders will adopt the nearest consumer-law definition. Another is that a lab's consumer EEG headset brings its manufacturer's terms of service with it, governing the data before it becomes a research dataset. He recommends interdisciplinary test projects and operational tools, and asks scientists to engage with scientific societies, funders and legislative hearings: "Show up to one" (The Transmitter) thetransmitter.

The argument is persuasive for research but has a gap the essay does not close. Use-based regimes depend on enforcing purpose limits after collection, and that is exactly where consumer neurotech has failed. Muñoz cites Ienca and colleagues on why brain data draws special concern: it tracks mental states, can escape conscious control, and can be written to. Those properties bear on how a use-based regime would be enforced, not only on whether it should exist. For anyone building BCI or emulation pipelines, the practical point is the headset terms of service. Check what the manufacturer's licence permits before any recording becomes a dataset thetransmitter.

Ways of thinking

Shane Parrish's Brain Food this week pairs two "tiny thoughts" that work as one model. First: "The voice in your head is your ego's defender. It shapes the facts to make you feel right." Second, on refusing AI: "A carpenter who refuses a hammer doesn't make the house any better... Judge the work, not the tool." source. Taken together, they say: evaluate outcomes with instruments your ego cannot bend, and attach your identity to the quality of the result, not to the method.

Today's stories show the model working and failing. The PubMed graph author built a system called an "agentic knowledge graph" and then reported, in his own README, that the graph-based governance thesis scored AUROC 0.500. The calibrated confidence of the plain reader beat it. That is judging the work over the tool, even when the tool is the project's identity medium. The Claude Code analysis shows both halves of the model. The author judged the work rigorously, with read-to-edit ratios, stop-hook firings and interrupt rates, and caught a real regression weeks before the vendor confirmed it. Then the narrative chose the culprit: the visible change, redaction, became the cause, while the actual causes were an effort default and a caching bug shipped the same month github. The defence against your own ego is the same instrument turned on your hypothesis: list every change in the window before attributing.

The vendor side has the mirror image. Cursor reports 38% over a baseline it chose, and NVIDIA's leaderboard, which nobody at Cursor controls, places the entry 14th cursor. MegaRAG's win rates come from a judge whose verdict swings from 86% to under 1% on one ablation medium. Synthetic users in today's NN/g quick hit "reach the same conclusion" as humans while losing the long tail nngroup. In each case the tool is being judged by a measurement the tool's authors designed.

A working rule follows. For any claim, especially your own, ask who built the instrument that produced the number, and whether it could have come out differently. If the person who designed the evaluation would be equally happy with any result, the number tells you about the work. If not, it tells you about the ego. Parrish's other line this week, Marcus Aurelius's "until death, all defeat is psychological", has a reasonable engineering reading. A failed result is information unless you refuse to look at it source.

Wildcards

Mistral x Mozilla: Firefox's Smart Window runs on Mistral

2 sources, 2 min read

Why this is here: exploring inference infrastructure, kernels, and model tooling.

On September 16, 2026, Mozilla and Mistral announced that Mistral models now power Smart Window, Firefox's beta AI browsing assistant. It interprets complex searches, recalls pages the user navigated away from, and finds sources across open tabs. The rollout starts in France and North America, with the UK and Germany expected later in 2026. The stated privacy terms: conversations are not saved on Mozilla's servers by default, and Mistral agrees to zero data retention. Mistral says its models are being fine-tuned for regional languages, dialects and cultural context. The announcement does not name the model or say where inference runs (Mistral) mistral. TNW's headline identifies the model as Mistral Small 4 and notes the context. Firefox users objected to earlier AI plans, and in February Mozilla added a single setting that disables all generative AI features (TNW). Coverage describes the feature as opt-in, with tabs and history shared only when the user chooses mistral.

Why it is relevant to infrastructure: this is a server-inference deal presented as privacy. The privacy rests on a contract (zero retention) rather than architecture (on-device inference). StartupHub put it plainly: a partner-promise model, so trust depends on vendor handling, not browser settings (StartupHub). For a security-minded reader, the questions that matter are not covered in what was found. Is the browsing context sent per request in full or summarised locally? Are requests routed through Mozilla proxies that strip identifiers? Is zero retention audited? Do abuse-monitoring exceptions apply, as they often do in "zero retention" API terms? mistral

Does it hold up? As a distribution story, yes. A European model vendor gets a consumer channel, and Mozilla gets a provider that is not a U.S. hyperscaler, which matters given the 71% compute concentration in today's archive substack. As a privacy story, it holds up only as far as the contract is enforced. Local inference with a small model would have been the stronger guarantee, and the absence of any mention of it is notable mistral.

ARTEMIS: Google's open-source agent for driving real Android phones

2 sources, 2 min read

Why this is here: exploring LLM personalities, open models, and AI commentary.

ARTEMIS, under Google's GitHub organisation, is Apache-2.0 and "turns natural-language instructions into reliable Android automation" for test suites and everyday tasks github. It has two profiles. Flash is a single model in an observe, reason, act loop at about 3 to 5 seconds per step. It chains repeated transient taps into one click_sequence, and has no task plan, no pre-execution checks and no ADB shell. Pro is a planner, operator and checker graph at about 15 to 40 seconds per step. The planner writes milestones, the operator executes with the full toolset, and a read-only checker verifies checkpoints and does a final review. A "Safety Net" checks each action before execution, using the XML hierarchy first and pixels as a fallback, and returns blocked actions to the operator as "execution incidents". Targeting prefers element indices and falls back to coordinates and visual location. On first use it installs an "Artemis Accessibility Helper" to read screen layout, which the README says listens only on the phone. The README lists Gemini, Claude, GPT-4o and Qwen-VL. It claims 99%+ completion on Google Research's AndroidWorld benchmark. The repository shows about 12.6k stars, 1.5k forks and 91 open pull requests (GitHub) github.

For the reader, ARTEMIS is a clean case study in harness design, not personality. The checker is read-only. Actions are verified before they execute. Failures come back as structured incidents, not silent retries. These are the same patterns the agent-harness lead describes, applied to a GUI medium. It is also a security object. An accessibility service that can read and drive every app is the most powerful permission on Android. Any on-screen text, such as a message, a web page or a notification, becomes model input, which makes prompt injection through the screen a first-order risk that the README does not discuss github.

Does it hold up? The 99%+ AndroidWorld figure is self-reported and was not independently checked. AndroidWorld is a fixed task suite, so near-saturation says little about arbitrary apps. The README does not say whether ARTEMIS is an official Google product. The roadmap (iOS, on-device VLMs, voice) is aspirational. As a reference architecture for test automation it looks solid. As a general phone agent, give it only a test device github.

Quick hits

Retrieval & knowledge graphs

4 sources, 1 min read

• Semantic chunking pipelines. Kuriko Iwai surveys chunking strategies for RAG. Read it with MegaRAG's point that the document's native unit (page, section) often beats token-window or embedding-boundary chunking when layout carries meaning medium +1.
• "Vector search is not enough". Asma Houimli's GraphRAG blueprint argues that similarity search misses relational questions. Today's PubMed graph is a useful corrective: its accuracy came from dense retrieval and reranking, with the graph supplying provenance, not answers medium +1.

Agents & tooling

3 sources, 1 min read

• Ten modern CLI tools for 2026. A Sandun Lakshan roundup. Useful mainly for agent-heavy terminal workflows where fast search and structured output cut the tokens per tool call; the specific list was not verified medium.
• Spec-driven development in Scrum and Kanban. Jaroslaw Wasowski argues that SDD is not a new waterfall and asks where the spec lives in each process. The practical point for coding agents: the spec has to be a versioned artifact the agent reads, not a ticket comment medium.
• NN/g course on coding tools for designers. A self-paced Nielsen Norman Group course on prototyping inside AI coding tools. It signals that designer-built prototypes in code are now mainstream practice nngroup.

Product & design

3 sources, 1 min read

• Synthetic users vs. humans. NN/g finds synthetic respondents reach the same top-line conclusion as humans but collapse onto the modal answer, losing rare terms and subgroup differences. Its verdict: use them for hypotheses, not evidence nngroup.
• UX maps glossary. NN/g separates chronological maps (journeys), affinity and concept maps, stakeholder maps and roadmaps, and warns teams to confirm which "map" they mean before building one nngroup.
• Eleven questions before redesigning a process for AI. A DataDrivenInvestor checklist by Ramkumar K. It was not read in full, and like any vendor-neutral checklist, its value depends on whether it includes "should this process exist at all" medium.

Data & infrastructure

3 sources, 1 min read

• Lambda vs. Kappa. Siddharth Ghosh revisits batch-plus-speed-layer against stream-only architectures. It is background for anyone building agent telemetry pipelines like the Claude Code analysis in today's archive medium.
• "DuckDB just put a $400K/year skill on your laptop". DataExpert's headline is hype. The substance is that DuckDB and adjacent open-source tools make single-machine analytics over Parquet routine. Today's PubMed graph, for one, used Parquet and listed DuckDB as a dependency medium +1.

Models & background

2 sources, 1 min read

• The ideas that shaped modern language models. A Data Science Collective overview by Kheirie of the experiments behind current LMs. Good context next to Next-Concept Modeling's claim to be a third family beside autoregressive and diffusion models medium +1.

Neuroscience

1 source, 1 min read

• Is confidence a second thought? Ariel Zylberberg argues in The Transmitter that in some settings circuits compute confidence at the same time as the choice, not afterwards. That changes which experiments can tell the accounts apart, and it is a useful analogy for whether LLM "confidence" should be read from the same forward pass or from a separate check thetransmitter.