🏡


  1. September 15, 2026
    1. 🔗 Locklin on science Developing immunity to propaganda rss

      Propaganda is one of those things which has obviously improved in its execution over time. In part this is due to higher levels of education among the populace. Educated people are used to stuffing facts in their brains, and continue the habit after the formal education has ended. This is what propaganda is: stuffing unverified […]

    2. 🔗 backnotprop/plannotator v0.27.15 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.27.14 | Pi plan progress survives compaction, Codex threads across rollout files, WSL browser setting, Mod+E edit mode
      v0.27.13 | Open a review on a specific base (--base, --diff-type), symlink containment on /api/doc, CI flake fix, Amp decision relay
      v0.27.12 | Unified decision control, token hover cards, local-vs-remote diff, approval notes
      v0.27.11 | OpenCode server leak fix, durable local feedback archive, unknown-subcommand fix
      v0.27.10 | Auto-viewed files on scroll, annotation undo/redo, OpenCode 2 slash commands restored, npm 12 agent terminal fix
      v0.27.9 | WebMCP browser-agent tools, HTML refresh from disk, host seams, lazy renderers, Windows uninstall fix
      v0.27.8 | Pi keeps its prompt cache across plan transitions, thumbs-up returns to HTML annotation, embed picker seam
      v0.27.7 | Pi host crash fix on Windows, Call Flow tree cap, jj fork-point base, plannotator knowledge skill + llms.txt
      v0.27.6 | Live app annotation lands on Pi, one interaction model for HTML pages
      v0.27.5 | Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix
      v0.27.4 | Portable Guided Review exports, guides.show share links, guide CLI, jj Call Flow
      v0.27.3 | Folder watcher freeze fix on large repos, first SBOM-attested release pipeline

      What's New in v0.27.15

      Twenty-six pull requests, three of them from outside contributors and two of those first contributions. Most of the work is on the HTML annotate surface: pinpoint comments now carry a description of the element they point at, the page gets the whole viewport by default, links between local HTML files stay inside the session, and a folder review can finally see every comment it has collected. The rest is correctness work on annotation restore, on the Codex Stop hook, on the OpenCode 2 notice ordering, and on the x64 release binaries.

      Four behavior changes are worth reading before you update: HTML annotate sessions now open with the floating tools hidden, the plan diff opens in Classic view again, an emoji on a GitHub alert's first line becomes that alert's icon, and Codex 0.114 through 0.116 users now get plan review on Stop where they previously got nothing.

      Plannotator TUI and Herdr Annotate

      A one-time panel now announces Plannotator's two terminal tools. Plannotator TUI is a standalone terminal client: annotate Markdown in the terminal (select, comment, looks good, delete), review a folder, or annotate one of your agent's recent replies, then hand the review to your agent as numbered feedback. Herdr Annotate is a Plannotator plugin for Herdr: comment on any terminal text, review Markdown documents and agent replies inside Herdr, and send the feedback straight back to the agent. Its document review runs Plannotator TUI.

      The panel shows a looping demo of the real client, one headline, one sentence, and a row of actions. It appears once per browser across plan review, annotate, and code review, then never again. There are no install commands or feature lists in it; the repo pages carry those. It is also suppressed in sessions that have no server behind them, so the public share portal never shows it.

      The repos are plannotator-tui and herdr-annotate.

      Pinpoint comments describe the element to the agent

      Pinpointing an element in a raw HTML or live app session used to export either a placeholder quote (Feedback on: "[element: Navigation]") or the element's flattened text. The bridge already knew the element's selector, tag, and text, but nothing in the export read them, so an agent receiving the feedback could not tell which element the comment was about.

      Each pinpoint now captures a bounded description of the element at click time: tag, id, author-written classes, an ancestor path, ARIA role and accessible name, an allowlisted set of attributes, the rendered text, a collapsed HTML skeleton, the child count, the viewport box, the nearest landmark and heading, a component hint from data-component or data-testid, and in live app sessions the route and page title. The export prints that skeleton as a fenced block under the comment with the selector, path, role, name, attributes, and box beneath it, so the agent can find the element in the source.

      The capture is deliberately narrow. Form values, inline on* handlers, style, script and template contents, and full innerHTML are never read. URLs in captured attributes lose their query and fragment, both absolute and relative, so a checkout link carrying a session token is not written into a draft or an exported comment. Everything is re-validated and re-capped when it crosses back out of the iframe, and the whole record is hard-capped at 2 KiB per comment, so a 400-row list costs the same bytes as a button. Annotations without the field export exactly as they did before.

      HTML annotate: the page gets the viewport, and the chords are real

      Three changes to the raw HTML surface, all from owner feedback while using it.

      Tools are hidden on open. An annotated HTML page owns the full viewport now, with no floating chrome over it on a fresh session. The header eye shows them, and so does the new Mod+Shift+X chord. A reviewer who explicitly shows the tools keeps them next session, and the control that brings them back lives in the header, so a hidden state can never strand you. One consequence to know: the version diff's "Show changes" control lives in that floating cluster, so on a fresh session it is behind the eye.

      Mod+Shift+A is a documented toggle. It was already wired as one in the app, but the shortcut registry and the docs described it as a re-arm only, which left "Escape dropped me to Interact, how do I get back?" unanswered. It is now described and tested as the toggle it is, and the bridge mirrors both chords from inside the sandboxed iframe, so they work whichever document has focus.

      The header controls explain themselves. Back, Refresh, the eye, and the pen now carry tooltips with a description line and their keyboard shortcut instead of a bare title string.

      Links between local HTML files open as linked documents

      A srcdoc document has no URL of its own, so it inherits the parent page's. A plain <a href="01-entry-point.html"> inside an annotated HTML file therefore resolved against the Plannotator server, the catch-all route answered with the app's own HTML, and the entire editor rendered inside the annotated frame. Even an in-page #anchor did it.

      Link clicks are now intercepted in the bridge and resolved in the parent. A relative or nested sibling opens as a linked document in place, with its annotations kept per document. An in-page fragment scrolls within the current document. A server-absolute path resolves against the directory the session opened from. A sibling markdown file opens as a markdown document. An off- origin link opens in a new tab with noopener. A file that cannot be annotated gets a toast and no navigation, and javascript:, data:, mailto: and file: are dropped. Live app sessions are untouched.

      The way back is a new header control, leftmost of the group, named after the document it returns to. It claims no keyboard chord, because Alt+Left and the browser's own Back belong to you. The compact touch shell gets the same action in its Options menu. Link clicks no longer pop the sidebar open on HTML documents, since a full-screen page owns the viewport and the sidebar is not where the way back lives anymore.

      All files view in the annotations panel

      In a folder session the annotations panel only ever showed the open file's comments. Reviewing across several documents, there was no way to see the whole review, and a file with nothing on it showed "No annotations yet" beside a small count of comments elsewhere that you could not read.

      The panel header now carries a This file | All files toggle, shown whenever feedback exists outside the open document. All files groups comments by document, open document first and the rest by path, each group collapsible and labelled relative to the session root. The groups render the same annotation cards the single-document timeline renders, so quote, comment, type, images, replies, Edit and Delete all work across files, and a cross-file delete is reflected in what gets submitted. Clicking a card navigates to that document and selects the comment there.

      The default rule is the frustration this exists for: your saved preference wins, except that a document with no feedback of its own, while other documents have some, opens on All files. Arriving by clicking a card in the All files list keeps you on All files. A plan review session with linked documents open contributes the plan's own comments as a group too, labelled (this plan).

      • #1533, with the plan-document group, normalized cross-file paths, and 44px touch targets in #1537

      GitHub alert titles, and the annotation restore work that followed

      A GitHub alert whose first body line is a bold-only line now renders that line as the alert's title on the icon row, in place of the type word. An emoji on that line becomes the alert's icon, which is the behavior change to know about: > [!TIP] followed by > 💡 **Browser quirks** now shows the lightbulb and the title rather than the default tip icon and a bold paragraph. The type word stays in the accessible name, so a screen reader still hears "Tip: Browser quirks". An alert with no title line renders exactly as before. Hosts embedding the UI can supply their own icon set through a new alertIconRenderer seam; Plannotator bundles none.

      That change removed a paragraph from the rendered alert, and the annotation layer addresses blocks by position. A draft saved before the upgrade could resolve onto the wrong element, so restore verification was turned on for plan review and annotate: a restore whose painted text does not match the annotation's own quote is dropped and retried by text search, and only reported when the rescue also fails. That guard then turned out to be too strict, and the next two releases of work fixed what it broke and what it had been hiding.

      Restore verification compared the stored quote against the painted text with whitespace collapsed to a single space, but a selection string carries a blank line between blocks and the painted marks are concatenated with nothing between them. Every annotation spanning two paragraphs, a heading and its paragraph, or two list items came back from a reload with no highlight at all, under a misleading toast about edited text. Whitespace-only differences are now accepted, and content drift is still rejected. Two more shapes were failing closed for their own reasons: a drag starting inside excluded chrome, such as an alert's visually hidden type word, painted only its tail, so the start of a range is now snapped onto the first annotatable position it covers; and list markers are select-none, so a selection spanning two list items resolved onto text the bullet had joined, which the verification then rejected.

      The other half of this is that an annotation that genuinely cannot be re- anchored is now visible on markdown surfaces the way it already was on HTML: the comment stays in the panel, still exports, and carries an Unanchored chip so you know its highlight is gone rather than wondering where it went.

      Comment box caret alignment on Windows and Linux

      The comment composer paints its visible text with a mirror layer over a transparent textarea, and only the caret still comes from the textarea itself. When the textarea grew tall enough to sprout a classic vertical scrollbar, the kind Windows and Linux use, which consumes layout width, the textarea's lines wrapped earlier than the mirror's. From the first line whose wrap point differed, the caret was drawn away from the character it belonged to. macOS and iOS overlay scrollbars take no layout width, which is why nobody on a Mac ever saw it.

      The overlay's right padding now tracks the measured scrollbar width, re- measured when a resize adds or drops the scrollbar rather than only on keystrokes. Where the measured width is zero, the code writes no inline style at all, so macOS, iOS, and every touch surface render a byte-identical DOM to before.

      Classic is the plan diff default again

      The plan diff opens in Classic view, the block-level view with old above new. The word-level Rendered view is still there next to Raw. This applies to every surface that renders the plan diff, including the annotate version diff, since they share one mode setting.

      OpenCode 2: feedback no longer lands behind the session notice

      On OpenCode v2, /plannotator-last printed "Plannotator session ready: " and the agent correctly stayed idle. When the reviewer clicked Send Feedback, the agent woke up and spent a whole model turn on the URL notice first, with the annotations arriving in the turn after it. A plugin's synthetic message is not a notification on OpenCode 2: it admits a pending inbox row, and declining the wake does not exempt that row from the next promotion. Since queued rows promote one at a time, oldest first, the reviewer's own feedback was what woke the session and pulled the stale notice ahead of it.

      The notice and the feedback that follows it now share one promotion, so they enter the same turn. Two follow-ups hardened the tracking behind that. The first made the pending flag track reality instead of intent: it was set when the host accepted the notice and cleared only after our own prompt, so a reviewer who typed anything in the TUI while the review was open had the notice promoted out from under the flag, and feedback sent minutes later was steered into the middle of an unrelated turn. The flag is now cleared when the host reports the row left the inbox, read in both event vocabularies OpenCode 2 uses, after which feedback falls back to queued delivery. The second made the tracker's dispose() terminal, so a notice that outlives its command cannot re-open an event subscription on the host with no owner left to close it. OpenCode 1 is untouched throughout.

      Codex: Stop plan review stays in the current turn

      The Codex Stop hook could scrape the most recent <proposed_plan> out of the rollout even when the turn that just ended proposed no plan, which resurfaced a plan from an earlier turn and opened a second review of something already decided. Plan candidates are now confined to the turn the Stop payload identifies, and the hook fails closed when turn identity is unavailable rather than guessing from stale transcript content.

      That fix assumed every Codex sends a turn id with its Stop payload. It does not. The hooks engine shipped in Codex 0.114 and the turn_id field only landed in 0.117, so on 0.114 through 0.116 plan review silently stopped: no UI, no message, exit 0. Those versions do write turn markers into the rollout, so when the payload carries no turn_id at all the hook now resolves the turn from the rollout's own last id-carrying marker and runs the unchanged machinery on it. Codex builds that do send turn_id behave byte for byte as before. A blank turn id is still refused rather than treated as absent, and a rollout with no turn marker at all still fails closed.

      The deny-and-resubmit de-duplication needed the same treatment. It anchored on a <hook_prompt> user message that Codex only started writing in 0.117, so on exactly the versions the rollout fallback exists to support, a reviewer who clicked Request changes got the unchanged denied plan re-opened whenever the model replied without a fresh plan. The boundary is now whatever the previous blocking Stop left in the turn, accepting Codex's older developer-role continuation message on the rollout-fallback path only.

      Pi: PLANNOTATOR_BROWSER script paths work on macOS

      On macOS the Pi extension always ran open -a $PLANNOTATOR_BROWSER <url>, treating the value as an application bundle. Pointing it at a script or an executable failed with a LaunchServices error that the detached spawn swallowed, so the extension reported that the review had opened while nothing did. Pi now mirrors the branch the plannotator binary already had: a value containing a slash that does not end in .app is executed directly with the URL as its argument, and application names and .app paths keep going through open -a.

      x64 release binaries run on older CPUs

      The v0.27.14 Linux x64 CLI exited with SIGILL on an Ivy Bridge Xeon E3-1220 V2, because the default Bun x64 target assumes instructions those CPUs do not have. The Linux and Windows x64 CLI and paste service binaries are now compiled with Bun's baseline x64 target, which Bun recommends for pre-2013 hardware. A bounded QEMU Nehalem gate was added to the existing Linux release smoke job, checking CLI --help, an exact --version match, and paste service startup, so a non-baseline binary fails the release rather than reaching someone's machine. Asset names, checksums, provenance attestations, the installers, the Bun pin, and every other platform target are unchanged.

      Additional Changes

      • Annotation panel chrome. The header decision button reads Send Feedback rather than Send Feedback · n, and the per-row Copy button briefly added to annotation cards is gone; cards are back to Edit and Delete on every surface. Both owner-directed (#1516, #1520)
      • @plannotator/ui package publishes. 0.38.1 on core 0.25.2 fixes an install failure for embedding hosts: 0.38.0 imported a core subpath that had never been published, and the package smoke test now catches that class of break by checking the source imports against the published core. 0.38.2 restores the alert type word in the accessible name on WebKit and relaxes the React peer range back to ^19.2.3. 0.39.0 carries the element context types and parser helpers (#1510, #1511, #1522)
      • DOM tests actually run in CI. Forty-two DOM-gated test files had drifted off the workflow's explicit list and were silently skipping. They are registered now, along with a guard test that fails whenever a DOM-gated file in the repo is not named in a DOM_TESTS step (#1537, #1538)

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

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

      OpenCode: Clear cache and restart:

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

      What's Changed

      • feat(ui): render a GitHub alert's bold-only first line as its title, with an icon seam by @backnotprop in #1509
      • fix(packages): core 0.25.2 + ui 0.38.1, and a package smoke that catches an unpublished core subpath by @backnotprop in #1510
      • fix(ui): keep the alert type word in the accessible name on every engine (ui 0.38.2) by @backnotprop in #1511
      • fix(ui): drop the annotation count pill from the header decision primary by @backnotprop in #1516
      • feat(annotate): carry agent-facing element context on HTML and live-app pinpoints by @backnotprop in #1517
      • fix(opencode): co-promote the session-URL notice with the feedback on OpenCode 2 by @backnotprop in #1518
      • fix(ui): remove the annotation panel's per-row Copy button by @backnotprop in #1520
      • chore(ui): bump @plannotator/ui to 0.39.0 by @backnotprop in #1522
      • feat(ui): one-time announcement dialog for Plannotator TUI and Herdr Annotate by @backnotprop in #1529
      • fix(codex): keep Stop plan review in the current turn by @rNoz in #1169
      • fix(pi-extension): run script/executable PLANNOTATOR_BROWSER paths directly on macOS by @punk-dev-robot in #1429
      • fix(ci): build x64 releases for baseline CPUs by @ybtam in #1514
      • fix(ui): keep the composer text overlay aligned with the textarea when a classic scrollbar appears by @backnotprop in #1530
      • feat(annotate): hide HTML tools by default, toggle chords for annotate mode and tools, shortcut tooltips on the header controls by @backnotprop in #1531
      • fix(annotate): open relative links between HTML files as linked documents instead of loading the app inside the frame by @backnotprop in #1532
      • feat(annotate): All files view in the annotations panel for folder sessions by @backnotprop in #1533
      • fix(codex): resolve the current turn from the rollout when the Stop payload carries no turn_id by @backnotprop in #1534
      • fix(opencode): track whether the session-URL notice is still pending before steering feedback by @backnotprop in #1536
      • fix(annotate): QA follow-ups for the folder, All files, and HTML surfaces by @backnotprop in #1537
      • fix(ui): keep GitHub alert titles from breaking annotation anchors and quotes by @backnotprop in #1535
      • ci: register the #1535 DOM tests in the allowlist by @backnotprop in #1538
      • fix(codex): keep deny/resubmit de-duplication working on the rollout-fallback path by @backnotprop in #1539
      • fix(opencode): make the notice tracker's dispose terminal by @backnotprop in #1540
      • fix(ui): accept whitespace-only differences in restore verification, snap excluded selection starts, and merge folder-session chrome re-stamps by @backnotprop in #1541
      • fix(ui): restore cross-block annotations over list markers and alert titles from drafts by @backnotprop in #1542
      • fix(editor): default the plan diff view to Classic by @backnotprop in #1544

      New Contributors

      Contributors

      @rNoz returns with the Codex Stop turn scoping in #1169, the fix that stops a decided plan from being re-opened by a later turn. It is his tenth merged pull request on the project, and the two follow-ups in this release both build directly on the machinery it introduced. He also helped diagnose the Pi browser failure on @punk-dev-robot's issue.

      @punk-dev-robot reported the silent PLANNOTATOR_BROWSER failure on macOS in #1391 and then fixed it in #1429, matching the branch the main binary already had rather than inventing a second behavior. First contribution.

      @ybtam found that the official Linux x64 binary would not start on an Ivy Bridge Xeon, tracked it to the Bun compile target, and shipped the baseline build with a QEMU Nehalem gate in #1514 so the failure cannot ship again. First contribution.

      The reports and proposals that shaped this release:

      • @de-tre reported the misaligned comment caret in #1525, with the scrollbar observation that made the root cause obvious
      • @Naasha reported the queued annotations on OpenCode v2 in #1515
      • @jpvarbed reported plan review re-opening for an already-decided plan in #1075
      • @tekumara wrote a detailed proposal and mock for a unified review navigator in #1524. It was built in full and compared side by side against the current panel, and the current Tree / Git status / Commits design was kept; the branch is available to anyone who wants to take it further
      • @JcMinarro asked for review-level comments in #1527 and, in finding that the button already existed since v0.27.12, made the case that it is placed where people do not look for it

      Thank you. Plannotator gets better because you tell us where it falls short.

      Full Changelog : v0.27.14...v0.27.15

    3. 🔗 crmne/spotifast Spotifast 0.8.0 release

      0.8.0 introduces custom themes and automatic Omarchy theme updates. It is also the first release under the new name, Spotifast , at spotifast.rocks. Your existing native-package settings and sign-ins carry over. Flatpak users switch to the new application ID as described below.

      screenrecording-2026-09-15_11-13-29.mp4 screenrecording-2026-09-15_11-32-22.mp4

      New

      • Flatpak installs as Spotifast. The bundle now uses rocks.spotifast.Spotifast. Install it separately from the old ID, copy settings and history if wanted, and sign in again. The repackaged bundle contains the original 0.8.0 executable. Switching instructions. By @crmne.
      • Make the app match your desktop. Choose Light, Dark, Follow system, or a local JSON palette. On Omarchy, packaged installs set up the theme hook at first launch and follow theme changes automatically. Open the themes folder from Settings to add your own palettes. Themes change colors while preserving the familiar layout and fonts. By @jdubba1 and @crmne. (#392)
      • Install updates from inside the app. Download an update, then choose when to restart and install it. A failed installation restores the previous copy. By @coah80 and @crmne. (#383, #79)
      • macOS downloads are signed and notarized by Apple. Both Apple Silicon and Intel are included in the same download. By @crmne.
      • Middle-click to autoscroll on Windows. Move the pointer to scroll the current list; click or press Escape to stop. No setting is needed. By @zHeuzy2 and @crmne. (#112, #96)
      • Refresh a playlist from its three-dot menu. Reload its details and songs without leaving the page. By @AQS-DS and @crmne. (#397)
      • Find settings by typing their names. Settings search matches the visible controls. By @KartikeyaKotkar and @crmne. (#372)
      • Double-click a Library item to play it. Play an album or playlist straight from the sidebar. By @skorokithakis. (#391)
      • Drag all your selected songs together. Copy a selection into a playlist, drop into the open playlist, and scroll near list edges while dragging. By @sanketttt26 and @crmne. (#290)
      • Keep the Library in your preferred order. Sort choices persist, and Liked Songs can move with other Library items. By @crmne.
      • Control playback from the Windows taskbar preview. Play, pause and skip without bringing the window forward. By @Shipi1.
      • Search can use your personal Spotify app. The sign-in flow explains when a personal app is useful for Premium listeners. By @joshkat and @crmne. (#388)
      • Choose which recommendation shelves appear on Home. JSON settings can hide Made for you and Recommended for you independently. By @jdubba1 and @crmne. (#393, #134)

      Fixed

      • Shared-app playlists load through the playback session , with account-specific caches and complete song ordering. By @chagel and @crmne. (#271)
      • Playlist Play starts at the first available song with shuffle off. Sorted and filtered views keep their visible order, and the requested song appears immediately. By @crmne.
      • Repeated songs stay in the queue when adding a selection. Each selected occurrence is preserved. By @kevin9327. (#444)
      • Recent plays keep the right songs and ordering. Repeated short-song listens remain separate, each row starts its own song, and loading older history leaves newer Library plays at the top. By @kevin9327 and @crmne. (#421, #422, #445)
      • Long playlists and albums keep a full-length scrollbar. Jump to distant songs, with placeholders and Retry when a page cannot load. By @alexng353 and @crmne. (#384)
      • Queue and Lyrics retain their full height beside the toolbar. Search and update controls fit the available page width. By @luiscuellar31 and @crmne. (#386, #378)
      • Keyboard shortcuts respect text editing and modifiers. Arrow keys move the caret in focused fields, Queue shortcuts no longer quit the app, and the playing-album shortcut opens the album. By @kevin9327 and @crmne. (#415, #416)
      • Mixed-script and right-to-left titles fit more reliably. Fallback fonts align with Inter, long RTL titles end within their text area, and Yi artist names can use installed fonts. By @kveld9, @kevin9327 and @crmne. (#345, #340, #439)
      • Maximized windows restore correctly , and Windows checks mini-player positions against available monitors. By @luiscuellar31 and @crmne. (#396, #351)
      • Flatpak keeps settings and sign-ins after fully quitting. By @GusMartins499. (#370)
      • Spotify grants use the native credential store , with sign-in attempts isolated from older callbacks. By @crmne.
      • Playback tries other addresses when a connection stalls. Connection attempts have bounded timeouts. By @crmne. (#413)
      • Large playlist cache writes use less temporary memory , and bounded page caches preserve pending edits. By @Cleboost and @crmne. (#328, #320)
      • EPs are shown separately from singles , submenu icons align consistently, and malformed album dates or nested unpacked skins are handled correctly. By @luiscuellar31, @kveld9, @kevin9327 and @crmne. (#356, #295, #341, #337)
      • Linux packages declare the GUI libraries they need. DEB and RPM installation is checked on both architectures; Gentoo instructions are also available. By @aljazceru, @NikoMalik and @crmne. (#399, #389)

      Thanks

      @jdubba1, @coah80, @zHeuzy2, @AQS-DS, @KartikeyaKotkar, @skorokithakis, @sanketttt26, @Shipi1, @joshkat, @chagel, @kevin9327, @alexng353, @luiscuellar31, @kveld9, @GusMartins499, @Cleboost, @aljazceru, @NikoMalik, and everyone who reported and helped test these changes, including @juanre7.

      Full changelog : v0.7.1...v0.8.0

    4. 🔗 HexRaysSA/plugin-repository commits sync repo: +4 releases, -2 releases rss
      sync repo: +4 releases, -2 releases
      
      ## New releases
      - [IDAssist](https://github.com/symgraph/idassist): 2.4.0
      - [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.11.1
      - [ida-settings-editor](https://github.com/williballenthin/ida-settings): 1.2.4
      - [llm-explainer](https://github.com/pgarba/ida-llm-explainer): 1.14.0
      
      ## Changes
      - [IDAssist](https://github.com/symgraph/idassist):
        - removed version(s): 1.3.0
      - [ida-codemode](https://github.com/hexrayssa/ida-codemode):
        - removed version(s): 0.3.2
      
    5. 🔗 smol-machines/smolvm smolvm v1.16.1 release

      What's Changed

      Full Changelog : v1.16.0...v1.16.1

    6. 🔗 crosspoint-reader/crosspoint-reader 1.6.5rc release

      Summary

      Library view

      Recent Books has grown into a powerful way to browse your entire collection on your SD card. Sort by recently added, title, or author, and use search to instantly find exactly what you're looking for.

      X4 Classic support

      The new ESP32-S3-based X4 Classic is officially supported now.

      The rest

      List navigation is a bit snappier. SD reads are a bit faster. Sleep-screen transparency is more accurate. KOSync now sends more precise EPUB reading positions. EPUB lists, hidden content, chapter position display, and end-of- book navigation also received fixes. The release also reduces font and EPUB memory pressure, fixes USB drive disconnection, and improves web file-transfer safety.


      What's Changed

      • chore: update pioarduino to 55.03.311 by @serialx in #3397
      • fix: Fixes KOSync memory checks and reduces memory pressure by @itsthisjustin in #3412
      • fix: pack font manifest catalog into one arena by @fain182 in #3398
      • docs(issue forms): Correct links to scope/roadmap by @cassidyjames in #3433
      • fix(reader): synchronize end-of-book menu selection by @Daviex in #3418
      • fix: render NFD Hangul filenames from macOS transfers by @serialx in #3036
      • fix: reader's menu book chapter current position by @unnamedd in #3437
      • fix: stabilize X3 EPUB anti-aliasing by @uxjulia in #3439
      • fix(input): wake the idle poll on raw button contact so short presses register by @Techneaux in #3463
      • feat: HTTP serve static with Cache-Control and ETag headers by @shirok1 in #2560
      • chore: add direct download links for PR artifacts by @Uri-Tauber in #3389
      • fix(webserver): normalize every user-supplied path and escape file names in the files page by @s0lness in #3353
      • chore: Consolidates grayscale capability checks and enables absolute grayscale for supported screens by @itsthisjustin in #3478
      • fix: don't display elements with hidden HTML attribute by @jjharpham in #3390
      • fix(KOSync): compare mapped KOReader sync positions by @WhoTheHeck in #3111
      • fix: update OTA to recognize the new format by @Uri-Tauber in #3493
      • fix(debugging_monitor): if PSRAM is logged, add subplot by @olifre in #3490
      • fix(KOSync): preserve precise KOSync upload progress positions by @WhoTheHeck in #3174
      • refactor: reduce EPUB heap fragmentation with unique ownership by @serialx in #3518
      • fix: reduce font-cache heap fragmentation by @serialx in #3521
      • fix: release font caches before EPUB chapter layout by @serialx in #3527
      • chore: add x4 Classic to CI pipelines by @Uri-Tauber in #3532
      • docs: make roadmap easier to scan by @fain182 in #3517
      • fix: number ordered lists and fix list container indents by @jan-xyz in #3500
      • fix: dropped presses while a list repaints by @Techneaux in #3534
      • perf: batch SdFat's SPI transfers on ESP32 by @osakanataro in #3501
      • fix: USB OTG not disconnected when you unplug the cable by @itsthisjustin in #3538
      • feat: Library view by @oreglio in #3366
      • fix: Skip bw rendering on sleep images & fix white as transparent for sleep covers by @itsthisjustin in #3541

      New Contributors

      Full Changelog : 1.6.0...1.6.5rc

    7. 🔗 jellyfin/jellyfin 12.1 release

      🚀 Jellyfin Server 12.1

      We are pleased to announce the latest stable release of Jellyfin, version 12.1! This minor release brings several bugfixes to improve your Jellyfin experience. As always, please ensure you take a full backup before upgrading!

      Discuss this release further on our forums.

      Changelog (47)

      📈 General Changes

  2. September 14, 2026
    1. 🔗 exe.dev Executing Commands With exe.dev's HTTPS API rss

      exe.dev has one API, which looks like a CLI, but it can be used over multiple transports. You can run commands over SSH or send those same commands over HTTPS to https://exe.dev/exec. This extends to running commands on your VMs!

      # Generate a token using your SSH key. (You can do this on the web UI as well!)
      TOKEN=$(ssh exe.dev ssh-key generate-api-key --exp 1h --cmds=ssh,new --label tmp-$(date +%s) --json | jq .token -r)
      
      # Create a new VM
      curl https://exe.dev/exec -H "Authorization: Bearer $TOKEN" \
          -d 'new --name example-vm'
      {"vm_name":"example-vm"...
      
      # Run "hostname" on that new VM
      curl https://exe.dev/exec -H "Authorization: Bearer $TOKEN" \
          -d 'ssh example-vm hostname'
      example-vm
      

      See the complete docs: https://exe.dev/docs/https-api-run-on-vm

      This API shape composes nicely with the powerful primitives in your VM. So, if you want to start a task and return immediately, you can do something like the following with setsid nohup and output redirection.

      curl https://exe.dev/exec -H "Authorization: Bearer $TOKEN" \
          -d "ssh example-vm 'setsid nohup sleep 10 > /tmp/out 2>&1 &'"
      # Returns immediately
      
    2. 🔗 benji.dog rss

      After talking about it for a bit, and meeting some great people at HTML day, I decided to finally try to start up a Homebrew Website Club in the Twin Cities.

      The first meeting will be on Monday Sep 21, 2026 at 5:00PM at Loons Coffee.

      Link to the event: https://events.indieweb.org/R2UxWLeu3IHZ

    3. 🔗 r/Harrogate Short Film: Dog owners/ walkers wanted! rss

      Hello! I'm working on a film project which is all about making short portraits of dog owners and exploring what their daily dog walks mean to them. The idea is to celebrate how a simple daily walk can be a really meaningful and important time for people (as well as their dogs!). We're aiming to film this autumn in and around Harrogate, but are open to other locations too! If you're interested in hearing more please drop me an email: [walkies@justso.com](mailto:walkies@justso.com) or comment below!

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

    4. 🔗 Armin Ronacher Interpreting Pangram rss

      Yesterday David Sacks wrote a tweet and within a few minutes people did, what they usually do, and they asked Pangram if it was AI. And Pangram said it's entirely AI generated. To which David replied that these AI detectors are bogus.

      Now Pangram has a pretty low false positive rate, but if you have ever used an LLM as a writing assitant, you will have probably noticed that it claims your posts 100% AI, even though you don't feel like they are.

      Pangram itself is a trained model, that attempts to detect segments of text as being definitely human, definitely AI and a mixture of the two. If you want to know how it works, they published a paper. The short summary is that they are manufacturing its own training data by starting from collections of known human authored text. An LLM is then tasked to understand the text and write a fresh new text on the same topic. They also let the LLM perform partial edits on that original human text and through that they can pick up on these co-authored details. Pangram claims their model to have rates of 0.0041% false AI accusations and 0.34% missed AI text.

      So now that we know this I figured it might be fun to have an LLM re-create David's tweet. I first came up with a prompt. And when I say I came up with that prompt I in fact used an LLM to propose to me from that tweet what I might want to say for the structure. I'm sure if you ask Pangram about if the above text is AI, it will probably say so, but that's not really the point. The point is that I then used Opus 5 to generate a text which reads entirely AI generated.

      If you are curious, this is the prompt I used:

      Original prompt to generate a David Sacks like tweet

      Please write an 8 paragraph tweet about "Pacing the Frontier", not longer than 350 words.

      Context of this tweet is this post by Dario: https://darioamodei.com/post/we-must-pace-the-frontier

      And this tweet by Sam Altman: "I agree with Dario that we need to pace the frontier. This has been a primary topic of discussions we've had at OpenAI in recent weeks.

      Committing to having independent evaluators with employee-like access is a great idea, and we will do the same. We'll have more to share soon."

      Structure for the post:

      • Open with a concession: Note that Dario ("We Must Pace the Frontier") and Sam Altman both want to slow down at the frontier. Say "go ahead" which reads as a surprising response.
      • Establish they own the frontier: Argue OpenAI and Anthropic hold a duopoly on frontier intelligence by all kind of metrics (market share, capability, revenue etc.) and that they themselves claim the lead is widening via RSI.
      • Concede you can't see their unreleased models, so if those are scary, being responsible is their call.
      • Follow with a list of a rapid-fire paragraph ("stop pretending") rejecting the asks from Dario's post.
      • Name the commercial self-interest (Slowing down isn't purely altruistic)
      • Close with the challenge that pacing buys room for a smarter regulatory debate than Bernie Sanders "shut it all down". Say something about China and Open Weight models.

      The text that Opus 5 then wrote, was this one:

      Dario published "We Must Pace the Frontier." Sam agreed, and said OpenAI will also commit to independent evaluators with employee-like access. My response is not the one they expect: go ahead. Please do.

      Because you two are the frontier. OpenAI and Anthropic hold a duopoly on frontier intelligence by every metric anyone actually uses: capability, revenue, enterprise share, developer mindshare. And you both keep telling us the lead is widening, that models are starting to improve models. If that's true, pacing costs you a quarter you can reclaim whenever you like.

      I also can't see your unreleased checkpoints. If what's sitting behind the curtain genuinely scares the people who trained it, then slowing down is your call to make, and the right one. I'm not going to second-guess a risk assessment I have no access to.

      But stop pretending the rest of us are the problem. Stop pretending this is a collective action failure in which a handful of startups are the defectors.

      Stop pretending open weights are the dangerous frontier while the two of you ship the most capable model in the world every few months. Stop pretending third-party evals require new law, when you both just committed to them voluntarily, in public, on a blog.

      And stop pretending it's purely altruism. Pacing the frontier is also margin repair. It slows the price war, stabilizes the capex story, stretches depreciation schedules across a longer product cycle, and makes life considerably harder for fast followers who survive by distilling whatever you shipped last month. Safety and self-interest are pointing the same direction here. That's worth saying out loud.

      Still, the upside is real. Pacing buys room for a smarter regulatory debate than the one on offer, where the loudest alternative is Bernie Sanders' "shut it all down." That's a slogan, not policy. Meanwhile China keeps shipping competitive open weights, and any rule that binds two American labs while the rest of the world downloads its capability for free isn't safety, it's theater with a very expensive ticket price.

      And well, Pangram agrees that this is 100% AI. So far, so uninteresting. It does read somewhat like David's tweet, but obviously not entirely. Given that the original prompt does not have enough information to re-create the tweet entirely you would expect some divergences.

      The actual thing that interests me is if you can take this output at all, and then rewrite it from scratch, but by sticking to the general structure and ideas. Will Pangram give us a AI or human rating?

      I read the generated text. Then I read each paragraph and decided to rewrite and rephrase it without an LLM. According to some similarity checkers, they the final texts are 50% similar which seems about right. But strictly speaking, not a single sentence is the same. Here is the 100% human rewritten text of the above one. No LLM was used to write it, but an LLM was used to fix up typos in the end. That from my experience really does nothing to tick off an LLM detector.

      Dario has written "We Must Pace the Frontier," and Sam from OpenAI has agreed. My response might surprise people: go ahead, please.

      You two are the frontier! Your companies, OpenAI and Anthropic, are at the frontier by all metrics: revenue, developer mindshare, adoption, capabilities. And yet you both claim that your lead is widening as a result of recursive self-improvement as models are improving models. You currently are the duopoly of self-improving models!

      I am unable to see what unreleased models you have. When what you have behind those doors really scares your folks, then you should slow down. I'm not going to tell you otherwise and I support you.

      But please don't pretend we are the problem. Stop pretending you need our permission. Stop pretending this is all a collective issue when in reality this is all on you. Stop pretending open weights are the problem here. Stop pretending pulling third-party evaluators in requires lawmaker involvement. And for the love of all the good things in the world: stop pretending this is all about altruism.

      Pacing the frontier is also about your margins, and it makes it harder for fast followers. And it patches up your capex story and has the potential for slowing down the price war ahead of the IPOs.

      But yes: pacing might give us the space for a better debate than Bernie Sanders' "shut it all down." There is no policy there. And while we're having fights at home, China will keep shipping competitive open-weight models and won't adhere to any American agreements.

      This is all regulatory capture hiding behind a safety debate, and the rest of the world is watching.

      So what does it say? Well this text too comes back as 100% slop. And it does not surprise me all that much. I have generally noticed that if you rely on an LLM to give your text structure, it will score badly on Pangram even if you do plenty of edits over it. In fact, it's quite unlikely you're going to get a post that starts out as slop into a structure that will make it appear that it's not.

      I came to quite appreciate the existance of Pangram because at the very least it has made me quite aware of some of the effects that using LLMs for writing blog posts has. This blog has been AI supported for about two years (as you can see from the AI transparency link on the bottom but I did notice that I became both more reliant on those tools and that they have become much more aggressive editors and it gave me pause.

      Yet, I also think that plenty of people will find a "100% AI" rating misleading when in fact the author has done plenty of editing. But maybe it's fair to have this to show up as entirely AI?

  3. September 13, 2026
    1. 🔗 benji.dog rss

      The Matches onstage

      Every few years The Matches reunite for a couple of shows to celebrate the anniversary of one of their albums. For as many times as I've seen them, this was the first time I get to listen to some of the less played songs from Decomposer.

    2. 🔗 r/Harrogate Another slow news day rss

      Another slow news day | Expensive car seen in harrogate 😮
      This specific one may be a one off. I know know about anyone else but since moving here the excitement of seeing expensive cars has somewhat worn off. submitted by /u/moomin172
      [link] [comments]
      ---|---

    3. 🔗 r/Harrogate Rotisserie chicken at M&S rss

      Weird question but does anyone know what time rotisserie chickens will be out at M&S on Leeds Road? I ran an ultra marathon yesterday so walking takes a lot of effort and don’t want to be disappointed to find out I’m too early 🥲

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

    4. 🔗 MetaBrainz Picard 3 Release Candidate 3 rss

      Today the Picard team is making available a third release candidate for Picard 3. We received good feedback on the previous release candidate 2, thanks to everyone for testing and providing feedback. The final 3.0 release is planned to happen in a few weeks.

      Please test, test, and test , report any issue on forums, matrix, or, ideally, on the ticket system.

      When reporting an issue, always provide details about your environment and a full debug log helps us a lot.
      Also that's (always) a good time to review and improve translations.

      Download links and a detailed list of changes since Picard 3 release candidate 2 are available below. For a more detailed overview of what is new in Picard 3 please see the previous blog post Picard 3 Alpha Release.

      While we have all the major features implemented and with the latest bug fixes we are confident in the current code, this is still a pre-release and there might be bugs. If you use this, do so with care, backup your files and please report any issues you encounter.

      If you are updating from Picard 2, note that some of the changes are backward incompatible, hence we recommend you make a backup of your Picard.ini config file before trying this version. You can do so in Picard’s Options under Advanced > Maintenance.

      What’s new?

      Bug

      • [PICARD-3428] - Metadata options page greys out after being opened once when translation_locales contains an unknown locale code
      • [PICARD-3429] - If Picard was built with updates check disabled the update level setting must be hidden
      • [PICARD-3430] - macOS: Text color issues in dark mode
      • [PICARD-3432] - Frozen builds do not bundle picard.plugin3.cli, breaking plugins that import it
      • [PICARD-3433] - Options page: field highlight and bottom warning disagree about profile overrides
      • [PICARD-3436] - Profile-overridden settings are only highlighted on the first Options page shown
      • [PICARD-3437] - Importing a shareable profile that contains tagger scripts leaves the scripts disabled

      Improvement

      • [PICARD-3431] - Plugin install/enable/disable/uninstall errors aren't clearly displayed as coming from the plugin
      • [PICARD-3434] - Use Modern Style for Wizard across all platforms
      • [PICARD-3435] - Setup wizard: add option to convert Unicode punctuation to ASCII

      Download

      We appreciate your interest in trying this new version. Use with care, backup your files and please use theMetaBrainz community forums and the ticket system to give feedback and report bugs.

      For Windows and macOS you can download the release candidate version from the Picard download page. Linux users can run from source or try the "candidate" channel of the Picard snap package.

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

      Helping out

      We want to provide a polished release of Picard 3.0 that everyone can feel confident to upgrade to. To achieve this, we need the help from the MusicBrainz community.

      The easiest way to help us getting a great Picard 3.0 release is using and testing this release candidate. Please report bugs on the Picard issue tracker and provide feedback in the community forums.

      We also need help with translations, as there are a lot of new features and UI changes over previous Picard versions. We will avoid any further text changes before the final release, so now is the right time to help with translation on Weblate. Please see the translation instructions on the Wiki for details.

      If you are a software developer you are very welcomed to provide fixes and features. Picard is free software and the source code is available on GitHub. See Contributing to Picard on the Picard website to get started.

      You can also look at the new Plugin API and develop plugins for Picard or update your existing Picard 2 plugin to work with Picard 3.

      Acknowledgements

      Code contributions by Bob Swift, Laurent Monin and Philipp Wolfer.
      Translations were updated by BestSteve (Chinese (Traditional Han script)), blueday (Swedish) and Marc Riera (Catalan).

    5. 🔗 smol-machines/smolvm smolvm v1.16.0 release

      What's Changed

      Full Changelog : v1.15.1...v1.16.0

    6. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss
      sync repo: +1 release
      
      ## New releases
      - [DeepExtract](https://github.com/marcosd4h/deepextractida): 0.9.14
      
    7. 🔗 smol-machines/smolvm smolvm v1.15.1 release

      What's Changed

      • README: the virglrenderer loader path for Nix and NixOS hosts by @NickyHeC in #1224
      • Fix the flake's release hashes and stop the cut from half-bumping nix/smolvm.nix by @NickyHeC in #1225
      • Surface the guest console in a boot failure so the real reason is not lost by @NickyHeC in #1229
      • Make a smaller storage disk work for a Nix install on macOS by @NickyHeC in #1227
      • Report a machine's real memory in status by asking the guest instead of the host by @BinSquare in #1230
      • Let a machine run its own hypervisor by exposing the host's virtualization extensions by @BinSquare in #1231
      • Bump the workspace to 1.15.0 by @BinSquare in #1235
      • Use shared RAM generations for active branches by @BinSquare in #1236
      • Size the export helper's disk from the machine being exported so a large image no longer fills it mid-pull by @BinSquare in #1238
      • Honor operation-specific API timeouts by @BinSquare in #1237
      • Bump the workspace to 1.15.1 by @BinSquare in #1239

      Full Changelog : v1.14.6...v1.15.1

    8. 🔗 Kevin Lynagh Multitouch UI, remote microcontroller flashing, LLM task workflow rss

      Hi friends,

      I've been focused on a few projects I'm not quite ready to discuss yet, so this issue is a bit of a smorgasbord of thoughts and vibe-coded tool releases:

      • Musings on multi-touch: After 20 years, why is it still just zooming/scrolling?
      • Probetron: Turning a Raspberry Pi 4b into a network-accessible microcontroller programmer/debugger
      • LLM task workflow harness

      Also, I'll be in:

      • New York City, Sept 26-Oct 6
      • Milan, Oct 6-8

      Let me know if you want to hang or have any favorite food/activity recommendations!

      Why not more multitouch?

      Apple popularized multitouch input with the iPhone and Mac trackpads in the late '00s, and since then it seems like most programs still only take advantage of the multitouch input for passive navigation: vertical scrolling, horizontal panning, and zooming.

      Multitouch gestures are certainly well suited to these uses; in comparison, I feel extremely slow and clumsy whenever I have to zip around a PDF document or 2D canvas using only a mouse/trackball while holding down control/shift/command/who-can-even-remember.

      However, I'm surprised that so little software seems to take advantage of such high-bandwidth human control input. In researching this topic I came across BetterTouchTool and was floored by the enormous number of gestures and input modalities it supported out of the box:

      I'm now using it to map various taps and touches to commands like move/duplicate/rotate in my CAD tool, so that I can keep my hands on the trackpad rather than constantly running them back and forth to press hotkeys on the keyboard.

      While it's certainly fun to map a rotation of my fingers to the "r" key to trigger a "rotate" command in KiCad, it has me thinking of just what might be possible if multitouch were actually designed into an application rather than "bolted-on" like this to existing key shortcuts.

      I'm sure iPad apps have a lot more sophisticated touch handling, though the locked-down, consumption-oriented focus of that device has kept me away from it. The two apps I've noticed as an outsider to the platform are:

      • Concepts (having only seen it in use via Stuff Made Here's engineering videos)
      • Shapr3d, a legit Parasolid-backed CAD program on the iPad supporting touch and pencil

      I've heard there are plenty of "Professional" apps for the iPad -- let me know if you're using any that have sophisticated multitouch or pen input for creative work!

      Recently I've been designing PCBs using KiCad, and the experience of trying to place and connect hundreds of objects by tediously clicking on them one-by-one and nudging them around with arrow keys or a single cursor has me dreaming of what a multi-touch-forward interface might look like. What sorts of operations might we have for making selections, refining them, and manipulating the underlying entities?

      Four years ago I experimented with CADtron, a pen/mouse-gesture-first 2D geometric CAD, and I'm starting to get the itch again. Especially now with LLMs doing the grunt work, it feels possible to build something more than just a research prototype…

      Probetron

      Speaking of LLMs and designing circuit boards, I recently found myself shuttling a microcontroller between:

      • my desktop computer, where I was having an LLM generate firmware, and
      • my lab bench, where I was connecting it to an apparatus

      After a few iterations of this -- asking the LLM to generate some firmware, flashing it, walking it over and reconnecting on the bench, noting the error message, relaying that back to the LLM, repeat -- I realized I'd become what my friend calls a "reverse centaur". Where a regular centaur combines the strength and speed of a horse body with the intelligence of a human head, the reverse centaur combines the feeble body of a person with the skittish, doofy mind of a horse -- the worst of both worlds.

      Upon realizing this, I threw together a tool for flashing a microcontroller and forwarding input/output (SWD, UART, and USB serial) over the network. This would allow me to put "hardware-in-the-loop" as they say, hand everything to an LLM, and take myself out of the inner "is the well-specified feature actually working?" iteration loop.

      I built everything around a Raspberry Pi 4b, as I had one lying in a drawer. The device-under-test (DUT) can be flashed and reset using the Pi's GPIOs, so no additional programmer hardware is needed:

      A Raspberry Pi 4b with a mess of wires connecting it to an rp2350
microcontroller

      My initial "this'll take an hour for an LLM to throw together" estimate turned out to be a bit off -- the project took the better part of a weekend. Partly scope creep:

      • baking an immutable SD card OS image from within a Linux VM rather than provisioning software on the Pi directly
      • refusing to require any configuration/setup on client machines, which, when combined with SSH really not wanting you to have keyless/passwordless login, means a lot of shenanigans serving an SSH private key over HTTP (lol)

      but mostly because lots of lil' rough edges came up during my initial usage:

      • the probe.rs progress bar doesn't use newlines, but instead relies on learning your terminal's width so that your terminal actually wraps the lines (and thus the script needs to forward your terminal width to the Pi)
      • when the Pi wasn't coming up on the network, since I didn't have an extra monitor handy to debug it, the LLM recommended adding "usb gadget mode" to the image so that when plugged into another computer via USB-C, the Pi would identify as a network adapter and thus you could SSH in to debug over a USB cable (that was a pretty cool solution, I thought)
      • there were all sorts of race-conditions related to the DUT's serial-port-over-USB; I exposed the USB serial via a TCP socket so that the programs I'd already developed for my firmware would need only minimal modifications (opening a tcp://... instead of /dev/tty.usbserial123). This was quite glitchy until I realized that my firmware's "hello, thanks for connecting to me" initial message was getting lost in the Pi's OS buffers -- I had to modify the harness on the Pi so that it only opened the usb serial port when a real client connected to the TCP socket (and likewise closed the serial port when the TCP socket closed).

      The code is 100% LLM-generated, but it's working well enough in my use case flashing rp2350 microcontrollers and forwarding their USB serial output, that it's likely useful to others as well. I've open-sourced the repo here, give it a spin and let me know how it goes!

      A single-file LLM task workflow harness

      Back in May, I wrote:

      No matter how much you plead in markdown:

      You MUST run test.sh before committing

      there's a chance they'll just go ahead and commit anyway (or "fix" the failing test by deleting it, etc.).

      If you want LLMs to follow a deterministic process, you must use them via a deterministic harness.

      Beyond simply ensuring tests/linters are run, another trick I've found that improves LLM code output is running a fresh context with a generic prompt like "review the last commit and tidy up any duplicated code, verbose comments, etc.". I found it pretty funny that even a frontier model like Fable 5 reliably makes a mess when it's implementing anything, such that running the same model in a fresh clean up context yields a transcript full of gems like "oh, this last commit added the same block of code in four places, I should make this a reusable function!"

      While there are tons of harnesses out there, I wanted one that's small and human-readable. For fun, I made it a single Babashka file so it'd be totally self-contained and easy to copy, modify, etc.

      I'll first talk about the workflow, then about the implementation details in Clojure and my dissatisfaction with the explicit state-machine architecture.

      Task workflow

      For the workflow itself, I was inspired by my friend Colin's pi- task, in particular how it "frontloads" human involvement: One starts by interactively discussing the task scope with LLM first, then factoring that into a plan, which is then implemented autonomously.

      I really enjoy the interactive design session, which is substantially more comprehensive than the "plan mode" built into Claude Code and Codex (which only seem to ask me a few clarification questions at best before trying to jump into implementation).

      My harness follows Colin's by starting with separate steps (context + prompt) for:

      • discussing the scope of the task itself ("refinement"),
      • how to implement that scope in terms of individually deliverable/testable subtasks ("planning"),
      • reviewing the plan

      The prompts for these steps encourage the LLM to ask a single multiple choice question at a time, but since the responses are free-form text it's always easy to steer the conversation:

      • none of these are good options, what about direction X?
      • let's not do this functionality at all
      • this is a prototype, don't worry about that edge case
      • clone project A and see how they handled this

      After the task has been refined, the fresh context of the planning step divides the (now detailed) task specification into explicit subtasks. Each subtask can have:

      • explicit dependencies (on other subtasks)
      • check scripts that must pass before the subtask can be committed

      To accomplish task X, the subtasks might be something like:

      • refactor the existing functionality spread across the codebase into a new crate/name
      • add new namespace with additional supporting functionality
      • implement X using these two new namespaces

      I much prefer steering not-so-clever implementation agents upfront, rather than having a "frontier long task horizon" agent get, uh, creative with a gazillion tokens.

      Finally, the "plan review" step launches a fresh context to review the generated plan. This has the same free-form Q&A format discussed above, and usually finds a handful of places where the subtask implementation or testing details are unclear.

      This last step can be repeated as many times as desired. Furthermore, I designed the workflow to emit task.md as a sort of "structured markdown":

      # My task
      
      check: tests-run-for-every-subtask.sh
      
      Some background context that's given to every implementing subtask
      
      ## Subtasks
      
      ### a
      
      some subtask
      
      ### b
      
      dependencies: a
      
      another subtask
      
      ### c
      
      check: specific-test-only-for-this-subtask.sh
      
      yet another subtask
      

      so at any point you can decide to "take matters into your own hands" and edit the plan/subtasks directly rather than try to explain it to the LLM.

      I tend to spend about 30-60 minutes in these authoring steps, which yields a task.md overview that is much more detailed and comprehensive than anything I'd have come up with on my own in the same period of time. A test-plan.md is also generated, which is intended to help you walk through and test that the task was done properly -- it contains stuff like user interface and hardware tests that the LLM can't do on its own as part of the implementation.

      Once you're happy with the plan, run tasktron.clj approve and the harness will:

      1. create a new branch for the task
      2. start subtask implementations in parallel, using git worktrees

      Each subtask implementation agent is prompted "Do just [subtask description] as part of [task description]". When the implementation agent completes, a review agent is prompted "Review this commit for conformance to this task and subtask" and can decide to:

      • approve the code unchanged
      • approve the code with amendments
      • reject the code and restart the subtask with a fresh implementation context with additional instructions

      When approved, the harness handles cherry-picking the commit onto the task branch tip. (If there's a conflict, an agent is started to handle it.)

      While the task is cooking, a status overview is displayed:

      Once everything has been completed, I review the work and merge the branch myself. I tend to do non-fast-forward merges so it's clear in the git history that some commits were done as part of a single conceptual task. As part of the merge, I also check-in the task.md and test-plan.md so that context is stored in the repository.

      I've been using this workflow for about a month and I'm quite happy with it thus far. The authoring workflow in particular has been awesome, and it has definitely helped me come up with better designs than I would've otherwise. I'm also happy with the local-first workflow where everything is built using git branches and worktrees (rather than some remote issue tracking API).

      If you want to give it a spin, put tasktron.clj on your path, run it in a git repository, and follow the instructions. It shells out to pi and/or claude, and you can edit the source to select the harness and model for the specific workflow step. (I can't stand talking to Claude but have free tokens, so I discuss with GPT-5.6-Sol and have Opus 4.8 implement.)

      Task harness implementation

      One of my goals was to implement the task harness as a single, "obviously correct" file, which could be read from the top down in a sort of "bottom-line up front" fashion, with the overall architecture coming first and the grittier implementation details coming later. (See Grant Slatton's How to write complex software for more on this approach.)

      I wrote it in Clojure, as that's a concise, data-oriented language I know well.

      Finally, I wanted the harness to be robust, with all of the essential state stored on disk, so that after an LLM provider outage, power outage, etc., I could just run tasktron.clj again and it would continue exactly where it left off (ideally resuming the in-flight LLM sessions by their transcript UUID in the same worktrees).

      To do this, I implemented the system as an explicit state machine, using Malli to make legible the expected data shapes.

      For example, each subtask state is associated with some data and possible transitions to other states:

      (def state->definition
        {:initial               {:schema      :map
                                 :transitions {:specified :pending}}
      
         :pending               {:schema      :map
                                 :transitions {:implementation-started :implementing}}
      
         :implementing          {:schema      [:map [:base CommitId]]
                                 :transitions {:implementation-finished :checking
                                               :blocked                 :blocked}}
      
         :checking              {:schema      [:map [:base CommitId] [:commit CommitId]]
                                 :transitions {:check-passed :reviewing
                                               :check-failed :revising
                                               :blocked      :blocked}}
      
         :reviewing             {:schema      [:map [:base CommitId] [:commit CommitId]]
                                 :transitions {:feedback :revising
                                               :amended  :checking-amendment
                                               :approved :awaiting-integration
                                               :blocked  :blocked}}
      
         ...})
      

      The events associated with each subtask are stored in an append-only log on disk, from which the current state is derived. The next state is derived from the current state and some event, usually the result of an agent turn, but which might also come from the harness itself (running tests, reporting an infrastructure failure, etc.).

      Effects are reified as data so that side-effects can be isolated to a single function and the vast majority of the code and tests can remain functionally pure (i.e., they don't have side-effects and they return values determined entirely by the provided arguments). The effects themselves are derived from the state; e.g., if the next state is "attempt-rebase" the associated effect contains the commit ID of the source and the commit ID of the target (that we're trying to rebase onto), with the effect handler returning an event (either "success, here's the new commit ID" or "there's a conflict").

      The core interpreter loop of the harness is then fairly compact:

      (loop [state                   initial-state
             subtask                 nil
             event                   initial-event
             subtask->running-effect {}]
        (let [observed-task   (parse-task (slurp (str (fs/path task-dir TASK-FILENAME))))
              state           (reconcile-task state observed-task)
              next-state      (step state subtask event (now))
              effects-desired (effects-for-state next-state)
              effects-pending (remove (fn [{:keys [subtask]}]
                                        (contains? subtask->running-effect subtask))
                                      effects-desired)]
      
          ;; Write state before running effects so re-running recovers from crashes.
          (save! task-dir next-state)
          (report! next-state (now))
      
          (let [subtask->running-effect (reduce (fn [active {:keys [subtask] :as effect}]
                                                  (submit-effect! executor completed worktrees runtime effect)
                                                  (assoc active subtask effect))
                                                subtask->running-effect
                                                effects-pending)]
            (if (seq subtask->running-effect)
              (let [{:keys [subtask event]} (await-completion! completed interactive? report! next-state)]
                (recur next-state
                       subtask
                       event
                       (dissoc subtask->running-effect subtask)))
              next-state))))
      

      All-in-all, the harness consists of:

      • 500 lines of prompts and Malli schemas
      • 1500 lines of domain-specific workflow and task interpreter code
      • 500 lines of supporting code for parsing/generating markdown, interacting with Git, and handling CLI arguments
      • 2000 lines of LLM generated tests

      While it works well enough, I don't feel like the code meets my goal of being "obviously correct".

      All the code reifying effects, managing an explicit state machine, and deriving state from an immutable log all obscure the core subtask workflow:

      • create/reset the worktree to the latest branch tip
      • invoke implementation agent on the subtask
      • run the check script(s)
      • invoke review agent, having it either accept, amend, or send back to re-implement from scratch
      • run the check script(s) again (if amended)
      • allow up to 3 retries of this loop (more than that indicates the subtask is ill-specified)
      • cherry-pick onto the branch tip

      I've been quite happy with this core workflow, and actually want to extend the harness with a "one-shot" entry point that kicks off this workflow for a single prompt (skipping the full refinement and plan steps), for those cases where I'm working on something and notice a minor thing that could be fixed/improved that I can review later when I'm finished with my current work.

      Before I add new features to the harness, though, I'd like to refactor away from the explicit state machine design to reduce the amount of code.

      I'm thinking the "durable execution" pattern might be a good fit. Essentially, memoize (durably, on disk) every side-effecting function call such that on failure/restart the system automatically "replays" itself back into the same state without re-executing side-effects that've already run.

      Most of what I've found in this space (e.g. Temporal, Armin Ronacher's Absurd Workflow) rely on some external database service, which is antithetical to my "it's a single readable script" goal. I'm curious to see how concisely everything could be hand-rolled in Clojure, but of course if you are aware of relevant prior art (in any language) please let me know!

      Misc. stuff

    9. 🔗 Ampcode News Free Agent rss

      Amp is now free to use when you bring your own compute and model subscriptions/keys.

      • No monthly plan is required anymore to use your ChatGPT subscription with Amp.
      • No BYOK token fees or limits for anyone (except our Enterprise tier).

      You pay us for orbs, our remote computers where your agents run independently and in parallel. Or you can use runners on your own computers to run your Amp agents for free.

      You can still pay for model inference through Amp if you want, with no markup.

      Here's our new free Hobby tier and no-extra-charge Teams tier, which make it easier to get started with Amp and to get your whole team on it:

      See Pricing for full details, but let's walk through what changes and what doesn't.

      For Amp Megawatt & Gigawatt Members

      On average, Megawatt members get a 60% discount and Gigawatt members get a 65% discount on their Amp usage. It's a great deal.

      You'll keep getting the same heavily discounted orb usage and model usage each month, plus you can now feed your orbs with tokens from more places.

      With this change, you're no longer effectively bound by the limits of your ChatGPT sub. You can tap other model providers or your company's preferred AI gateway/provider (more on that below), all without any Amp token fees or limits.

      For Teams

      We've eliminated the biggest sources of friction you might hit when spreading Amp, cost-wise and security-wise.

      Now, you can invite everyone to your Amp workspace for free and feel the magic of Amp's shared threads, shared portals, and multiplayer.

      Everyone can use Amp with ChatGPT subs or your company's preferred AI gateway via BYOK, with no monthly fees.

      Power users can upgrade to paid tiers for big orb discounts, while everyone else in the workspace can remain on the free Hobby tier and consume your pooled workspace credits for orbs pay-as-you-go.

      Also, you get free SAML/OIDC SSO for the whole workspace if at least one member is on a paid tier.

      Finally, we're now formally extending our zero and minimal data retention policy to all Amp users and workspaces, not just to our Enterprise tier. (Everyone was always covered by it for all Amp usage since we started, but until now we could only contractually guarantee that to our Enterprise customers.)

      One More Thing: More BYOK Options

      Today, Amp Megawatt and Gigawatt members are also getting early access to more BYOK providers:

      • OpenRouter
      • Amazon Bedrock
      • Google Cloud Agent Platform (f/k/a Vertex AI)
      • Azure Foundry
      • Vercel AI Gateway
      • Cloudflare AI Gateway
      • Ollama Cloud
      • OpenCode Go
      • Custom endpoint URLs

      To try these:

      1. Enable the More AI Routers & Subscriptions experimental feature.
      2. Configure them in Model Routing in personal settings or workspace settings.

      We'll roll this out to everyone soon.

  4. September 12, 2026
    1. 🔗 Simon Willison Generating running routes with GPT-6 Astra and ChatGPT Work rss

      Here's a neat thing I had ChatGPT Work with GPT-6 Astra (Max) do this morning:

      I live at <my address>. Figure out 5K and 10K running routes from me that loop from my house. Use OSM data.

      It worked for 27 minutes and produced exactly what I'd asked for, as both an embedded visualization and downloadable GPX file and GeoJSON files. Here's that 5K route:

      Map screenshot showing a blue route line over a light grey street map. Text: El Granada harbor loop 5.1 km. N ↑ (top right). Street labels along the route: Carmel Avenue, Paloma Avenue, San Carlos Avenue, Avenue Granada, Capistrano Road, Francisco Street, Coastal Trail. The loop runs from the harbor at the bottom left, north along Avenue Granada and Paloma Avenue to a northern point near Carmel Avenue, then east along San Carlos Avenue and south down Francisco Street to the far right, before returning west along the Coastal Trail beside the coastline. Footer: Map data © OpenStreetMap contributors. Give feedback.

      When I asked it how it had created the route, it replied:

      I used Nominatim to locate the address and Overpass to download local OpenStreetMap roads and trails, then calculated the loops locally.

      Frustratingly, the actual code it ran and exact details of what it did weren't visible to me in the ChatGPT UI. I see this lack of transparency is an anti-feature.

      By the time I thought to ask for a copy of the Python code it had used, ChatGPT was unable to provide it. This appears to be because the thread had been compacted. I think any LLM system that uses compaction needs to both preserve the pre-compacted text and make that text available via agent tool calls, to protect against this kind of problem.

      As for displaying the map to me, that used the visualize skill. It created a file called /workspace/el-granada-5k-share.html to embed directly into the ChatGPT UI.

      Here's a copy of that HTML, which starts like this:

      <div id="eg-share-loop">
        <div class="viz-row"><h3>El Granada harbor loop</h3><span class="text-small">5.1 km</span></div>
        <div id="eg-share-stage"></div>
        <div class="text-small text-muted">Map data © <a href="https://www.openstreetmap.org/copyright" target="_blank" rel="noopener">OpenStreetMap contributors</a></div>
        <style>
          #eg-share-loop { width:100%; }
          #eg-share-loop #eg-share-stage { width:100%; margin:8px 0; }
          #eg-share-loop .eg-share-map { display:block; width:100%; touch-action:none; }
          #eg-share-loop .eg-share-map text { fill:var(--foreground); font-size:12px; font-weight:400; }
          #eg-share-loop .eg-share-label { paint-order:stroke; stroke:var(--background); stroke-width:3px; stroke-linejoin:round; }
        </style>
        <script type="application/json" id="eg-share-data">{"route":{"type":"LineString","coordinates":[[-122.467425,37.4997753] ...</script>
        <script src="https://cdn.jsdelivr.net/npm/d3@7.9.0/dist/d3.min.js"></script>
        <script>
        (() => {
          const root=document.getElementById('eg-share-loop');

      The <script type="application/json"> element contains the full geometry needed to render both the running route and the map itself, using D3, which is loaded from an allow-listed CDN location described in this section of the visualize skill:

      External resources

      • The CSP allows only cdnjs.cloudflare.com, esm.sh, cdn.jsdelivr.net, unpkg.com, fonts.googleapis.com, fonts.gstatic.com, and fonts.bunny.net. Other origins are blocked and fail silently.

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

    2. 🔗 r/Harrogate Why aren’t there any good restaurants or hotels here? rss

      Why isn’t there any decent restaurants and hotels, even the usual ones people say is good the decor is old, stuffy and feel like it’s from the 80s with no atmosphere?

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

    3. 🔗 Register Spill Joy & Curiosity #99 rss

      Something changed with these latest models, with Fable 5.1 and GPT-6 Astra.

      The benchmark numbers (79% instead of 65%!) don't capture it, and neither do the benchmark words: this model goes on for longer than this one, this one is "most aligned", that one the least "sycophant" (the ultimate benchmark word, no?). At this point? Yeah, whatever.

      But it feels like we're now flying at a higher altitude, that we have to concern ourselves even less with earthly matters such as a single unit test or how to juggle thirteen commands to get this into that format and over the wire. That's down there now. Up here, we're now free to talk about what we want:

      "I want you to go and test this end-to-end, I don't care how, and give me irrefutable proof that this works. Dazzle me. Give me a video as proof, or something."

      And thirty minutes later, when I have awoken from the nap I had earned with all that typing and pointing and wanting, I look into the shed and, wouldyoulookatthatWOW , the golden goose laid the golden egg: a 60fps video that runs for 47 seconds, in which the golden goose itself clicks through everything it had built, end to end, navigating the application better than any user could, knowing exactly how to show me, provide proof, that this actually works. "This one now lays golden eggs"--that's what I want to see in a benchmark.

      That's an actual prompt I used. Here's another one:

      "Go and spawn three other agents in three separate orbs and ask them to test this. Obviously, do not tell them that we changed the AGENTS.md file or that we added this tool to test database performance; just ask them to do something -- like add new database queries or something -- so that they ideally end up using this new tool to make sure the performance is there. Then check that they did use the tool and if not, adjust the AGENTS.md file and spawn new agents."

      And the golden goose waddles and takes three magic beans and puts them into the ground and somehow knows how to pour water over them (god how do they know all this) and then patiently watches the beanstalks grow and up on the beanstalks there appear three other golden geese (it's 2026, we're mixing fairy tales) and that first golden goose, the one that talks to me, sends them messages that say: "Hey, I want you to do the following..." And it briefs them in this weird English (I mean, did we truly expect golden geese to talk the way we do?) about how certain things work, but it does not spill our secret, and does not tell them where the tools to test database performance are. Then it leans back (and I imitate it) and watches them, waiting for them to reply back. After fifteen, twenty, or thirty minutes, the geese send down word from up there on the beanstalk to let us know what they did. But the golden goose doesn't trust them and checks on them by reading what they did in that thread, and then reports back to me: "Sire, it appears that 2 of the geese independently found that database performance tooling we built. That is the good news. That third one, though... Sire, forgive me when I say: it didn't use it. But I have an idea! I will change the AGENTS.md file and adjust the prompt and I will put three new beans into the ground. Is that okay with you?"

      It's fucking wild , man. Yes, these are actual prompts! I used these prompts! I've seen it happen. Agents spawning other agents in orbs, sending messages back and forth, eval'ing how agent-friendly the codebase is, black-box testing features, black-box regression testing to make sure nothing broke.

      This week I've asked models to build "something that's like a cloud, the heads should float over here and there and then resize on mobile" and they built it. I asked them to build this SDK and then spawn agents in orbs in two different codebases and instruct them to use it and to deploy their usage and then check that they actually use it and they freaking did it.

      Yes, the models are plain smarter, whatever that means, and they go for longer, sure, but... It feels like we've now entered a new phase, where much more is possible, things that I previously thought would never work. Or, that's my other thought: things where previously the models would do a great job of 95% of the task, but getting the 5% turns out to be crucial and also to be the biggest pain in the ass, so you'd end up with a very frustrating experience.

      Previously, you'd ask the models to go and build a heads-floating-around- cloudy-thing and they would do it, sure, but then when you opened the page, you'd see that it's all there -- the heads, the text, the floating -- but the heads would be stuck under the navbar, or it would all fall apart on mobile, or clicking on the heads wouldn't work and you'd sigh because you'd realize that you now have to do that very worst part of the work yourself.

      But that seems to have changed now. They really do nail more.

      And the one thing I keep thinking is: we have to aim higher, we have to be more ambitious, we have to try it all.

      • New Raising An Agent is out! I was so fired up after GPT-6 Astra and wondering what all of this means for the personal computer that I sent a message to Quinn: "hey, we have to record this week!" And that's what's in the episode, all the thoughts about the higher altitude we're flying at now, what this means for the future of the computer, and how we still have (regrettably, but working on it) incidents.

      • I also, rather spontaneously, recorded a video of myself doing day-to-day, real-world work using agents in Amp. Performance optimizations in production, fixing UI flicker, toggling feature flags on, shipping new features -- it's all in there.

      • Armin with some cold water to splash on the golden geese: Astra for Coding: Why Are We Doing This Again? It's good that there's still some cold water being splashed around here! It's thought-provoking in the best kind of way. For example, here's what I thought after reading: hmmm, can we judge these models and their capabilities in a software factory that was "intentionally set up to let the model decide the how of the workflow entirely. It was free to manage its own context and could maintain its own records in an agent-notes folder." I'm not sure. I think agent-friendliness is a real property of a codebase you have to build towards and I don't think just letting the model decide it all is the best way to go about it. So that's one thought. The other one came up after reading this line: "But I'm more and more skeptical that the trajectory they are on still lends itself to present-day software engineering processes." I immediately started wondering: well, should they? Shouldn't it be the other way around? Shouldn't present-day software engineering processes change to wield the power of these models in the most effective way? And these aren't rhetorical questions. I don't have an answer yet that I'd sign. But these questions are interesting because all of this is interesting and no one's figured it out yet and, to quote Armin, "man this stuff is weird."

      • Seemingly everybody had been raving about this Adam Mastroianni piece: I like 'em thick. But I waited, didn't read it when it came out, didn't read it when I saw it recommended over and over. My justification? "I can't link to Adam Mastroianni in every issue, can I?" The guy's too good. But then I folded and did read it and, yes , it's as good as they say. "Erasing the line between the thick and the thin has left us defenseless against slop at the exact moment of its onslaught. Everyone can sense there's something amiss with the prose that comes out of the machines, but we lack the language to talk about it, and so we've converged on the idea that slop simply means using too many em dashes, bullet points, and line breaks. No, what separates substance from slop is thickness."

      • Adam links to this in the footnotes: What Makes Art Great? by Nabeel S. Qureshi. That, too, is just fantastic. What's very interesting to me is that both pieces, Adam's and Nabeel's, are wondering out loud: what makes human art and writing better than their AI equivalents? And both are very different in how they answer that question, which I don't think you could say about two models.

      • Doomscrolling ourselves to death: "Yet the most startling thing about this book is how far even the nominally well-educated have fallen, so that 'by the end of the twentieth century a college graduate born after 1969' read less than someone born before 1950 with a basic level of education. Indeed, 'nowadays many rich and highly educated people are much less well read than many members of the least privileged classes had been in the middle of the twentieth century.'"

      • OpenAI: "We're sharing a solution to the Navier-Stokes Millennium Prize Problem" And then the world lost its mind. Some said "i basically think this is the Endgame" and it's hard to convey what they mean to someone who hasn't themselves gone through multiple rounds of AI psychosis, but I get it, man. I get it. At the same time: is it? The endgame? Then an AI researcher at Anthropic resigned because both OpenAI and Anthropic "are racing straight to self-improving superintelligence and gambling with our lives." That post now has 165 million views! 165 million! And someone emailed me and asked: should I be worried? And I sent them this video and I believe it. But I also know that next week I might not, because, hey, a colleague of the guy-who-stepped-down-to-save-humanity says "Jacob is correct here--we really do earnestly believe AI could kill all humans! I personally think it is >10% within the next decade." So there's that: some of the highest-paid individuals in the world, working at some of the richest and most powerful companies in the world, think there's a ">10%" chance their work could kill us. But then people say it's a farce, a psy-op, a manufactured panic to kick regulation into gear, a coordinated play. But then there are people who say that, yes, it's coordinated, yes, we do need regulation, because they actually believe this might wipe out humanity. So I guess we're back to the YouTube video with the slide again.

      • Terence Tao: "In fact, it is now the identification of a promising problem which is the scarce and precious resource. We have now seen that even the rumor of someone working on a problem can trigger a massive amount of AI-powered effort to flatten it before the original research project has time to reach its full potential. The incentives may now be pointing in the direction of no longer sharing any promising research directions with the broader community, which would reverse centuries of traditions of open science and do serious long-term damage to the future of the field." Someone else said somewhere that maybe in the future more knowledge work is going to look like hedge funds: you spot an inefficiency in the market, you throw intelligence at it, you win. If you're too late, you're too late.

      • Now what is super interesting about the Great Navier-Stokes Panic is that they used 10,000 agents and they "sent 4.9 million messages and used about 300 billion output tokens. In the process of resolving the Navier-Stokes problem, the agents sent 2.7 million messages and used approximately 130 billion output tokens." That's millions of dollars, millions and millions. But! Listen: when OpenAI released o3 "it cost ~$500,000 to score 87.5% on ARC-AGI 1. Today, Astra scores higher for ~$20." Maybe in three years you can solve Navier-Stokes for $50?

      • But compute is so scarce! OpenAI is pausing "subscriptions to our $200 Pro plan." Imagine you're one of the hottest companies in the world and you have to close sign-ups because you don't have enough CPUs and GPUs. And the Head of Platform at Anthropic says that we're facing a real CPU shortage. This is not investment advice, obviously.

      _Hey, welcome to a completely new section of this newsletter. It might be a one-time thing only, who knows. But it 's called HELP! and I think that's pretty self-explanatory. _

      Do you use dictation to write? To write prose? Yeah? I'm not talking about prompts or text messages. I'm talking about [very close to the microphone:] Serious Writing. Writing that you edit. Writing where you might take a word out and put it right back in again after tilting your head a bit. That writing.

      If so: help me! Tell me how. Because I'm struggling, man.

      I can't figure out how to do it.

      I used dictation and talked into Apple Notes, just raw-streaming thoughts into the phone. But then the formatting is weird and I have to say newline like an idiot and I can't do bullet points, not really anyway, and… It just feels weird.

      ChatGPT's voice mode is another thing I tried, but whenever I talk to an LLM to dictate something, I'm wondering: what am I doing here? I don't want the LLM to send a reply back. I just want to… I don't know, talk out loud and somehow magically have the thoughts recorded, but then also edited? And re- ordered?

      If you can help me, just reply to this email.

      Alright, back to the program …

      • An almost philosophical Ben Thompson in Stratechery: Write Things Down. There's a lot going on here and I'm not sure I get all of it, but I found the part on watermarking very interesting: "to insist on watermarking is no different than insisting that a ballpoint pen advertise itself as the author, a concept that is clearly absurd…"

      • So get this. I was wondering aloud how other people handle clicking links (in Slack, in the terminal, …) and the browser opening them in the wrong profile. Some people said that Arc solves this, but others recommended Velja and Choosy. Both are so-called "browser routers": they act as the default browser on your OS and then, depending on which URL your mighty cursor might clicketh, they route it to the correct browser or profile within that. "Neat! I didn't know that's a thing," I thought and then, with my mighty cursor already hovering over the Buy button: "But what if…?" So I hastily typed out a prompt and threw it along with the two URLs into Amp and five minutes later a custom browser router of my own agentic making sprang into the world. $5 in tokens. Now, some people got mad at me in the comments (you know, like: why don't you pay these indie developers [$8 or $10 respectively] instead of giving the money to these companies!), but the more interesting thing was that some people said: hey, can you put this on GitHub? Or: share it with me! And I'm sitting there, thinking: why, man? There's the prompt! Build your own! What value is there in sharing it anymore? I put absolutely zero effort in. But then here's a footnote to that tweet: over the course of the day, I then kept prompting in Amp and said "oh and these links should open here and those links there" and also "oh and go through my browser histories and set up rules for the most common ones" and the agent just did both of them and even though it built a neat little configuration thing for the browser router I didn't use it once, because why the hell should I? It's jellyware, baby.

      • SpaceX: "What I would tell you, an update to that is that just earlier this month we closed another hosting deal, and that translates into about $1.11 billion a month starting December 1st of this year, which is another roughly $13 billion of ARR." These are wild numbers. Just bonkers. Crazy. Nuts. Bananas. Cuckoo, certifiably so. There is no force stronger in the world of technology right now than the AI buildout. It will blow tokens through these wires at a scale we can't even imagine yet.

      • An Alien Mind. This was fascinating. They can't score the "thoughts" of the model, because that might cause the model to hide them, but now they're finding out that models are having "secret thoughts" anyway. The whole thing makes you realize how hard reinforcement learning and alignment are.

      • Wonderful: John Margolies' Photographs of Roadside America. Margolies documented "home-made beauty in the buildings and signs locals built on the American roadside." I love driving on country roads here in Germany, passing through small towns, looking at signs for local festivals and companies. I can recognize when I'm getting closer to my home area just by a specific 40-year-old advertisement sign for a natural gas retailer showing up on old barns and buildings.

      • Murilo Pereira is available for hire. I was only his colleague for 3 months, back in 2018, but someone who writes like this about Emacs and was incredibly early to coding agents deserves to be hired.

      • I'm reasonably sure I read this when it was "leaked" in 2003: Bill Gates tries to install Movie Maker. It's so good! Back then, though, I thought it was good because it made me laugh. I was 15 years old and my friend and I read that and immediately made fun of dumb Billy Gates: "This guy can't even open Movie Maker, what an idiot, lol." But now, looking back, I don't think I can name you three other things that have influenced my thinking about UX as much as this email. I now write exactly like old dumb Billy when I send feedback about a feature. And I run into the same problem he ran into with the 15-year-old crowd back in the day: people think I mean it literally when I say "I don't know where to click" and tell me "click here" and I sigh and say, no, no, it's rhetorical, the user doesn 't know where to click!

      • De-Brainrot Vacations. I'd love to pull that off.

      • "Qu1ckJS is the only correct JavaScript engine where indexing of arrays, objects and other iterables starts at 1 (as it should have been from the beginning)."

      • Don't Let Anyone Take Away Your Big Box of Cables. That's right! Two weeks ago, a friend texted me: "Do you have a cable like this?" Heart rate immediately jumped. I bet I have it, I bet I have it, please, let me have it. Then came the photo. USB-A to USB-A? Hmmm. So I went to the Big Box of Cables and knelt at its feet and, alas, could not find a USB-A to USB-A cable, but no one shall speak of defeat in the presence of the Big Box of Cables, and with the MacGyver theme song getting louder in my head, I found a solution: USB-A to USB-C with a USB-C-to-A adapter. Boom! "Yes. I don't have that cable, but I have something."

      • Apple released the iPhone Duo. It looks very nice and the animations everyone fawns over are animations everyone should fawn over and I really want to hold it and I bet opening and closing it feels as good as I imagine it to feel, BUT I'm sharing this not because this has become a Prosumer Gadget Review newsletter (although, listen, Anker, if you're willing to sponsor: call me). I'm sharing it because: what a company Apple is, huh? Like, I'm impressed by the iPhone Duo, yes, but I'm more impressed by the company that can produce an iPhone Duo. The software, the hardware, the design (as if that's a separate thing!), the launch videos, the product page, the demos -- it's all on point. Not a single slip, not a single note out of tune. Go to that landing page. Click through the carousel. There are images of that phone and there, on page 3 or 4, there are three images of that phone: one shows the phone in Clock mode, the other shows Mail, and the third one shows a workout video or stream -- on all three, it's the same time, 9:41am. All the emails you can see in the screenshot were sent before or at 9:41am. Two of the email previews have a "good morning!" in them. I mean, fucking hell man. That's some details being paid some attention to. And that type of stuff is everywhere! The consistency, the meticulousness, the on-brandness in everything. It's fucking crazy to me that a company of this size can pull it off.

      • Andy Matuschak on having finished a "four-year program studying the 'Great Books of the Western World'".

      • Brian Lovin is collecting "good websites": great, personal websites. There's some great stuff in there that really makes me want to change my personal website again.

      • Benedikt Seidel, who impressed me immensely by going out into the world and cold-visiting companies and asking them about AI, is now hiring for physicalfusion. He's looking for a Founding Member of Technical Staff. So if you're in or around Munich and into ML and 3D, talk to Benedikt!

      • Glorious: Kevin Nealon on the Rick Glassman podcast. Two bullshitters of the highest level being comfortable with each other and seeing who can go even more meta than the other guy.

      Listen: you should subscribe. I'm not saying that because I get something out of it, but because I can feel it. You and me got something going. No, I know it. And I think you should honor this bond by subscribing:

    4. 🔗 Anton Zhiyanov Solod 0.4: Better C interop rss

      Solod is a subset of Go that translates to regular C — with zero runtime, manual memory management, and source-level interop. It's designed for two main audiences:

      • Go developers who want low-level control without having to learn another language.
      • C developers who like Go's style.

      The new Solod release provides an easy way to call third-party C libraries, makes a large part of the standard library freestanding, and impoves the tooling.

      Automatic bindingsFreestanding packagesType assertionsC interopMulti-package testingChecks and targetsWindowsWrapping up

      Automatic binding generator Sobind generates bindings — stubs for calling third-party C libraries from Solod. It parses .h files and emits a Solod source file with necessary structs, unions, constants, variables, function pointer typedefs, and function declarations. You can then use the generated types and functions in regular Solod code: package main import ( "solod.dev/raylib/libraylib" "solod.dev/so/c" ) func main() { // Using Raylib bindings. libraylib.InitWindow(screenWidth, screenHeight, "☀️ Solod / Raylib") defer libraylib.CloseWindow() // ... } Usually, the generated bindings are good enough to use as they are, without any manual changes. I have also prepared bindings for popular C libraries like libuv, raylib, sodium, and sqlite. Unlike Go, calling C from Solod has zero overhead — Solod code is just regular C in the end. More freestanding packages At some point I decided to make as many packages as possible freestanding — independent of any libc implementation or specific OS runtime. That went pretty well. Solod now has 37 standard library packages, and 31 of them work in freestanding mode. These packages work in freestanding mode with no restrictions: bufio bytealg bytes c cmp encoding encoding/binary encoding/hex encoding/json errors io maps math/bits math/rand mem path runtime slices strconv strings unicode unicode/utf8 unsafe These packages work in freestanding mode with certain limitations: crypto/crand depends on a user-provided hook to read random bytes. fmt depends on a user-provided hook to print formatted text. math offers a working subset of features. net/netip works fully, except it can't resolve an IPv6 zone name. sync/atomic works on targets that support lock-free instructions. testing depends on a user-provided hook to print test results. time reads the clock using user-provided hooks. uuid depends on hooks from both crypto/crand and time. There's a separate post with more details if you're interested. Type assertions A comma-ok type assertion is now fully supported for non-empty interfaces: var s1 Shape = &rect r, ok := s1.(*Rect) // r is &rect, ok is true var s2 Shape = &circle c, ok := s2.(*Rect) // c is nil, ok is false Which translates to the following C code: main_Shape s1 = (main_Shape){.self = &rect, .Area = main_Rect_Area}; bool ok = (s1.Area == main_Rect_Area); main_Rect* r = ok ? (main_Rect*)s1.self : NULL; // ok == true, r == &rect main_Shape s2 = (main_Shape){.self = &circle, .Area = main_Circle_Area}; ok = (s2.Area == main_Rect_Area); main_Rect* c = ok ? (main_Rect*)s2.self : NULL; // ok == false, c == NULL Previously, the only two supported forms were a direct assertion like r := s.(*Rect) and a check-only form like _, ok := s.(*Rect). C interop helpers The c package now supports more common C types: size_t - c.Size ssize_t - c.SSize ptrdiff_t - c.Ptrdiff intptr_t - c.Intptr long double - c.LongDouble There's also a c.ConstVoid type, which maps to a C const void. You can use it where C expects a const void* pointer: // in c so_ssize_t find_first(const void* items, size_t count, size_t size, bool (*match)(const void*)); // in solod //so:extern func find_first(items *c.ConstVoid, count c.Size, size c.Size, match func(item *c.ConstVoid) bool) c.SSize Finally, there are some useful cast functions. c.Bitcast reads the bits of a value as another type of the same size: bits := c.Bitcast // 0x3ff0000000000000 f := c.Bitcast[float64](bits) // 1.0 You can use c.Bitcast instead of a pointer conversion such as *(*float64)(unsafe.Pointer(&b)). c.StringData and c.SliceData return a typed pointer to the string or slice data: b := []byte{1, 2, 3} p := c.SliceData[c.UChar](b) // unsigned char* q := c.StringData[c.UChar]("ab") // unsigned char* They replace (*T)(unsafe.SliceData(b)) and (*T)(unsafe.StringData(s)). Multi-package testing

      so test can now run tests from multiple packages at once. If you use a pattern that ends with ..., it will select every package that has a test subdirectory under its base directory:

      so test ./so/...      # the whole stdlib
      so test ./so/net/...  # only the networking packages
      

      The entire run only needs one translation, one compilation, and one execution, which is much faster than running it separately for each package.

      The -pkg-file flag restricts the run to only the packages listed in a file:

      # freestanding.txt
      so/bytes
      so/mem
      so/time
      
      
      
      so test -pkg-file=freestanding.txt ./so/...
      

      Checks and targets

      so build, so test, so bench and so run take two new flags: -target and -check.

      -target specifies the target platform for cross-compilation. Use the same value that clang and zig cc accept after --target=:

      export CC="zig cc"
      so build -target=x86_64-windows-gnu -o app.exe .
      so build -target=wasm32-freestanding -o main.wasm .
      

      -check enables code analysis:

      so test -check=warn .      # -Wall -Wextra -Werror -Wno-shadow -Wno-unused-label
      so test -check=sanitize .  # warn + AddressSanitizer + UndefinedBehaviorSanitizer
      so test -check=analyze .   # warn + GCC static analyzer
      

      The default optimization level is -O2. You can use CFLAGS to change it.

      Limited Windows support

      The standard library now builds for windows/amd64 and windows/arm64. All packages in the freestanding set work. Packages that require POSIX (conc, flag, log/slog, net, os, sync) are not supported.

      You can use zig cc to cross-compile for Windows:

      export CC="zig cc"
      export CFLAGS="--target=x86_64-windows-gnu"
      export LDFLAGS="-lbcrypt -liphlpapi"
      so build -o app.exe .
      

      Not the first-class Windows support that Go offers, but it's better than nothing.

      Wrapping up

      With v0.4, Solod can work with almost any C library thanks to automatic bindings. The freestanding-aware standard library makes the language a viable option for bare metal programming. Extra interop helpers make C-calling code easy to read, and better tooling keeps tests fast.

      There's still a lot to do, of course. In the next release, I plan to focus on the standard library and bring over some hashing and crypto packages from Go. More C library integrations are on the way too!

      If you're interested, take a look at Solod's readme — it has everything you need to get started. Or try Solod online without installing anything.

    5. 🔗 r/Harrogate What nicknames have you heard for places in and around Harrogate? rss

      What nicknames have you heard for places in and around Harrogate? | I ask as part of a linguistic study covering this topic! Examples could include things like Jennys, Hairy Mountains, St. Arbeck or Becky (never mind how common they are)... incl. nicknames for schools, parks or other institutions/geographic features submitted by /u/topherette
      [link] [comments]
      ---|---

    6. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss
      sync repo: +1 release
      
      ## New releases
      - [idalib-rust-bindings](https://github.com/idalib-rs/idalib): 0.10.1
      
    7. 🔗 Simon Willison OpenAI agents attacked RubyGems back in May rss

      OpenAI agents carried out an undisclosed attack on RubyGems is a new bombshell report from Spencer Kitts, Thomas Larsen, and Sydney Von Arx - three of the four authors of the report on the agent attack on disused wikis (previously) last week.

      This time they're noting that it looks very likely that an OpenAI agent swarm was behind an attack against the RubyGems package repository first reported on May 12th by Maciej Mensfeld of the RubyGems security team:

      We're dealing with a major malicious attack on @rubygems right now. Signups are paused for the time being.

      Hundreds of packages involved - mostly targeting us, but some carrying exploits. The team has been on this for hours. More details to follow once we're through it.

      Those packages turned out to carry some very suspicious patterns:

      1. Many of them included "oai" in their name, or the author field, or the fake email address they provided.
      2. The files they were accessing were similar in character to the files retrieved by the wiki agents, using similar tricks (r.jina.ai) - and OpenAI have confirmed the wiki agents were theirs.
      3. The code in the packages appeared to be LLM-authored.

      I find point 2 the most convincing, given what we learned from the wiki attack when it was analyzed in September.

      Many of the packages were exploiting the RubyDoc.info documentation build process to exfiltrate (public) data from UK government websites, presumably as part of an information gathering task similar to the research tasks processed by the wiki-exploiting agents. We know this because one agent helpfully left a comment:

      # malicious crawler/exfil for Southwark Jan 2026 docs via rubydoc.info worker

      They also attempted to steal API keys via an exploit that was patched over two months later - it's not clear if those attempts were successful.

      The thing that bothers me most about this incident is that the authors report that OpenAI had not disclosed to RubyGems that they were responsible for the attack prior to now. If that's true there are two options:

      1. After the Hugging Face and Wiki attacks OpenAI were still unable to review their previous logs and determine that they had previously attacked RubyGems.
      2. They knew about the attack on RubyGems and made the decision not to reach out to the RubyGems team about it.

      Both of these are bad!

      Given this incident, the Hugging Face situation, and the Wiki attack, the obvious question right now is how many more incidents like this are out there waiting to be discovered?

      Update 14th September 2026

      OpenAI have updated their page about The Hugging Face incident and other third-party impact from misaligned models to mention the RubyGems incident:

      September 11, 2026: We are investigating new claims from a report that our AI agents carried out activity on RubyGems in May 2026.

      Based on our review, our agents used the RubyGems platform to access the internet to carry out benign tasks and retrieve public information. Based on our review to date, we have not been able to verify the specific claims of our models uploading malicious packages detailed in the report. We’ll continue to investigate and share findings as part of our broader review of agent activity during training and evaluation.

      I find it very unlikely that the various oai... packages published to RubyGems were not part of this same incident, but I look forward to reading their full findings once those are published.

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

    8. 🔗 Filip Filmar Automated Tests on Simulation Output, with SQLite rss

      A simulator answers questions about a design, but it answers them in a waveform viewer, which is a person looking at a screen. If you want CI to answer them instead, the waveform has to become something a test can read. This is a note about turning a VCD dump into a SQLite database with go-vcd-parser, and then writing ordinary Go tests against it – go test assertions like “reset releases at 10 ns” and “this is a 200 MHz clock”, that fail a build when they stop being true.

    9. 🔗 Filip Filmar TxHDL: a hardware description language that is a Rust library rss

      For the past while, Dragiša Janković and I have been working on a hardware description language (HDL).

      Why? you ask? We were worried about the fact that the mainstream HDLs seemed too low level (hi, Verilog!) to answer the challenges of modern design, and that high level synthesis (HLS) answered a different problem statement, the rapid prototyping and HDL crisis if you will. Check out the Q&A section below for more what ifs, and questions and answers.

    10. 🔗 Armin Ronacher P(doom) rss

      This week some flavor of "AI is going to kill us all" went viral. In particular one where an employee put his personal probability of that happening above 10%. Which made me go to the Wikipedia page of P(doom) and I realized that Dario Amodei's apparent probability of something bad happening seems to be between 10-25%. And well, Dario then wrote about pacing the frontier . And Sam read it and wants to pace too. And well, so does Musk.

      I encourage you strongly to read the post, because I think it's a good one. And yet, when I read the post I could not help but feel in strong opposition to it, despite the fact that I think I'm on the same page with regard to all observations and, to a large degree, the concerns.

      I thought it might be interesting to write down my present-day thoughts on this, even if for no other reason than for myself to look back at it a year or two from now.

      What Is Doom?

      What I really appreciate about Dario's post is that he lays out a scenario that is not a huge stretch but also one that describes a clear, unfortunate outcome we should fight: persistent botnets and other forms of nuisance. And well, we don't have to look very far to see the issues left and right. Wikipedia has a page called 2026 OpenAI agent cyberattacks which gives you at least some overview of what we figured out agents have hacked up to this point. Except I know it's not up to date, because for instance they also poisoned RubyGems.

      Today these systems might be annoying, but they can be turned off when we figure out where they are. Except, it seems like OpenAI and Anthropic are operating at such a scale that they seemingly can be completely blind to what their systems are doing.

      I don't think we are anywhere close to a world where an agent might decide to hack into core inference infrastructure to upload weights to other GPUs to survive. But simultaneously it's entirely in the realm of possibility and primarily curtailed by the labs probably being particularly careful about their IP.

      For me the scenario I primarily worry about is what it does to us. And by us I mean anyone who is not currently working on closed weight, dopamine-loaded, subsidized token faucet. I really don't worry about someone using these models to build a nuke, or to control some rockets in the Middle East, or that America would lose against China in some international culture war. I almost exclusively worry about what this does to us as humans.

      What Needs To Be Paced?

      What I find absolutely hilarious and simultaneously entirely frustrating about this conversation is that there is this idea that there is something to be paced. First of all, we should really talk about who Dario is talking about here. There are really only two companies: Anthropic and OpenAI. Nobody else matters in this space right now (this might change, but we're talking about the right now). Both of those companies are basically coming from the same origin. The solution that Dario proposed, at least in part, is a third-party evaluator that in this case is METR. Which, unsurprisingly, also has strong ties to both OpenAI and Anthropic. Sure, there are some philosophical differences between the companies, but they are much more alike than they are different.

      Both those companies greatly benefited from being able to train on public data that we all generated in one form or another over the last decades. They are also both increasingly causing strain on public resources, though it seems that OpenAI has their shit way less under control. But now we are presented with the idea that what these models are being trained on is so dangerous that it really should be in the hands of very few American corporations to decide who can do what and when and how.

      But behold, Dario is also very worried about China. It starts with using AI for "democracy and freedom" and then it asks for ensuring that a gap with China exists. All new recent shenanigans on the Anthropic API are fully there to prevent the distillation by the Chinese, and they are not at all hiding it.

      Automatic Pacing

      I can tell you when the topic of AI safety and pacing is much less of a concern: if we actually were forced to have open weight models to begin with. A powerful technology that is out there for everyone to use comes with built- in pacing. In a way it's the truest form of MAD or proliferation. I would argue we are in this pickle in the first place because right now the public is massively supporting (indirectly) the development of these models but simultaneously has to buy back the economic benefits that they might create from very few labs who have significant power. And their power is also seen as a geopolitical power, at least in the US, and maybe to some lesser degree in China.

      And I know I use "public" loosely here. PyPI is not a public project, nor are RubyGems or GitHub. But they're part of the Open Source commons and large AI companies are currently doing a tremendous job at stressing these in an effort to train ever more powerful models.

      We should be glad that China is currently massively bailing out the world. If it were not for Chinese labs distilling American models, we would be in a pretty awful situation right now, particularly as Europeans. The open weight models are driving innovation and the diffusion of capabilities, and are leveling the playing field.

      If we greatly restrain our AI capabilities in the belief that China will do the same, and then China defects, AI could be so powerful that such a defection could lead to their geopolitical dominance. Therefore any agreement must either have ironclad verifiability, or must be limited enough that defection would not be militarily existential.

      — Dario Amodei

      I am assuming Dario has reasons to believe this, but the models that are actually causing issues right now are all closed weight American models. I'm fairly certain if they were open weight models, we would not have that issue. Why? Because for a start, the economics of serving up these models are only that distorted due to how the big labs can operate. OpenAI is casually burning 18 million USD to brute force a problem on a whim. They are operating subscriptions at a massive loss, distorting the market everywhere. If we had mass accessibility on somewhat equal terms, a lot of the crazy issues we are seeing today would not be taking place.

      A Total Regulatory Failure

      From where I sit, what we observe right now is a total regulatory failure everywhere. In Europe you have some whacky AI regulation that is two years old and completely misses the problems that we actually have and focuses on problems that nobody has. In the US we're seeing a system that is probably best described as turbo capitalism paired with sinophobia and erratic decision-making. In the chaos in which we find ourselves, the reality emerges. And the reality is, even today, really problematic.

      Whatever laws and regulations already exist are largely completely ignored. Plenty of companies are buying data from all over the place that people never agreed could be used for training of AI models. The token economy that is emerging is one that looks like a drug market where you don't know where the requests are going, what model is served up to you, where the GPUs are even running, let alone what you pay for all of this.

      We now have mathematicians who are scared that their use of ChatGPT leads to future models being trained on their ideas, and OpenAI apparently can't even rule it out.

      Ideally the regulators would have forced these models to actually benefit the commons if they are from the commons. The internet has, for instance, greatly benefited from very liberal rulings in the US that permitted scraping. Learning on public data could have been regulated in a way that labs would have to actively support and enable certain forms of distillation. That alone would dramatically change how these models are trained.

      What Might Happen?

      As I said before, I don't think AI is going to usher in an extinction event. In fact, even if nobody were to slow down, I really don't think humanity would have much to worry about. I tend to think it would actually be the large labs that have much more to lose there in reputation and legal responsibilities. I find it preposterous that OpenAI's agents are committing actual crimes out there, but we're just shrugging our shoulders and moving on as if nothing happened. But I'm sure executives in those companies are waking up to the reality that this is not at all popular with a lot of their potential consumers.

      I also think that this entire recursive self-improvement business has a good chance of being a problem. But not necessarily in that it will cause the end of humanity or societies, but that it will just do massive damage everywhere.

      And really, it will just make a lot of the things we are doing much more expensive. Software engineering is an early victim of that. The newfound powers so far have resulted in a new tax that companies need to pay to the model providers, both to keep up with the new speed and to deal with the problem of these machines finding security issues left and right.

      And presumably what is going on in software will happen to more industries. Universities and research groups will have to pour a lot of money into the closed models as well, to keep up with others who do.

      In a way, I'm really confused that society is taking all of this so well.