🏡

August 29, 2026
1. 🔗 HexRaysSA/ida-nexus v0.9.0 release
  
  Full Changelog : v0.8.1...v0.9.0
2. 🔗 gildas-lormeau/single-file-cli v2.4.1 release
  Fixes
  - Fixed self-extracting pages saved with --embed-pdf failing to open, displaying the error "Cannot extract the data of the page"
  - Fixed self-extracting pages served with an HTTP error status staying stuck on the "Please wait..." message instead of displaying the page
  - Fixed a size miscalculation which could leave the end of central directory record of a self-extracting page outside the range ZIP readers scan to find it
  - Updated zip.js to 2.8.61
  Co-authored by Claude (Claude Code)
August 28, 2026
1. 🔗 earendil-works/pi v0.84.4 release
  New Features
  - Terminal capability overrides — Override detected terminal hyperlink, image, and truecolor support. See Capability Overrides.
  - Extension UI prompt events — Integrations can distinguish active agent work from time spent waiting for ctx.ui prompts. See Extension UI prompt events.
  - RPC queue clearing — Retrieve and clear queued steering and follow-up messages with clear_queue. See RPC clear_queue.
  - Fullscreen selection copy controls — Disable automatic selection copying in fullscreen mode and use Ctrl+X to copy the active selection. See UI & Display.
  - DeepSeek V4 Flash Vision (experimental) — Use the vision-capable model through the built-in DeepSeek provider. See API Keys.
  Added
  - Added ui_prompt_start and ui_prompt_end extension events so host integrations can distinguish active agent work from waiting on user-facing ctx.ui prompts (#8355 by @cristinaponcela).
  - Added detectSupportedImageMimeTypeFromFile() to the public library exports (#8600 by @xl0).
  - Added inherited experimental vision-capable deepseek-v4-flash-vision-exp model support.
  - Added transcript usage notices for compaction and branch summaries when cache miss notices are enabled.
  - Added RPC clear_queue to retrieve and remove queued steering and follow-up messages (#8432).
  - Added environment variables and advanced settings for overriding auto-detected terminal hyperlink, image, and truecolor capabilities (#8665).
  - Added fullscreenCopyOnSelect to disable automatic fullscreen selection copy; when disabled, Ctrl+X copies the active text selection before falling back to the last assistant message, while /tree still copies the selected message (#7720).
  Fixed
  - Fixed toggling thinking visibility clearing partial output from running Bash tools (#8611).
  - Fixed Windows shell aborts crashing Pi when taskkill.exe is unavailable on PATH (#6596).
  - Fixed resumed sessions corrupting the next appended entry when their JSONL file lacks a trailing newline (#8345).
  - Fixed extension messages sent with triggerTurn: false while the agent is running being inserted between a tool call and its result, which made providers that validate message order reject the replayed history. They are now appended once the turn's tool results are in (#8537).
  - Fixed compaction and branch summaries forcing toolChoice: "none" (#8649, #8638).
  - Fixed large tool results crossing the auto-compaction threshold being sent to the provider before compaction. Pi now compacts between tool execution and the next assistant response in the same run, and restores interactive progress when that run resumes (#6879).
  - Fixed Google Vertex requests failing with HttpsProxyAgent is not a constructor when the bundled Node.js runtime uses an HTTP(S) proxy (#8610).
  - Fixed saving a default model from a non-empty model scope so it remains available in that scope.
  - Fixed inherited @ file autocomplete ranking to prefer direct and shallower matches over similarly ranked nested paths (#8669).
  - Fixed inherited OpenAI-compatible streams serializing thinking signatures repeatedly during streaming (#8671).
  - Fixed inherited main-screen rendering crashing when image-heavy output exceeded V8's string length limit (#8028).
  - Fixed inherited fullscreen double-click word selection splitting paths and kebab-case tokens on / and - (#8676).
  - Fixed inherited Cloudflare AI Gateway catalogs omitting supported workers-ai/* passthrough models.
  - Fixed inherited OpenAI-compatible reasoning replay to merge consecutive streamed text and summary reasoning_details deltas.
  - Fixed inherited OpenRouter reasoning controls so reasoning-mandatory models do not receive effort: "none" (#8614 by @davidbrai).
  - Fixed inherited OpenAI-compatible Chat Completions ignoring an explicitly requested toolChoice when no tools are defined.
  - Fixed inherited fragmented Mistral tool calls splitting when continuation chunks omit the tool-call ID (#8387).
2. 🔗 BarutSRB/OmniWM OmniWM v0.6.4 release
  What's New Since 0.6.3
  
  0.6.4 turns the single scratchpad into ten multi-window scratchpad slots, adds automatic settings migration so upgrades no longer reset your configuration, exposes diagnostics capture through omniwmctl, and lets the Workspace Bar step aside per display during native fullscreen. It also retires stale tiles for apps that close windows without destroying them, and introduces OmniWM's compass-mark identity, its website, and a documentation hub.
  
  Before You Upgrade — Breaking Changes
  - Your 0.6.3 settings migrate automatically. No reset, no manual edit. On first launch OmniWM copies the exact original file to settings.toml.pre-v1 (or .pre-v1.1) and rewrites the live file with schemaVersion = 1. The migration preserves configured values, safely matchable unknown keys, symlink targets, and permissions. It also fills in the keys 0.6.4 requires — workspaceBar.hideInNativeFullscreen = false and an empty [scratchpads.labels] — and maps your old scratchpad hotkeys onto slot 1. The canonical rewrite can reorder the document and strip comments; the .pre-v1 backup retains the original text verbatim. Automatic migration is guaranteed for settings emitted by OmniWM 0.6.1 through 0.6.3, so a normal 0.6.3 upgrade needs no config work. Diagnostics reports every automatic change and the backup location.
  - Rolling back to 0.6.3 resets your settings. Keep the.pre-v1 backup. A settings file written by 0.6.4 contains hotkey action IDs that 0.6.3 cannot resolve. 0.6.3 treats the whole file as invalid, preserves it as settings.toml.corrupt, and starts from full defaults. Migration is forward-only: to downgrade, quit OmniWM and restore settings.toml.pre-v1 over settings.toml before launching 0.6.3.
  - Two hotkey action IDs were renamed and eighteen were added. assignFocusedWindowToScratchpad became assignFocusedWindowToScratchpad.1 and toggleScratchpadWindow became toggleScratchpad.1; slots 2 through 10 add the remaining pairs, all Unassigned. Migration rewrites the two old IDs in place, so your existing triggers survive and Settings > Hotkeys keeps working. This matters if you keep settings.toml in a dotfiles repo, generate it from a template, or hand-merge it across machines — the old IDs are no longer valid action IDs, and an unknown ID invalidates the file. In Settings the rows now read Assign Focused Window to Scratchpad N and Toggle Scratchpad N. No other action ID, default binding, config path, runtime-state path, IPC socket path, or CLI command path changed, and OmniWM still requires macOS 26+ on Apple Silicon.
  - IPC protocol goes from 11 to 13. Upgrade the bundledomniwmctl with the app. A 0.6.3 client speaks 11 and will be rejected. Protocol 13 covers two bumps:
    
    Capture requests and results, the captureActions capability list, and a new capture_state_conflict error code. Clients that switch exhaustively over IPCErrorCode must handle it.
    
    Scratchpad slot indexing. command scratchpad assign and command scratchpad toggle now require a scratchpadIndex argument (<1-10> in the CLI); the old no-argument form is an error.
    
    Window and Workspace Bar payloads changed shape.
    
    query windows gains a nullable JSON scratchpadIndex field and a scratchpad-index field selector. Full table, text, and TSV output keep the existing SCRATCHPAD column in place, but assigned windows now show their slot number instead of true, so parsers must update value handling rather than column positions.
    
    The --scratchpad selector changed meaning. It used to match the scratchpad window; it now matches every window assigned to any of the ten slots, so scripts that assumed a single result can now receive many.
    
    IPCWorkspaceBarMonitor.scratchpad — previously a nullable object holding one window — is replaced by scratchpads, an always-present array. Each entry carries index, an optional label, windows, and isVisible. An empty array replaces what used to be null.
    
    focus previous is advertised differently. It was published as Niri-only while command enforcement had always treated it as shared, so it already ran fine on Dwindle. The manifest now matches reality. query capabilities, query commands, and generated shell completions all report shared — regenerate cached capability output and completion scripts.
  - The IPC/CLI and architecture references moved out of the repository. docs/IPC-CLI.md and docs/ARCHITECTURE.md are now short stubs pointing at omniwm.app/reference/cli/overview and the architecture guide. The full text is maintained under website/src/content/docs/. Bookmarks and links to the old in-repo files still resolve, but no longer contain the reference itself.
  Headline Feature — Ten Multi-Window Scratchpads
  
  The scratchpad is no longer a single parked window. There are now ten numbered slots, each holding any number of floating windows, overlaid on whatever workspace you are looking at. An empty slot is inert and invisible. #585
  - Assign Focused Window to Scratchpad N moves the focused window into slot N , floating it if it was tiled and parking it off-screen. Pressing the same shortcut on a window already in slot N returns it to the layout.
  - Toggle Scratchpad N reveals or parks every window in the slot as one coordinated operation, on the monitor you are interacting with. Revealing a slot parks whichever slot was showing, so at most one scratchpad is on screen at a time.
  - A revealed scratchpad follows you across workspace switches and stays up until you toggle it off. If it is showing on another monitor, its shortcut summons it to the one you are on.
  - Revealed windows behave as ordinary floating windows. Whether clicking something underneath pushes them behind it follows the usual focus and raise rules, including Raise Window When Focus Follows Mouse.
  - Every non-empty slot gets a Workspace Bar pill showing its name and its windows' icons; clicking the pill toggles that slot. Scratchpad pills always group by app, independent of the Deduplicate App Icons setting.
  - Slots are addressed by number everywhere. An optional label replaces the number in the Workspace Bar and in omniwmctl output:
    
    [scratchpads.labels]
    
    1 = "term" 3 = "COMMS"
  - Automation gets the full surface: omniwmctl command scratchpad assign <1-10>, omniwmctl command scratchpad toggle <1-10>, and window queries that expose both scratchpad membership and the slot index.
  Scratchpad membership lasts for the lifetime of the OmniWM process — only the labels are persisted. The ten assign/toggle pairs start unassigned except for slot 1, which inherits your previous scratchpad shortcuts through migration.
  
  Settings and Automation
  - Settings persistence now safely preserves unknown TOML keys through saves, including array-owned keys when their owner can be matched unambiguously. Ambiguous preservation, exhausted migration-backup slots, unsafe symlinks, and unsupported-schema or migration-backup save races leave the file untouched and block writes rather than risk data loss.
  - Trace and performance captures can be scripted with omniwmctl capture start trace, omniwmctl capture start performance, omniwmctl capture stop, and omniwmctl capture status. Capture state and the most recent artifact metadata are available through IPC. As with all omniwmctl use, Enable IPC must be turned on from the menu bar first.
  - Quake Terminal's updated GhosttyKit adds Kitty clipboard reads and writes, binary-safe multi-format transfers, clipboard type listings, requester-aware confirmation previews, optional session grants, and a dedicated selection clipboard.
  Workspace Bar and Window Lifecycle
  - Hide in Native Fullscreen is a new opt-in Workspace Bar setting, off by default. Suppression is derived per display, so a bar disappears only on the monitor showing a native-fullscreen Space and returns automatically on exit. Reserved tiled layout space stays stable to prevent unrelated windows from jumping. #601
  - Windows that apps such as Calendar close by ordering out instead of destroying are now retired from the layout. OmniWM validates targeted rescans against the app's Accessibility window list, including when the frontmost app loses its last focused window. #610
  - Targeted rescans preserve intentionally parked windows, including scratchpad and other hidden lifecycle states, rather than mistaking them for closed windows.
  Identity, Website, Documentation, and Thanks
  - OmniWM now uses a compass-mark identity across the app icon, launch overlay, status item, repository, and a reproducible brand-asset package.
  - omniwm.app launches with interactive feature demos, a knowledge base, install and CLI references, testimonials, sponsor credits, and canonical-domain redirects.
  - The README, architecture guide, IPC/CLI contract, issue-reporting guidance, and contributor documentation were rewritten against the current codebase and Swift 6.4 toolchain. The README now documents scratchpads, orientation-aware Niri containers, the advanced-commands hotkey filter, and the complete shortcut tables.
  - Matt Wicks (@wicksipedia) joins the contributor showcase under SSW Consulting, and the latest private sponsor is recognized anonymously with a path to request public credit.
  Release Integrity
  
  The OmniWM app is Developer ID signed, Apple-notarized, stapled, and Gatekeeper verified.
  - OmniWM-v0.6.4.zip SHA-256: 9b2bf54d20d67f536270032e0625176c06c6e03b8897ddf025558d948339e5e7
  - GhosttyKit.xcframework-v0.6.4.zip SHA-256: c7b1a8541206fa4ebf55e5dca8f12df4efa7ed5df490c4c426a5ee091c74ec21
3. 🔗 PrimeIntellect-ai/prime-agent Beta (v0.8.1-beta.564.1.d60fab8) release
  
  Automated beta build from main (d60fab8a76d9c169f945341f0ee3bde21903bb55).
4. 🔗 uswds/uswds USWDS 3.14.0 release
  What's new in USWDS 3.14.0
  
  Features
  
  Package | A11y | Breaking | Markup change | Description
  ---|---|---|---|---
  usa-accordion, uswds-core | Yes | Yes | Yes | Added a left-aligned expand/collapse icon option. A new $theme-accordion-icon-position setting (default: "start") lets teams set icon placement globally. The .usa-accordion--icon-start and .usa-accordion--icon-end modifier classes support per-instance placement. This improves discoverability for users viewing content at high magnification or zoom levels. Thanks @HopeTurnerUSCIS, @rosamundtgov, and @jeana-adhoc! (#6789)
  
  ✏️ Teams should verify layout at common zoom levels for the new default accordion behavior.
  usa-breadcrumb | Yes | Yes | - | Breadcrumbs now wrap by default. The previous truncation behavior is now opt-in via the new usa-breadcrumb--truncate modifier class. Thanks @AKnassa! (#6722)
  
  ✏️ Teams should confirm breadcrumbs display as expected and add usa- breadcrumb--truncate if they want the old truncation behavior.
  usa-range | Yes | - | Yes | Added a visible hint to the range slider. A new usa-hint element with the text "Move the slider to change the value" is added above the slider so sighted users receive the same guidance that screen reader users already had. Thanks @ravitejapioneerblaze-code! (#6673, #6811)
  
  ✏️ Teams should pull in the updated markup.
  usa-range | Yes | - | - | Improved range slider border visibility. The border is now 2px and uses the base-darker theme token. A focus ring is also added to the slider input. Thanks @manichandra! (#6659)
  usa-date-picker | Yes | - | Yes | Addedaria-current="date" to today's date button. Assistive technologies can now programmatically identify the current date in the calendar widget. Thanks @daresTheDevil! (#6593)
  usa-file-input | - | - | - | Error border now uses theerror-dark token. The file input error state previously used secondary-dark, which could show the wrong color in projects with distinct secondary and error palettes. Thanks @manichandra! (#6669)
  
  Bug fixes
  
  Package | A11y | Breaking | Markup change | Description
  ---|---|---|---|---
  usa-modal | Yes | - | - | Closing a modal now always restores screen reader access to the page. If the element that opened the modal had left the document by the time the modal closed, page content kept aria-hidden="true" and stayed invisible to assistive technology until reload. Thanks @vssinghh! (#6786)
  usa-modal, uswds-core | Yes | - | Yes | Fixed modal content being read twice by screen readers. The default focus target has changed — on open, focus now moves to the first enabled button in the modal footer, or the first enabled button in the modal if no footer button is present. FocusTrap no longer uses autoFocus. (#6703)
  
  ✏️ Teams should verify modal focus lands where expected after this update.
  usa-memorable-date | Yes | - | Yes | Added per-field hints to the memorable date component. The component previously used a single shared hint referenced by all three fields via aria-describedby, causing screen readers to repeat the full instruction block on every field focus. Each field now has its own targeted hint. The visible group hint remains for sighted users with aria-hidden="true". (#6725)
  
  ✏️ Teams should update to the new per-field hint markup. Teams supporting other languages should update their hint strings.
  usa-file-input | Yes | Yes | Yes | Removed the drag instruction on mobile and coarse-pointer devices. The file input previously showed "Drag file here or choose from folder" on all devices, including mobile where drag-and-drop isn't a practical interaction. Coarse-pointer devices now show and announce "Choose from folder" only. Thanks @manichandra! (#6660)
  
  ✏️ Teams should check for layout changes and update any accessibility tests that assert the old exact instruction text.
  usa-character-count | Yes | - | - | Deferredaria-live to prevent iOS VoiceOver from announcing character count on page load. Live updates continue to fire normally during typing. Thanks @daresTheDevil! (#6595)
  usa-character-count | - | - | - | Fixed the label selector so it correctly finds the associated label. Thanks @ealexhaywood! (#6385)
  usa-footer | - | Yes | - | Restricteddata-tag to heading elements. The footer's big link list was vulnerable to XSS through unsanitized data-tag values. Non-heading elements now gracefully fall back to h4. Thanks @IHIutch! (#6674)
  
  ✏️ Teams should review any footer data-tag values that aren't heading elements.
  usa-banner, uswds-core | - | - | - | Fixed toggle so it resolvesaria-controls from the component's root node. This allows banner toggles to work correctly when used inside a shadow root. Thanks @arpitjain099! (#6714)
  uswds-core | - | - | - | Fixed the language selector Escape key handler. Thanks @arpitjain099! (#6713)
  uswds-core | - | - | - | Guarded the keymap against non-keyboard events from datalist selections. This prevents a console error when a user selects an option from a datalist. Thanks @vijaygovindaraja! (#6594)
  usa-table | - | - | - | Restored the row header border in borderless tables. Row-scoped body header cells now keep their top border so row headers don't appear visually disconnected. Thanks @manichandra! (#6661)
  usa-table | - | - | - | Fixed.usa-sr-only table caption causing heading-row border collapse. Thanks @IHIutch! (#6633)
  usa-time-picker | - | - | - | Added missing combobox style dependency to the time picker package. Thanks @IHIutch! (#6634)
  usa-input, usa-textarea, usa-range, usa-combo-box, usa-input-prefix-suffix, usa-select | - | - | - | Setbox-sizing: border-box on the %block-input-styles mixin to prevent overflow. Components in host environments that reset global box sizing no longer overflow their containers. Thanks @VenkateshAddala! (#6736)
  
  ✏️ Teams should verify these elements display correctly in projects with custom global box-sizing resets (e.g. those who set $theme-global-border- box-sizing: false).
  usa-in-page-navigation | - | - | - | Standardized the component's enhancement guard to usedata-enhanced in line with other USWDS components. (#6688)
  uswds-core | - | - | - | Fixed ink assignment referencing the wrong variable. Custom ink colors in a project's theme were referencing the wrong system token. Thanks @nektro! (#6651)
  
  ✏️ Teams should verify that custom ink colors in their theme render as expected.
  
  Guidance changes
  
  Alert
  
  The alert component page now recommends that alert headings start with the alert type to improve clarity and urgency of the message, both for accessibility and general usability, as well as adding extended guidance to help teams use the correct alert type. Thanks @jeana-adhoc and @rosamundtgov! (#3288)
  
  Markup changes
  
  Memorable date
  
  The memorable date component's three fields now each have their own aria- describedby hint instead of sharing a single
  group hint. Teams who've copied the memorable date markup should update to the per-field pattern:
```
 <fieldset class="usa-fieldset">
   <legend class="usa-legend">Date of Birth&lt;/legend&gt;
-  <span class="usa-hint" id="mdHint">For example: January 19 2000&lt;/span&gt;
+  <span class="usa-hint" aria-hidden="true" id="memorable-date-hint">
+    Select a month. Enter 1 or 2 digits for the day and 4 digits for the year.
+  &lt;/span&gt;
   <div class="usa-memorable-date">
     <div class="usa-form-group usa-form-group--month usa-form-group--select">
       <label class="usa-label" for="date_of_birth_month">Month&lt;/label&gt;
-      <select class="usa-select" id="date_of_birth_month" name="date_of_birth_month" aria-describedby="mdHint">
+      <span class="usa-hint usa-sr-only" id="memorable-date-month-hint">Select a month from the dropdown.&lt;/span&gt;
+      <select class="usa-select" id="memorable-date-month" name="memorable-date-month" aria-describedby="memorable-date-month-hint">
         ...
       &lt;/select&gt;
     &lt;/div&gt;
     <div class="usa-form-group usa-form-group--day">
       <label class="usa-label" for="date_of_birth_day">Day&lt;/label&gt;
-      <input class="usa-input" aria-describedby="mdHint" id="date_of_birth_day" name="date_of_birth_day" ... />
+      <span class="usa-hint usa-sr-only" id="memorable-date-day-hint">Enter 1 or 2 digits for the day.&lt;/span&gt;
+      <input class="usa-input" aria-describedby="memorable-date-day-hint" id="memorable-date-day" name="memorable-date-day" ... />
     &lt;/div&gt;
     <div class="usa-form-group usa-form-group--year">
       <label class="usa-label" for="date_of_birth_year">Year&lt;/label&gt;
-      <input class="usa-input" aria-describedby="mdHint" id="date_of_birth_year" name="date_of_birth_year" ... />
+      <span class="usa-hint usa-sr-only" id="memorable-date-year-hint">Enter 4 digits for the year.&lt;/span&gt;
+      <input class="usa-input" aria-describedby="memorable-date-year-hint" id="memorable-date-year" name="memorable-date-year" ... />
     &lt;/div&gt;
   &lt;/div&gt;
 &lt;/fieldset&gt;
```
  File input
  
  The file input no longer renders the drag instruction on coarse-pointer or mobile devices. On those devices, the
  instruction now reads "Choose from folder" instead of "Drag file here or choose from folder". For fine-pointer devices,
  the text remains "Drag file here or choose from folder." Teams with tests that assert the exact instruction text should
  update those tests.
```
- Drag file here or choose from folder
+ Choose from folder
```
  Accordion icon alignment
  
  The default alignment for the accordion toggle icon switches to the left for better accessibility for users who zoom or
  use screen magnification. Teams can now use the usa-accordion--icon-start or usa-accordion--icon-end modifier to
  left-align or right-align the expand/collapse icon at the instance-level respectively. Icon position can be set globally
  with the $theme-accordion-icon-position Sass setting. The default behavior ("start" / left-aligned) is changed from
  v3.13.0, and the historical behavior can be preserved with $theme-accordion- icon-position: "end".
```
- <div class="usa-accordion">
+ <div class="usa-accordion usa-accordion--icon-start">
```
  or
```
- <div class="usa-accordion">
+ <div class="usa-accordion usa-accordion--icon-end">
```
  Or set globally in your theme:
```
+ $theme-accordion-icon-position: "start";
```
  or
```
+ $theme-accordion-icon-position: "end";
```
  Dependencies and security
  
  Dependency updates
  
  Dependency name | Previous version | New version
  ---|---|---
  lit | 3.2.1 | 3.3.3
  receptor | 1.0.0 | --
  
  Note: receptor has been removed as a dependency. Its functionality has been reimplemented in first-party code.
  Thanks @aduth! (#6489)
  
  Dev dependency updates
  
  Dependency name | Previous version | New version
  ---|---|---
  @babel/core | 7.26.8 | 7.29.7
  @babel/preset-env | 7.26.8 | 7.29.7
  @chanzuckerberg/axe-storybook-testing | 6.3.1 | --
  @material-design-icons/svg | 0.14.13 | 0.14.15
  @rollup/plugin-commonjs | 28.0.3 | 29.0.3
  @spiriit/vite-plugin-svg-spritemap | 4.0.0 | 6.0.0
  @storybook/addon-a11y | 6.5.16 | 9.1.20
  @storybook/addon-essentials | 6.5.16 | --
  @storybook/addon-links | 6.5.16 | --
  @storybook/builder-webpack5 | 6.5.16 | --
  @storybook/html | 6.5.16 | --
  @storybook/html-vite | -- | 9.1.20
  @storybook/manager-webpack5 | 6.5.16 | --
  @storybook/test-runner | -- | 0.23.0
  @types/node | 20.14.10 | 24.13.3
  @uswds/compile | -- | 1.3.2
  autoprefixer | 10.4.20 | 10.5.0
  axe-core | 4.10.2 | --
  axe-playwright | -- | 2.2.2
  concurrently | -- | 10.0.3
  css-loader | 6.8.1 | --
  del | 6.0.0 | 8.0.1
  esbuild | -- | 0.28.1
  eslint | 8.56.0 | 10.8.0
  eslint-config-airbnb-base | 15.0.0 | --
  eslint-config-prettier | 9.1.0 | 10.1.8
  eslint-plugin-airbnb-base | 0.0.1-security | --
  eslint-plugin-import | 2.31.0 | --
  eslint-plugin-import-x | -- | 4.17.1
  eslint-plugin-lit | 2.0.0 | 2.3.1
  eslint-plugin-no-unsanitized | 4.1.2 | --
  file-loader | 6.2.0 | --
  globals | -- | 17.8.0
  gulp | 4.0.2 | 5.0.1
  gulp-mocha | 9.0.0 | 10.0.1
  gulp-postcss | 9.0.1 | 10.0.0
  gulp-rename | 2.0.0 | 2.1.0
  gulp-sass | 6.0.0 | 6.0.1
  html-webpack-plugin | 5.6.3 | 5.6.8
  http-server | -- | 14.1.1
  magic-string | -- | 0.30.21
  merge-stream | 2.0.0 | --
  mocha | 10.8.2 | 11.8.0
  postcss | 8.5.2 | 8.5.25
  postcss-discard-comments | 6.0.2 | 8.0.2
  postcss-import | 15.1.0 | --
  postcss-loader | 7.3.3 | --
  postcss-preset-env | 9.6.0 | --
  prettier | 3.4.2 | 3.9.6
  react-dom | 17.0.2 | --
  resolve-url-loader | 5.0.0 | --
  sass-embedded | 1.83.4 | 1.100.0
  sass-loader | 16.0.4 | --
  sass-true | 6.0.1 | 10.1.0
  sinon | 12.0.1 | 22.1.0
  snyk | 1.1295.3 | 1.1306.2
  storybook | -- | 9.1.20
  style-loader | 3.3.3 | --
  svgo | 3.3.2 | 4.0.2
  twig | -- | 3.0.0
  twigjs-loader | 1.0.3 | --
  vite | 6.2.2 | 6.4.3
  vite-plugin-svg-sprite | 0.6.2 | --
  wait-on | -- | 9.1.0
  webpack | 5.98.0 | 5.109.2
  webpack-cli | 5.1.4 | 7.2.2
  
  0 vulnerabilities in regular dependencies (dependencies for USWDS projects installed with npm install @uswds/uswds)
  
  19 vulnerabilities (11 moderate, 3 high) in devDependencies (development dependencies)
  
  SHA-256 for release
  
  da91c65e6fc736fa397f0daf6ca2c2c95711506d85c7ad2537a4570725401e1c
  
  Additional contributions
  - Thanks to @szepeviktor for fixing typos and EditorConfig improvements. (#6720, #6278)
  - Thanks to @manichandra for fixing 18F guide links. (#6658)
  - Thanks to @ericsorenson for upgrading our eslint (#6690) and Storybook (#6697, #6715) tooling
  - Thanks to @olsonap for fixing initialization on the interactive components in our Storybook instance (#6664)
5. 🔗 r/LocalLLaMA zai-org/GLM-5.3 · Hugging Face rss
  | GLM-5.3 uses the same base model as GLM-5.2 — every gain comes from post-training. Compared with GLM-5.2, it is much better at complex coding and long-horizon tasks:
  - Stronger Coding: GLM-5.3 is the most capable open-weights model for coding, with a 50% improvement over GLM-5.2 on our in-house Z.ai Code Bench. It also achieve open-source SOTA on public benchmarks including Terminal Bench 3.0 and Agents' Last Exam.
  - Emergent Cyber Capability: As we scaled post-training, cyber capability developed faster than we expected. GLM-5.3 is state of the art on CyberGym for vulnerability discovery, and its gains are largest further up the exploitation chain, where it more than doubles GLM-5.2 on exploitation benchmarks.
  https://huggingface.co/unsloth/GLM-5.3-GGUF submitted by /u/jacek2023
  [link] [comments]
  ---|---
6. 🔗 gildas-lormeau/single-file-cli v2.4.0 release
  New features
  - Added --browser-profile to capture pages with a browser profile, and --create-browser-profile to create one interactively (e.g. to log into a website before capturing it)
  Fixes
  - Fixed pages being captured as if they were controlled by automation: the browser is no longer launched with --enable-automation, so navigator.webdriver is now false
  - Fixed pages being captured as if the browser were headless: the Headless token is now removed from the user agent, fixing captures of websites which reject headless browsers (e.g. pages saved as a "Just a moment..." interstitial). --user-agent still takes precedence when set
  - Fixed the filenames of unwritten files displayed in the progress output when using --dump-content
  - Fixes from single-file-core 1.5.99 to 1.5.106, including: fixed srcset attributes losing candidates with invalid descriptors and producing empty entries, fixed filenames starting with a dot, fixed the data used by {digest-sha-*} filename templates being missing (fix gildas-lormeau/SingleFile#1756)
  Co-authored by Claude (Claude Code)
7. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 plugins, +6 releases rss
```
sync repo: +2 plugins, +6 releases

## New plugins
- [ida-mcp](https://github.com/hexrayssa/ida-mcp) (0.8.1, 0.8.0)
- [ipyida](https://github.com/eset/ipyida) (2.3)

## New releases
- [ida-bochs-binaries](https://github.com/hexrayssa/ida-bochs-binaries): 1.0.3
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.8.1, 0.8.0
```
8. 🔗 r/LocalLLaMA claude mods didn't like that, somehow 🤷‍♀️ rss
  
  | submitted by /u/peculiar-ragdoll
  [link] [comments]
  ---|---
9. 🔗 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.
10. 🔗 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.
11. 🔗 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.
12. 🔗 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.
13. 🔗 New Music Releases Vintage Culture - Selekta EP rss
  Vintage Culture - a new release is available:
  - 2026-08-28: Selekta EP (EP)
  Amazon: Canada | Deutschland | France | United Kingdom | United States
  
  Visit muspy for more information.
14. 🔗 Ampcode News Amp on iOS & macOS rss
  
  Control your orbs from anywhere.
  
  Install the iOS app through TestFlight[^1], and the macOS app through direct download.
  
  Download at ampcode.com/app.
  
  It's orbin' time no matter where you are.
15. 🔗 Ampcode News No Mailmap Required rss
  Amp can now use a Git identity that is separate from the email on your Amp account. Pick the name and verified email that should appear on commits made in orbs.
  
  You can ask Puck to set it for you:
  
  If you have not added the identity yet, Puck sends a verification link to the email address. Once you click it, Puck gets notified and can make the identity your personal default if you asked it to.
  
  You can also manage identities under Signing Keys. Your personal default applies to personal projects unless you choose another identity in a project's settings. Workspace admins choose one rule for the whole workspace:
  - Amp uses the Amp identity.
  - Amp Account uses each member's Amp account.
  - User Choice lets each member choose.
  When Amp starts an orb, it sets GIT_AUTHOR_* and GIT_COMMITTER_* from the selected identity. If commit signing is on, Amp only signs for an email you have verified.
  
  Your Amp login can stay tfc@ampcode.com while your commits use tim@culver.house.
August 27, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-27 rss
  IDA Plugin Updates on 2026-08-27
  
  New Releases:
  - ida-nexus v0.8.1
  - ida-nexus v0.8.0
  Activity:
  - claude-marketplace
    
    82d6625b: Change IDA MCP URL
  - disrobe
    
    b17915d4: xtask: synchronize python 3.13 threshold routing
    
    e3785be1: native: recover msvc security cookie guards
    
    6084b650: publish current python and dex recovery measurements
    
    249aaa1a: python: publish the improved pinned corpus result
    
    1db331c3: preserve explicit none returns after nested guards
    
    92b837ad: native: recover rust bounds panic guards
    
    375f9560: native: grade stripped elf exported names
    
    b129e0f6: recover nonconstant returns from infinite finally arms
    
    51371393: native: recover exported function names with typed evidence
    
    08c1ee40: add flutter fallback engine identity
    
    4013718e: recover guarded returns from infinite finally arms
    
    cf0209a9: reuse Flutter symbols from the Python cache
    
    91bdf3c2: python: recover guarded breaks inside infinite finally arms
    
    083cd586: infer Flutter parameter arity
    
    0b1c640d: python: preserve guarded finally breaks in infinite loops
    
    bd9fadcb: recover resolved import thunk names
    
    2a390d23: cache flutter engine symbol maps
    
    dd963bb6: python: register byte coverage result type
    
    5b60348a: native: bound frame-pointer allocations
  - ida-bochs-binaries
    
    067c07fc: ci: standardize IDA installation pattern (#9)
  - ida-llm-explainer
    
    99e6a96d: Settings: group into tabs (Server/Explain/CFG trace/C export/Agent se…
    
    7de1cfd7: docs: agent.md - operating instructions for external agents
    
    c12f0e25: v1.11.0: agent server - localhost HTTP API for external agents to dri…
    
    9a634d7d: v1.10.0: auto-compact + live context gauge (with t/s), clean context …
  - ida-nexus
    
    737fdced: Only create mcp session log when events come in
    
    8d3a9212: 0.8.1
    
    ddbf1bf1: Add missing LICENSE
    
    a7aa95ed: Redirect to ida-mcp for installation instructions
    
    65ecd8b4: 0.8.0
    
    656fe6b4: Fix release workflow
    
    af9aa5df: Create reusable ida_nexus.plugin module
    
    61128e42: Remove extensions from repository
    
    1dfce8fa: Update tool descriptions to include IDA Nexus where appropriate
  - ida-pro-mcp
    
    f19e02bb: Merge pull request #515 from Iams4kura/bugfix/omit-notification-respo…
    
    e5d3a6e8: fix(http): omit notification response bodies
  - idamcp
    
    1d726bd7: Refactor sql_query to return structured QueryResult
    
    ce73a56c: Fix potential database initialization race conditions
    
    38543b66: Suppress KeyboardInterrupt in gateway proxy
    
    a64b3593: Allow target address outside of image in get_xrefs_to
  - idawilli
    
    df5d53a6: Merge pull request #150 from williballenthin/fix-oplog-ida94-tests
    
    fca90673: Merge pull request #149 from williballenthin/fix-codemode-sandbox
    
    d8846ad3: Merge pull request #148 from williballenthin/fix-codemode-api-ty
    
    57e0606c: fix: MontyTypingError.display() no longer takes format kwarg
    
    30bf2a1d: fix oplog tests for IDA 9.4 API changes
    
    0db6f246: trigger CI
    
    c4afbdb1: fix: adapt IdaSandbox to pydantic-monty pool/session API
    
    911aac08: fix: remove unused type-ignore directives in ida-codemode-api
    
    d9bbfb13: Merge pull request #147 from williballenthin/update-gha-skill
    
    75b34bcc: update skill: -seed for IDA venv, fix example typos
    
    2f0dfabf: refactor: follow skill pattern for IDA venv/idapyswitch/IDAPYTHON_VEN…
    
    50062f53: fix: use uv venv -seed for oplog so hcli finds pip
    
    12e46233: fix: set HCLI_CURRENT_IDA_PYTHON_EXE for oplog, -python for ty
    
    ab62b038: fix: use uv venv instead of -system for Python environment
    
    b7a31946: update CI workflows to follow IDA GHA skill conventions
    
    f229c7b9: ida gha: real world lessons
    
    4924de81: add skill for IDA and GH Actions
  - ipyida
    
    56ba0915: Make sure the repo URL in the ida-plugin.json doesn't include the www.
    
    ecd266ae: Revert "Add a ida-plugin.json file so the hcli repo finder robot pick…
  - Security-Tools
    
    b5784e3e: Add new software
2. 🔗 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
3. 🔗 r/LocalLLaMA 5090 now officially cost 5090 rss
  
  | I was planning on another 5090, but then I realize... perhaps I am much better off getting an M5 Ultra Mac Studio with 256gb of ram. We are so genuinely cooked. submitted by /u/Sadge404
  [link] [comments]
  ---|---
4. 🔗 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]
5. 🔗 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?
6. 🔗 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]
7. 🔗 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.
8. 🔗 HexRaysSA/ida-nexus v0.8.1 release
  
  Full Changelog : v0.8.0...v0.8.1
9. 🔗 HexRaysSA/ida-nexus v0.8.0 release
  
  Full Changelog : v0.7.0...v0.8.0
10. 🔗 @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.
11. 🔗 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]
  ---|---
12. 🔗 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.
13. 🔗 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.
14. 🔗 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.
15. 🔗 r/LocalLLaMA Qwen3.8-Flash-Next better then DeepSeek V4 Pro rss
  
  | submitted by /u/Normal-Phone7762
  [link] [comments]
  ---|---
16. 🔗 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
```
17. 🔗 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
18. 🔗 r/LocalLLaMA NVIDIA buying HF isn't a good thing for open source rss
  
  | submitted by /u/johnnyApplePRNG
  [link] [comments]
  ---|---
19. 🔗 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]
  ---|---
20. 🔗 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.
21. 🔗 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.
22. 🔗 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.
23. 🔗 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.
24. 🔗 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.
25. 🔗 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.
August 26, 2026
1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-26 rss
  IDA Plugin Updates on 2026-08-26
  
  New Releases:
  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. 🔗 gildas-lormeau/single-file-cli v2.3.1 release
  New features
  - Crawls and batch captures (--urls-file) now print their progress on stderr, e.g. [3/25] saved https://example.com (example.html) (ref #163, #23)
  Fixes
  - Fixed cross-origin (site-isolated) frames being saved empty with an extra 5s delay per capture. They are now captured like same-origin frames
  - Fixed --blocked-URL-pattern, --http-header, --emulate-media-feature, the user-agent emulation and --browser-ignore-insecure-certs not being applied in cross-origin frames
  - Fixed --blocked-URL-pattern and --http-header not being applied when resources are fetched outside the browser (e.g. when fetching a resource from the page fails due to CORS)
  - Fixed the invisible DEL character in the default value of --filename-replaced-character displayed by --help
  - Fixes from single-file-core 1.5.96 to 1.5.98, including: fixed broken references to SVG symbols with ids starting with a digit (fix gildas-lormeau/SingleFile#1936), fixed invalid nesting of BODY elements (fix gildas-lormeau/SingleFile#1954), removed FileReader usage to support Safari Lockdown Mode (fix gildas-lormeau/SingleFile#1973), fixed a memory leak when capturing pages repeatedly in the same tab
  Co-authored by Claude (Claude Code)
3. 🔗 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]
4. 🔗 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]
5. 🔗 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.
6. 🔗 r/LocalLLaMA GLM-5.3-Flash: Frontier Intelligence, Flash Cost rss
  
  submitted by /u/BriguePalhaco
  [link] [comments]
7. 🔗 gildas-lormeau/single-file-cli v2.3.0 release
  SingleFile CLI 2.3.0
  
  New features
  - Added the --crawl-save-archive-page-transitions option to control page transitions when navigating in multi-page archives. The possible values are "auto" (default, i.e. transitions run only when pages opt in via an @view-transition CSS rule), "fade" (the previous behavior) and "none"
  - Added the weekday template variables, e.g. {weekday-locale} and {weekday-short-utc} (fix gildas-lormeau/SingleFile#1948)
  Behavior changes
  - The process now exits with code 1 when at least one capture fails. Batches and crawls still complete, and the exit codes (0, 1, 255) are documented in the README
  - Page transitions in multi-page archives now run only when pages opt in via CSS instead of always crossfading (see --crawl-save-archive-page-transitions above)
  Fixes
  - Fixed saving pages enforcing Trusted Types via a Content Security Policy (fix #199, #24). This requires a browser based on Chromium 151 or newer, --browser-bypass-CSP can be used as a fallback with older versions
  - Fixed --browser-remote-debugging-url not being recognized as an alias of --browser-server
  - Fixed a latent error when a capture was aborted while waiting for a timeout
  - The Docker image now explicitly disables the single-process mode of the browser (it can still be overridden by passing --browser-single-process)
  - Fixes from single-file-core 1.5.93 to 1.5.95, including: PDFs saved with --embed-pdf are now also stored as the first entry of the zip content, fixed @import rewriting when saving original URLs (fix gildas-lormeau/SingleFile#1961), fixed a hang when processing stylesheets larger than 16MB (fix gildas-lormeau/SingleFile#1962), fixed identity mappings and special characters in filename replacements
  Co-authored by Claude (Claude Code)
8. 🔗 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)
```
9. 🔗 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
10. 🔗 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
11. 🔗 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.
12. 🔗 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.
13. 🔗 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.