1. August 30, 2026
   1. 🔗 gildas-lormeau/single-file-cli v2.6.1 release

      SingleFile CLI 2.6.1

      CLI fixes and improvements

      • The resources fetched outside the browser present the same user agent as the browser. They used to be requested under the user agent of the runtime, so a capture reached a server under two identities unless --user-agent was set.

      Core fixes and improvements

      • The bootstrap page of a password-protected archive no longer carries the URL of the page. The comment inserted by SingleFile and the canonical link both wrote it in the clear, next to the title that was already withheld.

      Co-authored by Claude (Claude Code)

   2. 🔗 PrimeIntellect-ai/prime-agent Beta (v0.8.1-beta.580.1.a903d4b) release

      Automated beta build from main (a903d4b6768f484bd6d459b7b0aa7dee38e461e2).

2. August 29, 2026
   1. 🔗 gildas-lormeau/single-file-cli v2.6.0 release

      SingleFile CLI 2.6.0

      New features

      • Add --disable-compression, storing the files of an archive without compressing them.
      • --include-BOM now works on plain HTML captures, which never had an implementation of it.
      • --embedded-image and --embedded-pdf now work with --crawl-save-archive. The PNG or the PDF you provide becomes the one the whole archive can be read as, instead of being ignored.

      CLI fixes and improvements

      • --http-header no longer makes the page send a CORS preflight for every cross-origin resource. A header that is not CORS-safelisted is injected below the CORS decision instead of on the network layer, so the servers that answer no preflight keep serving the resource.
      • --blocked-URL-pattern blocks a request before it is sent. It used to be applied once the response had come back, so a blocked URL was still contacted, and whether it was depended on which other options were in use.
      • The network options are applied to service workers. A page whose subresources are served by its own worker was captured without the extra headers, the blocked URL patterns and the proxy authentication.
      • --create-browser-profile drops the browser caches from the profile it creates. They are never copied to the capture profile, and they were the bulk of the directory.
      • Every option is named in lowercase in the sources. The parser has always compared option names case-insensitively, so the names accepted on the command line are unchanged.

      Core fixes and improvements

      • A video poster is stored in a lossy format instead of PNG, which costs an order of magnitude less for the same frame.
      • A media element left without any source no longer carries autoplay.
      • A font named by a shorthand the parser cannot read is kept instead of dropped.
      • Self-extracting archives gained a CDATA rung in the wrapper ladder, which widens the set of pages they can hide their payload in.

      Co-authored by Claude (Claude Code)

   2. 🔗 championswimmer/pi-context-prune v1.4.0 release

      Release 1.4.0

   3. 🔗 blacktop/ida-mcp-rs v9.4.3 release

      What's Changed

      • feat: add headless workspaces, typed raw opens, and debugger workflows by @blacktop in #56

      Full Changelog : v9.4.2...v9.4.3

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

      What's Changed

      Hunk 0.19.2 backports an important session reload security fix to the 0.19 release line.

      Highlights

      • Reject option-like Git ranges and refs in session reloads, preventing local session broker callers from injecting Git flags such as --output=<path> and writing diff output to arbitrary paths, by @benvinegar in #894.

      Full Changelog : v0.19.1...v0.19.2

   5. 🔗 Confessions of a Code Addict Demand Paging in Action: mmap, Page Faults, and RSS rss

      In the previous video in our virtual memory series, we discussed demand paging. But that was mostly theoretical, explaining how demand paging works inside the Linux kernel and the mechanisms through which it handles page faults. In this follow-up video, we make it more concrete by learning to inspect the virtual memory of a running process to see demand paging in action.

      If you watch this video, you will learn a few cool things:

      • What is demand paging (the compressed version; watch the previous video for a more in-depth explanation)

      • What is the /proc file system in the Linux kernel

      • How to read /proc/<pid>/maps to inspect the VMAs of a live process

      • How to read /proc/<pid>/smaps to inspect which VMA is consuming how much physical memory

      • How to use mmap

      • How to use getrusage to track the number of page faults of a process

      If you are new to this series, it is based on my ebook called "Virtual Memory from First Principles". It is available to read for free online and also available to purchase from Gumroad (PDF/Epub) and Amazon (Kindle edition).

      Buy PDF/Epub

      Get Kindle Edition

      ---

      And, if you want to watch the previous videos in this series, the following is what has been published so far:

      • What is virtual memory and why do we need it

      • Size of the virtual address space of a process

      • Address space of a process

      • Structure of page tables and how page table walks work

      • What is inside a page table entry

      • Size of a physical address

      • Demand paging

      Share

      Read more

   6. 🔗 gildas-lormeau/single-file-cli v2.5.0 release

      New features

      • Added --declare-appended-data to declare the data appended after the compressed data as the comment of the ZIP archive, so that readers rejecting undeclared trailing bytes (e.g. java.util.zip) accept the saved file. ZIP tools then print that data when listing the archive
      • Added --crawl-save-archive-page-list to insert the list of the crawled pages in the prelude of the archive saved with --crawl-save-archive, so that indexing tools can read it without extracting the archive. The list is no longer inserted by default

      Fixes

      • Fixes from single-file-core 1.5.108 and 1.5.109, including: the page title, the text body and the resource URLs are now kept out of a password-protected archive, where they were readable outside the encrypted data; the %PDF- header is kept within the range PDF readers scan whatever the length of the page doctype; the extraction of the data from the page is more robust

      Co-authored by Claude (Claude Code)

   7. 🔗 r/LocalLLaMA Tencent compressed Hy4-preview from 1.5TB to about 200GB GGUF and kept about 98% performance. rss

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

   8. 🔗 modem-dev/hunk v0.20.1 release

      What's Changed

      Hunk 0.20.1 is a security and reliability patch for session reloads, syntax highlighting, and theme previews.

      Highlights

      • Reject option-like Git ranges and refs in session reloads, preventing broker callers from injecting Git flags and writing diff output to arbitrary paths, by @benvinegar in #894.
      • Prevent syntax-highlight cache identity collisions from displaying stale code after a review reload, by @benvinegar in #889.
      • Keep the theme selector responsive and its highlighted row visible during rapid keyboard navigation, by @benvinegar in #893.

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

   9. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 releases rss

      sync repo: +2 releases
      
      ## New releases
      - [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.9.1, 0.9.0
      

   10. 🔗 Stephen Diehl The Internet Is Kind of a Predatory Cesspit Now rss

       The Internet Is Kind of a Predatory Cesspit Now

       I’m a kid of the 90s, and I still remember the early internet. It was slow, ugly, unreliable, and full of cranks, a strange world of wheezing dial-up modems, Usenet flamewars, <marquee> tags, and dancing babies. It was also stubbornly alive and human. People built websites about Babylon 5, model rockets, train timetables, shareware, and whatever else had colonised their minds. Most of it had no business model. That was the literal point. The web felt like a public square assembled by obsessive amateurs.

       None of this was entirely innocent. There were scams, viruses, Nazis, pornography, and chain emails from deposed Nigerian princes. But then predation moved from the periphery to the centre. It used to be an abuse of the network. Now it is the network’s organising principle. The scammer once had to find a victim. The platform now finds one, profiles the weakness, optimises the pitch, processes the payment, and recommends the next scam. What was once an aberration has become the norm.

       The modern internet is now a highly optimised machine for detecting human vulnerability, amplifying it, and placing a payment link beside it. Any insecurity can become a commercial niche, including the desire to escape commercial life itself. There is always a course, a newsletter, a private community, or a referral code waiting at the end of the funnel.

       The bleak part is not that grifters exist. Every society has hucksters. It is that much of the population has been conscripted into the downline. Ordinary people now spend their lives promoting investments they barely understand, products that do not work, and political claims they have never examined. Many earn nothing. They are unpaid distributors for someone farther up the pyramid. The consumer, salesman, and product have collapsed into the same exhausted person.

       People increasingly behave like addicts because addiction is the business model. The feed supplies alternating doses of outrage, fear, envy, lust, and hope. Each feeling arrives with something to buy. People doomscroll until they acquire the anxiety that the next influencer will monetise. Then they purchase a bet, a coin, a supplement, a course, or an enemy. Finally, they repost the pitch. Consumption becomes distribution. The mark becomes the salesman.

       This is an industrial system for manufacturing weakness at scale. A legitimate business can survive a satisfied customer. A grift cannot. It needs the customer frightened, aggrieved, lonely, sick, or greedy forever.

       When I started writing about cryptocurrency in 2020, I still carried a naive assumption about the size of this economy. I thought people were generally decent and the grifter class was a small pool of degenerates with rotten moral character, preying on those made vulnerable by the material conditions of our time.

       I was very wrong. The grift economy is massive. More disturbing still, it is participatory. A large and growing share of the population now appears willing to devote every waking hour to fleecing their fellow man as a career choice. They stream, post, recruit, promote, refer, astroturf, and close. They turn every friendship into a lead and every conversation into a qualifying call. They do not clock out because the market follows them into bed. The smartphone is a shop counter that sleeps beside their head.

       Obviously most of these people are not succeeding. The maths simply can never work out. That is part of the trick. The aspiring influencer with forty-seven followers is not an entrepreneur in any meaningful sense. He is free labour for the platform and cheap distribution for the person selling him the dream. The affiliate marketer buys a course about affiliate marketing, then recovers the cost by selling the same course to the next affiliate marketer. The life coach coaches new life coaches. The dropshipper sells tutorials to failed dropshippers. The pyramid is social before it is financial. Everyone stands on someone else while insisting they are about to escape.

       This arrangement blurs the useful moral distinction between predator and prey. Many online grifters are themselves marks. They believe the rubbish they sell because belief makes the selling bearable. They have sunk money, time, identity, and public dignity into the scheme. Admitting the product is worthless would mean admitting that years of their life were worthless too. It is psychologically cheaper to recruit another victim. The fraud sustains the faith, and the faith sustains the fraud.

       A normal trade ends when a need is satiated. You need a chair. Someone sells you a chair. You sit down and stop thinking about chairs. However, an online grift can never satiate. It must preserve the need that feeds it. The grievance merchant cannot resolve your grievance. The wellness influencer cannot let you feel well. The trading guru cannot let you become financially secure. The manosphere podcaster cannot let young men become calm, loved, and socially competent. Satisfaction is churn. Misery is recurring revenue.

       The platforms did not invent fear, greed, loneliness, or status anxiety. They industrialised their extraction. Their recommendation systems are vast reinforcement-learning loops that continuously experiment on human weakness. Each objective is a moving composite of high-dimensional signals for attention, retention, and conversion, dispersed across models, metrics, tests, and feedback systems. The subject cannot see the experiment. The operator cannot fully explain it. The regulator can barely comprehend it. The loop knows only that one stimulus keeps a person scrolling while another lets them leave. Calm accuracy loses. Threat, transgression, humiliation, and impossible promises win. The resulting social damage appears nowhere in the objective function. It arrives as an externality.

       This creates a brutal selection environment. The honest financial adviser explains diversification and gets twelve views. The crypto lunatic predicts a thousandfold return and gets twelve million. The physician says a chronic condition requires careful management. The wellness crank says seed oils are poisoning your soul. The historian describes an ambiguous event with contingent causes. The political influencer identifies a secret cabal and gives you the address of a pizza parlour. One of these people has the better business model. It is not the one burdened by reality.

       The system is dopaminergic in the most banal and mechanical sense. It runs on anticipation, uncertainty, and variable reward. The next refresh might bring approval, outrage, profit, or vindication. Usually it brings nothing, which makes the next refresh more urgent. Social media fused the Skinner box with the commission structure. The addict is handed a referral code and told he is now a small business owner.

       Crypto has become the subject of my verbal ire so often because it is the apotheosis of the grift economy. It takes alienation, precarity, gambling addiction, technological mystification, and a thick slurry of libertarian derp, then synthesises them into the ultimate predatory investment product.

       Crypto also perfected the recursive structure of the modern online grift. Promotion creates price movement. Price movement is presented as proof of adoption. That proof recruits new buyers. Their money creates more price movement. Every participant has a direct financial incentive to become a publicist for his own position. The asset comes with its own volunteer propaganda network. It is a pyramid scheme with a podcast department.

       Much to my dismay, the rest of the internet has learned the same lesson. The cheapest product is empty promises untethered to reality. The most scalable labour force is the addict. The best marketing conceals itself inside identity. Sell people a worldview, and they will advertise it for free because criticism of the product now feels like criticism of the self.

       Language models will make this cheaper and worse. The cost of producing plausible lies has been driven to precisely zero. One person can generate a landfill of articles, videos, testimonials, investment analysis, and synthetic experts before breakfast. The grift no longer needs conviction, charisma, or even a pulse. It needs a language model, an affiliate account, and access to a population whose critical faculties have been sandblasted by twenty years of algorithmic media.

       There is a temptation to regard the people caught in this machine with simple contempt. Some deserve it. A person who knowingly ruins strangers for commission has made a moral choice. But contempt is not an analysis. Precarity supplies the recruits. Alienation supplies the audience. The collapse of stable work, affordable housing, local institutions, and plausible routes to material security is what makes the pitch of the grift economy so seductive. The grift offers agency where ordinary life offers delay. It offers community where society offers isolation. It offers a jackpot where work offers a performance review and another year of rent increases.

       Then it metabolises those injuries into new injuries. The lonely man buys a doctrine that makes him intolerable to women. The indebted worker gambles his remaining savings on a crypto token. The frightened patient abandons medicine for supplements. The politically powerless person spends fourteen hours a day screaming at strangers while the people with power quietly cut his wages and public services. The promised escape reproduces the condition that made escape desirable.

       It is a desperately sad way to live. There is no craft in it, no solidarity, and no completion. No compassion or joy. Every relationship becomes an audience. Every interest just becomes grist for the content mill. Every conviction becomes a content strategy. The grifter can never rest because absence kills engagement. The mark can never rest because the next post might contain the secret. Both wake to the same notifications, trapped on a dopamine treadmill driven by opaque algorithms that can never slow down.

       The worst advice from the 90s, “just say no,” starts to look less stupid when our greatest technical innovation learns to turn distress into inventory. Disconnection is not Luddism in that environment. It is the refusal to mistake a predatory system for a social world.

       Complete disconnection is nearly impossible. Modern life no longer permits it. But an appliance is used for a bounded purpose and then put away. Emails, train times, articles, and files all have endpoints. Infinite feeds of drivel do not. They carry the casino into bed and let an opaque RL loop select the emotions that arrive before breakfast.

       The internet is indisputably an inhuman place. Not because it contains no humans. Billions of us are in here, screaming frantically at each other while feeling utterly alone. It is inhuman because the systems governing it are utterly alien algorithms that cannot recognise human ends. They recognise engagement, conversion, retention, and growth. Grief is a market segment. Loneliness is a targeting signal. Friendship is a retention mechanism. Political conviction is ad inventory. Nothing can simply matter. It must perform.

       Life inside this environment means adopting its categories. Thoughts are assessed by their reach, experiences by their shareability, and people by their usefulness to an identity. A person becomes legible to the machine by becoming less legible to himself. Eventually the system no longer needs to impose its values. Its subjects carry them in their pockets and enforce them on their own minds.

       The physical world is not pure. It contains salesmen, casinos, demagogues, fanatics, and bores. It also contains stubborn limits. A conversation ends. A pub closes. A book runs out of pages. Your friend gets tired of hearing you talk and tells you to shut up. Reality supplies friction, and friction is one of the few remaining defences against appetite without limit.

       We are not going back to the early internet. Nor should we romanticise it. The old web had plenty of sewage. What it also had was space beyond the market. A person could make something without becoming a brand. A conversation could end without a conversion. A community could exist without turning its members into marks for an investment scheme.

       The question is not whether the internet contains useful things. It does. The question is whether human existence should be organised around alien and inhuman objective functions no human chose and nobody can inspect or understand. An RL loop can optimise engagement, retention, and conversion. It cannot tell us what a human life is for. The final grift is letting the loop decide what your life should be.

   11. 🔗 gildas-lormeau/single-file-cli v2.4.1 release

       Fixes

       • Fixed self-extracting pages saved with --embed-pdf failing to open, displaying the error "Cannot extract the data of the page"
       • Fixed self-extracting pages served with an HTTP error status staying stuck on the "Please wait..." message instead of displaying the page
       • Fixed a size miscalculation which could leave the end of central directory record of a self-extracting page outside the range ZIP readers scan to find it
       • Updated zip.js to 2.8.61

       Co-authored by Claude (Claude Code)

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

      IDA Plugin Updates on 2026-08-28

      New Releases:

      • ida-bochs-binaries v1.0.3

      Activity:

      • augur
        • 20836a8c: ci: bump taiki-e/install-action in the actions-dependencies group
      • capa
        • 497120ff: Merge pull request #3166 from mandiant/update-idalib-gha
        • bc008353: ci: update idalib-tests job to use HCLI best practices
      • ghidra
        • 9f377f1c: Merge remote-tracking branch 'origin/patch'
        • cdf95422: GP-7171: Upgrading commons-collections4 to 4.6.0
        • 2a6e9bac: GP-7172: Pass - to native swift demangler to indicate end of flags
        • 483d64b0: Merge remote-tracking branch 'origin/GP-7169_ryanmkurtz_headless-SQU…
        • 7a969f94: GP-7169: Headless fix
        • b09f13d6: Merge remote-tracking branch 'origin/patch'
        • 594da048: GP-7190: Decrementing lock count when exception occurs in
      • haruspex
        • f2f4bc54: Merge pull request #10 from 0xdea/dependabot/github_actions/actions-d…
        • 59581e8d: ci: bump taiki-e/install-action in the actions-dependencies group
      • ida-bochs-binaries
        • 418a1717: v1.0.3
        • 7b23af12: Fix IDABXPATHMAP for PE32+ targets (#11)
      • ida-domain
        • 1d9041ee: Add analysis API (#114)
        • 70dad136: Fix examples embedded in docs #115
      • ida-llm-explainer
        • ca80c1ee: IDA 9.3 compatibility fixes (field-tested) + README changelog
      • ida-nexus
        • 97a7acd5: Delete useless CLI test
        • dd2c86d0: Add reusable and unattended MCP server API
      • ida-pro-mcp
        • 3c97954d: Merge pull request #516 from devnoname120/feat/forward-idalib-max-wor…
        • 8ea8bc5c: Forward IDA MCP environment variables in plugin
      • idawilli
        • 438d7aee: ida gha: fixes
      • rhabdomancer
        • 0ecc1ff0: Merge pull request #9 from 0xdea/dependabot/github_actions/actions-de…
        • 328fca93: ci: bump taiki-e/install-action in the actions-dependencies group
   2. 🔗 earendil-works/pi v0.84.4 release

      New Features

      • Terminal capability overrides — Override detected terminal hyperlink, image, and truecolor support. See Capability Overrides.
      • Extension UI prompt events — Integrations can distinguish active agent work from time spent waiting for ctx.ui prompts. See Extension UI prompt events.
      • RPC queue clearing — Retrieve and clear queued steering and follow-up messages with clear_queue. See RPC clear_queue.
      • Fullscreen selection copy controls — Disable automatic selection copying in fullscreen mode and use Ctrl+X to copy the active selection. See UI & Display.
      • DeepSeek V4 Flash Vision (experimental) — Use the vision-capable model through the built-in DeepSeek provider. See API Keys.

      Added

      • Added ui_prompt_start and ui_prompt_end extension events so host integrations can distinguish active agent work from waiting on user-facing ctx.ui prompts (#8355 by @cristinaponcela).
      • Added detectSupportedImageMimeTypeFromFile() to the public library exports (#8600 by @xl0).
      • Added inherited experimental vision-capable deepseek-v4-flash-vision-exp model support.
      • Added transcript usage notices for compaction and branch summaries when cache miss notices are enabled.
      • Added RPC clear_queue to retrieve and remove queued steering and follow-up messages (#8432).
      • Added environment variables and advanced settings for overriding auto-detected terminal hyperlink, image, and truecolor capabilities (#8665).
      • Added fullscreenCopyOnSelect to disable automatic fullscreen selection copy; when disabled, Ctrl+X copies the active text selection before falling back to the last assistant message, while /tree still copies the selected message (#7720).

      Fixed

      • Fixed toggling thinking visibility clearing partial output from running Bash tools (#8611).
      • Fixed Windows shell aborts crashing Pi when taskkill.exe is unavailable on PATH (#6596).
      • Fixed resumed sessions corrupting the next appended entry when their JSONL file lacks a trailing newline (#8345).
      • Fixed extension messages sent with triggerTurn: false while the agent is running being inserted between a tool call and its result, which made providers that validate message order reject the replayed history. They are now appended once the turn's tool results are in (#8537).
      • Fixed compaction and branch summaries forcing toolChoice: "none" (#8649, #8638).
      • Fixed large tool results crossing the auto-compaction threshold being sent to the provider before compaction. Pi now compacts between tool execution and the next assistant response in the same run, and restores interactive progress when that run resumes (#6879).
      • Fixed Google Vertex requests failing with HttpsProxyAgent is not a constructor when the bundled Node.js runtime uses an HTTP(S) proxy (#8610).
      • Fixed saving a default model from a non-empty model scope so it remains available in that scope.
      • Fixed inherited @ file autocomplete ranking to prefer direct and shallower matches over similarly ranked nested paths (#8669).
      • Fixed inherited OpenAI-compatible streams serializing thinking signatures repeatedly during streaming (#8671).
      • Fixed inherited main-screen rendering crashing when image-heavy output exceeded V8's string length limit (#8028).
      • Fixed inherited fullscreen double-click word selection splitting paths and kebab-case tokens on / and - (#8676).
      • Fixed inherited Cloudflare AI Gateway catalogs omitting supported workers-ai/* passthrough models.
      • Fixed inherited OpenAI-compatible reasoning replay to merge consecutive streamed text and summary reasoning_details deltas.
      • Fixed inherited OpenRouter reasoning controls so reasoning-mandatory models do not receive effort: "none" (#8614 by @davidbrai).
      • Fixed inherited OpenAI-compatible Chat Completions ignoring an explicitly requested toolChoice when no tools are defined.
      • Fixed inherited fragmented Mistral tool calls splitting when continuation chunks omit the tool-call ID (#8387).
   3. 🔗 BarutSRB/OmniWM OmniWM v0.6.4 release

      What's New Since 0.6.3

      0.6.4 turns the single scratchpad into ten multi-window scratchpad slots, adds automatic settings migration so upgrades no longer reset your configuration, exposes diagnostics capture through omniwmctl, and lets the Workspace Bar step aside per display during native fullscreen. It also retires stale tiles for apps that close windows without destroying them, and introduces OmniWM's compass-mark identity, its website, and a documentation hub.

      Before You Upgrade — Breaking Changes

      • Your 0.6.3 settings migrate automatically. No reset, no manual edit. On first launch OmniWM copies the exact original file to settings.toml.pre-v1 (or .pre-v1.1) and rewrites the live file with schemaVersion = 1. The migration preserves configured values, safely matchable unknown keys, symlink targets, and permissions. It also fills in the keys 0.6.4 requires — workspaceBar.hideInNativeFullscreen = false and an empty [scratchpads.labels] — and maps your old scratchpad hotkeys onto slot 1. The canonical rewrite can reorder the document and strip comments; the .pre-v1 backup retains the original text verbatim. Automatic migration is guaranteed for settings emitted by OmniWM 0.6.1 through 0.6.3, so a normal 0.6.3 upgrade needs no config work. Diagnostics reports every automatic change and the backup location.

      • Rolling back to 0.6.3 resets your settings. Keep the.pre-v1 backup. A settings file written by 0.6.4 contains hotkey action IDs that 0.6.3 cannot resolve. 0.6.3 treats the whole file as invalid, preserves it as settings.toml.corrupt, and starts from full defaults. Migration is forward-only: to downgrade, quit OmniWM and restore settings.toml.pre-v1 over settings.toml before launching 0.6.3.

      • Two hotkey action IDs were renamed and eighteen were added. assignFocusedWindowToScratchpad became assignFocusedWindowToScratchpad.1 and toggleScratchpadWindow became toggleScratchpad.1; slots 2 through 10 add the remaining pairs, all Unassigned. Migration rewrites the two old IDs in place, so your existing triggers survive and Settings > Hotkeys keeps working. This matters if you keep settings.toml in a dotfiles repo, generate it from a template, or hand-merge it across machines — the old IDs are no longer valid action IDs, and an unknown ID invalidates the file. In Settings the rows now read Assign Focused Window to Scratchpad N and Toggle Scratchpad N. No other action ID, default binding, config path, runtime-state path, IPC socket path, or CLI command path changed, and OmniWM still requires macOS 26+ on Apple Silicon.

      • IPC protocol goes from 11 to 13. Upgrade the bundledomniwmctl with the app. A 0.6.3 client speaks 11 and will be rejected. Protocol 13 covers two bumps:

        • Capture requests and results, the captureActions capability list, and a new capture_state_conflict error code. Clients that switch exhaustively over IPCErrorCode must handle it.
        • Scratchpad slot indexing. command scratchpad assign and command scratchpad toggle now require a scratchpadIndex argument (<1-10> in the CLI); the old no-argument form is an error.

        • Window and Workspace Bar payloads changed shape.

        • query windows gains a nullable JSON scratchpadIndex field and a scratchpad-index field selector. Full table, text, and TSV output keep the existing SCRATCHPAD column in place, but assigned windows now show their slot number instead of true, so parsers must update value handling rather than column positions.

        • The --scratchpad selector changed meaning. It used to match the scratchpad window; it now matches every window assigned to any of the ten slots, so scripts that assumed a single result can now receive many.
        • IPCWorkspaceBarMonitor.scratchpad — previously a nullable object holding one window — is replaced by scratchpads, an always-present array. Each entry carries index, an optional label, windows, and isVisible. An empty array replaces what used to be null.
        • focus previous is advertised differently. It was published as Niri-only while command enforcement had always treated it as shared, so it already ran fine on Dwindle. The manifest now matches reality. query capabilities, query commands, and generated shell completions all report shared — regenerate cached capability output and completion scripts.

      • The IPC/CLI and architecture references moved out of the repository. docs/IPC-CLI.md and docs/ARCHITECTURE.md are now short stubs pointing at omniwm.app/reference/cli/overview and the architecture guide. The full text is maintained under website/src/content/docs/. Bookmarks and links to the old in-repo files still resolve, but no longer contain the reference itself.

      Headline Feature — Ten Multi-Window Scratchpads

      The scratchpad is no longer a single parked window. There are now ten numbered slots, each holding any number of floating windows, overlaid on whatever workspace you are looking at. An empty slot is inert and invisible. #585

      • Assign Focused Window to Scratchpad N moves the focused window into slot N , floating it if it was tiled and parking it off-screen. Pressing the same shortcut on a window already in slot N returns it to the layout.

      • Toggle Scratchpad N reveals or parks every window in the slot as one coordinated operation, on the monitor you are interacting with. Revealing a slot parks whichever slot was showing, so at most one scratchpad is on screen at a time.

      • A revealed scratchpad follows you across workspace switches and stays up until you toggle it off. If it is showing on another monitor, its shortcut summons it to the one you are on.

      • Revealed windows behave as ordinary floating windows. Whether clicking something underneath pushes them behind it follows the usual focus and raise rules, including Raise Window When Focus Follows Mouse.

      • Every non-empty slot gets a Workspace Bar pill showing its name and its windows' icons; clicking the pill toggles that slot. Scratchpad pills always group by app, independent of the Deduplicate App Icons setting.

      • Slots are addressed by number everywhere. An optional label replaces the number in the Workspace Bar and in omniwmctl output:

        [scratchpads.labels]
        

        1 = "term" 3 = "COMMS"

      • Automation gets the full surface: omniwmctl command scratchpad assign <1-10>, omniwmctl command scratchpad toggle <1-10>, and window queries that expose both scratchpad membership and the slot index.

      Scratchpad membership lasts for the lifetime of the OmniWM process — only the labels are persisted. The ten assign/toggle pairs start unassigned except for slot 1, which inherits your previous scratchpad shortcuts through migration.

      Settings and Automation

      • Settings persistence now safely preserves unknown TOML keys through saves, including array-owned keys when their owner can be matched unambiguously. Ambiguous preservation, exhausted migration-backup slots, unsafe symlinks, and unsupported-schema or migration-backup save races leave the file untouched and block writes rather than risk data loss.
      • Trace and performance captures can be scripted with omniwmctl capture start trace, omniwmctl capture start performance, omniwmctl capture stop, and omniwmctl capture status. Capture state and the most recent artifact metadata are available through IPC. As with all omniwmctl use, Enable IPC must be turned on from the menu bar first.
      • Quake Terminal's updated GhosttyKit adds Kitty clipboard reads and writes, binary-safe multi-format transfers, clipboard type listings, requester-aware confirmation previews, optional session grants, and a dedicated selection clipboard.

      Workspace Bar and Window Lifecycle

      • Hide in Native Fullscreen is a new opt-in Workspace Bar setting, off by default. Suppression is derived per display, so a bar disappears only on the monitor showing a native-fullscreen Space and returns automatically on exit. Reserved tiled layout space stays stable to prevent unrelated windows from jumping. #601
      • Windows that apps such as Calendar close by ordering out instead of destroying are now retired from the layout. OmniWM validates targeted rescans against the app's Accessibility window list, including when the frontmost app loses its last focused window. #610
      • Targeted rescans preserve intentionally parked windows, including scratchpad and other hidden lifecycle states, rather than mistaking them for closed windows.

      Identity, Website, Documentation, and Thanks

      • OmniWM now uses a compass-mark identity across the app icon, launch overlay, status item, repository, and a reproducible brand-asset package.
      • omniwm.app launches with interactive feature demos, a knowledge base, install and CLI references, testimonials, sponsor credits, and canonical-domain redirects.
      • The README, architecture guide, IPC/CLI contract, issue-reporting guidance, and contributor documentation were rewritten against the current codebase and Swift 6.4 toolchain. The README now documents scratchpads, orientation-aware Niri containers, the advanced-commands hotkey filter, and the complete shortcut tables.
      • Matt Wicks (@wicksipedia) joins the contributor showcase under SSW Consulting, and the latest private sponsor is recognized anonymously with a path to request public credit.

      Release Integrity

      The OmniWM app is Developer ID signed, Apple-notarized, stapled, and Gatekeeper verified.

      • OmniWM-v0.6.4.zip SHA-256: 9b2bf54d20d67f536270032e0625176c06c6e03b8897ddf025558d948339e5e7
      • GhosttyKit.xcframework-v0.6.4.zip SHA-256: c7b1a8541206fa4ebf55e5dca8f12df4efa7ed5df490c4c426a5ee091c74ec21
   4. 🔗 r/LocalLLaMA zai-org/GLM-5.3 · Hugging Face rss

      | GLM-5.3 uses the same base model as GLM-5.2 — every gain comes from post-training. Compared with GLM-5.2, it is much better at complex coding and long-horizon tasks:

      • Stronger Coding: GLM-5.3 is the most capable open-weights model for coding, with a 50% improvement over GLM-5.2 on our in-house Z.ai Code Bench. It also achieve open-source SOTA on public benchmarks including Terminal Bench 3.0 and Agents' Last Exam.
      • Emergent Cyber Capability: As we scaled post-training, cyber capability developed faster than we expected. GLM-5.3 is state of the art on CyberGym for vulnerability discovery, and its gains are largest further up the exploitation chain, where it more than doubles GLM-5.2 on exploitation benchmarks.

      https://huggingface.co/unsloth/GLM-5.3-GGUF submitted by /u/jacek2023
      [link] [comments]
      ---|---

   5. 🔗 crosspoint-reader/crosspoint-reader v1.6.0rc release

      Summary

      This release is mostly bug fixes reported after 1.5.0. A handful of new features rode along too.

      New hardware support

      1.5.0 officially brought in support for our first ESP32S3-based reader — the Seeed reTerminal Sticky. With this release we now officially add support for the X4pro and M5Stack PaperMono devices. Both devices get full frontlight controls, swipe gestures in the reader, and the X4 Pro adds a capacitive Home key with configurable long-press settings.

      Want one? You can order them at crosspointreader.com/devices — that has our affiliate links, and buying from here helps support CrossPoint.

      Transparent sleep screens

      The sleep screen now supports transparent images. Add transparent PNGS and BMPs to your .sleep folder to see nice sleep screen overlays on top of your book pages!

      Reading Night Mode

      You can now toggle on Night Mode in the Reader settings to invert your display. This setting only effects your reader and will therefore flash white at the page refresh interval and revert to white outside of the reader and on your sleep cover.

      For dictionary users

      StarDict .syn synonym lookups are in, and HTML dictionary definitions now render through the EPUB engine instead of raw text — styled entries in dictionary lookups should display correctly now.

      The rest

      An Extra Wide line spacing option. You can now see the password while typing it into Wi-Fi, KOReader, and OPDS fields. Lists and tabs moved onto the new FUI framework.

      What's Changed

      • chore: split GH build action by @Uri-Tauber in #2901
      • fix(epub): bump FOOTNOTE_HREF_LEN 96→256 for long calibre paths by @fchaix in #2722
      • fix: invalidate stale footnote caches by @lpla in #2935
      • fix: accept any 2xx from KOSync-compatible servers by @itsthisjustin in #2945
      • fix(ui): wrap button hint labels that overflow their button by @vishae in #2928
      • feat: retain custom sleep screen during wake by @BrigBryu in #2943
      • feat: Adds dark mode with image polarity preservation by @itsthisjustin in #2705
      • feat: StarDict .syn synonym lookup support by @W-Floyd in #2696
      • fix: MAC address reading when WiFi is off by @itsthisjustin in #2960
      • fix: ignore empty watchdog reports by @uxjulia in #2968
      • fix: properly link AGENTS.md by @thiagokokada in #2976
      • feat: convert all lists and tabs to FUI by @itsthisjustin in #2957
      • feat: skip boot screen on startup by @uxjulia in #2989
      • feat: add orangutan translation by @Uri-Tauber in #2992
      • feat: add transparent sleep overlays by @lpla in #2937
      • feat: render HTML dictionary definitions via EPUB engine by @Uri-Tauber in #2836
      • fix: backport File Transfer guard from CrossInk by @lpla in #2990
      • perf: light-sleep idle + refresh downclock — ~3.2x active reading time (X3-measured) by @BrianPugh in #2525
      • fix: settings UI not updating after language change & line height padding by @itsthisjustin in #2997
      • fix: Guard GPIO13 power control for Xteink C3 boards only by @itsthisjustin in #2998
      • fix: prevent reader resume position rollback by @thiagokokada in #2962
      • fix: narrow pr-formatting-check.yml to pull_request_target only by @sfoulad in #3006
      • feat: support transparent PNG sleep overlays by @lpla in #2974
      • chore: remove unnesessary swallowing code by @Uri-Tauber in #2973
      • feat: Using factory lut for less fizzy cover image by @theZiz in #3018
      • fix: hyphenate focus-split words and break after visible hyphens by @Uri-Tauber in #2892
      • fix: batch-load SD fallback glyphs for UI text to fix Hangul slowdown by @itsthisjustin in #3026
      • refactor(reader): consolidate reader activities by @Uri-Tauber in #3025
      • fix: guard file list against render-task race in FileBrowserActivity by @serialx in #3034
      • chore: Revert "feat: Using factory lut for less fizzy cover image (#3018)" by @itsthisjustin in #3047
      • fix: release SD font caches before starting WiFi + web server by @serialx in #3035
      • fix: make the project agent guide a real AGENTS.md and relocate skills by @canardleteer in #3058
      • feat: Add support for x4pro & papermono devices by @itsthisjustin in #2983
      • fix: let TxtReaderActivity::skipPages() reach the end-of-book sentinel by @sfoulad in #3061
      • feat: add Extra Wide reader line spacing option by @serialx in #3037
      • fix: strip comments from XHTML in the EPUB optimizer by @s4y in #3028
      • fix: pagination to handle wrapped labels in UI lists by @itsthisjustin in #3072
      • fix: image decode overflow and viewport clipping issues by @itsthisjustin in #2959
      • fix: epub metadata parsing by @Leinnan in #3001
      • feat: show Wi-Fi, KOReader, and OPDS passwords during entry by @uxjulia in #3080
      • chore: revert light sleep code but keep battery drain fix by @itsthisjustin in #3077
      • docs: correct contributing guide to branch from develop by @fain182 in #3081
      • fix: Slow CJK TOC & Lists by @itsthisjustin in #3071
      • fix: Release SD font cache before render transparent sleep overlay by @RayWarthog in #3093
      • fix(ruby): don't flush while in a ruby group by @brianhuster in #3102
      • fix: stop negative font IDs from stealing scan slots by @serialx in #3107
      • fix: clear sleep image after wake by @thiagokokada in #3009
      • fix: add ' to the static HTML entity table by @Uri-Tauber in #3122
      • fix: don't use dithering for non-alpha bmp transparent sleep screen by @theZiz in #3119
      • feat: strip embedded fonts during EPUB optimization by @hyemin-ht-kang in #3085
      • feat(fonts): add script-group metadata to the font manifest by @Uri-Tauber in #2699
      • fix(epub): ignore trailing non-XML data after tag in ChapterHtmlSlimParser by @bjesus in #3134
      • feat(fonts): use Ubuntu Medium as the UI text weight by @fain182 in #3096
      • feat: lower frontlight brightness for x4pro by @itsthisjustin in #3115
      • feat: scripts grouping in fonts manager by @Uri-Tauber in #3141
      • feat: render EPUB tables as columns by @lpla in #2654

      New Contributors

      • @fchaix made their first contribution in #2722
      • @vishae made their first contribution in #2928
      • @BrigBryu made their first contribution in #2943
      • @BrianPugh made their first contribution in #2525
      • @sfoulad made their first contribution in #3006
      • @serialx made their first contribution in #3034
      • @canardleteer made their first contribution in #3058
      • @s4y made their first contribution in #3028
      • @Leinnan made their first contribution in #3001
      • @RayWarthog made their first contribution in #3093

      Full Changelog : v1.5.0...1.6.0rc

   6. 🔗 gildas-lormeau/single-file-cli v2.4.0 release

      New features

      • Added --browser-profile to capture pages with a browser profile, and --create-browser-profile to create one interactively (e.g. to log into a website before capturing it)

      Fixes

      • Fixed pages being captured as if they were controlled by automation: the browser is no longer launched with --enable-automation, so navigator.webdriver is now false
      • Fixed pages being captured as if the browser were headless: the Headless token is now removed from the user agent, fixing captures of websites which reject headless browsers (e.g. pages saved as a "Just a moment..." interstitial). --user-agent still takes precedence when set
      • Fixed the filenames of unwritten files displayed in the progress output when using --dump-content
      • Fixes from single-file-core 1.5.99 to 1.5.106, including: fixed srcset attributes losing candidates with invalid descriptors and producing empty entries, fixed filenames starting with a dot, fixed the data used by {digest-sha-*} filename templates being missing (fix gildas-lormeau/SingleFile#1756)

      Co-authored by Claude (Claude Code)

   7. 🔗 HexRaysSA/plugin-repository commits sync repo: +2 plugins, +6 releases rss

      sync repo: +2 plugins, +6 releases
      
      ## New plugins
      - [ida-mcp](https://github.com/hexrayssa/ida-mcp) (0.8.1, 0.8.0)
      - [ipyida](https://github.com/eset/ipyida) (2.3)
      
      ## New releases
      - [ida-bochs-binaries](https://github.com/hexrayssa/ida-bochs-binaries): 1.0.3
      - [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.8.1, 0.8.0
      

   8. 🔗 r/LocalLLaMA claude mods didn't like that, somehow 🤷‍♀️ rss

      | submitted by /u/peculiar-ragdoll
      [link] [comments]
      ---|---

   9. 🔗 New Music Releases Mastodon - Marrow Deep rss

      Mastodon - a new release is available:

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

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

      Visit muspy for more information.

   10. 🔗 New Music Releases Kamelot - Dark Asylum rss

       Kamelot - a new release is available:

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

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

       Visit muspy for more information.

   11. 🔗 New Music Releases Russian Circles - Nine rss

       Russian Circles - a new release is available:

       • 2026-08-28: Nine (Album)

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

       Visit muspy for more information.

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

       Train - a new release is available:

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

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

       Visit muspy for more information.

   13. 🔗 New Music Releases Kaskade - Hear Me Now rss

       Kaskade - a new release is available:

       • 2026-08-28: Hear Me Now (Single)

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

       Visit muspy for more information.

   14. 🔗 New Music Releases Vintage Culture - Selekta EP rss

       Vintage Culture - a new release is available:

       • 2026-08-28: Selekta EP (EP)

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

       Visit muspy for more information.

   15. 🔗 Ampcode News Amp on iOS & macOS rss

       Control your orbs from anywhere.

       Install the iOS app through TestFlight[^1], and the macOS app through direct download.

       Download at ampcode.com/app.

       It's orbin' time no matter where you are.

   16. 🔗 Ampcode News No Mailmap Required rss

       Amp can now use a Git identity that is separate from the email on your Amp account. Pick the name and verified email that should appear on commits made in orbs.

       You can ask Puck to set it for you:

       

       If you have not added the identity yet, Puck sends a verification link to the email address. Once you click it, Puck gets notified and can make the identity your personal default if you asked it to.

       You can also manage identities under Signing Keys. Your personal default applies to personal projects unless you choose another identity in a project's settings. Workspace admins choose one rule for the whole workspace:

       • Amp uses the Amp identity.
       • Amp Account uses each member's Amp account.
       • User Choice lets each member choose.

       When Amp starts an orb, it sets GIT_AUTHOR_* and GIT_COMMITTER_* from the selected identity. If commit signing is on, Amp only signs for an email you have verified.

       Your Amp login can stay tfc@ampcode.com while your commits use tim@culver.house.

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

      IDA Plugin Updates on 2026-08-27

      New Releases:

      • ida-nexus v0.8.1
      • ida-nexus v0.8.0

      Activity:

      • claude-marketplace
        • 82d6625b: Change IDA MCP URL
      • disrobe
        • b17915d4: xtask: synchronize python 3.13 threshold routing
        • e3785be1: native: recover msvc security cookie guards
        • 6084b650: publish current python and dex recovery measurements
        • 249aaa1a: python: publish the improved pinned corpus result
        • 1db331c3: preserve explicit none returns after nested guards
        • 92b837ad: native: recover rust bounds panic guards
        • 375f9560: native: grade stripped elf exported names
        • b129e0f6: recover nonconstant returns from infinite finally arms
        • 51371393: native: recover exported function names with typed evidence
        • 08c1ee40: add flutter fallback engine identity
        • 4013718e: recover guarded returns from infinite finally arms
        • cf0209a9: reuse Flutter symbols from the Python cache
        • 91bdf3c2: python: recover guarded breaks inside infinite finally arms
        • 083cd586: infer Flutter parameter arity
        • 0b1c640d: python: preserve guarded finally breaks in infinite loops
        • bd9fadcb: recover resolved import thunk names
        • 2a390d23: cache flutter engine symbol maps
        • dd963bb6: python: register byte coverage result type
        • 5b60348a: native: bound frame-pointer allocations
      • ida-bochs-binaries
        • 067c07fc: ci: standardize IDA installation pattern (#9)
      • ida-llm-explainer
        • 99e6a96d: Settings: group into tabs (Server/Explain/CFG trace/C export/Agent se…
        • 7de1cfd7: docs: agent.md - operating instructions for external agents
        • c12f0e25: v1.11.0: agent server - localhost HTTP API for external agents to dri…
        • 9a634d7d: v1.10.0: auto-compact + live context gauge (with t/s), clean context …
      • ida-nexus
        • 737fdced: Only create mcp session log when events come in
        • 8d3a9212: 0.8.1
        • ddbf1bf1: Add missing LICENSE
        • a7aa95ed: Redirect to ida-mcp for installation instructions
        • 65ecd8b4: 0.8.0
        • 656fe6b4: Fix release workflow
        • af9aa5df: Create reusable ida_nexus.plugin module
        • 61128e42: Remove extensions from repository
        • 1dfce8fa: Update tool descriptions to include IDA Nexus where appropriate
      • ida-pro-mcp
        • f19e02bb: Merge pull request #515 from Iams4kura/bugfix/omit-notification-respo…
        • e5d3a6e8: fix(http): omit notification response bodies
      • idamcp
        • 1d726bd7: Refactor sql_query to return structured QueryResult
        • ce73a56c: Fix potential database initialization race conditions
        • 38543b66: Suppress KeyboardInterrupt in gateway proxy
        • a64b3593: Allow target address outside of image in get_xrefs_to
      • idawilli
        • df5d53a6: Merge pull request #150 from williballenthin/fix-oplog-ida94-tests
        • fca90673: Merge pull request #149 from williballenthin/fix-codemode-sandbox
        • d8846ad3: Merge pull request #148 from williballenthin/fix-codemode-api-ty
        • 57e0606c: fix: MontyTypingError.display() no longer takes format kwarg
        • 30bf2a1d: fix oplog tests for IDA 9.4 API changes
        • 0db6f246: trigger CI
        • c4afbdb1: fix: adapt IdaSandbox to pydantic-monty pool/session API
        • 911aac08: fix: remove unused type-ignore directives in ida-codemode-api
        • d9bbfb13: Merge pull request #147 from williballenthin/update-gha-skill
        • 75b34bcc: update skill: -seed for IDA venv, fix example typos
        • 2f0dfabf: refactor: follow skill pattern for IDA venv/idapyswitch/IDAPYTHON_VEN…
        • 50062f53: fix: use uv venv -seed for oplog so hcli finds pip
        • 12e46233: fix: set HCLI_CURRENT_IDA_PYTHON_EXE for oplog, -python for ty
        • ab62b038: fix: use uv venv instead of -system for Python environment
        • b7a31946: update CI workflows to follow IDA GHA skill conventions
        • f229c7b9: ida gha: real world lessons
        • 4924de81: add skill for IDA and GH Actions
      • ipyida
        • 56ba0915: Make sure the repo URL in the ida-plugin.json doesn't include the www.
        • ecd266ae: Revert "Add a ida-plugin.json file so the hcli repo finder robot pick…
      • Security-Tools
        • b5784e3e: Add new software
   2. 🔗 r/LocalLLaMA 5090 now officially cost 5090 rss

      | I was planning on another 5090, but then I realize... perhaps I am much better off getting an M5 Ultra Mac Studio with 256gb of ram. We are so genuinely cooked. submitted by /u/Sadge404
      [link] [comments]
      ---|---

   3. 🔗 r/LocalLLaMA With HuggingFace, Nvidia is also acquiring llama.cpp and the team behind it rss

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

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

      This includes:

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

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

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

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

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

      Source:

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

      Edit:

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

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

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

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

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

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

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

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

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

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

      

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

      Enzyme to React Testing Library migration

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

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

      Our button that increments its counter

      Now, the test to verify this, in Enzyme:

      The unit test in Enzyme

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

      The unit test in React Testing Library

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

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

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

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

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

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

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

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

      AI makes impractical migrations doable

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

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

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

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

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

      A few more details from inside Asana

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

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

      And finally, one addition from my end:

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

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

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

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

      Expect long-avoided migrations to finally happen

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

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

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

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

      ---

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

      🍂 IDA Pro fall training season is coming...

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

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

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

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

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

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

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

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

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

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

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

       The system lived in my head

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

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

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

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

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

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

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

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

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

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

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

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

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

       The rule forced me to get those reps.

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

       One agent became a dozen

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

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

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

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

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

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

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

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

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

       I closed my laptop. The work kept going.

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

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

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

       

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

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

       So I built botd.

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

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

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

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

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

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

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

       Everything passed. I still didn’t want it.

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

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

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

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

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

       

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

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

       

       I threw it away anyway.

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

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

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

       Shipping got easy. Deciding what to ship got important.

       Not all agents write code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       

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

       Engineer the system before the agent writes the code

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       botd is dead; long live botd

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

       From CommsPerson@Startup.com

       Hi Gergely,

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

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

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

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

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

       Would this be worth exploring for the podcast?

       Best,

       MarketingPerson
       Startup

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

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

       But to spell it out to the marketing folks:

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

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

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

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

       But to leave these marketing folks with some advice:

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

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

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

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

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

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

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

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

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

       What's Changed

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

       New Contributors

       • @fgrehm made their first contribution in #1066

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

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

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

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

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

   17. 🔗 Console.dev newsletter PicoMQ rss

       Description: Durable streams on object storage.

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

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

   18. 🔗 Console.dev newsletter MicroLighter rss

       Description: CSS syntax highlighter.

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

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

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

       Above & Beyond - a new release is available:

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

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

       Visit muspy for more information.

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

       Armin van Buuren - a new release is available:

       • 2026-08-27: Starbound (Single)

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

       Visit muspy for more information.

   21. 🔗 Ampcode News Projects with Multiple Repositories rss

       Projects in Amp can now include more than one repository.

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

       

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

       

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

   22. 🔗 Ampcode News So Long, TUI Sidebar rss

       We are removing the sidebar from the Amp TUI.

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

       

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

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

       ---

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

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

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

generated: August 30, 2026 at 01:54:16