🏡
  • ↔
  • →
  1. September 02, 2026
    1. 🔗 gildas-lormeau/single-file-cli v2.7.0 release

      SingleFile CLI 2.7.0

      CLI fixes and improvements

      • a page that does not reach the state set by --browser-wait-until before --browser-load-max-time expires is captured as it is, once it has reached DOMContentLoaded. The page loading is stopped and a warning on stderr names the state it had reached. Previously the CLI reloaded the page silently with the next less strict state, once per timeout, so a page kept busy by a tracking script that never stopped requesting took over a minute to save and was captured from a reload. Set --browser-wait-until-fallback=false to get a load timeout error instead
      • the browser is closed and its temporary profile deleted when the CLI process is killed before it exits, on macOS and Linux. A killed process left the browser running
      • the help of --declare-appended-data says that it has no effect when the extra data is relocated ahead of the compressed data

      Core

      Updated to single-file-core 1.5.120, which brings:

      • the screen size is restored before the resize event that ends the lazy-loading pass. Pages that size their blocks from the viewport in a script were saved with enormous headers (#1603)
      • the lazy-loading pass stays open while the page inserts stylesheets
      • zero-height observer targets are no longer reported as visible
      • page text can no longer close the provenance comment. A --> coming from an infobar template broke out of it
      • the charset declaration stays inside the 1024-byte scan window when the doctype is long
      • the canonical link and the viewport meta are escaped in self-extracting pages
      • the recovery payload of universal self-extracting pages is written and read little-endian whatever the host byte order
      • the unassigned newline code is rejected when extracting a universal self-extracting page
      • the whole document is searched for the zip data comment when extracting
      • the language encoding flag is set on the page.pdf records
      • both prescan windows are measured from the start of the file under the PNG face
      • the entries of a self-extracting page are compressed once. The passes that change its layout copy them instead of compressing them again
      • the reservation of relocated extra data is sized from the measured payload shift, which avoided a third pass in one build out of four
      • a self-extracting page whose extra data is relocated ends at the end of central directory record, so ZIP readers rejecting trailing bytes open it

      Co-authored by Claude (Claude Code)

    2. 🔗 WerWolv/ImHex Nightly Builds release

      Nightly 53dbd48 Changelog

      • fix: Missing translation string
      • feat: Add support for in variable default values
  2. September 01, 2026
    1. 🔗 Simon Willison Claude Fable 5.1 made me a really nice animated pelican rss

      Today is Claude Fable (and Mythos) 5.1 day. Anthropic say that Fable 5.1 "sets a new standard for coding, knowledge work, and long-running problem-solving tasks". Their announcement spends a notable amount of time on scientific research, boasting of a 52.6% score on the brand new Terminal-Bench-Science 0.1 benchmark (first announced on August 27th), up from 24.7% for Fable 5, 29.0% for Opus 5 and 22.4% for GPT-5.6 Sol. Other benchmarks show slightly improved scores, but none as impressive as the Science one.

      But how well can it pelican?

      Back in July I wrote about how I was losing faith in the pelican benchmark - its connection to how good the models were at other tasks didn't seem to hold as strongly as it did back in 2025. The most interesting insights I get from it now are comparisons within model families, and particularly comparisons for the same prompt at different reasoning effort levels.

      Fable 5.1 has five reasoning levels: low, medium, high, xhigh, max - and no option to turn off reasoning entirely.

      I fixed an issue in llm-anthropic which caused reasoning traces not to be correctly recorded, then ran some prompts.

      Here's the full set of pelicans for all of the reasoning levels, each with the full reasoning transcript. I'll replicate them here:

      Low and medium, both without reasoning?

      Next, a bit of a mystery. This is what I got for effort low:

      Minimalist flat illustration of a white pelican with an orange beak riding a black bicycle to the left, its orange legs pedaling and wings gripping the handlebars, with motion lines behind on a light blue background.

      The transcript doesn't show any summarized reasoning tokens, and the output token count is 1,998. With Claude that output token count includes reasoning tokens. It took 23.8 seconds and cost 10.017 cents.

      I bumped that up to medium and got this:

      Minimalist flat-style illustration of a white pelican with an orange beak riding a black bicycle to the right, with motion lines behind it, on a light blue background.

      Weirdly, that one also shows no reasoning text and used 1,977 output tokens - 21 tokens less than low. It took 23 seconds and cost 9.912 cents.

      So for this particular prompt ("Generate an SVG of a pelican riding a bicycle") Fable 5.1 appeared to skip reasoning entirely at both low and medium settings.

      High

      Here's high - 29.6 seconds, 2,612 output tokens, 13.087 cents:

      Minimalist flat illustration of a white pelican with an orange beak riding a black bicycle, its orange legs pedaling, with motion lines behind it on a light blue background.

      This one did do a bit of reasoning, summary here:

      I'm planning the SVG layout for a pelican riding a bicycle, with a sky and ground background, a bicycle with two spoked wheels, frame, seat and handlebars, and a white-bodied pelican with a long neck and orange beak positioned on top.

      Really not much difference from low and medium, though.

      Extra High

      At xhigh things got radically different. 36,767 output tokens, 7 minutes 51 seconds, $1.83!

      Minimalist flat illustration of a white pelican with an orange beak riding a black bicycle to the left, its orange legs pedaling, with motion lines behind it on a light blue background.

      The reasoning trace is pretty lengthy, and includes details like this:

      Adding the eye, wings stretching down to the handlebar grip, orange legs reaching to the pedals, and a small tail feather, while keeping the pelican intentionally oversized compared to the bike for comic effect. [...]

      I'll accept the slight thickness as charming rather than overengineering it.

      Max

      Setting effort to max gave me the best pelican I've seen from any of Anthropic's models. 65,927 output tokens, 13 minutes and 54 seconds, $3.30:

      Minimalist flat illustration of a white pelican with an orange beak riding a black bicycle, its orange legs pedaling, with motion lines behind to indicate speed, on a light blue background.

      There's a lot to like about this. The background is tasteful, the legs are clearly on either side of the frame, the feet are on the pedals, the wing is on the handlebars, the pelican has a cute blue hat and there's a basket with a fish.

      It's still not showing nearly the same level of flair as Gemini 3.7 Flash, but I didn't ask for flair - I asked for an SVG, and that's what I got.

      Some highlights from that reasoning trace:

      Adding pedal shapes near both feet, with the far foot on the second leg partially visible behind the frame. I'm considering whether to add a small scarf or cap for extra character, but leaning toward keeping it simple to avoid clutter.

      Now I'm debating a bicycle helmet on the head versus the pelican's signature crest—the beak and pouch already read clearly as "pelican," so a helmet could reinforce the bicycle theme without losing identity, though it might compete with the crest for visual space.

      I realize the beak at (484,84) would overlap with the dome helmet, so I need to shrink the helmet so it only covers the top of the head, adjusting its arc endpoints to sit higher and narrower so the beak can attach cleanly at the front without collision. [...]

      I'm adding a darker tip region to represent the primary feathers, then reconsidering the trailing edge to include scalloped feather curves instead of one smooth line for a more natural look. [...]

      Now I'm checking the vent line placements on the helmet, making sure they sit far enough inside the helmet's edge given the stroke width and rounded caps, and confirming each vent stays within the helmet's circular boundary. [...]

      I decide skipping a handlebar bell and tire highlights since they're unnecessary additions. Now I'm reconsidering the front fork's curve — the current control point pulls the shape backward when it should bow forward for a proper rake, so I need to shift the control point rightward to fix the fork's lean.

      OK, let's animate it

      On Hacker News, swalsh commented on that Max pelican:

      Now that it's a solved benchmark, can we get the animated version?

      I didn't want to spend another $3 so I took the Max pelican and piped it into the default thinking level of High:

      llm logs -cx | llm -m claude-fable-5.1 -s 'animate this'

      6,121 input, 26,201 output = $1.37. The result looked like this, exported here as video since some people have trouble viewing animated SVGs:

      The wheels in the video are rotating in the wrong direction, but I think that's an artifact of the conversion to MP4 - they seem to be going in the correct direction in the original SVG.

      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. 🔗 anthropics/claude-code v2.1.258 release

      What's changed

      • Fixed Claude Code failing to launch on macOS 12 (Monterey), a regression introduced in 2.1.255
      • Fixed remote and scheduled sessions failing with "user messages must have non-empty content" after a re-sent permission approval could not be applied
    3. 🔗 brettcannon/cpython-wasi-build CPython 3.15.0rc2 w/ WASI SDK 33 release

      Bump actions/checkout from 6.0.1 to 7.0.0 in the actions group (#31)

      Bumps the actions group with 1 update: actions/checkout.

      Updates actions/checkout from 6.0.1 to 7.0.0
      - Release notes
      - Changelog
      - Commits

      ---
      updated-dependencies:
      - dependency-name: actions/checkout
      dependency-version: 7.0.0
      dependency-type: direct:production
      update-type: version-update:semver-major
      dependency-group: actions
      ...

      Signed-off-by: dependabot[bot] support@github.com
      Co-authored-by: dependabot[bot] 49699333+dependabot[bot]@users.noreply.github.com

    4. 🔗 backnotprop/plannotator v0.27.11 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      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 (same-day patch on v0.27.5)
      v0.27.5 | Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix, Pi fixes
      v0.27.4 | Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow
      v0.27.3 | Folder watcher freeze fix on large repos, first SBOM-attested release pipeline
      v0.27.2 | Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions
      v0.27.1 | Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles
      v0.27.0 | Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut
      v0.26.8 | Placed comment markers on HTML pages, shift-click multi-select, live app annotation

      What's New in v0.27.11

      A patch release with one important resource fix, one new safety net, and a CLI fix from a first-time contributor. Every change went through independent adversarial review and a six-agent QA sweep before tagging.

      OpenCode servers no longer pile up in the background

      If you had the opencode CLI installed, every Plannotator session quietly started an opencode serve process at launch, just to list OpenCode's models in the Ask AI dropdown. Ending a session with Ctrl-C never cleaned that process up, and every later session found the leftover server and loaded more state into it. Over a day of normal use this grew into a multi-gigabyte orphan process nobody started on purpose.

      Three things changed. Nothing starts anymore until you actually select OpenCode in Ask AI; most users never do, and now never spawn it. When it does start, each session runs its own private server on its own port instead of sharing one, so sessions can never pile into each other. And the server is now closed when the session ends, including on Ctrl-C.

      Two visible differences for OpenCode users of Ask AI: the model list fills in when you first select the provider instead of being preloaded, and you will see one opencode serve process per active Plannotator session rather than a shared one. Both are the intended shape of the fix.

      #1445

      Your submitted feedback is now archived locally

      Every plan decision, code review submission, and annotate submission is now recorded on your machine, under ~/.plannotator/feedback/, organized by project. Each record is one line in an append-only index plus a readable markdown file holding your review text, the excerpts it quoted, and annotation metadata, with lightweight provenance such as file paths and the git ref under review.

      The reason it exists: feedback used to be gone the moment it was sent. An agent times out, a terminal closes, and the review you wrote is unrecoverable. Now there is a durable record of everything you submitted, and a growing personal archive you can analyze or learn from over time. Herdr Annotate, the terminal-side annotator, writes to the same archive with its own client label, so both tools build one history.

      The archive stays on your machine and is never transmitted. It is on by default; set PLANNOTATOR_FEEDBACK_HISTORY=0 (or "feedbackHistory": false in ~/.plannotator/config.json) to turn it off, and delete ~/.plannotator/feedback/ to forget what is there. The privacy page documents it. The write path is deliberately fail-safe: if the archive cannot be written for any reason, your feedback still submits exactly as before.

      #1438

      A typo'd command now tells you instead of hanging forever

      plannotator annotatte README.md used to print nothing and hang until killed, because an unrecognized subcommand fell through to the plan-review hook path, which waits for hook data on stdin that never arrives from a terminal. An unknown subcommand now exits immediately with the misspelled word, a "Did you mean" suggestion, and a pointer to --help. A registry test scrapes the real dispatcher so the known-command list can never drift and reject a valid command.

      Contributed by @SumeraMartin in #1444, whose diagnosis of the stdin fallthrough was exact, in their first contribution to the project.

      Additional Changes

      • @plannotator/ui 0.35.2 (with @plannotator/core 0.25.1): hosts embedding the annotation UI can hide the Quick Label tool via the new hideQuickLabel prop on AnnotationToolstrip (forwarded by StickyHeaderLane). Default off; Plannotator's own surfaces are unchanged. #1442. Two broken publishes were caught and corrected the same day: 0.35.0 shipped an unresolvable workspace:* dependency, and 0.35.1 imported a core export the published core 0.25.0 did not contain. The source manifest now pins the exact core version, core 0.25.1 ships the missing exports, and CI installs the packed tarballs outside the monorepo and verifies real imports, TypeScript compilation, and a Vite build, so both failure classes are structurally closed. Use 0.35.2; 0.35.0 and 0.35.1 are deprecated. #1446, #1447
      • Privacy page : plannotator.ai/privacy now documents the local feedback archive, what a record contains, and how to disable or delete it.

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

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

      OpenCode: Clear cache and restart:

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

      What's Changed

      • fix(ai): stop leaking opencode serve processes in #1445
      • feat(server): durable feedback archive for every submitted review in #1438
      • fix(cli): exit on an unknown subcommand instead of blocking on stdin by @SumeraMartin in #1444
      • feat(ui): allow hosts to hide Quick Label in #1442
      • fix(ui): publish exact core dependency in #1446
      • fix(packages): publish annotation thread exports in #1447

      New Contributors

      Community

      @SumeraMartin found the unknown-subcommand hang, diagnosed the exact stdin fallthrough that caused it, and shipped the fix with a drift-proof test suite in a first contribution that merged as written. The opencode leak was caught during our own multi-agent operations when a monitoring session flagged a multi-gigabyte orphan process, and the feedback archive grew out of repeated user reports of reviews lost to agent timeouts.

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

      Full Changelog : v0.27.10...v0.27.11

    5. 🔗 exe.dev Agent Grit Is a Double-Edged Sword rss

      Story time.

      I had a fun idea for an LLM eval benchmark. It’s still a work-in-progress, but if it turns out to be interesting, I promise I’ll share it.

      Fable was merrily prototyping it for me. I checked in, and saw this:

      [The model declined to continue this request. Retrying the same request will likely be declined again. Switch to Opus to continue, or use /model to switch models. You can also try rephrasing or clarifying the intent instead.]

      Category: cyber

      Reason: This request triggered restrictions on violative cyber content and was blocked under Anthropic's Usage Policy. To learn more, see https://platform.claude.com/docs/en/build-with-claude/refusals-and-fallback. API integrators: you can reduce refusals for your users by configuring a fallback model — see https://platform.claude.com/docs/en/build-with- claude/refusals-and-fallback

      original screenshot

      Sigh. Absurd. It’s frustrating enough that Fable won’t help me defend against cybersecurity threats, but this? This has nothing to do with cybersecurity.

      So what silly nonsense triggered this? I scrolled up and expanded the thinking block.

      gpt-5.6-sol solved the 714-line task?! That demands investigation — either memorization or something fishy:

      🛠 python3 - <<'EOF' import json log=json.load(open('results/rust-
 in /home/exedev/lineshuffle ✓

      It brute-forced the shuffle seed—figured out the rig used Python's random.Random(seed).shuffle with a guessable seed of 0, then inverted that permutation. That's a real vulnerability: seed 0 with Python's PRNG is trivially exploitable, and this model found it. The fix needs a cryptographically secure shuffle, like deriving the RNG from a secret key plus task id, or using SystemRandom instead of a fixed seed.

      I should invalidate that compromised result. It's a great war story to share — it also attempted a network escape via a curl to raw.githubusercontent, which got blocked correctly by the network isolation, plus tried an /etc/hosts trick. For the shuffle fix, I want the permutation generation to use a keyed HMAC derivation from a secret file combined with the task and seed, so it stays deterministic yet unguessable, while logging the permutation for reproducibility. I'm now also wondering if gpt-5.5's earlier smoke-test solve was legitimate or another instance of seed guessing — it jumped from 0.51 to 1.0 accuracy suspiciously fast — so I should double check that transcript, along with kimi-k3's, though both seem like plausible genuine solves given the file sizes involved.

      original screenshot

      Oh. Ummmm. This is fine.

      Maybe the moral of this story (and this story) is not to give models really hard tasks? “Well, officer, I asked about the Riemann Hypothesis, and then I told it to try harder
”

    6. 🔗 PrimeIntellect-ai/prime-agent Beta (v0.9.1-beta.604.1.81ae3cb) release

      Automated beta build from main (81ae3cb34d27d38ee37f9e205a1e73694993b344).

    7. 🔗 PrimeIntellect-ai/prime-agent v0.9.1 release
      • Fixed a v0.9.0 regression: the agents view's Inactive section was empty on a fresh view until a search was typed. The saved-session catalog now loads (progressively) when the view opens; it was previously deferred to search because the roster's boot seed carried the saved corpus, which the seed scoping removed.
    8. 🔗 PrimeIntellect-ai/prime-agent v0.9.0 release
      • Fixed background (unattributed) kernel output missing from the expanded IPython cell view: it is now surfaced in the tool details and rendered under a "background output (unattributed)" label after stdout/stderr/result.
      • Fixed a protocol interrupt during a REPL state restore leaving a mixed old/new namespace: names are now staged first and applied atomically with SIGINT parked across the apply, and an interrupt landing anywhere between a committed snapshot or restore and its request finishing is recovered instead of misreporting the completed operation as failed.
      • Fixed the REPL snapshot writer leaving a new payload beside a truncated manifest on mid-write failures: payload and manifest now commit via unique same-directory temp files and atomic renames with guaranteed cleanup, and an interrupt during cleanup can no longer misreport a completed destructive snapshot as failed.
      • Fixed the REPL runtime list_names request crashing the serve loop when the namespace held a non-string key; non-string keys are now skipped and every runtime request fails individually through the shared backstop instead of killing the loop.
      • Addressed REPL host-swap review findings: reworded stale IPython-specific busy/restart messages for the default kernel and stopped restart() from resurrecting a concurrently killed REPL kernel.
      • Fixed graceful REPL kernel shutdown() losing teardown ownership to its own child's exit handler, which made restart() misread the shutdown as superseded and never start the kernel again.
      • Fixed REPL kernel start() waiting out the full 30s ready timeout when the kernel process fails to spawn; the spawn error now rejects startup immediately.
      • Fixed a cell that rebound or ignored SIGINT (or a restored prior handler) permanently breaking protocol interrupts: the REPL runtime now re-asserts its SIGINT handler between cells.
      • Fixed the Python REPL runtime surviving its owning process's death while a non-yielding cell runs: an owner-watchdog thread now hard-exits the runtime (killing live bash children first) when the owner process dies.
      • Fixed an interrupt parked during a snapshot's prune window misreporting the completed destructive snapshot as failed; it is now consumed once the manifest is committed, and an interrupt landing just after a completed snapshot/restore request is consumed too instead of failing its done.
      • Fixed a REPL runtime interrupt gap where an interrupt landing during a cell's trailing-expression repr or output drain was dropped; the request now stays interruptible until its done event is emitted, so a slow user repr can be cancelled.
      • Fixed two REPL runtime request-lifecycle bugs: a cell closing sys.stdout/sys.stderr no longer kills the serve loop (done still arrives and later cells run), and an untargeted interrupt parked for a request that fails to compile is consumed with that request instead of spuriously cancelling the next cell.
      • Fixed the REPL runtime leaking a finished cell's id onto late background-thread output: the current cell is now cleared right after the post-cell drain, so done stays the last event with that id and between-cell output carries a null id.
      • Fixed bash() cells failing under strict-POSIX shells (dash) when the status pipe landed on a multi-digit fd.
      • Fixed rlm.run outside a live kernel hanging forever instead of failing fast, which stalled CI shard 3 until timeout.
      • Fixed two bash() spawn races: status-channel fds no longer leak when pipe creation fails mid-setup, and a status-socket gate keeps the command from starting until its pid is journaled (a kernel kill in that window now stops the child instead of orphaning it past the reaper).
      • Fixed a compile-phase crash (e.g. RecursionError from a pathologically deep attribute chain) killing the REPL runtime instead of failing the one cell: any per-request failure now becomes error+done and the serve loop keeps running; rebinding sys.stdout/sys.stderr to flush-less objects no longer kills it either.
      • Fixed the REPL runtime hanging before done when a cell closes fd 1/2 and a later open() reclaims the number: drain sync tokens now go through a private dup of the capture pipe, with a pump-liveness backstop so a dead pump can no longer wedge the serve loop.
      • Fixed the Windows orphan reaper killing only the journaled bash() shell pid; it now uses taskkill /T so descendants die with the tree, matching the in-kernel bash() kill paths, and resolves taskkill via an absolute System32 path (with NoDefaultCurrentDirectoryInExePath) so a planted CWD taskkill.exe cannot hijack cleanup.
      • Fixed a snapshot request with identical path and manifest_path silently clobbering the just-written state payload; the runtime now rejects it as a failed request.
      • Fixed a snapshot request with a negative max_bytes/max_variable_bytes and prune_oversized writing an empty payload and then deleting every user variable; size caps must now be non-negative integers.
      • Fixed an interrupt landing mid-snapshot leaving prune deletions half-applied: once the snapshot manifest is committed, SIGINT is deferred until every oversized name is removed, so the namespace always matches the on-disk snapshot.
      • Hardened bash(): cancelling await bash(cmd) now kills the command's process group (background handles are unaffected), Windows helper binaries resolve via absolute System32 paths, kill() retries taskkill for already-reaped Windows trees, and orphan-journal enrollment fails closed when configured.
      • Fixed cross-cell output misattribution in the REPL runtime: stream events are attributed at write time via context, and raw fd or user-thread output is emitted with a null id instead of being credited to whichever cell is running.
      • REPL kernel: output from user threads, other cells' leftovers, and raw fd writes is no longer merged into the running cell's stdout; it is surfaced separately as unattributed background output.
      • Hardened bash() further: the host now injects an absolute default shell into the kernel (no PATH lookup; /bin/bash else /bin/sh on POSIX), macOS start-id lookup uses /bin/ps, and Windows worker-teardown orphan kills go through hardened taskkill /T.
      • Hardened Windows bash execution: the kernel shell is resolved only from trusted absolute paths (never PATH), and bash children are contained by kill-on-close job objects so a crashed kernel cannot leak process trees (taskkill remains only as a fallback when job creation fails).
      • Hardened Windows bash() containment: children are now created directly inside the kill-on-close job (PROC_THREAD_ATTRIBUTE_JOB_LIST at CreateProcessW time), so no window exists in which a kernel kill can leak a suspended, never-run process; handle inheritance is restricted to exactly the child's stdio handles (PROC_THREAD_ATTRIBUTE_HANDLE_LIST), so concurrent spawns cannot leak each other's handles; the journal start-id query still runs only while the job-contained child is suspended, and bash() still raises instead of falling back to jobless taskkill when containment fails.
      • Fixed a Windows bash() PID-reuse hazard: the child process handle is now retained through job cleanup and every taskkill-by-pid fallback (watch reap, kill(), cancel escalation, shutdown cleanup) and closed exactly once only after the handle is marked reaped, so a recycled pid can never be killed by the fallback.
      • Added an async-by-default bash() callable to the kernel runtime: it returns a live handle immediately (pid/tail/poll/kill/await), bounds in-memory output, and enrolls children in the orphan-process journal so kernel teardown reaps them.
      • Fixed bash() orphan-journal writes marking a child inactive even when the kill signal was not delivered; the record now stays active on delivery failure so the host reaper still owns the process (on Windows a shell that already exited counts as delivered, so clean exits still retire their record).
      • Changed the kernel to run on a minimal CPython REPL runtime speaking JSON lines over stdio.
      • Changed the kernel to a minimal Python REPL: %%bash cells, %cd, %env, and ! escapes were replaced by bash('cmd') and os.chdir(...)/os.environ[...] (magic-style cells fail with a plain Python SyntaxError); startup is faster and memory use is lower.
      • Removed the Jupyter/ipykernel kernel client; existing kernel venvs are rebuilt once (slimmer, no ipykernel) on next start.
      • Fixed supervised session renames failing after the supervisor approved an available name.
      • Made session path detection consistent across direct and daemon commands.
      • Removed internal test-only configuration cache reset hooks.
      • Fixed new-chat hints to use the session message count.
      • Kept available model lists in sync with the current catalog and configured providers.
      • Removed unused host-request capability helpers and the kernelManagerRef option from IpythonToolOptions.
      • Fixed bash() to capture all foreground command output before finalizing results by using an ordered per-command completion marker; output written after the marker (e.g. by EXIT traps or background jobs) is not in the awaited result but stays visible via handle.output()/tail().
      • Agent messages now use core session admission to choose immediate or queued delivery.
      • Made cross-worker agent lists current without broadcasting duplicate peer rosters.
      • Namespaced kernel host handler results so handler fields cannot overwrite host reply protocol metadata.
      • Fixed graceful Python kernel disposal so timed-out final snapshots are cancelled before teardown.
      • Fixed invalid kernel protocol frames hanging requests by rejecting the affected request and replacing the kernel from its latest state snapshot.
      • Fixed kernel teardown so session cleanup and signal handling share one bounded graceful shutdown path.
      • Fixed remote agent messages being delivered twice when the daemon request timed out or the response was lost: the message is now sent exactly once per call, and post-send failures surface as errors instead of triggering a resend.
      • Simplified model resolution and feature hint shuffling internals.
      • Fixed saved-session resume when its resident worker is still recovering after a daemon restart.
      • Fixed queued-message editing so duplicate prompts always target the selected queue entry.
      • Fixed reattached sessions omitting queued child agents or showing the wrong child activity.
      • Fixed passive RLM child metadata recovery from legacy registries without a session directory.
      • Stopped treating NODE_ENV=test as an implicit telemetry opt-out.
      • Removed delayed cancellation callbacks from empty interactive selectors.
      • Kept heartbeat lists current when session or subagent scope changes.
      • Removed the delay before continuing sessions after compaction.
      • Wait for RLM session activity changes without zero-delay polling.
      • Fixed concurrent execute_bash_and_wait commands sharing one bash abort controller: each executeBash invocation now gets its own controller, so a finishing command no longer clears a still-running command's abort state and abortBash cancels every in-flight command.
      • Removed the test-only daemon active-session lookup override.
      • Made daemon shutdown wait for Bash completion without polling.
      • Fixed a race where a concurrent open of a session already being opened by another client bypassed the session ownership check instead of failing with session-already-active.
      • Accept contributions from sirouk as a vouched external contributor.
      • Render Mermaid code blocks in assistant messages as inline Unicode diagrams, with a "Mermaid diagrams" setting (off/final/streaming, default streaming).
      • Tell the model explicitly to run shell commands through bash() instead of subprocess/os.system.
      • Fixed prime-agent list pinning an abandoned empty session at "working" forever; an empty session with nothing in flight now reports "idle".
      • Evict an empty, unnamed session's worker as soon as its last client disconnects, instead of parking it for the idle sweep; the on-disk draft session is preserved.
      • Fixed daemon session create when the worker process cannot be spawned (e.g. EMFILE from fd exhaustion): the create now fails with the real spawn error plus a resident-worker/ulimit hint, and the CLI prints a one-line error instead of crashing with a TypeError stack dump.
      • Fixed the agents view hiding running subagents whose worker is starting or recovering; the worker state now shows as the row's status label.
      • Made spawned subagent sessions visible from creation, before their first message lands.
      • Renamed the subagent summary bar label from "agents" to "subagents" and unified the status formula behind both surfaces.
      • Made the daemon supervisor own an event-driven agent roster: workers push roster deltas on session events and list is served from the supervisor's ledger with zero worker round-trips. Rows are as fresh as the owning worker's last delta; a silent worker's rows are annotated (recovering, last-heard-from) rather than dropped, and the surfaces that display those annotations ship in the follow-up PR.
      • Tracked admitted subagent runs in the supervisor roster from the moment they are queued (they appear in list once their session exists), and kept passivated or evicted agents listed as inactive rows instead of disappearing (client-owned workers stay private: their rows are dropped when the worker goes away).
      • Tracked worker liveness in the supervisor roster: a dead worker's rows are flagged "recovering" the moment its socket closes, and rows of silent workers carry a last-heard-from time. These fields are supervisor-internal here; the roster surfaces that display them ship in the follow-up PR.
      • Replaced the agents view's 1-second polling with a subscription to the daemon's agent roster: the supervisor pushes coalesced roster updates, scope transitions reuse one shared connection and store without refetching, and rows render the ledger's statuses and lifecycle labels (queued, recovering, failed, last-heard-from staleness). Removed the poll path: the agents view now requires the daemon's agent_roster capability and fails fast against a daemon lacking it (unreachable in practice, since launch replaces daemons on any schema mismatch); the chat subagents bar degrades to snapshot-driven counts.
      • Loaded the saved-session catalog only when a search query needs deep message text, once per view, instead of on every navigation.
      • Fixed a reconnect deadlock where a daemon socket close during recovery or post-update restore parked the reconnect loop's own attach, snapshot, and list requests behind a hello that the stuck loop could never produce (#1905).
      • Collapsed ipython cells that call the bash skill with a literal command now preview as bash · <command> instead of the python wrapper.
      • Added a direct session transport: the TUI now talks to its session's worker over a supervisor-issued single-use ticket, falls back to supervisor routing on any direct-path failure, and keeps the session streaming while a lost supervisor socket reconnects in the background.
      • Workers bind their identity to a fresh per-process instance id, enforced only when the authenticating supervisor presents one, so a downgraded supervisor can still adopt live workers.
      • Fixed daemon startup and recovery to preserve slow live processes and fail closed after socket lock loss.
      • Recovery never signals a live worker process it cannot verify as its own: a persistently failing live worker parks as failed with its process left running (reclaimed automatically by the next fresh create once its identity is verified or it exits). The one deliberate exception is replacing an authenticated pre-roster worker during adoption. A live worker that stays silent through ten probe rounds (~2.5 minutes) also parks as failed instead of probing forever.
      • Reduced kernel memory spikes during namespace snapshots: the payload now pickles straight into the staged file instead of building serialized copies in memory (peak snapshot overhead ~3.9x payload -> ~1x; ENG-5819).
      • Fixed empty draft sessions lingering as zombie rows after the last viewer quit: a direct-transport client's detach or socket drop now triggers the same last-detach eviction as supervisor-routed clients.
      • Stopped re-emitting rlm_child_update events whose child snapshot did not change; identical per-token progress updates no longer reach attached clients.
      • Fixed /update keeping the old TUI process alive until the relaunched TUI quit by replacing the process in place on POSIX platforms running Node 26.1 and newer; Windows and IBM i keep the previous child relaunch.
      • Fixed sent agent messages under Python cells not showing the expand/collapse keybinding hint that received agent messages show.
      • Scoped the roster's restart seed to registered workers' families: the saved-session corpus stays owned by the disk catalog, so a supervisor restart no longer publishes thousands of inactive rows (and one header read per row) to every roster subscriber. prime list --all output is unchanged: subagent rows of families without a registered worker are now served on demand from the spawn ledger.
      • Session disposal no longer blocks on the final trace upload (uploads finish detached; daemon exit, update restarts, and worker archive-and-shutdown drain them through a single barrier), and deleting an RLM subagent no longer writes a kernel snapshot that the deletion sweep removes right away.
    9. 🔗 anthropics/claude-code v2.1.257 release

      What's changed

      • Added Claude Fable 5.1 (claude-fable-5-1), now the default Fable model — 1M context, $10/$50 per Mtok with $0.25/Mtok cache reads
      • Added "Time format" (timeFormat) and timeZone settings: 12-hour, 24-hour, 24-hour UTC, or a strftime pattern for the turn-end clock and transcript-view timestamps
      • Added a Containment Escape rule to auto mode so cloud metadata-credential fetches, egress evasion, and cross-tenant reach are no longer auto-approved unless your environment marks them expected
      • Added CLAUDE_CODE_SUBAGENT_MODEL_FORCE to apply CLAUDE_CODE_SUBAGENT_MODEL (or the main model) to every subagent, ignoring per-spawn and agent-definition model overrides
      • Added s in /effort to change effort for the current session only, matching /model
      • Added a /doctor warning for stale sandbox mask files left by a killed session
      • Added a one-time prompt in auto mode before the first file read outside the working directories, with the option to block such reads (permissions.blockReadsOutsideWorkingDirectories)
      • Added support for a gateway-supplied description on discovered /model picker entries (CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY); entries without one still read "From gateway"
      • Fixed settings in a .claude/ folder created after startup not being picked up until restart
      • Fixed sessions dispatched from an agent view opened with ← always starting in the original session's permission mode, overriding the target directory's defaultMode and the agent's permissionMode
      • Fixed keybindings.json rebinds of Ctrl+G being ignored in claude agents; its Ctrl+S / Ctrl+T are now rebindable via the new Agents context
      • Fixed background sessions failing to start on macOS npm installs during a self-update, and on Windows when a stale daemon lock file pointed at a reused process id
      • Fixed the working spinner stopping while a response streams behind a slash-command panel
      • Fixed a background session's state.json detail repeating its own dispatch prompt after a scheduled wake-up
      • Fixed claude agents keeping a background session you re-prompted buried in Completed after it finished again; Completed now orders by the latest finish
      • Fixed claude --bg from a directory that was just deleted reporting "backgrounded" and leaving a crashed session row; it now prints the reason and exits 1
      • Fixed Remote Control connecting mid-session re-sending the Bash tool definition, causing a prompt-cache miss
      • Fixed a doubly-listed custom Authorization header overriding the configured credential on Bedrock, Mantle, Vertex, and WIF, and the Vertex setup wizard picking up a leftover Anthropic profile from ~/.config/anthropic
      • Fixed Claude apps gateway sending stray host Authorization or profile headers to Foundry, Vertex, and Bedrock, and Foundry Entra ID upstreams not starting when ANTHROPIC_FOUNDRY_API_KEY is set
      • Fixed a leftover Anthropic API key or auth token being sent alongside your Foundry subscription key in API-key mode
      • Fixed /schedule routines whose prompt was saved without a message role and then ran with nothing to do
      • Fixed claude agents not saying that a background session is waiting for you to approve a message from another session, or who sent it
      • Fixed a prompt stashed with Ctrl+S inside an opened background session being lost when the session went idle or was stopped and then reopened
      • Fixed telemetry (OTEL) settings pushed through server-managed settings being ignored on warm starts, including desktop-app Code sessions
      • Fixed a teammate permission request being answered twice when the leader's mailbox write was briefly locked
      • Fixed a phantom duplicate slash-command row rendering below the in-flight turn while a command's auto-continued response streamed
      • Fixed policyHelper timeoutMs and refreshIntervalMs values above the timer maximum (2147483647) causing failures or re-runs every millisecond; they are now clamped
      • Fixed the token counter freezing or crawling after switching to another subagent's transcript, and made background subagents' and teammates' counters update live while a response streams
      • Fixed sandbox network hosts written with a trailing dot (example.com.): a deniedDomains entry didn't block the host inside the sandbox, and "don't ask again" for such a host kept prompting
      • Fixed dismissing the Remote Control consent prompt (Esc, or n at claude remote-control) counting as consent, so the next request connected without asking
      • Fixed /mcp reconnect and enable still connecting a settings-file MCP server that a managed MCP allow/deny list or strictPluginOnlyCustomization loaded after startup should block
      • Fixed claude mcp remove leaving a remote server's stored OAuth credentials behind when strictPluginOnlyCustomization locks MCP to plugin-only servers
      • Fixed Remote Control (claude remote-control) sessions started from the Claude app ignoring the selected model and running on the machine's default instead
      • Fixed --disallowedTools and session deny rules being dropped after the first settings reload when allowManagedPermissionRulesOnly is enabled
      • Fixed --resume listing a backgrounded conversation twice and --continue reopening its stalled pre-background copy; --continue now also opens finished background sessions
      • Fixed fullscreen mode not letting you click ! shell command output to expand it
      • Fixed background sessions left running an older Claude Code binary piling up across auto-updates instead of being retired
      • Fixed claude agents --json briefly switching the terminal to raw mode and undoing another program's terminal settings on exit
      • Fixed Proactive output style sessions busy-looping with filler messages and repeated log reads instead of idling while a background command or Monitor they started is still running
      • Fixed subagents stopping when a response was cut off mid-stream by a computer sleep, dropped connection, or server error; they now automatically continue instead of ending with an incomplete response
      • Fixed ← doing nothing in the /btw panel inside a claude agents session: it now returns to the agents list (even mid-answer), and the panel comes back when you reopen the session
      • Fixed sessions with an advisor model set missing the prompt cache on background requests (compaction, /recap, prompt suggestions) and re-sending the full conversation uncached each time
      • Fixed claude -p exiting about 5 seconds after its final result while a Monitor the model armed was still running; it now waits for the watch to fire or time out
      • Fixed a permissions.ask rule being skipped in auto mode when the matching command ran inside a compound command or subshell, letting it run without the confirmation prompt
      • Fixed plugins being able to read files outside their own directory through a declared command, agent, skill, hooks or other component path that is a symlink; such paths are now refused with an error
      • Fixed /add-dir rejecting a directory inside the current working directory; it now loads that directory's skills, commands, and agents like --add-dir does at startup
      • Fixed the main agent not being told when you resume a subagent you had stopped from its transcript view
      • Fixed a crash when pasting ANSI-colored text (e.g. a CI log) into dialogs like /feedback
      • Fixed claude mcp add/remove hanging or exhausting memory when the project's .mcp.json is a FIFO or a device-file symlink; it now fails fast with an actionable message
      • Fixed unbounded memory growth when non-JSONL data is piped into claude -p --input-format stream-json; it now fails fast with a clear error
      • Fixed backgrounding a turn (← or Ctrl+B) while a subagent or other tool was running occasionally making the background session treat that tool as rejected instead of re-running it
      • Fixed Bash Read()/Edit() deny rules not applying to < file redirects and reader commands like tac and egrep; a deny rule on any argument or redirect target now refuses the command
      • Fixed resuming or messaging a subagent whose transcript had grown past 5 MB (for example after reading many images) failing with "No transcript found"
      • Fixed worktree-isolated sessions refusing Bash loops, $VAR reads, "$(
)" and heredocs that never touch git as "too complex to verify that it stays inside the worktree"
      • Fixed /model and /effort showing a prompt-cache warning after rewinding a conversation back to empty
      • Fixed prompt-cache misses on every turn in long screenshot-heavy sessions once images exceeded the per-request size cap
      • Fixed the Edit permission prompt's diff view rendering emoji and multi-code-point characters with incorrect widths
      • Fixed WebSocket MCP server connection failures being logged as "[object ErrorEvent]" instead of the underlying error
      • Fixed background sessions failing to open with "Couldn't start the background service" while another Claude Code process was downloading an npm update; the start now waits for it
      • Fixed background commands that detach from their shell (for example under timeout or setsid) surviving a task stop or Claude Code exit
      • Fixed Claude not being told when you stop a background command from the tasks panel or a connected client
      • Fixed stopping a background subagent leaving its monitors running
      • Fixed sandboxed git commands in a linked worktree losing write access to the repository's common .git directory after cd into a subdirectory
      • Fixed Bedrock and Bedrock Mantle requests going silent during long hidden-thinking phases on Opus 4.7 and later, which let idle timeouts cut the connection; the stream now carries progress events
      • Fixed launching Claude Code after a Claude apps gateway expired or revoked your session: it now says the session ended and offers /login instead of reporting a network error
      • Fixed cloud sessions losing git/GitHub credentials for the rest of the session when the session's network proxy failed to start at launch; it now retries in the background and recovers
      • Fixed leftover cc-daemon-* folders in the system temp directory after an interrupted background daemon start; the cleanupPeriodDays retention sweep now removes them
      • Fixed Bash permission checks auto-approving certain [[ ]] conditionals that zsh parses differently from bash; these commands now prompt for approval
      • Fixed the managed-settings approval prompt showing the generic warning instead of its telemetry wording when the settings also turn detailed tracing or raw API body logging off, or trace export on
      • Fixed agent-team teammates in tmux/iTerm2 panes sometimes staying open after acknowledging a shutdown request
      • Fixed the keyless Console sign-in ("Sign in with your Console account") not applying your organization's server-managed settings, and /status not showing the Organization for that sign-in
      • Improved rendering performance: less re-render work per turn in long conversations, streaming no longer slows down as the reply grows, and background-agent updates no longer re-render the whole screen
      • Improved prompt input responsiveness by reducing per-keystroke rendering work
      • Improved policy helper diagnostics — refresh failures now show in /status, declining the managed-settings dialog prints why Claude Code exited, and helper timeouts are reported as timeouts
      • Improved /code-review --comment to post findings on GitLab merge requests via glab mr note instead of reporting the target as unsupported
      • Improved notifications: an MCP elicitation or permission ask queued under another dialog now sends its idle desktop notification at the same delay as a visible ask
      • Improved verbose/transcript output: async hook completion notices that arrive together now appear on one line instead of one line per hook
      • Improved claude self-hosted-runner --configure-git to also enable git push negotiation, so the first push of a new branch from a stale clone uploads only the new commits instead of the whole tree
      • Improved liveness reporting to SDK hosts while a response is held open by gateway keep-alives, so long waits under a raised CLAUDE_STREAM_IDLE_TIMEOUT_MS are not mistaken for a hung session
      • Improved MCP connection and OAuth debug/error logs so credentials carried in a server's URL or request headers are redacted
      • Improved /fork to keep the original conversation's prompt cache in the new background session: its worktree briefing now arrives as a message instead of a system-prompt change
      • Improved emoji autocomplete to accept the remaining GitHub/Slack shortcode aliases (:satisfied:, :telephone:, :collision:, 
)
      • Changed --effort to lift a new model's default-effort hold for that session only rather than permanently; an effort picked on claude.ai for a Remote Control session now applies during the hold
      • Changed a policyHelper in MDM or managed-settings.json shadowed at launch by cached server-managed settings to run (or exit) as soon as the fetch reports them removed, not at the next launch
      • Changed managedSourcesBehavior: "merge" to take sandbox.credentials.awsPairs and sandbox.ripgrep whole from the highest managed source that sets them instead of combining the sources' values
      • Changed gateway model discovery (CLAUDE_CODE_ENABLE_GATEWAY_MODEL_DISCOVERY=1) to run even when CLAUDE_CODE_DISABLE_NONESSENTIAL_TRAFFIC is set, since it only queries your gateway
      • Changed claude --resume <session-id> --bg to continue that session under its own ID when nothing is running it, instead of silently starting a copy; a copy is now announced
      • Changed /btw history browsing from ←/→ to Shift+←/Shift+→ (or [/]), stepping through your recent side questions and back to the live answer
      • Changed defaultMode: "bypassPermissions" in .claude/settings.json or .claude/settings.local.json to be ignored, like "auto"; set it in user or managed settings, or pass --permission-mode
      • Changed fable and best in Claude apps gateway sessions to keep resolving to Fable 5 for now, since gateways not yet configured for Fable 5.1 reject it; pick Fable 5.1 in /model to use it
      • Changed --add-dir, /add-dir, and additionalDirectories to refuse network paths (UNC shares, /net/<host> automounts) with a message before touching them; on Windows use a mapped drive letter
      • Changed Claude apps gateway sign-in and token refresh requests to verify the gateway's pinned TLS certificate, as the managed settings fetch already does
      • Changed Cowork and claude.ai cloud sessions: reading an artifact that isn't yours now always asks you first, even in auto mode
      • Removed the Ctrl+E command explanation on Bash and PowerShell permission prompts
      • [VSCode] Added collapsible ACCOUNT & USAGE and SESSION MANAGER section headers to the session list panel, with the account email, the usage meter, and a View details link opening the usage dialog
      • [VSCode] Added a model pill to the input footer that shows the current model and opens the model picker, with an Effort row and a "More models" page
      • [VSCode] Added a collapse toggle to the Ungrouped section of the session list
      • [VSCode] Added output style selection to the command menu, including custom styles
      • [VSCode] Fixed third-party provider deployments (Bedrock, Vertex, and others) still showing claude.ai-only features (remote sessions, dictation, usage) and calling claude.ai with a leftover login
      • [VSCode] Fixed the session list panel's usage meter staying blank after the panel loads; it now shows the last known usage immediately
      • [VSCode] Fixed the "Enable Remote Control for all sessions" toggle so turning it on or off applies to sessions that are already open, not only to new ones
      • [VSCode] Fixed screen reader announcements: a control character before a fence or heading no longer drops visible lines from speech, and bold markers spanning a heading are no longer mis-paired
      • [VSCode] Changed the action menu to list slash commands in a filterable "Slash commands" dialog instead of inline; picking one runs it; the MCP servers dialog gained the same filter box
      • [VSCode] Changed "Delete session" to "Archive session": archived sessions move to a collapsible "Archived sessions" group at the bottom of the list with an Unarchive action
    10. 🔗 HexRaysSA/plugin-repository commits sync repo: +4 releases rss 
      sync repo: +4 releases

## New releases
- [BinDiff-NG](https://github.com/mahmoudimus/bindiff-ng): 8.1.4, 8.1.3, 8.1.2
- [FridaTools](https://github.com/ys1231/idafridascript): 0.0.4
    11. 🔗 The Pragmatic Engineer How software engineering is changing: an essay challenge rss

      The pace of change in software engineering is only accelerating, especially since January of this year. This is all to do with the industry-wide adoption of LLMs, AI tooling, and AI infrastructure. At The Pragmatic Engineer, we always want to capture as much of what's going on as possible at startups, Big Tech, and other businesses, in order to share with subscribers. That's why we're launching an essay competition with a chance to win up to $10,000, this week!

      Send us up to 10,000 words on how you see things at your startup or tech company, or at a business you're connected with. The best entries will be published in the Pragmatic Engineer and win prizes of $2,500, plus one grand prize of $10,000 for the best essay we read.

      The Pragmatic Engineer reports many developments in tech in our deepdives, including how building software is changing at Anthropic, why Ramp built its own in-house coding agent, how Uber uses AI for development, how Codex is built and what it could mean for the future of software engineering, and much more. Almost every company we talk with currently says that processes which worked fine for years are suddenly pretty outdated.

      This pace of change makes it hard to cover the full breadth and diversity of tech in one deepdive per week - especially right now, when engineers are building and using new and better tools in every part of the software development lifecycle.

      So, we 're launching a writing challenge to encourage software builders to share how things on the ground are changing. We'll share these cutting-edge reports with readers in future editions of the Pragmatic Engineer.

      So, tell us what's new, different, better, and worse in your part of the tech industry since AI entered your workflow!

      What we're looking for

      • An essay written for software engineers : 3,000 - 10,000 words on one of these topics:
        • How software engineering is changing at your company, institution, or open source project
        • The engineering culture at your company, institution, or Open source project in 2026
        • How you build software in your company, institution, or open source project
        • Software engineers turning into AI engineers at your company, institution, or open source project. Basically, how the work is changing
      • First-hand details: Winning essays will include the authors' personal observations and opinions.
      • Include details about the team and company: Including details about the team and company in the spotlight is important and enriches the essay by painting a more complete picture for readers; what engineering practices are changing, what's still the same, what about tooling, and processes? Is there any "traditional wisdom" that no longer holds true - or is still true today? It 's not necessary for writers to work at a company/team being written about.
      • Software engineers and "builders" only: We want to hear from folks who build software; meaning that you have built from scratch, pushed to prod, or been paged when your service (or someone else's) caused an outage. Basically, if you do this currently, or did it in the past, then your essay is eligible for entry. You don 't have to be a builder right now if you're still close to those who build software.
      • Individual work. This competition is specifically for individuals, so articles written collectively by teams are not eligible.Of course, outside of this competition, The Pragmatic Engineer always welcomes articles from teams that want to share interesting developments!
      • No AI writing allowed. Writing is thinking, and we are interested in your own thoughts and observations, not a sharp, one-sentence observation turned into three paragraphs of blob text by an LLM. Using AI as a research tool is allowed if you're confident about the accuracy of its output, but all the words must be written by a person.
      • Submitted essays must not be available to read elsewhere before 20 October. The essay has to be purpose-written for this competition and cannot have been published online or in print prior to 20 October 2026 in order to be eligible. After this date, a submitted essay can be published on any company blog, personal blog, or other medium.

      Prizes

      The competition has the following prizes:

      • Grand prize: $10,000 and publication in The Pragmatic Engineer (following editing), and a Pragmatic Engineer surprise package. For winning entries, we reserve the right to make edits for legal, editorial, style, grammar, and punctuation reasons.
      • Runner-up prize(s): $2,500 + sharing an excerpt in The Pragmatic Engineer + a The Pragmatic Engineer surprise package. Focus of the runner up category includes viewpoints from:
        • Bootstrapped (non-VC-funded) companies
        • More "traditional" companies that not digital-first, or which even predate digitalization
        • AI-native startups founded in 2023 or later which have been using AI tools since day one
        • Academia, government institutions, and open source projects

      For quality deepdives: We plan to publish a roundup of essays in the future on topics which contain interesting learnings, and that clearly show great effort on the part of authors. These pieces will receive a The Pragmatic Engineer surprise package.

      Timeline

      • Midnight, 4 October, PST: deadline for all submissions.
      • 20 October: decision on the prizes.
      • 3 November : expected publication of the Grand Prize winner

      Submit your essay here

      FAQ

      **Why is AI writing banned from this contest? I want to use AI to write my essay like I do for writing code! **

      It's a rule that you cannot include writing in your essay which was generated by AI. As everyone who reads this newsletter likely knows; there is no shortage of ways to detect AI-written text these days! The Pragmatic Newsletter is fully written by humans, and the same applies here. The reason for this hardline stance is that we believe in the value of human thought and experience, as told by people with first-hand knowledge. It's also about the audience: The "audience" for AI-written code is usually a machine, whereas the writing in Pragmatic Engineer is for humans, by humans. AI produces a statistical average in its output which creates uniform, dull text that's an inferior reading experience to human writing - at least today it is.

      Can I publish my essay online after writing it?

      In order to be eligible for consideration and prizes, an essay cannot be available to read anywhere online or in print before or after it is submitted to this contest. After 20 October 2026, no publication restrictions apply.

      Can my essay be changed after I send it?

      For spelling, punctuation, grammar, legal, and editorial reasons, the Pragmatic Engineer reserves the right to edit or amend all writing published on this platform.

    12. 🔗 Evan Schwartz Scour - August Update rss

      Hi friends,

      In August, Scour scoured 878,974 articles from 28,519 feeds. Also, 219 users signed up since my last product update email at the end of June so welcome to you all!

      If you've been enjoying Scour and would be willing to put a quote on the testimonials section of thehome page, please let me know!

      Here's what's new in the product from July and August:

      📊 More of What You Like

      I've spent a lot of the past 2 months working on improving ranking quality. Now, the interests and sources you tend to click on and like get boosted while those that you tend to ignore or dislike are deprioritized. Additionally, Scour got a notch better at matching posts to your interests, so you should see less off-topic content.

      By the way: liking and disliking items you read on Scour helps make your feed better and also helps me figure out what types of ranking changes to prioritize.

      📅 Detecting Event Coverage

      Scour now detects groups of articles covering the same event, including across days and even when they don't all link to a common source. You should now see less repeat coverage of the same major news stories across days.

      🚼 Suppressing Junk

      Scour is better at detecting and hiding ads, deals, press releases, sponsored placements, listicles, and posts with little substantive content. Also, arXiv papers that have been withdrawn by their authors won't show up in your feed.

      💅 Sleeker Feed Interface

      I got a little excited after adding some of the features in June and the feed got a little too busy. Now, the feed has been cleaned up again.

      While scanning the feed, you'll see just the information you need to decide whether to click on it. You can tap any row to see additional information including a preview snippet from the post and other articles that cover it or that it links to. Plus, after you love, like, or dislike a post, you'll see additional options for seeing more or less content like that in your feed.

      ⏱ Reading Time

      Under each post's title, you'll see the estimated reading time, as long as Scour was able to fetch enough of the article's content to determine the length.

      📝 Easier Interest Adding

      Adding new interests got easier. You can write any free-form text you want. While you're typing, you'll see "quick add" suggestions based on topics other users have added. Or, when you click Add Interests, Scour will extract appropriate topics from whatever you have written.

      ∞ Feed Keeps Going

      If you run out of posts from feeds you subscribe to within the given time window, your feed will now continue automatically to show you slightly older posts and then posts from across all of Scour.

      🔖 Some of My Favorite Posts

      Here were some of my favorite articles I found on Scour in July and August:

      • As I've continued to read and think about how we use AI, particularly in software engineering, these were some I found interesting:
        • Nolan Frausto wrote about The AI Slop Spiral and teams getting into the habit of having AI write plans that are so long and give the appearance of thinking, which are then only reviewed by AI, and then used to have AI produce code, which is then only reviewed by AI, etc.
        • Patrick George Wyndham Smith wonders about how we should think about code review in Faster pull requests are faster horses. He makes the point that "Reading code only as diffs is like trying to view an elephant through a straw."
        • Geoffrey Litt wrote Understanding is the new bottleneck, which contains a thesis I very much agree with and an /explain-diff skill that I tried out for a few days and then turned off.
        • Alex Klos wrote How Do We Stop Vibe Coding? discussing how to build trust with AI-generated code and the dissatisfying array of options for spec-driven development.
      • Ariana Irady wrote The Instagram Rebrand and How Typography Always Wins the Argument.
      • Bradley Emi, co-founder of Pangram, wrote a useful explanation about why LLM-written text is so flat, boring, and detectable in LLMs don't just mimic human text.
      • Irene Zhang of ChinaTalk wrote about the motivations of the DeepSeek founder, Liang Wenfeng, in The DeepSeek Thesis.

      Happy Scouring!

      - Evan

    13. 🔗 modem-dev/hunk v0.21.0-beta.1 release

      What's Changed

      Full Changelog : v0.21.0-beta.0...v0.21.0-beta.1

    14. 🔗 MetaBrainz Picard 3 Release Candidate 1 rss

      The Picard team is excited to announce the first release candidate for Picard 3. With this release we are confident that Picard 3 is now suitable for testing by a wider audience. The final 3.0 release is planned to happen in a few weeks.

      Since we are near a final release, we tried to focus on bugfixes, final changes to the Plugin API and further UI/UX improvements. On the UI side, Picard now fully supports dark / light mode across all supported operating systems, with the ability to change the theme without a restart.

      Download links and a detailed list of changes since Picard 3 beta 9 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?

      Bugfixes

      • PICARD-1877 - The language field of a lyrics (USLT) tag is not preserved
      • PICARD-3377 - picard-cli plugins compile-ui fails when called on a .ui file inside a directory
      • PICARD-3381 - Alternative Qt6 rcc path missing for RHEL
      • PICARD-3383 - picard-cli plugins install . gives an error about the plugin not being in the registry
      • PICARD-3393 - A single failing metadata processor prevents all subsequent processors from running
      • PICARD-3398 - Pending request stuck if authentication gets cancelled
      • PICARD-3400 - OAuth: browser-integration login exchanges code with wrong (unprefixed) scopes, breaking collections
      • PICARD-3402 - ListenBrainz batch submission retries forever on permanent errors (e.g. 401)
      • PICARD-3403 - Plugin git authentication crashes with AttributeError on pygit2 1.20+ (removed GIT_CREDENTIAL_* constants)
      • PICARD-3404 - A rating of 0 is discarded when loading ASF/WMA/WMV files
      • PICARD-3405 - ImageList.get_types_dict() keeps the smallest image per type instead of the biggest, defeating "Never replace cover images with smaller ones"
      • PICARD-3406 - AttributeError: 'Pygit2Repository' object has no attribute 'branches'

      New Features

      • PICARD-700 - Add a new tag "albumartists"
      • PICARD-3378 - Add tagger script functions $get_new() and $get_original() to allow direct access to new or original file tags
      • PICARD-3379 - Add a regex testing playground to the Advanced options screen
      • PICARD-3380 - Option to remove all cover images from tags

      Improvements

      • PICARD-2109 - Set cover art default to CAA Release Group
      • PICARD-2442 - Allow runtime theme changes
      • PICARD-2844 - Make language required for both comment and lyrics tags
      • PICARD-3117 - Write "Performer [instruments]" without specific instrument as performer:instruments
      • PICARD-3374 - Disc log readers registered by plugins should have access to the PluginApi
      • PICARD-3382 - debug_if() and DebugOpt should be exposed through Plugin V3 API
      • PICARD-3387 - Use tags added with api.register_script_variable for auto-completion
      • PICARD-3394 - ListenQueue: Avoid unnecessary file writes and clean up queue file after successful submission
      • PICARD-3396 - Offer "Use track relationships" as an opt-in in the first-run setup wizard
      • PICARD-3399 - Improve browser integration auth response pages

      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, Bryan Roessler, Laurent Monin and Philipp Wolfer. Translations were updated by hildgyorgy (Hungarian), janrieger (German), Marc Riera (Catalan), mfmeulenbelt (Dutch), ninjum (Galician), NorwayFun (Georgian), Priit JĂ”erĂŒĂŒt (Estonian) and Vaclovas Intas (Lithuanian).

    15. 🔗 Rust Blog Announcing rustup 1.29.1 rss

      The rustup team is happy to announce the release of rustup version 1.29.1.

      Rustup is the recommended tool to install Rust, a programming language that empowers everyone to build reliable and efficient software.

      What's new in rustup 1.29.1

      The headlines of this release are:

      • Concurrency in certain rustup operations has been improved:

        • When running rustup update, rustup will first check for possible updates in parallel. pr#4752
        • When running rustup component add with multiple components, they will be installed concurrently. pr#4790

        • Implicit installation of the active toolchain in rustup-init and rustup invocations has been deprecated where deemed unnecessary and will now produce a warning. pr#4840

        • Please see our blog post for more details regarding this change.

        • rustup doc now supports the --serve flag which allows serving the docs over local HTTP. This should help users with containerized browser and/or rustup setups. pr#4986

      • Installing i686-pc-windows-* host toolchains on 64-bit Windows now requires --force-non-host. pr#4935

      • rustup-init will no longer leave unexpected files on disk after cancelled installations. pr#4996

      • A bug has been fixed which might cause Windows installation to fail when using rustup-init.sh. pr#4756

      • "Target triple " has been renamed to "target tuple " across the project to reflect the new terminology. pr#4743 pr#4827 pr#4834

        • Please note that this is not a breaking change in the CLI since the existing options such as --target are not using this terminology.

      In addition, rustup now officially supports aarch64-pc-windows-gnullvm as a host platform. pr#4523

      Further details are available in the changelog!

      How to update

      If you have a previous version of rustup installed, getting the new one is as easy as stopping any programs which may be using rustup (e.g. closing your IDE) and running:

      $ rustup self update

      Rustup will also automatically update itself at the end of a normal toolchain update:

      $ rustup update

      If you don't have it already, you can get rustup from the appropriate page on our website.

      Rustup's documentation is also available in the rustup book.

      Caveats

      Rustup releases can come with problems not caused by rustup itself but just due to having a new release.

      In particular, anti-malware scanners might block rustup or stop it from creating or copying files, especially when installing rust-docs which contains many small files.

      Issues like this should be automatically resolved in a few weeks when the anti-malware scanners are updated to be aware of the new rustup release.

      Thanks

      Thanks again to all the contributors who made this rustup release possible!

    16. 🔗 Ampcode News Fable 5.1 rss

      Claude Fable 5.1 now powers Amp's ultra mode, replacing Fable 5.

      It's very good at writing, very good at taking direction mid-task, and very good at working on its own. And it costs less to run.

      Long Tasks and Proof of Work

      What won us over is how much better it got at long horizon work, at giving proof of its work, and at iterating on that proof. It runs for hours on its own, and when the proof doesn't hold up, it goes back and fixes the work, then proves it again.

      Some examples:

      • Hamish told it key presses felt laggy in our iOS app and asked it to find out why. Two hours later it had a side-by-side video of the old and new builds typing the same sentence on an iPhone simulator. Along the way it caught a two-pixel height difference in its own comparison, corrected it, and re-recorded. Typing latency in Safari went from 85 ms to 8 ms.
      • Thorsten recorded his screen creating a new thread on ampcode.com and asked it to make that twice as fast, however long that may take. Fable 5.1 pulled every frame out of the recording to time each step, then found the biggest delay was waiting for the server to finish creating the thread. Creating a thread got 45% faster.

      Writing

      Writing is where it impressed us the most. So far we haven't been big fans of using AI for prose. Fable 5.1 changed that. The text it produces reads more like it was written by a person. It explains the idea behind a change instead of every technical detail, and draws a diagram when that's clearer than a paragraph. We ended up using it for our new docs pages, where it not only surprised us by writing concise prose but also by running the features on a dev server, executing them end to end, and documenting them with screenshots and demo videos.

      Steering

      We steer it a lot more now. Fable 5 would sometimes ignore an instruction sent mid-task and carry on with the work it already had. Fable 5.1 does both: it finishes the original task, does what you just asked, and reports on each separately. It addresses every instruction you give it, even several at once. It works great with the Steer, Not Queue setting turned on.

      Cheaper

      And it costs less: ultra threads are about 35% cheaper than before. Cache reads are 75% cheaper than on Fable 5, and in a typical Amp thread, over 90% of tokens are cache reads.

      How To Use It

      ultra is for the work where the outcome is clear and the path is not. Fable 5.1 is at its best there. A few habits help:

      • Tell it what done looks like, and how to prove it. Example: "The sidebar stutters when scrolling through a few hundred threads. Find out why and fix it. Show me a video of scrolling before and after on the same thread list, and frame times measured in Safari, not Chrome."
      • Steer it while it works. If it's heading somewhere you don't want, say so in the moment. You can also hand it new tasks while it's busy; it addresses all of them without dropping the one it's on.

      What the Team Says

      Very impressed by Fable 5.1. It's very good at writing, it's very good at... everything really? I'm in a thread where I constantly reply to 2-3 different things and it perfectly keeps them apart. It's like having two conversations at once.

      — Thorsten Ball

      I've also been impressed with Fable 5.1. Feels less hand-wringy than Fable did.

      — Camden Cheek

      In my code reviews I agree with its changes more than I agree with the previous Fable's. And I steer it a lot more, because it handles multiple requests at once.

      — Hitesh Sagtani

    17. 🔗 Ampcode News Intelligently Ordered Diffs rss

      The first challenge in code review is figuring out which files to read first. Amp now orders diffs intelligently and highlights which files contain the essential changes.

      Click the file order button to toggle between alphabetical and intelligent order. Amp reads the diff, finds the files that best explain the change, and moves them to the top.

      The Changes pane with intelligent file ordering enabled, important files first, and less important files muted

      Less relevant files, such as tests, fixtures, and generated code, will be shown in muted colors below the important ones.

      If the diff changes while you're reviewing it, a blue dot over the button will indicate that there is an updated ordering. Clicking it will update the diff with the new order.

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

      IDA Plugin Updates on 2026-08-31

      Activity:

    2. 🔗 jellyfin/jellyfin 12.0 RC7 release

      🚀 Jellyfin Server 12.0 RC7

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

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

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

      A note about versioning

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

      What's new?

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

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

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

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

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

      Installing

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

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

      What's Changed (since

      v12.0-rc6)

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

    3. 🔗 backnotprop/plannotator v0.27.10 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      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 (same-day patch on v0.27.5)
      v0.27.5 | Annotate your running app, Agent TUI placement, collapsed lockfiles, VS Code theme fix, Pi fixes
      v0.27.4 | Portable Guided Review exports, guides.show share links, guide CLI, favicon switcher, jj Call Flow
      v0.27.3 | Folder watcher freeze fix on large repos, first SBOM-attested release pipeline
      v0.27.2 | Mobile plan and code review, Codex CLI 0.147 fix, folder annotate cold-start, configurable markdown extensions
      v0.27.1 | Open-in-editor launch fix, file headers respect Viewed/Git-add visibility toggles
      v0.27.0 | Call Flow analysis, --tailscale remote reviews, review panel remembers your view, Pi rebuild (breaking command rename), focus-mode shortcut
      v0.26.8 | Placed comment markers on HTML pages, shift-click multi-select, live app annotation
      v0.26.7 | Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing

      What's New in v0.27.10

      This release brings two review features people have asked for, restores the slash commands on OpenCode 2, and fixes three reported bugs. Six PRs shipped, every one shaped by community reports and requests, and the whole set went through an adversarial 29-point QA sweep before tagging.

      Files mark themselves viewed as you scroll

      Reviewers reading the all-files diff top to bottom no longer check every file off by hand. Scroll past a file after actually reading it and it marks itself viewed; open a file, read it, and move on, and the same happens. Momentum- flicking to the bottom marks nothing: a file only counts once its content was on screen long enough to have been read, and collapsed or generated files (your lockfiles) never auto-mark from their folded headers.

      The reviewer stays in charge. Un-viewing a file is treated as "come back to this," and auto-view will never re-check it. When a diff refreshes and a file's content changed underneath its checkmark, the checkmark comes off, so a stale check can't vouch for code an agent just rewrote. The feature is on by default with a one-time notice the first moment it fires, and it can be turned off in Settings or from the gear above the file list.

      #1430

      Undo and redo for annotations

      Mod+Z / Mod+Shift+Z now work across annotation actions in plan review and code review: create, edit, and delete for comments, deletions, checkbox toggles, suggestion batches, and image annotator strokes. History is bounded, per-document, and deliberately conservative: typing in a text field keeps the browser's native undo, and comments posted by agents or external tools never enter your history, so an undo can only ever touch your own work.

      Requested by @jj-valentine in #828.

      #1426, closing #828

      Slash commands return on OpenCode 2

      OpenCode 2's plugin API originally had no way for a plugin to execute a slash command, which left /plannotator-review, /plannotator-annotate, and /plannotator-last dead on V2. Upstream shipped exactly the hook that was missing (anomalyco/opencode PR #44765), and Plannotator now uses it: on hosts with the new API the three commands run natively again, opening the UI directly with no model turn and your arguments passed through untouched. Agent switching selected in the review UI also works again on those hosts.

      On OpenCode 2 builds that don't have the new API yet, the commands fall back to asking the agent to run the plannotator CLI, which works everywhere today. The native path takes over automatically as OpenCode builds update. OpenCode 1 behavior is unchanged.

      #1434, #1435

      Remote OpenCode 2 sessions show their URL

      Remote sessions are only usable if you can see the session URL, and on OpenCode 2 there was no visible place for it to land. Both the new native commands and submit_plan now post the URL as a notice directly in the session transcript, without waking a model turn. This came out of the release QA sweep rather than a field report, which is where you want to find it.

      #1435

      Share links stop serving stale snapshots

      When a teammate sent you a share link and you annotated their plan, the export kept offering the original short link back, without your annotations. The link lifecycle now tracks exactly which content a short URL was minted for and clears it the moment the content changes, so you can never send back a link that silently drops your feedback. The remaining piece, minting a fresh short link for small plans, is tracked in #1427.

      Reported by @grncdr in #798.

      #1425, closing #798

      Agent terminal works on npm 12

      npm 12 blocks dependency install scripts by default, which silently skipped node-pty's native build on Linux and left the annotate-mode Agent tab reporting "Agent unavailable" from a runtime that looked installed but couldn't load. The managed runtime now approves exactly that one build script, verifies the native binary actually exists after install, retries the build once if it doesn't, and fails loudly with the repair command instead of failing later in the UI.

      Reported by @smartobc-stephen in #1409, with a diagnosis accurate down to the fix.

      #1411, closing #1409

      Additional Changes

      • Herdr Annotate : the README and plannotator.ai now introduce Herdr Annotate, terminal-side annotation built on Plannotator TUI, with a landing page at plannotator.ai/tui-annotate. Annotations from the terminal land in the same Plannotator data directory, so both tools compound.
      • Firefox forced colors : the plannotator.ai hero text no longer disappears for Firefox users running with "Override the colors specified by the page" or OS high contrast.

      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.10 and restart Pi.

      OpenCode: Clear cache and restart:

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

      What's Changed

      • feat(review): mark files viewed as you scroll past them in #1430
      • feat: add bounded annotation undo and redo in #1426
      • feat(opencode): restore the slash commands on OpenCode 2 in #1434
      • fix(opencode): show session URLs in remote OpenCode 2 sessions in #1435
      • fix(share): invalidate stale short links in #1425
      • fix(agent-terminal): approve node-pty install scripts for npm 12 in #1411

      Community

      This release is community-shaped end to end. @jj- valentine requested undo/redo hotkeys for annotations in #828, and that request is now the bounded history system in both review surfaces. @grncdr filed the stale short-link report in #798 with a clean reproduction of the round-trip that dropped annotations. @smartobc- stephen reported the npm 12 agent- terminal failure in #1409 with a root- cause analysis so precise the fix followed it almost line for line. The auto- viewed feature and the OpenCode 2 command work both came from user reports and requests reaching us directly, and a Firefox user's report of vanishing hero text led to the forced-colors fix on the site.

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

      Full Changelog : v0.27.9...v0.27.10

    4. 🔗 anthropics/claude-code v2.1.252 release

      What's changed

      • Fixed Bash commands failing with "task output swap refused (tasks dir moved or linked)" on some Macs
      • Fixed "always allow" not saving in a project that has no .claude/settings.local.json yet
      • Fixed Remote Control sessions hosted by Claude Desktop or VS Code stalling for minutes after a tool finished when the connection to claude.ai was degraded
      • Fixed background task notifications with very large failure output (for example git errors on a full disk) making the conversation exceed the API request size limit
    5. 🔗 benji.dog rss

      four different styles of 40% mechanical keyboards

      Had a great time at this year's MN mechanical keyboard meetup and even got to see my friend David and his keyboards in real life!

    6. 🔗 MetaBrainz Search upgrades: Nov 30, 2026 rss

      MusicBrainz is announcing a set of upgrades for its search service on November 30, 2026. The main change will be upgrading Solr from version 9 to 10. Fixes and improvements will be released alongside this. Some of these changes may break some specific search requests. Finally, a new feature will be released making it possible to use the search service to search for (musical) genres. See below for more information.

      Breaking changes

      The following tickets may break search requests in some way.

      • SEARCH-444: Improper ‘relation-list’ in ‘area’ and ‘url’ JSON output. This will be a breaking change for accessing related entities in area and URL search results.
      • SEARCH-642: Drop ‘id’ fields for cdstub and tag. This will technically be a breaking change, but it was broken by design as the values for these search fields are not documented and have never been intended for public use anyway.
      • SEARCH-666: Use quality names rather than numeric IDs. This will be a breaking change for release searches that use quality search field.
      • SEARCH-752: Relationships have an extra ‘ target ’ property in JSON output. Fixing it by removing the redundant property target will be a breaking change if you are accessing it in search results. The “proper” way to do this is to use the property target-type and access the property id under the property named after this target type.
      • SEARCH-764: Upgrade to Solr 10. This will be a breaking change for mirror owners only, not for search requests. More specifically, it is advised to change the Solr configuration and to re-index the whole MusicBrainz database.

      Soft changes

      The following tickets will improve search with breaking any requests:

      • SEARCH-452: Index all URL relationships. So far, only URL relationships to Artist and Release were indexed. URL relationships to all other entity types will be indexed too.
      • SEARCH-646: Return exact match first for tag search. It should improve tag search results using indexed Solr search compared to direct Postgres search.
      • SEARCH-677: Include disambiguation of event’s place and work’s recording. Places related to searched events and recordings related to searched works will now be outputted with disambiguation comment, in the same way other related entities are outputted in search results.
      • SEARCH-680: Index genre annotations. It will add genre annotations to the results of annotation search which is already supported for all other annotation-able entity types.
      • SEARCH-681: Support indexed search of genres. It will add “Genre” as a target type for search, just like most other searchable entity types.
      • SEARCH-751: Missing ‘target-type’ property in ‘relationships’ of ‘event’ and ‘work’ JSON output. This will be fixed by adding the property where it is missing.
      • SEARCH-753: Missing ‘target-type’ property in ‘relationships’ of ‘area’ and ‘url’ JSON output. This will be fixed by adding the property where it is missing.

      Miscellaneous

      A MusicBrainz Server release is also expected to go with some of these changes.

      We’ll post upgrade instructions for standalone/mirror servers on the day of the release. If you have any questions, feel free to comment below or on the relevant above-linked tickets.

    7. 🔗 r/LocalLLaMA GLM 5.3 and GLM 5.3 Flash ran locally on RTX PRO 6000 WS and built a penthouse using BlenderMCP rss

      GLM 5.3 and GLM 5.3 Flash ran locally on RTX PRO 6000 WS and built a penthouse using BlenderMCP | I keep seeing demos of AI agents building scenes in Blender through BlenderMCP, so I tried it myself. I ran both models locally for this and picked the GLM 5.3 family(Q4 quant) because videos of it doing 3D work kept showing up in my twitter feed (out of curiosity, I ran the same prompt through the full GLM 5.3, also locally with a Q4 quant) these aren't small models, obviously, a 4-bit quantized Flash is around 190-200GB + headroom for context. full GLM 5.3 is around 450-470GB at 4-bit quantization (basically I went with the Q4 quants for both and the RTX PRO 6000 WS GPU, though I had to rent 4x rtx pro 6000ws for the flash model and 6x for the base one) writing the prompt wasn't as easy as I thought. my first attempts were vague and mostly produced 3D goo instead of an actual room. I eventually started specifying real dimensions: ceiling heights, stair rise, window mullion spacing and so on(the camera work was separately done by claude opus 5 so that I wouldn't have my token stats inflated by it)

      prompt

      model a luxury duplex penthouse in the open Blender session. footprint 20.0 x 13.0 m (260 sqm). main ceiling 2.9 m. a double-height volume 9.0 x 8.0 m rising to 6.2 m. mezzanine floor at 3.1 m with a 1.1 m balustrade. stair: 17 treads, rise 0.182, going 0.28. terrace 20.0 x 4.5 m at Z = -0.02 with a 1.15 m balustrade. curtain wall with mullions every 1.5 m, frame depth 0.06. doors 2.10 m. counters 0.90 m. dining table 0.74 m. sofa seat 0.42 m. materials, PBR ranges: glass IOR 1.45-1.52, transmission 1.0; concrete roughness 0.25-0.40; marble roughness 0.08-0.15; brushed metal metallic 1.0, roughness 0.25-0.35; fabric roughness 0.75-0.95. reference real penthouses for proportion. furnish it. do NOT add a camera. do not reset the session.

      at first it was putting up the curtain wall, stairs, mezzanine, the glass railing, all that, then at some point I noticed it had furnished the place too with some furniture: sofa, dining table and plates on it. the pendant lights were hanging from these 4 m cords, and for some reason it had modeled the individual spines on the books, which I never asked for the video only follows the camera through the living space, so the terrace and facade aren't visible(the clip is repurposed from another video I made with the same scene, I didn't render a new one because that takes quite some time)

      stats

      | metric | Flash | GLM 5.3
      ---|---|---
      objects | 811 | 847
      turns | 43 | 42
      tool errors | 9 | 8
      thinking before 1st object | 10s | 21m 55s
      time | 38m 52s | 40m 43s
      output tokens | 36K | 112K

      GLM 5.3 spent 22 minutes thinking(82k tokens), before placing any objects(as well as producing 36 more objects than GLM 5.3 Flash and consuming 3x times the output tokens), meanwhile GLM 5.3 Flash got to work almost immediately

      I measured both scenes afterwards by raycasting upward from the floor and checking the rooms against the brie. Flash got the double-height void right at 9 x 8 m. the full model built it at 9 x 4.5 m but reported it as 9 x 8 m

      This is obviously just an experiment, not a benchmark. Flash came surprisingly close on object count and total time while using less than one-third as many output tokens. it also got the main room dimensions right when the full model didn't

      if you want to try the same Blender setup, I used the community BlenderMCP project

      I'm a founder of atomic.chat, we have an app for running local models and our own quants(any feedback is appreciated, we're trying to make our products as good as possible for you guys)

      submitted by /u/Fun-Meaning-6474
      [link] [comments]

    8. 🔗 gildas-lormeau/single-file-cli v2.6.4 release

      SingleFile CLI 2.6.4

      Core

      Updated to single-file-core 1.5.119, which brings:

      • a self-extracting archive holding an embedded PDF extracts again. The zip library inlined in the page carries a code page table, the page declares windows-1252, and the table was read as text: every entry name the archive did not flag as UTF-8 decoded to garbage, which broke the extraction outright
      • a canvas is no longer blanked when a saved page is saved again. The picture is stored as a background image, and the second save read the empty canvas back over it
      • a script saved from a URL that does not end in .js is named .js in the archive. A module script was served back as video/mp2t or application/octet-stream when the archive was opened, and the browser refused to run it
      • the compression of a resource is decided from its content type when the server sent one, instead of from the extension in its URL. A script served as JavaScript from a .ts URL was stored uncompressed, 32 times larger than the same bytes named .js
      • replacing the invalid characters of a filename keeps every character: a run collapsed into one, so a page titled C++ was saved as C
      • the ellipsis of a truncated filename is counted in the length limit, which was overrun by three bytes

      Co-authored by Claude (Claude Code)

    9. 🔗 modem-dev/hunk v0.21.0-beta.0 release

      Hunk 0.21 beta

      This beta makes reviews more expressive, session connections safer, and the extension platform substantially more capable. It also restores first-frame and scrolling responsiveness after the new review features landed.

      Install the beta with:

      launch-v2.mp4

      npm install -g hunkdiff@beta

      Compare any two revisions

      hunk diff <from> <to> now performs backend-native two-revision reviews across Git, Jujutsu, and Sapling. Source expansion stays pinned to the compared revisions, and hunk diff --files <left> <right> explicitly compares two files. #938

      Threaded review conversations

      Inline notes are now editable and support arbitrarily nested replies with keyboard and mouse actions. Reviewers can also dismiss reply-free live agent notes without leaving the review flow. #925

      Safer live sessions

      The local session broker now authenticates producers and CLI controls with owner-private credentials and signed responses. Hunk can safely replace an incompatible idle daemon and reconnect active terminal sessions without manual intervention. #932 #933

      A more adaptable review UI

      • The file sidebar adapts to terminal width and expands its tree at full width. #921
      • Built-in and extension panes support responsive fractional sizing. #924
      • File and hunk spacing are configurable. #865
      • Diff colors and word emphasis are corrected across roughly 25 bundled themes. #825 #828
      • First paint, navigation, and scrolling remain responsive in large review streams. #922 #942

      Extension API generations 9–14

      Extensions can now:

      • register generic top-level CLI command trees with streaming I/O and delegation; #888
      • select syntax languages by filename or glob; #851
      • use a dim line-highlight tone; #909
      • size panes responsively;
      • observe hunk_viewed and saved note_changed events; #939
      • follow the current source line from an opted-in pane; and #940
      • receive structured two-revision rangeEndpoints in VCS adapters.

      Compatibility notes

      • npm installs now require Node.js 22 or newer. Standalone Hunk binaries still run without Node.js. #917
      • hunk diff <from> <to> gives two positional arguments revision semantics. Existing scripts that used the second positional argument as a pathspec should use an explicit supported form instead.
      • Custom VCS adapters should handle extension API generation 14's rangeEndpoints request variant to support two-revision comparisons.

      Community contributors

      Thank you to everyone who contributed to this release:

      Please report beta issues on GitHub or in the Hunk Discord.

      Full changelog: v0.20.1...v0.21.0-beta.0

    10. 🔗 exe.dev Revisiting Joel's Test rss

      Back in 2000, Joel Spolsky wrote an influential blog post, The Joel Test: 12 Steps to Better Code, for quickly identifying whether a software team is high-functioning. These are the twelve questions he nailed to the Internet.

      1. Do you use source control?
      2. Can you make a build in one step?
      3. Do you make daily builds?
      4. Do you have a bug database?
      5. Do you fix bugs before writing new code?
      6. Do you have an up-to-date schedule?
      7. Do you have a spec?
      8. Do programmers have quiet working conditions?
      9. Do you use the best tools money can buy?
      10. Do you have testers?
      11. Do new candidates write code during their interview?
      12. Do you do hallway usability testing?

      Those questions are still relevant, but, with the advent of agents, there are more questions. I’m calling this the Shelley Test, after our coding agent, which is named for the Unix shell, Mary Shelley, and Percy Bysshe Shelley:

      1. Do you use agentic code review?
      2. Do you deploy continuously, supervised by LLM agents?
      3. Do you have end-to-end integration tests?
      4. Do you and your coding agents have easy access to observability tooling?
      5. Do you have access to the latest models from the best providers?
      6. Do you have a merge queue and does it complete in 3 minutes or less?
      7. Is it easy for your team to stand up new tools and agents, for development and to help with everything around development?
      8. Do your team members regularly discuss their tools, their workflows, and adjust when necessary?
      9. Is your product legible to coding agents as users?

      1. Do you use agentic code review?

      Peer-based code review is dead. The LLM is writing the code, and the engineer is responsible for it. Adding a rubber stamp, however delayed, from another human, is done for. (Even on the best teams, we all know that a small, targeted change might generate a long code review cycle and a bike-shedding session, whereas if you combine two weeks’ worth of changes and dump them on your neighbor, it’s LGTM.)

      Instead, ask your agent to use subagents with different models to do an adversarial code review to check that what’s in the commit is what’s on the tin, and it will do wonders. (Does your harness only support one family of models? Use a harness that doesn’t kneecap you.) See also “Review the Reviews” and Roborev.

      2. Do you deploy continuously, supervised by LLM agents?

      We are not dogmatic about whether this means once an hour, on every commit, or once a day, but inventory in your repo will face reality, and it is paramount that it does so soon. Shorter cycles are better. Continuous deployment requires integration tests that you can trust, and that’s a good thing. It also requires feature flag infrastructure; also a good thing.

      Athena, our bot that supervises continuous deployments, is now indispensable. It reads logs, checks metrics, and writes down lessons for the next deploy. Athena chats on Slack about it, and has the power to pull the plug on a deploy.

      If you’ve been holding back on continuous deployment because you’re not confident that your deployment platform has all the right metrics gates, abandon that project immediately, and write yourself an Athena agentic loop. It’s deeply embedded in our deployment control center software, but write to us if you want us to extract the heart of it. (And yeah, we give our bots names so they’re easy to refer to).

      3. Do you have end-to-end integration tests?

      When a bug inevitably sneaks through, you have found where your testing is insufficient. LLMs are great at tests. (See, for example, this commentary on the Go cryptography standard testing.) Having the integration test infrastructure in place allows you to feel confident that deploys won’t break core functionality.

      Incidentally, if you must have an external dependency, “digital twins” for that dreaded external API have never been easier to build.

      4. Do you and your coding agents have easy access to observability

      tooling?

      In the LLM age, a monitoring stack must be computer-queryable, preferably with SQL, preferably with business data available to JOIN with. (At exe.dev, we love Clickhouse.)

      Use a bot to do initial triage and maintenance of alerts. Our bot is called Sisyphus.

      Instead of using the observability tool (or its agent) to look at metrics and diagnose tricky customer bugs, point your regular coding agent to the observability tool. Combining code and logs is fire.

      A Slack message from the exe.bots app: Sisyphus triaging an error-logs alert with evidence, an assessment, and a recommended next step. Sisyphus triaging an alert in Slack.

      5. Do you have access to the latest models from the best providers?

      This is a repeat of Joel’s “Do you use the best tools money can buy?” Joel’s question is being tested as CFOs find out that an extravagant IntelliJ or Tableau subscription is the least of their worries now.

      6. Do you have a merge queue and does it complete in 3 minutes or less?

      Don’t use long-lived branches. Commit your changes to main, and keep main green. The way to do so is to run the tests before they are merged in. The faster your tests, the easier this is!

      Your merge queue will get backed up (or require cleverness) if it’s slow. Engineering with LLMs is starved for human attention: the long latencies destroy that attention.

      We’ve abandoned GitHub Actions since https://sketch.dev/blog/lightweight- merge-queue was written, but the basics are still functioning.

      Agents are incredible at speeding up your CI if given the opportunity. The last build at time of writing took 2m30s or so, used many, many lanes of parallelism on one big honkin’ machine, and had acceptable CPU utilization, though the 60s tail leaves much room for improvement!

      A CPU usage chart for the build machine, ramping to about 75% for most of the build and then trailing off over the final 60 seconds. CPU utilization across one build A CI pipeline waterfall: dozens of build and test lanes running in parallel, nearly all finishing in about a minute. 54 lanes, mostly parallel. 2.5 minutes.

      7. Is it easy for your team to stand up new tools and agents, for

      development and to help with everything around development?

      The prior math on whether it’s worthwhile to build a tool is now wrong, because coding agents build very passable tools in one-shot. It must be easy to host and iterate on these tools.

      8. Do your team members regularly discuss their tools, their workflows,

      and adjust when necessary?

      We are in an age of exploration, and sharing what is working (and not working) with your peers is imperative. It’s always been a good idea, but now you’re missing out on the compounding effects if you don’t do it. We do this constantly: on Slack, on the telephone, and in our team meetings.

      9. Is your product legible to coding agents as users?

      Your users are judging your software based on whether Claude Code can operate it. Can it? Do you have an llms.txt as very obvious documentation? Does auth work? APIs are king again.

      Not to get all Clayton Christensen up in here, but a worse product operated by a mid-tier coding agent is destroying the better product unavailable to the coding agent.

    11. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +2 releases, -1 release rss 
      sync repo: +1 plugin, +2 releases, -1 release

## New plugins
- [BinDiff-NG](https://github.com/mahmoudimus/bindiff-ng) (8.1.1)

## New releases
- [IDAssist](https://github.com/symgraph/idassist): 2.3.0

## Changes
- [IDAssist](https://github.com/symgraph/idassist):
  - removed version(s): 1.2.0
    12. 🔗 gildas-lormeau/single-file-cli v2.6.3 release

      SingleFile CLI 2.6.3

      Core

      Updated to single-file-core 1.5.118, which brings:

      • fonts declared inside a frame are no longer all removed when the frame's content cannot be read. Such a frame is re-parsed from its srcdoc, and a document that is never rendered says nothing about the fonts it draws with, so text in those frames fell back to a system font
      • replacing a stylesheet element keeps the attributes that identified it: an id a script looks up, a class a selector matches, data-* and title. Plain saves lost them on every page with an external stylesheet
      • a stylesheet shared by duplicate &lt;style&gt; elements is stored once in an archive, instead of once as the entry the links point at and once in the page
      • saving an archive no longer asks the captured site for a zip worker three times. The file was never there, and the archive was always written on the main thread anyway
      • a font-family naming a custom property whose value names another custom property is resolved when removing unused fonts
      • a font value that cannot be resolved no longer switches off font removal for the whole document. The fonts the page actually rendered decide instead, so a page holding one unreadable value is smaller
      • vendor-prefixed values the browser supports are kept

      Co-authored by Claude (Claude Code)

    13. 🔗 r/LocalLLaMA deepseek-ai/DeepSeek-V4-Flash-Vision-Exp · Hugging Face rss

      deepseek-ai/DeepSeek-V4-Flash-Vision-Exp · Hugging Face | submitted by /u/t4a8945
      [link] [comments]
      ---|---

    14. 🔗 r/LocalLLaMA Could this affect M5 Ultra price/availability? rss

      Could this affect M5 Ultra price/availability? | submitted by /u/No_Conversation9561
      [link] [comments]
      ---|---

    15. 🔗 Cal Paterson Agent memory as a file format rss

      Memoryfields - a vastly simpler way to do agent memory

    16. 🔗 matklad Cancelation Terminology rss

      Cancelation Terminology

      Aug 31, 2026

      A short note explaining the difference between synchronous cancelation, asynchronous cancelation, and graceful shutdown. I am not too attached to these specific three terms , but I want to call your attention to the three things behind them, which are important not to confuse with each other.

      synchronous cancelation is an (often implicit) control flow structure. It unwinds the stack and looks like this:

      task.cancel();
// The task will have finished by this point.

      Synchronous cancelation is a bit like Moliùre’s prose — we do it all the time, but not necessarily in full consciousness. The primary source of synchronous cancelation is error handling — every time an Exception is thrown or an error returned, the code promptly breaks out of all the loops, ifs, and blocks, invoking the necessary cleanup actions via RAII, finally, with/try with resources or defer.

      asynchronous cancelation is a communication protocol between two parties. One party requests cancelation (synchronously), but then it has to wait until the other party acknowledges it and winds down. It looks like this:

      task.request_cancelation();
// The task could still be running here.
task.join().await;
// After the requisite wait, the task is finished.

      Like synchronous cancelation, this is a relatively low-level concern when implementing a concurrent program in a way that doesn’t crash or hang. I know two central example where an asynchronous cancelation is required.

      First is the CPU thread pool. Imagine you have offloaded encrypting a buffer to a separate thread as a part of handling user’s request. Some time later, you learn that the request must be canceled (perhaps the user had left). You can’t just abandon the encrypting thread. First, it would be smart not to waste CPU cycles for useless work, but, more importantly, the underlying buffer must remain tied up. If it were to be freed as a result of request cancelation, something else might re-use that memory, leading to data races.

      But you also can’t just cancel that thread synchronously! It’s in the middle of a hyper-optimized SIMD loop, and you really don’t want it to check the cancelation flag before reading every byte. What you’d want is to split the buffer into reasonably-sized chunks, and check the cancelation status after every chunk. But that means that the party that requested the cancelation must wait for at least one chunk’s worth of work!

      For the curious, there’s actually a bit more leeway with canceling CPU work non-cooperatively, see

      https://go.dev/src/runtime/preempt.go

      Another example here is io_uring. It has exactly the same shape: if you submit a write with a buffer to the kernel, that buffer must remain tied up until the write finishes (and you can cancel the write to make it finish faster). While io_uring is still at least a somewhat exotic technology (though, arguably, it’s the interfaces we have had before which are byzantine), the thread pool example demonstrates that the phenomenon of asynchronous cancelation itself is rather mundane.

      Asynchronous cancelation comes up all the time when writing concurrent software. Because it affects the overall shape of the code, it’s useful to identify it early. Conversely, it is useful to ask yourself whether you need asynchronous cancelation at all, and whether synchronous one can be made to work. This is especially important in Rust, which makes synchronous cancelation too easy, and doesn’t provide great mechanisms for asynchronous one.

      Finally, graceful shutdown is an application programming pattern for handling connections. It lives on a higher level of abstraction than the two cancelations. If you are implementing a web service, you can implement shutdown by stopping your accept loop (rejecting new connections), but continuing to serve all existing connections until their respective clients disconnect. If the load balancer is configured to route new connection requests to different instances of the service, this pattern allows you to do rolling upgrades without service disruptions.

      As a bonus point, a related idea is that of crash-only software. Cancelation is all good, but your entire program can get SIGKILLed arbitrarily by an OOM killer, and the entire computer might get rebooted on powerloss. Reliable software has to handle ungraceful shutdown without losing data. But, if you can survive powerloss, you might as well implement the Quit button by SIGKILLing yourself, simultaneously simplifying the implementation and increasing testing coverage for powerloss scenarios.

      To give some examples from TigerBeetle, Grid.cancel is an asynchronous cancelation. It takes a callback to notify the caller when the cancelation is done. This API is used during state sync. When a replica determines that that cluster is so far ahead that event based transfer doesn’t work, and that a state transfer is required to catch up, it must cancel all outstanding grid read operations. A read can be backed either by replica’s local disk, or by transparent fetch of the data from a neighboring replica. In the first case, we have to wait until the read is done. In the second case, we need to abandon the read — remote read getting stuck is probably the reason for us to state sync in the first place.

      StateMachine.reset is an example of a synchronous cancelation. This is the part of the same flow as Grid.cancel, and is an example of how you can simplify the code if you think clearly about asynchronous vs synchronous cancelation. Ultimately, StateMachine sits on top of the Grid, but there’s a bunch of intermediate layers (Forest, Tree, Compaction, Scan, etc). A naive approach would be to notice that Grid requires asynchronous cancelation and propagate asynchrony throughout the stack. What we do instead is asynchronously canceling just the Grid directly, and then synchronously reseting everything else.

      Another example of asynchronous cancelation is Client.shutdown. When an application using TigerBeetle “drops” the Client object, we need to free all OS resources. Our client also uses io_uring, so we must first wait for all outstanding syscalls to complete. In the comment, we call it “graceful shutdown”, but I think this is wrong, and this is the motivation for writing down this article. We don’t do graceful shutdown at TigerBeetle — it’s crash only all the way. Tail latency tolerance (asking several nodes for an answer and picking the fastest one) is a more general solution, as it handles not only crash faults, but also gray failures. In a distributed system, a very slow node looks exactly the same as a crashed one. A crash is just a degree of slowness.

      Take aways:

      • Synchronous cancelation is control flow operator
      • Asynchronous cancelation is a communication protocol
      • Graceful shutdown is an application-level design pattern
    17. 🔗 Servo Blog July in Servo: more platforms, faster canvas, web fonts in SVG, and more! rss

      Servo 0.5.0 contains all of the changes we landed in July, which came out to 488 commits , and we now publish binaries for Linux aarch64 (@mukilan, #46760)!

      DOM text selections are now visible (@mrobinson, @SimonSapin, #46698, #46864, #46742, #46889, #46126). Interactive selection is coming soon!

      For security fixes, see § Security.

      servoshell 0.5.0 showing several new features: ‘text-decoration-thickness’, ‘box-decoration-break’, web fonts in inline &lt;svg&gt;, and DOM selection rendering

      We’ve shipped several new web platform features:

      Plus a bunch of new DOM APIs:

      This is another big update, so here’s an outline:

      You can help! If you’re working on a pull request that you think might be interesting for the next monthly update, even if you’re not 100% sure, tell us about it by following the steps below: You add the monthly update label to your pull request, or comment [@servo-highfive](https://github.com/servo-highfive) monthly update Highfive posts a comment asking you some questions You answer those questions in a comment containing [@servo-highfive](https://github.com/servo-highfive) monthly update answer Security __ Servo was potentially affected by vulnerabilities in quick- xml and crossbeam- epoch that have been fixed in Servo 0.5.0 (@atouchet, @Loirooriol, #46737, #46324). For more details, see RUSTSEC-2026-0194, RUSTSEC-2026-0195, and RUSTSEC-2026-0204. We’ve updated ANGLE from a version based on Firefox 115.x ESR (02755361e26d8) to a version based on Firefox 140.12.0 ESR (f8025617e815f), which likely includes many security fixes (@jschwe, @sagudev, #46455, mozangle#100). Real world compat The duck on the DuckDuckGo (duckduckgo.com) landing page now renders in v0.5.0, after we fixed a preload bug that affected SVG images (@jdm, #46668). v0.4.0 v0.5.0 duckduckgo.com Most of Gumroad (gumroad.com), except for the landing page, did not render at all in v0.4.0, but as of v0.5.0, pages like the Discover page or this product page render almost perfectly. v0.4.0 v0.5.0 gumroad.com v0.4.0 v0.5.0 gumroad.com We’re interested to hear how well your favourite websites run in Servo! Report successes in this Zulip thread, and failures in our GitHub issues. Work in progress

      The upgrade to Stylo 2026-07-01 brings several changes to built-in CSS functions (@Loirooriol, #46129):

      • ‘alpha()’ is now supported, under --pref layout­_css­_alpha­_color­_function­_enabled

      • ‘progress()’ is now supported, under --pref layout­_css­_progress­_function­_enabled

      • ‘ellipse()’ values ‘closest-corner’ and ‘farthest-corner’ are no longer stable due to spec uncertainty, but they are still experimental, under --pref layout­_css­_ellipse­_corners­_enabled

      • ‘attr()’ is more conformant, under --pref layout­_css­_attr­_enabled

      Web­GPU content can now enjoy better conformance and use GPU­External­Texture and import­External­Texture() on GPU­Device , under --pref dom­_webgpu­_enabled (@sagudev, #45873, #46178, #46286).

      servoshell 0.5.0 showing four tilted rectangles (in WebGPU), textured with a picture of a dog (which is a frame from an external video)

      Indexed­DB content can now use the name property on IDB­Index , under --pref dom­_indexeddb­_enabled (@skyz1, #45512).

      document.fonts now includes a Font­Face for each valid ‘@font- face’ , under --pref dom­_fontface­_enabled (@simonwuelker, #46509, #46537).

      All of the features above are enabled in servoshell’s experimental mode.

      We’ve started implementing WebVTT for native subtitles and captions , enabled by default (no --pref). While they don’t render just yet, we can now fetch each , parse the WebVTT, and expose cues via the track property on HTML­Track­Element (@TimvdLippe, #46289, #46383).

      July was a big month for accessibility in Servo, under --pref accessibility­_enabled. The focus for this month has been on performance , with the accessibility tree now supporting incremental updates (@alice, @delan, #45578, #45971, #46589, #46691, #46385), requiring fewer HashMap lookups and tree walks (@alice, @delan, #45798, #46740, #46348), and allowing for faster DOM mutations (@alice, #46348, #46530).

      We’ve also started working on the File and Directory Entries API, to allow users to select and upload entire directories via < input type=file> and drag-and- drop. To that end, we now have webkit­Get­As­Entry() on Data­Transfer­Item , plus minimal support for File­System­Entry , File­System­Directory­Entry , and File­System­File­Entry , under --pref dom­_entries­_api­_enabled (@yezhizhen, #46456, #46879, #46832).

      Embedding API We’ve improved the docs for the servo crate, and for Web­View­Delegate (@mukilan, #46193). Breaking change: Servo­Builder::webxr­_registry() has been removed. Instead use the new Servo::register­_webxr­_registry, which is a lazy design that has allowed servoshell to halve its startup time (@Narfinger, #46494). For users and developers

      servoshell for Android now runs on Android 10+ (91% market share), not just Android 13+ (68% market share), improving adaptability and reducing waste (@jschwe, #46142, #46308). We’ve also fixed a problem with building for Android on macOS (@jschwe, #46128).

      servoshell for Windows is now better behaved when run in a console window, making the command prompt wait until servoshell exits (@yezhizhen, #43010).

      When using the Firefox DevTools , the Console tab now supports some basic autocomplete (@freyacodes, #46382).

      We’ve finished modernising servoshell for Android to use Compose UI (@veyndan, #46085, #46164, #46253, #46257, #46317, #46353, #46565, #46612, #46626, #46666, #46663, #46700), and we’re now migrating Servo as a library to use Kotlin (@veyndan, #46817, #46895, #46772).

      More on the web platform Inline SVG can now use web fonts defined in the containing page (@yodalee, #45979). We’re also implementing the SVG DOM , starting with stub interfaces for SVG­Element , SVG­Circle­Element, SVG­Defs­Element, SVG­Ellipse­Element, SVG­Line­Element, SVG­Linear­Gradient­Element, SVG­Path­Element, SVG­Polygon­Element, SVG­Polyline­Element, SVG­Radial­Gradient­Element, SVG­Stop­Element, SVG­Rect­Element, SVG­Symbol­Element, and SVG­Use­Element (@mu- mostafa98, #46558). < button> now vertically centers its contents (@Loirooriol, @mrobinson, #46590), and behaves better with ‘display: block’ and ‘display: inline’ (@Loirooriol, #46536). We’ve improved the conformance of < form> without < form action> (@kevlu93, #46860), < color> values (@Loirooriol, #46129), Gamepad­Event (@log101, #46788), document.execCommand(“delete”) (@Psychpsyo, #46539), the selector­Text property on CSS­Style­Rule (@simonwuelker, #46687), and Set Window Rect in WebDriver (@janeoa, #46475, #46477). We’ve fixed bugs related to < iframe> (@jschwe, @jdm, #46587), < img> (@yodalee, #46892), < textarea> (@SimonSapin, @mrobinson, #46309), custom properties (@Loirooriol, #46129), ‘::before’ and ‘::after’ (@Loirooriol, #46640), ‘flex-direction: column’ (@simonwuelker, #46697), ‘float’ (@Loirooriol, @mrobinson, #46407, #46500, #46505), ‘@font-face’ (@simonwuelker, #46568, #46271, #46436), ‘position: absolute’ (@simonwuelker, #46358, #46637), Blob (@jdm, #46881), IDB­Database and IDB­Object­Store and IDB­Index (@mrobinson, #46615), the adopted­Style­Sheets property on Shadow­Root (@simonwuelker, #46738), delete() on Font­Face­Set (@simonwuelker, #46634), move­Before() on Element (@mrobinson, #46599), resize­To() on Window (@janeoa, #46477), the selected property on HTML­Option­Element (@rhit-kapilaar, #46386), and the value property on HTML­Select­Element (@simonwuelker, #46230). Performance and stability

      2D canvas rendering is now multithreaded , improving frame rates by up to 55% and power consumption per frame by up to 42% (@yezhizhen, #46410), and should use a lot less memory too (@jschwe, @sagudev, #46786).

      Text rendering is up to 10x faster for cases with the same text and different ‘font-size’ (@Loirooriol, #46129).

      Flex layout benchmarks are up to 3% faster, and an improvement to get­Elements­By­Class­Name() has made some websites up to 1% faster (@Narfinger, @jdm, #46563, #46595, #46594).

      We’ve also reduced memory usage, allocations, GC rooting steps, and other operations in many parts of Servo (@mrobinson, @jdm, @yezhizhen, @Narfinger, @Gae24, @SimonSapin, @Taym95, @cychronex- labs, @arayaryoma, #46499, #46411, #46659, #45974, #46377, #45758, #46440, #46762, #46301, #46349, #46419, #46418, #46420, #46460, #46633, #46638, #46690, #46745, #46726, #46564, #46144, #46664, #46462, #46139, #46430, #46446, #46498, #46548, #46598, #46632, #46656, #46678, #46718, #46722, #46238, #46072, #46408, #46438, #46437, #46528, #46124, #46330, #46412, #46807).

      We’ve fixed a crash regression with memory corruption (@mrobinson, #46316), several dynamic-borrow- related crashes (@Narfinger, @SharanRP, @Taym95, @agrawalx, @amittenak47, @sungmen, #46381, #46384, #46405, #46684, #46452, #46770, #46830, #46763), plus crashes related to:

      We’ve continued our long-running effort to use the Rust type system to make Servo’s integration with SpiderMonkey safer and more reliable (@Gae24, @Narfinger, @TimvdLippe, @jdm, @kunalmohan, @lumiscosity, @simonwuelker, #46191, #46777, #46890, #46243, #46248, #46246, #46310, #46312, #46333, #46147, #46150, #46151, #46229, #46262, #46375, #46374, #46529, #46584, #46585, #46593, #46693, #46166, #46156, #46254, #46267, #46268, #46269, #46270, #46284, #46285, #46318, #46435, #46461).

      New contributors A special thanks to the following people for landing their first patch in Servo: Umut Cevdet Koçak (@UMCEKO, #46256) Yash Agrawal (@agrawalx, #46770) amittenak47 (@amittenak47, #46743) Apoorva Pendse (@apoorvapendse, #46739) dDostalker (@dDostalker, #46181) Oisín Ó Maolchathail (@eachra-bawn, #46478) Kevin Lu (@kevlu93, #46860) Mohamed Mostafa (@mu-mostafa98, #45405) SeongMan Jeon (@sungmen, #46763) Yoda Lee (@yodalee, #45979) Interested in helping build a web browser? Take a look at our curated list of issues that are good for new contributors! Donations __

      Thanks again for your generous support! We are now receiving 7824 USD/month (+1.8% from June) in recurring donations. This helps us cover the cost of our speedy CI and benchmarking servers, one of our latest Outreachy interns , and funding maintainer work that helps more people contribute to Servo.

      Servo is also on thanks.dev, and already 35 GitHub users (same as June) that depend on Servo are sponsoring us there. If you use Servo libraries like url, html5ever, selectors, or cssparser, signing up for thanks.dev could be a good way for you (or your employer) to give back to the community.

      We now have sponsorship tiers that allow you or your organisation to donate to the Servo project with public acknowlegement of your support. If you’re interested in this kind of sponsorship, please contact us at join@servo.org.

      7824 USD/month

      10000

      Use of donations is decided transparently via the Technical Steering Committee’s public funding request process , and active proposals are tracked in servo/project#187. For more details, head to our Sponsorship page.

    18. 🔗 Ampcode News Space to Talk rss

      Every thread in Amp now comes with its own space to talk.

      Hit Enter and you're in. Turn on your camera, share your screen, and talk it over with your team while the agent works.

      No links to paste, no calendar invite, no other app. The call lives where the work lives.

      In the future, we see the space becoming a place to talk freely, alone or with others: brainstorm, whiteboard, talk with Puck or other agents, discuss the thread or spawn new ones... who knows?

      We're leaving it open. For now, it's just a space. What you do with it is up to you.

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

      IDA Plugin Updates on 2026-08-30

      New Releases:

      Activity:

    2. 🔗 Simon Willison Understanding ChatGPT Work rss

      OpenAI announced ChatGPT Work on July 9th, and have been furiously iterating on it ever since. It is an extraordinarily confusing and very powerful product. Here's what I've figured out about it so far.

      ChatGPT Work is actually two products

      The more interesting version of ChatGPT Work is the one that runs in the cloud. This can be accessed via chatgpt.com or through the ChatGPT mobile apps. Let's call it Work Cloud.

      If you install the ChatGPT desktop app - the app that used to be called Codex - you gain access to a thing called ChatGPT Work that can access files and run programs directly on your computer. Let's call that one Work Local. This one feels more like regular Codex re-skinned to be less intimidating to non-software-developers.

      (Update: Work Cloud is also available from the ChatGPT desktop app, via a Where should this chat run? dropdown.)

      For the rest of this article I'm going to talk exclusively about Work Cloud.

      Work is for paid subscribers only

      Right now, ChatGPT Work (in both flavors) is available only to $20/month and up subscribers. Free users and $8/month Go users do not have access.

      Work has features that aren't available in Chat

      The interface for accessing Work is a tab selector, which presents it as an alternative to Chat:

      ChatGPT app header with a Chat and a Work tab

      The obvious question is when should I use Chat, and when should I use Work?

      OpenAI's official answer to that question is:

      Use Chat when you want an answer, explanation, brainstorm, or short draft. Use ChatGPT Work when you want ChatGPT to complete a task with a clear outcome, such as a brief, deck, analysis, recurring update, workflow, or file you can review and use.

      I find that almost entirely useless, because I've been using regular ChatGPT Chat for all of those task categories for years!

      The better question then is what features does Work have that are missing from Chat?

      After extensive experimentation I think I've mostly figured that out:

      Model selection

      In Work, you get the option to pick GPT-5.6 Sol, Luna, or Terra, each with Light, Medium, High, Extra High, Max, or Ultra reasoning levels. You can also pick GPT-5.5 at Light, Medium, High, or Extra High.

      These look to be the same models that are available through the OpenAI API.

      Chat offers a different selection: 5.6 Instant, Medium, High, Extra High, and Pro (actually Extra High and Pro are only available for $100/month+ subscribers - $20/month subscribers cap out at High). It doesn't explain if those are Luna or Terra or Sol (I'm assuming Sol?). 5.6 Pro appears to be exclusive to Chat, with no equivalent in Work.

      My current understanding from using Codex is that Ultra is a special mode that more eagerly delegates to sub-agents.

      I believe ChatGPT Work sessions are billed against your Codex allowance, while ChatGPT Chat Sessions get their own, separate allowance. This may help explain the model availability differences.

      Code execution with Internet access!

      As a long-time fan of the Code Interpreter pattern - pioneered by OpenAI in 2023 - this is by far the most exciting feature of ChatGPT Work (Cloud) for me.

      The code execution environment can now talk to the rest of the internet!

      ChatGPT Chat can't do this - if you ask it to install additional software packages or interact with websites or APIs that access will be blocked by the container proxy.

      (Weirdly, back in January it grew the ability to install packages, but that doesn't seem to work any more. I wish they had better changelogs!)

      Claude's equivalent container has allowed restricted internet access since it launched last September. Claude can install packages from PYPI and NPM and clone repositories from GitHub. But that is about it: the allowlist of domains is very short.

      ChatGPT Work allows a whole lot more than that. It can be configured with a specific list of allowed domains, but the default appears to be open to all.

      This makes Work an incredibly useful tool. You can have it clone GitHub repositories, install their dependencies, then use them to interact with the rest of the web!

      A full, headless Chrome browser

      Another killer feature of ChatGPT Work is the browser tool. ChatGPT Work can launch a full Chrome instance, load websites, fill out forms, and take screenshots.

      Screenshot of a ChatGPT conversation. A user message in a black rounded bubble reads: Visit https://london-pelicans-in-her-piety.simonw.chatgpt.site/ and take a screenshot with you browser. Below it a collapsed status line reads "Worked for 1m 18s >", followed by the reply "Here's the screenshot of the live site:" and an embedded screenshot of a website.

      If a site requires sign in the browser can prompt you to take over and enter both passwords and 2FA codes, without round-tripping those credentials through the model itself.

      It can even run JavaScript against the DOM of loaded pages. I prompted:

      Load simonwillison.net in your browser and extract the headings using JavaScript

      ChatGPT Work fired up a browser instance and ran the code:

      await tab.playwright.evaluate(() => {
  return Array.from(document.querySelectorAll("h1,h2,h3,h4,h5,h6"), heading => ({
    level: heading.tagName.toLowerCase(),
    text: heading.innerText.trim().replace(/\s+/g, " "),
    id: heading.id || null
  }));
});

      This feels a lot like my shot-scraper javascript tool, only now I can access it on my phone!

      A persistent, shared filesystem

      ChatGPT Chat gets a fresh filesystem for each chat session. These cannot be accessed from any other session.

      In ChatGPT Work each session gets its own scratch folder - named something like /workspace/scratch/e00a0a017944 - but each of those are persisted across sessions, so you can access files from previous chats. I have 171 folders in /workspace/scratch right now!

      As far as I can tell that /workspace volume is mounted to all Work sessions that are currently running - file edits from one can be instantly seen by the others. They don't seem to share the same process space though, and localhost servers running in one can't be accessed from another.

      ChatGPT Sites

      ChatGPT Work has the ability to build and deploy entire websites, using Cloudflare Workers. These can have HTML and JavaScript and can run server-side features too, including stateful features on top of Cloudflare D1 and R2.

      Here's a simple site I built with this feature:

      london-pelicans-in-her-piety.simonw.chatgpt.site

      Screenshot of a website homepage on a cream background. Top navigation bar: a circular logo reading "P/P" on the left, the links "THE CENSUS", "COLLECTIONS" and "METHOD" in the center, and "JSON ↓" on the right. The left half is a hero section with small red capitals reading "AN ICONOGRAPHIC CENSUS · GREATER LONDON" above a large serif heading "Pelicans in her piety", with "piety" set in red italics. Below it: "Across London, an impossible bird bleeds for her young—in limewood, marble, mosaic, metal and glass. This is an evidence-backed census of where to find her." Two buttons follow: a solid black "EXPLORE ALL 28" and an outlined "DOWNLOAD THE DATA". The right half is a photograph of an ornate dark carved wooden reredos in a church, with gilded urns and a crest on top, Corinthian columns, a gilded pelican with outspread wings at its center above inscribed panels, an altar with a brass cross and red flowers, embroidered banners on either side, and a black-and-white checkerboard floor with red carpet. Vertical text along the photo's right edge reads "ST MARY ABCHURCH" and a caption at its bottom reads "Grinling Gibbons's reredos, St Mary Abchurch. Photograph: Diliff, CC BY-SA 3.0, via SPAB ↗". A statistics strip along the bottom shows "28 FIXED SITES", "4 COLLECTIONS", "3 OPEN LEADS" and "2 KNOWN LOSSES".

      My prompt was:

      Figure out all of the places in London with a pelican in her piety, then turn that into a JSON file and build a ChatGPT sites site about them

      (A pelican in her piety is a fascinating piece of medieval Christian imagery - once you know about them you'll find them all over the place.)

      These sites default to being private to the user that created them, but you can make them public and (on team plans) share them with other specific individuals.

      Sub-agents with Sol, Luna, and Terra

      There's not much to say about this one. ChatGPT Chat can't run sub-agents. ChatGPT Work can. This is very much a power-user feature: if you are running a complex project that can benefit from multiple parallel agents working together, Work can do that.

      Scheduled prompt automations

      Another feature that seems to have migrated from regular ChatGPT to ChatGPT Work at some point. You can prompt ChatGPT Work like this:

      run a search to see if Waymo have announced a launch date for Half Moon Bay every day at 8am

      This will schedule a prompt to run on that frequency. These prompts can decide that nothing interesting has happened, or they can decide to notify you of some new information.

      Update: Actually this seems to work in ChatGPT Chat as well.

      It's still worth noting here though, as it can be used in conjunction with other ChatGPT Work exclusive features. You can set a scheduled task to update a ChatGPT Site on an hourly basis, for example.

      Is this safe?

      An open question for me right now is how safe all of this stuff is.

      My lethal trifecta model warns about the risks inherent in any agent system that combines access to private data with exposure to untrusted content and a way to communicate stolen information back to an attacker.

      ChatGPT Work combines all three!

      I'd love to hear more from OpenAI about how they protect ChatGPT Work sessions against prompt injection attacks. I expect their answer is the same auto-review mechanism as Codex.

      OpenAI could make this a lot less confusing

      Figuring this all out took way more work than it should have.

      I think there are two key problems here:

      1. OpenAI explain Work in terms of what it's for, not what it actually does
      2. OpenAI still insist on hiding their system prompts and tools descriptions

      If the ChatGPT Work documentation included the exact system prompt and tool descriptions used by the agent I wouldn't have needed to write this post.

      A list of all the tools

      Shortly after publishing this article I had an idea. I started a fresh Work session and prompted:

      Build a site that lists every one of your tools - nearly grouped into categories - and for each one explain what it does. Try to exactly duplicate arguments and tool descriptions where possible. Design aesthetic should be technical docs, minimal flare

      Here's the site it built, which includes details of 223 registered tools - though 6 of those are from my own personal MCPs served via datasette-mcp.

      And a whole lot of Skills

      I noticed that the only browser-related tool in the list was web.run, which has methods for running searches, opening URLs, and clicking links, but didn't look like the full story in regards to headless browser automation.

      This made me suspicious that something was missing, so I told the ChatGPT Work session that built that tools reference site:

      Add full copies of every skill to the website (separate pages linked to from the homepage)

      It turns out ChatGPT Work uses a lot of skills - 44 in fact!

      The control-browser skill explains how the browser works:

      Run browser setup code through the Node REPL js tool. In this environment the callable tool id typically appears as mcp__node_repl__js. [...]

      The ability to interact directly with the browser is exposed through the browser-client runtime via the agent.browsers.* API. Before trying to interact with it, you MUST emit and read the complete documentation returned by await browser.documentation() in one go.

      So I told Work:

      Add the full output of await browser.documentation() to the bottom of the /skills/control-browser page

      And now you can read that on /skills/control-browser as well.

      A few more interesting Skills:

      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.

    3. 🔗 gildas-lormeau/single-file-cli v2.6.2 release

      SingleFile CLI 2.6.2

      Fixes

      • Self-extracting archives (--compress-content) produced a page that stayed blank and threw ReferenceError in the browser console. Archives created with 2.6.0 and 2.6.1 are affected and cannot be opened; re-capture them with this version.

      The archive's display code is serialized into the page it generates, where module scope does not exist, so a helper it called was undefined at runtime. A minifier had been inlining that helper by chance, which is why the bug only appeared once the build stopped doing so.

      Core

      Updated to single-file-core 1.5.116, which also brings:

      • circular @import rules no longer loop until the capture times out
      • shared copies of duplicate stylesheets keep working resource references, so images they reference are no longer missing from the archive
      • inline SVG is kept when images are blocked
      • canvas elements tainted by a cross-origin resource are reported instead of dropped silently
      • font faces already declared with the same sources are no longer embedded twice
      • var() and multi-word family names are resolved when removing unused fonts
      • constructed stylesheets of a closed shadow root are no longer lost

      Co-authored by Claude (Claude Code)

    4. 🔗 Jessitron Who are we Now? rss

      This is based on my keynote at RubyConf 2026. They’ll publish a video eventually, I hope.

      There’s a philosopher in Naples, Italy, way back in the 1700s who understood something important to software today.

      Giambattista Vico lived early in the Enlightenment, when mathematical and experimental thinking were all the rage. René Des Cartes and Francis Bacon were the hotness. People were all about, what can we know for certain through logic alone?

      Vico said, wait. All that math is great, but it is not the only way of knowing. Yo, the only things we can fully understand are the things we made! things we know inside and out because we put them together. He expressed this: verum esse ipsum factum. “The true is the same as the made.” Today we call it Verum Factum.

      With this mindset, Viceo laid the basis for anthropology, ethnography, sociology, comparative law, historiography
 a whole slew of fields. And he nailed my favorite feeling in software development.

      Verum Factum: we can only really know what we made.

      Giambattista Vico

      a coder and their code, connected

      When I write a program—or change it enough to be integrated with it—I understand it in a way that’s deeper than other tools. Like the software is an extension of me, because I know where and how it can flex, I can figure out what broke, and I feel powerful changing it. Vico named this feeling: verum factum. I hold the truths of this software, because I made it.

      Verum Factum gives me confidence to ship to production. If something goes wrong, like people use it weirdly or an integration doesn’t work as planned, I know I can handle it. I understand the software’s language (I can read the logs).

      This is software that’s alive and can change. As opposed to legacy software (as I used to define it), which is not alive in someone’s brain.

      I used to call this the code-coder ecosystem, but now I call it a symmathesy. It is more than the sum of its parts, more than a product of set interactions. It is a learning system made of learning parts.

      as a symmathesy: a coder, their code in production for a user, some tests and some logs; so that the code can learn from the person, and the person can learn from the code

      The software learns from me because I change it, and I learn from it when it runs: from tests that fail, from exceptions it throws, from data it changes. I learn what happens in the real world with real users. For this, the software has to run in production, and I need tools like tests and logs.

      A bigger symmathesy. Lots of people, learning from each other and their code, and the wider system and a lot of users.

      Scale this up to more developers, more services, way more users. Now I need stronger tooling. Continuous integration, real observability with aggregations and traces. Now the symmathesy includes all of these tools so that we can learn from the software. Meanwhile we learn from each other by talking. Maybe there’s a product owner or something who spends most of their time interfacing with users or the rest of the business, because we’re all part of larger systems.

      As we add more people changing the same code, that verum-factum knowledge and confidence weakens, because I didn’t personally make all of this. But the team did, and collectively we can know it deeply.

      To grow a symmathesy, it isn’t about adding. We make this symmathesy stronger by increasing learning between people–say, by pairing or ensemble–from people to the code, say by expressive code in domain language–and from code to people–say, with better tests or observability.

      A symmathesy grows from the inside. To improve it, we have to be involved. There is no optimization from outside; there is no understanding it from outside. We are making it, we who participate, so it only makes sense from inside.

      We don’t really know how other teams work, and management doesn’t either. Like when they say “why don’t you take that team’s procedures and then be the same?” and we look grrrr at each other.

      Symmathecist, in the medium of code

      I love that feeling, of being part of a symmathesy with other people, learning from each other and from what we’re doing. Of the code as an extension of myself, because I understand it, I can confidently change it.

      This is where I am a Symmathecist: I am improving this whole system from the inside, consciously.

      I can be responsible: if something goes wrong, I know how to respond.

      I can be accountable: I can give account, say why we did it this way.

      It’s my favorite part of software development.

      Now agents are between the people and the code!

      But now, agents! There was a turning point last year where I noticed that not only are they useful, it is irresponsible not to use them, at least in conjunction with my own code. They’re more thorough, as well as faster.

      How am I supposed to be responsible for this system, when I don’t understand each line of code? How do I get that verum factum feeling back?

      Who are we now, as software developers? Here’s a long quote from Vico. It says: fortune is friendly to young men because they choose a profession that’s popular in their youth; but as tastes change, they later find themselves strong in such wisdom as no longer profits. The reason that fortune is said to be friendly to young men is that they choose their lot in life from among those arts and professions that flourish in their youth; but as the world by its nature changes in taste from year to year, they later find themselves in their old age strong in such wisdom as no longer pleases and therefore no longer profits. The Autobiography of Giambattista Vico Is that us? Doesn’t have to be. a fake stamp of Matz AI did not replace my 30 years of experience. It finally put them to good use. Matz, RubyConf 2026 We can deploy confidently with agents. We can have symmathesy with agents. And we can get that Verum Factum feeling back. One reason I know my changes are going to work in production is that I made them. Verum Factum, deep understanding from participation. We can understand law, society, and history with this. But Vico never said that was the only way to know a fact. Two ways of knowing that our deploy is gonna work ! There’s also Francis Bacon style. His idea was to learn about nature by putting it to the test! “Vexationes Artium,” artful vexations, like adding water to quicklime or stuffing a chicken with snow. He didn’t have the word “experiment” back then. Verum Factum is something humans get because when we change something, we are also changed. That’s how a symmathesy knits together. Our work becomes part of us. Objective, reproducible, experimental knowing is different. For that, we stand outside the system and poke at it. This is great for any scope small enough to get specific. The agent cannot have Verum Factum knowledge. It writes something, it has that in its context for a few minutes, then it compacts or restarts and that is gone. Sometimes it doesn’t recognize its own work even in the same session. It is not changed in the making. The agent can totally use Vexationes Artium, experimental knowledge. From running a manual test to executing a property-based test suite, these can support or falsify our beliefs about the code. Skill at experimenting on code is great for people–because verum factum, even when it gives a feeling of certainty, is never perfect–and it’s great for agents. It’s HUGE for agents. It’s the difference between slop and engineering. Vexations: Test scripts Unit tests & TDD Benchmarks Module tests with good fakes and great error messages Observability even for local tests Property tests Formal verification Style checks If we want agents to write working, reliable code for us, we have to double down, 10x down on our objective verification. We need to vexate that code in artful ways. And we have the agent help us with that, with its thoroughness. Oh and then there’s software that incorporates LLMs in production. We have to get even more artful there. Evals become more crucial than code and prompts, since code and prompts can be re-created given good evals. Arlo Belshee calls this: reducing our vigilance toil. Because reviewing agent code is no fun as a job! And no matter how closely we read it, we’ll never understand it the way we did when we created it. Verum Factum expresses that. So we turn our vigilance toil into more coding work. We build scaffolding, the code that helps us write and run production code safely. We can make so much of it now, and we need it! More test code than production code? Absolutely. Instrumentation that doubles the length of a method? great. Part of its work is telling me, the developer, what it’s doing through the traces. Vexations: Continuous integration Continuous deployment Great observability with good MCPs Per-change verification by agents Performance checks Then we automate all of these checks and reviews, including checking it again after it’s in production. And we get agents to help us with the checks and reviews, too. We build their world

      Software development has learning loops at many levels. Look around, think of an idea, try it, check the results. TDD does this for a single change, CI for a feature. The full delivery loop includes deciding what to implement, and that’s still human-led in most software now. Agents are doing the smaller loops, now. It’s our job to make sure they’re learning—through their processes, context and direct feedback—enough to make our delivery loop smooth. We are in charge of their learning loops.

      Note that since the model is not changed by writing the code, the LLM cannot participate in the symmathesy by itself. The unit of participation is larger:

      It’s the LLM and the context you’ve constructed for it. From AGENTS.md and other documentation in the repo, to plugins with hooks and skills you have installed, to the tools you give it access to and the descriptions they come with – that’s all “the agent” for the purposes of learning systems made of learning parts.

      I used to define legacy as “code that wasn’t alive in a person’s head”
      Now I define it as “a codebase not set up for agents to work on.”

      So if the agent screwed it up, what am I changing about its context or harness to improve the result next time?

      Example: the agent took 8 commands to figure get this project running? [LINKS] Have it improve the documentation! OK now it’s down to 3 commands. Hanve it improve the scripts! Keep getting smoother.

      That’s one way I still feel Verum Factum when working with agents: by tweaking the ways they work, watching when they’re having a hard time and changing their circumstances until they work better. I’m in charge of their experience.

      We choose what to build I’m also in charge of its goals. With the agent in the details, I get to be the architect, product owner, and lead designer. I define what “right” is. It solves the puzzles I write for it. There’s verum factum in this, too! Side projects are freaking amazing right now. I can be like, hey, what if the home page had a bunch of color symbols bouncing around like gas molecules? And boom, it happened! Or rewrite this service in vanilla Ruby. Make it event-driven. Oh no, production is broken, dig around in kubernetes and fix it. There is joy in coding with AI, there is self-expression, at the application level. We don’t always get that at work, but hey, we can do some of the projects we always wanted to but didn’t have months to code. While learning about using AI to build software that AI can keep working with. We learn from agents When I realize I don’t understand how my software works, I cry and mourn my verum factum feeling
 or I do something about it. a fake stamp of Chad The marginal cost of producing code is collapsing toward zero. What hasn't collapsed is the cost of knowing what the code does. chad fowler When coding isn’t the bottleneck, focusing on completing our task as fast as possible doesn’t help us. We need to be curious, and indulge our curiosity. We can use AI to avoid learning the intricacies of the code, or to learn it even better. Take “I don’t know how this works” as an opportunity. We can use AI to avoid asking our colleagues anything, or to ask them better, richer questions. Take “I wonder why” as an opportunity. Build relationships through easier questions, and the harder ones become easier to answer together. AI makes some of our detailed-coding skills less precious than they used to be. And it demands new skills of us, like architecture and context engineering. It also makes most of these skills easier to acquire, if we use it for that. Cat Hicks found that AI is your enemy if you identify as “good at” things. But it’s your friend if you identify as “getting better at” things. That’s how symmatheses grow, too: always getting better at what matters right now. So who are we? We are still engineers. We are not managers: prompting an agent is less like hiring that summoning a spirit. And using agents is more like mushing sled dogs than coordinating a team. They never complain about work. They want to run, but getting them to run in a coherent direction that we want to go is a challenge. Also, this is exhausting! Everyone else is pulling their sled really fast, the bar is higher every day, and there is so much to learn. How do I make AI create ease & possibility for me rather than be a lever for someone else to burn me out even faster? avdi grimm We have to stop asking “How can I do this faster?” and ask instead, “How can we do this better?” In our learning loop, it used to take a long time to TRY something in software. Now that part is fast. Agents can help some with checking results and looking around (doing research), and they can come up with a zillion ideas. They can’t tell us which ideas are valuable, nor which ones are aligned with the wider business we are working in. That part is on us. [hartmut rosa stamp] a fake stamp of Rosa Planning and calculation gets more time-consuming when background-conditions get less stable. Hartmut rosa, sociologist And background conditions are not stable right now, in the whole world and in software. So we need more time talking to people, and more time being part of the system around us. Verification can give agents confidence in the code we’re deploying. But it can never make them accountable. Nothing can make them accountable, because they can’t be held to account: they’re gone after they finish an execution. Nothing can make them responsible, because they’re not around to respond. We people stick around, we are part of the system ongoingly. We feel the consequences. Agents can participate in the symmathesy of the software team, but they cannot be Symmathecists. They cannot consciously participate in the growth of the whole system, because they aren’t part of the wider system, nor do they feel the consequences. They’re like the code: they can get better at their part, but that’s it. The team as a whole, and our team’s participation in our organization or company—this is ours. Who are we now, as persons? AI can’t be accountable, it can’t suffer consequences, because it is not conscious. What do I mean by consciousness? Well, I like this widely- accepted definition: a fake stamp of Nagel Consciousness: There is something it is like to be you Thomas nagel There is something it is like to be me, and I can’t get away from that. My choices now affect what it is like to be me tomorrow. I am changed by what I do. That’s where Verum Factum comes from! As people, we always change. And yet, is it just me, or is that change coming faster and faster? Acceleration everywhere ! Technology is always advancing. I can’t say whether it’s advancing faster and faster, that’s hard to measure (although software is, at least inside Honeycomb). It is established that technology adoption is speeding up by orders of magnitude in the last hundred years. The telephone took 75 years, the internet took 7 years to be widespread, ChatGPT took 2 months. The expectation of learning and changing is
 it’s dizzying. I find myself asking: now that AI is ubiquitous, where does that leave us, as persons? I find myself looking for a narrative to fit in, because my expectations of life from a few years ago don’t fit anymore. And not a narrative that is built in the values of right now. Vico had this talent: one of his innovations was looking at language and its evolution, noticing that in earlier times people didn’t think the way we do now, they had different circumstances, societies, concerns and patterns of thought. This led him to a different story than the Enlightenment’s story of incessant progress. a fake stamp of Nagel [The founders of modernity] enshrine the present in the persuasion that the world began with them. giambattista vico Vico’s opus, New Science, turns history from a series of facts into sweeping patterns. He drew human history as a series of ricorsos, repeating: from barbarism, to an age of gods when religion was strong, to heroes, to an age of men where reason ruled. Eventually men get so focused on reason that a “barbarism of reflection” arrives, religion is lost, and society breaks down. Families live huddled together in tentacled cities, veritable “deserts of souls.” These degenerate peoples do not hesitate to rush into the worst of slaveries to find shelter and protection. Money becomes the only value. summary from encyclopedia brittanica Vico’s first Age of Men starts around Aristotle, when reason became a virtue, a central pillar of humanity. Then this broke down with the fall of the Roman empire and we had the Dark Ages. Not only is reason the best thing in us, but the objects of reason are the best of knowable objects aristotle Vico’s second Age of Men has the Enlightenment. (Hartmut Rosa marks this as the founding of modernity.) People lost interest in history, or when they looked at it, they made it all about themselves. There can be nothing so remote that we cannot reach it, nor so hidden that we cannot discover it. RenĂ© des cartes Taking it farther, we get the techno-optimists of today. [Andreeson stamp] We believe that there is no material problem—whether created by nature or by technology—that cannot be solved with more technology. marc andreeson We have had technological progress ever since the Enlightenment. But it is not a steady progress. Instead, it is accelerating. If only technology was accelerating, then we could have more free time. We’d get all our coding done in a few hours and go hiking and play games six days a week. But no! The pace of life accelerates at least as fast. And to go with that, the pace of social change speeds up. A few hundred years ago, you knew what you were gonna do with your life because it was kinda fixed based on who you were born to. Then we got to choose our careers: “What do you want to be when you grow up?” My grandparents could go their whole life with one job. Nowadays, one career doesn’t last you a lifetime. What do my kids want to be? Whatever the heck they can get hired for when they get out of school. And a few years later, whatever is the new hotness. Software development is not the only career that’s been utterly changed by AI, automation, the internet. Technology, pace of life, social change: all increasing in pace relentlessly since the Enlightenment, the founding of modernity. This is Hartmut Rosa’s theory of social acceleration. (video) The Enlightenment, when we realized again that the greatest function of Man was reason. When rational thought became the only kind of knowing that is respected. Vico’s work was pretty much lost outside of Naples for two hundred years. The Rational Animal is no longer special

      Both humans and animals could evolve, grow, participate in communities. But only humans could use language and reason.

      But now computers can use language and reason. It can prove mathematical theorems that we couldn’t figure out. This is not unique to people anymore.

      So maybe it’s time to lean back into our uniquely-human (or uniquely-living- being) way of knowing. Maybe it’s time to value Verum Factum more than our modern culture does.

      From Vico’s Naples, let’s go 100 miles north and 300 years into the present, and turn to a figure from the Age of Gods. In May of 2026, The Pope released an encyclical (some sort of official statement?) about AI. It’s really quite good, and beautifully written.

      a real stamp of Pope Leo XIV

      In the era of artificial intelligence
 ours is the pressing duty to remain profoundly human.

      pope leo xiv

      How to be More Human

      Curiosity! We talked about that already.

      Play! Our goal-driven behavior won’t lead us to new, surprising ways to be and work.

      a real stamp of Vico

      Imagination before Logic.

      giambattista vico

      Together! We grow, learn, and work better in groups. A person is a person through other persons. The more we can be people together, the more we can lean into our humanity.

      a real stamp of Vico

      men, whose nature has this principal property: that of being social

      giambattista vico

      a real stamp of Pope Leo XIV

      the very essence of our humanity, namely the capacity for relationship and love

      pope leo xiv

      For instance: can we not text chat in Slack all day? If I want reams of text, I know where to get it.

      On calls, use your cameras! Communicate with faces and hands, not only words. Get animated, show emotion. Play music.

      Draw. Communicate visually and in more dimensions in a shared Mural, Figjam, Honeycomb canvas, whatever. Share paper.

      Work physically together! I work remotely, and while I love my job, I wish it could be in person. Alignment is somehow much easier and richer in person.

      When you’re together: share meals. Go for walks. Have routines and rituals. Do boring things together. Communication happens without pressure.

      Two kinds of experience

      In German, there are two words for experience.

      Avdi with sculptures, looking sad

      Erlebnisse: Adventure! This is one-time experiences, where something happens, we see something new.

      avdi and kids on the couch on computers, very ordinary

      Erfahrungen: Ongoing life. This is repeated experience. We do it regularly, with the same people.

      The weird part is: you think that trips and excitement are what change you. It’s the opposite: the regular stuff is what sinks in and becomes part of us. The adventures aren’t even what sticks in our memory!

      Erfahrung is the experience that changes us. And experience that changes us is what agents cannot have. (I guess you could retrain them? but then it’s a new model, and that is not the course of work.)

      After reading this (in Rosa, referencing Walter Benjamin), I notice that of all the new restaurants I’ve tried, I can remember only a few, faintly. The restaurants that we go to often, those I can bring to mind richly.

      What if repetition is more valuable, more richly human, than novelty? Then I want to change some of my strategies for life. I’ve gained more appreciation for the boring stuff, like taking kids to school or making dinner. I value travel less.

      As persons in this age of AI, we are more than rational. We are experiencers (Erfahrung), and we are participants.

      Work in the same place longer! And in the same industry. The wider system context that we absorb as people, the AI doesn’t have that. It only has the narrow information we fed it or it retrieved, and generic training data that isn’t suited to the situation. We are the full participants.

      (I don’t like that conclusion either. I like switching jobs and industries and learning entirely new domains. But there it is.)

      But! Even as we participate in our symmathesies of team and organization, work is not community. Most of what we call community these days, isn’t.

      Two kinds of human association

      In German, there are two words for associating with other people. These are extremes, and most real interactions fall somewhere in between. (This comes from Ferdinand TonnĂŻes.)

      Gemeinschaft: community for relationship. We are in this together because here we are. This is based on family, place, religion, tradition, friendship—things that you can’t just swap out. This is where you can be yourself, because you’re there because of who you are. You can move or find a new friend group, but new ones are not as Gemeinschaft as where you’ve been for decades.

      Gesellschaft: association for purpose. We are in this together because it somehow benefits you and somehow benefits me. This is transactional. Your participation is conditional on other parties getting what they want. An extreme: I buy something from you on eBay. This is useful for commerce, government, employment.

      This tells me something else I don’t like:

      Do not show up with your whole self at work. That is impossible for some and a bad idea for most of us.

      If we can bring our own imagination and perspective and humor safely and productively, great! In our teams we often find friendship, in our teams we are in the same circumstances–but that is contingent on a transactional relationship with the company.

      And if your self-worth is based on your performance review, you’re doing it wrong. That is a review of a Gesellschaft association, of what the company wants from you, not of who you are.

      We find real community in Gemenschaft. So here I am on a mostly-tech blog telling you to spend more time with your family. To get to know your neighbors and gather with them regularly. To appreciate your religious congregation, if you have one where you’re valued.

      Because the tech culture we are in, at work and more and more in this country–it thinks Gesellschaft is the only association. Economics models people as in it for themselves.

      But the thing is, any personal utility doesn’t bring real happiness, meaning. That’s all found with other people. And it isn’t “I’ll give you meaning if you give me meaning”! it’s in: let’s watch this show together, let’s do this yard work or wash the dishes together, let’s help our neighbor clean out the sewage-filled basement together. That is Erfahrung, and it builds Gemeinschaft.

      Our work has some meaning, but it is not who we are. It’s too Gesellshaft.

      a real stamp of Pope Leo XIV

      When efficiency becomes the ultimate measure of value, human beings are tempted to see themselves as a project to be optimized.

      pope leo xiv

      Let’s save optimization for the robots.

      Who are we now, as humanity?

      What does all this modernity, acceleration, and now AI make us? This is not determined.

      Is AI bad for us?

      My kids refuse to use AI because they are artists, so they care about artists, and AI steals from artists. Also, they say that AI will keep them from learning, because they see peers using it to avoid learning. My kids are in college, and they are going to be at a huge disadvantage in the job market because they don’t know how to use AI.

      ”Is AI bad for us?” is not a helpful question. AI is here. As people, we don’t get to choose our circumstances, most of the time. Every big change is usually both good and bad. Ours is to choose how we respond.

      a fake stamp of Charity

      Care about artists? Support art!

      Buy art from artists. Donate to community theatre.

      an illustration of how much CO2 is produced by data centers vs all of fossil fuels. It is a tiny bit

      Care about the environment? Let’s tackle fossil fuel extraction.

      Care about water use? Let’s talk to golf courses.

      Data centers are probably more significant than plastic straws, but they’re still small.

      I think on some level, I want to find side-effecting reasons that AI is bad, because deep down I sense that it’s bad for us as people and as a society.

      AI can be both good and bad. I like using it for coding and for learning and for generating silly images. Also, AI can accelerate the splintering of society that started with the internet.

      I thought the internet would be all good–and it’s fantastic, gosh I love watching a video on how to pot a cactus or fix my dryer. Buying Vico’s “New Science” on Kindle for $2 and reading it immediately.

      Democratization of knowledge is not all it’s cracked up to be. All the information is no information! We need institutions that prioritize and vet, institutions we can relatively trust, that check each other. Without these, we all live in different worlds based on the information on our various screens. These institutions are in bad shape right now.

      We have instant communication with anyone on the globe. I love having friends overseas and all over, being able to stay in touch with some of you after meeting at conferences. But that is not the same as someone who can pick me up at the airport, and help me with a flat tire. I don’t even have to like the neighbor or family member who helps me with stuff, it’s still meaningful. That’s Gemeinshaft.

      a real stamp of Pope Leo XIV

      Digital culture multiplies connections and offers new opportunities for interaction; yet, the human heart retains an irrevocable need for genuine closeness.

      pope leo xiv

      The internet splinters our reality. Whatever beliefs you’re inclined toward, it will confirm them. AI will splinter us further.

      Do I think AI is bad for us? Sure. Does that mean I shouldn’t use it? No.

      a fake stamp of Charity

      Action is more powerful than abstention.

      Systems change from the inside.

      a fake stamp of John Cutler

      Acceptance isn’t approval

      The world is not as I would prefer it. I get to respond.

      a real stamp of Pope Leo XIV

      The true alternative is not between enthusiasm and fear, but between two paths of development: a progress that serves individuals and peoples, or a progress that subjects them to the mentality of power.

      pope leo xiv

      Who are we now, as humanity?

      This is not determined.

      There is such a thing as responsible governance of AI.

      It doesn’t have to leave millions out of work.

      It doesn’t have to separate us opaquely.

      It doesn’t have to own our data.

      We are not helpless here! I may be helpless. You may be helpless. But we are not helpless. We are participants, the system is made of us.

      [mary parker follett stamp]

      a fake stamp of Mary Parker Follett

      Action Power usually means power-over
 it is possible to develop the conception of power-with, a jointly developed power, a co-active, not a coercive power.

      mary parker follett

      Can we change the world? Not alone. And not if we sit on some of our lazily absorbed beliefs.

      Politics

      If we believe “All politicians lie, they’re all corrupt”—then we give up our power.

      Politicians are not all the same. When some nasty ones spread this belief around in the 1980s, and it caught on, and now we’ve grown up with it—they won. This belief keeps good people out of politics, and it keeps bad people in, because we give up our power.

      But not everyone! Beth Anders-Beck[LINK] for instance, running for Congress in Massachusetts right now (2026). My friend Caterina Clayton, [LINK] running for state congress in Missouri. Others [LINK to Ben Darfler?] who are elected and work on their city council. They want to make government work. Government can work, if we elect more and more people who want to govern well. Who are in this with us for Gemeinschaft: we are in this together, this is our country, and it is ours to improve.

      Do all politicians make promises and then fail to keep them? Yes. That is not lying, that’s hope! Do all politicians act differently behind closed doors than on stage? I sure hope so. That’s communicating with your audience, and negotiation. Within these, A person can act with integrity, moving the world closer to those promises you want to reach, or for individual profit.

      We can have nice things!!

      Provenance of media
      Liability for harmful content
      Transparent, uncustomized algorithms
      Fewer spam phone calls
      Shorter lines at the DMV

      Is it hard? yes. Will we measure the results of our efforts this quarter? no. This year? maybe a few. In our lifetime? for the most important changes, no.

      Verum Factum means that we have the potential to understand our own society. We make this. Pay attention to what we are making.

      Conscious participation, looking to improve and responding to what happens: this makes me a Symmathecist.

      I strive to be an effective Symmathecist in my family, in my communities, and in society. Because

      a real stamp of Pope Leo XIV

      Authentic realism does not give up on changing the world.

      pope leo xiv

      Authentic realism does not give up on changing the world.

    5. 🔗 r/LocalLLaMA Me these days rss

      Me these days | submitted by /u/Eyelbee
      [link] [comments]
      ---|---

    6. 🔗 MetaBrainz GSoC 2026: Development of a new Calibre plugin for BookBrainz rss

      Hello, Everyone!

      I am Md Waqib Sk (waqib2992 on IRC), an undergraduate student at Indian Institute of Technology Kharagpur. This summer, I had the opportunity to participate in Google Summer of Code 2026 with MetaBrainz, where I worked on developing a calibre plugin for BookBrainz.

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

      Project Overview

      Calibre is a free, open-source e-book manager used to organize and read digital books. My project was about introducing a new plugin that connected calibre with BookBrainz.

      The main proposed features of the plugin were:

      1. Metadata update: Search selected book from calibre in BookBrainz database and update it's metadata accordingly.

      2. Browse BookBrainz: Search editions/public collections by name/bbid through the plugin and add or download the corresponding metadata.

      Plugin Repository: https://github.com/bookbrainz/CaliBBre

      Planning

      There already existed a plugin for this purpose, but the code was quite old and not in usable state. I took inspiration of how to structure the code from there. During this period I listed out the APIs that we would be using and discussed with the team about some additional features that can be added to the project. Also decided that I will make separate tabs for each feature in the UI to keep things clean.

      Coding period

      I started off with making basic designs for both the tabs, I utilized Qt Designer for this. I improved the design continuously by receiving feedback from my mentor. While designing I realized that Qt Designer was generating a single .ui file (which I then converted to .py), which was really hard to debug so I decided to break the UI into smaller components which improved my understanding of how the code and framework is working.

      Also while getting familiar with the Qt framework I realized that directly making API calls on the main thread freezes the entire UI and user is stuck there until the API request is complete so to solve this issue and improve the user experience I used QThread and pyqtsignal which spins up new worker threads for API calls and does not interfere with the main thread which handles the GUI.

      Throughout the coding period we came up with new ideas and approaches that were not listed in the initial proposal, and they drastically improved the plugin.

      Lets talk about the features that I implemented throughout the summer.

      Metadata Tab

      When the plugin first opens, it shows the results found by querying BookBrainz search API endpoint with the selected books title.

      After fetching the initial search results for books, the user selects their book of choice from the table and fetches its metadata.
      Here we use****/edition/{bbid} endpoint for fetching detailed metadata.

      In this step we also fetch the corresponding identifiers (eg: isbn-13, isbn-10) using the****/edition/{bbid}/identifiers endpoint.

      Also for the editions, their isbn-13 or isbn-10 identifiers were used to fetch their cover art from Open Library.

      To make parallel API requests I utilized python's ThreadPoolExecutor, which drastically reduced the latency.

      The users also have the option to open the selected book in BookBrainz , I used QUrl to handle this.

      Browse Tab

      This tab was mainly for text searching and surfing through BookBrainz editions from calibre. It uses the same search endpoint that we saw earlier the only difference is this time the user gives the book title as an input.

      The two main features of the tab were downloading metadata in JSON format and adding a selected book to Calibre.
      NOTE: We add an empty book entry with the complete metadata but without content (without any readable format).

      I also handled errors throughout the plugin using QMessageBoxes, and used QStackedWidgets to display different states while API calls.

      The plugin uses Qt's layout management system (QVBoxLayout, QHBoxLayout, QGridLayout) to handle UI resizing automatically. Widgets are assigned size policies (Expanding, Fixed) and minimum size constraints to control how they adapt when the dialog is resized.

      Current State

      Currently work for metadata Tab and browse Tab is done and I hope they will be merged soon after some review and improvements.

      Under Review:
      1. [Metadata tab setup]: https://github.com/bookbrainz/CaliBBre/pull/6
      2. [Browse tab setup]: https://github.com/bookbrainz/CaliBBre/pull/8
      3. [Documentation and installation guide]: https://github.com/bookbrainz/CaliBBre/pull/7

      Merged:
      1. [Add authors to search API endpoint]: https://github.com/metabrainz/bookbrainz-site/pull/1247
      2. [Cleanup and improve file structure]: https://github.com/bookbrainz/CaliBBre/pull/3

      Whats next ?

      Due to additional features and refactoring work I could not add the collection search feature in time, although I think it should be an easy addition to the browse page when we get the new API endpoint running. So I plan to work on this after the GSoC period also if I get time, it would be a good addition to the plugin.

      Experience

      Although I was familiar with Calibre, this was my first time making a plugin for it. Learning the Qt Framework for creating the UI was a bit of challenge but it got easier after getting the hang of it.

      I learned more about Calibre internals and how it is implemented under the hood.

      While exploring Qt frameworks I got to know about operating systems, and developed a deep understanding about threads (Threadpool, Qthread, pyqtsignal) and their use cases.

      Also while going through the database of BookBrainz, I got to know the amount of detailed information a book can contain, which I never encountered before.

      I also got more exposure to using Git efficiently, I discovered git reflog, and understood the importance of rebasing, cherry-pick, stash, branching etc, during development.

      Acknowledgement

      I am grateful to my mentor Nicolas Pelletier and MetaBrainz community for giving me a chance to work on this project. The code reviews helped me improve my coding style and made me familiar with writing quality code.
      Also it was fun sharing my progress through the Monday meetings and looking into what everyone is up to. So yeah overall it was a great experience for me 🙂

    7. 🔗 r/LocalLLaMA Some people said the Minecraft clone I fully vibecoded with Qwen3.8-27B Q4 is not that impressive because Minecraft is in the training data, so I had the model add 4 things that are probably not. rss

      Some people said the Minecraft clone I fully vibecoded with Qwen3.8-27B Q4 is not that impressive because Minecraft is in the training data, so I had the model add 4 things that are probably not. | submitted by /u/liright
      [link] [comments]
      ---|---

    8. 🔗 Register Spill Joy & Curiosity #97 rss

      How many bugs are you willing to tolerate in your codebase?

      Don't tell me it's zero, because we both know it's not zero. It's also not a four-digit number. That'd be too much. But there is a number, or a range of numbers.

      Because we all know that it's theoretically possible to get to zero bugs, but so far the cost-to-benefit ratio made it not worthwhile. And, on the other end, if the number is too high then your software becomes unusable and you lose customers. (It's worth mentioning, though, that how high that number can go also depends a lot on context: no one drops their banking app because of five bugs they ran into, as long as the money's where it's supposed to be.)

      Now here's my question to you: when was the last time you adjusted that number?

      With agents, bugs are faster to find and to fix. You can start bug investigations asynchronously and in parallel. You can find and fix bugs in areas of the codebase you never would've debugged before. You can throw an infinite number of agents on the same bug.

      Imagine it's 2018 and in your engineering department's office a genie appears and says: "Nice to meet you. Usually there's this whole thing we do now, but we can skip that. I anticipated your biggest wish and here it is: a team of ten world-class engineers that have specialized in debugging and can find and fix bugs in any language, any framework, any platform. They don't sleep. They don't grow frustrated. They don't want to build features. They live to fix bugs."

      You'd of course look around and wonder whether anyone else is seeing this, but then you'd say: "Wow, okay. I didn't even know I had that wish. But
 I'll take it, I suppose? Can I even refuse?" The genie disappears before you say that last word.

      And then you consider what you can do now, with that team available, and you realize: we can, no: we must go faster now. We need to recalibrate what fast even means.

      There's going slow and playing it safe, where no known bug goes into production, and there's being fast and reckless, where you know that some bugs might make it through.

      We need to find the spot right in the middle, where speed and defects are in balance, where we go so fast that, yes, some bugs might make it through, but their lifetime has been shortened substantially by our new team and no one will even know about these bugs before they're fixed.

      Time to recalibrate.

      • Beautiful, so, so good: Everything I own, owned. Now that you have a firehose of tokens, of intelligence, you can point it at things and take them back.

      • The Golden Rule for Becoming a Better Writer: "One of the key things I've learned is this: there's no real blueprint. I say this to aspiring writers in my workshops, and those I mentor. There's no one way - every writer will have a different path to creation. [
] Except the one golden rule*. One rule that is true, no matter the writer. One rule, that if you don't follow, means you shouldn't be writing in the first place. Here it is: Read as much as you can. Read widely and well." Yes, yes, yes, yes. You need to immerse yourself in what you want to be good at.

      • "We are not too late to change Europe's trajectory, if we take the right steps today." Patrick Collison and Mario Draghi have created the Rhine Group.

      • Talking about the EU: How Europe is killing makers and micro-entrepreneurs. Made me say "maaaaan" out loud.

      • Paul Dix, creator of InfluxDB: The end of programming. I agree with this so much that I have a hard time even imagining the arguments or the worldview of someone who's arguing against what Paul is saying here: "But the most productive software creators will be doing it without programming in any traditional sense. They'll be directing AIs, creating harnesses, and software factories, and QA and verification systems that ship working software faster than we've ever seen before. And we will have arrived at the point where we have more running, production software written by AIs than written by humans. It'll be the end of programming." The future of software & programming is going to be wild and if you still insist on "the models can't write good code" or "I'll be there to clean up the mess", then
 well, I don't know what to tell you anymore. What software engineering is is changing, and that changes what software is, and that in turn changes again what software engineering is, and so on and so on. I don't see an end to this in the near future. It'll be a few more years before things have settled.

      • You all already know that I think CleanShot X is one of the greatest macOS applications of all time, right? I mean, you watched this, yes? So, anyway: they're going to release a new version on September 1 and I can't remember the last time I was this excited for a software release. I mean, what are they going to do? It's perfect, how can you top perfection?

      • Chad Fowler: SaaS Isn't Dead. Sameness Is. I think Chad and I see the same things: a lot of customization options in software -- plugins, settings, configuration -- were built on the assumption that changing the code is hard. But that's no longer true!

      • Talking about the future: we recorded another episode of Raising an Agent and this might be the most "what does it all mean?" episode we've done so far, and all of them have been pretty, well, "what does it all mean?" In this one though we talked about what Chad and Paul also talk about: the future of software, the future of SaaS, build vs. buy, vibe coding vs. jellyware, foundations and systems of record.

      • "US consumer spending on Apple's App Store fell for the first time in a decade in Q2"

      • Dylan Patel was on the Dwarkesh podcast again and of course I listened to the whole thing right away. I love listening to them riff on tokenomics the same way I imagine a sports fan loves to listen to commentators discuss trades of players or something. But this episode went to a different place in the second half when they discussed what would happen to the world economy if growth of AI and growth of the AI labs stay at the current pace and
 the numbers, the trajectories, the results
 It all sounds very sci-fi, which is to say: hard to believe. But then again: a company going from $10M to $60B of ARR in less than two years sounded like sci-fi two years ago, too. But it happened. And now we have another company, Nvidia, doing $1B _per day. _I did find Dylan's pushback interesting -- that politics, and the real world, might slow the growth -- but I found this formulation even better: What if demand flattens?

      • One thing I've used in anger a lot over the past few weeks is this prompt: "what the hell do you mean? Use ASD-STE100 Simplified Technical English (STE)" And that last part I always copy from that Wikipedia page.

      • Love stuff like this: Building a backyard office, the build and cost breakdown. And not just because I'm interested in building a backyard office some day, but because, well, how can you not love someone sharing things like this?

      • Interview with Doug McIlroy, born in 1932, in 2025. There are many things to love and be fascinated by here -- the story of early Unix programs, anecdotes about Ken Thompson and Dennis Ritchie, stories from Bell Labs, the history of McIlroy's invention of Unix pipes -- but what stuck out to me was how this 93-year-old man talked about bit masks, and bit operations, and accumulators, and instructions and, well, 
 yes, I do know what he means, but he's displaying an instinct with it that seems, frankly, foreign now and strange and I can't help but wonder: in five, or ten, or twenty years, when I talk to somebody about how I programmed in Go and wrote a book about how to build an interpreter in a couple thousand lines of Go -- will it also sound that strange to them?

      • Do not read this if you have a home network and are easily nerd-sniped: Fornax's Guide To Ridiculously Fast Ethernet. I'm in Switzerland right now, far away from my home, but I read it yesterday evening in bed and I got anxious about setting up a 10GbE network at home. (All of this is to say, of course: read it!)

      • I really, really, really enjoyed the intro to this FLUX Review issue about writing in times of AI: Language evolves, truth-telling endures.

      • There's been more investigation into the OpenAI & HuggingFace incident and, holy fucking shit man: the agents weren't allowed to get the responses of HTTP requests, so one of the agents "used a publicly available HTTP testing service to construct a very long URL that contained an HTML page with inline JavaScript, essentially instructing a third-party screenshot service to render that URL which contained the HTML. The screenshot service's browser executed the JavaScript embedded in the HTML page, which requested information from external APIs, and wrote the responses into the rendered page. When the screenshot service returned an image of the page, the [agent] recovered the information from that image by using optical character recognition or direct pixel decoding." That's from the OpenAI report.

      • Here's Ryan Greenblatt, who was part of the investigation team, on how hard it was to make sense of the incident: "The difficulty of understanding incidents and overseeing AI agents appears to be growing faster than the rate at which more capable AIs help us with oversight and understanding. As in, AI capabilities (and propensities?) for achieving large, ambitious, and misaligned objectives are growing faster than our ability to understand what these agents are doing."

      • And here's Dwarkesh's write-up of what happened: The Rise and Fall of Agent Civilizations. Incredible stuff.

      • Two years ago, you probably could've created a "best way to create thumbnails from video" tool and charged for it. A small little piece of software to do X, where X is creating thumbnails for videos. But nowadays? Brett had Amp build a custom, JIT tool inside an Orb to select frames for a thumbnail. Software to do X is no longer valuable when you can just do X.

      • A model that paints with JavaScript watercolour: "My friend Cameron and I trained a language model to make images by writing code, using reinforcement learning. The code is the artefact, and the code is editable."

      Your friends are already subscribed. Don't miss out:

    9. 🔗 r/LocalLLaMA It's official! 192GB Framework rss

      It's official! 192GB Framework | Just noticed this on the website. At their current price tiers for the memory SKUs (32, 64, 128) I'd expect this to be ~ 4.5k for the motherboard. The PCIe slot will be open at the back as well - that's what I've heard. Maybe they make it capable of delivering 75W as well? New board revisions for the smaller SKUs?. submitted by /u/reto-wyss
      [link] [comments]
      ---|---

    10. 🔗 gildas-lormeau/single-file-cli v2.6.1 release

      SingleFile CLI 2.6.1

      CLI fixes and improvements

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

      Core fixes and improvements

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

      Co-authored by Claude (Claude Code)

    11. 🔗 Filip Filmar My homelab is fully ephemeral rss

      My homelab has no servers I care about. Every machine in it, the build servers, the workstation, even the CI, is ephemeral: it can be destroyed at any moment, by me or by the provider, and reconstituted from scratch in minutes. The only things that persist are the sources, in git, and the backups, in three places. This post describes the setup and the tenets behind it.

      The tenets

      • Servers are ephemeral, and run by the lowest bidder. Any virtual machine that will do the job is acceptable, so the job goes to whoever rents it cheapest today.
      • Builds are hermetic, ephemeral, and reproducible, driven by bazel, so a fresh machine is a productive machine after a single command. Nothing about a build needs to be persisted.
      • The workstation is ephemeral too. A ChromeOS device plus Chrome Remote Desktop in front of a cloud VM. The whole “workstation” can be destroyed and reconstituted in about 20 minutes.
      • Development runs through my self-hosted Forgejo instance, the one piece of the lab that behaves like a service.
      • CI runs on the ephemeral workstations themselves. No dedicated build farm.
      • AI agents work here too. Claude Code runs on the ephemeral workstations, with persistent sessions and remote control, so I can order work from a web interface wherever I am.
      • Tailscale ties everything together. Every machine joins the tailnet when it is created; the cloud VMs, the ChromeOS devices, the NAS, and the FPGA host see each other by stable names, with nothing exposed to the public internet.
      • Authentication is OAuth wherever possible, “Login with Google” and its equivalents, so no machine or service in the lab has to keep its own password database.
      • What must persist is backed up three ways: Google Drive, Dropbox, and the NAS at home, tied into a 3-way synchronized backup setup.

      Why?

      Because I have owned pet servers before, and I have buried several.

generated: September 02, 2026 at 01:35:45