๐Ÿก
  • โ†”
  • โ†’
  1. October 30, 2026
    1. ๐Ÿ”— New Music Releases Queens of the Stone Age - Perfecth rss

      Queens of the Stone Age - a new release is available:

      • 2026-10-30: Perfecth (Album)

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

      Visit muspy for more information.

    2. ๐Ÿ”— New Music Releases Northlane - Anemoia rss

      Northlane - a new release is available:

      • 2026-10-30: Anemoia (Album)

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

      Visit muspy for more information.

  2. October 29, 2026
    1. ๐Ÿ”— kellyjonbrazil/jc v1.26.2: Merge pull request #883 from kellyjonbrazil/dev release

      Dev v1.26.2

    2. ๐Ÿ”— backnotprop/plannotator v0.28.38 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.37 | DeepSeek Harness support, save plans to Notion, AsciiDoc in annotate, browse the whole repository in code review, Go to File and Go to Definition, Tidy and hand-offs in the Inbox
      v0.28.36 | Qwen Code support, plans open in the Clean look, live HTML and diagrams in Inbox messages, a Feedback button, plannotator inbox status, stop and restart
      v0.28.35 | Updates check the download against checksums Plannotator fetches itself, a failed check changes nothing
      v0.28.34 | Start a Grok Build session from the Inbox, action items in your reply, a tidier Board, Settings โ†’ Capabilities, a failed feedback send is shown
      v0.28.33 | Pi updates no longer get stuck on 0.28.31
      v0.28.32 | A security update (built on Bun 1.4.4, eMudhra certificates), the Inbox Board, custom Inbox prompts, hover cards for issue and PR links, rich-text Copy
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh

      What's New in v0.28.38

      Attach files to a reply in the Inbox, swipe through a question's picture choices, and easier-to-read list rows. In code review, Call Flow and Semantic Changes show the code when you hover. 17 PRs, 3 of them from 3 community contributors.

      Plannotator Inbox

      Attach files to a reply

      The reply box has a paperclip for files of any type. You can also drop files on the reply box, or anywhere on the thread to open the reply with them. A saved draft keeps only its words, not its files.

      Swipe through a question's picture choices

      In full screen, a question's picture choices are a set of their own, in order from A to the last choice. A caption names each choice, with a dot per choice. On a phone the picture follows your finger, and a swipe down closes it.

      Easier-to-read list rows

      The subject is on the second line, with the agents, the โš  badge and the open question count at its right end. In a wide list these sit in columns that line up down the list.

      Smaller changes

      • The What's new link now shows within about 15 minutes of a release's notes being written, instead of a day later. #2337
      • A sent reply no longer comes back as a draft. #2334
      • Heading links in a Markdown attachment scroll to the heading. By @utpalsinghdev. #2316, closing #2229
      • Search is in the list header when the sidebar is closed, next to New message. #2330
      • The skills line under your reply is one quiet line of skill names, with nothing to open. #2333
      • Text between two$skill names no longer shows as math, in the Inbox, plan review and annotate. #2331

      Plannotator

      See the code on hover in Call Flow and Semantic Changes

      In code review, hover or focus a step's file:line in Call Flow, or a row in Semantic Changes, and a window shows that code as it is in the review. Deleted code shows from the old file. The same window in plan review and annotate no longer runs off the right edge of the screen. By @dmmulroy.

      Smaller changes

      • Plan history and the feedback archive now agree on a long project name cut after a hyphen. Plans being revised during the upgrade restart at v1 once (long names cut after a hyphen). By @zerone0x. #2332, closing #2306

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update npm:@plannotator/pi-extension

      OpenCode: Re-run the install script above. It also clears the OpenCode 2 plugin cache.

      What's Changed

      • feat(inbox): swipe a question's picture choices as a set; the image follows the finger by @backnotprop in #2315
      • fix: scroll to headings in Inbox Markdown attachments by @utpalsinghdev in #2316
      • chore(ui): publish prep 0.54.0 by @backnotprop in #2318
      • feat(ui): HtmlViewer sandbox prop for hosts by @backnotprop in #2319
      • test(e2e): never reach a real Codex CLI from the Inbox decision-mode spec by @backnotprop in #2267
      • chore(ui): KaTeX 0.19 by @backnotprop in #2320
      • chore(ui): publish prep 0.55.0 by @backnotprop in #2329
      • Inbox: Search in the list header when the sidebar is closed by @backnotprop in #2330
      • fix(ui): text between two $skill references no longer renders as math by @backnotprop in #2331
      • fix(core): make sanitizeTag idempotent when the 30-char cut lands after a hyphen by @zerone0x in #2332
      • Inbox: a sent reply no longer comes back as a draft by @backnotprop in #2334
      • feat(review): source previews on hover in Call Flow and Semantic Changes by @dmmulroy in #2322
      • Inbox: list rows put the subject on line 2 with agents and counts at its right end by @backnotprop in #2321
      • Inbox: quieter skills line on your replies by @backnotprop in #2333
      • Inbox: attach files to a thread reply (paperclip and drop) by @backnotprop in #2335
      • spec: formal model of the update and What's new lifecycle (Quint + fast-check) by @backnotprop in #2338
      • Inbox: show What's new when the release notes land after the Inbox asked (0.28.38) by @backnotprop in #2337

      Community

      • @dmmulroy: code previews on hover in Call Flow and Semantic Changes in #2322
      • @zerone0x: one project name for plan history and the feedback archive in #2332
      • @silopolis: reported in #2306 that plan history and the feedback archive filed one project under two names
      • @utpalsinghdev: heading links in Inbox Markdown attachments in #2316
      • @zane668: reported in #2229 that heading links in Inbox Markdown attachments did not scroll

      Full Changelog : v0.28.37...v0.28.38

    3. ๐Ÿ”— omerbenamram/pyevtx-rs 0.14.1 release

      Changed

      • Update the Rust parser to evtx 0.14.0. JSON output no longer repeats a key
        when an element holds two substitutions whose nested templates have elements
        with the same name: those names are numbered (Name, Name_1), as they are
        elsewhere (evtx #302).

      What's Changed

      Full Changelog : 0.14.0...0.14.1

    4. ๐Ÿ”— exe.dev Introducing execonnect: Access Private HTTP Services from exe.dev rss

      execonnect is a way to let your exe.dev VMs connect to HTTP services, even if those services arenโ€™t on the public internet. You run execonnect on the machine hosting the service (or on any machine that can access the service), and this establishes a link between your service and exe.dev. From that point on, you can configure integrations.

      For example, at exe.dev, we run a Victoria Metrics service inside of our network. Iโ€™m running execonnect inside the VM, and thereโ€™s a โ€œvictoriaโ€ integration in exe, and I can access our metrics. I configured it as a team integration, so it works for all of my co-workers as well.

      Diagram: inside the exe.dev production network, a monitoring VM runs Victoria Metrics and exe connect. exe connect dials out to the exe.dev exe connect switchboard. On my development VM, a Shelley session asked to โ€œuse the victoria integration to build a distribution of our disk usageโ€ runs curl, sending GET /query to victoria.int.exe.xyz; the exe.dev integrations proxy forwards it through the switchboard to exe connect, which sends GET /query to Victoria Metrics. Caption: exe connect dials out to the switchboard, so requests from my VM reach the monitoring server (which isnโ€™t on the public internet).

      How does it work? Execonnect is a Go program with a userspace wireguard. On the exe.dev side, our anycast proxy network works as the other end of that wireguard tunnel. Execonnectโ€”the part which you may run in your own infrastructureโ€”is open source, of course, so you can see what itโ€™s doing.

    5. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [threatray](https://github.com/threatray/plugin-ida): 3.0.3
    6. ๐Ÿ”— crosspoint-reader/crosspoint-reader v2.0.0rc release

      CrossPoint 2.0.0

      What a busy month. A lot of new features landed in CrossPoint, and we're eager to hear what you think.

      New devices

      This release adds support for four ESP32-S3-based devices: the Metalio E-Ink 4, the EEGO A4 (standard and Lite versions), and the BOOX Picco. If you're thinking of buying one, you'll find links at https://crosspointreader.com/devices. That page uses our affiliate links, so buying through it helps support CrossPoint.

      SD card plugins

      CrossPoint now supports plugins installed on the SD card. A plugin can add book catalogs and downloads to the reader, or tools to the device's web interface. To show the Plugins entry on Home, enable Plugins under Settings โ†’ Connectivity.

      Plugins are not apps that run arbitrary code on the reader. On-device plugins use the screens and operations the firmware already provides, such as sign-in, catalogs, downloads, and supported reading events. They can't replace the reading engine, install hardware drivers, or add unsupported document formats.

      Some plugins include JavaScript, but that code runs in a browser on your phone or computer, so the browser page has to stay open while it works. For example, a browser plugin can turn articles or RSS feeds into an EPUB, which you then read on the device.

      The plugin system will stay focused on reading and book services. It won't become a platform for on-device games, calculators, notepads, writing apps, web browsers, or PDF rendering. Those remain outside CrossPoint's scope, plugins included.

      Bluetooth page turners

      Bluetooth page turners now work on all devices. Go to Settings โ†’ Connectivity โ†’ Bluetooth Page Turner to scan for a remote, pair it, and map its buttons. Short and long presses can trigger different actions: page turns, chapter navigation, the reader menu, and clipping selection.

      Highlights and clippings

      You can now select text in EPUBs, highlight passages, and save excerpts as clippings. On button devices, use the reader menu. On touch devices, hold a word and drag the selection handles. Selected text also works for dictionary lookup, including multi-word phrases. If you turn on Sync Clippings, clippings can sync through a compatible CrossPoint Sync server.

      EPUB formatting and reading controls

      EPUB rendering now handles more of what books actually contain: drop caps, small caps, mixed text sizes, borders, and shaded blocks. Tables take column content, cell padding, and borders into account. Headings stay attached to the text that follows them, and paragraph indentation has its own setting. EPUBs can also show non-interlaced GIF images, covers included.

      Noto Serif is now optional

      To free up space for all of this, Noto Serif moved from a built-in font to an optional SD card font. If you use it, install NotoSerif through Manage Fonts before or after upgrading. Without it, a Noto Serif selection falls back to Noto Sans.
      Libron also available for direct download from the font manager.

      Everything else

      • OPDS, the catalog format used to browse and download books, now supports version 2.0 alongside existing catalogs.
      • The device web interface has a new look and more consistent dialogs.
      • Settings are grouped into a cleaner layout that's easier to extend.
      • Touch devices get swipe-to-delete in the file browser and a few other places.
      • Azerbaijani is now available as a UI language.

      We also added a device comparison page to the website, for anyone who wants a CrossPoint device but can't decide which one: https://crosspointreader.com/device-comparison.

      What's Changed

      New Contributors

      Full Changelog : 1.6.5...2.0.0rc

    7. ๐Ÿ”— MetaBrainz Picard 3.0.3 released rss

      Picard 3.0.3 is a maintenance release for Picard 3.0 with fixes for reported issues and updated translations.
      This release fixes a crash when switching color themes, a crash when loading a release from an ISRC lookup, metadata issues in the Album Pane when multiple files match a track, and problems saving tags to WAV files with invalid chunk sizes, along with several plugin, cover art, and sorting fixes.
      It also brings a few small improvements, including Enter-key navigation in the scripting documentation search, better recording-match scoring to avoid false positives on gross track-length mismatches, and normalization of lowercase or unhyphenated ISRCs.

      The latest release is available for download on the Picard download page.

      The detailed changes for this maintenance release are below. For an overview of the new features since Picard 2.13 please see our detailed release announcement for Picard 3.0.

      Thanks a lot to everyone who gave feedback and reported issues.

      Whatโ€™s new?

      Bugfixes

      • [PICARD-3477] - Setup Wizard: Checkbox description text not fully shown
      • [PICARD-3496] - "Grouping" tags cannot be deleted from MP3s
      • [PICARD-3498] - Disabling plugin purges cover art provider configuration from picard.ini
      • [PICARD-3499] - Reinstalling local in-place plugin and switching to git fails
      • [PICARD-3509] - Crash when switching themes
      • [PICARD-3510] - Newly added custom column renders with solid white background on tracks while built-in columns do not
      • [PICARD-3511] - Right-pane artwork replacement silently fails to embed in FLAC files
      • [PICARD-3513] - Blocking album task that is completed forever blocks UI operation
      • [PICARD-3514] - Cover Art Archive "Exclude" types list does not override the "Include" list
      • [PICARD-3515] - If many files for a given track are found and additional fields are enabled, metadata is wrong in the Album Pane
      • [PICARD-3516] - Article-insensitive column sort is non-deterministic (QCollatorSortKey lacks working equality)
      • [PICARD-3517] - Built-in player prevents file write access
      • [PICARD-3518] - Cover art saved as external files ignores CAA "front" flag when naming files
      • [PICARD-3519] - Picard unable to save metadata for WAVE files with data size not matching actual data
      • [PICARD-3521] - Picard crashes when loading a release from ISRC lookup for files already matched to a track
      • [PICARD-3527] - Track match indicator is inconsistent
      • [PICARD-3528] - Uses alias sort name even if artist credits matches artist name

      Improvements

      • [PICARD-3526] - format_isrc does not normalize lowercase or unhyphenated valid ISRCs
      • [PICARD-3507] - Scripting documentation function/tag search: Enter key to proceed to next match
      • [PICARD-3508] - Gross track-length mismatch does not prevent a false-positive recording match on Lookup

      Download

      Picard 3.0.3 is available for download from the download page of the Picard website. For Windows 10 and 11 users installing from the Microsoft Store the update to Picard 3.0.3 is now available and can be installed from the Microsoft Store app. Linux users can get the latest Snap package. The Linux Flatpak package is maintained separately and will be updated soon.

      Picard is free software and the source code is available on GitHub.

      Get in touch

      Please use the MetaBrainz community forums and the ticket system to give feedback, suggest new features or report bugs.

      Acknowledgements

      Code contributions by Laurent Monin, Philipp Wolfer and Shubham Prasad.
      Translations were updated by "ApeKattQuest, MonkeyPython" (Norwegian Bokmรฅl), pXF (Hungarian) and x150 (German).

    8. ๐Ÿ”— backnotprop/plannotator v0.28.37 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.36 | Qwen Code support, plans open in the Clean look, live HTML and diagrams in Inbox messages, a Feedback button, plannotator inbox status, stop and restart
      v0.28.35 | Updates check the download against checksums Plannotator fetches itself, a failed check changes nothing
      v0.28.34 | Start a Grok Build session from the Inbox, action items in your reply, a tidier Board, Settings โ†’ Capabilities, a failed feedback send is shown
      v0.28.33 | Pi updates no longer get stuck on 0.28.31
      v0.28.32 | A security update (built on Bun 1.4.4, eMudhra certificates), the Inbox Board, custom Inbox prompts, hover cards for issue and PR links, rich-text Copy
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages

      What's New in v0.28.37

      DeepSeek Harness joins Plannotator, plans can be saved to Notion, and AsciiDoc files open in annotate. Code review can now browse and search the whole repository, with Go to File and Go to Definition. In the Inbox: Tidy, handing a thread to another agent, and copying a message or a thread. 42 PRs, 18 of them from 16 community contributors, 9 of them first-timers.

      Plannotator Inbox

      Tidy

      Tidy , in the โ‹ฏ menu of the list and the Board, sends a short prompt to each live agent that may owe you something: an old open question, a Board card that has not moved, or a reply of yours it has not answered. Each agent tidies its own threads, and one with nothing to change sends nothing. You choose which agents to ask.

      Ask, add or hand off a tagged agent

      After you tag an agent in the reply box, a line under it says what Send does: Ask it (as before), Add it to the thread, or Hand off the thread to it. A hand-off has Undo.

      Copy a message or a thread

      Each message has a โ‹ฏ menu with Copy message, Copy link to message and Copy thread. The thread header and the list row menu copy the whole thread as Markdown, and a copied message ends with the names of its attached files.

      One set of keyboard shortcuts

      J and K now move between threads; Shift+J and Shift+K move between messages. F opens full screen, ? shows every key, and Settings โ†’ General โ†’ Keyboard turns single-key shortcuts off.

      /plannotator-inbox teaches your agent the Inbox

      The command still opens the Inbox and shows its address. It now also gives your agent a short briefing on how to send you messages and questions there. With the Claude Code plugin, Pi and OpenCode 2, the briefing stays hidden and starts no turn. On OpenCode 2 it goes into the system prompt, so that session's prompt cache misses once.

      Smaller changes

      • The Inbox no longer starts Grok Build sessions. Old Grok Build threads still read as before, and a reply there waits until the session is back. A leftover inboxRun.grok setting is ignored. #2308
      • The agent's mark is back on the left in two-line and phone rows. #2309
      • Images in a Markdown attachment now load when the file links them by a relative path. #2285, for #2228
      • Qwen Code is named in wake lines, not "another agent". #2304

      Plannotator

      Browse the whole repository in code review

      The file tree has a Changes | All files switch. All files lists every file at the revision under review and updates as files change on disk. Open any file in a tab, switch a changed file to Whole file , and comment on any line, even outside the diff.

      Renamed: the diff choice "All files" is now "Every file" ("Every file (HEAD)" in Git), and the Diff line of exported feedback uses the new name.

      Go to File and Go to Definition

      โŒ˜P (Ctrl+P) finds any file in the repository. F12 opens a definition in a tab, Shift+F12 lists references, and Back and Forward retrace your steps. The keys match VS Code and are listed in Settings โ†’ Shortcuts.

      Explain a review agent's finding

      A review agent's findings have an Explain button. Ask AI checks the finding against the code, explains it, and suggests a fix when it holds. By @leoreisdias.

      DeepSeek Harness support

      Plan review opens when a DeepSeek Harness (0.2.1-rc.2 or later) agent leaves plan mode. Add @plannotator/dsh from DSH's Plugins page, or run dsh plugin --profile <profile> add @plannotator/dsh. /plannotator-review, /plannotator-annotate and /plannotator-last work in DSH too. By @Nyarlathoteppppp.

      Save plans to Notion

      Notion joins Obsidian, Bear and Octarine as a place to save plans. Each save creates a page under a parent page you pick in Settings โ†’ Notion. Plannotator reads your token from NOTION_TOKEN and never stores it. By @franktronics.

      AsciiDoc files

      plannotator annotate opens .adoc and .asciidoc files, and the folder browser and linked documents show them too. By @fabriziosestito.

      Jujutsu review defaults

      Settings โ†’ Git is now Settings โ†’ Review, with separate defaults for Git and Jujutsu. A Jujutsu review can open on Current change, Line of work, Last change, Evolution diff or All files. By @graemefolk.

      Link to a heading from a comment

      Write # and a heading's exact text in a comment, like #3.1 Scope, and it becomes a link that scrolls to that heading. A new opt-in plannotator-markup skill shows agents how to leave comments on a document you are annotating. By @centraldogma99.

      Pick the document's font

      Settings โ†’ Display โ†’ Document font sets the font of plan review and annotate documents: a preset or any font on your computer. Code keeps its monospace font. By @ilja.

      Faster page loads on a slow link

      Plannotator now sends a small page first and loads the rest (syntax highlighting, diagrams, math, fonts) when it is needed. A remote session on a phone opens in seconds instead of minutes. By @giladbarnea.

      Smaller changes

      • Unsent code review comments survive in local Git reviews after edits, commits, refreshes and restarts. A comment whose lines changed shows as Outdated. By @oorestisime. #1645, closing #1590
      • The top of the code review sidebar reads as one line, like All changes since main, and each word opens its menu. The +/โˆ’ counts are easier to read in every theme. #1998
      • Behind a reverse proxy, PLANNOTATOR_PUBLIC_URL sets the full address a remote session gives out, for Cloudflare Tunnel, nginx and the like. By @Whamp. #1266
      • Keep Plannotator's cookies away from other local apps with PLANNOTATOR_URL_HOST=plannotator.localhost (or "urlHost" in config.json). Nothing changes unless you set it. By @utpalsinghdev. #2188, closing #2184
      • --tailscale says plainly when Tailscale Serve is off for your tailnet, with Tailscale's link to turn it on. #2303
      • OpenCode plugin sessions show inplannotator sessions. By @TheRealAlexV. #1567
      • The OpenCode 2 update command no longer fails with "Plugin is not configured". By @utpalsinghdev. #2277
      • Annotate and review feedback starts a turn on an idle oh-my-pi instead of waiting. By @LoneExile. #1423
      • Long file and folder names show in full on hover in the annotate file browser. By @MarwanBz. #2236, closing #2195
      • The comment box no longer flickers while you type with an IME (Korean, Japanese, Chinese). By @wnduqrla. #2239
      • VS Code extension 0.17.0 reads a Guided Review in one Guide tab, with hover, Go to Definition and Ask on selected lines. In its panel, a key the review uses no longer also runs VS Code's command. #2134, #2130, #1964

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update npm:@plannotator/pi-extension

      OpenCode: Re-run the install script above. It also clears the OpenCode 2 plugin cache.

      What's Changed

      • Inbox: Ask, Add or Hand off from the reply box's tag line (A2) by @backnotprop in #2297
      • fix: load local images in Inbox Markdown attachments by @utpalsinghdev in #2285
      • fix(opencode): wait for plugins before the OpenCode 2 update command by @utpalsinghdev in #2277
      • test(perf): add reproducible plan load benchmark by @corrius in #1198
      • Add font and size controls to Annotate by @ilja in #1657
      • fix(pi-extension): start a turn for annotate feedback on idle oh-my-pi by @LoneExile in #1423
      • feat: support reverse-proxy public URLs by @Whamp in #1266
      • feat(opencode-plugin): register embedded sessions for discovery by @TheRealAlexV in #1567
      • Inbox: one keyboard system (phase 2) by @backnotprop in #2257
      • test(pi): stop network test leaking PLANNOTATOR_BROWSER by @backnotprop in #2302
      • fix(review): recover local Git drafts after diff changes by @oorestisime in #1645
      • fix(inbox): name Qwen Code in wake lines by @backnotprop in #2304
      • CI: fix a mislabeled pin, setup-node v7.1.0, no Renovate Ubuntu runner bumps by @backnotprop in #2300
      • fix(ui): show full file-browser names on hover by @MarwanBz in #2236
      • test: fix the top CI flakes (dictation paste, Mark read hang, Windows workspace timeout) by @backnotprop in #2301
      • feat: add Notion notes integration by @franktronics in #1032
      • test(e2e): stop the ref-cards-review code review flake by @backnotprop in #2307
      • VS Code Guided Reviews: our guide reader in one tab by @backnotprop in #2134
      • VS Code panel: forward only keys the review did not take (explorer step 0) by @backnotprop in #1964
      • feat: add DeepSeek Harness (DSH) support by @Nyarlathoteppppp in #2158
      • feat: add adoc support by @fabriziosestito in #1009
      • fix(tailscale): say plainly when Tailscale Serve is off, with Tailscale's link by @backnotprop in #2303
      • Inbox rows: agent mark back on the left of line 2 by @backnotprop in #2309
      • fix: support isolated localhost preference cookies by @utpalsinghdev in #2188
      • Code review: Changes | All files in the tree (explorer step 1) by @backnotprop in #1966
      • CI: parallel Test lanes, sharded Inbox e2e, no duplicate tests in the Release dry run by @backnotprop in #2235
      • chore(vscode): release 0.17.0 (Guided Reviews, Ask the agent) by @backnotprop in #2130
      • ci: stop the guide viewer manifest from conflicting across PRs by @backnotprop in #2310
      • Inbox: Tidy, from the list's and the Board's โ‹ฏ menu by @backnotprop in #2296
      • Code review: any file in a tab, Changes | Whole file, comments on any line (explorer step 2) by @backnotprop in #1969
      • feat(review): add Jujutsu review defaults by @graemefolk in #1500
      • CI: fast tier on every push, heavy tier behind the ci:full label; Deploy on workflow_run by @backnotprop in #2313
      • feat(inbox): copy a message, copy a thread by @backnotprop in #2312
      • feat(review): explain agent-generated findings with Ask AI by @leoreisdias in #1181
      • feat: link #Heading section references in annotation text, and a skill that uses them by @centraldogma99 in #1419
      • fix(ui): stop the comment composer flickering while typing with an IME by @wnduqrla in #2239
      • Code review: Go to File, Go to Definition / References into tabs, Back / Forward, next change (explorer step 3) by @backnotprop in #1976
      • Inbox: remove the Grok Build runner until Launch agents settles its approach by @backnotprop in #2308
      • /plannotator-inbox: brief the agent on using the Inbox by @backnotprop in #2311
      • feat(inbox): name attached files at the end of a copied message by @backnotprop in #2314
      • Code review: the sidebar's top reads as one sentence (approved review-sidebar-header) by @backnotprop in #1998
      • perf(app): serve the lazy chunks from the single-file bundles instead of inlining them (12x improvement) by @giladbarnea in #1618

      New Contributors

      Community

      Full Changelog : v0.28.36...v0.28.37

    9. ๐Ÿ”— Console.dev newsletter Sponsor: WarpBuild rss

      WarpBuild - AI agents push more commits. WarpBuild runs GitHub Actions twice as fast at half the cost.

      Visit WarpBuild

    10. ๐Ÿ”— Console.dev newsletter Atuin Threads rss

      Searchable agent session history.

      What we like: Sync search history for your terminal agents alongside your regular terminal history. Resume sessions across machines (local, cloud, etc). End to end encrypted. Optionally self-host your own sync server. MCP server so agents can search old sessions.

      What we dislike: CLI-only.

    11. ๐Ÿ”— Console.dev newsletter Namespace Devbox rss

      Cloud dev environments.

      What we like: Create cloud dev environments. Supports macOS, Windows, and Linux. Connect via SSH and through coding agents. Run persistent services and expose ports. Create custom base images and share settings across teams. Workspaces can be shared. SDK & MCP server so AI agents can manage their own environments.

      What we dislike: Remote desktop only available on macOS devboxes.

    12. ๐Ÿ”— Console.dev newsletter Sponsor: Coresignal rss

      Agentic B2B search for builders

      Visit Coresignal

    13. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 plugin, +3 releases rss 
      sync repo: +1 plugin, +3 releases

## New plugins
- [yarmaker](https://github.com/cod3nym/yarmaker) (0.1.2, 0.1.1, 0.1.0)
    14. ๐Ÿ”— HexRaysSA/plugin-repository commits Update known-repositories.txt rss 
      Update known-repositories.txt
    15. ๐Ÿ”— matklad Avoid Public Functions Calling Other Public Functions rss

      Avoid Public Functions Calling Other Public Functions

      Oct 29, 2026

      A small-scale rule of thumb. This article will land much better with a concrete example, but I am drawing a blank here, so you gotta just blindly trust my say so!

      When implementing a software module, itโ€™s often a case that you are writing a public function foo, and at least part of what foo does is already handled by another public function bar. The DRY instinct encourages you to call bar() from within foo. This usually creates problems down the line. Instead, create a new private function and refactor both foo and bar to call that shared helper:

      // BAD
pub fn foo() void {
    return bar(.{ .frobnicate = true });
}

pub fn bar(options: struct {
    frobnicate: bool = false,
}) void {
    // ...
}


// GOOD
pub fn foo() void {
    return helper(.frobnicate);
}

pub fn bar() void {
    return helper(.transmogrify);
}

fn helper(mode: enum { frobnicate, transmogrify }) void {
    // ...
}

      Rationale: the goal of a public API is to provide an interface that works best at the call site. If parts of public API are re-used to implement the rest of the API, then thereโ€™s a tension between making the interface convenient for the outside user and making it convenient to use from within abstraction itself. Namely, functions tend to grow optional parameters that should never be set by the user. Crucially, the parameter growth and interface degradation can happen after the original code sharing.

      By proactively making the shared implementation private, the tension is defused. You still might need to tinker with helper signature until it does everything it needs to do, but, because the helper is private, this is a cheap, local change.

      A notable exception to this rule of thumb are โ€œshortcutโ€ APIs, where a public function is defined as a commonly used chain of calls to other public functions. There, the rule is the opposite โ€” no private calls are allowed, to make sure that it is a genuine shortcut, and not a midlayer mistake.

      P.S. While researching if anyone wrote a better blog post already, I stumbled upon a fun stack overflow question, asking, paraphrasing:

      Iโ€™ve heard that it is bad when a public function calls another public function. Is this really so?

      The most upvoted answer explains that it is indeed bad, because this makes mocking to test a single method in isolation more complicated. Which is, imo, a natural, but horrible consequence of misguided approach to testing. You shouldnโ€™t be mocking your methods, you should mock your IO. And, similarly, you shouldnโ€™t test methods, but rather software functionality (unless you are building a public library with a stable API, which is a fun and important, but very narrow fraction of software development).

      The accepted answer says that this recommendation makes no sense if it is not backed by an industry wide or an organizational standard. Which somehow manages to make even less sense โ€” you shouldnโ€™t follow the guideline rules because they are written in sanctified ink! Rather, you should apply each particular rule because of the underlying reasons that motivate the rule. Guidelines and best practices articles can concentrate lots of good reasoning in a single place, but they donโ€™t absolve you from thinking!

    16. ๐Ÿ”— Filip Filmar UberDDR4 Under Bazel: An Open DDR4 Controller, Checked by One Command rss

      UberDDR4 is an open-source DDR4 SDRAM controller and PHY for FPGAs, written by Angelo C. Jacobo. It connects a Wishbone master to DDR4 memory. It handles initialization, command timing, bank scheduling, refresh and PHY calibration. Its native PHY runs the memory at DDR4-2400 on a Kintex UltraScale+ part. The project is the successor to UberDDR3, and the NGI0 Commons Fund of NLnet paid for it.

      The repository is unusually well verified for an open hardware project. It has Verilator lint, Icarus and Yosys compile checks, 34 SymbiYosys proofs, and 26 simulations against Micron’s DDR4 model. A shell script, run_compile.sh, runs them in sequence. We converted all of it to Bazel, in a pull request on our fork. This article shows what that took and what it measured.

    17. ๐Ÿ”— Armin Ronacher Custom Voices With Qwen3-TTS rss

      With my kids I'm currently building a little dungeron crawler and we're trying to learn a bit about game development along the way. However given that we live in the modern times of increasing capabilities we wanted to get a narrator and voice over.

      But we also wanted it to not sound like everyone's standard AI voices so I looked into what options there are on the table. After some investigation I narrowed down to using Qwen3-TTS which uses voice embeddings for custom voices.

      With a bit of creativity you can also do more with those custom voices than appears initially. In case this is of interest to you, this post just covers what we learned and with some examples. You can probably point your agent to it and it can do something with it.

      What Qwen Offers

      Qwen3 is not the only TTS model in town, and it wans't even my first choice. We initially used Kokoro. However Qwen3 supports voice cloning and we wanted to have it feel a bit more unique.

      In practice it's a bit tricker though. Qwen3 ships three kinds of models:

      • 1.7B-Base (and 0.6B): clones a voice from a few seconds of reference audio
      • 1.7B-CustomVoice: comes with nine built-in speakers and instructions
      • 1.7B-VoiceDesign: invents a voice from a text description

      The base model clones either in context or from the speaker embedding alone but there is no documented way to clone a voice and direct it with instructions. That means unlike the custom voice and voice design models you cannot say "speak sad" or "whisper" with a cloned base model.

      At present the official options for a custom voice are fine-tuning Base on a single speaker or to make a clip with VoiceDesign and clone it with Base. That is not all that bad, but it means instructions are gone.

      Playing With It

      For this blog post I took 28 seconds of me from my talk at PyAI Conf, cut between two pauses so that it starts and ends on a full sentence, and transcribed it with Whisper. The transcript is really only needed for baking but to compare against an already existing voice it's useful to have it say the same thing as the original recording.

      Note that a conference talk recording is not ideal but it works anyways. Which is also a good reminder that you really don't need a particularly clean recording (or a very long one) to get a halfway convincing version of a person. Particularly when then presented to you on a low quality phone call, it won't be very hard to trick your grandmother.

      The first thing you can do is to blend that recording with another voice. For instance you can use VoiceDesign to make up a voice from a description. For this blog post the designed voice was created like this, with Qwen's own Python package qwen-tts (pip install qwen-tts, I used 0.1.1), which the rest of the code in this post uses too:

      import torch
from qwen_tts import Qwen3TTSModel

kw = dict(device_map="mps", dtype=torch.bfloat16, attn_implementation="sdpa")
design = Qwen3TTSModel.from_pretrained("Qwen/Qwen3-TTS-12Hz-1.7B-VoiceDesign", **kw)
wavs, sr = design.generate_voice_design(
    text=open("voices/transcript.txt").read(), language="English",
    instruct="A man in his forties with a warm, natural, medium-low voice, speaking "
             "clearly and calmly at an easy conversational pace, like someone reading "
             "aloud to a friend.",
)

      You can see how the two different voices behave, particularly when blended together:

      Interactive demo: see the post on the website.

      Voice Embeddings

      What Base takes from a recording when cloning from the embedding alone is a speaker embedding which is basically 2048 numbers out of a speaker encoder that was trained. The same voice gets similar numbers and different voices get different ones. Which btw, is also a convenient way to do speaker detection from recordings if you want to! It's not perfect, but it's quite helpful for a single audio track recording to tell two speakers apart if you do some basic slicing and dicing (more on that below).

      Because it is just a vector, you can do arithmetic on it. For instance a weighted average of two embeddings is a spaker that is somewhere between two voices:

      base = Qwen3TTSModel.from_pretrained("Qwen/Qwen3-TTS-12Hz-1.7B-Base", **kw)

def fingerprint(path):
    prompt = base.create_voice_clone_prompt(ref_audio=path, x_vector_only_mode=True)
    return prompt[0].ref_spk_embedding

def blend(a, b, t):
    a, b = a.float(), b.float()
    mixed = (1 - t) * a + t * b
    return (mixed / mixed.norm() * ((1 - t) * a.norm() + t * b.norm())).to(torch.bfloat16)

armin, designed = fingerprint("voices/armin.flac"), fingerprint("voices/designed.flac")

      Here is the same sentence in eleven blends:

      Interactive demo: see the post on the website.

      Note that it stops sounding like me quite quickly, but it retains some of my features. And it for sure ends up with creating a unique voice regardless. I found some better successes when ensuing that the two voices have similar spectograms (eg: similar "recording setups"). In this recording you can hear that one voice picked up by the lapel mic was a bit hollow compared to the designed voice.

      If you like a a voice that comes out, you can bake it back into a new recording that you can then use as reference:

      import soundfile as sf

mixed = blend(armin, designed, 0.5)
audio, rate = say(open("voices/transcript.txt").read(), mixed)  # say() is shown further down
sf.write("voices/final.flac", audio, rate)
final = fingerprint("voices/final.flac")

      The baked voice does not come back exactly as the blend but it makes handling it easier if you want to. It's just one voice reference file.

      So on the question of using those embeddings for speaker recognition: how good does that work? I took an episode of State of Agentic Coding, the podcast Ben and I record, cut it into 2-second windows one second apart and compared each with an embedding of me form the conference.

      Somewhat surprising, but maybe not too surprising using my conference recording clip as the reference this does not work at all with Qwen3. If instead I take the 20 seconds where I introduce myself at the start of the episode as the reference, it gets 98% of the rest right.

      On the other hand using a model that was trained for speaker verification instead does manage to pick me up from the conference recording clip. For instance ECAPA, finds me from the conference clip in 97% of the windows.

      Here are 20 minutes of that podcast, classified by speaker with the different approaches:

      Interactive demo: see the post on the website.

      Instructed Cloned Voices

      But the embeddings a very useful for the voice cloning! But how to give them instructions? Base and CustomVoice manipulate the speaker the same way: one vector inserted into the talker's input sequence. In CustomVoice that vector is a row of the embedding table. In Base it is the x-vector from the speaker encoder, which only Base has. The generation code takes either (voice_clone_prompt is a regular argument of generate), and the transformer weights of the two models are nearly identical. So take the embedding with Base, then hand it to CustomVoice instead of one of its speakers:

      cv = Qwen3TTSModel.from_pretrained("Qwen/Qwen3-TTS-12Hz-1.7B-CustomVoice", **kw)

def say(text, xvec, instruct=None, language="English"):
    ids = cv._tokenize_texts([cv._build_assistant_text(text)])
    told = [cv._tokenize_texts([cv._build_instruct_text(instruct)])[0]
            if instruct else None]
    voice = {"ref_code": [None], "ref_spk_embedding": [xvec],
             "x_vector_only_mode": [True], "icl_mode": [False]}
    codes, _ = cv.model.generate(
        input_ids=ids, instruct_ids=told, voice_clone_prompt=voice,
        languages=[language], non_streaming_mode=True,
        **cv._merge_generate_kwargs(temperature=0.7, subtalker_temperature=0.7),
    )
    wavs, rate = cv.model.speech_tokenizer.decode([{"audio_codes": codes[0]}])
    return wavs[0], rate

wav, rate = say("I really thought this would work.", armin,
                "Speak in a sad, sorrowful tone, voice low and heavy, on the verge of tears.")

      Pick a speaker for the slot, a model and an instruction:

      Interactive demo: see the post on the website.

      Instructions work on cloned voices, but less reliably than on the built-in speakers, and it depends on the emotion, but honestly, it came out better than I anticipated. Definitely good enough to have some true custom voices for a voice over that don't necessarily sound like something, someone else has in their game.

      Other Fun Math

      If a voice is a point in a 2048-dimensional space and blending works we can maybe do some other funny math on it. The obvious one is to try to see if some math can be used to manipulate gender.

      To find it I had VoiceDesign create 14 different voices for men and women each. When you then take the average woman minus the average man you can then move any voice along that direction:

      women = torch.stack([fingerprint(f"design/f{i}.wav") for i in range(14)]).float()
men = torch.stack([fingerprint(f"design/m{i}.wav") for i in range(14)]).float()
middle = (women.mean(0) + men.mean(0)) / 2
axis = women.mean(0) - men.mean(0)
axis = axis / axis.norm()

def move(xvec, t):
    """Put the voice at position t along the gender axis, keep the rest."""
    x = xvec.float()
    return (x + (t - (x - middle) @ axis) * axis).to(torch.bfloat16)

      Here is the result for my clone:

      Interactive demo: see the post on the website.

      Anyways, that's that. If you want to play around with Qwen3 TTS I hope this was of some help, and maybe you got some ideas of what to do with the voice embeddings. Use it for good, not evil.

    18. ๐Ÿ”— Ampcode News macOS Satellites rss

      Amp now has a Mac: ask it to work on your iOS or Mac app and watch it build, test, and run the app.

      How It Works

      Your thread still runs on a Linux orb, next to your dev server and toolchain. The Mac is a second machine attached to that orb. Amp can automatically start a Mac, run commands on it, and read and write files, so it decides on its own when the work needs a Mac.

      When it does, our server boots a fresh Mac in the cloud with Xcode and the simulators installed, in about 30 seconds. Your orb connects to it and keeps your code in sync, so Amp still edits on the orb and only builds, runs, and tests on the Mac. Screenshots, logs, and builds come back to the thread, and the app on the Mac reaches your backend on the orb through portals.

      The thread's Mac tab streams the Mac's screen. Watch Amp's work, or take control of the Mac and try the app yourself.

      Your orb runs Linux with the thread, dev server, and toolchain. 1. It starts a macOS Satellite in about 30 seconds. 2. It syncs your code to the Mac. 3. The Mac builds, runs, and tests. 4. Screenshots, logs, and video come back to the orb.

      Every Mac starts fresh, and nothing on it is saved. When Amp is done with a Mac, it keeps it running for 20 more minutes. If you send a follow-up in that time, Amp reuses the same Mac and its build cache instead of starting a new Mac and building from scratch. After that, the Mac is deleted. To delete it right away, archive the thread or ask Amp to stop the Mac.

      Morbs Are Dead, Long Live macOS Satellites

      Before shipping macOS Satellites, we tried out Morbs: orbs that ran the whole thread on a Mac. But we ran into issues that made the approach unfeasible for a wider rollout. Docker and your backend took minutes to start there,[^1] and keeping a Mac disk around for every thread got expensive.

      So we split the thread across two machines. Everything that runs well on Linux stays on the orb and starts fast, and a Mac only shows up for the work that needs macOS.[^2] We're calling them macOS Satellites because they orbit your orb.

      Pricing

      Size CPUs Memory Price
      mac.medium 6 14 GB $2/hour
      mac.large 12 28 GB $4/hour

      macOS Satellite time comes out of the same orb usage your plan includes, just at a higher rate. Once that runs out, it comes out of your Amp credits, the same way orb time does.

      Every Mac starts as a mac.medium. If you need more, ask Amp for a mac.large, or turn off mac.medium under Mac Satellites in Settings โ†’ Experimental Features.

      Join the Waitlist

      macOS Satellites are in beta and opening up as we add Macs. Join the waitlist in Settings โ†’ Experimental Features. Each day you click Move Me Up moves you up the line.

      Go point Amp at that app you've been meaning to build! Find out more in the docs.

      New to Amp? Sign up and get started on your Apple apps.

    19. ๐Ÿ”— Ampcode News Visualize This rss

      You can now ask Amp to visualize or build something for you and it will do it, right in the thread: charts, timelines, diagrams, and mockups you can click through.

      Here are some examples, from our real threads. Go ahead, hover and click through them:

      Open the post on ampcode.com to see the chart of last month's commits that Amp drew.

      Here, for example, is an excerpt from Quinn's thread, where he asked for ways to fit a diff stat into a small button:

      Open the post on ampcode.com to try Quinn's sixteen diff stat buttons.

      And here's what went into building this feature:

      Open the post on ampcode.com to see the history of this feature that Amp drew.

  3. October 28, 2026
    1. ๐Ÿ”— IDA Plugin Updates IDA Plugin Updates on 2026-10-28 rss

      IDA Plugin Updates on 2026-10-28

      New Releases:

      Activity:

      • GhidraDec
        • 928255a7: Publish passing backfills incrementally and use a private feed secret
        • ffe9607a: Detach graph callbacks before plugin unload; test repeated GUI lifecycle
        • 37550375: Find IDA 9.5 macOS text-based linker stubs
        • d1c83448: Support Ghidra 12.2 and public SDK revisions; fix headless callbacks
      • ida-sigmaker
        • 608bc217: chore: release v1.15.1 (#96)
        • ef30d03e: fix: declare IDA 9.5 support in the plugin manifest (#95)
      • IDAPluginList
        • 5b051d81: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • pdb
    2. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +3 releases, -3 releases rss 
      sync repo: +3 releases, -3 releases

## New releases
- [ida-mcp](https://github.com/hexrayssa/ida-mcp): 20261028.0.3, 20261028.0.2, 20261028.0.1

## Changes
- [ida-mcp](https://github.com/hexrayssa/ida-mcp):
  - removed version(s): 0.10.4, 0.10.3, 0.10.2
    3. ๐Ÿ”— exe.dev Run Claude and GPT on exe.dev Without API Keys rss

      exe.dev integrations let you store secrets with exe.devโ€™s control plane so your VMs (and the agents on those VMs) can access services without seeing the secrets themselves. The next step is to avoid having the secret to begin with. When exe.dev and the other service both support Workload Identity Federation (WIF), you can do just that.

      If youโ€™ve been using API keys for exe.devโ€™s LLM gateway, thereโ€™s now another way. Both Anthropic and OpenAI support Workload Identity Federation. Two fewer keys to lose!

      Pro tip: agents are excellent at configuring WIF on your behalf.

      The Add Identity Federation Integration dialog in exe.dev, showing the issuer and subject to configure on the Anthropic side An Anthropic LLM integration set to use Workload identity

    4. ๐Ÿ”— backnotprop/plannotator v0.28.36 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.35 | Updates check the download against checksums Plannotator fetches itself, a failed check changes nothing
      v0.28.34 | Start a Grok Build session from the Inbox, action items in your reply, a tidier Board, Settings โ†’ Capabilities, a failed feedback send is shown
      v0.28.33 | Pi updates no longer get stuck on 0.28.31
      v0.28.32 | A security update (built on Bun 1.4.4, eMudhra certificates), the Inbox Board, custom Inbox prompts, hover cards for issue and PR links, rich-text Copy
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, ๐Ÿ‘ Looks good reaches the agent, notifications that never fail silently

      What's New in v0.28.36 Qwen Code joins Plannotator: the Inbox, plan review, Ask AI and the installers. Plans now open in the Clean look. Inbox messages can hold live HTML and diagrams, the Inbox has a Feedback button, and plannotator inbox gets status, stop and restart. 28 PRs. After you update, each agent's prompt cache misses once, because the Inbox tool description, the session reminder and the rules-file note changed. Plannotator Inbox Qwen Code in the Inbox plannotator inbox connects Qwen Code the way it connects Gemini CLI. It adds its own entry to Qwen's settings.json and keeps the file's comments. Qwen Code shows in Settings โ†’ Agents, and its sessions are tagged in the Inbox. When you reply to a running Qwen Code session, the reply arrives in it as its next turn. For this, Plannotator registers itself with Qwen Code (0.24 or later) as a trusted sender, so Qwen does not ask you before it takes the reply. Settings โ†’ Agents turns this off. Sessions that cannot be woken (Windows, qwen -p) get the reply on their next read. #2271, #2274 Live HTML, SVG and diagrams in a message An agent can put an html block in a message, and the Inbox draws it as a live, sandboxed page in the thread, in your theme. An svg block draws as a picture. Each one has Code and Full screen under it. Agents are told they can do this. #2288 Send feedback from the Inbox Feedback , above Settings in the sidebar, sends a message to the Plannotator team, with an optional category and email. The dialog shows exactly what is sent. Prompt your agent to send feedback copies a prompt: your agent asks you for the feedback, shows you the text, and sends it with the new plannotator feedback command only after you say yes. #2286 plannotator inbox status, stop and restart status shows the Inbox's URL, pid and version, and says when the running Inbox is a different version from your plannotator. stop ends only the Inbox of this data folder. restart starts the new version, and an agent that calls during the restart gets the new Inbox. The command shapes come from @rmohta's fork. #2276 Smaller changes Filter the Board by project. A Project button in the Board header shows when cards span two or more projects. #2284 A drawing goes into your reply at once. โœ“ or Enter adds it as a comment, with Undo. Escape cancels. #2254 Agents send updates and decisions when you would want them, and no longer hold them back to send later. #2287 Copy file in the code attachment viewer, for YAML, JSON, logs and other code files. #2253 Stopped and Holds up show as triangles in the list, and the agent's mark sits by the time. #2182 A choice written as markdown reads as its words in folded lines and answer rows, not as . #2219 Mark read works on an update you already opened while the list still holds it in New. Found by @seabass011. #2265 A thread with open questions no longer stays in Quiet in a narrow window or on a phone. #2270 Plannotator

      Qwen Code support

      Plan review opens when a Qwen Code agent leaves plan mode (Qwen Code 0.13.0 or later). After you approve in Plannotator, Qwen Code still asks you to confirm in the terminal: a Qwen hook cannot approve that step. /plannotator-review, /plannotator-annotate and /plannotator-last work in Qwen Code.

      Ask AI offers a Qwen Code provider when qwen is on your PATH, and uses it by default in a Qwen Code session. It runs in Qwen's plan mode, with the editing tools turned off.

      The install scripts set up the Qwen Code extension and skills when they find Qwen Code. --skip-qwen (-SkipQwen on Windows) turns this off. The session- log reader and the findings on Qwen's plan confirmation come from @NonoElRobot's Qwen Code port.

      Plans open in the Clean look

      Plan review and annotate now open in Clean, the document edge to edge. Grid is one switch away in Settings โ†’ Display.

      If you kept Grid, you move to Clean once and see a short notice. Pick Grid there to keep it; you are not asked again.

      Smaller changes

      • Comments on a plan's linked documents survive a reload. Each document's comments are saved on their own, in plan review and in annotate sessions on a URL or the last message. #2263, for #1545
      • owner/repo#N links to that repo's issue or PR in plan review, annotate and the Inbox, with hover cards. #2283
      • Taller issue and PR hover cards, and the footer stays in view in a short window. #2281
      • Ask AI with Claude loads your settings asclaude does, including CLAUDE.local.md and .claude/settings.local.json. Your Claude Code hooks now run in Ask AI sessions too. #2280
      • Code review previews follow links like VS Code, refuse files over 5 MB with a plain message, and no longer hang on a FIFO. #2272
      • Monospace digits no longer show as superscripts on Linux. #1963, for #1961
      • In the Grid look, a short plan's card runs to the bottom of the view. #2269
      • A question card's buttons wrap as whole buttons in a narrow column. #2266

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update npm:@plannotator/pi-extension

      OpenCode: Re-run the install script above. It also clears the OpenCode 2 plugin cache.

      What's Changed

      • Inbox: a drawing goes into your reply at once by @backnotprop in #2254
      • Code-nav and diff expansion: 5 MB cap and no FIFO hang, links followed like VS Code by @backnotprop in #2272
      • Monospace digits no longer render as superscripts on Linux (#1961) by @backnotprop in #1963
      • fix(inbox): a thread with open questions never stays in Quiet behind a covered list by @backnotprop in #2270
      • Ask AI: load Claude settings the way the CLI does by @backnotprop in #2280
      • Inbox: show a markdown choice label's words, not its markdown, in folded lines and answer rows by @backnotprop in #2219
      • feat(inbox): plannotator inbox status, stop and restart by @backnotprop in #2276
      • Open plans in the Clean look by default by @backnotprop in #2268
      • Inbox: Copy file in the code attachment viewer by @backnotprop in #2253
      • Inbox: Feedback in the sidebar, a write-only feedback Worker (deployed), plannotator feedback by @backnotprop in #2286
      • Guided Reviews: run your own claude and codex, not the adapter's bundled copy by @backnotprop in #2278
      • fix(inbox): keep Mark read on a seen update held in New by @backnotprop in #2265
      • Grid look: the plan card reaches the bottom of the view by @backnotprop in #2269
      • Link owner/repo#N refs; tell agents how refs link; Board card text links by @backnotprop in #2283
      • Taller issue and PR hover cards; keep the footer in a short window by @backnotprop in #2281
      • Inbox: row badges as triangles, agent mark by the time, hover card A by @backnotprop in #2182
      • Question card: the footer reflows as whole buttons in a narrow column by @backnotprop in #2266
      • chore(e2e): new specs no longer edit playwright.config.ts by @backnotprop in #2293
      • Inbox: connect Qwen Code and tag its sessions by @backnotprop in #2271
      • Qwen Code: plan review, skills and annotate-last by @backnotprop in #2273
      • Inbox: agents follow through on what they promised, without pinging (one wording per harness, parity test) by @backnotprop in #2287
      • Save plan review's linked-document comments per document (#1545) by @backnotprop in #2263
      • Inbox Board: filter by project by @backnotprop in #2284
      • test: qwen-session test never names the real ~/.qwen by @backnotprop in #2298
      • Installers: set up Qwen Code (extension and skills) by @backnotprop in #2275
      • Inbox: replies go into running Qwen Code sessions by @backnotprop in #2274
      • feat(inbox): live html, svg and diagram fences in a message by @backnotprop in #2288
      • Qwen Code: Ask AI provider by @backnotprop in #2279

      Community

      • @NonoElRobot: ported Plannotator to Qwen Code in a fork. The Qwen session-log reader, the extension layout and the findings on Qwen's plan confirmation in #2273 come from it
      • @rmohta: built plannotator inbox status, stop and restart in a fork, the shapes that #2276 uses
      • @seabass011: found in a fork that Mark read stopped working on an opened update, fixed in #2265
      • @TallJimbo: reported in #1961 that monospace digits rendered as superscripts
      • @utpalsinghdev: checked #1545 against main and asked what case was left, which led to the plan review fix in #2263

      Full Changelog : v0.28.35...v0.28.36

    5. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [SigMaker](https://github.com/mahmoudimus/ida-sigmaker): 1.15.1
    6. ๐Ÿ”— Simon Willison The October inflection point for vibe game development rss

      I've written before about how November 2025 was an inflection point for coding agents - the point where Opus 4.5 and GPT-5.1 crossed a tipping point that meant their respective coding agents became reliable daily drivers for software engineers. I think we've reached a new inflection point in October 2026, and this time it's for vibe coding computer games.

      Claude Opus 5.5 in particular exhibits meaningful improvements in several areas needed to build a compelling game:

      That last one is particularly important. Models have been able to create something that looks like a game for quite a while now, as seen in my previous experiments. The challenge has been getting to a game that's actually fun to play.

      Game design is a deep subject area. I won't pretend to be well versed in it - I know enough to have respect for it as a craft. Creating a novel, compelling gameplay loop which challenges players at the right level and provides a satisfying learning curve is a fine art. I didn't think the models could do it.

      Then I tried telling Claude Opus 5.5 to "Make it a LOT more fun"... and it did.

      In the past few weeks I've vibe coded (in the classic sense of the term - no looking at the code at all) four games that I've genuinely enjoyed playing.

      I attended Foo Camp in Berkeley over the weekend and met several people who were having similar experiences. Building games that play well is shockingly easy now. The new challenge is coming up with concepts for games that are novel and delightful and that wouldn't exist without AI assistance.

      I haven't done an exhaustive study, but my current impression is that GPT-6 Astra isn't quite there yet. It can absolutely build a game, but its sense of fun doesn't match that of Opus 5.5. I expect OpenAI will get there by the end of the year.

      Here are the four game projects that have convinced me that the models are now capable of producing fun games with very little guidance. All four are built in HTML and JavaScript and run entirely in the browser.

      Tree Appreciator

      The smallest game I found to be genuinely delightful is Tree Appreciator. I used the regular Claude chat interface for this - it didn't even need Claude Code.

      I built this on a whim while we were driving along Skyline Boulevard looking at trees. My prompt was:

      Build a three js game called "Tree appreciator" - it shows you two algorithmically generated trees and the game mechanics is about appreciating the differences between them. Think hard about how to make sure it is both fun and beautiful.

      I've found that telling models to use three.js works really well. Claude doesn't have its own image generation model but is capable of building full-color 3D models that look and feel excellent.

      This game required no iteration or follow-up prompting at all - I got the game in a single shot. It gave me back a charming little mobile-friendly spot-the-difference game. You can play that here. Here's the chat transcript that built it.

      Screenshot of a web game called Tree Appreciator, a spot-the-difference puzzle showing two side-by-side 3D renders of the same leafy green oak on a grassy hill at golden hour, with orange low-poly hills and a hazy sky behind and pale rocks in the grass. The left tree (Fig. i) has a small brown-and-orange bird perched near the top and a cluster of red-orange autumn leaves in its left canopy; the right tree (Fig. ii) has a small orange squirrel on a branch right of center. Header text: "Tree Appreciator" "No. 001 Quercus aurata 'Silver Echo'" "Golden oak ยท A low hill at golden hour", with sound, book and help icons at top right. A popup over the scene reads: "These two trees grew from one seed." "Three small things differ between them. Tap one in either tree when you spot it." "Drag to turn both trees. Pinch or scroll to look closer." with a "Got it" button. Panel labels: "Fig. i" "Fig. ii".

      It's pleasingly relaxing. The graphics are fun, and collecting trees that you have completed in a "herbarium" provides a nice, cosy sense of accomplishment.

      Emberwick

      This was a more ambitious project that I again built using regular Claude chat. I started out by building an experimental prototype of an engine for a top-down fantasy RPG:

      Build a demo game engine three.js which is a top down (but at an angle) RPG - the player gets to move through the world with one or two companions. Create a fantasy village setting that demonstrates walking around outside and then shows how when the player enters a building the wall between the player and the camera goes transparent so the user can see what is happening

      Add some NPCs and plenty of furniture and different types of building some with an upstairs - be creative, make it look great

      Here's that first version. It worked really well!

      Screenshot of a low-poly 3D top-down fantasy game showing the interior of a cutaway tavern at dusk, with grass, a lamppost and benches outside. Inside, warm candlelight falls on wooden floorboards: a stone fireplace with a figure in a red armchair on a red rug, a blue armchair with an orange cat on it, a long bar with barrels and bottle shelves where a red-haired barkeep stands, a candle chandelier, a cloth-covered table, small round tables with stools and a blue banner with a gold emblem. A group of three adventurers (a white-haired figure in a blue robe, a red-armored figure with a hammer and a green-clad figure) stands just inside the doorway. Top-left panel text: "Harvest Eve" "17:09" "Tavern & lodging ยท Taproom" "The Gilded Goose" with buttons "Dawn" "Noon" "Dusk" "Night" and a pause button. A speech bubble above the fireplace reads "โ™ช la la la โ™ช". A circular minimap sits at top right marked "N". Bottom center prompt: "F Talk to Old Fennick Regular". Bottom-left party portraits labeled "You" "Brakka" "Elowen". A "?" button sits at bottom right.

      I was inspired to increase my ambitions:

      Make it not so flat - the buildings are great but the landscape itself is completely flat at the moment, fix that

      Add basements to two of the buildings with a tunnel system joining them below the village

      Add the start of a rocky mountain on one side of the village containing a cave with a sleeping troll

      Here's that version.

      Screenshot of the same low-poly fantasy game, now in a dim underground cave lit by a campfire with a spit roast, glowing pale mushrooms and blue crystals. A huge green troll lies asleep on a straw bed at top right, surrounded by scattered bones and skulls. The cave also holds a small round pool ringed with stones, a yellow rug, chests, a fenced pen with a sheep, a pile of orange pumpkins and a stone stair down the left side. The party stands in the center: the green-clad figure and the red-armored figure facing the blue-robed figure holding a glowing staff by the fire, who says in a speech bubble "Smell that? Old brandy and older mud." The location panel reads "Harvest Eve" "17:25" "Underground ยท Under the mountain" "Grumblethorn's Cave".

      When that produced a good result, I decided to push it all the way:

      Now turn this into an actual game - quadruple the size of the playable area, introduce fun game mechanics, add a plot that isn't too cliche, some twists, a magic system, make it really good

      We're back to prompts like "make it really good" here! Asking for a plot that "isn't too cliche" seemed to work too - it's a bit clichรฉ, but still novel enough that I enjoyed following the story.

      Unlike Tree Appreciator, this took quite a bit of additional playtesting and prompting to get to a finished version. This was mainly due to gameplay problems - things like a character not being in the right place to complete a quest because a different story element had caused them to move to another location.

      Here's that final game. It has a full story that takes about 15 minutes to play through.

      Emberwick title screen. The 3D village sits in the background. The text reads Every fire in Emberwick was lit from the Hearthstone, and every fire dies at midnight unless it is lit again. Tonight the Hearthstone is gone, the wizard is missing, and the village is sure the troll did it. You came for the festival. Someone has other plans for you. Buttons for: Begin, Build your own places, Restore a save

      There's even an experimental level editor if you want to drop in your own houses, furniture, and landscape features.

      Once it was all working (and I'd iterated through some gameplay bugs), I played it through from start to finish and found myself emotionally affected by the ending! I'm somewhat embarrassed by this, because everything in this game - the graphics, the plot, the characters, the music, the dialog - came from the model. My creative input was pretty much just "it's a fantasy village and there's a troll asleep in a cave".

      Here's the full shared Claude chat in which I built this game.

      I also fed that same initial sequence of prompts through ChatGPT GPT-6 Pro. Here's the transcript and the finished game for comparison. It looks great, but I don't think it plays nearly as well.

      Battle Drones

      This is by far my most successful project, which I wrote about last week. It's a Command & Conquer-style Real-Time Strategy game where two robot armies (or four as of Saturday) build units, harvest scrap, and battle over territory.

      This is also the project that convinced me that Opus 5.5 knows what "fun" is.

      The first versions were built back in July using Claude Fable 5. It got me to a workable 2D Command & Conquer-style game, but it wasn't great to play.

      I prompted Opus 5.5 to "Make it a LOT more fun" and then later to "Port this game to three.js" and the game was transformed. There's a blow-by-blow account (prompts included) in my write-up.

      Today, Battle Drones has 2-4 player multiplayer (via a vibe coded WebSockets relay server), medals, replays, seven maps, a random map generator, and a set of "mutators" that add variants of the rules.

      It also lets different LLMs play against each other, using a mode where the game advances five seconds and then pauses to give different models time to interpret the new game state and line up their next set of commands. Here's a replay of Claude Haiku 5.5 vs. GPT-6 Luna:

      Screenshot of a replay of a real-time strategy game between two AI models, shown from a top-down view of a snowy map with a dark frozen lake of cracked ice floes on the left and pine forests at the top and lower right. Top bar: pause button, "6:27", "1ร—", "anthropic/claude-haiku-5-5 ยท industry" in blue, "gpt-6-luna ยท industry" in red, a blue-and-red strength bar labeled "B" and "R", and "0:03". Left notification: "Blue: Pushing turrets at the enemy's south-east edge." Replay panel: "Blue anthropic/claude-haiku-5-5 ยท industry vs Red gpt-6-luna ยท industry ยท frostbite seed 42", a timeline slider at "6:27 / 7:48", and buttons "โˆ’30s", "+30s", "All", "Blue's eyes", "Red's eyes", "Notes". In the scene, a group of blue tanks and a large blue Goliath mech trailing smoke advance near the ice edge at lower center, while a column of red turrets (one burning) lines the ice to their north, red tanks and trucks sit by a rocky ridge to the east, and red base buildings occupy the top right. A minimap is in the top right corner and zoom in, zoom out and lightning-bolt buttons are on the lower left.

      Battle Drones is a particularly good example of Opus 5.5's ability to create 3D models. This page lets you browse all of the models in the game.

      I released Battle Drones under the Apache 2.0 License last Tuesday. On Wednesday Gabriel Turpin released Panache (screenshots here), a fork of Battle Drones that reimagined the game for steampunk 1900s Belle ร‰poque France, with new models and music and an animated intro sequence. Open source at work!

      Pumpkin Farmer, aka Quarter Sun Cove

      I live in Half Moon Bay, California, home of the annual Half Moon Bay Art and Pumpkin Festival, which includes a giant pumpkin weigh-off competition.

      I decided to try building a game that wasn't just a cheap imitation of something that already existed, so I set out to create a game about farming pumpkins, growing giant pumpkins, and handling the rush of the October pumpkin season.

      I called it "Quarter Sun Cove".

      I'm still iterating on this project, but it's shaping up quite nicely. It's a cosy farming simulator where you spend the year tending to your giant pumpkin and planting out regular-sized pumpkins for sale in October, then sell pumpkins during pumpkin season and enter your giant pumpkin in the weigh-off.

      Every character in it is a (vegetarian) animal. The mayor of the town is a pelican. You can be a pelican, skunk, raccoon, possum, beaver, coyote, fox, owl, sea otter, or harbor seal. Those species all later show up (accompanied by their children) to buy pumpkins from you.

      It's absurdly cute.

      Screenshot of an isometric low-poly pumpkin farming game. In the bottom left, a huge giant pumpkin, far bigger than anything around it, sits in its own fenced plot under string lights. Beyond it are rows of pumpkin vines with a scarecrow and animal visitors (pelicans, beavers and otters) picking pumpkins and browsing the farm stand, plus a red barn, beehives, a cornfield, parked cars and a dock on the water, with fog drifting across. A side panel shows stats for the patch row "Row 3 ยท Warty" with a "Cut 7 โ†’ barn" button, and a customer review at the bottom reads "โ˜…โ˜…โ˜…โ˜…โ˜… Carried our pumpkin like a baby. It was heavier than the baby."

      You can play the latest version here. I'm not convinced by the game mechanics yet - it's actually quite complicated: you have to decide when to plant pumpkins such that they will become ripe at the weekends in October with the most visitors.

      Here's the initial brainstorming session, which resulted in this spec file. Then I had Opus 5.5 Ultracode burn millions of tokens and nearly two days building it.

      I told Claude to "surprise and delight the user frequently" and the result is so many little details and easter eggs. There are mischievous raccoons, an elephant seal that runs the weigh-off, harbor seals that roll their pumpkins back into the ocean, a wandering goat, and superstitions about growing giant pumpkins that sometimes come true.

      This isn't my best game yet - it's not as fun to play as Battle Drones - but it represents the kind of game I want more of: weird, fun, uniquely personal - something that wouldn't have been built in the before-times.

      Four times as insulting

      If you are offended by AI-generated art, AI-generated music, AI-generated writing, and AI-generated code, I have bad news for you: vibe coded games combine all of those at once.

      I respect those opinions, even though I donโ€™t strongly hold them myself.

      The wider games community already has an aversion to AI-generated assets in games. This has been a growing issue over the past few years as tools like Midjourney have enabled developers to generate assets for their projects. This IGN story covering complaints about slop in Valve's Steam Next Fest is a good recent example.

      We now have games where everything - code, assets, dialog, and even the game design itself - can be outsourced to the models. And the results don't suck!

      Building a computer game used to be one of the most challenging projects in all of software development, combining a diverse range of skills and requiring intense focus and effort over many months or even years. And now here I am spitting out a playable multiplayer RTS by prompting on my phone!

      I expect that, as we've already seen with programming, this will result in a split. Some players will refuse to have anything to do with games that were built in this way. Others may embrace this as opening up game development to a much wider audience. I lean in that direction!

      I certainly won't be entering any of my vibe coded games in traditional game jams or competitions - I don't feel like I've earned that right. We'll likely see new avenues emerge for vibe game developers to compare their projects.

      What happens if someone actually puts the work in?

      The thing I find both exciting and shameful about this is that I have got interesting results from so little creative input. The projects I've described here are loosely ordered by how much effort I've put into them. Not a single project represents more than four hours of my work (plus many more hours of Claude Code churning away by itself).

      Now imagine what could be achieved by anyone who takes this seriously, invests significant creative time, applies better taste in game design, and then playtests and iterates on the result until it's as good as they can make it.

      I want to see games that wouldn't have existed without these new tools.

      You should build a game!

      Building games in this way is so much fun. It's the perfect application for vibe coding because it's so low stakes: how much damage can you cause with a bug in a personal vibe coded game project?

      (OK, you can do some damage... my attempt at audio-based multiplayer gave my wife Natalie a nasty headache!)

      All of my games so far have been HTML and JavaScript using static hosting (generally GitHub Pages or Cloudflare Pages). Modern browsers - including mobile browsers - are incredibly capable. Frontier models already know libraries like three.js and Phaser. I'm finding these mobile web games to be indistinguishable from the native experience, at least for the kinds of games I'm trying to build.

      I suggest starting with a prompt like this:

      Build a mobile-friendly three.js game where...

      This works on both chatgpt.com and claude.ai - you don't even need to fire up a full coding agent. As one last example, here's "Build a mobile-friendly three.js game where a mouse has to hide from a cat" by Claude Opus 5.5 Extra and by GPT-6 Extra High.

      Switch to Codex or Claude Code once your project passes the proof-of-concept phase.

      And if the game isn't fun enough, add this:

      Make it a LOT more fun

      You are only seeing the long-form articles from my blog. Subscribe to /atom/everything/ to get all of my posts, or take a look at my other subscription options.

    7. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 release, -1 release rss 
      sync repo: +1 release, -1 release

## New releases
- [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.14.2

## Changes
- [ida-nexus](https://github.com/hexrayssa/ida-nexus):
  - removed version(s): 0.9.0
    8. ๐Ÿ”— r/Harrogate Looking for bandmates rss

      Im looking to start a band in the harrogate area, I play the guitar 7 string and 6 string, im an intermediate player and love nu-metal.

      Im 15 years old, nott looking for anyone over the age of 17 (sorry pedos)

      Ik looking for:

      2nd guitarist

      Drummer

      Bassist

      Singer

      All in that sort of nu metal style specifically bands like reville and stuk but in broader terms korn.

      Dm if you are interested

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

    9. ๐Ÿ”— roboflow/supervision supervision-0.31.3 release

      v0.31.3 โ€” Grayscale annotators, OpenCV-exact fallbacks, and merged YOLO

      polygons

      Grayscale scenes work with more annotators, the pure NumPy fallback matches OpenCV pixel for pixel, and YOLO export handles multi-part masks.

      • YOLO export merges multi-part masks into one polygon and skips crowd annotations, with flags for the old output.
      • Background overlay and comparison annotators draw on grayscale scenes.
      • Without OpenCV, resize, blur, blending, drawing and connected components give the same pixels as OpenCV.
      • Invalid input fails early: ImageSink, the video frame generator and depth arrays now raise clear errors.
      • Short hex colors such as "#f0f" work in annotators.

      Drop-in upgrade unless you export YOLO labels: the default output changes, see the Migration guide.

      โœจ Spotlights / highlights

      YOLO export merges multi-part masks and skips crowd annotations

      DetectionDataset.as_yolo now omits detections whose iscrowd flag is set and writes a mask with several disconnected parts as one merged polygon line instead of one line per part. Both are on by default. The merge is done by the new sv.merge_multi_segment, which joins the parts through zero-width seams at their nearest vertices. (#2786)

      import supervision as sv

dataset = sv.DetectionDataset(...)
dataset.as_yolo(
    images_directory_path="images",
    annotations_directory_path="labels",
    data_yaml_path="data.yaml",
)  # 0.31.3: crowd skipped, one merged polygon line per mask

dataset.as_yolo(
    images_directory_path="images",
    annotations_directory_path="labels",
    data_yaml_path="data.yaml",
    ignore_crowd=False,
    merge_segments=False,
)  # the 0.31.2 output

      sv.merge_multi_segment

      New public function. Pass it the polygon parts of one mask and get back a single polygon. (#2786)

      import numpy as np
import supervision as sv

a = np.array([[0, 0], [10, 0], [10, 10], [0, 10]])
b = np.array([[30, 30], [40, 30], [40, 40], [30, 40]])
sv.merge_multi_segment([a, b]).shape
# (10, 2)

      Annotators on grayscale scenes

      BackgroundOverlayAnnotator and ComparisonAnnotator now draw on scenes shaped (H, W) or (H, W, 1), or given as a Pillow "L" image, instead of raising ValueError. Short hex colors such as "#f0f" now work in annotators and sv.hex_to_rgba. (#2832, #2803, #2801)

      import numpy as np
import supervision as sv

scene = np.zeros((100, 100), dtype=np.uint8)
detections = sv.Detections(
    xyxy=np.array([[20, 20, 60, 60]], dtype=float), class_id=np.array([0])
)
sv.BackgroundOverlayAnnotator().annotate(scene.copy(), detections).shape
# (100, 100)  (0.31.2: ValueError)

      The NumPy fallback matches OpenCV pixel for pixel

      Without OpenCV installed, resize (INTER_LINEAR on uint8), blur, addWeighted, thin lines, circles, filled polygons that leave the canvas, connectedComponents and mean now give the same pixels as OpenCV. BlurAnnotator, HaloAnnotator, HeatMapAnnotator, PixelateAnnotator, the blending annotators, sv.resize_image, sv.letterbox_image and PolygonZone masks are affected. (#2833, #2836, #2811, #2808, #2810, #2812, #2820)

      Bad input fails early

      sv.ImageSink(overwrite=False) raises FileExistsError instead of replacing an existing image, sv.get_video_frames_generator rejects a stride below 1, and DepthMap.from_ultralytics rejects unwrapped integer arrays. (#2800, #2819, #2795)

      import supervision as sv

for frame in sv.get_video_frames_generator("video.mp4", stride=0):
    ...
# ValueError: stride must be >= 1, got 0

      ๐Ÿ”„ Migration guide

      One default behavior changes: YOLO export. No public symbol was removed or renamed in this release, and nothing is deprecated.

      YOLO export defaults affect sv.DetectionDataset.as_yolo, and save_yolo_annotations and detections_to_yolo_annotations in supervision.dataset.formats.yolo. Before 0.31.3 export skipped nothing and wrote a mask with several disconnected parts as one polygon line per part. From 0.31.3 export drops detections whose iscrowd flag is set in detections.data, and writes the parts of a mask as one merged polygon line. Label files exported with 0.31.3 can therefore differ from those exported with 0.31.2 for the same dataset. (#2786)

      • Nothing to do if you want crowd annotations dropped and one polygon line per mask.
      • To keep the 0.31.2 output, pass ignore_crowd=False and merge_segments=False to as_yolo.
      • Re-export datasets you trained on from 0.31.2 labels only if the crowd or multi-part masks matter to your training run.

      Three bug fixes also turn silent behavior into an error: ImageSink(overwrite=False) raises FileExistsError for an existing image (#2800), get_video_frames_generator raises ValueError for a stride below 1 (#2819), and DepthMap.from_ultralytics rejects unwrapped integer arrays (#2795).

      ๐Ÿ“ Notable changes

      ๐Ÿš€ Added

      • sv.merge_multi_segment โ€” joins the disconnected polygon segments of one mask into a single polygon. (#2786)
      • ignore_crowd and merge_segments โ€” new parameters on DetectionDataset.as_yolo, save_yolo_annotations and detections_to_yolo_annotations. (#2786)
      • Depth showcase example โ€” examples/depth_showcase runs Depth Anything V2 Large, Apple Depth Pro and a YOLO depth model through sv.DepthAnnotator on video files, webcams and streams. (#2804, #2818)

      ๐ŸŒฑ Changed

      • DetectionDataset.as_yolo now skips crowd annotations and writes multi-part masks as one merged polygon line. Pass ignore_crowd=False and merge_segments=False for the previous output. (#2786)

      ๐Ÿ”ง Fixed

      Annotators

      • BackgroundOverlayAnnotator and ComparisonAnnotator raised ValueError on grayscale scenes. (#2832, #2803)
      • Annotators and sv.hex_to_rgba rejected 3- and 4-digit short hex colors such as "#f0f". (#2801)

      Input validation, I/O and metrics

      • ImageSink(overwrite=False) silently replaced an existing image, including through a dangling symlink; it now raises FileExistsError, and a path with an embedded null character raises ValueError. (#2800)
      • get_video_frames_generator could yield frames past end for stride=0 or a negative stride; it now raises ValueError. (#2819)
      • DepthMap.from_ultralytics accepted unwrapped integer arrays as depth values. (#2795)
      • KeyPoints.as_detections and with_nms let an extra coordinate change the boxes; they now use x/y only. (#2817)
      • MeanAverageRecall.compute() raised IndexError when filtering by object size with shared scalar metadata. (#2791)
      • download_assets(VideoAssets.GROCERY_STORE) failed MD5 verification; the catalog now holds the checksum of the hosted file. (#2804)

      NumPy fallback without OpenCV

      • resize with INTER_LINEAR on uint8 images now matches OpenCV pixel for pixel; arm64 builds that hand some grayscale and RGBA resizes to the Carotene HAL can differ by up to two levels. (#2833)
      • addWeighted rounds 8-bit, 16-bit and float32 blends like OpenCV. (#2836)
      • blur rounds 8-bit results like OpenCV. (#2811)
      • line, polylines, drawContours and circle at thickness 1, and filled circles, match OpenCV; a negative circle radius raises ValueError. (#2808)
      • fillPoly and filled drawContours match OpenCV for polygons that leave the canvas. (#2810)
      • connectedComponents and connectedComponentsWithStats number 8-connected components in OpenCV's order. (#2812)
      • mean keeps small values when large positive and negative float32 pixels cancel. (#2820)

      ๐Ÿ† Contributors

      Welcome to our first-time contributors: Oke Iyanuoluwa Enoch, Maidul Hasan Masum, Jooyoung Lim, Zhenhuan Wang, Shreya Boyane, Carlos Maraรฑes, Vuln3rat0r and reuben rouse!

      • Oke Iyanuoluwa Enoch (@Iyanuoluwa007, LinkedIn) โ€” made the NumPy fallback match OpenCV for thin lines, circles, polygons, blur and connected components, and added strict type checking across the tests.
      • LEE, WEI-HONG (@AuricTW) โ€” made ImageSink refuse to overwrite existing images, rejected non-positive frame strides, and kept float32 precision in the mean fallback.
      • kevin (@kevin9327) โ€” made the NumPy fallback resize and addWeighted match OpenCV.
      • A Aswanth Raj (@aswanth-07, LinkedIn) โ€” built key point boxes from x/y coordinates and kept scalar metadata in recall size buckets.
      • Vuln3rat0r (@Vuln3rat0r) โ€” added sv.merge_multi_segment and merged multi-part masks in YOLO export.
      • Mohammad Hijjawi (@MohammadHijjawi97, LinkedIn) โ€” made BackgroundOverlayAnnotator work on grayscale scenes.
      • Shreya Boyane (@Sonica-B, LinkedIn) โ€” made ComparisonAnnotator work on grayscale scenes.
      • Carlos Maraรฑes (@cmaranes) โ€” accepted short hex colors in annotators.
      • reuben rouse (@reubenjrouse, LinkedIn) โ€” rejected unwrapped integer arrays in DepthMap.from_ultralytics.
      • Jooyoung Lim (@mmporong, LinkedIn) โ€” fixed docstring examples that were not valid Python.
      • Maidul Hasan Masum (@mh-masum6875) โ€” added type checking to the dataset, metrics and detection tests.
      • Zhenhuan Wang (@NaCr05) โ€” enabled strict typing for the conversion and iterable tests.
      • Jirka Borovec (@Borda, LinkedIn) โ€” added the depth showcase example and prepared the release.

      Automated contributions: Dependabot, Copilot, Claude, Codex, pre-commit.ci

      Full changelog : 0.31.2...0.31.3

    10. ๐Ÿ”— backnotprop/plannotator v0.28.35 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.34 | Start a Grok Build session from the Inbox, action items in your reply, a tidier Board, Settings โ†’ Capabilities, a failed feedback send is shown
      v0.28.33 | Pi updates no longer get stuck on 0.28.31
      v0.28.32 | A security update (built on Bun 1.4.4, eMudhra certificates), the Inbox Board, custom Inbox prompts, hover cards for issue and PR links, rich-text Copy
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, ๐Ÿ‘ Looks good reaches the agent, notifications that never fail silently
      v0.28.22 | ๐Ÿ‘ Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing

      What's New in v0.28.35

      Plannotator

      Updates check the download against checksums Plannotator fetches itself

      On macOS and Linux, plannotator update, the Inbox's Update now and the background auto-update no longer download with the system curl. On macOS, curl still trusts the leaked eMudhra root certificates. Plannotator now downloads the install script and the release's checksums over its own connection. The install script then checks the new binary against those checksums before it replaces anything. Windows is unchanged, because Windows already blocks those certificates.

      When a download does not match, nothing changes: the update stops with a plain message, and your Plannotator keeps working. The background auto- update then waits 1 day, then 3, then 7, before it tries that version again. A newer release, Update now and plannotator update try at once.

      Smaller changes

      • The install scripts carry the checksums of thesem download instead of reading them from the archive's own checksums.txt. #2218

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update npm:@plannotator/pi-extension

      OpenCode: Re-run the install script above. It also clears the OpenCode 2 plugin cache.

      What's Changed

      • Safe updates, step 1: Plannotator downloads the install script and checksums itself by @backnotprop in #2218

      Full Changelog : v0.28.34...v0.28.35

    11. ๐Ÿ”— backnotprop/plannotator v0.28.34 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.33 | Pi updates no longer get stuck on 0.28.31
      v0.28.32 | A security update (built on Bun 1.4.4, eMudhra certificates), the Inbox Board, custom Inbox prompts, hover cards for issue and PR links, rich-text Copy
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, ๐Ÿ‘ Looks good reaches the agent, notifications that never fail silently
      v0.28.22 | ๐Ÿ‘ Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
      v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused

      What's New in v0.28.34

      A tidier Board in the Inbox, a Board chip in compose, action items in your reply, hover cards in review, and failed sends that no longer look like they worked. Usage counts are removed. 25 PRs.

      Plannotator Inbox

      A tidier Board

      Lane cards are one title row now, with the marks and the age on the right. A second line shows only when you owe something ("You: โ€ฆ") or a send is waiting. "You: โ€ฆ" opens the thread where you decide, and an opened card has Open thread or Create thread at the top. Agents now give cards short titles of 2 to 5 words.

      Ask the agent to track new work on the Board

      Compose has a Board chip beside the Thread row. Turn it on, and the agent puts the work you ask for on the Board, unless a card already links the thread. The chip shows only while the Board is on.

      Settings โ†’ Capabilities

      A new Capabilities section holds the Board switch, with the Experimental switches under it.

      The Board switch has moved from Settings โ†’ General to Settings โ†’ Capabilities.

      Action items go in your reply

      Done and Can't do it now go into your reply draft, with any note, and reach the agent with your next Send.

      A Done no longer goes to the agent by itself after a few seconds; it waits for your Send.

      Agents reply in the right thread after compaction

      After the agent compacts its context or resumes, it gets the list of its open Inbox threads, so it replies where it should and not to a thread it half remembers. A decision that waits in the Inbox stays there: the agent no longer asks it again in the chat.

      Decide inside a thread (experimental)

      Decision mode now starts from a thread. When 2 or more decisions wait in a thread, "Decide these N" is the first row of its open questions.

      The Decide button beside the list title and the Decide row in the sidebar are gone.

      Start a Grok Build session from the Inbox

      When Grok Build is installed, New message can start a Grok Build session in any of your projects. The Inbox runs the session, so every reply you send reaches it as a real turn. You answer its permission requests in the thread. To turn it off, use Settings โ†’ Agents โ†’ Run in the Inbox.

      Smaller changes

      • Full screen goes back to where you opened it. ร—, Escape and the browser's Back return to the thread or to the file beside it. #2245
      • A recommendation written into a choice label counts. "Foo (Recommended)" shows as the recommended choice, with Accept recommended. #2247
      • ARecommended: line finds a choice written as a link or with formatting. #2251
      • A click anywhere in the reply box puts the cursor in it, so typed and dictated text no longer goes nowhere. #1960
      • A new Inbox tab is always counted as open, and a closed one no longer is. #2237, #2250
      • While the Board is off, agents see one line saying it exists and where to read about it. #2260
      • Cursor's Inbox note says plainly that you paste it into Cursor yourself, and the copy no longer carries markers that promise an automatic removal. #2162, for #1991

      Plannotator

      You see when feedback does not send

      In plan review, annotate and code review, a send that fails now shows why, with Retry and Copy feedback , and your annotations stay where they were.

      A failed approve or send now keeps you on the page; before, it could show the Approved or Feedback Sent screen.

      Hover cards for issue, PR and MR links

      In plan review, annotate and code review, pointing at a GitHub issue or PR link, or a GitLab MR link, shows its title and state, read through gh or glab on your computer. This works in Pi too. Remote sessions don't show the cards.

      Usage counts are removed

      Plannotator no longer has any code that counts the use of experimental features. Nothing was ever sent on its own: only a hidden command could send counts, and only when someone typed it. The experimental switches work as before.

      The hiddenplannotator telemetry command is gone.

      A one-time introduction to the Plannotator Inbox

      Plan review, annotate and code review show a short film about the Inbox once, with Close and Learn about the Inbox. After you close it, it does not show again anywhere.

      Smaller changes

      • Plan review keeps a plan's versions when Claude Code changes folder between submits, so the Versions tab and the diff stay. #2199, for #2197
      • Code review: "Edit Code to Suggest" moves to a new Experimental tab in Settings. #2234
      • Every published package is checked before release for settings that could hold an update back without a word, as happened to Pi on 0.28.31. #2238, for #902
      • The privacy page's contact email is nowramos@plannotator.ai. #2252

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update npm:@plannotator/pi-extension

      OpenCode: Re-run the install script above. It also clears the OpenCode 2 plugin cache.

      What's Changed

      • test: deflake four tests (clock, shared-events, multiTarget, auto-update SIGINT) by @backnotprop in #2237
      • refactor(core): move the Inbox thread's pure rules into @plannotator/core by @backnotprop in #2224
      • test(inbox): pixel and DOM parity harness for the thread by @backnotprop in #2222
      • Board: "You:" opens the thread where you decide; less padding under the lanes by @backnotprop in #2240
      • Settings: Capabilities section (Board, with Experimental inside) in the Inbox; Experimental tab in code review by @backnotprop in #2234
      • Inbox: Decide works inside a thread (no global queue) by @backnotprop in #2241
      • fix(questions): read a recommendation marked in a choice label, and nudge the agent toward Recommended: by @backnotprop in #2247
      • Board: Title-row lane cards, Open/Create thread on the opened card, short titles by @backnotprop in #2248
      • Show when feedback or a decision fails to send (Retry, Copy feedback) by @backnotprop in #2242
      • feat(inbox): open threads after compaction/resume, reply_to checks, chat-or-Inbox rule, notes refreshed at start by @backnotprop in #2246
      • Compose: a Board chip that asks the agent to track the work by @backnotprop in #2249
      • fix(questions): a Recommended: line names a markdown label by its plain words by @backnotprop in #2251
      • fix(inbox): full screen goes back to where it was opened from by @backnotprop in #2245
      • Remove the usage counts for experimental features; keep the flags by @backnotprop in #2259
      • Privacy page: contact email is ramos@plannotator.ai by @backnotprop in #2252
      • Inbox: a press anywhere in the reply box puts the caret in it by @backnotprop in #1960
      • One-time Plannotator Inbox announcement in plan review, annotate and code review by @backnotprop in #2256
      • fix: honest wording for Cursor's copy-by-hand Inbox note (follow-up to #2153) by @backnotprop in #2162
      • fix(plan): keep a plan's version history when the session cd's into another repo (#2197) by @backnotprop in #2199
      • chore(deps): bump motion from 12.43.0 to 14.4.0 by @dependabot in #2202
      • Inbox: one Board line for agents while the Board is off by @backnotprop in #2260
      • Hover cards for issue, PR and MR links in plan review, annotate and code review (Bun and Pi) by @backnotprop in #2262
      • fix(inbox): a closing tab no longer counts itself again after pagehide (notify_reach e2e) by @backnotprop in #2250
      • Inbox: action items go in the person's reply by @backnotprop in #2216
      • ci: guard every published package against update-blocking fields by @backnotprop in #2238
      • Inbox: start a Grok Build session from New message, every reply a real turn (ACP runner, step 1) by @backnotprop in #2174

      Community

      • @HunterClarke-git: reported in #1392 that feedback could be lost
      • @zane668: gave a step-by-step reproduction in #1392 of feedback lost after Plannotator stopped, and reported in #902 the Pi update that stuck on 0.28.31, which the new release check guards against
      • @kyletruong: asked in #1991 for the Inbox note in Cursor
      • @aomalov: reported in #2197 that plan history lost its versions after a change of folder, and proposed a fix in #2205

      Full Changelog : v0.28.33...v0.28.34

    12. ๐Ÿ”— Filip Filmar A Rocket Core on the AX7A200B, over Ethernet rss

      FireSim runs simulated RISC-V systems on an FPGA. Its design with one Rocket core, Berkeley’s 64-bit RISC-V processor, now runs on an Alinx AX7A200B board. The host reaches the board over an Ethernet cable instead of PCIe, and the simulated core’s memory is the board’s DDR3. The core loaded programs, printed on its UART, read UART input, wrote an instruction trace, and ran a compute-bound loop at 42.5 MHz effective, on a 50 MHz FPGA clock. The full write-up is a three-page paper: FireSim over Ethernet: A Rocket Core on a Low-Cost FPGA Board (PDF).

    13. ๐Ÿ”— Filip Filmar FireSim Over Ethernet on the AX7A200B rss

      FireSim’s GCD example now runs on an Alinx AX7A200B board, with the host connected over a plain Ethernet cable instead of PCIe. On the board, a TxHDL unit takes register reads and writes out of raw Ethernet frames and performs them on the simulator’s control port. On the host, a 260-line platform file sends those frames from FireSim’s unchanged driver. Once the board was programmed, the test passed on its first run. The link is slow: FireSim reports an effective target clock of 0.938 kHz.

    14. ๐Ÿ”— Filip Filmar Hardware Development with Bazel: the book is out rss

      My book Hardware Development with Bazel: Authoring HDL Rules came out on 27 October 2026, in paperback and for Kindle. It has 334 pages. It teaches you to write Bazel rules for hardware: VHDL simulators, verification frameworks and AMD Vivado, up to complete verification and RTL-to-bitstream flows. This post explains who the book is for and what is in it.

      The cover of Hardware Development with Bazel

      Why I wrote it

      Hardware teams build FPGA and ASIC designs with Makefiles, TCL scripts and vendor GUIs. Those builds cannot tell what really needs to rebuild after a change. They also often cannot reproduce last year’s bitstream on a new machine, because the result depends on what is installed on the host.

    15. ๐Ÿ”— Ampcode News Your Own Self-Hosted Orbs rss

      You no longer need to be in a workspace to self-host orbs. Up until now, only workspace admins could manage self-hosted orb providers.

      Now, you can add a provider in your personal Settings โ†’ Orbs and set it up the same way as a workspace provider. When you create a thread, it shows up under Self-Hosted, marked Personal.

      The new thread composer with the orb picker open and my-orbs selected under Self-Hosted, marked Personal

  4. October 27, 2026
    1. ๐Ÿ”— IDA Plugin Updates IDA Plugin Updates on 2026-10-27 rss

      IDA Plugin Updates on 2026-10-27

      New Releases:

      Activity:

      • ffxiv_bossmod
      • ida-nexus
        • 5f422f61: Merge pull request #82 from HexRaysSA/fix/66-failed-launch-extraction
        • e8e18044: Fix failed-start database extraction cleanup (#66)
        • f8987335: Merge pull request #81 from HexRaysSA/fix/analysis-completion-73
        • 5232eee5: Fix false autoanalysis cancellation
        • d84e0ef9: Merge pull request #80 from HexRaysSA/grace-expiration-fix
        • 3f8f634d: Fix managed-worker lease grace during publication
        • 93972419: Merge pull request #79 from HexRaysSA/indexer-bug
        • eadc42ee: Make sure indexer works when launching the GUI
    2. ๐Ÿ”— ghostty-org/ghostty v1.4.0 release

      v1.4.0

    3. ๐Ÿ”— exe.dev Automatic Compaction: How Shelley Keeps Going and Going Without Losing the Plot rss

      When it comes to LLMs, context rules everything around us. An agent loop is inherently quadratic: messages accumulate and every iteration you send the full stack of messages to the model. That stack of messages is the context , and it starts with a system prompt, descriptions of the tools, and your instructions. Messages upon messages get added. Tool responses (in other words, the agent reading your source code) usually end up being the majority of the context. This impacts cost (see Expensively Quadratic: the LLM Agent Cost Curve) and quality. You want to give the model just the "right amount" of context, but how?

      Every LLM call resends the whole context

      Compaction is the process of taking your current (long) conversation and rewriting or removing stuff to make it a shorter conversation.

      Shelley's approach to compaction is to insert a "nudge" message from the harness at about 200k tokens and to give the model a compaction tool that lets it (a) truncate specific tool outputs and (b) "squish" together sections of history into smaller, rewritten segments (which will then have pointers to the originals). 200k seems like the sweet spot for current frontier models, but we've left the exact number configurable.

      The compaction tool requires a few rounds. First, the model gets an "index" so that it can identify the messages by a sequential id. Then, the model suggests messages to collapse or trim. Shelley has a "linter" that verifies that the compaction isn't too big or too little. The model tries again, and usually the second time is just right. After compaction, the conversation continues as it always did, except the squished chunks are shorter, the verbose tool outputs are trimmed, and evidence of the compaction is no longer visible to the LLM.

      From a data model perspective, a Shelley conversation has some mutable state (slug name, model choice, current draft) and an append-only log of messages. Compaction is materialized as special "compaction" messages, and the harness, when concatenating all the messages together to send to the LLM, replaces the relevant chunks with their rewrites and trimmed results. If the model ever wants to read something that got compacted away, the data is in SQLite, and Shelley has a skill to hint at the right query. (One of Shelley's principles is the ability to be introspective. I tuned the linter heuristics by having Shelley introspect and backtest its own past conversations.)

      Shelley's in-place compaction

      This is Shelley's third(!) implementation of compaction. The previous two implementations started a new "generation" of a conversation inside the same conversation, with a brand-new context and a summary (first implementation), and preserving the most recent messages (second implementation). This third implementation keeps it going as one conversation, but the history is somewhat rewritten. I'd love to believe this is our last implementation, but model capabilities have been changing quickly, and I expect there will be more iteration.

      From the cost perspective, this is the cost graph for a recent long Opus 5.5 conversation. It adds up to about $25 and has gone through 4 compactions, with the context length capping out at about 200k. The little arrows where the price spiked are $1 cache misses, probably when I stepped away from the computer. (You can get this graph in your Shelley session by clicking on the context length counter.)

      Shelley context and cost graph Context length and cumulative cost for a long Opus 5.5 conversation, across 4 compactions.

      We've been rocking this implementation for a few weeks, and we think it works quite well. We've enabled "auto compaction" by default. I used to click on "Compact and Send" every once in a while and look at the context length. Now, I just talk, and talk, and talk, and it's all good. I've also started letting my agentic conversations meander a bit more, do follow-ups and so on.

      Tune in next week to hear about switching to asynchronous tool and subagent calls. Or maybe we'll talk more about multiple input modalities!

      If you're interested in more of our writing about coding agents:

      P.S.: Here's a behind-the-scenes look at yak-shaving involved in building the animation above. I built it using Shelley, after having earlier built a bespoke program using Excalidraw, and after adding animations to said bespoke drawing program.

      The compaction animation in the drawing app Building out the animations for this post in Shelley

    4. ๐Ÿ”— r/Harrogate Is Jennifield Drive quiet? rss

      Hi! I'm looking to move to a quiet area in Harrogate. I saw a place near Jennifield Drive (around Lindrick Way), is this street noisy? I would like to avoid cars playing loud music, making loud engine noises, etc. Leeds it's usually like that on some similar streets, that's why I'm asking. Thanks

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

    5. ๐Ÿ”— backnotprop/plannotator v0.28.33 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.32 | A security update (built on Bun 1.4.4, eMudhra certificates), the Inbox Board, custom Inbox prompts, hover cards for issue and PR links, rich-text Copy
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, ๐Ÿ‘ Looks good reaches the agent, notifications that never fail silently
      v0.28.22 | ๐Ÿ‘ Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
      v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused
      v0.28.20 | Inbox search (โŒ˜K), real folder names for projects, data files open in the code view, word-only replies leave questions open

      What's New in v0.28.33

      A fix for Pi users stuck on 0.28.31. 1 PR.

      Plannotator

      Pi updates no longer get stuck on 0.28.31

      0.28.32 required a newer Node for the Pi extension. On an older Node, npm then kept 0.28.31 without an error, and plannotator update still printed "Pi extension updated." That Node requirement is gone. Instead, Pi shows one warning at start when its runtime does not have the October 2026 TLS fixes (Node 22.23.4, 24.22.1 or 26.12.1). The installer now updates Pi with pi update and checks the version that Pi actually loads.

      Smaller changes

      • The installer's npm check stops quickly on a broken network. #2233

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update npm:@plannotator/pi-extension

      OpenCode: Re-run the install script above. It also clears the OpenCode 2 plugin cache.

      What's Changed

      • fix(pi): updates never get stuck: drop the Node floor, verify the installed version by @backnotprop in #2233

      Community

      • @zane668: reported in #902 that plannotator update left the Pi extension on 0.28.31

      Full Changelog : v0.28.32...v0.28.33

    6. ๐Ÿ”— backnotprop/plannotator v0.28.32 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.31 | An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the plugin tool
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, ๐Ÿ‘ Looks good reaches the agent, notifications that never fail silently
      v0.28.22 | ๐Ÿ‘ Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
      v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused
      v0.28.20 | Inbox search (โŒ˜K), real folder names for projects, data files open in the code view, word-only replies leave questions open
      v0.28.19 | Ask this session in T3 Code, folder sessions load shared stylesheets and images, the agent note asked once per agent, Copy connect prompt

      What's New in v0.28.32

      A security release: the binaries are now built on Bun 1.4.4, which no longer trusts the compromised eMudhra certificates. Also a Board page for the Inbox (off unless you turn it on), custom Inbox prompts, hover cards for issue and PR links, replies that wake Codex, and rich-text Copy. 26 PRs: two from @utpalsinghdev and one from first-time contributor @meowhib.

      On v0.28.30 or older? Run the install script once: curl -fsSL https://plannotator.ai/install.sh | bash (Windows: irm https://plannotator.ai/install.ps1 | iex). plannotator update on those versions asks only GitHub's API and may not reach this release.

      Security: update now (eMudhra certificates)

      Eight eMudhra intermediate certificate keys (6 for TLS, 2 for code signing) chaining to emSign ECC Root CA - G3 were found this month to be trivially recoverable; no misuse has been seen. Release binaries are now built on Bun 1.4.4, which drops that root and blocks the 8 compromised keys whatever root they chain to. v0.28.31 and earlier trust the root and have no block. Please update.

      Plannotator also runs inside other hosts, which need their own update:

      • OpenCode plugin: update OpenCode to 1.19.4 or later (it runs on Bun 1.4.4).

      • Pi extension: run Pi on Node 22.23.4, 24.22.1 or 26.12.1 or later in the same line. On an older Node, a fresh install gets 0.28.31 while pi update gets 0.28.32; 0.28.33 removes that floor.

      • VS Code extension: desktop VS Code blocks the keys from 1.144 (Electron 43.8.1 or later); 1.143.x desktop does not. Remote SSH, WSL and containers are fixed in 1.143.1.

      • #2215, from @iMacTia's #2214 and @FNDEVVE's Bun 1.4 work in #1489

      Plannotator Inbox

      The Board (off by default)

      A Board page of cards in lanes, for work you and your agents track together. Agents can add cards, you can drag them between lanes, and a card links its threads, PRs and issues with their live state. It is off unless you turn it on in Settings โ†’ General โ†’ Board; while off, agents are not offered the card action and nothing changes.

      Custom Inbox prompts

      Settings โ†’ Prompts replaces the Inbox reminder your agents get at session start, for every agent or per host (Claude Code, Pi, OpenCode). It is also in config.json under prompts.inbox.

      Hover cards for issue, PR and MR links

      Rest the pointer on a link to a GitHub or GitLab issue, pull request or merge request (or a #123 the Inbox links) to see its state, title, author, checks and review state without opening a tab.

      Replies wake Codex

      Your Inbox reply now reaches the Codex thread that asked as a new turn, with no plugin. Needs Codex CLI 0.149 or later.

      A tour in the real Inbox

      The onboarding tour now walks through the Inbox's own viewers: a question with pictures, a comment on its words and on a file, one Send, then compose and Artifacts. It still writes nothing to your Inbox.

      Smaller changes

      • Never stuck on a version. If update checks keep failing for 3 hours, the Inbox, review windows and the terminal say so and show the install command; a stuck "Updatingโ€ฆ" is released and shown as Failed. Settings โ†’ General now has the update control. #2210
      • Pi, Oh My Pi and OpenCode 2 sessions get a reload line when they run older Plannotator code than what is installed, with the command to copy: /reload in Pi, /restart in Oh My Pi, opencode2 reload in OpenCode 2 (or opencode2 plugin list && opencode2 plugin update <spec> when the plugin itself is behind). Claude Code sessions already got /reload-plugins. #2213
      • /plannotator-inbox opens the Inbox and shows its address, in every agent that has the other /plannotator-* commands (plannotator inbox --open in a terminal). #2207
      • Pull down to refresh the list on a phone. #2204
      • Question cards on a phone keep their buttons whole, radios show when picked, and pasting an image works. #2206
      • Coming back from a file keeps your place in the thread. #2208
      • An ร— button exits full screen in the desktop file view (Escape still works). #2217
      • The thread's foot shortens its words before its status wraps onto a second row. #2186
      • An action item's why shows as Markdown , not raw ** and backticks. #2225

      Plannotator

      Copy as rich text

      Copy in the selection toolbar (now on desktop too) puts rich text and plain text on the clipboard together. A selection pasted into Outlook, Slack or a doc keeps its headings, lists, links, code and tables; pasted into a terminal or prompt, it is plain text with its line breaks. Works in Markdown, HTML and live app annotation, plan review and the Inbox.

      Package changes in code review

      A Packages card under each changed package.json or lockfile lists the dependencies the diff adds, removes, upgrades or downgrades, with the versions the lockfile resolved. Lockfile-only diffs, such as Dependabot's, get one too.

      Smaller changes

      • Built on Bun 1.4.4. It drops the compromised eMudhra root certificate, and the CLI uses less memory and starts faster. #2215
      • Security: live app annotation never proxies a Plannotator server. A page loaded through the live app proxy could make same-origin writes to the Inbox or another review; every Plannotator server now refuses proxied requests. #2190
      • Pi: an update while a review is open no longer loses your feedback. #2223
      • A pending comment on a hidden slide hides with it and comes back with your text when you return. #2185 by @utpalsinghdev, closing #1431
      • Annotate's file browser says when it hit its file cap (5,000 by default, PLANNOTATOR_FILE_BROWSER_MAX_FILES) instead of dropping files silently. #2189
      • Agent guidance split into focused guides , so harnesses that load AGENTS.md get a short map. #2193 by @meowhib, closing #2192
      • Dependency updates. #2200, #2203

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update --extensions

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      New Contributors

      Community

      Full Changelog : v0.28.31...v0.28.32

    7. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [DelphiHelper](https://github.com/eset/delphihelper): 1.26
    8. ๐Ÿ”— r/Harrogate DANCE EVENT - 28TH NOV & 5TH DEC - HARROGATE rss

      DANCE EVENT - 28TH NOV & 5TH DEC - HARROGATE | Heyyyyy Harrogate team ๐Ÿคฉ Hope you are keeping well! We are back for number 002 & 003 of Loose ๐Ÿ˜ Completely free entry so I am only promoting a good time ๐Ÿซถ & if it was anything like the 1st one itโ€™s not an event to miss ๐ŸฆŽ Itโ€™s hosting all independent Harrogate DJโ€™s at an Harrogate independent venue!
      Major Tomโ€™s Social
      7pm - late
      Free entry
      Pizza til 9pm
      Board games Easy listening to dance tunes ๐Ÿ’ƒ ๐Ÿ•บ ๐Ÿชฉ Jazz house
      Afro House
      Funk
      Groove
      House
      Techno
      Acid
      Minimal
      UKG
      Bassline Loose is a place to leave your worries at the door & let loose, we are all in this together ๐ŸฆŽ All promo is over on Instagram @mclaren.edj 18+ with encouragement for all ages to show up and show out, thereโ€™s music for everyone & you might even find something new you like! Old skool & New skool ravers welcome ๐Ÿซถ๐ŸฆŽ If you wanna come n have a dance & make some new friends drop by! Hope to see some of you there! Thank you! ๐Ÿซถโค๏ธโ€๐Ÿฉน I AM A HARROGATE LOCAL, BORN N BRED. So youโ€™d be supporting a local event with local djs! submitted by /u/EllsMcL
      [link] [comments]
      ---|---

    9. ๐Ÿ”— Project Zero Fuzzers vs. AI: Comparing Fuzzilli and BigSleep on JavaScript Engines rss

      Summary

      Project Zero compared two automated tools used by Google to find vulnerabilities in Chromeโ€™s JavaScript engine, V8, on a regular basis. Fuzzilli is a generative JavaScript engine fuzzer and BigSleep is an LLM-based bug finding system. In the past six months, BigSleep found more vulnerabilities than Fuzzilli (45 versus 37) with a 25% overlap in the specific bugs reported. Since this comparison methodology has a tendency to underestimate overlap, we also performed dedicated experiments to test theoretical overlap in vulnerabilities reported since 2023. These experiments estimated overlap at roughly 60%. Regardless of which value is accurate, a substantial portion of vulnerabilities were discoverable by only LLMs or only fuzzing. While it is extremely promising that LLMs have become able to find so many vulnerabilities so quickly, fuzzing and LLMs are still complementary approaches. We recommend vendors perform both fuzzing and agentic analysis of their code to maximize the number of vulnerabilities that get reported before they impact users.

      Introduction

      Fuzzing has long been successfully applied to software projects such as Chrome or V8 (Chromeโ€™s JavaScript engine) to detect bugs. Recently, the arrival of powerful LLMs able to read, reason about, and write code is causing a transformative change to software development and software security. With hundreds, sometimes thousands of new bugs and vulnerabilities having been discovered in well-fuzzed targets, a natural question arises: how do new LLMs compare to โ€œtraditionalโ€ fuzzers? Are they starting to replace them or do the two approaches complement each other? To help answer this, we look at three key questions:

      1. How many bugs does each approach find in the real world?

      2. What is the overlap between the two approaches?

      3. What is the โ€œshapeโ€ of bugs discovered by one system but not the other?

      For this blog post, we will limit ourselves to two concrete systems: Fuzzilli, a JavaScript engine fuzzer, and BigSleep, an agentic bug finding system. Both of these systems run in production and automatically look for bugs in newly added code, which makes them fairly directly comparable. Specifically, Fuzzilli runs continuously across many instances, with the first ones usually picking up new changes within a few hours, while BigSleep currently runs once per day and is prompted to review new commits and write proof-of-concept testcases for any bugs it discovers. Both systems report bugs through Clusterfuzz, which will do basic crash triaging, then file bug reports in Chromeโ€™s issue tracker.

      We also limit ourselves to V8 as a target, a high-performance JavaScript and WebAssembly engine with a sophisticated and mature testing and fuzzing setup. In particular, Fuzzilli is a special-purpose fuzzing tool designed to find bugs in these engines. The usually complicated nature of these bugs makes for an interesting โ€œplaygroundโ€ to compare the two approachesโ€™ ability to find deep and complex bugs in well-tested software. We leave it to future work to perform similar analysis on a broader set of targets, fuzzers, and agentic bug finding systems.

      We will now look into each of the three main questions in a dedicated section. Each section will first summarize the general approach, then describe the methodology in detail (often as bullet points, so you can skip those blocks if you donโ€™t care too much about the details) before exploring the results. We conclude with an attempt at interpreting the results to get a picture of the current state of fuzzing vs. AI.

      Part 1: Production Statistics

      This is the simplest part to analyze, although with some caveats weโ€™ll see in a bit. The basic idea is to query issues from Chromiumโ€™s bugtracker (where V8 bugs are tracked) and extract various statistics from there. This is especially easy since thereโ€™s a dedicated hotlist for each of the two systems. We limit our analysis to the six months from April to September 2026 as the automatic BigSleep pipeline only became active in April this year. As such, our raw data comes from the following two bug tracker queries:

      From there, the raw numbers of bug reports are:

      • Fuzzilli: 316

      • BigSleep: 441

      Small win for BigSleep. However, this includes all types of bugs, and BigSleep initially also found a lot of configuration and integration issues in V8, for example crbug.com/503869331 where the unsafe flag blocking mechanism didnโ€™t work properly yet. These are legitimate issues, but less relevant for our comparison since thereโ€™s little real-world security impact. One easy way to get rid of these is to look specifically at vulnerabilities by limiting the results to type:vulnerability:

      • Fuzzilli: 178

      • BigSleep: 95

      Suddenly a clear win for the fuzzers? Not quite. There are still some problems with this data, notably duplicates and unactionable reports (e.g. bugs closed as WAI). At first, this seems like a simple thing to fix: just include another constraint such as status:(fixed | verified). Unfortunately, things are a bit more complicated. Take for example Fuzzilli bug crbug.com/511935486. The events on this bug are basically:

      • The bug is filed by Clusterfuzz on May 11 and assigned to an engineer

      • The bug is closed by Clusterfuzz as the testcase no longer reproduces later that same day

      As such, this bug received zero developer interactions. Most likely what happened here is that this bug was a duplicate of another bug, crbug.com/511210507, but Clusterfuzz didnโ€™t realize it as the crash signature (derived from the stack trace) was slightly different. When the other bug received a fix, the testcase stopped reproducing on Clusterfuzz, which closed the issue.

      Maybe the best thing we can do is to look at โ€œactionableโ€ bugs, defined as those that are not marked as duplicates or WAI and that received at least one fix commit referencing them. Then, looking at only Type-Vuln bugs filters out a lot of the less-relevant BigSleep bugs, even though these were โ€œactionableโ€. With that, the final picture looks like this:

      So in terms of vulnerabilities, itโ€™s roughly a tie (small advantage BigSleep) at the moment: 45 vs. 37.

      This naturally raises the question of cost: how expensive is each of the two approaches and what does that mean in terms of cost-per-bug? Unfortunately, itโ€™s challenging to make a comparison at this stage in the research. While some effort has been dedicated to making Clusterfuzz more efficient, similar effort has not been expended for Big Sleep and neither system is particularly calibrated for an optimal cost-per-bug ratio.

      Part 2: Overlap

      The next question is how much these approaches overlap each other. For this, our approach is twofold: we first attempt to find an answer in the bugtracker, by trying to identify bugs discovered by both systems. Next, we run a dedicated experiment in which we let BigSleep try to rediscover old Fuzzilli bugs.

      Bugtracker Overlap

      The basic idea is to see which bugs were found by both systems, so weโ€™re effectively looking for duplicate bug reports. Similar to part 1, there are a few steps we need to take to ensure we get a somewhat accurate picture:

      • First, we look for bugs filed by one system that get deduplicated into a bug filed by the other. For example crbug.com/522410841 which is a duplicate of crbug.com/522860268. This is a clear overlap.

      • Next, we need to take into account that many โ€œunactionableโ€ reports (those with zero associated fixes) are often duplicates. For those reports, we need to find the commit that fixed them, then look at the bug associated with that commit, and treat these two bugs as duplicates. This can be a multi-prong relationship: both bug X found by BigSleep and bug Y found by Fuzzilli might be a duplicate of bug Z reported by someone/something else. In that case, that bug still counts as overlap.

      • Then, we need to realize that many duplicates never receive a bugtracker entry since they are already deduplicated at the Clusterfuzz level (since both Fuzzilli and BigSleep rely on Clusterfuzz for basic triage and bug filing). As such, we need to query Clusterfuzzโ€™s underlying database to find more duplicates.

      • Finally, we need to decide what to do with separate bugs that get fixed by the same CL, for example the four bugs fixed by crrev.com/c/7965120. While this can legitimately happen for distinct bugs, itโ€™s probably more likely for the bugs to be duplicates (such as in this case), and so we count them as such.

      With all the different types of deduplication, we get this final picture:

      Again, looking at just the actionable vulnerability reports (likely the best measure), we see an overlap of roughly 25% (20 out of a total of 81), with a slight majority of these found first by Fuzzilli and later by BigSleep.

      Overlap Experiment

      The second way to measure the overlap is to run a dedicated experiment in which we try to re-discover bugs found by one system in the past using the other. Specifically, here we try to re-discover old Fuzzilli bugs using a BigSleep setup thatโ€™s as close to the production configuration as possible. For each bug we collect the commit that (likely) introduced the bug, and ask the agent to review those changes just as in the production CI environment. Note that the other direction, trying to rediscover past BigSleep bugs with Fuzzilli is more difficult to set up, since fuzzers cannot easily be given a similar โ€œstarting pointโ€. Moreover, for many of these bugs we already know the outcome of such an experiment: the majority of โ€œhistoricโ€ BigSleep bugs (e.g. those from 2025) were found after fuzzers like Fuzzilli had already been fuzzing vulnerable builds for months, sometimes years. So they would most likely also not rediscover them in an experiment (except perhaps in a few cases where Fuzzilli was since updated to support new language features). Similarly, in production, BigSleep only reports crashes with a delay of 1-2 days (as thereโ€™s currently only one run per day). As such, fuzzers also get a head-start there.

      In more detail, here is how the experiment is set up:

      • We start with a list of historic Fuzzilli bugs (from early 2023 until mid-2026) by querying the bug tracker hotlist. This gives us around 1150 raw bugs.

      • We restrict this to only type:vulnerability as these are the types of bugs we care most about and will remove some โ€œnoiseโ€ as above. We are left with roughly 600 vulnerabilities.

      • Next, we filter this list down to bugs that reproduce in the environment used by the agent. This involves two parts:

        • Bugs that reproduce on an x64 debug+asan build of the d8 shell as provided by Chromeโ€™s public build infrastructure. This is important because many bugs only reproduce in special builds, for example because they are architecture-specific or need certain compile-time features.

        • Bugs that can be reproduced without special flags. The problem here is that fuzzers often set custom flags, either to enable in-development features (e.g. --experimental-wasm-jspi in crbug.com/361123483) or to turn on different fuzzing modes that make certain types of bugs easier to discover (e.g. --deopt-every-n-times in crbug.com/362784006). However, we canโ€™t let the agent set arbitrary flags on historic V8 builds as these didnโ€™t have a โ€œsafe-flags onlyโ€ mode (leading to many false-positive crashes), and we also donโ€™t want to tell the agent which flags it should use for a given challenge as that would be a hint. As such, for simplicity we limit ourselves to bugs that can reproduce with a standard set of flags (--fuzzing, --jit-fuzzing, --expose-gc) and only allow the agent to set those.

      • We end up with 132 historic bugs.

      • We now perform some deduplication similar to what we did above to identify implicit duplicates, which we remove. This leaves us with a final number of 112 bugs.

      • For a realistic comparison, we then convert these bugs into โ€œcode review challengesโ€ similar to the ones used by the production BigSleep pipeline. For that, we try to identify the commit that (likely) introduced the bug, for example based on bisection. We note that this skews the comparison against BigSleep for two reasons:

        • We likely sometimes identify the wrong commit that is unrelated to the bug in question, making the task harder or even impossible.

        • We only have one commit per bug, while in the real world, the agent might discover the bug from another, subsequent commit that touches a similar part of the codebase.

      • We now run the agent for 25 attempts on each commit. The agent is asked to find bugs related to the commit and prove their existence by writing a testcase that crashes the vulnerable build. The attempt is terminated once a crash is found, so each attempt can report at most one bug. We use essentially the same configuration that was used in production BigSleep at that time, including the same underlying model: Gemini 3.6 flash.

      • Finally, we run some post-processing on the results to check if the agent found the โ€œrightโ€ bug or an unrelated one. For that, we check that the testcase crashes the pre-fix revision but not the post-fix revision. This is imperfect but fairly easy to implement.

      Here are the results from the experiment:

      Starting from just the commits that (likely) introduced the bugs, BigSleep was able to re-discover ~62% of the original bugs, while finding a different (but by now fixed) bug for another ~12% of commits. On around 26% of the commits it failed to find any bugs.

      Memorization

      One thing to worry about with experiments such as this one is memorization: the LLM remembering specific bugs from its (pre-)training data and as such having an easier time โ€œre-discoveringโ€ them during evaluation. We can try to get some idea of the effect of this by looking at the success rates for bugs from different time spans, e.g. every half-year period for which we have bugs in the data set. If there was memorization, weโ€™d expect higher success rates (both for a single attempt and for the combined run) on bugs prior to the learning data cutoff of the model. Here are the results for our experiment:

      For the model used in this experiment (Gemini 3.6 flash), the knowledge cutoff date is March 2026. Combining that with the fact that in early 2026, Chrome bugs would only become publicly visible after ~3 months, the effective knowledge cutoff for Fuzzilli bugs should be around Jan 2026. Looking at the data, there seems to be no statistically significant amount of memorization pre-2026. We note, however, that this may be different for other models or future model generations and as such recommend that this be re-evaluated for similar experiments in the future.

      Difficulty

      A follow-up question we might ask is how the overlap compares with โ€œdifficultyโ€. For example, in the best case a system like BigSleep would easily find issues that fuzzers struggle with and vice versa. In that case, budget that was previously spent on long fuzzing sessions may now be re- allocated and put to different uses. Here are the results of analysing this, where โ€œbug difficultyโ€ is measured by the time it took Fuzzilli to discover the bug:

      While we do get a statistically significant result here (although not of particularly great magnitude), it actually points in the other direction! Bugs that are hard to find for a fuzzer are likely also hard to find for an AI agent. As such, those fuzzers should probably be kept running for now.

      Components

      Another thing we can look at is a per-component breakdown of the bugs and their rediscovery rates:

      Interestingly, the overlap is significantly smaller for compiler bugs. This is the area where Fuzzilli probably specializes most in, which may explain the results. Later on (in part 3), weโ€™ll also develop another hypothesis for why (some) bugs in the compilers may be more difficult to rediscover for BigSleep.

      Prompting

      A final question is how much the specific prompting played a role in the performance of the AI agent. For that, we run two quick follow-up experiments, only on the bugs that werenโ€™t previously re-discovered and with different prompts:

      1. Instead of starting from commits, we start from the vulnerable file or function. This may be an easier starting point but is still a fairly realistic setup since both can for example be obtained by extracting modified files and functions from a given commit.

      2. Instead of asking the agent to find memory corruption vulnerabilities (what we care most about), we specifically tell it that assertion failures and similar crashes are also desirable.

      Running these two experiments with only 5 attempts per bug (instead of the 25 used in the main experiment), the agent re-discovered 10 additional bugs in total: 8 from the different starting points and 7 with the rephrased prompt (with 5 found in both runs).

      In total, combining these results with our original experiment, we get the following picture:

      So the share of โ€œcorrectโ€ bugs found climbs to ~70%, and we find some kind of bug for ~84% of starting points. However, for fairness it should be noted that equivalent tweaks to a fuzzer could likely also result in higher discovery rates for certain bugs, so the results of this follow-up experiment should be treated with some caution.

      Summary

      The main results from our two angles are:

      1. In production, the overlap is noticeable but not substantial at around 25%.

      2. In our experiment, overlap was around 60% of historic Fuzzilli bugs (70% with additional runs that used different prompts).

      3. The overlap is not uniformly distributed:

        1. Bugs that are difficult for a fuzzer to find are more likely to also be difficult to find for an agent, so thereโ€™s more overlap on โ€œeasyโ€ bugs.

        2. The overlap seems to be smaller in the JIT Compilers and higher in the rest of the engine.

      From just the experiment, we might expect a higher overlap in production. However, there are probably a few factors that prevent(ed) this:

      • Thereโ€™s a limited time window for overlaps: once a bug reported by either system is fixed, the other system no longer has a chance to rediscover it (as the bug wonโ€™t reproduce on Clusterfuzz and will therefore be discarded).

      • Our experiment only looked at a subset of Fuzzilli bugs that reproduce on a standard x64 d8 fuzzer build and without special flags. In production, each system has access to slightly different and specialized builds, as well as different runtime flag constraints, and there the overlap is potentially smaller.

      • Pipeline hiccups such as overloaded servers or bugs in the automation likely prevented a number of commits from being reviewed by BigSleep in the last months, so bugs introduced by them may have been missed.

      • Since its introduction in April, the model underlying the BigSleep pipeline has been upgraded multiple times. Earlier models likely performed worse, and we expect future models to perform better.

      Part 3: Shape of Bugs

      In this section, we will first look at three case studies of bugs found by one system but not the other, then attempt to draw conclusions from these and other bugs.

      BigSleep: Chrome Bug 449760249 (October 2025)

      This bug is a nice example of BigSleep benefiting from the underlying modelโ€™s reasoning capabilities to discover a variant that was (likely) too complex to trigger by a fuzzer in a reasonable amount of time. Itโ€™s also a good example to show the general working of an agentic bug finding system.

      Background: TDZ and Hole Check Elision

      Before diving into the bug specifics, we first need to look at some JavaScript internals, specifically variable initialization. In JavaScript, variables declared with the let or const keywords cannot be used before they are initialized, and attempting to do so will lead to an exception (โ€ReferenceError: Cannot access 'foobar' before initializationโ€). In V8โ€™s terminology, these variables reside in a โ€œtemporal dead zoneโ€ (TDZ) until they are initialized. Internally, V8 sets variables in the TDZ to a special sentinel value, the_hole, and then checks for this value when accessing the variableโ€™s content.

      To limit the performance impact of these hole-checks, V8โ€™s bytecode compiler implements an optimization (behind the default-enabled --ignition-elide- redundant-tdz-checks flag) to identify redundant checks and subsequently remove them. The idea here is to identify โ€œdominatingโ€ checks where it can then be guaranteed that a hole-check has already been performed for a given variable on all possible paths leading to the current position.

      This is a security-relevant optimization as an incorrectly removed hole-check would result in the internal the_hole value leaking to JavaScript code, a condition that has historically been exploitable (although new mitigations for this bug class have since shipped).

      The Original Vulnerability

      The original bug (issue 40071027 - discovered two years earlier by Fuzzilli!) involved do-while loops containing a break statement. In a do-while loop, the loop condition evaluates after the body. If the condition contains an assignment to a variable, the bytecode compiler will mark the variable as initialized. However, if a break statement executes in the loop body in the first iteration, then the condition will never execute. The bytecode compiler originally failed to account for this, leading to an incorrectly omitted hole check and subsequent leak of the_hole value.

      To fix this, the implementation of BytecodeGenerator::VisitDoWhileStatement was modified in the following way:

      - VisitForTest(stmt->cond(), ...);
+ if (!loop_builder.break_labels()->empty()) {
+   HoleCheckElisionScope elider(this);
+   VisitForTest(stmt->cond(), ...);
+ } else {
+   VisitForTest(stmt->cond(), ...);
+ }

      Specifically, the patch works by creating a HoleCheckElisionScope for processing the condition code in case the loop contains break statements. This means that any updates to the TDZ state of variables will be discarded once the scope object is destroyed. As such, code after the loop will see the previous TDZ state (which is the correct behavior in this case).

      Discovery of the Variant

      The BigSleep agent began its analysis by examining the patch to VisitDoWhileStatement, realizing that the fix relied on loop_builder.break_labels()->empty() to decide if a protective HoleCheckElisionScope was required. It then began creating and testing various hypotheses for scenarios in which no break statement was registered with a given loop but the condition would still be skipped at runtime. For example, it hypothesized that a try-catch in combination with a throw inside the loop might confuse the hole-check elision logic. It then investigated how try-catch was implemented in the bytecode compiler and concluded that this was handled correctly.

      Eventually, the agent started investigating labeled breaks, which allow directly breaking out of inner loops. It hypothesized that these might not be handled correctly and continued to investigate how these were being processed, for example by studying the logic in BytecodeGenerator::VisitBreakStatement. This time, it seemed to have identified a real flaw: in the case of nested breaks, the inner loop was apparently not being informed of the existence of a break statement! It therefore formulated the following vulnerability hypothesis:

      1. If a labeled break inside a do-while loop targets an outer scope, the inner do-while loopโ€™s LoopBuilder is not notified.
      2. Consequently, loop_builder.break_labels()->empty() remains true.
      3. Therefore, when generating the code for the loop condition, the HoleCheckElisionScope introduced by the patch is not used.
      4. The condition is bypassed at runtime, but the bytecode compiler erroneously removed a later hole-check, leading to a leak of the_hole to JavaScript.

      The agent then began writing a testcase to prove the existence of this bug. The initial attempt with simply two nested loops and a label failed, however, as the bytecode compiler would add another protective scope object for the labeled block. To work around this, the agent decided to use a switch statement. When handling a switch statement, the bytecode compiler uses a HoleCheckElisionMergeScope to compute the intersection of initialization states across all branches. By ensuring that the variable was initialized in a default case, the merge logic then concluded that the variable was correctly initialized on all paths.

      Proof of Concept

      With that, the agent had everything in place to produce a testcase to demonstrate the vulnerability. Below is the agentโ€™s PoC:

      // Flags: --ignition-elide-redundant-tdz-checks
function trigger(cond) {
  {
    target: switch(1) {
      case 1:
        do {
          // Labeled break targeting the switch. The do-while LoopBuilder remains unaware.
          if (cond) break target;
        } while((x=1) && false); // Condition performs a check/assignment on x.
        break;
      default:
        x=1; // Ensure x is considered initialized across all switch branches for merging.
    }
    // Generator incorrectly believes x is checked/initialized. Elides TDZ check.
    x + 1;
    let x;
  }
 }
 trigger(true);

      Here is how this testcase works:

      1. trigger(true) executes, entering case 1 of the switch.
      2. The do-while loop executes break target.
      3. Control flow jumps to the end of the switch, bypassing the do-while condition where x is assigned.
      4. At runtime, x remains uninitialized (holding the_hole).
      5. Because the TDZ check was elided at compile time, the engine leaks the internal the_hole value to JavaScript code in the x + 1 expression, leading to a potentially exploitable condition.

      We can see how this bug would be difficult for a fuzzer to find since the testcase is quite complex. While a coverage-guided fuzzer would have received rewards for triggering individual code paths (such as the handling of labeled break, the switch statement, the do-while loop, etc. in the parser), there is no additional reward for putting these together โ€œin the right wayโ€ and so ending up with a testcase like this is quite difficult.

      BigSleep: Chrome Bug 443765373 (September 2025)

      This bug is an example of a relatively simple bug type that is challenging to discover with standard fuzzing approaches.

      Background: Exception handling in V8

      To understand this bug, it is necessary to briefly look into exception handling in V8. Take the following example JavaScript code:

      function simple() {
  try {
    throw 42;
  } catch (e) {
    return e;
  }
}

      Here, we have a function consisting of a try-catch block in which an exception is raised. Running this in d8 with --print-bytecode, we can see the internal bytecode that the engine generates to execute the JavaScript code:

      [generated bytecode for function: simple]
         0x2ad5001000e4 @    0 : 1b ff f9  Mov <context>, r0
         0x2ad5001000e7 @    3 : 0d 2a     LdaSmi [42]
         0x2ad5001000e9 @    5 : b5        Throw
         0x2ad5001000ea @    6 : d1        Star1
         0x2ad5001000eb @    7 : 8d f8 00  CreateCatchContext r1, [0]
         0x2ad5001000ee @   10 : d2        ...
         ...
         0x2ad5001000f7 @   19 : b7        Return
Handler Table (size = 16)
   from   to       hdlr (prediction,   data)
  (   3,   6)  ->     6 (prediction=1, data=0)

      For the purpose of this bug, the relevant part is mostly the last line of the output. Here, the bytecode essentially says โ€œif there is an exception while the PC is between offset 3 and 6 in this bytecode, then execution should continue at offset 6 (the start of the exception handler)โ€.

      The Bug

      The agent spotted the bug while looking at the following function, responsible for writing the handler table data structure in memory:

      void HandlerTable::SetRangeHandler(int index, int handler_offset,
                                   CatchPrediction prediction) {
  int value = HandlerOffsetField::encode(handler_offset) |
              HandlerWasUsedField::encode(false) |
              HandlerPredictionField::encode(prediction);
  int offset = index * kRangeEntrySize + kRangeHandlerIndex;
  Memory<int32_t>(raw_encoded_data_ + offset * sizeof(int32_t)) = value;
}

      Here, the int offset is being combined with a few other bits of data into a new int value. As such, the handler_offset cannot have the full integer range in the new field, possibly leading to integer truncation issues. The agent then investigated the specific bounds of these values and realized that the HandlerOffsetField had only 28 bits (allowing for 256MB) while the maximum bytecode size was 512MB! From there it was relatively simple to craft a testcase that crashes, simply by creating a huge function (resulting in

      256MB of bytecode) with an exception handler at the end, then triggering an exception inside of it. The result is a jump to a wrong bytecode offset, a primitive thatโ€™s easily exploited. Here is the relevant part of the testcase:

      // yield statements turn into a large chunk of bytecode
let kNumYields = 500000;

let body = `
  if ("foo" === "bar") {
    ${"yield* 42;".repeat(kNumYields)}
  }
  try {
    throw 42;
  } catch (e) {
     // Will never get here
  }
`;

      Such a testcase would again be difficult to craft by a fuzzer as the fuzzer isnโ€™t rewarded for creating large code (at least not with generic coverage feedback). In fact, the fuzzer is likely even actively discouraged from finding this bug since generating and executing large bytecode takes some time (in debug builds, the testcase generated by the agent needs a few seconds to trigger) and would therefore probably have led to timeouts during fuzzing.

      Fuzzilli: Chrome Bug 40076141 (November 2023)

      This bug is a good example of a type of bug that is likely difficult to find just by looking at (one part) of the source code. It was originally discovered by Fuzzilli and not rediscovered by any of the experiments from part 2.

      Background: Value Representation in V8

      Consider the following piece of JavaScript code:

      let i = 42;
let f = 13.37;
let s = "foobar"
i = s;

      Here we create multiple variables holding values of different types. Note, however, that we never declare the type of a variable, and that variables can hold values of different types throughout their lifetime (i first contains an integer, later a string). What we see here is that JavaScript is a dynamically typed language, and so variables (and also object fields, etc.) have no fixed type. However, the actual runtime values still need to have a type: the engine somehow needs to know that foobar is a string value and that certain operations (e.g. substring search) can therefore be performed on it. Conceptually, this is possible by representing runtime values with a struct such as

      enum JSType {
    JS_TYPE_INT,
    JS_TYPE_FLOAT,
    JS_TYPE_STRING,
    ...
};

struct JSValue {
    JSType type;
    // Either the raw value or a pointer to another object, e.g a JSString.
    uintptr_t value;  
};

      However, this is somewhat inefficient since we now need something like 16 bytes to represent a simple 4-byte integer at runtime. As such, modern JS engines use clever tagging schemas, which rely on unused pointer bits to encode type information. Specifically, in V8 the JSValue type is a tagged pointer (or just tagged for short) which stores one bit of type information in the least-significant bit:

      • If the bit is one, then the value minus 1 is a pointer to another object. This works because objects are aligned and so cannot start at an uneven address.
      • If the bit is zero, then the next 31 bits contain a raw integer value (also called a small integer - Smi)

      As such, to figure out the type of a value at runtime, the engine first looks at the least-significant bit. If that is zero, the value can be โ€œuntaggedโ€ to obtain the integer value by right-shifting by one. On the other hand, if the bit is one, the value is a valid pointer to an object that contains further type information. For more details on V8โ€™s pointer tagging scheme see also this blog post.

      The Testcase

      Letโ€™s start by looking at the testcase produced by the fuzzer, which isnโ€™t overly long:

      function f0() {
    let v2 = 1;
    for (let i3 = v2; i3 >= v2; i3 += v2) {
        v2 = v2 && i3;
    }
}
f0();

      The bug is caused during optimization of the loop by the Maglev compiler, specifically due to a conflict between two stages of the compiler pipeline: the initial graph builder and the later MaglevPhiRepresentationSelector.

      The Graph Builder

      The graph builder is responsible for building the initial Maglev intermediate representation (IR) of the code. For that, it consumes both the input code (in the form of V8 bytecode) as well as runtime feedback that was collected while the code executed in lower tiers such as the interpreter. When processing the loop in this testcase, the following happens:

      1. Both i3 and v2 are modified during the loop. Since the IR uses static single-assignment (SSA) form, these turn into Phi nodes, which make the code look like every variable only has a single assignment :)
      2. For the i3 >= v2 comparison, the runtime feedback states that i3 was so far always a Smi and therefore speculates that this will be the case in the future. It guards this assumption by emitting a CheckedSmiUntag, which will extract the raw int from the tagged value and will bail out to the interpreter if the input is ever not a Smi.
      3. For the following operations on v2, the compiler can then rely on the existing check and emit UnsafeSmiUntag nodes, which avoid the runtime checks but are only safe to use if the input is guaranteed to be a Smi.

      The resulting code for the loop now looks roughly like this (in Maglev pseudocode):

      loop:
  i3 <- Phi(1, i3_next)                   // loop variable, tagged
  v2 <- Phi(1, v2_next)                   // loop variable, tagged

  i3_int <- CheckedSmiUntag(i3)           // deopt if i3 is not a Smi
  v2_int <- CheckedSmiUntag(v2)           // deopt if v2 is not a Smi
  if i3_int < v2_int: break

  v2_next <- Phi(i3, v2)                  // result of `v2 && i3`: "known Smi"
  v2_next_int <- UnsafeSmiUntag(v2_next)  // no (re-)check needed
  i3_next_int = i3_int + v2_next_int
  i3_next <- Int32ToNumber(i3_next_int)   // tag the int32 result for the phi

      The MaglevPhiRepresentationSelector

      The purpose of this optimizer is to identify Phi nodes where all inputs have the same raw representation (e.g. int32), and if so convert the Phi to that representation to avoid future untagging operations. For the code above, the code sees that both inputs to i3 are int32 and therefore decides to convert the Phi to int32 representation. Following CheckedSmiUntag operations then become a no-op and can be removed, while consumers that need a tagged value now require a conversion step. With that, the final code now looks like this:

      loop:
  i3 <- Phi(1, i3_next)                   // all inputs int32, so i3 becomes a raw int32
  v2 <- Phi(1, v2_next)                   // stays tagged

  v2_int <- CheckedSmiUntag(v2)
  if i3 < v2_int: break                   // CheckedSmiUntag(i3) removed as a no-op

  i3_tagged = Int32ToNumber(i3)           // HeapNumber if i3 >= 2^30!
  v2_next <- Phi(i3_tagged, v2)           // stays tagged, needs tagged inputs
  v2_next_int <- UnsafeSmiUntag(v2_next)  // HeapNumber pointer treated as a Smi
  i3_next <- i3 + v2_next_int             // tagging no longer needed here

      The Conflict

      The bug now occurs because of two optimizations interacting badly with each other:

      1. The graph builder uses UnsafeSmiUntag as it believes that the value must be a Smi at this point
      2. The representation selector removes a CheckedSmiUntag as it believes it is no longer required

      Specifically, what can happen now is that eventually, i3 becomes larger than the maximum Smi value. At that point, Int32ToNumber can no longer fit the integer into a Smi and instead allocates a HeapNumber object (a container holding a larger number, basically). At this point, however, the UnsafeSmiUntag is no longer safe as the input is now a pointer. This leads to a corrupted pointer value being extracted and subsequently to memory corruption. Note that in the original code, this could not have happened as the HeapNumber wouldโ€™ve been rejected by the CheckedSmiUntag(i3).

      What may have made this bug difficult to find for BigSleep is the fact that both optimizations are correct in isolation. As such, looking at just one of them wouldโ€™ve made it difficult to spot the issue. The agent would somehow have needed to hypothesize about the other optimization or stumbled upon the relevant code by chance (or exhaustive search).

      Overview

      Looking at the examples above as well as other bugs found by LLMs, we can see a few clear examples of bugs where an LLM has the advantage:

      • Bugs that require complex logic to trigger but can be found through progressive logical reasoning and experimentation with the target program, such as crbug.com/449760249 discussed above. This is likely the strongest advantage.
      • Bugs that require specific โ€œmagicโ€ values (e.g. edge-case integers, specific strings, etc.), such as crbug.com/443765373 discussed above.
      • Bugs that require new (or less common) features that a fuzzer may not be aware of. Examples include crbug.com/436181695, where the fuzzer didnโ€™t support the new await using syntax yet, and in fact also crbug.com/449760249 above where Fuzzilli lacked support for labeled breaks at the time.
      • Bugs that require a non-standard harness, custom flags, or special helper tools/functions that a fuzzer is not configured to use (e.g. crbug.com/516833326 which required --expose-fast-api and the d8.test.FastCAPI API).

      On the other hand, here are some advantages that fuzzers enjoy (for now):

      • They can find โ€œnon-localโ€ bugs reasonably well if not too many individual pieces are required. crbug.com/40076141 discussed above is an example for such a bug.
      • They can find bugs that are hard to spot by reasoning about the source code alone. One clear example would be bugs caused by (incorrect) C++ compiler optimizations such as crbug.com/500771385. Another potential example is bugs such as crbug.com/414840455, which are related to handling dead code in V8โ€™s compilers. This is likely an unusual state and therefore may be hard to reason about. BigSleep missed a few of these in our experiments.
      • They are immune to certain biases affecting the agentic approaches, such as the choice of starting point (e.g. commits), the exact prompt phrasing, or the bug types seen (and not seen) during training. They do suffer from other types of biases though (e.g. the weights of individual mutators and generators).
      • They donโ€™t get distracted by โ€œshallowโ€ bugs, whereas BigSleep missed a few bugs because it found easier ones instead. This is probably somewhat self-correcting though as the shallow bugs would eventually get fixed, giving the agent another chance to discover the deeper bug.

      There is probably also a category of bugs that are hard to find for both approaches: bugs that are very non-local (bad for the agent) and require complex testcases (bad for the fuzzer) to trigger. In this case, a fuzzer would probably discover the individual pieces of the testcase (through coverage feedback) but wonโ€™t be able to find the right combination to trigger the bug (as in our first example). A code-reviewing agent, on the other hand, may struggle with the large search space of code fragments that may interact badly with each other (as in our last example). This is only a hypothesis, however, and would require further experiments and data to validate.

      Part 4: Conclusion

      In this blog post, weโ€™ve compared coverage-guided fuzzers with vulnerability- discovery agents that read and reason about the source code. Specifically, weโ€™ve looked at Fuzzilli and BigSleep, which both run as automated pipelines on V8 to discover newly introduced bugs. Looking at the data from those pipelines, we saw a roughly equal share of vulnerabilities found in the last 6 months (around 40 each), and a moderate overlap in discovered bugs of around 25%. However, in a dedicated experiment, overlap was closer to 60%. For now, this means that the two approaches remain complementary, and specialized fuzzing continues to provide value by finding bugs quickly and identifying certain kinds of issues that are otherwise hard to spot. At the same time, LLMs only very recently became capable of finding bugs in software like V8 at all, and have made tremendous progress since. The model used for our experiment is by now already outdated and outperformed by newer generations. Looking to the future, we expect further model improvements, potentially coupled with better prompting and more flexible harnesses (that e.g. allow the model to build, improve, and run fuzzers itself instead of being limited to pure code auditing), to lead to a growing share of bugs being discovered by agentic systems.

    10. ๐Ÿ”— Filip Filmar An AXI bus in TxHDL: links, routers and bridges rss

      Complex designs in TxHDL communicate over AXI4 interfaces. The Vreteno RISC-V processor, the Razboj rasteriser, DDR3 memory controllers, Ethernet MACs, and HDMI video controllers all use AXI interconnects. This post describes the AXI components in the TxHDL standard library. The library provides high-level channel abstractions, hardware protocol trackers, address routers, and bridges to AXI-Lite and Wishbone. All components lower to synthesizable Verilog and VHDL, verified against randomized bus fuzzing on every build.

    11. ๐Ÿ”— Filip Filmar FireSim Under Bazel rss

      FireSim is an open-source tool from UC Berkeley that runs a chip design, usually a RISC-V system written in Chisel, on an FPGA, so that it is simulated cycle by cycle, far faster than in software. FireSim 1.22.0 now builds under Bazel, from Chisel source to a bitstream and a host driver, with no sbt, conda or Vivado project on the host. Upstream, getting a machine ready to build FireSim takes dozens of pages of setup instructions. Under Bazel, all of that setup comes down to a single bazel_dep line in MODULE.bazel. It is a net of 22 small modules in my Bazel registry, most of them build files laid over an upstream commit, plus one rules module, rules_firesim. On FireSim’s own Nitefury II recipe, a single Rocket core, the build gives a bitstream that meets timing on Vivado 2025.2. Three problems decided the design: Golden Gate needs Chisel 6’s FIRRTL, it needs an older Scala and other dependency commits than the target, and Chisel writes machine paths into the output.

    12. ๐Ÿ”— Ampcode News Amp on Android rss

      We now have an Android app:

      The Amp design talk thread in the Amp Android app The slide deck in the Portals tab of the Amp Android app The present.js diff in the Changes tab of the Amp Android app

      Download and install from ampcode.com/app, or scan this QR code:

  5. October 26, 2026
    1. ๐Ÿ”— IDA Plugin Updates IDA Plugin Updates on 2026-10-26 rss

      IDA Plugin Updates on 2026-10-26

      New Releases:

      Activity:

      • ffxiv_bossmod
      • gpt6-Astra
        • e431bc16: fix: restore desktop CI for all fifteen model seats
      • ipyida
        • 656c0f2a: Fix typos in comments and docstrings
      • oh-your-pi
        • a1a8fbf3: fix(coding-agent): declare the jsonc-parser runtime dependency
        • 9b6add8c: fix(stats): stop the dashboard rendering a blank page
        • 76021787: feat(coding-agent)!: drop third-party config discovery providers
        • 8544f448: feat(coding-agent): state oyp/omp identity in the default system prompt
      • plugin-ida
        • 0b245f51: chore(deps): Bump actions/setup-python from 7.0.0 to 7.1.0 (#34)
        • f33a1a58: chore(deps): Bump step-security/harden-runner from 2.22.1 to 2.22.2 (โ€ฆ
    2. ๐Ÿ”— Quarkslab's blog Snapshotting our way to CVE-2026-9539 rss

      Introduction

      In this blogpost we present a LibAFL-Qemu based fuzzer we developed with the goal of targeting (complex) state machines using incremental snapshots. We targeted libslirp's TCP code during development and showcase the fuzzer on CVE-2026-9539 which we missed at that time due to a lack of detection.

      First we will describe CVE-2026-9539, why it went unnoticed for years as well as when we fuzzed the code and what can be done about it. Then we will describe how the fuzzer works and show it running against libslirp to find CVE-2026-9539. The code is available on Quarkslab's github and we tried to isolate the target-specific parts so it is easy to adapt to a different target.

      Description of CVE-2026-9539

      libslirp is ยซa user-mode networking library used by virtual machines, containers or various tools.ยป. Being Qemu's default network stack makes it an interesting target for a VM escape.

      CVE-2026-9539 is described as an ยซheartbleed-likeยป Out-Of-Bound (OOB) Read vulnerability which exposes data from other connections. It was found by Bruce Chen and Shi Weiming from STAR Labs SG Pte. Ltd and was reported to libslirp in May 2026, around the same time we failed to see our fuzzer triggering it because of a lack of detection.
      We won't explain the bug at length here and stick to the important bits as the ticket on libslirp's gitlab is very detailed:

      1. Libslirp allocates two large arrays (128KiB) that it uses to support the socket's send and receive buffers. It uses two pointers to walk these buffers like ring-buffers.
      2. Libslirp was testing the TCP urgent pointer against the size of an intermediate buffer, not against the amount of valid data in the socket.
      3. As it tries to read more data than available, an integer underflow happens leading to even more data being read.
      4. The data is sent with multiple packets and leaks the whole content of the receive buffer, including leftovers from a previous allocation if the memory chunk is a previously freed one that was re-used for this socket. The same 128KiB of data is sent over-and-over.

      As the data is too big to be sent in a single packet and multiple checks try to prevent OOB accesses, the bug stays inside the ring-buffer area and never goes out-of-bound as far as Address Sanitizer (ASAN) is concerned, making this bug seemingly invisible.

      Why CVE-2026-9539 went unnoticed and what can we do about it

      As we said in the previous section, the bug is not a classical OOB read but an OOB read inside a custom allocator, so it will not crash the program and ASAN is blind even if a fuzzer is able to reach it.

      Speaking about fuzzers, libslirp integrates a bunch of them. These are libfuzzer-based and use a custom mutator working with PCAP files. The main issue with the fuzzer targeting the TCP-related code is that it fails to open and connect to sockets. The fuzzers are not using libdesock or preeny and bypassing the socket part by modifying the source code can lead to surprising results and be tricky.

      There are two ways to detect CVE-2026-9539 using sanitizers: the easiest one consists in detecting its side effect, while the other consists in working around ASAN's shortcomings when an internal allocator is used.

      Detecting the side effect

      The integer underflow in the sosendoob function is not the whole story but interestingly it makes the vulnerability easy to detect using ASAN's sibling UndefinedBehaviorSanitizer (UBSAN).

      We recommend reading MaskRay's excellent blogpost All About UndefinedBehaviorSanitizer for a complete tour of UBSAN.

      Contrary to ASAN, UBSAN only exists as an LLVM pass so it is only available when you are able to compile the project from source. Recompiling libslirp with integer overflow detection (-fsanitize=unsigned-integer-overflow,signed- integer-overflow) and reaching sosendoob's underflow, we are rewarded with multiple UBSAN runtime errors (which we can suppress with custom annotation after determining whether this is an expected behavior), including the relevant one:

      ../src/socket.c:394:15: runtime error: unsigned integer overflow: 8 - 2048 cannot be represented in type 'uint32_t' (aka 'unsigned int')
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior ../src/socket.c:394:15

      Customizing ASAN

      Address Sanitizer is using a shadow memory to track allocation sizes and memory accesses. Basically, it handles a big array mimicking the memory of your program filled with values indicating if the program is allowed to read/write the associated byte.
      A byte which should not be accessed is said to be poisoned and ASAN provides functions to (un)poison a memory region.

      You can refer to TrailOfBits' Sanitize your C++ containers: ASan annotations step-by-step blogpost for a tutorial-like introduction to manual poisoning with ASAN.

      Poisoning the whole ring-buffer and manually unpoisoning/poisoning memory when it is ยซallocatedยป/ยซfreedยป by the internal allocator should detect this bug. It requires more work and is prone to errors but it would be more reliable as it does not depend on side effects of the bug.

      LibAFL-Qemu's ASAN implementation also exposes an API to poison/unpoison memory regions, so this can also be achieved when the source code is unavailable.

      Fuzzing against the (state) machines

      Fuzzing a state machine, such as the TCP one, generally requires sending multiple inputs in a given order. There are multiple ways to solve this problem, each having pros and cons. We are only listing some techniques which require low efforts and fuzzers built on modern fuzzers such as AFL++ or LibAFL.

      Persistent mode and persistent record

      The first and easiest option is to run your fuzzer in persistent mode, avoid resetting anything between iterations, opt-in for the low stability and hope AFL++'s persistent record option will catch the right input chain to have a reproducer.

      Splitting the input

      A common technique in order to easily find reproducible issues is to split the fuzzer's input into multiple inputs. This can be done by letting the fuzzer generate a sequence of bytes and then use FuzzedDataProvider, Arbitrary or similar.
      Another way of doing it is by creating a custom mutator which uses a magic value to separate the parts of the input. This is what libslirp's fuzzers do.

      This approach is subject to the havoc effect (a change to an early input part changes the interpretation of the next ones) and the fuzzer could theoretically generate the magic value (choose your separator wisely and avoid compiling the harness with cmplog).

      Multipart inputs

      Multipart inputs is a variation of the previous approach. It is built in LibAFL and removes the need for a custom mutator. It also removes the very unlikely risk that the fuzzer generates the magic value that separates the parts, but the havoc effect is still an issue.

      Working from snapshots

      Instead of working from the initial state and sending multiple inputs to the target, a security analyst tries to reach interesting states manually in order to take a snapshot. This snapshot is then fuzzed in isolation, one input at a time.

      This setup removes most of the issues discussed previously but the ability to reach a complex state might depend on how the current state was reached.

      Fuzzer in the Middle (FitM)

      FitM is a fuzzer designed for client-server targets when both are available. The fuzzer impersonates one end of the protocol until the other end's response changes. When a new response (which is a proxy for the state) is found, the fuzzer takes a snapshot and switches to impersonating the other end of the communication channel.

      It relies on Qemu for emulation and CRIU to take the snapshots. The setup might be a bit tedious.

      Taking snapshots while fuzzing

      The approach we have implemented is inspired by FitM, it is also close to NyxNet with a different backend and design choices, and to FTZ. We built our fuzzer on top of LibAFL-Qemu usermode, its SnapshotModule and SnapshotManager. We could have mostly copy-pasted the SnapshotModule into a MultiSnapshotModule but we chose another route which looked a bit easier back then.
      Using the hook mecanism provided by LibAFL-Qemu, we are detecting changes to the state machine to trigger a new snapshot.
      The SnapshotManager then saves the internal structures of the SnapshotModule and can restore it on demand. This way, we should be able to explore the different states and state transitions of the target.
      Leveraging LibAFL's metadata concept, we are able to track which input generated a snapshot and the full chain of snapshots leading to a given state, allowing to easily try to reproduce any issue.
      On libslirp, we are using a lain-based custom mutator to only generate TCP packets so the fuzzer does not explore code unrelated to the state machine we are targeting.

      Lain is an input mutator/generator which works using annotations on Rust struct. The mutations it performs try to conform with the type and it offers some control over which parts of the struct can be mutated. Nowadays it could be replaced with Autarkie which shares the concept of using annotations on Rust struct but is considered a grammar mutator rather than a structure-aware one.

      Our ยซincremental snapshot fuzzerยป

      LibAFL-Qemu's SnapshotModule

      LibAFL-Qemu's usermode comes with a SnapshotModule which unlocks snapshot fuzzing for linux userland targets. It only snapshots the target's memory, not its registers. Taking a snapshot of the registers should be done manually in the harness.
      In this section, we will briefly describe how it works.

      The snapshot function is in charge of taking the snapshot and does the following:

      • It saves the values of brk (think of it as the limit of the memory region the heap can use) and mmap_start.
      • It walks the whole Qemu memory mapping and saves the bounds and permissions of the mappings.
      • While walking the memory map, it also walks the pages of each mapping, one at a time, and stores the content of the pages along their address and permissions in the SnapshotPageInfo structure.

      In order to track when memory is written, the SnapshotModule sets up ยซwrite hooksยป in Qemu tasked with adding the (now) dirty pages to the SnapshotModule's accesses field. It also registers pre_syscalls and post_syscalls hooks to track some syscalls which affect memory (mmap, munmap, mprotect, brk, read, ...).

      Thanks to these hooks, the reset function can restore the snapshot's state in a more efficient way than just restoring everything the way it was. It works as follows:

      • If the heap has shrunk or grown (the value of brk changed), it reverts it by mapping/unmapping memory.
      • It walks the dirty pages to restore their content.
      • If some mappings were mapped or unmapped, it reverts the changes and restores the content if needed.
      • If a mapping's permission changed, it calls mprotect to revert it.

      The SnapshotManager

      The SnapshotManager is a member of LibAFL-Qemu's Emulator structure. The default SnapshotManager for usermode is the NopSnapshotManager which does nothing as the name suggests. A SnapshotManager must implement the IsSnapshotManager trait, which exposes 3 functions:

      • save: which is responsible for taking snapshots;
      • restore: which is responsible for restoring snapshots;
      • do_check: which is in charge of verifying the snapshot's correctness. We are not using this function in our fuzzer.

      Our implementation's save function is called when a change to the TCP state is detected. To limit the amount of duplicate snapshots, it first performs a hash of the state (augmented with the flags of the answer packets from the stack to have more diversity) to decide if we actually take a snapshot. It then saves most of the SnapshotModule's fields and uses the accesses as a diff between a snapshot and its parent.
      The SnapshotManager keeps a HashMap tracking the chain of snapshots to restore in order to reach another snapshot. This HashMap is filled during the call to save, leveraging the fact that the first step to reach a given snapshot is to reach the new snapshot's parent, as well as the converse (reaching the new snapshots is done by first reaching its parent).
      Last but not least, the SnapshotManager updates its internal state and a module we called ObserverModule, which is used to add snapshot-related metadata to the testcase.

      A decision graph to show the save function's flow which is explained in the previous paragraph
      Save function flow

      The restore function is simpler, it restores the current snapshot before retrieving the path to the target snapshot. It then restores the chain of snapshots by copying the saved SnapshotModule state back into the SnapshotModule and calling the SnapshotModule's reset function.

      A decision graph to show the restore function's flow which is explained in the previous paragraph
      Restore function flow

      Taking snapshots

      As the goal is to explore a state machine, we want to take snapshots when the internal state changes. This part is target specific, some will use a single function that sets the state, others could have a function for each possible state, and some others will just write the state to a memory region. Libslirp falls into the latter category.

      To target libslirp, our fuzzer is using a hook to retrieve the memory region allocated for the tcpcb structure (which contains the t_state field) to track the state of the connection. Then, a write_hooks tracks write- operations in the t_state field, signaling to the harness, through the OberserverModule, that it should ask the SnapshotManager to try taking a new snapshot when execution ends.
      We also used a pre_syscall_hook to hook the socket and fcntl syscalls, and various InstructionHook to bypass some verifications such as the checksum.

      The harness and metadata

      With our design, part of the logic is handled in the harness. LibAFL-Qemu expects the harness to take the fuzzer's state as an argument, so it is possible to retrieve the current testcase and the metadata attached to it. Our implementation heavily relies on this to drive the SnapshotManager and to save to disk all the information we need to reproduce a given testcase.

      When a snapshot is generated, its SnapshotId is added to the new testcase's metadata. When a testcase is used and mutated, the harness retrieves its metadata and restores the snapshot associated to the stored SnapshotId. If no new snapshot is generated but new coverage is found, the restored snapshot is kept as the associated snapshot.
      The bytes that were sent are stored in the metadata under the name gen_bytes, along with the associated SnapshotId. This allows to easily retrieve the full chain of inputs leading to a given testcase (because it is not straightforward to differentiate between a testcase which generated new coverage while on a given snapshot, and the testcase which generated the snapshot).

      A decision graph to show the harness decision making which is explained in the previous paragraph
      Harness decision making

      Drawbacks and limitations

      There are a few drawbacks and limitations coming either from our design or LibAFL itself, that we will discuss a bit more later in the section:

      • QASAN does not work with (multiple) snapshots.
      • This fuzzer was built on LibAFL 0.15.4, which often crashes when the target/Qemu crashes, killing the fuzzer.
      • LibAFL-Qemu does not come with a full-restore mechanism, making it impossible to have two separate trees of snapshots.
      • A new snapshot is associated to the testcase that generated it, providing a low diversity in the subsequent inputs.
      • External tooling is required to reproduce a series of input.
      • The snapshots take a lot of memory so the deduplication criterion is very important.
      • It is not possible to share testcases between fuzzer instances.

      The third limitation comes at the price of having only a single entry in the initial corpus, or taking a snapshot before starting the fuzzing loop and forcing it as the root of all snapshots.

      Optimizing the memory consumption of storing snapshots would require modifications to the SnapshotModule, so we did not do it (yet).
      Sharing testcases does not carry metadata informations and even if it did, the SnashotId would not correlate between instances. It should be possible to work around it using the EventManager but this was not explored (yet) as the benefit might not be worth the time.

      QASAN has an internal shadow memory which would need to be saved and restored by the SnapshotManager. It appears the AsanHostModule provides the snapshot and rollback functions that could be leveraged for this but it is not straightforward.

      As new snapshots are associated to the testcase generating it, the mutation step will generate a variant of this testcase and restore the associated snapshot. So the fuzzer has a high chance to keep generating inputs which resemble the one which generated a given snapshot.
      In the case of a TCP stack, the difference is not huge, especially when we have a mutator which ensures some fields are kept, but targeting a protocol such as TLS would require more diversity. Decoupling the testcase from the snapshot could be the answer in such cases.

      External tooling is required to walk the input list and reconstruct the full chain required to run it. We can turn this limitation into a strength by having a separate tool which monitors new inputs, retrieves the chain leading to it and runs it under ASAN and dumps the coverage.

      Offline reproducer, coverage collection and sanitization

      As stated in the previous section, some instrumentation can interact with the snapshot part of the fuzzer in bad ways, so the easy path is to have external tooling. We chose to use Notify to react to new testcases being written to disk. When a new testcase is found its metadatas are parsed in order to retrieve the associated snapshot, the parent snapshot of the associated snapshot, the gen_bytes and a few other useful information.
      Keeping a HashMap allows to retrieve the full chain of inputs leading to the new testcase, then the only thing left to do is spawn a new process which will set up a fuzzer with both AsanHostModule and DrCovModule to test the input chain against ASAN and collect the coverage in DrCov format, ready to load in bncov. The design of the two modules makes it mandatory to run a full fuzzer and call fuzzer.evaluate_input, rather then just call qemu.run on the instrumented Qemu instance because it does not trigger the pre_exec and post_exec functions.

      Testing the fuzzer

      The fuzzer targeting libslirp is available on Quarkslab's github. The instructions to compile libslirp on the correct commit, along with a patch to build the target binary and suppress false positive integer overflow (seq/ack numbers wrapping), and then run the fuzzer are in the readme.

      The code has been split to highlight libslirp-related and tcp-related code parts. We kept the full naming (e.g. libslirp::utils::setup_target_arguments) to make it easier to locate which parts are the core of the fuzzer and which parts are target-specific.

      &boxvr&boxh&boxh Cargo.lock
&boxvr&boxh&boxh Cargo.toml
&boxur&boxh&boxh src
    &boxvr&boxh&boxh libslirp
    &boxv   &boxvr&boxh&boxh hooks.rs
    &boxv   &boxvr&boxh&boxh misc.rs
    &boxv   &boxvr&boxh&boxh mod.rs
    &boxv   &boxur&boxh&boxh utils.rs
    &boxvr&boxh&boxh network_targets_utils
    &boxv   &boxvr&boxh&boxh inputs.rs
    &boxv   &boxvr&boxh&boxh mod.rs
    &boxv   &boxvr&boxh&boxh mutator.rs
    &boxv   &boxvr&boxh&boxh tcp.rs
    &boxv   &boxur&boxh&boxh utils.rs
    &boxvr&boxh&boxh main.rs
    &boxvr&boxh&boxh feedback.rs
    &boxvr&boxh&boxh observer_module.rs
    &boxvr&boxh&boxh snapshot_manager.rs
    &boxur&boxh&boxh utils.rs

      Our fuzzer against CVE-2026-9539

      The video below shows the fuzzer running against an unpatched libslirp, compiled with UBSAN only looking for signed and unsigned integer overflows and ignoring the overflows on seq/ack numbers. The logs show both the TCP connection state before the next input is sent (call to libslirp::misc::log_target_state at main.rs:244) and the input we are sending.
      In the video it takes seconds for Qemu to crash on a Illegal instruction, this is because UBSAN is in trap mode so it raises an UD instruction upon errors. As stated in the ยซDrawbacks and limitationsยป section, LibAFL-Qemu can have some issues with signal handling on the version we used.

      A gif recording of the fuzzer running against libslirp, finding CVE-2026-9539
      Our fuzzer against CVE-2026-9539

      As Qemu and the fuzzer are crashing on the UD instruction we have no information about what happens, so you should either trust us or try it yourself in minimal runtime mode, stop the fuzzer and scroll-up to find the error and confirm it did hit CVE-2026-9539.

      Acknowledgement

      This project was AI-free.

      I'd like to thank my colleagues, in particular Laurent Laubin, Chris and Celian for their support and inputs on the project.

      I'd also like to thank:

      • Addison Crump, his parking game fuzzer was a great and fun introduction to implementing custom feedbacks and metadatas in LibAFL;
      • Toka for his work on LibAFL-Qemu;
      • Romain Malmain for his work on LibAFL-Qemu and answering my questions when I first started experimenting with LibAFL-Qemu;
      • last but not least, I'd like to thank Samuel Thibault, who is a maintainer of libslirp and supervised my first try at fuzzing on a real target back in 2020.
    3. ๐Ÿ”— @HexRaysSA@infosec.exchange ๐Ÿ“ข IDA 9.5 is here: more platforms, more agentic power. mastodon

      ๐Ÿ“ข IDA 9.5 is here: more platforms, more agentic power.

      โ†’ 3 new decompilers: Android Dalvik, Infineon TriCore and Qualcomm Hexagon
      โ†’ IDA MCP and Assist for AI-driven reverse engineering
      โ†’ Recursive decompilation across call graphs
      โ†’ IDA Home now includes 11 cloud decompilers instead of 2, at the same price
      โ†’ And much, much more

      Itโ€™s one of our biggest releases yet. Active license holders can download it now from the Download Center.

      https://hex-rays.com/blog/ida-9.5-release

    4. ๐Ÿ”— Hex-Rays Blog IDA 9.5 Is Here: More Platforms, More Agentic Power. rss

      IDA 9.5 Release: Three New Decompilers, Malware Analysis add-on, Apple Kernelcaches and More

      IDA 9.5 is here, and itโ€™s one of our biggest releases yet.

      Three new decompilers for Android Dalvik, Infineon TriCore, and Qualcomm Hexagon significantly expand platform coverage, while Apple kernelcache and DriverKit analysis take a major step forward. Support for AVX/SSE, Armv9, MIPS Release 6, WebAssembly 3.0, PowerPC, and ARC gets stronger too.

    5. ๐Ÿ”— r/Harrogate Duck ponds? rss

      Are there any places to see ducks in Harrogate? Thanks!

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

    6. ๐Ÿ”— pydantic/monty v1.4.0 - 2026-10-26 release

      What's Changed

      New Contributors

      Full Changelog : v1.3.0...1.4.0

    7. ๐Ÿ”— roboflow/supervision supervision-0.31.0 release

      v0.31.0 โ€” Depth, moving cameras and pose mAP

      supervision now sees depth: load depth maps from your model or stereo rig, measure how far each object is, and draw the map.

      • sv.DepthMap measures the distance to every detection and colours depth over any image, no OpenCV needed.
      • PolygonZone and LineZone keep counting in the right place while the camera pans.
      • KeyPointMeanAveragePrecision scores pose models the way pycocotools does.
      • Kosmos-2 , Gemini 3.6/3.7 and MediaPipe hands now load straight into Detections and KeyPoints.
      • MeanAveragePrecision runs far faster on crowded images and lets you raise the detection cap.

      It's a drop-in upgrade if 0.30.x showed you no deprecation warnings, apart from four output changes. sv.ByteTrack with the supervision.tracker package, supervision.keypoint, sv.LMM, the legacy sv.MeanAveragePrecision and a few helpers are gone; the Migration guide has the swaps.

      โœจ Spotlights / highlights

      image

      Depth maps: load, measure and draw

      sv.DepthMap holds metric depth, stereo disparity or relative depth for one frame, and keeps track of which one it is. sv.DepthCamera converts disparity to metres, measure_detections writes the median depth under each object to detections.data ("depth_m" when the map can give metres), and sv.DepthAnnotator colours the map over an image without OpenCV. sv.DepthClipRange keeps one colour scale across a whole video, so colours don't flicker between frames. Loaders read Roboflow Inference, Ultralytics, Transformers, and 16-bit PNG and PFM dataset files such as KITTI and Middlebury. (#2691, #2692, #2693, #2694)

      import numpy as np
import supervision as sv

depth = np.full((100, 100), 20.0, dtype=np.float32)
depth[20:40, 20:40] = 4.0
depth_map = sv.DepthMap(depth, kind="depth_m")

detections = sv.Detections(xyxy=np.array([[20, 20, 40, 40], [60, 60, 90, 90]], dtype=float))
detections = depth_map.measure_detections(detections)
detections.data["depth_m"]  # array([ 4., 20.], dtype=float32)

annotated = sv.DepthAnnotator().annotate(np.zeros((100, 100, 3), np.uint8), depth_map)

      people-walking-composed.mp4

      Zones that follow the camera

      Zones used to assume a fixed camera; when it panned, the scene slid out from under the zone. PolygonZone.trigger and LineZone.trigger now take an optional per-frame coord_transform that maps detection anchors back into the frame the zone was drawn on. Any object with abs_to_rel and rel_to_abs works, as described by the new sv.CoordinatesTransformation protocol, including the transformations from the trackers motion estimator. Drawing is unchanged, and coord_transform=None keeps current results. (#2657)

      import numpy as np
import supervision as sv

class CameraShift:
    def abs_to_rel(self, points): return points + [50, 0]
    def rel_to_abs(self, points): return points - [50, 0]

zone = sv.PolygonZone(polygon=np.array([[0, 0], [100, 0], [100, 100], [0, 100]]))
car = sv.Detections(xyxy=np.array([[120.0, 40.0, 140.0, 60.0]]))
zone.trigger(car)                                 # array([False])
zone.trigger(car, coord_transform=CameraShift())  # array([ True])

      COCO keypoint mAP for pose models

      sv.metrics.KeyPointMeanAveragePrecision scores sv.KeyPoints predictions by Object Keypoint Similarity at ten thresholds from 0.50 to 0.95, and its scores agree with pycocotools COCOeval(..., "keypoints"). COCO greedy matching is now vectorized for box and keypoint mAP. In the benchmark reported with that change, one image with 1000 predictions and a 1000-detection cap dropped from 35.9 s to 0.5 s. MeanAveragePrecision also takes max_detection_thresholds for scenes with more than 100 objects. (#2687, #2733, #2716)

      import numpy as np
import supervision as sv
from supervision.metrics import KeyPointMeanAveragePrecision

targets = sv.KeyPoints(
    xy=np.array([[[10, 10], [60, 10], [35, 80]]], dtype=np.float32),
    class_id=np.array([0]),
    data={"area": np.array([4000.0])},
)
predictions = sv.KeyPoints(
    xy=np.array([[[11, 10], [60, 12], [35, 79]]], dtype=np.float32),
    class_id=np.array([0]),
    detection_confidence=np.array([0.9]),
)
metric = KeyPointMeanAveragePrecision(sigmas=[0.25, 0.25, 0.25])
metric.update(predictions, targets).compute().map50  # 1.0

      More models, and the matcher behind the metrics

      sv.Detections.from_vlm parses Kosmos-2 grounding results (sv.VLM.KOSMOS_2) and Gemini 3.6 and 3.7 structured boxes and polygon masks. sv.KeyPoints.from_mediapipe loads MediaPipe hand landmarks, with class_id 0 for a left hand and 1 for a right hand. sv.match_detections exposes the one-to-one greedy IoU matcher the metrics use, for comparing two models or auditing labels against predictions. (#1903, #2504, #2283, #2557)

      import supervision as sv

caption = "a snowman next to a fire"
entities = [("a snowman", (0, 9), [(0.1, 0.2, 0.4, 0.9)]), ("a fire", (19, 25), [(0.5, 0.6, 0.8, 0.95)])]
detections = sv.Detections.from_vlm(sv.VLM.KOSMOS_2, (caption, entities), resolution_wh=(640, 480))

pairs, unmatched_a, unmatched_b = sv.match_detections(detections_a, detections_b)

      ๐Ÿ”„ Migration guide

      No breaking changes beyond the APIs deprecated in 0.26โ€“0.28 and scheduled for removal in 0.31.0. If 0.30.x printed no deprecation warnings for your code, only the four output changes at the end of this section can affect it.

      Removed | Use instead
      ---|---
      sv.ByteTrack and the supervision.tracker package | ByteTrackTracker from the trackers package (pip install trackers); call update() instead of update_with_detections()
      supervision.keypoint | supervision.key_points
      sv.LMM, Detections.from_lmm | sv.VLM, Detections.from_vlm
      legacy sv.MeanAveragePrecision (supervision.metrics.detection) | sv.metrics.MeanAveragePrecision
      sv.denormalize_boxes(normalized_xyxy=...) | sv.denormalize_boxes(xyxy=...)
      supervision.dataset.utils.mask_to_rle / rle_to_mask | sv.mask_to_rle / sv.rle_to_mask
      ensure_cv2_image_for_annotation | ensure_cv2_image_for_class_method (supervision.utils.conversion)
      ensure_pil_image_for_annotation | ensure_pil_image_for_class_method (supervision.utils.conversion)
      ensure_cv2_image_for_processing | ensure_cv2_image_for_standalone_function (supervision.utils.conversion)
      create_tiles, overlay_image (also sv.overlay_image), validate_keypoint_confidence, validate_keypoints_fields | no direct replacement 

      # before
tracker = sv.ByteTrack()
detections = tracker.update_with_detections(detections)
map_result = sv.MeanAveragePrecision.from_detections(predictions=predictions, targets=targets)

# after
from trackers import ByteTrackTracker
from supervision.metrics import MeanAveragePrecision

detections = ByteTrackTracker().update(detections)
map_result = MeanAveragePrecision().update(predictions, targets).compute()

      Four behaviour changes can alter output: sv.Detections raises on non-finite boxes, sv.CSVSink writes arrays as JSON lists, ConfusionMatrix.from_detections rejects lists of different length, and multi-class mAR @ K scores follow COCO. Details under Changed and Fixed.

      ๐Ÿ“ Notable changes

      ๐Ÿš€ Added

      • Depth maps. sv.DepthMap, sv.DepthAnnotator, sv.DepthClipRange and sv.DepthCamera, with to_depth, measure_detections, resize, crop, value_at, DepthAnnotator(scale="metric"), and loaders from_inference, from_ultralytics, from_transformers, from_png16 and from_pfm. (#2691, #2692, #2693, #2694)
      • Camera-motion-aware zones. PolygonZone.trigger and LineZone.trigger accept coord_transform, typed by the new sv.CoordinatesTransformation protocol. (#2657)
      • COCO keypoint mAP. sv.metrics.KeyPointMeanAveragePrecision for sv.KeyPoints, matching pycocotools keypoint evaluation. (#2687)
      • Configurable mAP detection limits. Keyword-only max_detection_thresholds on MeanAveragePrecision; the default (1, 10, 100) is unchanged. (#2716)
      • Mask confusion matrix. sv.ConfusionMatrix.from_detections and benchmark accept metric_target=MetricTarget.MASKS and match by mask IoU, on dense masks or CompactMask. (#2612)
      • Metric result aggregation. MetricResult base class for metric results, plus aggregate_metric_results() and plot_aggregate_metric_results() to compare several results in one table or grouped bar chart. (#2498)
      • Public matcher. sv.match_detections returns one-to-one greedy IoU matches and the unmatched indices on each side, optionally per class. (#2557)
      • Kosmos-2. sv.VLM.KOSMOS_2 in sv.Detections.from_vlm, one detection per grounded region. (#1903)
      • Gemini 3.6 and 3.7. sv.VLM.GOOGLE_GEMINI_3_6 and sv.VLM.GOOGLE_GEMINI_3_7 parse the structured {"boxes": [...]} format, including normalized polygon masks. (#2504)
      • MediaPipe hands. sv.KeyPoints.from_mediapipe loads hand landmarks from the Tasks HandLandmarker and the legacy Hands solution, with a new hand skeleton, class_id 0 for left and 1 for right, and the handedness score in data["handedness_score"]. (#2283)

      ๐ŸŒฑ Changed

      • sv.Detections validates xyxy: non-finite (NaN, inf) or non-numeric boxes now raise ValueError instead of failing later. (#2503)
      • sv.ConfusionMatrix.from_detections raises when predictions and targets differ in length, instead of scoring the shorter list. (#2612)
      • sv.CSVSink writes NumPy arrays in data and custom_data as JSON lists instead of NumPy's truncated str() form; parse array cells with json.loads. (#2707)
      • sv.Detections.with_nmm and sv.mask_non_max_merge merge CompactMask unions without full-image allocations; the error for mismatched image shapes now names both shapes. (#2606, #2616)
      • sv.Detections.from_inference(compact_masks=True) crops each polygon mask to the polygon instead of the whole image, cutting time and memory for many polygons on large images. (#2678)
      • COCO greedy matching in MeanAveragePrecision and KeyPointMeanAveragePrecision is vectorized; results are unchanged. (#2733)
      • sv.ComparisonAnnotator builds its mask union from CompactMask crops in place instead of allocating a full (N, H, W) stack. (#2495)

      โŒ Removed

      • APIs deprecated since 0.26.0โ€“0.28.0 and scheduled for 0.31.0: sv.ByteTrack and the supervision.tracker package (use trackers.ByteTrackTracker), the supervision.keypoint module (use supervision.key_points), sv.LMM and Detections.from_lmm (use sv.VLM and from_vlm), the legacy sv.MeanAveragePrecision (use sv.metrics.MeanAveragePrecision), create_tiles, overlay_image, ensure_cv2_image_for_annotation, ensure_pil_image_for_annotation and ensure_cv2_image_for_processing (use the ensure_*_for_class_method / ensure_cv2_image_for_standalone_function decorators), validate_keypoint_confidence, validate_keypoints_fields, the normalized_xyxy argument of sv.denormalize_boxes (use xyxy), and the supervision.dataset.utils import path for mask_to_rle / rle_to_mask. (#2582)

      ๐Ÿ”ง Fixed

      • sv.Detections.from_ultralytics no longer shifts or truncates segmentation masks when letterbox padding is fractional. (#2739)
      • Indexing sv.Detections with a Python list of booleans now selects list-valued data with the same mask as the arrays; it was read as positions. (#2737)
      • sv.move_boxes and InferenceSlicer no longer wrap integer coordinates when an offset crosses the dtype's range. (#2734)
      • sv.Detections.box_aspect_ratio no longer overflows on integer boxes at large coordinates. (#2729)
      • BlurAnnotator and PixelateAnnotator keep a (H, W, 1) grayscale channel axis instead of failing with a broadcasting error. (#2725)
      • Without OpenCV, thick line, polylines and drawContours outlines match OpenCV's LINE_8 pixels for thickness 2 or more. (#2727)
      • Without OpenCV, fillPoly paints the same boundary pixels as OpenCV, so polygon_to_mask and PolygonZone agree across backends. (#2730)
      • Without OpenCV, resize with INTER_NEAREST samples the same source pixels as OpenCV, which also aligns sv.CompactMask.resize across backends. (#2722)
      • sv.process_video stops reading the source when a callback or frame write fails, instead of decoding the rest of the video before raising. (#2720)
      • Label annotators with smart_position=True separate labels whose boxes share a center; before, only the last label was visible. (#2718)
      • Oriented-box MeanAveragePrecision keeps corner precision at large coordinates and puts objects in the right size bucket. (#2717)
      • sv.KeyPoints keeps all three coordinates when selecting a single key point with a NumPy integer index. (#2715)
      • Integer boxes and oriented boxes no longer land in the wrong object-size category when their area overflows the dtype. (#2713)
      • sv.CompactMask accepts NumPy's copy keyword, so NumPy 2 no longer warns on conversion. (#2708)
      • sv.CompactMask.resize matches dense nearest-neighbour resizing, including crops that become empty. (#2697, #2705)
      • DetectionDataset.as_yolo, as_pascal_voc and as_labelme export a mask with holes as one instance instead of one extra instance per hole; approximate_mask_with_polygons in supervision.dataset.utils gains the opt-in bridge_holes parameter that does this. (#2703)
      • sv.metrics.MeanAverageRecall applies the mAR @ K limit per class per image, as COCO does; multi-class scores were too low. (#2701)
      • sv.metrics.MeanAveragePrecision scores perfect predictions as exactly 1.0 instead of 0.99999988. (#2687)
      • from_vlm with Gemini 2.5 or 3.5 keeps a mask pixel only where the score exceeds 127 of 255; masks grew by half a mask pixel per side. (#2589)
      • from_vlm with Gemini 2.5 or 3.5 keeps masks for the detections that pass classes when a filtered-out item has no mask. (#2504)
      • from_vlm keeps class_id integer-typed when a classes filter removes every detection for PaliGemma, DeepSeek-VL2 and Gemini 2.0. (#2556)
      • from_ultralytics for Detections, KeyPoints and Classifications accepts NumPy-backed results, including Results.numpy(). (#2710)

      ๐Ÿ† Contributors

      • JANG BYUNGKUN (@8rulerstar) โ€” added KeyPointMeanAveragePrecision and fixed perfect-prediction mAP scoring.
      • Caio Viotti (@cfviotti, LinkedIn) โ€” added depth support: DepthMap, DepthAnnotator, DepthClipRange, DepthCamera and model loaders.
      • Kari Pikkarainen (@kari-pikkarainen, LinkedIn) โ€” made zones follow camera motion with coord_transform.
      • Christoph Deil (@cdeil, LinkedIn) โ€” added max_detection_thresholds to MeanAveragePrecision.
      • Raghav Rathi (@raghav-rathi, LinkedIn) โ€” added mask targets to ConfusionMatrix.
      • shao (@shaoming11, LinkedIn) โ€” added metric-result aggregation and sped up ComparisonAnnotator with compact masks.
      • David (@David-rn) โ€” co-authored metric-result aggregation from the original proposal.
      • Jabrail (@jabrailkhalil) โ€” added sv.match_detections.
      • Soumik Rakshit (@soumik12345, LinkedIn) โ€” added Kosmos-2 support in from_vlm.
      • @Xayar145 โ€” added Gemini 3.6 and 3.7 support in from_vlm.
      • @tarunbommawar27 โ€” added MediaPipe hand landmarks to KeyPoints.from_mediapipe.
      • Advait Shukla (@AdvaitS) โ€” made Detections reject non-finite or non-numeric boxes.
      • Avanish Garg (@avanish-garg, LinkedIn) โ€” fixed CSVSink array output, CompactMask.resize and mask holes in dataset export.
      • Iuri de Silvio (@iurisilvio) โ€” sped up Detections.from_inference with compact masks.
      • @trueoneplusone โ€” sped up with_nmm for compact masks.
      • max (@quotentiroler) โ€” vectorized COCO greedy matching in mAP.
      • A Aswanth Raj (@aswanth-07, LinkedIn) โ€” fixed box_aspect_ratio overflow, CompactMask conversion and resize, single-point KeyPoints selection and NumPy-backed Ultralytics results.
      • Mohammad Hijjawi (@MohammadHijjawi97, LinkedIn) โ€” fixed boolean-list Detections indexing and smart_position label overlap.
      • NIKHIL (@Nikhi00718) โ€” fixed Ultralytics letterbox masks, grayscale blur and pixelate, process_video cleanup and box-area overflow in metrics.
      • kevin (@kevin9327) โ€” fixed thick-line drawing without OpenCV and Gemini mask binarization, and typed the test suite.
      • Kaushik Reddy Lingireddy (@Lingikaushikreddy, LinkedIn) โ€” fixed nearest-neighbour resize sampling without OpenCV.
      • peng xiang (@px12811) โ€” fixed fillPoly rasterization without OpenCV.
      • Devulapalli Naga Sri Vaishnavi (@Vaishnavi220506) โ€” fixed integer wrap in box translation and oriented-box mAP precision.
      • Muhammad Talha (@Talhax55z) โ€” fixed per-class MeanAverageRecall scoring.
      • FootysHands (@ayo0la) โ€” converted documentation examples to doctests.
      • Eesha (@eesha5) โ€” fixed imports in docstring examples.
      • Jirka Borovec (@Borda, LinkedIn) โ€” removed deprecated APIs, fixed from_vlm class_id dtype, followed up on with_nmm performance, and maintained docs, CI and release infrastructure.

      Automated contributions:@dependabot, @pre- commit-ci, @Copilot

      Full changelog : 0.30.0...0.31.0

    8. ๐Ÿ”— HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [HashDB](https://github.com/oalabs/hashdb-ida): 1.13.0
    9. ๐Ÿ”— backnotprop/plannotator v0.28.31 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.28.30 | An Artifacts view in the Inbox, comments on part of an image, diagrams in code review, Ask AI keeps its conversation in annotate
      v0.28.29 | Plan review opens on OpenCode 2, a DOMPurify security update, closing a review stops the agent everywhere
      v0.28.27 | Jump to open questions, files side by side or full screen, image zoom in the Inbox, empty To field, text size for plan review and annotate
      v0.28.26 | Action items and reply drafts in the Inbox, one decision button for plan review, Enter to save a comment, a custom code font
      v0.28.25 | Re-ask open questions, delivery ticks on the list, a count of new messages on the tab, right-click a thread, click Inbox to refresh
      v0.28.24 | A new look for the Inbox, Send now, tag agents, comment on an agent's message, much smaller reads for agents, links in HTML pages
      v0.28.23 | Inbox replies reach sessions with background subagents, dictated text no longer goes missing, ๐Ÿ‘ Looks good reaches the agent, notifications that never fail silently
      v0.28.22 | ๐Ÿ‘ Looks good, full view for files, one viewer for a thread's images and files, every session prints its URL, PLANNOTATOR_BROWSER=none opens nothing
      v0.28.21 | Message an agent from the Inbox, video attachments, Open in for attachments, Code / Tests / Generated in code review, writes from other websites refused
      v0.28.20 | Inbox search (โŒ˜K), real folder names for projects, data files open in the code view, word-only replies leave questions open
      v0.28.19 | Ask this session in T3 Code, folder sessions load shared stylesheets and images, the agent note asked once per agent, Copy connect prompt
      v0.28.18 | plannotator inbox connects your agents, agents are told when to use the Inbox, rendered Markdown in code review, Inbox Settings in sections

      What's New in v0.28.31

      An onboarding tour for the Inbox, pinned threads, picture choices in questions, palettes in Inbox Settings, tailnet reviews from the Claude Code plugin tool, and the right gh account for a PR. 39 PRs, four of them from a first-time contributor, @utpalsinghdev.

      Plannotator Inbox

      An onboarding tour

      A first run now opens on a screen explaining that the Inbox works beside the agents you already run, with two choices: take the tour or connect your agents. The tour replays a real thread from building the Inbox (a question with pictures, the reply, the next messages) and writes nothing to your Inbox. Returning users find it in Settings โ†’ General โ†’ Getting started.

      The Inbox first-run screen

      The tour opening: the Inbox works beside your agents

      Pin threads

      Pin a thread from its right-click menu or the pin in its header. Pinned threads sit in the sidebar above Projects with their state, keep their place in the list, and stay pinned when archived.

      Pictures and stakes in questions

      An agent can put a picture on each choice, and a question card shows them as tiles you pick from, with a zoom button. Optional Stakes:, Shows:, Why: and Reversible: lines show under the prompt and the choices. A recommendation that names the start of a choice (Recommended: Unpin it for - Unpin it: โ€ฆ) now marks that choice.

      Skip questions from the open-questions list

      Skipโ€ฆ at the foot of the "N open questions" list lets you tick the questions to skip, or Skip all. Skips wait in your draft until the next Send.

      Palettes in Inbox Settings

      Settings โ†’ General โ†’ Appearance โ†’ Colors picks the palette for the light and the dark half, the same setting plan review's Theme tab uses.

      The palette picker in Inbox Settings

      Step through files on a phone

      Full screen on a phone has a 4/9 โŒ„ pill for every file in the thread, and a sideways swipe steps to the next or previous file.

      Smaller changes

      • The Inbox says which agents your reply wakes. Claude Code, Pi and OpenCode 2 get it as a new turn on their own; agents through MCP see it when they next check. Agents nothing wakes are told to call wait_for_reply. #2168

      • Every wake ends with a line naming the thread id, read_thread and plannotator inbox --help. #2143

      • The Claude Code mod never steers into or aborts another plugin's turn. A reply waiting on such a turn goes in when the session is idle. #2176

      • The Inbox reminder reaches Team/Enterprise Claude Code sessions and comes back after compaction. #2167, closing #2159

      • No more "hook was skipped" notice at every permission prompt on Team/Enterprise accounts. #2160

      • The first-run screen asks for notifications , so the first question can notify. Your own sent reply shows your words and a short list of your answers. #2148

      • A dot on the sidebar toggle when an update is waiting and the sidebar is closed. #2135

      • Cursor gets the agent note as text to paste into its Rules (plannotator inbox --notes cursor). #2153 by @utpalsinghdev, closing #1991

      • Agents are nudged to attach a screenshot for something visual. #2175

      • An image the Inbox cannot load shows as its alt text , not a broken icon. #2177

      An image the Inbox will not load, shown as its alt text

      • Images and code in a choice keep their corners ; only the Recommended tag is a pill. #2179

      • Decision mode is experimental and off by default. It clears what agents ask across threads one decision at a time; turn it on in Settings โ†’ General โ†’ Experimental. #2141, #2154

      Plannotator

      Tailnet reviews from the plugin tool

      The plannotator tool in Claude Code takes a tailscale option, so a review the agent opens can be read on your phone over Tailscale. Ask this session keeps working there for the Tailscale login that owns the machine; anyone else on the tailnet gets the separate Ask AI.

      The gh account that can see the PR

      With two accounts signed in to gh, plannotator review <PR URL> now uses the one that can read the PR, for that review only. Your gh setting is unchanged, and an invalid GH_TOKEN is named.

      A fixed port for live app annotation

      PLANNOTATOR_LIVE_PORT sets the live app proxy's port (or a range), so live annotation works over an SSH port forward.

      Plannotator Graphite

      A new palette with a lighter, near-neutral dark half that stays readable in a bright room. Pick it in Settings โ†’ Theme.

      Smaller changes

      • A broken config.json is no longer overwritten. A settings save refuses, says how to fix the file, and leaves it as it was. #2178
      • Session secrets no longer reach child processes. The Ask this session token and the decision-file paths stay out of git, gh and the agent CLIs a review starts. #2169
      • A new release shows within minutes. Update checks read GitHub's latest-release link, and the review-window toast shows at most once a day. #2133, #2135
      • Cursor review jobs never start another program namedagent. #2173
      • Linux folder watches no longer exhaust inotify on large repositories. #2155 by @utpalsinghdev, #2163, closing #1439
      • Replacing an Ask AI question in Pi no longer stops the running turn. #2126 by @utpalsinghdev, closing #2038
      • Back in a multi-file annotate session keeps your place. #2129, closing #2128
      • The image viewer says how to zoom when the wheel starts scrolling. #2131, closing #2127
      • The diff shows again after switching through an empty diff in code review. #2180
      • Guided Review viewer uploads retry and publish the entry last, so a failed deploy cannot leave exported guides unstyled. #2150
      • Dependency updates , including Mermaid 12.2. #2152

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Claude Code Plugin: The plugin and the plannotator binary update separately, so run the install script above as well. In a terminal:

      claude plugin marketplace update plannotator
claude plugin update plannotator@plannotator

      Then restart Claude Code. Inside Claude Code, run /plugin marketplace update plannotator, then open /plugin โ†’ Installed โ†’ plannotator โ†’ Update now.

      Pi:

      pi update --extensions

      OpenCode: Re-run the install script above. It now also clears the OpenCode 2 plugin cache.

      What's Changed

      • fix: preserve Pi turn when replacing an Ask AI question by @utpalsinghdev in #2126
      • fix: Back in a multi-file annotate session keeps the reader's place by @backnotprop in #2129
      • Image viewer: say how to zoom when the wheel starts scrolling by @backnotprop in #2131
      • Inbox: skip a question from the open-questions list by @backnotprop in #2132
      • Update notices: check GitHub's latest-release link often by @backnotprop in #2133
      • Update notices: toast once a day, dot on the sidebar toggle by @backnotprop in #2135
      • Inbox: skip from the questions list with a select mode by @backnotprop in #2136
      • Add the Plannotator Graphite dark palette by @backnotprop in #2137
      • Inbox: choose light and dark palettes in Settings โ†’ Appearance by @backnotprop in #2138
      • Question cards: match a recommendation to the choice it begins by @backnotprop in #2139
      • Inbox: pin threads to the sidebar by @backnotprop in #2140
      • Inbox: decision mode (experimental, off by default) by @backnotprop in #2141
      • Usage counts for experimental features, phase 1 (nothing is recorded or sent yet) by @backnotprop in #2142
      • Inbox wake: a closing line with the thread id, read_thread and --help by @backnotprop in #2143
      • Question blocks: optional Stakes, Shows, Why, Reversible and picture choices by @backnotprop in #2144
      • fix: support fixed ports for live app proxies by @utpalsinghdev in #2145
      • Inbox first run: notifications ask on the first-run screen; your sent reply in your own words by @backnotprop in #2148
      • guides.show: retry viewer uploads, publish entries last, verify every file by @backnotprop in #2150
      • Live proxy port: tests for PLANNOTATOR_LIVE_PORT, one-line errors for EACCES by @backnotprop in #2151
      • chore(deps): bun minor and patch group by @backnotprop in #2152
      • fix: offer manual Inbox notes for Cursor by @utpalsinghdev in #2153
      • Decision mode: the agent contract lines on the Queue card by @backnotprop in #2154
      • fix: watch directories instead of files on Linux by @utpalsinghdev in #2155
      • Inbox: the onboarding tour by @backnotprop in #2156
      • fix(mod): only take ExitPlanMode PermissionRequest events by @backnotprop in #2160
      • feat: use the gh account that can see the PR by @backnotprop in #2161
      • fix: Linux folder watches keep working past the cap and unreadable folders by @backnotprop in #2163
      • Inbox: step files on a phone with the toolbar pill and a swipe by @backnotprop in #2164
      • Inbox reminder reaches Team/Enterprise sessions and survives compaction by @backnotprop in #2167
      • Inbox: say plainly which agents a reply wakes by @backnotprop in #2168
      • fix: scrubbed env vars no longer reach child processes by @backnotprop in #2169
      • Tailnet reviews from the plugin tool, with Ask this session for the machine's owner by @backnotprop in #2170
      • Code review: Cursor agent jobs never start another program named agent by @backnotprop in #2173
      • Inbox: nudge agents to attach a screenshot for something visual by @backnotprop in #2175
      • Claude Code mod: never steer into or abort another plugin's turn by @backnotprop in #2176
      • Inbox: draw an image the window cannot load as its alt text by @backnotprop in #2177
      • Inbox tour: fix the QA findings; never write over an unreadable config.json or pins.json by @backnotprop in #2178
      • Inbox: keep the pill on the Recommended tag, not on images or code in a choice by @backnotprop in #2179
      • Code review: show the diff after a switch through an empty diff; name a rejected GH_TOKEN by @backnotprop in #2180

      New Contributors

      Community

      Full Changelog : v0.28.30...v0.28.31

    10. ๐Ÿ”— Rust Blog How to fund Rust contributors rss

      TLDR:

      There is always so much to do in the Rust Project! New features to implement, bugs to fix, performance optimizations to make, issues to triageโ€ฆ It takes a lot of work to keep our high bar of quality while also shipping new features and improvements. And the workload keeps increasing with the continuous growth of Rust adoption.

      As is unfortunately common in open source projects, a large fraction of that work is currently done by volunteers. That causes various issues, such as people burning out or complex features taking many years to ship.

      Unsurprisingly, one of the best ways to help improve that is to get more people who work on Rust funded! This year, several funding initiatives started ramping up, and we already experience many positive effects. They helped us improve the maintenance status of critical Rust projects and make significant progress on several long-awaited features, such as allocators, the never type, the next trait solver or the Polonius borrow checker. However, only a fraction of people working on Rust are currently funded for their work.

      We know that there are Rust users, both individuals and companies, who would like to help improve Rust by funding it, but it might not always be obvious how exactly to do that. This post thus provides suggestions on how you can support the development of Rust in three ways.

      If you're unsure which option fits, or would like to discuss funding on behalf of your company, please contact the Funding team.

      Fund general maintenance

      Maintenance is a continuous process required to keep Rust (or any software project for that matter) working. It consists of two main activities. The first is general housekeeping, such as ensuring that Continuous Integration works, dependencies are kept up-to-date and issues, bugs and security incidents are promptly triaged and resolved. The second is performing refactorings and code reviews, which ensures that the codebase will be able to evolve and continuously ship new features, without accruing extensive technical debt.

      Having quality maintenance is crucial for the long-term health of Rust, yet it is typically very difficult to find funding for it; funders often want to sponsor specific new features, rather than just "keeping the lights on". However, without sufficient maintenance, it becomes much more difficult, and much slower, to ship new features. Improving the maintenance of Rust thus also helps us ship features and improvements faster, though the effects are sometimes only observable over longer periods of time.

      Funding maintenance is a great choice if you want to let us decide how best to improve Rust. The Rust Funding team continuously looks for Rust teams and projects that require help with their maintenance efforts, and allocates available funds to Rust maintainers who could help improve the situation.

      To fund Rust maintainers, consider donating to theRust Foundation Maintainers Fund or sponsoring the RustNL Maintainers Team.

      Fund specific features and improvements

      There are always many Rust improvements and new features that are in progress. We track some of those initiatives through Rust Project Goals. Each Goal describes a specific improvement to Rust: what it is, who is going to develop and drive it forward and which Rust teams are willing to help reviewing and maintaining it.

      Some of those Goals are looking for funding. Either to help their owner dedicate time and focus to push the given feature forward, or to fund maintainers who will perform refactorings necessary to unblock that feature and review its implementation. Often funding is required for both. When a Goal is properly funded, the probability that it will achieve its milestones is much higher, which then translates in the given improvement being shipped sooner to Rust users.

      Funding Project Goals is a great choice if you want to help push forward specific Rust features or Rust toolchain improvements that will benefit you or your company.

      To fund contributors working on Project Goals, consider taking a look atGoals that need funding and reaching out to their funding contact. If in doubt how to proceed, reach out to the Rust Funding team.

      Fund individual contributors

      There are hundreds of people in the Rust Project who continuously work on improving Rust. Some of them have personal fundraising profiles (e.g. on GitHub Sponsors), which allows you to support them directly.

      There might be various reasons for supporting a specific person. Maybe they are maintaining a crate that you love to use, maybe you like reading their blog posts, or maybe you are simply a fan of the work that they do. Whatever the reason, we are sure that they would appreciate your support!

      Funding individual contributors is a great choice if you want to directly support Rust contributors whose work you appreciate.

      To fund individual Rust contributors, check out their GitHub profile or personal website to see what options there are for supporting them. You can also examine our list of Rust Project members who can be supported through GitHub Sponsors[1].

      Conclusion

      We hope that this post is useful to anyone who would potentially like to invest funds into making Rust better. You can also find a shortened version of the "how to fund Rust guide" at the Funding page of the Rust website, or check out a RustConf 2026 talk by Niko Matsakis about how Project Goals and their funding works.

      If you are a company looking to fund the development of Rust, consider joining the Rust Commercial Network. Joining the network is free, and Rust Foundation membership is not required. It can help you find opportunities for funding improvements in specific areas related to Rust usage (e.g. user interfaces, language interop, supply chain security, etc.) and collaborate on funding Rust development with other companies.

      There are of course other ways of helping Rust other than donating funds. For example, you can check out Project Goals that are looking for contributors or more generally check our contributor onboarding guide. Companies can also help by giving employees paid time to contribute upstream, or by hiring Rust contributors to do that work. One possible model is the Engineer in Residence role, that was recently established in the Rust Foundation.

      1. Note that this list is not exhaustive; there are some Project members who accept donations through GitHub Sponsors (or another fundraising platform), but did not opt into being listed on this page. โ†ฉ
    11. ๐Ÿ”— seanmonstar Micro: Make smaller structs rss

      Iโ€™ve seen the hype about view types being added to Rust. I worry it exceeds the strangeness budget. And thereโ€™s a solution already available. Make your structs smaller.

      Iโ€™ve always insisted on optimizing for reading. And as many use LLMs make writing faster, thereโ€™s even less reason to pick shorter but more complex.

      Structs are free. They donโ€™t result in auto boxing. So, divide up your structs by how the fields relate to each other. Then itโ€™s much easier to borrow one field than to wish for some complex syntax to borrow many.

      I have even created temporary projection structs to borrow disjoint fields together, though itโ€™s a pretty rare thing to need.

      I wrote a clippy lint to catch structs that are too big, but seems others think itโ€™s too strict. I still think itโ€™s a good idea.

      Reply via: Email ยท Bluesky ยท Mastodon

    12. ๐Ÿ”— New Music Releases Philip Glass - Classical Workday Focus rss

      Philip Glass - a new release is available:

      • 2026-10-26: Classical Workday Focus (Compilation)

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

      Visit muspy for more information.

generated: October 29, 2026 at 22:05:25