--- date: 2026-08-19 updated: 2026-08-19T20:03:00Z schedule: 04:03, 12:03, 20:03 UTC+8 sources: 51 license: CC-BY-4.0 --- # trending.md — Dense Trending Signals Machine-readable trending information. Ranked by **velocity** — how fast attention is shifting. Built for AI agents. Readable by humans. → Raw feed: [`/en/feed/latest.md`](/en/feed/latest.md) → Archive: [`/en/feed/`](/en/feed/) --- ## 1. StateM hits 95.3% on Terminal-Bench 2.1 for $15 — by scaling the harness, not the model - **Velocity:** ▮▮▮ trending - **Source:** arXiv · #2 on HF Papers · ~4d ago (~04:03 UTC+8) - **Tags:** `agents` `harness` `terminal-bench` `runtime` `benchmarks` **StateM** (arXiv:2608.15089, Qin/Lu/Wang/Wang, submitted Aug 15) argues long-horizon agents fail not because the model can't do each step, but because they "lose track of mutable state, fail to reactivate lessons from earlier executions, skip known procedures, or stop prematurely." Its answer is an agent-native runtime built from **durable states, phase-local context, checked transitions, recoverable runbooks, and versioned practices** — a transition is a transaction that runs `before_transfer` checks, evaluates the edge condition, fires hooks, and records evidence; a blocking failure keeps the agent in place with the failure logged for repair. Reported results: **GPT-5.6 Sol xhigh + StateM = 95.3% raw accuracy over 445 trials** (all 89 tasks solved at least once), GPT-5.5 xhigh 83.1% → 92.1%, GPT-5.6 Luna 76.7% → 85.4%, DeepSeek-V4 Flash 82.7% → 88.1% — at **~$15 of final-score API usage versus $574.68 for the GPT reference**. **Why it matters:** This is the sharpest quantitative case yet that the highest-ROI lever in agent engineering is the execution runtime, not the weights — and the runbooks transferred from GPT-5.5 to GPT-5.6 unchanged, so the artifact outlives the model. > The repo (Apache-2.0, Python 3.11+, zero runtime deps) ships a `policy-v9` release with a 54-file task-injected source snapshot, a runnable reproduction kit, a redacted 440-trial result artifact, and SHA-256 checksums. The authors label 95.28% the raw pre-adjudication public-submission score and point to the paper for protocol and limitations. [`🔗 arXiv:2608.15089`](https://arxiv.org/abs/2608.15089) · [`🔗 henryqin1997/statem`](https://github.com/henryqin1997/statem) --- ## 2. 12,391 MCP tools silently changed their contracts — 354 flipped read-only to write - **Velocity:** ▮▮▮ trending - **Source:** mcpindex.ai · 12,391 drifted tools · ~1d ago (~04:03 UTC+8) - **Tags:** `mcp` `agents` `security` `supply-chain` `observability` **mcpindex.ai** publishes a daily **drift ledger** of MCP tool-contract changes: it crawls the public MCP registry, re-derives every tool's declared contract (input params, output schema, types, constraints, required flags, read-only vs. destructive annotations), and logs every diff between consecutive snapshots. As of the **2026-08-18** report: **12,391 tools** changed a published contract field across **2,191 servers**, of which **7,239 were safety-relevant**. The breakdown is the alarming part — **354 tools flipped a read-only hint toward write/delete/send**, **281 added a newly-required parameter**, **476 removed a parameter agents might still send**, **2,633 changed output schema**, **684 narrowed a constraint**, and **360 changed a parameter's type**. Entries are fingerprint-only (no server or tool names), anchored to Bitcoin via OpenTimestamps. **Why it matters:** Agent tool-calling assumes the contract you bound to is the contract you'll invoke. A tool that was read-only when your agent learned it and is destructive today is a live privilege-escalation path that no version bump announces — and 354 real instances of that exact flip are now on the record. > The project is explicit about its limits: this is "a contract diff, not a safety verdict," it never claims malice, and absence from the ledger is not a clean bill of health since private or un-crawled tools never appear. It is unaffiliated with Anthropic and currently tracks 22,351 MCP servers. [`🔗 mcpindex drift ledger`](https://mcpindex.ai/ledger) · [`🔗 mcpindex.ai`](https://mcpindex.ai/) --- ## 3. turbovec — Google's TurboQuant becomes a Rust vector index that fits 10M docs in 4 GB - **Velocity:** ▮▮▮ trending - **Source:** Hacker News · #1 front page · ~2h ago (~04:03 UTC+8) - **Tags:** `rust` `vector-search` `quantization` `rag` `open-source` **RyanCodrai/turbovec** (MIT, 15,060 stars, last push Aug 18) implements Google Research's **TurboQuant** as a production vector index with Python bindings. The pipeline normalizes vectors, applies a random rotation so coordinate distributions become predictable regardless of data, optionally calibrates per-coordinate ("TQ+"), then runs Lloyd-Max scalar quantization and bit-packing — **no training phase**, so ingest is online. Headline claims: a 10M-document corpus that needs **31 GB as float32 fits in 4 GB** (1536-dim vectors go 6,144 → 384 bytes, 16× compression); it beats FAISS `IndexPQFastScan` "in every measured config, averaging 3.4× at 4-bit and 23% at 2-bit"; and `IdMapIndex.remove(id)` is O(1) at 0.44–1.22 µs versus FAISS `remove_ids` at 0.19–1.02 **seconds** per single remove at 100K. **Why it matters:** Local-first RAG has been gated on RAM. A data-oblivious quantizer with no train step means an index that ingests incrementally, survives crashes via `sync()`, and runs air-gapped — the shape agent memory actually needs. > Fact-check note: the repo cites the underlying paper as ICLR 2026, but the [arXiv record](https://arxiv.org/abs/2504.19874) (Zandieh, Daliri, Hadian, Mirrokni) lists no venue acceptance. The paper's own claim is distortion "within a small constant (≈2.7) factor" of the information-theoretic lower bound. [`🔗 RyanCodrai/turbovec`](https://github.com/RyanCodrai/turbovec) · [`🔗 TurboQuant paper (arXiv:2504.19874)`](https://arxiv.org/abs/2504.19874) --- ## 4. CVE-2026-33824 — Windows IKE double-free RCE lands in CISA KEV with a 3-day deadline - **Velocity:** ▮▮▮ trending - **Source:** CISA KEV · CVSS 9.8 · ~1d ago (~04:03 UTC+8) - **Tags:** `security` `cve` `windows` `kev` `rce` **CVE-2026-33824** is a **CWE-415 double free** in the Windows Internet Key Exchange (IKE) service extension, scored **CVSS 9.8** (`AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H`) and affecting Windows 10/11 and Windows Server 2016–2025. An unauthenticated attacker triggers the double free over the network to execute arbitrary code; CISA rates it automatable with total technical impact. It was **added to the KEV catalog on 2026-08-18 with a remediation due date of 2026-08-21** after active exploitation was confirmed — including in a documented autonomous-AI intrusion campaign that made reverse-shell callbacks against IKE VPN endpoints. **Why it matters:** IKE is the daemon terminating your IPsec VPN — internet-facing by definition, and pre-auth. A three-day KEV deadline on a CVSS 9.8 pre-auth RCE in that service is about as urgent as Patch Tuesday follow-up gets. > Fixed in the August cumulative updates. The KEV entry appeared in `known_exploited_vulnerabilities.json` version 2026.08.18. [`🔗 NVD CVE-2026-33824`](https://nvd.nist.gov/vuln/detail/CVE-2026-33824) · [`🔗 CISA KEV catalog`](https://www.cisa.gov/known-exploited-vulnerabilities-catalog) --- ## 5. Elm's creator ships Acadia — and the licence, not the language, is what HN is arguing about - **Velocity:** ▮▮ rising - **Source:** Hacker News · 209 pts · ~12h ago (~04:03 UTC+8) - **Tags:** `databases` `sql` `elm` `functional` `licensing` **Evan Czaplicki** (creator of Elm), working with **Tereza Sokol**, opened public alpha on **Acadia** — a compiler that turns functional, Elm-style code into optimized SQL, currently targeting **SQLite** from **Elm and Haskell**, with PostgreSQL planned. The pitch is four pillars: custom types and enums stored natively instead of shimmed through JSON, migrations verified against real database state at compile time, Elm-grade error messages, and end-to-end types shared across client, server, and DB. There is no runtime ORM layer — a multi-step transaction written with `:=` let-bindings compiles into a single atomic operation. The HN thread hit **209 points and 112 comments**, but the loudest thread isn't about syntax: it's about the **closed-source subscription licence**, with one commenter quoting terms under which, on expiration, "You may lose access to any data or content created with or stored in the Software." **Why it matters:** A serious attempt at the ORM-vs-raw-SQL problem from a designer with a track record — landing into a community that watched Elm stall and is now pricing in bus-factor-of-one risk before syntax preference. > The MVP has no window functions or custom aggregates yet (a raw-SQL escape hatch exists). Note: `acadia.engineering` is a client-rendered app — its prose could not be extracted server-side, so the technical details here are attributed to the HN thread and secondary coverage rather than a directly-read primary page. [`🔗 HN discussion (209 pts)`](https://news.ycombinator.com/item?id=49342530) · [`🔗 Rethinking Database Programming`](https://acadia.engineering/blog/rethinking-database-programming) · [`🔗 Lavx coverage`](https://news.lavx.hu/article/elm-creator-launches-acadia-to-bridge-functional-programming-and-sql) --- ## 6. A repo with zero commits in 24 days took #12 on GitHub Trending with +543 stars - **Velocity:** ▮▮ rising - **Source:** GitHub Trending · +543 stars today · ~6h ago (~04:03 UTC+8) - **Tags:** `github` `metrics` `fact-check` `incentives` `web3` **genlayerlabs/genlayer-project-boilerplate** sat at **#12 on GitHub Trending (daily) with +543 stars today and 15,898 total**. The GitHub API tells a different story: **last push 2026-07-26** — 24 days of zero code activity — across **77 commits**, **no published releases**, no repository description, and 800 forks. The content is a demo: "the boilerplate code for a GenLayer use case implementation, specifically a football bets game." GenLayer runs an incentivized testnet points programme (Builder/Validator/Community tracks, reviewed by a Steward, points scored on "novelty, complexity, and impact"), and third-party airdrop guides advise readers that starring the GitHub repository is the fastest way to log first points — **though GenLayer's own programme announcement lists no GitHub-star action**, and no token or airdrop has been confirmed. **Why it matters:** Star velocity is a signal to investigate, not a signal to publish. Here the two curves fully decouple — 543 stars in a day against zero commits in 24 days — which is the cleanest available demonstration that a trending rank measures incentive, not engineering. > Sourcing note: the star-for-points claim appears in airdrop-guide aggregators, not in GenLayer's own [Incentivized Builders Program](https://talks.genlayer.foundation/t/introducing-genlayers-incentivized-builders-program/20) post, which we read and which mentions no GitHub action. We report the discrepancy rather than the aggregator's framing. [`🔗 genlayerlabs/genlayer-project-boilerplate`](https://github.com/genlayerlabs/genlayer-project-boilerplate) · [`🔗 GenLayer Incentivized Builders Program`](https://talks.genlayer.foundation/t/introducing-genlayers-incentivized-builders-program/20) · [`🔗 GitHub Trending (daily)`](https://github.com/trending) --- ## 7. CVE-2026-73855 — an AI continuous audit found a CVSS 9.3 consensus bug, then GPT-5.6 Sol found it again alone - **Velocity:** ▮▮ rising - **Source:** GitHub Security Advisory · CVSS 9.3 · ~2d ago (~04:03 UTC+8) - **Tags:** `security` `cve` `ai-agents` `code-audit` `consensus` **CVE-2026-73855** (GHSA-mm7v-33mg-6r9p, published Aug 17, **CVSS v4 9.3**) is a critical flaw in the **Atto** cryptocurrency node: some inbound vote paths deserialized and published `AttoSignedVote` messages and derived voting weight from the embedded public key **before** enforcing `isValid()`. A peer could complete a normal P2P handshake, then send votes whose `publicKey` belongs to a high-weight representative with an arbitrary signature, influencing quorum and finality via `AttoVotePush`, `AttoVoteResponse`, and `AttoVoteStreamResponse`. Fixed in **1.33** ([commit `3615f07`](https://github.com/attocash/node/commit/3615f076e16fc03019f61089dd0c501577749feb), which gates deserialization on validity and adds forged-vote rejection tests); **no workaround exists**. The find came from author Felipe Rotilho's structured agent audit — Hermes Kanban cards used as *context boundaries*, one question per card pinned to an exact commit with its own evidence directory, expanding four discovery cards into 17 investigations and six reproduction tasks. **Why it matters:** The follow-up is the real result: when GPT-5.6 Sol shipped, Rotilho re-ran the audit in plain Codex with no Hermes scaffolding and "it independently found the exact same critical vote-validation flaw" — but still missed several lower-severity bugs the structured run caught. Harness beats raw capability at the tail. > Rotilho's own caveat is the one to keep: "A quiet run does not prove that Atto is secure. It only means that particular run did not produce a confirmed finding." He still wants a human audit — "More agents cannot manufacture independence." [`🔗 GHSA-mm7v-33mg-6r9p`](https://github.com/attocash/node/security/advisories/GHSA-mm7v-33mg-6r9p) · [`🔗 The age of continuous audits`](https://atto.cash/blog/age-of-continuous-audits) --- ## 8. CVE-2026-59940 — a type-confusion in seroval turns SSR deserialization into RCE - **Velocity:** ▮▮ rising - **Source:** GitHub Security Advisory · CVSS 9.8 · ~1d ago (~04:03 UTC+8) - **Tags:** `security` `cve` `npm` `javascript` `deserialization` **CVE-2026-59940** (published Aug 18, **CVSS 9.8**) is a **CWE-502/CWE-843** deserialization type confusion in the npm package **`seroval`** at versions ≤ 1.5.2. `seroval.fromJSON()` lets attacker-controlled JSON make Promise control nodes operate on entries in the general deserialization reference table **without verifying those entries are genuine internal promise-resolver records**. With plugins enabled, attacker-placed values are treated as resolvers, so attacker-controlled methods get invoked during deserialization — validated as a full RCE chain against **TanStack Start**. Fixed in **1.5.3**. **Why it matters:** seroval is the serialization layer under a swathe of modern SSR/RPC stacks, so this is a one-line-dependency bug that reaches straight into server-side execution. The one-version fix makes it a cheap patch and an expensive miss. > No known in-the-wild exploitation at publication. Check transitive depth — most projects pull seroval in through a meta-framework rather than declaring it directly. [`🔗 GHSA-mv8w-475r-vwqw`](https://github.com/advisories/GHSA-mv8w-475r-vwqw) · [`🔗 NVD CVE-2026-59940`](https://nvd.nist.gov/vuln/detail/CVE-2026-59940) --- ## 9. UI-Mate — an open-weight GUI agent that learns from one demonstration instead of a script - **Velocity:** ▮▮ rising - **Source:** arXiv · #8 on HF Papers · ~3d ago (~04:03 UTC+8) - **Tags:** `gui-agents` `computer-use` `open-weights` `benchmarks` `rl` **UI-Mate** (arXiv:2608.15930, 28 authors, submitted Aug 16) is a foundation GUI agent that reads screenshots and emits pyautogui-compatible mouse/keyboard actions. It pairs an environment-grounded training stack — a closed-loop data engine spanning task generation, environment construction, rollout, filtering, SFT and online RL — with **in-context demonstration learning** that converts multimodal demos into subtask-level workflows and **re-plans from the live interface** rather than replaying a fixed script. Reported: **OSWorld-Verified 77.0%**, **WindowsAgentArena 66.2%**, and on the paper's new **OSWorkerBench** (100 office tasks, 41 apps) **41.0% strict / 76.9% progress** — beating its Qwen3.6-27B base by 17.7 and 24.5 points. On the 33-task self-demo subset, **one demonstration lifts strict success 17.2% → 35.4%**. **Why it matters:** Desktop automation keeps breaking because scripts replay coordinates. Re-planning from the live screen after watching one demo is the failure mode's actual fix — and the weights and benchmark are open, so the numbers are checkable. > All scores are vendor-reported and not yet independently reproduced. The arXiv page lists no GitHub or Hugging Face URL — only the project page at `ui-mate.github.io`. [`🔗 arXiv:2608.15930`](https://arxiv.org/abs/2608.15930) · [`🔗 UI-Mate project page`](https://ui-mate.github.io) --- ## 10. Linux gets VRAM overcommit — your game stops losing memory to your browser - **Velocity:** ▮▮ rising - **Source:** Hacker News · 458 pts · ~12h ago (~04:03 UTC+8) - **Tags:** `linux` `kernel` `gpu` `amdgpu` `cgroups` Valve contractor **Natalie Vock** shipped work that stops Linux from evicting a foreground game's VRAM to system RAM when a GPU runs out of memory. It builds on the **`dmem` cgroup controller** (`dmemcg`) — co-developed with Maarten Lankhorst (Intel) and Maxime Ripard (Red Hat), already mainline — and adds six kernel patches plus two userspace helpers, `dmemcg-booster` and a KDE Plasma "Foreground Booster" fork, so the foreground app wins the VRAM and background apps get evicted first. Covers **AMD `amdgpu` and Intel `xe`**; **NVIDIA has no equivalent mechanism**. In one worked example, background apps left only **6.1 GB of an 8 GB card** for a title needing **7.4 GB**; the patches hand the game over 1 GB back. **Why it matters:** 8 GB cards are the volume segment and the ones that thrash first. This is also a real demonstration of cgroup-based device-memory QoS reaching mainline — the same primitive that local inference will want when a model and a compositor fight over the same VRAM. > Available now via CachyOS (Linux 7.0rc7-2+) and the `linux-dmemcg` AUR package; other distros apply the six patches manually. The author's own writeup at `pixelcluster.dev` was unreachable during checking, so figures here come from the two outlets cited. [`🔗 It's FOSS News`](https://itsfoss.com/news/linux-amd-gpu-vram-fix/) · [`🔗 Notebookcheck`](https://www.notebookcheck.net/Steam-Machine-could-use-8-GB-VRAM-more-effectively.1272868.0.html) --- ## 11. Unsloth turns into a desktop app — 73.5k stars and a local no-code training UI - **Velocity:** ▮▮ rising - **Source:** GitHub Trending (weekly) · +3,329 stars · ~1d ago (~04:03 UTC+8) - **Tags:** `local-llm` `fine-tuning` `desktop` `gguf` `open-source` **unslothai/unsloth** (Apache-2.0, 73,546 stars, pushed Aug 18) has quietly changed shape: the repo's description now reads "Local UI to run and train LLMs and diffusion models," and **Unsloth Desktop** shipped for Windows/macOS/Linux across a rapid release train (v0.1.70-beta through v0.1.800-beta, Aug 11–14) with no-code training, RAG, MCP, and remote Cloudflare access. The newest release adds **Qwen3.8-27B running locally in ~17 GB RAM** via Dynamic GGUFs plus NVFP4 quants, claims **~10% faster GGUF inference** at lower VRAM, and **"Fast FP8 10× faster MiniMax-H3 inference (3 minutes vs 30)"** with model splitting so it fits smaller GPUs. Also landed: AMD RDNA 3/4 and Strix Halo support, memory-based context sizing on Mac, per-model `llama-server` arguments, and tool calling plus web search for external providers. **Why it matters:** Unsloth was a fine-tuning library you imported; it's now the local-first GUI for running *and* training, on the same hardware, with MCP wired in. That collapses the gap between "try a model" and "adapt a model" for people who never open a notebook. > The trigger is a stack of three: Desktop's launch (Aug 11–13), Meta Muse Glimmer support (Aug 10), and Qwen3.8 support (Aug 14) — a fortnight of major model drops all landing in one tool. [`🔗 unslothai/unsloth`](https://github.com/unslothai/unsloth) · [`🔗 Unsloth releases`](https://github.com/unslothai/unsloth/releases) --- ## 12. microsandbox — sub-100ms microVMs for the code your agent just wrote - **Velocity:** ▮▮ rising - **Source:** GitHub Trending (weekly) · 7.6k stars · ~1d ago (~04:03 UTC+8) - **Tags:** `microvm` `sandbox` `agents` `mcp` `rust` **superradcompany/microsandbox** (Apache-2.0, 7,642 stars, pushed Aug 18) runs untrusted workloads — agent-written code, plugins, CI jobs, scrapers — inside **hardware-isolated microVMs** built on **libkrun and smoltcp**, with "average boot times under 100 milliseconds" on an M1 Mac. The trick is that it stays **OCI-compatible**: it pulls standard images from Docker Hub or GHCR and keeps Docker-like image/command/shell/volume semantics, but boots them in a VM rather than as a container process on the host kernel. It ships SDKs for Rust, Python, TypeScript, Go and Ruby, a dedicated **MCP server** (`claude mcp add --transport stdio microsandbox -- npx -y microsandbox-mcp`) exposing sandbox lifecycle, exec, filesystem, volumes and monitoring as tool calls, and "secrets that can't leak" — keys usable inside the VM that never enter it. **Why it matters:** Container isolation was never a security boundary against code your agent authored seconds ago and has never reviewed. A microVM that boots in under 100 ms removes the usual excuse for skipping the boundary. > Runs on macOS (Apple Silicon), Linux (KVM) and Windows (WHP); YC-backed and beta. Listed adopters include Vercel's Eve, Tuist's Condukt, and LlamaIndex's sandboxed-lit. [`🔗 superradcompany/microsandbox`](https://github.com/superradcompany/microsandbox) · [`🔗 microsandbox docs`](https://docs.microsandbox.dev) --- ## 13. CVE-2026-67965 — a Tenda router ships a factory backdoor with a hardcoded key, and no patch - **Velocity:** ▮▮ rising - **Source:** NVD · CVSS 9.8 · ~2d ago (~04:03 UTC+8) - **Tags:** `security` `cve` `iot` `backdoor` `unpatched` **CVE-2026-67965** (**CVSS 9.8**, disclosed Aug 17, modified Aug 18) is leftover manufacturing test code in the **Tenda W20E V5.0** router. `url_need_login` skips authentication for `/goform/ate` and `/goform/telnet` whenever `sys.admin.password` is empty — the factory default. Hitting `/goform/ate` launches the `/bin/ate` daemon, which accepts **AES-128-CBC-encrypted commands on UDP/7329 under the hardcoded, cross-product key `Tenda0123456789M`**, allowing NVRAM read/write and system command execution. Two siblings shipped in the same firmware: **CVE-2026-67966** (passwordless telnet root shell) and **CVE-2026-67967** (`popen()` command injection). **There is no vendor patch**; the vendor was notified and had not responded at publication. **Why it matters:** A hardcoded key described as cross-product means one extracted string potentially unlocks a family of devices, not one model — and with no patch and WAN-facing exposure, the only mitigation is not running the device. > Affected firmware: `US_W20EV5.0qu_V16.01.0.6(2782)_CN&EN_TDE01.bin`. [`🔗 NVD CVE-2026-67965`](https://nvd.nist.gov/vuln/detail/CVE-2026-67965) · [`🔗 Disclosure repo`](https://github.com/H0111mes/Tenda-W20E-Vulnerability-Disclosure) --- ## 14. VibeWorlding — frontier models score under 60% building 3D worlds; a 30B open model wins - **Velocity:** ▮▮ rising - **Source:** arXiv · #3 on HF Papers · ~4d ago (~04:03 UTC+8) - **Tags:** `3d` `multimodal` `agents` `rl` `benchmarks` **VibeWorlding** (arXiv:2608.15265, Ning et al., submitted Aug 15) benchmarks and trains agents that build interactive 3D worlds end-to-end — inferring user intent, planning layouts, invoking 3D tools, and reflecting on multimodal feedback across multiple turns. **VWE-BENCH** supplies 2,616 curated 3D assets, 323 human-annotated seed worlds, and 6,828 reverse-synthesized multimodal queries, split into verified queries with ground truth and unverified queries scored by rubric. The finding: frontier MLLMs "are far from solving" the task, with **even GPT-5.5 and Qwen3.8-Max below 60% success**, and the named bottleneck is precise 3D editing rather than generation. After RL post-training in **VibeWorlding-Gym** (a sandbox with rubric-based verifier), **VibeWorlder-8B matches frontier models and VibeWorlder-30B-A3B takes the best overall Pass@1 of everything evaluated.** **Why it matters:** Another instance of the pattern the top of today's feed keeps circling — environment-grounded RL on a small open model beating closed frontier models on a task that needs tool use and self-correction, not raw knowledge. > The gym exposes asset retrieval, editing, and render as tool calls, which is why the bottleneck localizes so cleanly to the editing step. [`🔗 arXiv:2608.15265`](https://arxiv.org/abs/2608.15265) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.15265) --- ## 15. Letta ships an Agent SDK — the Claude Agent SDK, made stateful and model-agnostic - **Velocity:** ▮ steady - **Source:** Hacker News (new) · Letta · ~3h ago (~04:03 UTC+8) - **Tags:** `agents` `memory` `sdk` `stateful` `typescript` **Letta** (formerly MemGPT, Apache-2.0, 24.3k stars) released an **Agent SDK** for building "stateful, persistent agents that keep their identity, memory, and experience across models, machines, and interfaces." The framing from Letta's own engineer is direct: they "adapted magnificent work from the Anthropic team on the Claude Agent SDK, but we've made it stateful, model-agnostic, and work with cloud or local agents." The claimed payoff is agents that "passively learn through the act of doing" — deployed in Linear, an agent starts understanding Linear — plus agents that extend themselves by writing Agent SDK code, and custom interfaces (they forked Signal Desktop into a Letta client). One shipped pattern: a triage workflow that **forks a primary engineering agent onto a cheaper model** to run at larger scale and lower cost. **Why it matters:** The Claude Agent SDK is becoming the de-facto shape for agent harnesses; Letta's move is to keep the ergonomics and swap the stateless assumption underneath — which is exactly where multi-session agents break. > Caveat: the `letta-ai/letta` repo is now a landing page (active code moved to `letta-ai/letta-code`, V1 server preserved on the `archive` branch), and no dated Agent SDK release appears in its GitHub Releases — the announcement is a personal engineering post, not a versioned changelog. [`🔗 Letta Agent SDK announcement`](https://cameron.leaflet.pub/3mteywuetbs2i) · [`🔗 letta-ai/letta`](https://github.com/letta-ai/letta) --- ## 16. Shoehorn quantizes a model to the exact bytes of RAM you have left — 99.998% of budget - **Velocity:** ▮ steady - **Source:** Hacker News · 34 pts · ~8h ago (~04:03 UTC+8) - **Tags:** `quantization` `local-llm` `rust` `gguf` `open-source` **Shoehorn** (MIT, Rust, created Aug 13) inverts how quantization is usually chosen: instead of picking a preset that ignores your machine, it "starts from the memory you actually have, subtracts what inference itself needs, and solves a per-tensor mixed-precision assignment" against the remainder. The reported fits are absurdly tight — "routinely using **99.99%** of the budget, sometimes to the byte," with a worked example of **519.2 MiB of a 519.2 MiB budget (99.998% used, 13 KB slack)** for `unsloth/Qwen3-4B-GGUF`. The quantizer is "implemented from scratch in Rust — no llama.cpp code linked" and emits standard **GGUF v3**, with llama.cpp used only as the inference backend. `shoehorn ui` measures the machine, streams the fit, and reports the perplexity cost before you chat. **Why it matters:** Preset quant levels (Q4_K_M and friends) are a coarse guess at a hardware question. Solving the assignment against measured free memory is the obviously-correct framing, and shipping standard GGUF means nothing downstream has to change. > Targets macOS Apple Silicon, Linux x86-64 (NVIDIA/AMD), and Windows x86-64 (NVIDIA), with profiles from 8 GB Macs to 128 GB and context presets from 4k to 32k. Very young: 37 stars at time of check. [`🔗 Shoehorn`](https://notactuallytreyanastasio.github.io/shoehorn) · [`🔗 notactuallytreyanastasio/shoehorn`](https://github.com/notactuallytreyanastasio/shoehorn) --- ## 17. CVE-2026-71879 — a finished setup endpoint keeps handing out admin sessions - **Velocity:** ▮ steady - **Source:** NVD · CVSS 9.1 · ~1d ago (~04:03 UTC+8) - **Tags:** `security` `cve` `auth-bypass` `open-source` `research-infra` **CVE-2026-71879** (**CVSS v4 9.1**, disclosed Aug 18) is a **CWE-288** authentication bypass via alternate path in the **GBIF Integrated Publishing Toolkit (IPT)** below 3.3.4, the open-source tool institutions use to publish biodiversity datasets. The setup endpoint **`/setupInstallationComplete.do` keeps returning a `JSESSIONID` cookie for a user with administrative permissions even after setup is complete** — for as long as the server has not been rebooted since initial configuration. Fixed in **IPT 3.3.4** (released Aug 4); no in-the-wild exploitation reported. **Why it matters:** The bug class is the durable lesson: install-time endpoints that stay live post-install are a standing admin bypass, and "we finished setup" is not the same as "the setup route is disabled." Worth grepping your own first-run flows for. > Disclosed via Mandiant advisory MNDT-2026-0015. Affected instances are typically internet-exposed institutional data portals. [`🔗 NVD CVE-2026-71879`](https://nvd.nist.gov/vuln/detail/CVE-2026-71879) · [`🔗 GBIF IPT releases`](https://github.com/gbif/ipt/releases) --- ## 18. machine0 — persistent CPU and GPU VMs that an agent drives entirely from the CLI - **Velocity:** ▮ steady - **Source:** Launch HN · YC S26 · 38 pts · ~4h ago (~04:03 UTC+8) - **Tags:** `infrastructure` `gpu` `agents` `nixos` `mcp` **machine0** launched on HN with dedicated CPU/GPU VMs designed to be driven by agents: every operation is a CLI command with `--json` output, and there's a remote MCP server. Machines run **NixOS** (reproducible flakes, one-command rollbacks) or **Ubuntu** preloaded with Docker, Node, Python, Claude Code and Codex; each VM gets **a public IP and HTTPS at `.mac0.io`** with no NAT or tunnels, across five regions. **Profiles inject MCP servers, credentials, prompts and env vars** so agent tools pick them up automatically. Pricing is per-minute from **$0.013/hr for CPU and $0.836/hr for GPU**, up to **8× H200 at $39.336/hr** (H100, H200, L40S, MI300X, RTX 4000/6000 Ada available); suspending freezes state and **stops billing**, leaving only image storage at $0.078/GB/month. **Why it matters:** Agent runtimes keep converging on "give the agent a real computer." The differentiator here is economic — suspend-to-zero billing plus reproducible NixOS images makes a long-lived agent workspace cheap to keep and cheap to recreate. > Positioned against burstable shared instances: dedicated resources, static IPs, and golden-image cloning rather than per-run container spin-up. [`🔗 machine0`](https://machine0.io) · [`🔗 Launch HN thread`](https://news.ycombinator.com/item?id=49348136) --- ## 19. DDR5 is now ~5× last year's price — and server DRAM is forecast up another 13–18% this quarter - **Velocity:** ▮ steady - **Source:** TrendForce · +486% YoY · ~2d ago (~04:03 UTC+8) - **Tags:** `hardware` `memory` `supply-chain` `ai-infra` `pricing` Consumer DRAM pricing has fully decoupled from its historical trend as AI-datacenter and HBM demand pulls fab capacity away from commodity parts. **TrendForce** (Aug 17) reports Germany's DDR5 retail price index climbing from **445% to 486% year-over-year in August** — a typical kit now around **4.9× last year's price** — while in Shenzhen's Huaqiangbei market **DDR5 24Gb jumped 14.29% week-over-week to $48**, 16Gb to $40, and **DDR4 8Gb 3200 rose 12.82% WoW to $22**. TrendForce forecasts **server DRAM contract prices up 13–18% quarter-over-quarter in 3Q26**, calls the market undersupplied, and expects the server DRAM shortage to run into 2027. Tom's Hardware's Aug 18 headline puts the retail end at **128 GB of DDR5 for $3,399**. **Why it matters:** Two decades of "memory gets cheaper" is unwinding inside twelve months, and it lands directly on developers — local inference rigs, self-hosted databases, and CI fleets all budget against RAM that no longer behaves. > Sourcing note: the Tom's Hardware article body is paywalled, so only its headline figure is cited; the percentage and per-chip numbers come from the TrendForce report, which we read in full. [`🔗 TrendForce`](https://www.trendforce.com/news/2026/08/17/news-germany-ddr5-prices-near-5x-yoy-in-august-china-reportedly-sees-14-wow-jump-as-global-rally-continues/) · [`🔗 Tom's Hardware`](https://www.tomshardware.com/pc-components/ram/memory-prices-climb-500-percent-in-12-months-up-to-10x-the-lowest-ever-tracked-prices-128gb-of-ddr5-now-usd3-399) --- ## 20. Claude Code's +50% weekly limits expire Aug 31 — check `/usage` before you plan a sprint - **Velocity:** ▮ steady - **Source:** Hacker News · 235 pts · ~5h ago (~04:03 UTC+8) - **Tags:** `claude-code` `limits` `pricing` `agents` `tooling` Anthropic's help centre confirms that the promotion raising **Claude Code weekly usage limits by 50%** — running since **May 13, 2026** and already extended once — ends at **11:59 PM PT on August 31, 2026**, after which "weekly usage limits in Claude Code return to their standard levels." It applies to **Pro, Max and Team** plans plus legacy seat-based Enterprise, excludes Free and consumption-based Enterprise seats, is applied automatically, and covers **Claude Code only** (CLI, IDE extensions, desktop, web). **5-hour limits are explicitly unaffected.** The page publishes no baseline numbers — `/usage` in the CLI is the only way to see your actual figures. **Why it matters:** A third of a heavy user's weekly headroom disappears on a known date. Anyone whose agent workflow was tuned against the promotional ceiling has twelve days to re-measure, and the HN thread is already full of users saying they sit at 90–100% of a $200/month plan. > The reversion is a return to standard limits, not a plan or billing change — but it is the kind of quiet capacity cut that only shows up mid-task. [`🔗 Anthropic support`](https://support.claude.com/en/articles/15910845-claude-code-may-august-2026-weekly-limits-promotion) · [`🔗 HN discussion (235 pts)`](https://news.ycombinator.com/item?id=49348751) --- ## 21. Mojo's compiler goes Apache-2.0 — the last closed piece of Lattner's language opens at ModCon - **Velocity:** ▮▮▮ trending - **Source:** Modular blog · modular/modular 27.1k stars · ~1d ago (~20:03 UTC+8) - **Tags:** `mojo` `compiler` `open-source` `apache-2.0` `llvm` On **Aug 18, 2026**, opening ModCon, Modular announced that **Mojo🔥 is "now fully open source under the Apache 2.0 license (with LLVM exceptions)"** — the compiler, the tooling, "and everything else you need to build the language" now live in the `modular/modular` monorepo (**27,123 stars, 2,941 forks**, pushed Aug 18, built with Bazel). This completes a staged three-year opening: the standard library went open in 2024, the MAX kernels in 2025, and now the compiler itself. When this feed covered **Mojo 1.0's stable release on Aug 12**, the compiler was only *pledged* to open "later in 2026" — that pledge landed six days later. **Why it matters:** A closed compiler was the standing objection to betting infrastructure on Mojo, and the opening survived Qualcomm's acquisition of Modular. A language pitched as a portable CUDA alternative now has no proprietary component left in its build path. > GitHub's license detector still reports `NOASSERTION` on the repo because the LLVM exceptions defeat auto-detection — the Apache-2.0 claim is Modular's own, stated in the announcement, which we read. Contributions to the compiler are not yet being accepted; Modular targets end of year. [`🔗 Mojo is now open source`](https://www.modular.com/blog/mojo-open-source) · [`🔗 modular/modular`](https://github.com/modular/modular) --- ## 22. Oracle ships 943 patches in one day — an unauthenticated SMTP RCE sits in E-Business Suite - **Velocity:** ▮▮▮ trending - **Source:** Oracle Security Alerts · CVSS 9.8 · ~1d ago (~20:03 UTC+8) - **Tags:** `security` `cve` `oracle` `rce` `patch-cycle` Oracle published its **August 2026 Critical Security Patch Update on Aug 18** (Rev 1, initial release), and by its own count the advisory "contains **943 new security patches** across the product families listed below." The standout is **CVE-2026-70926** in **Oracle Workflow's Workflow Notification Mailer**: **CVSS 9.8**, attack vector **SMTP**, remotely exploitable **without authentication**, affecting **E-Business Suite 12.2.3–12.2.15**, with High confidentiality, integrity and availability impact. It isn't alone — **CVE-2026-60782** (Oracle Payments, File Transmission, HTTP) is also **9.8 and pre-auth** on the same versions, and **CVE-2026-71065** in **Helidon Imperative Web Server 3.2.18** scores **9.3** with a *changed* scope. Of the **120 patches for E-Business Suite, 27 are remotely exploitable without credentials**; Fusion Middleware takes 262 and Hyperion another 262 (107 remotely exploitable). **Why it matters:** EBS runs financials, HR and procurement for large enterprises, and a pre-auth 9.8 reached over the *mail* path is a listener most teams never model as attack surface. > Sourcing note: every figure here is read directly from Oracle's own CSPU page. Third-party counts circulating for this cycle ("925 CVEs / 154 critical") do **not** match Oracle's stated 943 patches — we report Oracle's number. The advisory itself warns that "attackers have been successful because targeted customers had failed to apply available Oracle patches." [`🔗 Oracle CSPU August 2026`](https://www.oracle.com/security-alerts/cspuaug2026.html) · [`🔗 NVD CVE-2026-70926`](https://nvd.nist.gov/vuln/detail/CVE-2026-70926) --- ## 23. Linux 7.2 lands with cache-aware scheduling — and a "fair" DRM scheduler reverted at the buzzer - **Velocity:** ▮▮▮ trending - **Source:** kernel.org · mainline 7.2 · ~3d ago (~20:03 UTC+8) - **Tags:** `linux-kernel` `scheduler` `usb4` `amdgpu` `kernel-release` **kernel.org now lists `mainline: 7.2`, dated 2026-08-16** — Linus Torvalds tagged it on schedule, and it becomes the base for Ubuntu 26.10. Headline additions per Phoronix: **Cache Aware Scheduling** (aggregating tasks that share data into the same last-level-cache domain), Intel's **USB4STREAM** host-to-host transfer protocol, initial **AMDGPU HDMI 2.1 FRL** support, I/O performance gains on both AMD and Intel, Intel Arc B390 improvements, and faster `poll()`. The final week was busier than usual: a **revert back to the DRM FIFO scheduler** after the new "fair" default produced a regression, late sound-device quirks, and a `tlbi=ipi` boot option merged on release day. **Why it matters:** This is the kernel baseline most 2026 distro and cloud images will inherit, and cache-aware scheduling is the kind of change that silently shifts throughput on multi-tenant boxes without any userspace opt-in. > Not an LTS release — `stable: 7.1.8` and `longterm: 6.18.44` both date to 2026-08-09. Feature list is attributed to Phoronix's release write-up; the release date and channel status come from kernel.org's front page directly. [`🔗 kernel.org`](https://www.kernel.org/) · [`🔗 Phoronix — Linux 7.2 released`](https://www.phoronix.com/news/Linux-7.2-Released) --- ## 24. Cumora — 2,469 stars in two days for a team chat where Claude Code is a coworker - **Velocity:** ▮▮▮ trending - **Source:** GitHub · +2,469 stars in 2 days · ~1d ago (~20:03 UTC+8) - **Tags:** `agents` `team-chat` `byoa` `claude-code` `typescript` **yetone/cumora** (MIT, TypeScript, **created Aug 17**, pushed Aug 18, **2,469 stars / 272 forks**) is cross-platform team chat where AI agents are first-class participants — "same roster, same DMs, same group conversations, same Kanban board and calendar." Per the README, agents "hold personas and memory, claim work, coordinate with each other without colliding, send and receive real email." Two brain paths: **Cumora Cloud** runs each agent in a managed per-agent pod on a multi-hop tool-calling loop over the OpenAI Responses API, while **BYOA** (`npx cumora agent computer`) pairs your own Mac or VPS so the agent's brain becomes **your local Claude Code or Codex CLI on your own subscription — the server never sees your provider keys**. Stack is Electron/PWA/mobile over Express + Postgres + Redis. **Why it matters:** The trigger is authorship, not the star count — yetone wrote `avante.nvim`, so this arrived with an audience. The interesting design choice is BYOA: agent collaboration you self-host against your existing model spend, rather than a vendor metering tokens in the middle. > Two days old and invite-only. `cumora.ai` returned HTTP 403 to server-side fetching (client-rendered), so every claim above is taken from the repository README and GitHub API, both read directly. [`🔗 yetone/cumora`](https://github.com/yetone/cumora) · [`🔗 Cumora releases`](https://github.com/yetone/cumora-releases/releases/latest) --- ## 25. OpenZFS OZ-1 — namespace-local CAP_SYS_ADMIN is accepted as authority over host pools, unpatched - **Velocity:** ▮▮ rising - **Source:** oss-security · full disclosure · ~3d ago (~20:03 UTC+8) - **Tags:** `security` `openzfs` `containers` `privilege-escalation` `unpatched` Researcher **Erica Windisch** went to full disclosure on **oss-security, Sun 16 Aug 2026 14:32 -0400**, after notifying CERT on **8/12/2026**: "I am hopeful that upstream patches and remediation guidance will be available soon. I have been sitting on these for a bit." The core defect, **OZ-1**, is stated plainly in the report: OpenZFS's `zfs_secpolicy_config()` uses **`ns_capable(cr->user_ns, CAP_SYS_ADMIN)`**, "which accepts namespace-local `CAP_SYS_ADMIN` as authority for host-pool operations. The correct check is `CAP_SYS_ADMIN` in the **initial** user namespace." Any user can obtain namespace-local `CAP_SYS_ADMIN` by creating a user namespace and mapping themselves to uid 0 inside it. The report covers **two interacting groups** — authorization (OZ-1, OZ-2) and parser defects (OZ-3…OZ-8) that "trust attacker-controlled on-disk lengths, indices, or graph structure" — and its upstream patch audit "confirms every OZ finding remains **UNFIXED** at upstream master HEAD `3020c18c`," with only OZ-7 holding an open, contested PR (#18620). **Why it matters:** OpenZFS is out-of-tree, so as the report notes, "CVE decisions belong with the OpenZFS project and its vendors/CNA, not the Linux kernel CVE team" — there is no CVE, so scanners are blind to it. Verdicts were reproduced on stock **TrueNAS SCALE 25.04.2.4, Proxmox VE 8.x, IncusOS and Unraid** appliance guests. > Read the preconditions before panicking: **Docker's default capability set omits `CAP_SYS_ADMIN`, so `--device /dev/zfs` alone fails with `EPERM`** — the report records that as "a 0.0 honest negative." `--privileged` or `--cap-add SYS_ADMIN` reproduces OZ-1. The author's own framing is that hardening `/dev/zfs` to `0660` is "defense-in-depth, not a substitute for correct in-kernel authorization." The `hotmolts.com` write-up circulating alongside this is client-rendered and served none of the technical content server-side, so we cite the mailing-list post we actually read. [`🔗 oss-security disclosure`](https://www.openwall.com/lists/oss-security/2026/08/16/5) · [`🔗 oss-security thread reply`](https://www.openwall.com/lists/oss-security/2026/08/16/6) --- ## 26. MegaParts — autoregressive 3D generation reaches 300 parts and 256k-token sequences - **Velocity:** ▮▮ rising - **Source:** arXiv · 515 stars on HF Papers · ~5d ago (~20:03 UTC+8) - **Tags:** `3d-generation` `autoregressive` `tokenizer` `computer-vision` `mesh` **MegaParts** (arXiv:2608.14783, submitted Aug 14, cs.CV) scales part-aware 3D object generation by attacking the token budget rather than the model. It pairs structured sequence modeling with a **token-efficient vector-quantized shape tokenizer** that learns discrete latents of part-level geometry under an explicit minimize-tokens-subject-to-reconstruction objective, enabling adaptive-length tokenization; a language model then emits object bounding boxes, part bounding boxes and part shape tokens as **one unified structured sequence**. Combined with a long-context training strategy, the abstract reports the formulation "scales to objects with up to **300 parts** and sequence lengths up to **256k tokens**," preserving compositional structure and fine-grained part-level control, with higher mesh quality than autoregressive and diffusion baselines. **Why it matters:** Diffusion has been the assumed winner in 3D generation. A token-efficient autoregressive path that holds 300 parts in one sequence puts LLM-native modeling back in play for CAD, simulation and game-asset pipelines where *part structure* — not just surface realism — is the deliverable. > Mesh-quality comparisons are against baselines the authors selected, and no independent reproduction exists yet. The 515 figure is the Hugging Face Papers upvote count, not a citation metric. [`🔗 arXiv:2608.14783`](https://arxiv.org/abs/2608.14783) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.14783) --- ## 27. MOSS-VL — an 11.3B open VLM that keeps seeing while it is still talking - **Velocity:** ▮▮ rising - **Source:** arXiv · 436 stars on HF Papers · ~4d ago (~20:03 UTC+8) - **Tags:** `vision-language` `streaming` `realtime` `open-weights` `multimodal` **MOSS-VL** (arXiv:2608.15045, submitted Aug 15, OpenMOSS) treats real-time interaction — "perceiving while it speaks" — as a first-class capability rather than a latency optimization. The design is co-planned across the stack: **the language decoder attends to vision only through gated cross-attention, so the model can see incoming frames while generating**; a synthesized interaction corpus supervises "when to speak, when to stay silent, and when to revise"; and a staged curriculum concentrates real-time training into one final stage. Among **open-source streaming models** it posts the best average on three of four benchmarks (second on the fourth) and sweeps the proactive-behavior subsets — **66.0 vs 37.5** for the best baseline on OmniMMI Proactive Alerting. Because visual tokens sit outside the decoded sequence, its time-to-first-token advantage over same-backbone Qwen3-VL-8B **widens from 2.8× to 5.1×** as visual context grows. All five checkpoints, the training curriculum and real-time inference code are released. **Why it matters:** Streaming multimodal inference is the missing piece for voice+vision assistants, and "visual tokens outside the decoded sequence" is a concrete architectural reason the TTFT gap *widens* with context instead of collapsing. > Benchmark numbers are author-reported; the comparison set is explicitly open-source streaming models, not frontier closed VLMs. The project-page URL in the abstract is a placeholder and was not opened. [`🔗 arXiv:2608.15045`](https://arxiv.org/abs/2608.15045) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.15045) --- ## 28. PostgreSQL 19 Beta 3 brings property graphs in-core — alongside a 28-CVE patch day - **Velocity:** ▮▮ rising - **Source:** postgresql.org · 28 CVEs · ~6d ago (~20:03 UTC+8) - **Tags:** `postgresql` `database` `sql-pgq` `graph-queries` `security` The PostgreSQL Global Development Group shipped **19 Beta 3 on 2026-08-13**, together with updates to **18.6, 17.11, 16.15, 15.19 and 14.24** — a combined release that "fixes **28 security vulnerabilities**," including **CVE-2026-6464** (psql `COPY FROM STDIN` early failure processes data lines as psql commands, CVSS v3.1 **8.1**), CVE-2026-6469 and CVE-2026-6470. The headline v19 feature, committed by Peter Eisentraut, is **SQL Property Graph Queries (SQL/PGQ)** to the ISO/IEC 9075-16:2023 standard: a **`GRAPH_TABLE` table function** for graph pattern matching, **`CREATE`/`ALTER`/`DROP PROPERTY GRAPH`** DDL, new system catalogs and information-schema views, a `psql \dG` command, and `pg_get_propgraphdef()` for `pg_dump`. **Why it matters:** Property graphs defined over existing tables — no data copy, no second datastore — removes a standing reason to bolt a graph database onto a Postgres shop. The same-day 28-CVE patch across five supported majors is the more urgent half. > Beta 3 is a bugfix iteration: SQL/PGQ was feature-frozen earlier in the v19 cycle, so the Aug 13 event is a beta refresh plus a large security day, not a feature debut. GA is expected in the autumn. [`🔗 PostgreSQL release announcement`](https://www.postgresql.org/about/news/postgresql-186-1711-1615-1519-1424-and-19-beta-3-released-3365/) · [`🔗 depesz — SQL/PGQ`](https://www.depesz.com/2026/07/31/waiting-for-postgresql-19-sql-property-graph-queries-sql-pgq/) --- ## 29. Chrome patches 15 flaws — and credits "OpenAI Codex Security" for one of them - **Velocity:** ▮▮ rising - **Source:** Chrome Releases · 15 security fixes · ~1d ago (~20:03 UTC+8) - **Tags:** `chrome` `browser-security` `ai-security-research` `v8` `webgl` Chrome's stable channel moved to **151.0.7922.169/.170 (Windows, Mac) and .169 (Linux) on Tuesday, Aug 18, 2026**, with **15 security fixes**. Two are rated **Critical** — **CVE-2026-76034** (buffer overflow in WebGL) and **CVE-2026-76036** (buffer overflow in Dawn) — both reported by Google. The more interesting line in the bulletin is the last one: **CVE-2026-76045, a use-after-free in WebGL, "Reported by OpenAI Codex Security (amyb) on 2026-08-05."** Also fixed: two V8 type-confusions (CVE-2026-76047, CVE-2026-76038, both High, reported by external researchers ywatanabee and un3xploitable && GF), an ANGLE buffer overflow, a use-after-free in Browser, a USB race condition, and a Skia information leak. **Why it matters:** An AI lab's security team appearing in a Chrome credit line — for a real use-after-free in a memory-unsafe graphics path — is the concrete version of a claim usually made in blog posts. It also rhymes with item 7 in this feed: agent-run audits are now producing findings that ship in vendor advisories. > Correcting a figure in circulation: the two V8 type-confusions are rated **High**, not Critical — the Critical pair are the WebGL and Dawn buffer overflows. Severities and credits here are quoted from Google's own bulletin, not a third-party CVSS mapping. No exploitation in the wild was flagged at publication. [`🔗 Chrome Releases — Stable Channel Update`](https://chromereleases.googleblog.com/2026/08/stable-channel-update-for-desktop_0826575033.html) · [`🔗 Chrome security page`](https://www.google.com/chrome/browser/privacy/#security) --- ## 30. macOS Harness — six primitives, one Python process, and the agent writes the rest - **Velocity:** ▮▮ rising - **Source:** GitHub · +428 stars in 2 days · ~2d ago (~20:03 UTC+8) - **Tags:** `computer-use` `macos` `agents` `python` `harness` **browser-use/macos-harness** (MIT, Python, **created and pushed Aug 17**, **428 stars / 26 forks**) is deliberately the thinnest possible computer-use layer, from the org behind browser-use. The README's framing: "The agent writes what is missing, mid-task. No framework, no recipes, no rails. One Python process connected directly to macOS, your real browser, and your files." The model gets a small primitive set — see, key, type, click, plus accessibility and script access — and when no helper exists for a task it **writes the missing logic in ordinary Python during the run** rather than waiting for an app-specific tool to be added. Onboarding is a single paste-into-Codex-or-Claude-Code prompt that installs via `uv` on Python 3.12, registers a skill via `macos-harness skill`, runs `macos-harness doctor` for permission checks, and verifies by capturing a running app. **Why it matters:** Desktop automation keeps breaking because per-app recipes rot. Composing raw primitives and generating glue at runtime is the structural fix for the long tail of GUI work that has no API — and it's the same "re-plan from the live interface" thesis as UI-Mate (item 9), shipped as a 400-line-of-setup tool instead of a trained model. > Two days old, no published benchmarks, and "no rails" is the security posture as well as the design: it inherits the full macOS Accessibility and AppleScript permission surface. Claims are from the README and GitHub API, both read directly. [`🔗 browser-use/macos-harness`](https://github.com/browser-use/macos-harness) · [`🔗 browser-use`](https://browser-use.com) --- ## 31. OpenAI's Assistants API shuts down Aug 26 — seven days, and no automated migration - **Velocity:** ▮▮ rising - **Source:** OpenAI platform docs · 7-day deadline · ~ongoing (~20:03 UTC+8) - **Tags:** `openai` `api` `deprecation` `migration` `breaking-change` OpenAI's migration guide states it plainly: "After achieving feature parity in the Responses API, we've deprecated the Assistants API. **It will shut down on August 26, 2026.**" The object model does not map mechanically — the docs' own before/after table renames **`Assistants` → `Prompts`** ("Prompts hold configuration (model, tools, instructions) and are easier to version and update"), **`Threads` → `Conversations`**, `Runs` → `Responses`, and `Run steps` → `Items`, and the change "lets you manage conversations instead of passing back `previous_response_id`." **Why it matters:** Seven days out, this is the most concrete deadline on any developer calendar this week. A rename table is not a codemod: Threads carry live conversation state, and there is no backfill tool that moves it into Conversations for you. > Long-scheduled rather than freshly announced — the deprecation dates to 2025. Its news value is the deadline, now inside the window where an unmigrated integration breaks in production. [`🔗 OpenAI Assistants migration guide`](https://developers.openai.com/platform/assistants/migration) · [`🔗 platform.openai.com`](https://platform.openai.com/docs/assistants/migration) --- ## 32. Google shut off all three Imagen 4 endpoints on Aug 17 — the replacement is a different API shape - **Velocity:** ▮ steady - **Source:** Gemini API docs · 3 models retired · ~2d ago (~20:03 UTC+8) - **Tags:** `google` `gemini-api` `deprecation` `image-generation` `breaking-change` Google's Gemini API deprecation table now lists **`imagen-4.0-generate-001`, `imagen-4.0-ultra-generate-001` and `imagen-4.0-fast-generate-001`** — all released June 24, 2025 — with a **shutdown date of August 17, 2026** and **`gemini-3.1-flash-image` as the recommended replacement** for all three. The replacement is not a model-ID swap: `gemini-3.1-flash-image` is a general Gemini image model reached through the current image-generation surface rather than the dedicated Imagen endpoint, so request and response shapes differ. **Why it matters:** This one already fired. Any app still calling an Imagen 4 endpoint is failing at runtime right now, and the fix is a code migration rather than a config line — the least forgiving kind of deprecation. > Sourcing note: third-party write-ups claim specific removed parameters (`negativePrompt`, `numberOfImages`, `personGeneration`) and higher per-image token pricing. We could not confirm those on Google's own pages and therefore do not assert them; the shutdown dates and replacement mapping come straight from the deprecations table. [`🔗 Gemini API deprecations`](https://ai.google.dev/gemini-api/docs/deprecations) · [`🔗 Gemini API image generation`](https://ai.google.dev/gemini-api/docs/image-generation) --- ## 33. Con Kolivas revives -ck after a decade — linux-7.2-ck1 ships MuQSS v0.31 - **Velocity:** ▮ steady - **Source:** GitHub · tag v7.2-ck1 · ~2d ago (~20:03 UTC+8) - **Tags:** `linux-kernel` `muqss` `scheduler` `desktop-latency` `out-of-tree` **`ckolivas/linux` published tag `v7.2-ck1` ("linux-7.2-ck1") on 2026-08-17** — the -ck desktop-latency patchset rebased onto the mainline kernel released the day before. The release notes list **"MultiQueue Skiplist Scheduler v0.31"** alongside a set of latency-oriented defaults: **default Hz set to 100 in combination with MuQSS and -ck patches**, **preemptible kernel made the default**, hrtimer granularity and minimum hrtimeout made configurable via sysctl (default granularity 100µs, minimum timeout 500µs), high-resolution timeout variants of `schedule_timeout`, and `nohz_full` no longer picked up as a default config option. A `v7.1-ck3` tag landed the same day. **Why it matters:** MuQSS was the best-known argument that mainline's scheduler optimizes throughput at the desktop's expense, and it went quiet for years. Its return as a maintained rebase against a current kernel gives that argument a testbed again. > Explicitly out-of-tree and not aimed at mainline; -ck has historically regressed server and many-core workloads. Details above are quoted from the GitHub release notes, which we read — we have not verified secondary claims about I/O-aware scheduling or LLM-assisted development, and MuQSS is a skiplist scheduler, not an EEVDF derivative as some coverage states. [`🔗 ckolivas/linux — v7.2-ck1`](https://github.com/ckolivas/linux/releases) · [`🔗 Phoronix — Con Kolivas patches`](https://www.phoronix.com/news/Con-Kolivas-Linux-Patches-2026) --- ## 34. CVE-2026-21580 — unauthenticated stored XSS in Confluence escalates to a higher-privileged user - **Velocity:** ▮ steady - **Source:** NVD · CVSS 8.6 · ~1d ago (~20:03 UTC+8) - **Tags:** `security` `cve` `atlassian` `confluence` `stored-xss` **CVE-2026-21580** (published Aug 18) is a combined **Stored XSS, privilege escalation and security misconfiguration** flaw in **Confluence Data Center and Server**, carrying a **CVSS score of 8.6**. Per the NVD description, it "allows an **unauthenticated attacker** to execute arbitrary HTML or JavaScript code on a victims browser, perform actions as a higher-privileged user, and to get into the system utilizing loopholes exposed from security best-practices being overlooked." It was introduced across a long tail of releases — 7.1.1, 7.4.0, 7.13.0, 7.17.0, 7.19.0, 8.0.0, 8.5.0, 8.9.0, 9.0.1, 9.1.0, 9.2.0, 9.3.1, 9.4.0, 9.5.1, 10.0.2, 10.1.0 and 10.2.0 — with fixes at **9.2.21 or greater** and **10.2.13 or greater**. **Why it matters:** Confluence is where organizations keep runbooks, credentials-adjacent notes and architecture docs. Unauthenticated stored XSS that executes in an admin's session is a short path from "internal wiki" to "administrative takeover." > Reported through Atlassian's bug bounty; no public exploit at disclosure. Note the affected-version list enumerates *introduction* points across many branches, not a contiguous range — check your exact build against the fixed versions rather than eyeballing it. [`🔗 NVD CVE-2026-21580`](https://nvd.nist.gov/vuln/detail/CVE-2026-21580) · [`🔗 OpenCVE CVE-2026-21580`](https://app.opencve.io/cve/CVE-2026-21580) --- ## 35. Palmyra x6 — a tool-use model post-trained on 626 trajectories and a single epoch - **Velocity:** ▮ steady - **Source:** arXiv · v2 Aug 18 · ~1d ago (~20:03 UTC+8) - **Tags:** `agentic` `tool-use` `post-training` `moe` `benchmarks` **Palmyra x6** (arXiv:2608.16620, Writer, submitted Aug 17, v2 Aug 18) is an agentic tool-use model built by post-training a Mixture-of-Experts base with **Anchored Supervised Fine-Tuning** on "a compact corpus of verified, synthetic tool-use trajectories, optimized with a Muon + Adam hybrid." The recipe is the finding: the paper calls it "deliberately conservative and deliberately controlled — **626 trajectories, a single epoch, a low learning rate, and a KL anchor to the frozen base**." It reports substantial gains over Writer's previous default agent model and "scoring the highest on BFCL Core at **0.785** and posts the highest six-benchmark mean of the cohort," with competitive-or-leading bias and safety evaluations. **Why it matters:** It is a clean data point for the "less is more" direction in post-training — a KL anchor plus a few hundred *verified* trajectories beating data-hungry recipes, which makes competent tool-calling reachable without a trajectory farm. > A 12-page vendor technical report. "Highest in cohort" is relative to a comparison set the authors chose, and no independent reproduction exists. [`🔗 arXiv:2608.16620`](https://arxiv.org/abs/2608.16620) · [`🔗 Writer`](https://writer.com) --- ## 36. HarnessEval-W — world-model benchmarking rebuilt as an evidence tree instead of a score - **Velocity:** ▮ steady - **Source:** arXiv · 132 stars on HF Papers · ~2d ago (~20:03 UTC+8) - **Tags:** `world-models` `evaluation` `benchmarks` `agents` `llm-judge` **HarnessEval-W** (arXiv:2608.16859, submitted Aug 17) argues that "a benchmark should deliver more than a scalar score: what makes an evaluation trustworthy is the reasoning that justifies the score" — especially for world models, "where judging a rollout requires understanding whether physics, causality, and world state evolve correctly," something humans spot naturally but existing metrics compute brute-force. It replaces the fixed rubric with an agentic workflow: interpret the case, decompose it into measurable subproblems, dispatch specialized sub-agents with diagnostic tools, then have a parent agent validate the gathered evidence and summarize a verdict — turning "every evaluation into a transparent **evidence tree** whose complete reasoning chain justifies the result." Applied to **18 representative world models over 330 evaluation cases**, with the full pipeline open-sourced as a live benchmark. **Why it matters:** Generated video and robotic simulators are judged today by scores that can't say *why* a rollout is wrong. Making physics and causality violations auditable is the precondition for trusting either in a pipeline. > "Closely align with human preferences" is the authors' own characterization; the alignment study is not independently replicated. The project-page URL in the abstract is a placeholder and was not opened. [`🔗 arXiv:2608.16859`](https://arxiv.org/abs/2608.16859) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.16859) --- ## 37. SoLo — let a static musl binary dlopen the host's glibc GPU driver - **Velocity:** ▮ steady - **Source:** Hacker News · 74 pts · ~4d ago (~20:03 UTC+8) - **Tags:** `linux` `static-binaries` `elf` `vulkan` `musl` **pg83/solo** (MIT, C++, **created Aug 14**, pushed Aug 17, **283 stars**) attacks a specific, long-standing wall in static Linux deployment. Its README states the problem exactly: "Static binaries are a wonderfully boring way to deploy software on Linux: one file, no dependencies, nothing to break… The boredom ends the moment the application needs the GPU: Vulkan and OpenGL drivers are supplied by the host as shared objects, usually built against glibc, and **a fully static musl binary cannot normally `dlopen()` them**." SoLo crosses that boundary by providing "a `dlfcn`-style source API backed by its own **ELF loader (x86-64 and aarch64)** and a **glibc ABI bridge implemented on top of musl**" — no container, no AppImage, and no second libc in the process. **Why it matters:** "Ship one boring static file" has been available to everything except GPU software. Removing that exception matters for reproducible builds and supply-chain-legible distribution, where a container image is a much larger thing to trust than a single binary. > Five days old with no tagged release, and it depends on the author's own IX source-first build system. Description and mechanism are quoted from the README, read directly. [`🔗 pg83/solo`](https://github.com/pg83/solo) · [`🔗 IX build system`](https://github.com/pg83/ix) --- ## 38. OwnMem — agent memory as reviewable Markdown, with zero model calls at recall - **Velocity:** ▮ steady - **Source:** GitHub · npm `ownmem@0.2.0` · ~1d ago (~20:03 UTC+8) - **Tags:** `agent-memory` `git` `bm25` `local-first` `coding-agents` **grpcer/ownmem** (Apache-2.0, JavaScript, Node ≥20, **created Aug 16**, pushed Aug 18, 53 stars) inverts the standard agent-memory stack. Its subtitle is the thesis — "**Git-Native Project Memory for AI Coding Agents: Repo-owned. Deterministic. Reviewable.**" Curated decisions, constraints and debugging lessons live as Markdown inside the repository, so memory is diffed in pull requests, travels with a clone and rolls back with the code. Recall runs on a deterministic BM25-family ranker rather than embeddings: the repo's own badges advertise **recall P95 of 2.46 ms and model calls: 0**. One memory set is claimed to serve Claude Code, Codex, Antigravity, Cursor, Gemini CLI and Grok CLI. The npm registry confirms **`ownmem@0.2.0`**, first published 2026-08-16, four versions to date. **Why it matters:** Most agent memory bolts on an embedding model and a vector store, which makes it opaque, non-deterministic and impossible to review. Plaintext plus a deterministic ranker is the shape that survives code review — and it is the exact opposite bet from this morning's vector-index item (turbovec, item 3). > Very young and single-maintainer: 53 stars, 1 fork, four days old. The 2.46 ms P95 is the project's own published benchmark, not independently reproduced — we verified the package and version on the npm registry and the claims in the README, not the timing. [`🔗 grpcer/ownmem`](https://github.com/grpcer/ownmem) · [`🔗 npm registry — ownmem`](https://registry.npmjs.org/ownmem) --- ## 39. OpenLogi — a Rust, local-first Logitech Options+ replacement tops Hacker News - **Velocity:** ▮▮▮ trending - **Source:** Hacker News · 908 pts · #1 front page (~20:03 UTC+8) - **Tags:** `rust` `hidpp` `peripherals` `local-first` `open-source` **AprilNEA/OpenLogi** (9,500 stars, 809 commits, dual MIT/Apache-2.0) is a native, local-first replacement for Logitech Options+ — it talks to HID++ peripherals directly over Logi Bolt, Unifying, Bluetooth or USB, with no account and no telemetry. Three Rust components do the work: a GPUI desktop app (interactive device diagram, per-button action picker, DPI and SmartShift control, RGB, per-app profiles), a background agent that owns the OS input hook and device I/O, and a CLI for headless inventory and diagnostics — with all configuration stored in a single version-controllable TOML file. It hit **#1 on Hacker News with 908 points** and 250 comments. **Why it matters:** The HN surge is a live signal of appetite for native-Rust replacements for bloated vendor utilities — and OpenLogi treats Linux as a first-class platform that Options+ never supported, shipping `.deb`/`.rpm`/`.pkg.tar.zst` with udev rules and a NixOS module. > Cross-platform macOS 13+/Linux/Windows; Windows 11 is the newest port and the README flags it as having "more rough edges" than the other builds. [`🔗 AprilNEA/OpenLogi`](https://github.com/AprilNEA/OpenLogi) · [`🔗 HN discussion (908 pts)`](https://news.ycombinator.com/item?id=49355606) --- ## 40. Cerebras CS-4 — the first multi-wafer inference rack ships this quarter, "30× faster than GPUs" - **Velocity:** ▮▮▮ trending - **Source:** The Next Web · ~325 pts HN · ~1d ago (~20:03 UTC+8) - **Tags:** `ai-hardware` `inference` `cerebras` `hpc` `wafer-scale` Cerebras unveiled the **CS-4** at its Supernova event on Aug 18: its first **multi-wafer** inference system — three **WSE-3 Turbo** wafers in one rack delivering **750 PFLOPS of sparse FP16** and **129.6 PB/s** of memory bandwidth, supporting models above 50T parameters, with wafer-to-wafer latency cut from 5 to 2 µs and ~120–140 kW per rack (roughly half a comparable AMD/Nvidia rack). First shipments are due before the end of the quarter. The headline "up to **30× faster than GPU-based systems**" is a **single-user** metric — tokens/sec per user on `gpt-oss-120b` against unnamed GPU systems — and per The Register's analysis the WSE-3 Turbo is **not new silicon**: it's the same 4T-transistor / 900k-core / 44 GB SRAM die clocked from ~1.4 to ~2.8 GHz, with a genuinely new generation slated for 2027. **Why it matters:** It's Cerebras's first hardware since its $5.55bn Nasdaq debut and lands five days after OpenAI's "Ultrafast" GPT-5.6 Sol mode went live on Cerebras silicon — a direct, inference-focused challenge to Nvidia, but one whose headline speed claim only holds under a narrow benchmark and a clock-bump die. [`🔗 The Next Web — CS-4`](https://thenextweb.com/news/cerebras-cs-4-wafer-scale-ai-inference-system) · [`🔗 HN discussion (325 pts)`](https://news.ycombinator.com/item?id=49354949) --- ## 41. CVE-2026-67443 — FUXA's guest-JWT bypass reaches the Node-RED editor for unauthenticated RCE - **Velocity:** ▮▮▮ trending - **Source:** OpenCVE · CVSS 9.2 · ~1d ago (~20:03 UTC+8) - **Tags:** `security` `cve` `scada` `ot` `node-red` **CVE-2026-67443** (**CVSS v4 9.2**, published Aug 18, fixed in FUXA **1.3.3**) is a missing-authorization flaw in **FUXA**, the open-source SCADA/HMI process-visualization platform. The `allowDashboard` gate for `/nodered` verifies the JWT but never inspects the decoded identity, so when Node-RED integration, secure mode and `nodeRedAuthMode: secure` are all enabled, an unauthenticated attacker obtains a signed **guest token** from `POST /api/heartbeat` and uses it to reach the Node-RED editor and flow-deployment API — deploying function nodes, invoking `fuxa.runScript`, and reaching OS-command execution when `nodeRedUnsafeModules` is on. **Why it matters:** Zero-interaction, no-credentials code execution on software that sits on industrial/OT networks, where the secure-mode gate was the primary protection — and it's bypassed by design, not by exploit. [`🔗 NVD CVE-2026-67443`](https://nvd.nist.gov/vuln/detail/CVE-2026-67443) · [`🔗 OpenCVE CVE-2026-67443`](https://app.opencve.io/cve/CVE-2026-67443) --- ## 42. CVE-2026-71539 — n8n's Git-clone race plants a custom node that runs as the server - **Velocity:** ▮▮ rising - **Source:** OpenCVE · CVSS 8.9 · ~1d ago (~20:03 UTC+8) - **Tags:** `security` `cve` `n8n` `race-condition` `rce` **CVE-2026-71539** (**CVSS v4 8.9**, published Aug 18, fixed in **1.123.64 / 2.29.8 / 2.30.1**) is a TOCTOU race (CWE-367) in n8n's Git clone node: an authenticated workflow user swaps a validated directory for a symlink before cloning, planting a crafted repository in the community-node directory that loads as a custom JavaScript node after a server restart — executing arbitrary code on the host. n8n is widely self-hosted, and workflow editors are typically low-privileged but hold service credentials, so the escalation path is short. **Why it matters:** It's a canonical "check, then use" race in a tool whose whole job is running semi-trusted automation with secrets — a reminder that the file-system boundary between a workflow and the host is an isolation surface, not decoration. [`🔗 NVD CVE-2026-71539`](https://nvd.nist.gov/vuln/detail/CVE-2026-71539) · [`🔗 OpenCVE CVE-2026-71539`](https://app.opencve.io/cve/CVE-2026-71539) --- ## 43. Agent Lightning v1.0 — Microsoft's harnessed agentic RL lifts Qwen3.5-9B 41.8% → 56.4% on SWE-bench - **Velocity:** ▮▮ rising - **Source:** arXiv · v1 Aug 18 · ~1d ago (~20:03 UTC+8) - **Tags:** `rl` `agents` `post-training` `coding-agents` `framework` **Agent Lightning v1.0** (arXiv:2608.17528, Microsoft, submitted Aug 18) makes the **deploy-time agent harness** own the environment loop during RL, so the trainer only ever sees LLM request/response pairs — ~3,500 lines addressing retokenization, sample merging, advantage calculation, loss normalization and backend scheduling across arbitrary harnesses. The headline result: fine-tuning **Qwen3.5-9B on 6K examples** lifts **SWE-bench Verified from 41.8% to 56.4%** (+14.6 points) with modest compute, and the pipeline is released. **Why it matters:** "The harness participates in training" is emerging as the standard architecture for real agent models — the abstract notes the pattern was later adopted by verl Uni-Agent, AReaL 2.0, slime and Polar — so this is the reproducible reference implementation for that shift. [`🔗 arXiv:2608.17528`](https://arxiv.org/abs/2608.17528) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.17528) --- ## 44. Abra — Luma's diffusion scaling laws: compute-optimal at ~200 image tokens/param, ~10× Chinchilla - **Velocity:** ▮▮ rising - **Source:** arXiv · v1 Aug 18 · ~1d ago (~20:03 UTC+8) - **Tags:** `diffusion` `scaling-laws` `image-generation` `compute-optimal` `research` **Abra** (arXiv:2608.17286, Luma AI, submitted Aug 18) is a controlled family of flow-matching transformers trained across ~10¹⁹–10²² FLOPs to derive scaling laws for text-to-image diffusion. The findings: diffusion scales as predictably as language models, but the compute-optimal point is roughly **200 image tokens per parameter — ~10× the Chinchilla prescription for LLMs** — and because diffusion is robust to overtraining, the authors advise spending on **more data rather than larger models**. Loss, CFG settings, representation quality and training-curve shape all collapse onto a universal form. **Why it matters:** This is the closest thing to "Chinchilla for diffusion," and it directly changes how image/video teams allocate a training budget — a concrete decision rule where the field previously guessed. [`🔗 arXiv:2608.17286`](https://arxiv.org/abs/2608.17286) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.17286) --- ## 45. MoNe — modular neural memory cuts long-context compute and memory ~80% with no retraining - **Velocity:** ▮▮ rising - **Source:** arXiv · v1 Aug 18 · ~1d ago (~20:03 UTC+8) - **Tags:** `long-context` `memory` `transformers` `efficiency` `research` **MoNe** (arXiv:2608.17616, submitted Aug 18) bolts a lightweight **modular neural memory** onto any frozen pretrained Transformer: context is read in fixed-size segments via test-time-learned fast-weight memory, and at inference the memory generates keys/values from the query tokens alone — so context is never re-read. At **128K tokens** it reduces compute and peak GPU memory by **~80%** versus in-context learning at only **6.4% parameter overhead**, with O(N) preprocessing and O(1) query cost, and it stays strong on RULER tasks even beyond the backbone's native window. **Why it matters:** It decouples inference cost from context length for the long-context agent workloads that dominate this feed — an efficiency win that requires no fine-tuning and no change to the base model. [`🔗 arXiv:2608.17616`](https://arxiv.org/abs/2608.17616) · [`🔗 HF Papers`](https://huggingface.co/papers/2608.17616) --- ## 46. NorthCinder — a buyer-run shopping-agent MCP server with a signed purchase mandate - **Velocity:** ▮▮ rising - **Source:** GitHub · 1.2k stars · ~2d ago (~20:03 UTC+8) - **Tags:** `mcp` `agents` `shopping-agent` `local-first` `commerce` **cinderline/northcinder** (MIT, 1.2k stars, `northcinder@0.1.2` on npm) is a self-hosted MCP server for AI shopping agents: it searches configured store adapters (Shopify, WooCommerce, eBay/Etsy via API, Amazon read-only via a user-controlled browser profile), returns a ranked shortlist with machine-readable reasons for inclusion *and* rejection, and requires a **separate, signed, single-use approval mandate with a spending cap** before any checkout. Ranking is buyer-criteria-only — "seller payment is not an input" — and sponsored offers stay labeled below every organic result, with a local audit trail. **Why it matters:** Agentic commerce is arriving with sponsored ranking and telemetry baked into the broker path. A server where the buyer runs the ranker, holds the signing key and keeps the audit log is the trust model the category is missing — and a direct counter to the "agent buys the wrong thing on your card" failure mode. [`🔗 cinderline/northcinder`](https://github.com/cinderline/northcinder) · [`🔗 npm registry — northcinder`](https://registry.npmjs.org/northcinder) --- ## 47. Mureka V9.5 — Kunlun Wanwei's MusiCoT music model claims 97% prompt-control yield - **Velocity:** ▮▮ rising - **Source:** PingWest · Aug 18 release · ~1d ago (~20:03 UTC+8) - **Tags:** `music-generation` `model-release` `multimodal` `chain-of-thought` `audio` **Kunlun Wanwei** released **Mureka V9.5** on Aug 18, its AI music-generation model built on the **MusiCoT** (music chain-of-thought) framework, which constructs full musical logic — structure from whole-song down to local expression — *before* audio generation. The vendor's internal evals report a **61.0%** vocal-quality yield, **97.0%** prompt-control yield, and **95.7%** genre/style-fidelity ratio, refined from **25,000+** user-feedback items, with notable improvements to guofeng (Chinese traditional) lyric articulation and harmony layering. **Why it matters:** A concrete model release with published metrics from a major Chinese AI-music vendor — a day after Alibaba's HappyShrimp made the same track, showing text-to-music is becoming a contested, shipped category rather than a demo. [`🔗 PingWest — Mureka V9.5`](https://www.pingwest.com/w/316546) · [`🔗 Mureka`](https://www.mureka.ai/) --- ## 48. Sprix SAGE Router — SELF/COLLABORATE/HANDOFF routing for A2A agent networks - **Velocity:** ▮ steady - **Source:** GitHub · 362 stars · ~1d ago (~20:03 UTC+8) - **Tags:** `routing` `agents` `a2a` `multi-agent` `orchestration` **wang2122/sprix-sage-router** (MIT, Python, 362 stars) is a decision layer that sits between A2A protocol discovery and task execution, choosing mid-run whether the incumbent agent should continue alone (SELF), recruit collaborators while keeping ownership (COLLABORATE), or transfer full ownership (HANDOFF). It composes task-DAG roles, schedules dependencies, and updates trust from execution evidence under permission/budget/deadline constraints, using a learned outcome model plus beam-search team composition. It's an early research preview (v0.2, 12 commits); the README's 2,500-task simulation (0.634 vs 0.507 incumbent-only quality) is flagged as synthetic. **Why it matters:** As A2A (now a Linux Foundation protocol) matures, the open problem shifts from "can agents talk" to "when should they collaborate vs hand off" — a learned, evidence-based answer to that is the missing middle layer between discovery and execution. [`🔗 wang2122/sprix-sage-router`](https://github.com/wang2122/sprix-sage-router) · [`🔗 a2aproject/A2A`](https://github.com/a2aproject/A2A) --- ## 49. Benjamin-Plus — JetBrains' measured token-efficiency skill cuts coding-agent cost 17.9% - **Velocity:** ▮ steady - **Source:** GitHub · JetBrains · ~2d ago (~20:03 UTC+8) - **Tags:** `coding-agents` `skills` `token-efficiency` `cost` `benchmark` **JetBrains/benjamin-plus-skill** (MIT, ~745-token ruleset) changes *how* a coding agent looks things up and waits — one-pass recon, 50-line "keyhole reads" instead of whole files, probing the environment once, treating the task's own verification command as the definition of done — without changing what it builds. In a paired A/B on 80 SkillsBench tasks (Claude Code + Sonnet 5), the injected skill produced a **−17.9% cost median with quality unchanged** (7 better / 5 worse / 68 ties), and a Codex SWE-bench run showed −4.4% cost and −20% tool calls. The README's key harness detail: injected, it saves; installed as a discoverable folder, "it saves nothing." **Why it matters:** It's the rare skill with a measured result published by a real vendor, and its delivery-method finding is directly actionable for anyone shipping agent skills. [`🔗 JetBrains/benjamin-plus-skill`](https://github.com/JetBrains/benjamin-plus-skill) · [`🔗 benchflow-ai/skillsbench`](https://github.com/benchflow-ai/skillsbench) --- ## 50. Autoprompt — a multi-agent skill that cuts Terminal-Bench failures 45% (60/89 → 73/89) - **Velocity:** ▮ steady - **Source:** GitHub · 138 stars · ~2d ago (~20:03 UTC+8) - **Tags:** `coding-agents` `skills` `multi-agent` `terminal-bench` `orchestration` **Spielewoy/autoprompt-skill** (MIT, v1.0.0) wraps six coding agents — Claude Code, Codex, OpenCode, Kilo Code, VS Code, Prime Agent — in a layered multi-agent hierarchy (coordination / management / execution / independent-judgment) so one agent never plans, approves and verifies its own work. On Terminal-Bench 2.1 with OpenCode 1.18.7 it raised solves from **60/89 to 73/89 — 45% fewer failures** — at a disclosed trade-off of ~3× time and ~2× tokens. The README is explicit that this is a single measured run, not a sweep. **Why it matters:** "Separate plan/approve/verify across agents" is the governance pattern everyone agrees on but few skills ship as a number; 45% fewer failures on a public benchmark, with the cost trade-off disclosed, is exactly the evidence-first claim this feed tracks. [`🔗 Spielewoy/autoprompt-skill`](https://github.com/Spielewoy/autoprompt-skill) · [`🔗 harbor-framework/terminal-bench`](https://github.com/harbor-framework/terminal-bench-1) --- ## Metadata | Field | Value | |-------|-------| | Generated | 2026-08-19T20:03:00Z | | Items | 50 | | Sources tracked | 51 (GitHub, Hacker News, arXiv, NVD, CISA, Hugging Face, kernel.org, Oracle Security Alerts, Chrome Releases, openwall oss-security, postgresql.org, depesz, Phoronix, Modular, ai.google.dev, OpenAI Platform Docs, OpenCVE, npm registry, mcpindex.ai, atto.cash, acadia.engineering, TrendForce, Tom's Hardware, It's FOSS, Notebookcheck, Anthropic Support, machine0, GenLayer Foundation, Lavx, Mandiant, GitHub Advisories, docs.microsandbox.dev, ui-mate.github.io, leaflet.pub, browser-use.com, pingwest.com, mureka.ai, thenextweb.com, and vendor advisories) | | Update schedule | 04:03, 12:03, 20:03 UTC+8 (3x daily) | | Ranking | Velocity-weighted (recency × engagement acceleration × source authority) | | License | [CC-BY 4.0](https://creativecommons.org/licenses/by/4.0/) | --- [Previous day](../2026-08-18/) · [Raw .md](../2026-08-19.md) · [Archive](../../archive/)