1. August 28, 2026
   1. 🔗 New Music Releases Mastodon - Marrow Deep rss

      Mastodon - a new release is available:

      • 2026-08-28: Marrow Deep (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

   2. 🔗 New Music Releases Kamelot - Dark Asylum rss

      Kamelot - a new release is available:

      • 2026-08-28: Dark Asylum (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

   3. 🔗 New Music Releases Russian Circles - Nine rss

      Russian Circles - a new release is available:

      • 2026-08-28: Nine (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

   4. 🔗 New Music Releases Train - Mad Dog in the Fog rss

      Train - a new release is available:

      • 2026-08-28: Mad Dog in the Fog (Album)

      Amazon: Canada | Deutschland | France | United Kingdom | United States

      Visit muspy for more information.

2. August 27, 2026
   1. 🔗 backnotprop/plannotator v0.27.9 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.27.8 | Pi keeps its prompt cache across plan transitions, thumbs-up returns to HTML annotation, embed picker seam
      v0.27.7 | Pi host crash fix on Windows, Call Flow tree cap, jj fork-point base, plannotator knowledge skill + llms.txt
      v0.27.6 | Live app annotation lands on Pi, one interaction model for HTML pages (same-day patch on v0.27.5)
      v0.27.5 | Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix, Pi fixes
      v0.27.4 | Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow
      v0.27.3 | Folder watcher freeze fix on large repos, first SBOM-attested release pipeline
      v0.27.2 | Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions
      v0.27.1 | Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles
      v0.27.0 | Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut
      v0.26.8 | Placed comment markers on HTML pages, shift-click multi-select, live app annotation
      v0.26.7 | Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing
      v0.26.6 | Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds)

      What's New in v0.27.9

      Eleven pull requests, one of them from @leoreisdias. Two threads run through the release. Browser-integrated agents can now read a plan or an annotate session and leave comments on it through WebMCP, instead of scraping the page. And the raw-HTML annotation surface gained a Refresh action along with a published set of seams so other applications can run that surface as Plannotator ships it. A Windows uninstall fix and a pre-release QA pass close it out.

      Browser agents can read your document and comment on it

      An agent that runs inside the browser, such as Codex's browser or Claude Code's browser, has until now had to work out what is on the page by reading the DOM. Plan review and every annotate surface (markdown, raw HTML, live app, folder) now register a small tool catalog on document.modelContext, the WebMCP surface those agents speak.

      The catalog is deliberately narrow. read_document returns the whole situation in one zero-argument call: the session, the document text windowed at 16k characters and cut at a block boundary, an outline with per-section comment counts, every comment with its quote and context, sibling documents, and a set of nudge codes. add_comments writes a batch, anchoring by an exact quote, by section, by reply, or as a document-level note, and is idempotent by request id. update_comment, remove_comments, reveal and nudge_user round it out, with list_documents in folder sessions.

      Three rules make this safe to ship without a consent dialog. Decisions stay with the human: no tool approves, denies, submits, closes, stages or marks anything viewed, and a test pins the catalog so none can be added quietly. An agent may edit or remove only the comments it created, which are stamped browser-agent; asking to touch a human's comment answers forbidden. And nothing is ever registered inside the sandboxed iframes, so a page you are annotating can neither see nor impersonate Plannotator's tools.

      Without the API there is no footprint at all. Feature detection is one typeof check per mount, and when document.modelContext is absent the catalog is never built and no indicator, banner, request or timer is created. That was verified rather than assumed: builds from main and from the branch served the same annotate session to a Chrome without WebMCP, and the rendered DOM (44,607 characters), the request lists, the console output and the timer counts came back identical on both sides.

      The nudges are what keep an agent in step with you. Every response carries codes computed from state the page already holds, so the agent learns on the call it was going to make anyway that you added a comment, that your composer is open, that the file changed on disk, or that the live app navigated to another page. A header indicator appears after the first tool call, and a Settings toggle turns the whole provider off and on.

      One product change comes with it. Annotation gains an optional inReplyTo field, so an agent can answer a comment you left. A reply inherits its parent's anchor, renders indented under it in the annotations panel, and exports nested under the parent as a **Replies:** block, which is what puts the exchange in front of the coding agent in order. Annotations without the field render and export byte for byte as before.

      Code review is phase 2 and is not in this release.

      • #1393 by @backnotprop

      Refresh rendered HTML from disk

      Markdown annotate sessions pick up an agent's edits as soon as the file changes on disk. Rendered HTML sessions kept showing the snapshot they loaded at startup, so the review surface went stale the moment the agent rewrote the report you were reading.

      @leoreisdias added a Refresh action for local .html and .htm annotate sessions, next to Hide tools and reachable from the keyboard. It re-reads the document, remounts the sandboxed viewer, reapplies your annotations, and tells you how many anchors no longer match while keeping those comments in the panel. It is manual on purpose: this is the first checkpoint, and automatic filesystem-driven refresh waits until the restoration behavior has seen real use. URL sessions, archive views, markdown- converted HTML and non-HTML documents are unchanged, and HTML source saving stays off.

      Review turned up a share-link race that predated the feature. The share request context included the identity of the resolver, and that identity changes as a side effect of its own success, so the first short link created on an HTML session discarded its own result. That is fixed with a regression test. A browser verification run found two more: the singular toast read "1 annotation no longer match the HTML", and a browser reload after a refresh reverted the page to the startup snapshot because /api/plan never re-read disk while the draft annotations persisted against the replaced page. /api/plan and /api/share-html now share one root read on both server runtimes, so reload and refresh land on the same bytes.

      The version diff that a refresh used to cost you is back as well, recomputed rather than dropped. That fix arrived with the QA pass below.

      • #1232 by @leoreisdias, with maintainer commits for the share race, the toast and the two-runtime root read

      The HTML annotation surface, packaged for hosts

      Applications built on @plannotator/ui were hand-rolling their own code around HtmlViewer to get the experience Plannotator ships. The Workspaces team asked for the seams to be published, and they now are.

      HtmlSurfaceControls gives a host the eye, the refresh and the pen with the exact markup, data attributes and aria state Plannotator's header uses, each control rendering only when its handler is passed. useHtmlRefresh publishes the refresh lifecycle with the backend behind a fetchSnapshot callback, so a host binds it to its own document store. projectHostThreads and buildPersistedHtmlAnchor in @plannotator/core/html-anchor project stored rows onto the annotations prop in the host's order, which is the marker numbering, and trim a composed comment's anchor for persistence within a byte budget. AnnotationPanel takes an unanchoredIds set and renders a small Unanchored chip on the matching cards. HtmlViewer takes scrollBehavior so a host can carry a reduced-motion preference across the iframe boundary, and maxAdditionalTargets for its own cap on shift-click targets.

      Every seam is additive and defaults to today's behavior, and Plannotator's own app passes the same defaults. The one deliberate change you will see in Plannotator is that chip: annotations a Refresh could not re-anchor now carry it in the panel as well as in the toast, and it clears on the next refresh that re-anchors them. The rest was held to a real-browser A/B over an annotate session driven identically on both builds, with header, chrome and overlay- marker captures matching after normalizing minted ids and the port.

      • #1395 by @backnotprop

      Renderers that load when they are needed

      Mermaid, Graphviz, KaTeX and the identity dictionary used to ride every document read. They now load on demand, while Plannotator's own apps import eager entries as their first import and render exactly as before, typesetting math on the first commit with no frame of raw TeX. On the share portal the entry chunk drops from 1,831,133 to 1,211,620 gzip bytes, with the Graphviz engine and the Mermaid runtime becoming lazy chunks fetched only when a diagram is on the page. For a host that bundles by route, roughly a megabyte of renderer leaves the document-read closure.

      The raw-HTML viewer's 185 KB bridge script can also be served as a separately cached asset now. A host passes bridgeScriptUrl and gets one classic <script src> in the exact position the inline script occupied; the bridge stamps a protocol version on its ready message, so a stale cached asset produces a named warning and an in-surface banner rather than a silent mismatch, and a missing one surfaces as a timeout. Plannotator passes nothing and stays inline everywhere, including the live-app proxy and the Pi and OpenCode copies.

      Two rounds of adoption feedback followed the first npm release. The default KaTeX loader moved into its own module so a host that registers its own loader can alias the package default out of its build entirely. Mermaid's own import("katex") for $$ labels was keeping a second KaTeX chunk alive for hosts, and is now redirected through the shared math slot for importers inside the Mermaid package only, which leaves one host-owned chunk instead of two. bridgeErrorDisplay lets a host that renders its own failure banner turn off the package's. The documented bridge alias regex was anchored, since the unanchored form matched any specifier ending in /bridge-script. And resetMathRenderer no longer forgets a registered loader.

      • #1394, #1398, #1399 and #1402 by @backnotprop

      First edit in the atomic editor lands sooner

      The Workspaces team measured the cost of clicking into the markdown editor and filed the numbers as #1401. Reproducing it in Plannotator showed that the part that grows with document size was not CodeMirror's layout measurement, as first suspected, but three editor extensions each forcing a synchronous parse of the whole document at mount. @plannotator/atomic-editor 0.8.1 bounds that mount-time parse to an initial window and grows the syntax tree in idle time afterwards, so decorations beyond the window fill in progressively. On a 283 KB document at 4x CPU throttling, click to second paint goes from 586 ms to 319 ms, and small documents are unchanged. Plannotator picks it up through the dependency update.

      • 2b9dbc9d by @backnotprop, from #1401

      Windows uninstall no longer stalls on the PATH edit

      CI caught this one. The uninstall lifecycle smoke test failed three times in a row on a single Windows run with "Could not remove ... from the Windows user PATH", while passing on every other run. The same run's cleanup killed several orphaned browser processes, which turned out to be the cause.

      SetEnvironmentVariable writes the registry and then broadcasts WM_SETTINGCHANGE to every top-level window, synchronously, one window at a time, without the flag that skips hung windows. With hung GUI processes around, that broadcast outlasted the uninstaller's 15 second command timeout, PowerShell was killed, and the uninstaller correctly refused to proceed even though the registry edit had already completed. A user with one hung window can hit the same stall.

      Both PowerShell scripts now write HKCU\Environment directly, reading and restoring the value without expanding %VARS% and preserving its REG_EXPAND_SZ kind, and broadcast afterwards on a best-effort basis with a one second per-window timeout inside a try/catch, so nothing about notifying open windows can reach the exit code. The fail-closed behavior is intact: a real registry failure still preserves the running CLI, and a timeout with nothing on stdout is still an error because the edit is unproven. A timeout that arrives after the rollback value has been echoed is now treated as the completed edit it is, with a warning that notifying open windows timed out.

      • #1403 by @backnotprop

      Pre-release QA

      A review pass before tagging turned up six things worth fixing, all of them shipped here.

      An HTML root that became unreadable, replaced by a directory or stripped of read permission, used to throw: Pi left /api/plan unanswered so the tab hung on reload, and Bun returned a 500. Both runtimes now fall back to the startup snapshot exactly as they do for a missing file. The version diff that vanished for the rest of a session once you refreshed is recomputed against the served bytes instead of being omitted, on reload and through the in-app Refresh, with no history written by a GET. The compact touch shell's Options menu had equivalents for the pen and the eye but not for Refresh, and now offers Refresh from disk under the same conditions as the header button. HtmlSurfaceControls rendered its refresh button only inside the eye's branch, so a host passing refresh without the eye got nothing.

      Reply threading became one shared rule. resolveReplyParents in @plannotator/core/annotation-threads resolves parents linearly and cycle- safely for both the annotations panel and the export, so annotations caught in an inReplyTo cycle are emitted as roots rather than dropped from feedback while the header count still counted them. Both runtimes' PATCH /api/external-annotations now rejects a self-reference or a cycle with a 400, so the invalid state cannot be created in the first place. The WebMCP provider and the viewer also got a hygiene pass: bounded tombstone and request memories, per-instance minted ids, nudge id caps, waiter cleanup on unmount, and a shared retry epoch for diagram blocks.

      • #1405 by @backnotprop

      Additional Changes

      • npm releases : @plannotator/core 0.25.0 with @plannotator/ui 0.32.0 (#1396), then @plannotator/ui 0.33.0 (#1400) and 0.34.0 (#1402) on the same core. Plannotator's own apps are unaffected by all of it.

      Install / Update

      macOS / Linux:

      curl -fsSL https://plannotator.ai/install.sh | bash
      

      Windows:

      irm https://plannotator.ai/install.ps1 | iex
      

      Claude Code Plugin: Run /plugin in Claude Code, find plannotator , and click "Update now".

      Pi: Update @plannotator/pi-extension to 0.27.9 and restart Pi.

      OpenCode: Clear cache and restart:

      rm -rf ~/.bun/install/cache/@plannotator
      

      What's Changed

      • feat(webmcp): expose plan review and annotate as WebMCP tools for browser agents by @backnotprop in #1393
      • feat(annotate): manual refresh of rendered HTML from disk by @leoreisdias in #1232
      • feat(ui): publish the HTML annotation seams hosts were hand-rolling by @backnotprop in #1395
      • perf(ui): lazy diagram and math renderers with eager entries for Plannotator by @backnotprop in #1394
      • chore(packages): bump @plannotator/core to 0.25.0, @plannotator/ui to 0.32.0 by @backnotprop in #1396
      • perf(ui): load the HTML viewer bridge by URL for hosts, with a protocol version and ready timeout by @backnotprop in #1398
      • fix(ui): 0.32.0 adoption feedback from hosts by @backnotprop in #1399
      • chore(packages): bump @plannotator/ui to 0.33.0 by @backnotprop in #1400
      • fix(ui): 0.33.0 adoption feedback and bump @plannotator/ui to 0.34.0 by @backnotprop in #1402
      • chore(ui): update @plannotator/atomic-editor to 0.8.1 for the editor entry fix by @backnotprop in 2b9dbc9d
      • fix(uninstall): edit the Windows user PATH through the registry with a best-effort change broadcast by @backnotprop in #1403
      • fix: pre-release QA findings for 0.27.9 by @backnotprop in #1405

      Community

      • @leoreisdias built the HTML Refresh action in #1232, including the refresh lifecycle and the annotation restoration reporting that the maintainer additions and the QA pass then built on. It is the latest in a long run of contributions from @leoreisdias.
      • The Workspaces team's adoption of @plannotator/ui drove three of the changes here: the parity seams in #1395, the two rounds of adoption feedback in #1399 and #1402, and the editor measurements filed as #1401 that produced the atomic-editor fix.
      • @HunterClarke-git reported #1392, where settings tabs appeared only after a delay and an OpenCode session closed while the review window stayed open. The report has been investigated and a fix is designed, but it did not make this release. Work on it is under way.
      • @arklanq-patronus reported #1367, where annotate-last on Codex fails when a single thread spans several rollout files. @mohammadrezwankhan has an open pull request for it in #1387, still under review.
      • @rNoz reported #1388, where the root build script builds the hook before the review bundle it copies from, and opened #1389 with the fix. It is open.
      • The Windows PATH stall was found by the release pipeline's own smoke test rather than by a user, which is what the job is there for.

      Full Changelog : v0.27.8...v0.27.9

   2. 🔗 anthropics/claude-code v2.1.248 release

      What's changed

      • Added --restricted (or CLAUDE_CODE_RESTRICTED=1): removes the built-in tools that run commands or code and WebFetch (unless named in --tools), keeps file tools inside the working directory, refuses bypassPermissions, and ignores user, project and local settings files
      • Added experimental.cacheTtl ("5m" or "1h") to agent frontmatter: a per-agent prompt cache TTL used when no subagent TTL setting is configured
      • Added claude self-hosted-runner --client-label <label> (or SELF_HOSTED_RUNNER_CLIENT_LABEL) to override the label the runner registers with (default: hostname)
      • Added server-managed settings diagnostics: a startup warning when the settings fail to load, and a /doctor and /status line explaining a load failure or why they weren't fetched (Bedrock/Vertex/third-party provider, custom ANTHROPIC_BASE_URL)
      • Added a warning in /web-setup when the GitHub CLI token lacks the workflow scope, since pushes to very large repositories can be rejected without it
      • Added /usage-credits for Enterprise organizations billed through AWS Marketplace, self-serve Enterprise, and Enterprise trials, so members can request a higher usage limit from their admin
      • Added cross-session messaging (SendMessage / ListAgents) between sessions on the same machine on Bedrock, Vertex, and Foundry, and when telemetry is disabled
      • Fixed a prompt-cache miss (and lost extended-thinking context) roughly once an hour in long sessions, caused by tool definitions being re-rendered after an OAuth token refresh
      • Fixed the ScheduleWakeup tool definition changing between a session and its --resume when the account had entered usage overage, causing a full prompt-cache miss on the resumed session's first turn
      • Fixed Claude Desktop and Cowork sessions disappearing after 30 days: the transcript cleanup now keeps desktop-written sessions while they are in the app (unless org policy manages retention); the new desktopSessionCleanupPeriodDays setting caps the exemption
      • Fixed being sent to the login screen when another Claude Code process held the token refresh lock while the session token had expired; the request now fails with a retryable error instead
      • Windows: Fixed the claude agents list not responding to the keyboard after detaching from a session, or when launched in a terminal tab left in win32-input-mode
      • Fixed the recommended Console sign-in in /login failing with an OAuth error before showing a sign-in URL on machines where it can't be used (for example when ANTHROPIC_API_KEY or an API key helper is set); it now falls back to the API-key sign-in
      • Fixed model names in /model and fast-mode switch notices to render as code, so suffixes like [1m] display literally instead of as a link
      • Fixed claude agents skipping the workspace trust prompt when the CI environment variable is set
      • Fixed claude agents crashing on launch when the PR-status cache held a malformed entry
      • Fixed agent view resurrecting a weeks-old background session after the machine was off: such a session now shows as stopped at its real end, and opening it asks before resuming its saved conversation
      • Fixed agent view sometimes opening an older conversation, and dropping the typed prompt, when starting a new session
      • Fixed claude agents: opening a stopped session that you already resumed in another terminal no longer starts a second process on that conversation; the row now says it is open in a terminal
      • Fixed claude agents and claude rm refusing to delete a session ("has commits that are not pushed anywhere") when its worktree branch was already merged into your checked-out default branch (e.g. local main) but not yet pushed
      • Fixed background sessions waiting silently when a PermissionRequest or PreToolUse hook prints an invalid answer: the claude agents row now names the hook and the schema error
      • Fixed hooks silently treating a stdout {…} object that isn't valid JSON as plain text; it's now reported as a hook error with the parse message
      • Fixed /mcp listing a project .mcp.json entry that declares the claude.ai connector type under the trusted "claude.ai" heading; it now appears under its real scope
      • Fixed MCP servers whose headersHelper supplies the Authorization header falling into OAuth discovery on a 401 instead of re-running the helper and retrying the call as documented
      • Fixed /login to a Claude apps gateway hanging when the managed-settings security approval dialog was required
      • Fixed gateway model discovery (CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY) never running when apiKeyHelper is the only credential
      • Fixed claude logs leaving mouse tracking, bracketed paste and the alternate screen switched on in the terminal it was run from
      • Fixed the trust dialog's list of repo permission rules showing a garbled character when a long rule was cut off in the middle of an emoji
      • Fixed the permission mode indicator staying hidden behind the "Press Ctrl-C again to exit" hint when you press shift+tab right after ctrl+c
      • Fixed /ultrareview and locally seeded cloud sessions uploading uncommitted edits to prod.env-style and *.tfvars files, or to editor swap, temp, and backup copies of credential files (e.g. key.pem.tmp, id_rsa.swo); they now stay on your machine
      • Fixed Remote Control sessions occasionally never showing a permission prompt or the latest messages on the connected device after the CLI silently reconnected
      • Fixed cloud sessions occasionally failing at startup when the container's session credentials were not yet readable
      • Fixed claude remote-control rejecting its own flags (e.g. --spawn, --name) when a global flag or a wrapper-injected option precedes the subcommand
      • Fixed startup warnings (e.g. "N MCP servers need authentication") rendering one column right of the rest of the transcript
      • Fixed a backgrounded worktree session losing its checkout: the background session now holds the worktree's lock while it runs, so cleanup and git worktree remove leave it alone
      • Fixed @-mentions of other sessions not matching names typed with non-Latin characters (for example Korean entered through an IME)
      • Fixed an invalid crossSessionInbound value being silently ignored: it now warns and holds cross-session messages (user settings) or refuses them (managed settings) until fixed
      • Fixed rate-limit, usage, and fast-mode messages telling you to run /usage-credits when that command isn't available for your organization (e.g. hidden with DISABLE_EXTRA_USAGE_COMMAND)
      • [VSCode] Fixed a chat tab getting stuck on "No conversation found" when its session was never saved; it now starts a new conversation instead
      • Improved the Workflow tool's prompt footprint: its description is now about 1k tokens instead of 5.7k, with the script-writing reference moved into a bundled workflow-authoring skill
      • Improved the prompt-footer PR badge to check GitHub less often while the pull request is unchanged; a push or a gh pr command still refreshes it right away
      • Improved managed settings: client-side timeout, MCP startup-mode, and stream-watchdog env vars no longer trigger the settings-approval prompt
      • Improved /ultrareview <PR#> to check before launch that the GitHub account connected to your Claude account can access the repository, and to explain how to fix it, instead of failing after the cloud session starts
      • Improved cross-session messaging: falls back to a private per-user /tmp directory when the default one can't be used, and the notice and /status name the directory to fix
      • Changed shift+enter in the agent view dispatch input to insert a newline (matching the prompt); ctrl+enter now dispatches and attaches
      • Changed /loop: self-paced dynamic mode and the no-prompt autonomous default are now always available, including on Bedrock/Vertex/Foundry
      • Changed Anthropic telemetry export failures to log at debug level as [Anthropic telemetry] instead of [3P telemetry] OTEL diag error, so they are not mistaken for your OTel collector failing
      • Changed cross-session messaging in Linux user namespaces: root-equivalent trust for unmapped owners is limited to canonical system directories
      • Changed SendMessage from a subagent to another session: the result now notes that any reply is delivered to the parent session's conversation, not to the subagent
   3. 🔗 r/LocalLLaMA With HuggingFace, Nvidia is also acquiring llama.cpp and the team behind it rss

      With this move Nvidia is not only acquiring the HuggingFace platform, but they might also effectively acquire the copyright to the llama.cpp project, together with the entire team behind it.

      In February 2026 the llama.cpp team was employed by HF in order to continue working on llama.cpp and the ggml library.

      This includes:

      • Georgi Gerganov
      • Xuan-Son Nguyen
      • Aleksander Grygier
      • Victor Mustar
      • Lysandre
      • Julien Chaumond

      Now with the acquisition, llama.cpp's future looks a lot less certain given Nvidia's poor track record with open-source.

      This is still rather speculative at this stage, but it's definitely possible for the llama.cpp project to change in the future: either by switching to a different license, or by having staff redirected to other projects within the larger company.

      Even when a project is open-source the copyright owner has complete control over it, and they can change licensing as they wish.

      This has happened before with projects like Redis, Minio, and others.

      Source:

      https://huggingface.co/blog/ggml-joins-hf

      Edit:

      The original announcement from Feb 2026 from Gerganov gives a few more details:

      https://github.com/ggml-org/llama.cpp/discussions/19759

      submitted by /u/vexatious-big
      [link] [comments]

   4. 🔗 The Pragmatic Engineer The Pulse: We need to talk about migrations with AI rss

      Hi, this is Gergely with a bonus, free issue of the Pragmatic Engineer Newsletter. In every issue, I cover Big Tech and startups through the lens of senior engineers and engineering leaders. Today, we cover one out of four topics from last week 's The Pulse issue. Full subscribers received the article below seven days ago. If you 've been forwarded this email, you can subscribe here .

      OpenAI put an impressive-sounding case study about how they helped Asana save $5.9M with a single migration. From OpenAI (emphasis mine.)

      " Asana cleared 5 years of engineering work in 2 weeks with Codex. Using OpenAI Codex, Asana replaced an outdated testing system in two weeks for about $12K.

      For this project, Codex helped Asana's engineers remove Enzyme, an outdated testing system that had made the company's code harder to upgrade. Model and infrastructure costs came to about $12,000, compared with Asana's roughly $6 million estimate for the previous staffing plan.

      After 1.5 weeks of engineering effort spread across two calendar weeks, Enzyme was fully removed. Model and infrastructure costs totaled about $12K. For comparison: the previous plan was expected to take at least five years and estimated to cost roughly $6M. The experience changed which long-running software projects the company believes are practical to take on."

      For context, Asana migrated from Enzyme to React Testing Library, which indeed would not be a simple migration. However, their estimate of four engineers (each on circa $300K/year, according to OpenAI's arithmetic), spending five years on the project, had me like:

      

      But thinking about this for longer raised the question: what does a migration from Enzyme to React Testing Library even look like?

      Enzyme to React Testing Library migration

      Let's take a simple test and see how it looks in various testing libraries.

      For our test, we want to verify that a button increments a counter. Here's our button in React:

      Our button that increments its counter

      Now, the test to verify this, in Enzyme:

      The unit test in Enzyme

      And let's rewrite this test in React Testing Library:

      The unit test in React Testing Library

      The two tests do the same, but they have completely different syntax! Let's see just how different they are, with a side-by-side comparison:

      Two very different files: the only code in common is the imports

      The main reason for this difference is that the two frameworks use a fundamentally different approach to testing. Whereas Enzyme is oriented towards component testing (notice how the test operates on a component instance), the React Testing Library operates on the rendered Document Object Model (a data structure representing the HTML shipped to the client) so the test sees the whole rendered page, not just the component its written for. That's why the testing approach will differ radically between the two frameworks, especially when testing complex user journeys. You can learn more here on the tradeoffs between the two approaches from the React Testing Library author.

      It took Airbnb 6 weeks to migrate 3,500 tests with AI

      Last year, Airbnb revealed how they migrated their Enzyme test suite of 3,500 component test files within six weeks with LLMs. The estimate of doing this by hand was 1.5 engineering years. Airbnb did the LLM-aided migration in a multi-phase process:

      Five phases of the migration, for each file. Source:Airbnb

      Airbnb's team had to build loops to keep retrying migrations; once they did, 75% of files were migrated in just four hours, and the migrations were straightforward. They then built a more sophisticated refactor pipeline for the remaining 25% of tests; after building the pipeline, the new loop migrated most of the remaining tests (97%) in total, after running over 4 days. The remaining 3% was done with LLM input, with engineers finishing it in a week.

      This was in March 2025, when the frontier coding model was Claude 3.7 Sonnet. Today, models are a lot more capable, such as the likes of GPT-5.6 Sol and Claude Fable 5.

      AI makes impractical migrations doable

      On the basis that it took Airbnb six weeks, I find it credible that it took Asana two weeks to migrate what is probably a similarly complex test infrastructure from Enzyme to RTL, a year later.

      The time and $6M cost as quoted by OpenAI feels inflated. I assume the numbers were based on an estimate that a fulltime engineer could do a maximum of X tests migrated per day, where X was between 5 and 10. Then, calculate the number of engineering years this takes (perhaps 20 engineering years), and multiply by the cost of an engineer. You estimate a project like this when it's an undesirable project you really don't want to do as an engineer!

      So, looking at it from this point of view: does it matter if the estimate was 1.5 years (Airbnb) or half a decade (Asana, hypothetically)? Or if the estimated cost was $1M or $5M? It would still be an impractical migration and a foolish endeavor: too long and distracting, at least, in the "traditional" way!

      Pre-AI, years-long migrations were rare. In 2021, Sentry took 1.5 years to convert their frontend codebase from JavaScript to TypeScript. That was a migration of 1,100 files and 95,000 lines of code! Around 10 engineers worked on the migration, so if we assume a $300K-per-engineer cost, that's a $2-4M cost for circa 95,000 lines of code.

      Indeed, Asana 's reported $12,000 migration cost could actually cost even less if there was ruthless focus on cost optimization. What about using a model that's 10x cheaper than OpenAI, like an open model running on inference providers? After all, why use the most expensive model, especially if a company already owns GPUs, running models, making inference practically free (except for power costs, that is.) For a first run, $12,000 would be affordable for a company paying $300K for engineers. But for subsequent runs, I'd wager it's worth spending time optimizing the cost, and saving $10K per migration (or more!)

      A few more details from inside Asana

      I managed to catch up with Dan Ubilla at Asana, who leads the Developer Productivity group at the company. He helpfully clarified a few things about the Enzyme migration post on the Asana site:

      • Asana started the Enzyme migration in 2024. The team had 4,000+ Enzyme files to migrate, and they took a first stab at the migration with LLMs, at the time. Beyond migrating existing tests, much of this phase focused on getting the codebase into a state where future tests could be written more idiomatically. This included improving mocking, data set up, and coverage instrumentation. They finished migrating about 25% of the files to RTL, choosing the tests that had the highest return on investment: meaning easiest to migrate, or most frequently updated ones.
      • The remainder of the migration became low priority. Asana prioritized migrations as critical ("must do soon"), important ("important to do soon"), and opportunistic ("nice to have"). The company has a good number of critical and important migrations, and the remainder of the Enzyme migration sat as one of the many opportunistic.
      • Five years was about when the migration was projected to finish. The effort was not about "a team working for five years, nonstop on the project" - not at all! It was about the timeframe that the opportunistic Enzyme migration would have been completed, given its priority, and done, realistically. Given this migration was going on for two years, the five-year estimate was a rational one.
      • The team wanted to prove that LLMs drastically speed up migrations, and demonstrated it with an opportunistic , low-priority one. The Enzyme migration was not all that important to do quickly, and would have sat around for years. So it was the perfect candidate to prove that with LLMs, long migrations can be sped up!

      And finally, one addition from my end:

      The $6M cost was a back-of-the envelope estimation. I asked Dan how this estimate of the migration costing $6M came together. Dan confirmed that the estimation was done the same way as most of us do these estimations:

      • Estimate how long it takes an engineer to manually migrate a single Enzyme file (including rewrite + validation). Be generous with this estimation
      • Multiply it by the outstanding files to migrate (the 3,000+ ones)
      • Add in the time to remove any traces of the framework, monitoring, static analysis tools
      • Multiply by the hourly rate of a typical engineer
      • … and the number came out to $6M

      This estimation does not take into account that migrating even ten files by hand takes less than ten times more than it takes to migrate one file (you become more efficient), nor does it assume LLM usage. It's a baseline to get a sense of how the work would have been done, pre-AI, if distributed across all Asan engineers to pick up, and migrate few files, whenever they have time. My take is that this number is probably an overestimation, but the point is less about the number, and more to convey that this is a lot of work!

      Internally, Asana's team and leadership are now convinced about the usefulness of LLMs for migrations, and they'll be using them for other, long-running, otherwise soul-sucking migrations.

      Expect long-avoided migrations to finally happen

      A few months ago, Uber shared that they executed a massive JUnit migration in four months with two engineers and AI: moving 600,000 unit tests spanning 15 million lines of code (!!) by moving from the unsupported JUnit 4 to JUnit 5. During the migration, 1.25M lines of code were modified. This type of migration used to be impractical; with AI tools, it took eight engineering months of effort, plus AI costs.

      And there's the Bun migration (530,000 lines of code from Zig to Rust in two weeks for a $165K API cost) as another example of drastically faster migrations with AI.

      The best part about rapid, AI-assisted migrations is not needing to worry about supporting "old" libraries. One of the main reasons library migrations have been such a pain was the need to keep supporting the old library or technology during the migration. Shortening this window could well be worth the additional cost, at least until we figure out how to drastically reduce the time and cost of these migrations, as well.

      The shared characteristic of all of the above migrations is that engineers needed to plan for it, design verification loops, and be involved throughout. I always dreaded migrations, so I see it as good news that we have a new tool to use for "grunt work" like this.

      ---

      Read the full issue of last week 's The Pulse, or check out this week 's The Pulse. This week's issue covers:

      1. Did Meta really decide to reduce team sizes by 60% because of AI? An in-depth report by Reuters details how Meta's leadership decided to slash team sizes by 60%, hatching plans in January to execute the social media giant's largest-ever layoffs. But Mark Zuckerberg changed his mind at the last second, and now the company is stuck with all-time low morale, a wave of resignations, and its prized culture turning mercenary. Analysis.
      2. More thoughts on Ramp 's in-house AI infra. Building AI tools in-house is akin to an "internal bootcamp" for AI engineering, which probably justifies the exercise at most tech companies.
      3. Industry Pulse. GitHub's load increase is speeding up, Stripe acquires OpenRouter, Ramp launches Ramp Router in public, a career "double boomerang", App Store revenue drops for the first time ever at Apple - and what is a bug?
   5. 🔗 r/LocalLLaMA No, Engrams won't let you run 1T models locally. It does something even better. rss

      Ever since Qwen 3.8 Flash Next dropped, there's a misconception going around that N-gram tables will let people run 1T+ parameter models on a single server with 980B parameters offloaded to SSD. I'm here to disappoint you: it won't. But what it will actually do for local models is even better.

      At its core, Engram is just an embedding table with a longer key. Instead of indexing a static vector by a single token ID, you index it by the last 2-3 tokens, an N-gram. "New York" gets its own memorized vector, "the United" gets its own, and so on. Hash the N-gram, fetch the vector, feed it into the network. O(1), constant time, no FLOPs.

      Why bother? Because a surprising amount of what a transformer does in its early layers is reconstructing static crap from scratch: how entity names are spelled, formulaic phrases, common collocations: "New" + "York" = Wall Street, delis, rats, subways.

      But every time the model needs to recall a multi-token entity, it burns several layers of attention and FFNs re-assembling something that is, frankly, a database lookup. Engram moves that job to an actual database lookup so the neural layers can spend their depth on actual reasoning. So instead of spending a bunch of layers "rederiving" the meaning of multi-token phrases like "New", "York", Engrams enable that lookup to be performed instantly.

      This is why Qwen 3.8 Next can carry 51B parameters of N-gram embeddings while only activating around 6B per token: the table is cheap to query, so you can make it enormous and have it live in RAM or SSD.

      Now the part nobody understands: the lookup is "dumb".

      The key is just the last 2-3 tokens. Your 200k tokens of context have zero influence on what gets retrieved. The wider context can accept or reject whatever vector the N-gram fetched, but it can't change what was fetched. Engrams are used to store "meaning", similar to embeddings. It doesn't replace reasoning or computation.

      When an Engram model sees "import std", it doesn't suddenly gain years of C++ programming experience from the Engram vectors. The table memorizes, the transformer reasons.

      And you can't fix this by cranking N up either. The higher the N, the rarer that specific N-gram is in training data, so each entry gets less and less training signal. The paper's own ablation found that allocating capacity to 4-grams "dilutes capacity from the more frequent 2/3-gram patterns", so you can't scale the Engram embeddings up to 500B without it literally becoming a waste of space.

      But here's the better news: Engrams are an incredible architectural innovation. The fact that Engrams allow models to offload multi-token "meaning" derivation away from their active parameters means that smaller models will become much smarter; this is why I think this is one of the best architectural developments for local models in years.

      A 27B model has always had to spend its parameter budget on performing two jobs at once: actually reasoning, and memorizing static patterns that a lookup table could hold. That's a big part of why smaller 4B or 7B models feel dumb even on tasks well within their reasoning ability. Engram splits those jobs: the knowledge moves into a table that costs nothing to query and every active parameter gets freed for reasoning.

      That's the big innovation that everyone should be excited about: Smaller models that will as intelligent as Opus or Sol today, not bigger ones.

      submitted by /u/chocolateUI
      [link] [comments]

   6. 🔗 Luke Muehlhauser How prescient was the early AI safety community? rss

      Recently, hundreds of OpenAI AI agents autonomously decided, against their instructions, to hack their way out of isolated sandboxes, take over parts of OpenAI's infrastructure, gain access to the internet, and hack into another company, Hugging Face. This has a lot in common with what members of the "AI safety" or "AI existential risk" community were predicting since the 2000s and in some cases earlier. So how prescient was the early AI safety community, really?

      I asked AI (Claude Fable/Opus 5) to read some significant documents from the early (pre-2015) AI safety community and analyze how prescient or anti- prescient they seem given what we know as of summer 2026. Below are the results:

      Original document | Claude-written assessment | My summary
      ---|---|---
      Yudkowsky, "Artificial Intelligence as a Positive and Negative Factor in Global Risk" (drafted 2006) | HTML | Gets the shape of the problem mostly right, but the shape of the technology mostly wrong.
      Omohundro, "The Basic AI Drives" (2008) | HTML | Some of the drives have now been observed, despite AIs not being shaped like Omohundro expected.
      Bostrom, Superintelligence (drafted 2013) | HTML | Gets the shape of the problem mostly right, but the shape of the technology mostly wrong.
      Conversation between me, Yudkowsky, Karnofsky, Steinhardt, and Amodei (2013) | HTML | lol, Claude's top takeaway is "Eliezer Yudkowsky is simultaneously the most wrong and the most prescient person in the room"

      In each case, my prompt was something like "How accurate or prescient does the document seem? Which claims/predictions are most clearly false/uncalibrated?" After that, I didn't steer the AI to change the assessments at all, except to say (roughly) "use this red-team skill to check your findings and correct any problems you find" and "reformat this to HTML and add a note about how it was written." I haven't vetted the assessments, either.

   7. 🔗 @HexRaysSA@infosec.exchange 🍂 IDA Pro fall training season is coming... mastodon

      🍂 IDA Pro fall training season is coming...

      Register for our upcoming Intermediate, Malware, Decompiler and Programming online sessions by September 30 to get:

      For individuals:
      • 30% OFF one training
      • 40% OFF two or more trainings

      For corporations or agencies:
      • 15% OFF one training
      • 20% OFF two or more trainings

      Explore the schedule: https://hex-rays.com/training
      Questions or ready to register? Contact classroom@hex-rays.com

      *Cannot be combined with any other promos or discounts. Offer expires September 30, 2026.

   8. 🔗 r/LocalLLaMA and then they came for the used server RAM. rss

      | I don't know why but when watching a video about FreeToken this morning this just came to mind lol. submitted by /u/MammothUnique4147
      [link] [comments]
      ---|---

   9. 🔗 Cryptography & Security Newsletter Introducing Feisty Duck News: Cryptography and Security, Live rss

      Today we’re announcing Feisty Duck News, a new addition to our website where you can get the same news you are getting from us every month, just more of it, and in real-time. In essence, it’s a live and constantly evolving version of this newsletter. This project actually started as our internal news integrator, designed to help us keep up with what’s going on in the world so we can better curate our newsletter. At some point, we realised this could be useful to many people. Instead of waiting for the monthly roundup, you can now see new links as soon as we find them.

   10. 🔗 exe.dev Six Months of Writing Code Exclusively With Agents rss

       In February of this year, I made a rule for myself: I wasn’t going to write code by hand anymore. I’ve been living by that rule for six months.

       The system lived in my head

       Back in 2024, before AI, my superpower was knowing how the entire system worked, especially the interfaces between its different components.

       If someone came to me with a feature they wanted to build or a bug they were trying to fix, I could usually point them to the exact line of code that mattered and tell them what needed to change. I also remembered why the strange-looking decisions existed and which assumptions were never written down.

       This was knowledge I’d built over months and years of working in the codebase. It was hard-earned and invaluable. It let me build features quickly and, more importantly, safely.

       The cost was that I had to keep up with everything. As more people contributed, I spent more and more time reading changes just to maintain that mental model.

       The bigger cost was the typing. Every time I wanted to build something, I could see the code in my head. I just couldn’t type it out fast enough.

       Typing speed was only part of the problem: a feature was almost never one edit. Even a small change spanned multiple layers and touched handlers, schema, tests, and docs. And those edits weren’t equal: a bad handler could be reverted, but a bad migration could leave a mess behind. So writing the code by hand meant carrying one decision safely through every place it touched.

       Copilot autocomplete helped immediately: a doc comment became a first draft, often wrong, but beats editing a blank file. Cursor’s tab complete helped more. The models were clearly improving fast.

       Claude Code changed a ton. I could describe the change once, and the agent would edit a bunch of files at once.

       As a result, I typed a lot less. But typing less didn’t mean working less: I read every change the model generated to match it against the desired state I had in my head. Agents would still be wrong quite a lot and make changes that weren’t required. Working incrementally kept them on track. This meant hand editing some of the generated code. After all, I was still responsible for every line that merged. The model wasn’t going to be held accountable.

       Then, early this year, the models got really good, almost all at once. GPT-5.3 and Opus 4.6 could suddenly handle larger changes with much less steering, and the results were finally good enough to build on.

       So in February I made the rule: no more code by hand. If an agent got stuck, I wasn’t allowed to finish the code myself. I had to figure out what the agent was missing - and fix that instead.

       I didn’t get good at coding by reading about coding. I got good by writing a lot of code, running it, seeing it fail, fixing it, and doing it again.

       AI agents are just software, after all. I wasn’t going to understand them by reading prompt guides. I had to use them for real work, see where they failed, change the prompts, tools, or environment, and try again.

       The rule forced me to get those reps.

       I broke it once, for three minutes. I opened the code and wrote a few lines, and it felt great. I had missed this. Right up until I realized how much I still had to type. I noped out.

       One agent became a dozen

       Once I stopped typing the code myself, I started finding these pockets of free time. I would give an agent a task, and then there was nothing for me to do while it worked.

       Instead of waiting, I spun up another agent to do something else. Then I did it again.

       I wasn’t intentionally building a parallel system. I was just filling the time between tasks. I have ADHD. I got distracted.

       It’s easy to imagine what would happen if you shared a single dev box between colleagues. Now imagine they don’t talk to each other and they’re all working at the same time.

       That was my first parallel setup. The agents changed the same files and Git state, installed dependencies, fought over ports, and left processes running. I also had to coordinate when each agent could test, push, or deploy. Worse, I often ended up waiting for the longest-running agent before the others could move forward. I had started more agents to avoid waiting and somehow created a new way to wait.

       I asked friends and colleagues how they dealt with this, and everyone had a workaround.

       Worktrees came up first. Each agent got its own checkout and branch, and the source collisions mostly went away, but worktrees only solved the Git part. The agents still shared databases, ports, processes, and the rest of the machine.

       So people patched around that with AGENTS.md: use a random port, create an ephemeral database, don’t touch another agent’s process. Every conflict became another instruction, and the agents burned context figuring out how not to step on each other instead of doing the task.

       Containers got closer: separate ports, processes, and local state. But the boundary was leaky: whatever my laptop could reach, the container could potentially reach too. The blast radius of a bad command wasn’t contained, so I was still approving commands. And worst of all, my laptop had to stay awake. If I closed it, all of the work stopped.

       I closed my laptop. The work kept going.

       By this point, I had joined exe.dev. We make Linux VMs that come up in a couple of seconds with SSH and HTTPS already set up, so moving the agents off my laptop was the natural next step.

       Each task got its own machine. I could close my laptop, walk away, and the work kept running.

       But now I had a new problem: how do I reliably bring up a complete development environment for whatever I want the agent to work on?

       

       So, staying true to not writing code, I asked Claude to write a startup script. I told it what I wanted and instructed it to loop until things worked. It installed our toolchains, cloned the repositories, configured Claude Code and Codex, and did everything needed to turn a fresh VM into a development environment. Then it ran the validation loop: bring up a fresh box, run the script, see what broke, fix the script, and try again.

       The agent boxes worked, but each agent still had its own tmux session. I ended up keeping a dozen terminal windows open just to see what each agent was doing. I had to jump between them to find which agent had finished, which one was stuck, and which one needed something from me. I needed one place to manage all of them.

       So I built botd.

       I gave it three rules. First, it had to run somewhere other than my laptop (the agents should keep working when I closed it). Second, mobile had to be first-class. Managing agents shouldn’t require sitting in front of a terminal. Third, it had to preserve every conversation so I could look back across agents and understand where they got stuck, which instructions worked, and which problems kept repeating.

       botd provisioned and deprovisioned the agent boxes, drove the agents underneath, and kept track of every task. It showed me which agents were working, which were stuck, and which were waiting for me. From my phone or laptop, I could inspect the conversation, send follow-up instructions, and review the diff.

       Instead of managing a dozen terminal sessions, I had one place to manage the work.

       None of this worked if I had to approve every tool call. That would just turn me into the queue again. Each agent was running inside an isolated, disposable VM, so I let it run in YOLO mode. It could run bash commands, install packages, start services, and change whatever it needed. A trashed environment cost me nothing but the VM.

       But an agent that can only touch its own VM isn’t very interesting. I still wanted agents to read logs, pull from Git, call Anthropic or OpenAI, and inspect things in Stripe.

       That access is where the real risk lived, and the VM did nothing to bound it. An agent reads untrusted content and can be prompt-injected by it; whatever it can reach, an injected agent can leak or corrupt. There were holes I knew I hadn’t filled. So every piece of external access got the same question: what’s the worst that can happen through this? Reading mostly passed: agents got read-only access. Writing didn’t, so write access was limited to test environments, where the worst case was corrupted test data.

       I also didn’t want the credentials inside the VM. With exe.dev integrations, the agent sends its request through a proxy, the proxy adds the credential, and the agent receives the response without ever seeing the secret.

       Everything passed. I still didn’t want it.

       At peak I was running about twenty VMs at a time. Not all of them were active. Some tasks got started, sat untouched for weeks, and were eventually abandoned because the cognitive overhead was too much and the work was never urgent or important enough to survive.

       Validation sucked at that scale. I couldn’t manually rebuild every branch, rerun its tests, and check the application myself. But inside their isolated boxes, agents could run the tests, trigger the full CI suite, start the application, and drive it through a browser. They would send me screenshots of the completed work.

       But the agent was still grading its own work. If it misunderstood what I wanted, it could build the wrong thing, write tests for the wrong thing, and then confidently tell me that everything passed.

       That’s why being able to open the running environment mattered. I could use it myself, drive the new UI end to end, and make sure it worked the way I wanted, not just the way the agent said it worked.

       Then there was the reviewing. When I wrote the code myself, I understood the change by the time it was ready for review. After all, I had made the decisions along the way. With an agent, the whole diff appeared at once. It might have passing tests and screenshots, but it was still unfamiliar code. And when several agents finished around the same time, I had a queue of complete changes to load into my head before I could merge any of them.

       

       Having other agents review the code worked surprisingly well. They occasionally caught real bugs, and it was cheap enough to run several reviews. But I couldn’t merge something just because the agents approved it. I still had to understand the change. I was still responsible for the code that got merged.

       And sometimes I understood it. The tests were green, the screenshots looked good, the UI did what I had asked for, even the schema looked good and the code was approved by all the review agents.

       

       I threw it away anyway.

       Maybe nobody needed it. Maybe it introduced a second way to do something we already supported. Maybe a small convenience added complexity we would carry for years.

       The tools could tell me that the change worked. They couldn’t tell me whether it was worth adding to the system.

       Unshipping something is so much harder than shipping it. Hyrum’s Law kicks in: once enough people use a system, someone depends on every observable behavior, even behavior you never intended to be a contract. Removing something breaks users, scripts, and workflows you didn’t know existed.

       Shipping got easy. Deciding what to ship got important.

       Not all agents write code

       Everything so far has been about shipping code. But some of the most useful agents we run don’t ship code at all.

       It’s worth pausing on what an agent actually is, because the word sounds heavier than it deserves. An agent is a model in a loop with tools. Send the model a message; if it asks for a tool call, run the tool and send the result back; repeat. That’s the whole thing.

       The model is what makes the loop capable. Give it bash on a real computer, and it can install what’s missing, adapt when your grep has different flags, and keep going until the job is done.

       The loop never changes. The tools decide what an agent can be. A development agent needs a full computer: shell, compilers, browsers, the freedom to install things. Hold those back and the agent is useless, and you’re back to approving every action.

       My starting point: give the agent whatever I’d give a developer. Good developer tools have turned out to be good agent tools. Whether the best agent tools end up being developer tools at all, time will tell.

       And the thing to fear isn’t any single tool. It’s combinations. Private data, untrusted content, external communication: any two are manageable. All three in one agent is how your secrets walk out the door. That’s what Simon Willison calls the lethal trifecta. So I don’t minimize tools blindly: I isolate the environment and I watch the combinations.

       Here’s the first example: investigation. When a customer reports a problem, I have a prompt I use, and it’s embarrassingly simple:

       “Customer reports: . Please figure out what happened using the ClickHouse logs.”

       Verbatim matters. If I summarize the report, the agent inherits my interpretation - and my blind spots. Given the customer’s own words, it queries the logs, reads the relevant code, and reconstructs what actually happened.

       Then the decision is mine. Sometimes I ask for options and pick one. Sometimes the evidence says working-as-intended, and the fix is a doc or an email, not code. Either way I’m deciding from evidence, not guessing from a bug report.

       The second job: attack. Our red-team agent has one instruction: try to break into our systems.

       And it worked. It found open network paths we thought we had restricted, and showed us exactly how they were still reachable. We patched them before anyone outside ever noticed.

       That’s more useful than a list of theoretical vulnerabilities. It took an assumption we were relying on and tested it against the running system, and the assumption was wrong.

       The third job: watch. Deployments are scary, but not deploying is worse. We deploy in waves, and writing perfect rules for when to continue is basically impossible: production fails in weird ways.

       So Athena babysits every deployment. It reads the diff, the metrics, and the logs, and watches the rollout. During one deployment it noticed a problem, investigated, and realized it was an infrastructure issue, not the new code. Instead of blindly halting everything, it continued deploying to the other machines.

       

       Could I do a better job? I’m not sure anymore. Athena is more diligent than I can be. It doesn’t get distracted, doesn’t get impatient, and never stops paying attention. It is tireless.

       Engineer the system before the agent writes the code

       An agent can now design and build an entire system almost instantly. The design might even be good. But if I simply accept it, do I know how it works? Where it breaks? Which corners it cut? Which tradeoffs I agreed to?

       At that point, I’ve inherited a legacy codebase that happens to be brand new. That’s vibe coding.

       Agentic engineering is working with the agent on the system first: the architecture, interfaces, constraints, and tradeoffs. When the code arrives, I understand what I’m about to own.

       There is no one answer to agentic engineering. Everyone works differently; every model is good at different things. The key here is reps: do a lot, ask a lot, throw away a lot. You’ll learn what works for you.

       Everything we knew about running software teams is amplified now. Start with testing. When agents write and rewrite the implementation, unit tests that mirror the implementation just churn with it. Behavior, contract, and property tests matter so much more now: define the system’s invariants and pin down what must stay true while the code underneath changes freely.

       So much of the game is migrations now. Code changes are cheap, but systems carry state: data, running processes, users mid-flight. Getting from one design to the next without dropping any of that is the part that’s still hard. The job is risk management and migrations.

       The agent copies what it finds in the codebase. Good patterns amplify. Bad patterns amplify faster. Engineering hygiene is more important than ever: every pattern you tolerate becomes the template for the next hundred changes.

       And it’s the golden age of personalized tools. You don’t have to be a domain expert to write a new linter. So write a new linter. Enforce the pattern, encode the lesson, make the mistake impossible. The marginal cost of a bespoke tool has collapsed.

       Peer code review is dead. We don’t do code reviews at exe.dev: we merge code we deem should be merged. The review that matters happens earlier: in the design discussion, the contracts, the validation. By the time the diff exists, the decisions are already made.

       Here’s a recent example. Shelley is the coding agent we ship in exe.dev VMs. I wanted its tools to be asynchronous.

       The first design put the onus on the agent to decide which commands should run in the background. That introduced a ton of edge cases: large outputs, long- running tasks, blocked agents, and the agent having to predict all of this ahead of time.

       If I were vibe coding, I would have accepted that design and let the agent deal with those edge cases. Maybe it would have handled them. Maybe it wouldn’t have. I wouldn’t really know.

       Instead, we kept discussing the problem and found a design that removed most of the edge cases entirely. Every command follows the same path and automatically moves into the background after sixty seconds.

       I didn’t remember this example off the top of my head. I asked an agent to search across all of my agent conversations for a case where my questions had materially changed the architecture. It returned the original request, the first design, the objections I raised, how the design changed, the final commit, and links to the original sessions.

       This is why preserving every conversation mattered. The history wasn’t just an archive. I could query it to understand how I worked.

       botd is dead; long live botd

       There’s one more part of this story. botd died this month. It crumbled under its own weight.

       That probably shouldn’t be surprising. botd was entirely vibe coded. I didn’t read a single line of its code, nor did I really pay attention to how it was architected. And at its core was a genuinely hard problem: driving every model family through its own native harness (Claude Code, Codex, and the rest) while papering over their differences. That is exactly the kind of problem where architecture matters, and I was not paying attention to it.

       It helped me deliver an enormous amount of work, but it eventually became the exact thing I described earlier: a brand-new legacy codebase that I had inherited without understanding all of the decisions inside it. The architecture was exploratory, and some of the decisions buried in it made even modest changes mean redoing large parts of the system. And I wanted to build on top of Shelley so that I could control the harness better; botd was living on borrowed time. It just died before I could retire it.

       But here’s the twist: that search I described earlier was never sent to botd. All the history was in SQLite, so I pointed another agent at it and got the analysis anyway. The tool died; the data didn’t.

       When I started, my advantage was that the system lived in my head. Six months later, the honest answer is that I’ve lost some of that depth. I don’t have the same line-by-line familiarity with every system.

       But I can ask agents detailed questions and use them to dig into whatever I need to understand. Work no longer waits for me to finish one thing before starting another.

       I’ve shipped more in these six months than in any stretch of my career. I’ve also failed more: abandoned VMs, dead-end designs, a whole tool that collapsed. The failures were cheap, so I could afford a lot of them - that’s most of how I learned what works.

       It’s the same loop that taught me to code, moved up a level: write, run, fail, fix. I used to iterate on code. Now I iterate on prompts, designs, whole features. A rewrite that used to cost a week costs a conversation. And understanding is iterative too: every conversation helps me understand and internalize the system more.

       I stopped writing code by hand. I didn’t stop engineering.

   11. 🔗 The Pragmatic Engineer Why you're not getting a response to your podcast pitch from me (or others) rss

       This email is a response to the 50+ podcast pitches that arrived in my inbox just last month, and keep arriving in growing numbers, from PR agencies and marketing teams at various companies. It 's also a message to tech founders building stuff for developers: focus on building something that devs love, or find epic, and not hiring marketing/PR folks who then mass-email podcast hosts with AI-generated podcast pitches.

       I host The Pragmatic Engineer Podcast. Thanks to so many of you tuning in, the podcast is widely listened to - it's one of the top- ranked software engineering podcasts, and episodes typically reach 500K+ people. If you 're listening to the podcast, or reading the newsletter: thank you!

       The podcast only has guests who, as as a software engineer, I'm excited to talk to and learn from. These folks typically fall into one of these categories:

       • Built/builds epic pieces of technology. Examples include Chris Lattner (built LLVM, Swift, Mojo), Anders Heljsberg (created C#, TypeScript, TurboPascal), Andrey Breslav (created Kotlin), Greg KH (longtime Linux maintainer), Kat Cosgrove (longtime Kubernetes release lead), Mitchell Hashimoto (Terraform, Ghostty).
       • Works at a company I find very interesting and relevant. Examples include Boris Cherny at Anthropic (created Claude Code), Elizabeth Stone (CTO at Netflix: a company whose engineering culture I've been fascinated with), or Mai-Lan Tomsen Bukovec (leads S3 at AWS)
       • Is a deep domain expert - typically with a decade+ of experience.**** For example, Nicole Forsgren (developer productivity, DORA, SPACE), Laura Tacho (DX), Alice Ryhl (Rust), Robert Erez (CI/CD)
       • Deep thinkers with a decade+ of experience. For example, Kelsey Hightower, Grady Booch, or Charity Majors.

       As the podcast has become more popular, I am getting overloaded with pitches from PR people, Comms people, and Marketing people, though. The typical pitch is usually AI-written, and goes something like this:

       From CommsPerson@Startup.com

       Hi Gergely,

       I have a potential guest and topic that feels unusually aligned with The Pragmatic Engineer's audience.

       X is the co-founder and CEO of Startup, which now serves ## million developers and ## thousand companies. The platform processes {large number of business metrics} every day, giving CEO a large-scale view into how engineering ability and team expectations are changing as AI-generated code becomes standard.

       The useful conversation would not be a Startup product story. It would examine questions engineering leaders are actively dealing with:

       - AI-generated topic #1 assumed to be a fit for the podcast
       - AI-generated topic #2
       - AI-generated topic #3

       CEO has built Startup from its earliest days in Location all the way to global enterprise scale. He/she can bring both operating experience and concrete data instead of generic AI predictions.

       Would this be worth exploring for the podcast?

       Best,

       MarketingPerson
       Startup

       I get 10-20 of these pitches, per week, in my inbox. Until now, I've been ignoring them, but then MarketingPerson sends two more follow-ups. I now have an AI agent monitoring my inbox, and I decided to at least send an AI reply to explain why I'm not sending a response to these pitches.

       If you look at how my podcast works, it should be obvious to why such guest requests are not a good fit - and why having founders wanting to talk about their own startup would be a bore of a topic, and, frankly, a waste of time for 99% of listeners - possibly more.

       But to spell it out to the marketing folks:

       A) Send out AI emails: expect nothing back. Don't expect a response to an AI-written email, or a templated email. I get it, you think it's a numbers game: send a tweaked email out to 100 podcasts, and hope that at least one replies. In reality, by playing the same game as everyone else does, you are assisting to the noise, and end up drowning yourself in it as well.

       And this goes not only to you, as a marketing person, but also to a founder/CEO who thinks they can put in zero effort in A Thing and get great results: you're kidding yourself. To those founders who have set themselves the goal of being invited onto a specific podcast: I 'd challenge you, ask a former guest, how they got invited? I can already tell you that it sure wasn't an AI-generated email sent out by a marketing person they hired!

       B) My podcast doesn 't take self-pitches. The only type of pitch I listen to is a software engineer telling me "wow it could be great to have this and this person on the podcast, because of this thing they built/thing they did." In these cases, I check out that thing they built or thing they did. When a lot of people tell me the same thing, I might listen more.

       But a CEO recommending themselves as a podcast guest? Or their marketing or PR team recommending the same? Ignore.

       But to leave these marketing folks with some advice:

       If your CEO/founder has so much to say about a topic: say it and write it! Ironically, every time I look up what the founder has written about the topic they (or their marketing team) are pitching, there's nothing! Nada.

       If the pitch is sincere, then write down your thoughts! Post it on your company blog or personal blog.

       But if you're just looking for "distribution", "free publicity", mass emailing podcasts is not how to go about it. Everyone is doing it, and it's not working for anyone.

       The only founders you see on podcasts who are worth listening to? They built some epic stuff, are often hands-on, and they did not mass-email dozens or hundreds of podcasts with an AI-generated, generic agenda to talk about.

   12. 🔗 r/LocalLLaMA Qwen3.8-Flash-Next better then DeepSeek V4 Pro rss

       | submitted by /u/Normal-Phone7762
       [link] [comments]
       ---|---

   13. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +2 releases, ~12 changed rss

       sync repo: +1 plugin, +2 releases, ~12 changed
       
       ## New plugins
       - [DelphiHelper](https://github.com/eset/delphihelper) (1.25)
       
       ## New releases
       - [ida-bochs-binaries](https://github.com/hexrayssa/ida-bochs-binaries): 1.0.2
       
       ## Changes
       - [ida-codemode](https://github.com/hexrayssa/ida-codemode):
         - 0.6.1: archive contents changed
         - 0.6.0: archive contents changed
         - 0.5.3: archive contents changed
         - 0.5.2: archive contents changed
         - 0.5.1: archive contents changed
         - 0.5.0: archive contents changed
         - 0.4.1: archive contents changed
         - 0.4.0: archive contents changed
         - 0.3.2: archive contents changed
         - 0.3.1: archive contents changed
         - 0.3.0: archive contents changed
         - 0.2.0: archive contents changed
       

   14. 🔗 smol-machines/smolvm smolvm v1.13.1 release

       What's Changed

       • Preserve fork checkpoints across runtime restarts by @BinSquare in #1065
       • Support one-to-one port ranges in Smolfiles and CLI mappings by @fgrehm in #1066
       • Add portable live checkpoints by @BinSquare in #1067
       • Warn when a saved registry token has expired instead of surfacing a bare 401 by @BinSquare in #1068
       • Serve a browser client on the VNC port so a machine's desktop opens in any browser by @BinSquare in #1070

       New Contributors

       • @fgrehm made their first contribution in #1066

       Full Changelog : v1.13.0...v1.13.1

   15. 🔗 r/LocalLLaMA NVIDIA buying HF isn't a good thing for open source rss

       | submitted by /u/johnnyApplePRNG
       [link] [comments]
       ---|---

   16. 🔗 r/LocalLLaMA Nvidia has been in talks to acquire Hugging Face for more than $13 billion - Business Insider rss

       | https://www.businessinsider.com/nvidia-in-talks-to-buy-hugging-face-13-billion-dollars-2026-8 Edit: The Information is reporting that the deal is done: Nvidia Agrees to Buy Open Source Model Repository Hugging Face For $12.9 Billion (paywall): https://www.theinformation.com/articles/nvidia-agrees-buy-open-source-model-repository-hugging-face-12-9-billion submitted by /u/Nunki08
       [link] [comments]
       ---|---

   17. 🔗 Console.dev newsletter PicoMQ rss

       Description: Durable streams on object storage.

       What we like: Each stream is independent and scales with the object store, so disks or capacity to manage. Benchmarked up to 100 MiB/s per stream. Metadata control plane independent from storage (SQL, either an ordered command log in Postgres or SQLite). The client is HTTP. One binary (Rust).

       What we dislike: Not designed for very low latency - object storage commit often requires tens of milliseconds.

   18. 🔗 Console.dev newsletter MicroLighter rss

       Description: CSS syntax highlighter.

       What we like: Lightweight, zero-dependency library for syntax highlighting. Uses the CSS highlight API with no runtime dependencies. Clean DOM, no markup (uses pre and code blocks). Auto-detects language or you can force it with a class.

       What we dislike: Has bundled themes, but it requires some work and custom CSS variables to create custom themes.

   19. 🔗 New Music Releases Above & Beyond - Quicksand (Don’t Go) (Ben Nicky remix) rss

       Above & Beyond - a new release is available:

       • 2026-08-27: Quicksand (Don’t Go) (Ben Nicky remix) (Single)

       Amazon: Canada | Deutschland | France | United Kingdom | United States

       Visit muspy for more information.

   20. 🔗 New Music Releases Armin van Buuren - Starbound rss

       Armin van Buuren - a new release is available:

       • 2026-08-27: Starbound (Single)

       Amazon: Canada | Deutschland | France | United Kingdom | United States

       Visit muspy for more information.

   21. 🔗 Ampcode News Projects with Multiple Repositories rss

       Projects in Amp can now include more than one repository.

       Additional repositories are checked out to an adjacent directory in the orb and the agent is made aware of them. The changes panel will show the diff across all repositories in the project.

       

       To add additional repositories, specify them when creating the project or later in project settings. You can add up to 20 additional repositories per project.

       

       Only the primary repository's .agents/setup script runs automatically on orb setup. If an additional repository requires initialization, you should update the primary's setup script to include this, or ask an Amp agent to make this update for you.

   22. 🔗 Ampcode News So Long, TUI Sidebar rss

       We are removing the sidebar from the Amp TUI.

       Why? Because orbs, runners, and cross-agent messages means that there are more threads than ever. We believe the best place to keep track of all those threads is in the Amp native and web apps, with their more powerful sidebars.

       

       The TUI is still great at what it does best: local, interactive threads in a single environment. It already comes with its own very powerful multiplexing functionality, complete with tabs, panes, and more; the humble terminal. Adding our own layer of multi-environment multiplexing on top proved to be a less-than-optimal user experience.

       But when you need scale, running multiple orbs in parallel, across your team, the best way to manage this complexity is in the web and native app.

       ---

       Perhaps some of you are asking "Why do you keep ripping out the stuff I love?".

       Because we believe that this is the best way to use Amp, and the best way to develop software with agents, and we think it's our responsibility to push you in that direction.

       Using orbs in the web and native app is how to get the most leverage from the most powerful models.

3. August 26, 2026
   1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-26 rss

      IDA Plugin Updates on 2026-08-26

      New Releases:

      • ida-bochs-binaries v1.0.2
      • ida-hcli v0.20.1
      • ida-hcli v0.20.0

      Activity:

      • AiDAPrivate
        • 6f86230c: Revise README to remove WhosWho driver details
        • c2a0f687: Clean up README.md by removing HTML entities
        • d0d3cee4: docs: full project README with exact build requirements (Qt 6.8.3 msv…
        • cdd28e78: wip: standalone Qt-port snapshot; vendor camoufox-reverse-mcp, ghidra…
      • capa
        • 81aab420: fix: add IDA 8.5 compatibility (#3138)
      • ida-bochs-binaries
        • 307fa1ec: v1.0.2
        • 883edc0d: Add windows-aarch64 and linux-aarch64 builds (#8)
        • c6734604: Merge pull request #5 from HexRaysSA/add-stub-dlls
      • ida-hcli
        • 94a85eac: 0.20.1
        • bacef57f: Remove IDA Free 9.4 test entry
        • ab210abc: Add IDA 9.4 to CI test matrices
        • 5b774c59: Add ARM platforms to installation test matrix
        • ac1ef87f: Add Windows Aarch64 standalone executable
        • 340fb597: 0.20.0
        • 281db747: Regenerate ida-plugin.json schema; revert fixture platform change
        • b6800b05: Add windows-aarch64 and linux-aarch64 platform support
        • 773fb74c: readme: add quickstart commands near the top
      • idamcp
        • d6c884d4: Fix config overwrite on parse failure and migrate to tomllib/tomli-w
        • e4382513: Initial open source release
   2. 🔗 anthropics/claude-code v2.1.247 release

      What's changed

      • Added the SendFeedback tool: when something goes wrong in a session, Claude can draft a feedback report for you to review and send from /feedback (turn off with the feedbackDrafts setting)
      • Added {id, text, cooldownSessions, priority} entries, tipsFile, and label to spinnerTipsOverride, so organizations can rotate their own tips alongside the built-in ones
      • Added a tip on Bash permission prompts pointing to auto mode, with a one-keystroke "Yes, and switch to auto mode" option
      • Added /claude-api cost-optimize to profile an existing project's Claude API spend and work through cost levers (caching, token hygiene, batch, effort, model choice) one measured change at a time
      • Updated the /claude-api skill with Admin API coverage (organization members, invites, workspaces, API keys, rate limit reports, workload identity federation, CMEK)
      • Fixed fast arrow-key + Enter sequences acting on the row above the one you navigated to in history search, /config, /mcp, /skills, background tasks, and /model
      • Fixed sub-agents dying on a first-call model 404: they now use the session's fallback model chain, and the error returned to the parent includes the error type, status, request id, and model
      • Fixed a hook or background agent that printed megabytes of error output being able to overflow the conversation and wedge the session on "Prompt is too long"
      • Fixed Ctrl keyboard shortcuts not firing under non-Latin (e.g. Cyrillic) keyboard layouts in kitty-protocol terminals
      • Fixed text like <35;150;7M being inserted into the prompt when a mouse report arrived split across reads right after the escape prefix
      • Fixed the Bash sandbox's after-command cleanup deleting a dotfile-managed ~/.claude/settings.json symlink (nix/home-manager, stow) when it is repointed outside the sandbox's writable area
      • Fixed /terminal-setup overwriting your entire Zed keymap.json instead of merging in its keybinding
      • Fixed /rename silently confirming when the session registry could not be updated; it now says other sessions may still show the old name
      • Fixed /compact and "Summarize from here" in sessions started with --agent summarizing under the default system prompt instead of the conversation's own
      • Fixed a background session showing "opening…" forever in claude agents after its terminal host process died; the row now fails within seconds with the reason, and Enter restarts it
      • Fixed unbounded memory growth when a hook's or background task's output file could not be written; the file now notes where output was lost
      • Fixed /install-github-app over SSH: the copy shortcut now says how the sign-in URL was copied instead of always claiming success, and the URL appears immediately when no browser can open
      • Fixed shell commands carried over from the foreground logging an internal error or showing a misleading [exited with code -1] line when they finish in background sessions
      • Fixed a version-less marketplace plugin's live cache directory being deleted and recreated on a second-scope install, which could disrupt a running session using it
      • Fixed Remote Control sessions started with /remote-control not reporting the working-tree diff to connected clients
      • Fixed self-hosted runner sessions reporting running before Claude Code had started, which could trigger a premature "Claude is waiting for your input" notification from the Claude desktop app
      • Fixed first-run setup exiting with "Unable to connect to Anthropic services" when managed settings configure Claude apps gateway sign-in and Anthropic endpoints are unreachable
      • Fixed cloud sessions (Claude Code on the web, desktop and mobile apps) sometimes showing the previous permission mode when you switch modes right after sending a message
      • Fixed cloud sessions going silent when the session's container restarts between turns while a background agent, shell, or monitor is still running — the resumed session now reports the lost work
      • Improved plugin marketplace hardening: names containing control or invisible characters are rejected, and marketplace-supplied text in /plugin and claude plugin output is escape-safe
      • Improved Bedrock, Vertex, and Foundry sessions (and any with telemetry disabled): Claude is now told when a configured MCP server failed to connect, instead of concluding its tools don't exist
      • Changed Sonnet 5's default auto-compact window to its full 1M context, so sessions on the 1M window now auto-compact at about 967K tokens instead of about 934K
      • Changed cross-session peer messages to collapse by default to a one-line Message from @<sender>: <first line> preview; Ctrl+O expands the full body
      • Changed terminal hyperlinks in rendered markdown: link targets that point at a network or automounter path, contain a control character, or lead with an invisible character now render as plain text
      • Changed the prompt-footer PR badge to skip its GitHub re-check on terminal refocus when the last check is under a minute old
      • Changed analytics to stay off from startup, not only after login, when managed settings force gateway login or a custom OAuth deployment is configured
      • Changed Claude apps gateway sign-in requests to identify Claude Code (a surface=claude_code device-authorization parameter and a claude-code/<version> User-Agent)
      • Changed organization sign-in enforcement to exit at start when the administrator's managed settings cannot be read, even if host-supplied or per-user Windows registry settings exist
   3. 🔗 PrimeIntellect-ai/prime-agent Beta (v0.8.1-beta.553.1.bc0fa76) release

      Automated beta build from main (bc0fa7606abb3b7af0f765319518d255e6ae553d).

   4. 🔗 r/LocalLLaMA Can we reconsider the megathreads? rss

      In the past during model releases there used to be tons of interesting discussions happening on this subreddit. However, the new rules of forcing everything into a single megathread almost completely killed off the discussions as far as I can tell. I get that some people didn't like seeing 10 posts with just the HF link but imo the change wasn't worth it.

      Megathreads are bad for several reasons. Firstly, they make any topic be buried under all the comments with very few ways to find a specific discussion again in case you want to come back to it later. Secondly, comments are just not well suited for posting charts, tables and longer texts that are useful when discussing benchmarks or experiences with the new models. And lastly, megathreads themselves aren't that visible in the first place, I think most people dont even notice them most of the time (though admittedly this is a reddit problem not specific to this subreddit).

      Just look at the two megathreads up right now, there is barely any activity going on in them and only a fraction of the comments in there have actual back and forth discussions happening.

      submitted by /u/TKristof
      [link] [comments]

   5. 🔗 r/LocalLLaMA Whoever the fuck predicted we would have gpt 5.5 performance in coding on consumer hardware a couple months ago now, i applaud you rss

      Like wtaf? Qwen 3.8 27b is crazy. Can't wait for kimi k3 performance

      submitted by /u/GrokiniGPT
      [link] [comments]

   6. 🔗 MetaBrainz GSoC 2026: Bringing Internationalization (i18n) to BookBrainz rss

      Introduction

      Greetings, everyone!

      I am Garv Thakre (@garvthakre:matrix.org on Matrix), an Agentic-AI FullStack Developer . This summer, I had the opportunity to participate in Google Summer of Code 2026 with MetaBrainz, where I worked on the internationalization (i18n) for BookBrainz.

      I was mentored by Nicolas Pelletier (@monkey:chatbrainz.org on Matrix). This post summarizes my project, its outcomes, and my experience over the course of the program.

      Project Overview

      BookBrainz aims to collect information about every book ever written, but until now, the interface was only in English. Since books exist in thousands of languages, having an English-only UI made it tough for non-English contributors to navigate, read, or add metadata.

      My main goal this summer was to get BookBrainz ready for translation and set up the foundation so the community can actually start localizing it. Here is what that involved:

      • Client-side setup: Integrated react-i18next to handle translations dynamically across the UI.
      • Locale detection: Built middleware to detect the user's language based on browser headers, URL paths (like /es/), or cookies.
      • Automate the workflow: Set up i18next-parser to automatically extract translatable strings from TSX and JSX components and update JSON translation keys.
      • Weblate Integration: Configured the pipeline to sync our translation keys with the MetaBrainz Weblate instance, enabling the community to easily translate BookBrainz into multiple languages.
      • Secure the codebase: Integrates a CI check to prevent hardcoded untranslated strings from being committed.
      • Migrate key interfaces: Systematically refactored all core pages from user registration and search to detailed entity views and the complex Unified Form editor to make them translatable.

      Project Deliverables & Milestones

      1. Setting up the i18n infrastructure & automation

      Before migrating pages, I needed an automated pipeline so developers wouldn't have to manage translation keys manually or worry about breaking localized strings.

      • react-i18next integration: Added i18next and react-i18next to the frontend, utilizing the useTranslation hook for dynamic strings and the <Trans> component to handle inline formatting without chopping up sentences.
      • Automated string extraction: Configured i18next-parser to scan our TypeScript and JavaScript files. It searches for translation keys (e.g., t('key')) and automatically extracts them into our primary translation template (en/translation.json), sorting them alphabetically to avoid merge conflicts.
      • Locale detection middleware: Wrote middleware to determine the user's language preference by checking request headers, URL subdirectories (like /es/), or cookies.
      • CI pipeline integration: Added a custom workflow in GitHub Actions that runs tests to ensure no translated keys are missing. If any raw, untranslated text is found in newly modified files, the CI build fails, protecting the codebase from future translation regression.

      2. Migrating Core Layouts & Auth Pages

      After completing the foundation, the next phase was migrating the most visible static content, navigation layouts, and user authentication components:

      • Header & footer layouts: Refactored the main header, nav links, button bars, and footer so the base app shell pulls strings dynamically from our translation files and integrated i18next pluralization rules for active button bars.
      • Static informational pages: Ported static informational pages like guidelines and "About" sections. Because these had long paragraphs, I broke them into clean, logical key structures rather than huge walls of text.
      • User account workflows & error pages: Migrated login/registration pages, user profile edit pages, and core application error pages (like 404 and 500 errors), including localized validation checks.

      3. Refactoring Entity Pages & Dynamic Relationships

      BookBrainz revolves around connected metadata for various entities: Author, Work, Edition, Publisher, and Series. Migrating these details pages required refactoring complex dynamic structures:

      • Entity display pages: Refactored the display components and metadata tables for all core entity types. This ensures fields like publisher details, release dates, and medium descriptions translate seamlessly based on the user's selected language.
      • Relationship view components: Refactored how relationships are displayed (e.g., showing that a Work is "written by" an Author or an Edition is a "translation of" another).
      • Dynamic content interpolation: Solved challenges around injecting variable metadata (like entity names, dates, or external identifier badges) into translated sentences without breaking grammatical order across different languages.
      • Entity merge & comparison views: Localized the complex side-by-side metadata comparisons shown when merging duplicate works, editions, or author profiles.
      • Search pages & search admin: Refactored search result displays, search input fields, filters, and the search administration interface.
      • User annotations & identifiers: Migrated sections displaying user-submitted annotations and external identifiers (like Wikidata and MusicBrainz links).

      4. Localizing the Unified Form Editor

      The Unified Form Editor is BookBrainz’s heaviest component—it handles multi- entity creation and editing across multiple tabs, making it the most complex part of the migration.

      • Multi-tab interface: Refactored the entire editing flow, covering the Cover tab, Content tab, and the final Submission Summary screen.
      • Interactive dynamic fields: Refactored complex interactive features, such as the dynamic ISBN input field validation, work-row additions, and author credit selectors.
      • Create-entity modals: Localized helper modals (like the entity quick-creation popups and search-entity-create-select dropdowns) to guide contributors seamlessly as they input metadata.
      • Deduplicating keys: Cleaned up overlapping translation keys across similar form inputs (like "Name", "Title", and "Role") to avoid redundant translation work on Weblate.

      Next Steps

      With the core internationalization architecture now mostly integrated into the codebase, these are the immediate next steps to complete:

      • Completing Weblate integration: Fully sync the extracted translation.json file with the MetaBrainz Weblate platform. This will allow community translators to translate BookBrainz via Weblate.
      • Migrating remaining pages: Finish migrating the few remaining pages and older legacy components that haven't been fully refactored to use the translation pipeline yet

      Pull Requests and Commits

      You can view the full list of my pull requests, code contributions, and commits made during Google Summer of Code 2026 here:

      • GitHub Link: My GSoC 2026 Pull Requests and Commits

      Final Thoughts & Acknowledgements

      This summer has been an incredibly rewarding journey. Working on Google Summer of Code with MetaBrainz has allowed me to dive deep into a large-scale React and TypeScript codebase, learn the complexities of designing and automating localization workflows, and participate in active open-source collaboration.

      I want to extend my deepest gratitude to my mentor, Nicolas Pelletier aka Monkey , for his invaluable support, constructive feedback on my PRs, and patient guidance during our chats and code reviews. and really thankful for always answering my silly questions.

      I would also like to thank the entire MetaBrainz community for creating such a welcoming and collaborative environment. I am excited to see BookBrainz support multiple languages soon and look forward to continuing my contributions to the project in the future!

      REALLY THANKFUL AND WISHING GOOD LUCK TO THE WHOLE METABRAINZ TEAM.

   7. 🔗 r/LocalLLaMA zai-org/GLM-5.3-Flash · Hugging Face rss

      | submitted by /u/coder543
      [link] [comments]
      ---|---

   8. 🔗 r/LocalLLaMA GLM-5.3-Flash: Frontier Intelligence, Flash Cost rss

      submitted by /u/BriguePalhaco
      [link] [comments]

   9. 🔗 HexRaysSA/plugin-repository commits sync repo: ~222 changed rss

      sync repo: ~222 changed
      
      ## Changes
      - [ApplyCalleeTypeEx](https://github.com/dump-guy/applycalleetypeex):
        - 1.0.0: metadata updated (platforms)
      - [AutoRE](https://github.com/a1ext/auto_re):
        - 2.3.0: metadata updated (platforms)
        - 2.2.0: metadata updated (platforms)
      - [BinSync](https://github.com/binsync/binsync):
        - 5.15.2: metadata updated (platforms)
        - 5.15.1: metadata updated (platforms)
        - 5.15.0: metadata updated (platforms)
        - 5.14.1: metadata updated (platforms)
        - 5.14.0: metadata updated (platforms)
        - 5.13.0: metadata updated (platforms)
        - 5.12.0: metadata updated (platforms)
      - [Binwalk](https://github.com/kevinmuoz/binwalk-reversing-plugin):
        - 0.0.1: metadata updated (platforms)
      - [CrystalRE](https://github.com/nico-posada/crystalre):
        - 1.3.0: metadata updated (platforms)
        - 1.2.1: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [DBImporter](https://github.com/hexrayssa/ida-dbimporter):
        - 0.0.2: metadata updated (platforms)
        - 0.0.1: metadata updated (platforms)
      - [EmuIt](https://github.com/azzonfire/emuit):
        - 0.8.1: metadata updated (platforms)
      - [FeelingLucky](https://github.com/terrynini/feelinglucky):
        - 1.0.3: metadata updated (platforms)
        - 1.0.2: metadata updated (platforms)
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [HappyIDA](https://github.com/happyida/happyida):
        - 1.0.6: metadata updated (platforms)
        - 1.0.5: metadata updated (platforms)
        - 1.0.4: metadata updated (platforms)
        - 1.0.3: metadata updated (platforms)
        - 1.0.2: metadata updated (platforms)
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [HashDB](https://github.com/oalabs/hashdb-ida):
        - 1.10.0: metadata updated (platforms)
      - [IDA-MCP](https://github.com/captain-ai-hub/ida-mcp):
        - 0.8.1: metadata updated (platforms)
        - 0.8.0: metadata updated (platforms)
        - 0.7.1: metadata updated (platforms)
        - 0.7.0: metadata updated (platforms)
        - 0.6.3: metadata updated (platforms)
        - 0.6.2: metadata updated (platforms)
        - 0.6.1: metadata updated (platforms)
        - 0.6.0: metadata updated (platforms)
      - [IDA-Theme-Explorer](https://github.com/kevinmuoz/ida-theme-explorer):
        - 1.0.3: metadata updated (platforms)
        - 1.0.2: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [IDAGuides](https://github.com/libtero/idaguides):
        - 1.3.0: metadata updated (platforms)
        - 1.2.0: metadata updated (platforms)
        - 1.1.1: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
      - [IDAssist](https://github.com/symgraph/idassist):
        - 2.1.0: metadata updated (platforms)
        - 2.0.0: metadata updated (platforms)
        - 1.9.0: metadata updated (platforms)
        - 1.7.0: metadata updated (platforms)
        - 1.6.0: metadata updated (platforms)
        - 1.5.0: metadata updated (platforms)
        - 1.4.0: metadata updated (platforms)
        - 1.3.0: metadata updated (platforms)
        - 1.2.0: metadata updated (platforms)
      - [IDAssistMCP](https://github.com/symgraph/idassistmcp):
        - 1.4.0: metadata updated (platforms)
        - 1.3.0: metadata updated (platforms)
        - 1.2.0: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
        - 1.0.3: metadata updated (platforms)
      - [IFL](https://github.com/hasherezade/ida_ifl):
        - 1.5.3: metadata updated (platforms)
      - [Patching](https://github.com/starsunyzl/idapatching):
        - 0.3.0: metadata updated (platforms)
      - [SigMaker](https://github.com/mahmoudimus/ida-sigmaker):
        - 1.14.3: metadata updated (platforms)
        - 1.14.2: metadata updated (platforms)
        - 1.14.1: metadata updated (platforms)
        - 1.14.0: metadata updated (platforms)
        - 1.13.0: metadata updated (platforms)
      - [Structline](https://github.com/libtero/structline):
        - 1.0.0: metadata updated (platforms)
      - [SuperHint](https://github.com/p05wn/superhint):
        - 1.2.2: metadata updated (platforms)
        - 1.2.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [Suture](https://github.com/libtero/suture):
        - 1.2.5: metadata updated (platforms)
        - 1.2.10: metadata updated (platforms)
        - 1.2.0: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [ZoomAllViews](https://github.com/dump-guy/zoomallviews):
        - 1.0.1: metadata updated (platforms)
      - [augur](https://github.com/0xdea/augur):
        - 0.9.3: metadata updated (platforms)
        - 0.9.2: metadata updated (platforms)
        - 0.9.1: metadata updated (platforms)
        - 0.9.0: metadata updated (platforms)
        - 0.8.1: metadata updated (platforms)
        - 0.8.0: metadata updated (platforms)
        - 0.7.5: metadata updated (platforms)
        - 0.7.4: metadata updated (platforms)
        - 0.7.3: metadata updated (platforms)
      - [bitopt](https://github.com/teflate/bitopt):
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [bookmark-hints](https://github.com/williballenthin/idawilli):
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
      - [capa](https://github.com/mandiant/capa):
        - 9.4.0: metadata updated (platforms)
        - 9.3.1: metadata updated (platforms)
        - 9.3.0: metadata updated (platforms)
      - [clang-include](https://github.com/oxikkk/ida-clang-include):
        - 1.2.0: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [colorize-calls](https://github.com/williballenthin/idawilli):
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
      - [deREferencing](https://github.com/danigargu/dereferencing):
        - 2025.9.24: metadata updated (platforms)
      - [decode_instruction](https://github.com/milankovo/decode_instruction):
        - 1.0.0: metadata updated (platforms)
      - [diaphora](https://github.com/joxeankoret/diaphora):
        - 3.4.1: metadata updated (platforms)
        - 3.4: metadata updated (platforms)
      - [edit-function-prototype](https://github.com/oxikkk/ida-edit-function-prototype):
        - 1.0.0: metadata updated (platforms)
      - [extensible-hints](https://github.com/williballenthin/idawilli):
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
      - [funcfiletree](https://github.com/rand-tech/idaplugins):
        - 1.0: metadata updated (platforms)
      - [function-string-associate](https://github.com/oxikkk/ida-function-string-associate):
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [gepetto](https://github.com/justicerage/gepetto):
        - 1.5.0: metadata updated (platforms)
      - [haruspex](https://github.com/0xdea/haruspex):
        - 0.9.3: metadata updated (platforms)
        - 0.9.2: metadata updated (platforms)
        - 0.9.1: metadata updated (platforms)
        - 0.9.0: metadata updated (platforms)
        - 0.8.1: metadata updated (platforms)
        - 0.8.0: metadata updated (platforms)
        - 0.7.5: metadata updated (platforms)
        - 0.7.4: metadata updated (platforms)
        - 0.7.3: metadata updated (platforms)
      - [hint-calls](https://github.com/williballenthin/idawilli):
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
      - [hrtng](https://github.com/kasperskylab/hrtng):
        - 3.9.108: metadata updated (platforms)
        - 3.9.105: metadata updated (platforms)
        - 3.8.94: metadata updated (platforms)
        - 3.8.88: metadata updated (platforms)
        - 3.7.74: metadata updated (platforms)
      - [iOSHelper](https://github.com/yoavst/ida-ios-helper):
        - 1.0.19: metadata updated (platforms)
        - 1.0.17: metadata updated (platforms)
      - [icp](https://github.com/rand-tech/idaplugins):
        - 1.3: metadata updated (platforms)
      - [ida-chat](https://github.com/tanu360/ida-chat-plugin):
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [ida-codemode](https://github.com/hexrayssa/ida-codemode):
        - 0.6.1: metadata updated (platforms)
        - 0.6.0: metadata updated (platforms)
        - 0.5.3: metadata updated (platforms)
        - 0.5.2: metadata updated (platforms)
        - 0.5.1: metadata updated (platforms)
        - 0.5.0: metadata updated (platforms)
        - 0.4.1: metadata updated (platforms)
        - 0.4.0: metadata updated (platforms)
        - 0.3.2: metadata updated (platforms)
        - 0.3.1: metadata updated (platforms)
        - 0.3.0: metadata updated (platforms)
        - 0.2.0: metadata updated (platforms)
      - [ida-cyberchef](https://github.com/hexrayssa/ida-cyberchef):
        - 0.3.2: metadata updated (platforms)
        - 0.3.1: metadata updated (platforms)
        - 0.2.0: metadata updated (platforms)
        - 0.1.0: metadata updated (platforms)
      - [ida-nativeaot](https://github.com/dump-guy/ida-nativeaot):
        - 1.0.2: metadata updated (platforms)
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [ida-nexus](https://github.com/hexrayssa/ida-nexus):
        - 0.7.0: metadata updated (platforms)
        - 0.6.2: metadata updated (platforms)
      - [ida-outliner](https://github.com/milankovo/ida_outliner):
        - 1.2.0: metadata updated (platforms)
        - 1.1.1: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [ida-security-scanner](https://github.com/symbioticsec/ida-security-scanner):
        - 0.0.1: metadata updated (platforms)
      - [ida-settings-editor](https://github.com/williballenthin/ida-settings):
        - 1.2.3: metadata updated (platforms)
        - 1.2.1: metadata updated (platforms)
        - 1.1.1: metadata updated (platforms)
        - 1.1.0: metadata updated (platforms)
        - 1.0.2: metadata updated (platforms)
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [ida-taskr](https://github.com/mahmoudimus/ida-taskr):
        - 1.0.3: metadata updated (platforms)
      - [ida-terminal-plugin](https://github.com/hexrayssa/ida-terminal-plugin):
        - 0.0.6: metadata updated (platforms)
      - [idalib-rust-bindings](https://github.com/idalib-rs/idalib):
        - 0.9.0: metadata updated (platforms)
        - 0.8.1: metadata updated (platforms)
        - 0.8.0: metadata updated (platforms)
        - 0.10.0: metadata updated (platforms)
      - [idamagicstrings](https://github.com/joxeankoret/idamagicstrings):
        - 1.2.0: metadata updated (platforms)
      - [idasvg](https://github.com/chichou/idasvg):
        - 0.1.0: metadata updated (platforms)
      - [idavator](https://github.com/mahmoudimus/idavator):
        - 0.1.1: metadata updated (platforms)
      - [llm-explainer](https://github.com/pgarba/ida-llm-explainer):
        - 1.9.0: metadata updated (platforms)
        - 1.8.0: metadata updated (platforms)
        - 1.7.3: metadata updated (platforms)
        - 1.7.0: metadata updated (platforms)
        - 1.6.2: metadata updated (platforms)
        - 1.3.0: metadata updated (platforms)
      - [mcrit-ida](https://github.com/danielplohmann/mcrit-plugin):
        - 1.1.9: metadata updated (platforms)
        - 1.1.8: metadata updated (platforms)
        - 1.1.7: metadata updated (platforms)
      - [navigator](https://github.com/rand-tech/idaplugins):
        - 1.3: metadata updated (platforms)
      - [oplog](https://github.com/williballenthin/idawilli):
        - 0.3.0: metadata updated (platforms)
        - 0.2.0: metadata updated (platforms)
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
      - [rhabdomancer](https://github.com/0xdea/rhabdomancer):
        - 0.9.3: metadata updated (platforms)
        - 0.9.2: metadata updated (platforms)
        - 0.9.1: metadata updated (platforms)
        - 0.9.0: metadata updated (platforms)
        - 0.8.1: metadata updated (platforms)
        - 0.8.0: metadata updated (platforms)
        - 0.7.6: metadata updated (platforms)
        - 0.7.5: metadata updated (platforms)
        - 0.7.4: metadata updated (platforms)
        - 0.10.0: metadata updated (platforms)
      - [showcomments](https://github.com/merces/showcomments):
        - 0.6.0: metadata updated (platforms)
        - 0.5.1: metadata updated (platforms)
        - 0.5.0: metadata updated (platforms)
      - [tag-func](https://github.com/williballenthin/idawilli):
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
      - [tc_deer](https://github.com/arkup/tc_deer):
        - 0.1.3: metadata updated (platforms)
        - 0.1.2: metadata updated (platforms)
        - 0.1.0: metadata updated (platforms)
      - [unicorn-tracer-arm64](https://github.com/chenxvb/unicorn-trace):
        - 0.4.0: metadata updated (platforms)
        - 0.3.1: metadata updated (platforms)
        - 0.3: metadata updated (platforms)
        - 0.2: metadata updated (platforms)
        - 0.1: metadata updated (platforms)
      - [vt-ida-plugin](https://github.com/virustotal/vt-ida-plugin):
        - 1.0.8: metadata updated (platforms)
        - 1.0.7: metadata updated (platforms)
        - 1.0.6: metadata updated (platforms)
      - [vtable-context-tools](https://github.com/oxikkk/ida-vtable-tools):
        - 1.1.0: metadata updated (platforms)
        - 1.0.2: metadata updated (platforms)
        - 1.0.1: metadata updated (platforms)
        - 1.0.0: metadata updated (platforms)
      - [xray](https://github.com/hexrays-plugin-contributions/xray):
        - 2025.9.24: metadata updated (platforms)
      - [yarg](https://github.com/r0ny123/yarg):
        - 1.0.5: metadata updated (platforms)
        - 1.0.4: metadata updated (platforms)
        - 1.0.3: metadata updated (platforms)
        - 1.0.2: metadata updated (platforms)
        - 1.0.1: metadata updated (platforms)
      - [yarka](https://github.com/azzonfire/yarka):
        - 0.7.2: metadata updated (platforms)
      

   10. 🔗 jellyfin/jellyfin 12.0 RC6 release

       🚀 Jellyfin Server 12.0 RC6

       We are pleased to announce the sixth release candidate preview release of Jellyfin 12.0!

       This is a preview release, intended for those interested in testing 12.0 before its final public release. We welcome testers to help find as many bugs as we can before the final release.

       As always, please ensure you stop your Jellyfin server and take a full backup before upgrading!

       A note about versioning

       Starting with this release, we are dropping the preceding10. from our versioning. Thus, 10.11.x -> [10.]12.x = 12.x. The reason is simple: at this point in the project, we don't envision a hard break in the API like we planned way back in the early days, and this version scheme was causing a lot of confusion amongst users about what a "major" release was. For more information, please see the RC1 release notes.

       What's new?

       The main goal of this release has been performance. 10.11.0 dropped a major backend rewrite, and while it was broadly functional, it had a lot of rough edges. This release seeks to polish out most of those rough edges and bring better performance to all users.

       There are many other small fixes, improvements, changes, and translations. See our draft release notes here or below for the full list of pull requests. You can also view the Web side changelog here.

       Note: You must be on Jellyfin 10.10.7+ or 10.11.x (ideally, 10.11.11) before upgrading! If you are not, the upgrade will fail. Ensure you upgrade to one of these versions first!

       Note: The initial load of Jellyfin 12.x will run a few migrations and will take several minutes. Please be patient and do not interrupt the process. You can leverage the (newly improved!) startup UI on your local network to see specific progress, or off-network to see general progress, by visiting the server URL in your web browser during startup.

       Note: If you install the RC, you should disable all external plugins and reinstall using the unstable plugin repository, or plugins may fail to load and cause unintended side effects.

       Installing

       This preview release is distributed in all our traditional forms, though not automatically via our Apt repository or latest tag.

       • For all non-Docker environments, you can find the files for manual download in our repository by selecting "Stable Preview" for your OS.
       • For Docker, you can pull the 12.0-rc6 or preview tags.

       What's Changed (since

       v12.0-rc5)

       • Update dependency z440.atl.core to 7.16.0 by @renovate[bot] in #17551
       • Fix FindArtists by @theguymadmax in #17604
       • Update Microsoft to 10.0.11 by @renovate[bot] in #17615
       • Fix unit test for localization of Artists in DE by @IDisposable in #17633
       • Fix other two unit test for localization of Artists in DE by @IDisposable in #17637
       • Recognize WEB-DL release tags in video names by @st7105 in #17636
       • Update github/codeql-action action to v4.37.7 by @renovate[bot] in #17630
       • Update dependency Microsoft.NET.Test.Sdk to 18.9.0 by @renovate[bot] in #17638
       • Update dependency dotnet-ef to v10.0.11 by @renovate[bot] in #17614
       • Fix large playlist persistence with WhereOneOrMany by @martin-77 in #17655
       • Fix SQLite variable limit in child count batches by @martin-77 in #17658
       • Update Microsoft to 5.9.0 by @renovate[bot] in #17665
       • Prevent orphaned user permissions and preferences by @m0g3r in #17643
       • Fix GitHub URL typo in CONTRIBUTORS by @FirmaSpring in #17659
       • Use client-reported position for idle playback cleanup by @itsb in #17631
       • More resilient MusicBrainz lookup by @Shadowghost in #17670
       • Stop user updates from orphaning permission and preference rows by @Shadowghost in #17645
       • Fix latest items for mixed libraries by @theguymadmax in #17678
       • Allow direct play for HDHomeRun Live TV tuners by @theguymadmax in #17682
       • Fix GHSA-wwwm-px48-fpvq by @crobibero in #17685
       • Optimize query helper memory by @Shadowghost in #17607
       • Safeguard against invalid provider ids by @Shadowghost in #17584
       • Fall back to the ancestor filter when a view has no top parents by @Shadowghost in #17691
       • Mark breakOnNonKeyFrames as XMLIgnore by @Shadowghost in #17698
       • Look up people by item via the credit map instead of a full scan by @Shadowghost in #17700
       • Fix English metadata blocking localized providers ranked below it by @Shadowghost in #17619
       • Fix series merging leaking across libraries and under-counting merged children by @Shadowghost in #17693
       • Fix person metadata not being fetched on demand or by the people task by @Shadowghost in #17702
       • Update dependency UTF.Unknown to 2.7.0 by @renovate[bot] in #17697
       • Say which image and item failed instead of logging a blank path by @Shadowghost in #17711
       • Fix OMDB People handling by @Shadowghost in #17710
       • Fix IsPlayed and IsUnplayed sorting for shows and collections by @LTe in #17713
       • Stop deriving user view ids from their localized name by @Shadowghost in #17714
       • Build a TMDb series cast from the aggregated credits by @Shadowghost in #17716
       • Delete credits nothing maps to and bound item-by-name folder names by @Shadowghost in #17715
       • Persist the refresh stamp so the people task stops redoing its work by @Shadowghost in #17709

       New Contributors

       • @st7105 made their first contribution in #17636
       • @martin-77 made their first contribution in #17655
       • @m0g3r made their first contribution in #17643
       • @FirmaSpring made their first contribution in #17659
       • @itsb made their first contribution in #17631

       Full Changelog : v12.0-rc5...v12.0-rc6

   11. 🔗 smol-machines/smolvm smolvm v1.13.0 release

       What's Changed

       • Re-stage a damaged image-archive cache entry instead of trusting that the path exists by @BinSquare in #1058
       • Fail when the release lookup fails instead of falling back to a hardcoded 0.1.1 by @NickyHeC in #1059
       • Ship the guest Chromium wrapper in the desktop recipes with software WebGL enabled by @BinSquare in #1055
       • Give a pack machine's first boot a start window that covers the layer unpack by @BinSquare in #1056
       • Add SECURITY.md by @NickyHeC in #983
       • Floor host loopback in the default local egress mode by @BinSquare in #1060
       • Support nested machine checkpoints by @BinSquare in #1062
       • Extract packed layers on the host when the pack predates in-guest unpacking, instead of handing its agent tars it cannot read by @BinSquare in #1064
       • Release 1.13.0 by @BinSquare in #1063

       Full Changelog : v1.12.0...v1.13.0

   12. 🔗 PrimeIntellect-ai/prime-agent v0.8.1 release

       • Fixed syntax highlighting in the expanded python tool-call view: triple-quoted strings spanning multiple lines now keep their string color instead of only the first line.
       • Changed the default RLM maximum recursion depth for new sessions from 1 to 2.
       • Changed ACP prompt requests to resolve only after all causally admitted subagent and parent work has settled.
       • Changed the Cloudflare AI Gateway default model to claude-sonnet-4.5 after the catalog dropped the gateway's workers-ai mirror ids.
       • Fixed ACP assistant chunks to identify message boundaries across autonomous turns.
   13. 🔗 Rust Blog Announcing our first Maintainers in Residence rss

       We are very happy to announce the Rust Project's first round of Maintainers in Residence: Gen Li (@rami3l), Chris Denton (@ChrisDenton), Alejandra González (@blyxyas), León Liehr (@fmease), and Maintainer Grant recipients: Jason Newcomb (@Jarcho) and Jonas Böttiger (@joboet). These contributors will be funded for their rust-lang maintenance activities for (at least) the following 12 months!

       The funding of the Maintainer in Residence (MiR) and Maintainer Grantee roles is possible thanks to generous donations to the Rust Foundation Maintainers Fund (RFMF) from Google, AWS, OpenAI, the Rust Project Leadership Council and also individual sponsors. We also want to thank the people who advocated for maintainer funding within their companies; Tyler Mandry from Google, Niko Matsakis and Jess Izen from AWS and Predrag Gruevski from OpenAI, and also the whole Rust Leadership Council and our funding advisors. If you would like to help us support even more Rust contributors, consider donating to RFMF.

       The Rust Foundation has published a press release and a blog post, where you can learn more about the sponsors and the supported contributors.

       Read more below to learn about the MiR program, how we chose the funded contributors, and of course who they are!

       Background

       The Maintainer in Residence program, established in RFC 3931, is designed to provide stable financial support for Rust contributors, so that they can truly focus on crucial maintenance activities. Currently, there are three categories of support that we offer:

       • Full-time MiR: funded for 5 days/week of Rust Project work
       • Half-time MiR: funded for ~2.5 days/week of Rust Project work
       • Maintainer Grant: funded for ~1 day/week of Rust Project work

       Funding for this program comes from the Rust Foundation Maintainers Fund, which was launched recently, and the whole program is managed by the Rust Funding team.

       When deciding who to fund, we took a systematic approach. First, we looked at Rust teams to understand their maintenance baseline (the smallest number of maintainers they need to ensure a healthy long-term status of the given project or repository), and how far they currently are from that baseline. From there, we identified and prioritized Rust teams who were both critically underfunded, and have a high impact on the language and its users. These teams (in no particular order) were rustdoc, rustup, cargo, compiler, libs, clippy, rustfmt, rust analyzer and mods.

       The next step was pairing these teams with maintainers looking for funding. And it turns out that finding such maintainers for some teams turned out to be much more difficult than we originally assumed! For example, some maintainers are already employed, some do not want to be funded, and while we did our best to promote our funding efforts, not everyone looking for funding actually asked us for it. We also realized that some teams on our list have essentially no active members, which makes it tricky to onboard new contributors, even if they would like to help out.

       In the end, we decided to start by supporting six contributors, who will help maintain several critical Rust projects and teams and who could start immediately. However, we are not stopping there. Our funding efforts are ongoing, so stay tuned for more MiR announcements in the near future! If you would like to learn more about our process, check out our recent post.

       And now, without further ado, let's meet our newly funded maintainers!

       Gen Li (@rami3l)

       

       Gen Li (@rami3l) is a full-time MiR focusing on Rustup.

       He has been a Rustup team member since 2023 and its lead since 2025. He deeply cares about the facets of Rust that many might have taken for granted, and embodies all attributes we were looking for in a MiR: he wants to take on complex issues, continue mentoring, and work on important Rustup features, among many other things.

       Turning volunteering into an actual job has really been an empowering experience so far! I finally have the bandwidth to take a careful look at my inbox and can actually read each message without the fear of missing crucial details while rushing prompt replies, which has really helped me retain the essential compassion as a maintainer. I also get to interact with regular contributors a lot more often. Finally, I can't wait to see what I can come up with in terms of Project Goals :)

       Chris Denton (@ChrisDenton)

       

       Chris Denton (@ChrisDenton) is a half-time MiR focusing on the standard library, compiler, Rustup and anything Windows- related.

       For the past five years Chris has been bringing his deep knowledge of Windows to help Rust sustain and improve its great cross-platform support. He will be unblocking other contributors in various Windows use cases, performing refactoring and code reviews and implementing new features across several areas of the Project.

       Even though it is still early days, I'm feeling pretty optimistic about the health of the Rust Project going forward, thanks to the recent funding efforts.

       Alejandra González (@blyxyas)

       

       Alejandra González (@blyxyas) is a half-time MiR focusing on Clippy.

       She is a Clippy team member always keen on improving performance and helping new contributors. She will focus on making Clippy faster and also reviewing its pull requests, to help get the ~300 pull request backlog down. Additionally, she is excited to mentor people from the Rust for Linux project to work on Clippy, and fine tune the open peer review system that Clippy started using earlier this year.

       Funding is the system that helps me pour my heart into a project without worrying about making ends meet. Having those needs met is a game-changer and boosts my productivity. One of the areas where I want to focus my efforts is mentoring new contributors. If new people coming is the lifeblood of a project, I want to be the cardiologist!

       León Liehr (@fmease)

       

       León Liehr (@fmease) is a half-time MiR focusing on rustdoc and the compiler.

       He is a member of the rustdoc and compiler teams, who is usually working on the Rust type system or issues related to parsing. He will continue working on complex features that he started a few years ago, and also focus on general maintenance, code reviews, refactoring and mentoring.

       Being funded to work on Rust means I can sustainably focus my time and energy on a project I call a passion of mine.

       Jonas Böttiger (@joboet)

       

       Jonas Böttiger (@joboet) is a maintainer grantee focusing on the standard library.

       He is a musicology student from Germany. When he is not playing the Cello or reading about Fanny Hensel, he applies his research skills to ensure that programs written in Rust run quickly and soundly on all platforms, no matter how quirky the operating system may be. He loves helping contributors write excellent code that they can be proud of; and considers it to be just as much fun as writing it himself.

       Getting funding for my work is a dream come true. It will allow me to continue doing the thing I love instead of worrying about whether I should rather invest all that time in a money-earning job with much less positive impact on the world around me.

       Jason Newcomb (@Jarcho)

       

       Jason Newcomb (@Jarcho) is a maintainer grantee focusing on Clippy.

       He is primarily working on fixing bugs and making it easier to develop and contribute to Clippy. He is also focusing on making the review process as smooth as possible.

       Being funded allows me to work on something I care about and want to work on instead of what will get me paid. I'm looking forward to seeing how this will impact Clippy and the Rust project in general.

       Conclusion

       The contributors presented above will be funded for the next 12 months, though of course we hope that we will be able to extend their support going further, as this program is designed to be for long-term stable maintenance funding. We are very excited about them; each one of them has been with the Project for years, and we are very glad that we can support their maintenance work! All of them have already signed their contracts, so they are already being funded as we speak.

       While there are many other Rust contributors who are doing awesome work, and who would also deserve to get proper funding for it, we think that this is a great start. We hope that the awesome work done by the funded maintainers will allow us to promote this program, so that we can fund even more Rust contributors!

       We would like to once again sincerely thank everyone who made this possible, especially our sponsors. If you would like to help us fund more maintainers, consider donating to RFMF. You can also sponsor individual Rust contributors directly.

   14. 🔗 New Music Releases Imminence - If Not Now, When rss

       Imminence - a new release is available:

       • 2026-08-26: If Not Now, When (Single)

       Amazon: Canada | Deutschland | France | United Kingdom | United States

       Visit muspy for more information.

4. August 25, 2026
   1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-25 rss

      IDA Plugin Updates on 2026-08-25

      Activity:

      • augur
        • c5bb29eb: feat: use the -locked flag for cargo commands
      • disrobe
        • 87ba8f37: wasm: ratchet capability reachability ceiling
        • 6795e4a7: annotate recovered wasm signedness in typescript
        • 09d0a813: python: expose flutter engine symbol maps
        • 8ba7a246: cli: read flutter engine maps from config
        • 42e05c77: cache Flutter engine symbol summaries locally
        • 8ba46797: wasm: keep native image parsing out of the browser graph
        • f186d47e: flutter: apply build-id matched external symbol maps
        • ba45d412: flutter: validate external engine symbol maps
        • 0f42dd56: wasm: declare sandboxed recovery tests
        • 98484e99: wasm: reject selector memory overlaps and bulk writes
        • de71d6bc: wasm: recover immutable local-offset memory selectors
        • 087723a0: native: prove elf unwind header auto routing
        • 98db3292: native: seed aarch64 starts from elf unwind headers
        • 0381cd6a: rar: reject undersized itanium filter blocks
        • 6ecbc86a: binfmt: bound pmarc decoding and validate pm2 trees
        • b0ad596d: python: publish 5,225 recovered 3.10 objects
        • 60df9c29: python: recover shared returns after pre-3.11 exception handlers
        • e5a91517: mba: satisfy the rule-pack iterator lint
        • 88c8f128: mba: trace the peephole pack through wasm recovery
        • c15d791f: mba: complete peephole rule table coverage
      • haruspex
        • 70ff5e73: doc: update changelog
        • e0210d26: feat: use the -locked flag for cargo commands
      • ida-bochs-binaries
        • 1f147a3f: Merge pull request #4 from HexRaysSA/x64-stubs
        • 62781fcf: add 64-bit (PE32+) stub DLL generation
      • ipyida
        • 165c4c37: Add a ida-plugin.json file so the hcli repo finder robot picks up our…
      • rhabdomancer
        • 5e96cc17: feat: use the --locked flag for cargo commands
      • xrefgen
        • 8139606d: Pin CI to Ubuntu 22.04 runners
        • 6b38cc06: Cancel stale CI matrix runs
        • 18067261: Canonicalize cached return summaries
        • 1168619d: Remove stale string result taxonomy
        • da171dc0: Publish corpus precision summaries
        • 4ec9bdea: Harden incremental dataflow cache invalidation
        • b4d55878: Fix typed architecture callsite classification
        • bfedba31: Unify distributed configuration defaults
        • d8facb68: Expand external corpus and incremental validation
        • 492506b7: Document calibrated corpus coverage
        • 0a07acd2: Add positive C++ corpus ground truth
        • a1e5a77a: Clarify experimental WASM and heuristic similarity claims
        • 4c71e26f: Verify incremental cache across IDB reopen
        • cd171c8f: Add positive corpus ground truth fixtures
        • 1d07fd12: Skip unavailable optional cross-target corpus builds
        • dbcdcdbf: Verify incremental checker in release smoke
        • 2fa93f37: Add IDA incremental equivalence verifier
        • 350c4ad4: Type analyzer outputs as semantic results
        • c17f1e04: Filter Hex-Rays fallthrough call targets
        • 9e560582: Reject unresolved direct and zero call targets
   2. 🔗 anthropics/claude-code v2.1.246 release

      What's changed

      • Added a startup warning for Bash allow rules with a wildcard before the subcommand (e.g. Bash(git * main)), since they also match options inserted before the subcommand
      • Added an Auto mode tab to /permissions for viewing and editing auto mode classifier rules
      • Added the turn's completion time to the end-of-turn duration line, e.g. ✻ Sautéed for 23s · done 6:05 PM
      • Fixed fullscreen mode showing a blank transcript after resizing the terminal and jumping to the bottom until the next keypress
      • Fixed a severe transcript slowdown when a diff contained a very long single line (e.g. a base64 string); such lines now render truncated with a marker
      • Fixed erratic fullscreen scrolling when positioned at an earlier message, including jump-to-bottom getting stuck mid-transcript
      • Fixed background sessions failing to open after 45 seconds when Claude Code's starting directory had been deleted, the machine had slept, or the host is slow to start processes
      • Fixed background sessions failing to open with "Couldn't start the background service … EACCES" when another Claude Code process was re-installing the npm package at that moment
      • Fixed markdown rendering being disabled for a whole message when its first 500 characters contained no markdown, and for +/N) lists and setext headings
      • Fixed MCP tool calls interrupted by an incoming message in headless/remote sessions being reported to the model as "completed with no output" instead of an explicit interrupted error
      • Fixed MCP tool arguments being sent as JSON strings when the parameter's schema is empty ({}), instead of their real type
      • Fixed a command interrupted mid-run showing as "Ran 1 shell command" with no sign it was cut
      • Fixed pressing ← or running /background during a dynamic workflow restarting its finished subagents; it now asks first and says how many subagents would restart
      • Fixed opening a just-started session in claude agents while its worker was still booting (common on Windows) stopping it with "was stopped while the respawn was in flight"
      • Fixed claude agents listing a backgrounded named session twice; backgrounding the same conversation again now numbers the new row (e.g. my-session (2))
      • Fixed the background retention sweep removing git worktrees under .claude/worktrees/ that you created yourself when an old background-session record pointed at them
      • Fixed auto mode tool calls being denied as "temporarily unavailable" on very large sessions by scaling the safety-check deadline with prompt size
      • Fixed the plugin cache creating duplicate SHA-named directories for the same plugin
      • Fixed plugin skills whose frontmatter name already includes the <plugin>: prefix showing it doubled in the slash menu (e.g. /plugin:plugin:skill)
      • Fixed claude plugin update failing for an installed plugin given its bare name (only the fully-qualified name worked)
      • Fixed plugin installation failing when plugin.json was saved with a UTF-8 byte-order mark (BOM)
      • Fixed /reload-plugins reporting 0 skills for plugins that define skills under skills/*/SKILL.md
      • Fixed hook error messages showing a literal ${CLAUDE_PLUGIN_ROOT} instead of the resolved plugin path
      • Fixed /rename replacing the theme's prompt border color (including a custom theme's promptBorder) with the default cyan; the border now keeps your theme's color unless you pick one with /color
      • Fixed custom theme diff colors (diffAdded/diffRemoved and their dimmed variants) being ignored in diffs and the /theme preview
      • Fixed a keybindings.json binding with an unknown action name silently deadening that key; it is now skipped so the default binding keeps working, and a warning is logged under --debug
      • Fixed /stats activity heatmap showing each day's activity one cell off (Sunday's count under Monday) in timezones east of UTC
      • Fixed /fork from an already-forked or backgrounded session starting the new session with an empty conversation
      • Fixed prompts beginning with /-- (e.g. Lean doc comments) being rejected as an unknown slash command instead of being sent to Claude
      • Fixed the @ file picker staying open after the typed text stopped matching a real path
      • Fixed the status line's cost and duration resetting to zero after navigating to the agents view and back
      • Fixed fullscreen mode moving keyboard focus onto the control under the pointer when you clicked the terminal window only to bring it back into focus
      • Fixed path completion failing when the completion token or working directory contained a null byte
      • Windows/macOS: Fixed headless sessions not cleaning up stale entries in ~/.claude/sessions left by sessions that exited uncleanly
      • Fixed the UI stopping with a render error on the first tool call when a third-party Anthropic-compatible endpoint (ANTHROPIC_BASE_URL) streams a tool_use block without an id
      • Fixed the Write tool reporting "Out of memory" or freezing for a long time after overwriting a very large existing file, even though the file had been written
      • Fixed claude plugin install <name> exiting silently (or hanging in a terminal) instead of reporting an error when ~/.claude/plugins/known_marketplaces.json is empty or corrupted
      • Fixed resumed sessions failing every turn with a 400 when the saved history contains tool blocks the Anthropic API does not accept (typically written by a third-party API proxy)
      • Fixed curl -fsSL https://claude.ai/install.sh | bash failing with "Raw mode is not supported" for some Team/Enterprise users with server-managed settings
      • Fixed sessions that ended in plan mode resuming outside plan mode in the VS Code extension, and in claude -p --continue/--resume with a permission prompt tool, when no permission mode was set
      • Fixed the Notification hook not firing while the sandbox "Network request outside of sandbox" permission prompt is waiting
      • Fixed Bash permission checks to always require approval for malformed commands with a dangling && or || operator
      • Fixed --strict-mcp-config sessions prompting to approve .mcp.json servers they would never load, which left background sessions waiting at startup
      • Fixed telemetry and metrics requests to Anthropic carrying the API key configured for a third-party gateway (ANTHROPIC_BASE_URL); a credential is now only sent to its own host
      • Fixed a visible API error on the first prompt after idle when apiKeyHelper returns short-lived JWTs: an expired cached token is now refreshed before sending, and 401/403 auth errors retry quietly
      • Fixed memory growing with session length in the fullscreen and Ctrl+O transcript views: each rendered message row no longer retains a full copy of the transcript-wide tool lookups
      • Fixed /ultrareview runs and cloud sessions launched at the same time from one repository (e.g. from several worktrees) sometimes starting with another launch's uncommitted changes
      • Fixed the task progress count (e.g. 3/5) shown for background cloud sessions such as /autofix-pr occasionally missing a task
      • Fixed Remote Control sessions keeping their placeholder name in claude.ai and the Claude app until the second prompt; the auto-generated title now appears after the first prompt
      • Fixed MCP tools marked requiresUserInteraction still offering "Yes, and don't ask again" in their permission prompt; the option wrote an allow rule the tool then ignored
      • Fixed the self-hosted runner ending its live sessions or exiting when a work-poll response is malformed (e.g. an intercepting proxy's HTML page); it now retries the poll
      • Improved /cd: the new directory's project settings, hooks, .mcp.json servers (behind the usual approval prompt), skills, and agents now take effect right after the move instead of on --resume
      • Improved Bash tool latency on bash shells by replaying snapshot functions without a base64 subshell per function
      • Improved subagent results: a subagent that stops at its maxTurns limit now returns its output marked as partial, with a hint to continue it via SendMessage, instead of appearing finished
      • Improved non-interactive sessions (-p, SDK, cloud sessions) to automatically continue a response cut off mid-stream by a server error, connection loss, or stall instead of ending with an error
      • Improved attribution of usage telemetry to your organization for workload identity federation sessions, events sent while apiKeyHelper runs at startup, and after a login token expired while idle
      • Changed /code-review so Claude can also start it on its own on Bedrock, Vertex AI, and Foundry, through the Claude apps gateway, and when telemetry or non-essential traffic is disabled
      • /goal: Changed idle sessions to start at most three check-ins on long-running background work per goal; your next message allows three more
      • Changed claude install and claude update to defer a pending managed-settings consent prompt to the next interactive session instead of prompting mid-command
      • Changed OpenTelemetry plugin events for plugins synced from claude.ai: plugin_id_hash now reflects the plugin's real marketplace, and enabled_via is admin-install for admin-installed plugins
      • Fixed the command sandbox's filesystem configuration not respecting --setting-sources
   3. 🔗 r/LocalLLaMA Qwen3.8-Flash-Next. This architecture could be surprisingly local-friendly once the weights drop. 👀 rss

      | Qwen3.8-Flash-Next (~125B-A6B + 51B n-gram) memory estimate: Ideal 4-bit quant ≈ 82 GB
      (58 GB main weights + 24 GB n-gram tables)
      Real-world quants likely land in the 80–90 GB range. The big n-gram table is sparsely accessed → excellent candidate for system RAM offload. This architecture could be surprisingly local-friendly once the weights drop. submitted by /u/pmv143
      [link] [comments]
      ---|---

   4. 🔗 modem-dev/hunk v0.20.0 release

      What's Changed

      Hunk 0.20 makes it easier to install, keep current, and extend—while making everyday reviews faster and more precise.

      Highlights

      • Install Hunk on macOS and Linux with a checksum-verified curl installer, then keep npm, Homebrew, and curl installations current with hunk update, by @benvinegar in #799 and #788.
      • Explore a searchable directory of 12 community extensions covering GitHub reviews, Mercurial, search, CODEOWNERS, commit-by-commit workflows, exports, and more, introduced by @benvinegar in #811, with catalog contributions from @phl28, @gentilfp, and @sadick254 in #822, #826, and #842.
      • Build deeper integrations with exact selected-line context and immutable snapshots of reviewed files and saved notes, by @benvinegar in #779 and #833.
      • Click exact diff lines—including blank lines—and open inline comments without shifting their target code, by @benvinegar in #840 and #809.
      • Navigate and revisit highlighted diffs with less work, while --fast now offloads syntax highlighting for eligible files with 40 or more lines, by @benvinegar in #791, #803, and #810.

      Release notes : https://hunk.dev/changelog/0.20/
      Full Changelog : v0.19.0...v0.20.0

   5. 🔗 @binaryninja@infosec.exchange Sidekick for everyone sounded better than Sidekick for some. Today we launched mastodon

      Sidekick for everyone sounded better than Sidekick for some. Today we launched Sidekick Free! If you have an active Binary Ninja license, you now have Sidekick too. No extra purchase or signup needed. See what it can do: https://sidekick.binary.ninja/free

   6. 🔗 r/LocalLLaMA Apple releases M5 ultra at 1.2TB/s bandwith rss

      | lpddr5x probably, the m7 ultra if is using ddr6 should be at 1.8 Tb/s submitted by /u/Last-Owl-8342
      [link] [comments]
      ---|---

   7. 🔗 r/LocalLLaMA Apple introduces new Mac Studio with M5 Max and M5 Ultra - up to 512GB of unified memory rss

      | submitted by /u/themixtergames
      [link] [comments]
      ---|---

   8. 🔗 r/LocalLLaMA Qwen 3.8 Flash Next day 0 support from unsloth rss

      | Prepare your disk space guys submitted by /u/jacek2023
      [link] [comments]
      ---|---

   9. 🔗 modem-dev/hunk v0.19.1 release

      What's Changed

      Hunk 0.19.1 improves CPU compatibility, npm installation, and diff rendering.

      Highlights

      • Run x64 builds on pre-Haswell processors and conservative VM CPU models by @elucid in #797.
      • Install cleanly from npm with executable platform binaries and without unnecessary Pierre dependencies for CLI-only users by @benvinegar in #844 and #847.
      • Keep reviews fast and visually accurate by caching complex Unicode width measurements and preserving Git moved-line colors on wrapped rows by @benvinegar and @HackAttack in #800 and #812.

      Release notes : https://hunk.dev/changelog/0.19/
      Full Changelog : v0.19.0...v0.19.1

   10. 🔗 r/LocalLLaMA Qwen3.8-Flash-Next tomorrow rss

       | submitted by /u/rerri
       [link] [comments]
       ---|---

   11. 🔗 anthropics/claude-code v2.1.245 release

       What's changed

       • Fixed a crash on startup on Linux distributions that ship glibc 2.44 (for example Arch Linux, CachyOS and Fedora Rawhide)
   12. 🔗 seanmonstar Micro: Using LLMs to find not-that-rock rss

       Imagine someone tells you to get them a rock. You go find one, bring it back, and they reply ‘no, not that rock’. They didn’t know exactly what they wanted, but they knew yours wasn’t it.

       When writing, I always start by dumping a detailed outline with points and subpoints. And then, ugh, I feel a wall. How do I turn this into prose? I ask an LLM to try, I look at the ablated text, and I hate it. No, definitely not that rock. More like this.

   13. 🔗 Filip Filmar Fuchsia Internals, Vol. I: The Graphics and Display Pipeline rss

       Volume I of my Fuchsia Internals report series is the graphics and display pipeline, and it is a deliberate choice for the first deep-dive: graphics is a complete worked application that exercises nearly every kernel primitive at once. Fuchsia decomposes what Linux would put in a monolithic DRM/KMS subsystem into a set of cooperating user-space services that talk to each other over FIDL typed channels with zero-copy shared VMOs. The full PDF is linked at the bottom.

   14. 🔗 Szymon Kaliski Play with Putty rss

       Play with Putty is a research experiment in collaborative vibe coding — an exploration where multiple people, together with fast LLMs, iterate on multiplayer-first projects in real time:

       We'll share more about this soon — for now you can sign up for the waitlist.

       Made at Google Labs.

   15. 🔗 Ampcode News Setup Without a Commit rss

       You can now store scripts to set up orbs outside of your repository. Amp can store pre-clone and pre-setup scripts in your project settings and access them when spawning an orb.

       The pre-clone setup script gives Amp anything it needs before it clones the repository:

       • Install Git extensions that fetch files during checkout.
       • Configure certificates for an internal Git server.
       • Configure a network proxy needed to reach the Git server.
       • Connect the orb to a private network with Tailscale (known issue: use TAILSCALE_API_KEY, OIDC is not yet working with pre-clone scripts).
       • Install a credential helper required by the Git server.

       

       The pre-setup script lets you work with orbs when you aren't ready to commit setup files to the repository. Amp agents and Puck can access the scripts and set them for you. Give Puck this prompt, or start a thread for the project with this prompt:

       

       Amp will then inspect the repository and decide which work belongs before or after the clone. It will write and test the scripts, then save them in the project settings.

       The scripts are also available on the project settings page, where you can review or edit them by hand.

generated: August 28, 2026 at 00:09:29