🏡


  1. August 25, 2026
    1. đź”— WerWolv/ImHex Nightly Builds release

      Nightly

      7411268 Changelog

      • fix: Crash or hang on exit
      • feat: Replace emergency file backups and periodic backups with a implicit default project
      • build: Update libwolv
      • fix: Cleanup TaskManager before exiting after running cli command
      • fix: Incorrect start address used while filling bytes (#2863)
  2. August 24, 2026
    1. đź”— anthropics/claude-code v2.1.243 release

      What's changed

      • Added a Loops breakdown to /usage: per-loop run count, total tokens, tokens per run, and last run, so runaway or chatty /loop tasks are easy to spot
      • Added modelPicker setting: curate the /model picker with an ordered, labeled list of models (any id spelling, including Vertex/Bedrock ids), appended to or replacing the built-in lineup
      • Added promptCacheTtl and subagentPromptCacheTtl settings so API-key and cloud-provider users can keep a 1-hour prompt cache on the main conversation while subagents stay at 5 minutes
      • Added modelPricing managed setting so an organization's contracted per-model rates and discount multiplier are used for /cost, the status line, and telemetry cost figures instead of list price
      • Added a keyless sign-in under /login → Anthropic Console: "Sign in with your Console account" (recommended) alongside creating an API key, so organizations that don't allow API keys can sign in
      • Added a Skipped sources line to /status that lists managed settings sources (for example managed-settings.json) present but not applied because a higher-precedence managed source is active
      • Added a managed marker in /mcp and /plugins on claude.ai connectors whose authentication is managed by your organization
      • Added a tip pointing claude.ai users who haven't connected GitHub for Claude Code on the web to /web-setup
      • Added a /status line showing whether GitHub is connected for Claude Code on the web (Pro/Max), pointing to /web-setup when it isn't
      • Added the model (and effort level) each subagent ran on to /tasks and the agent detail dialogs
      • Fixed remote MCP servers in non-interactive (-p) and SDK sessions never recovering after a dropped connection; they now reconnect automatically or report as failed
      • Fixed MCP server sign-in started from the desktop app failing with "Invalid redirect URI" on servers that support client ID metadata documents (for example Linear)
      • Fixed auto mode staying unavailable at startup when a temporary server-side disable was cached and later flag fetches failed
      • Fixed auto mode tool calls being denied as "temporarily unavailable" after about a minute of waiting when the API was briefly overloaded and asked the client to retry
      • Fixed the /model picker silently ignoring an Ultracode selection; picking Ultracode now applies it to the current session
      • Fixed /resume only listing the 50 most recent sessions; the picker now loads more as you scroll
      • Fixed cloud sessions resuming after a mid-turn restart with a pending hook or background-task notification re-sent as the prompt instead of the normal continuation message
      • Fixed cross-session messaging silently turning off inside user namespaces and rootless containers after the 2.1.232 socket-directory hardening
      • Fixed text that hangs outside its container (for example the sign-in URL in /login) losing its leading columns when another part of the screen repaints
      • Fixed spellcheck not underlining a misspelled word typed directly after an emoji
      • Fixed background subagents not waking when their last background Bash task completes
      • Fixed sessions going silent for 10+ minutes when the Anthropic API never starts a response: the request now times out after ~3 minutes, retries once, then shows API Error: No response from API
      • Fixed auth, model-availability, and other client-generated error messages rendering like model output instead of as error lines
      • Fixed workload identity federation in CI: processes in one job share the exchanged token instead of re-exchanging the single-use token; a rejected exchange fails fast with the server's message
      • Fixed server-managed companyAnnouncements not showing at startup in a session that began with signing in (for example the first launch after /logout)
      • Fixed hook if conditions like Bash(cat *) firing on unrelated Bash commands when the command contained $() or backtick command substitution followed by more arguments
      • Fixed plugin dependencies declared with a marketplace field never resolving when both plugins are loaded together via --plugin-dir
      • Fixed /reload-plugins keeping the LSP tool after the last LSP plugin is disabled; it now also warns before an LSP plugin change that would re-read the conversation
      • Fixed --agents silently ignoring invalid JSON or invalid agent definitions; it now exits with a clear error, like --mcp-config
      • Fixed /status showing "Found invalid entries in: ." with no filename when ~/.claude.json has an invalid MCP server entry
      • Fixed /clear removing the /rename session name from the prompt bar even though the name was kept for the new session
      • Fixed Ctrl+R history search and up-arrow history breaking when ~/.claude/history.jsonl contains a malformed entry
      • Fixed Ctrl+[ not leaving vim INSERT mode in terminals that encode modified keys (modifyOtherKeys / kitty protocol)
      • Fixed the local IDE connection being routed through HTTPS_PROXY (and sometimes failing) when localhost was listed in NO_PROXY but not lowercase no_proxy; both casings are now honored
      • Fixed sandbox network-violation details being dropped from the Bash tool result when the blocked command still exited 0 (for example curl printing the proxy's 403 page)
      • Fixed the status line rate_limits fields and /usage still showing a rate-limit window's pre-reset usage percentage after the window reset while the session was idle
      • Fixed claude --teleport <session> exiting on uncommitted changes instead of offering to stash them and continue, as the session picker already does
      • Fixed /web-setup repeatedly asking you to log in when an older GitHub CLI (without gh auth token) was already authenticated
      • Fixed Claude in Chrome losing its connection to Claude Code after an auto-update cleaned up the version it was set up with; the native host now launches via the stable claude launcher
      • [VSCode] Fixed sessions started before feature flags were first fetched (for example right after install) opening in the default permission mode instead of auto mode or your configured default mode
      • [VSCode] Fixed Focus view sections you expanded collapsing on their own during subagent tool activity
      • Improved startup time: sandbox and MCP bring-up no longer block the first frame, bare launches skip subcommand registration, and workflow discovery, settings, and trust-store work is cheaper
      • Improved native install and auto-update download size: the binary is now zstd-compressed (about 75 MB instead of 340 MB on Linux x64)
      • Improved attribution of usage telemetry to your organization for sessions that authenticate with ANTHROPIC_AUTH_TOKEN directly against the Anthropic API, so its data-handling settings apply
      • Improved native binary size: about 2 MB smaller by storing the bundled skill and prompt text more compactly
      • Improved memory usage of native builds: code is now loaded on demand instead of keeping the whole bundle resident (roughly 40–70 MB less memory per session)
      • Improved peak memory usage in long-running sessions (the runtime now garbage-collects sooner as the heap grows)
      • Improved /login over SSH: the sign-in URL appears immediately, pressing c reports how the URL was copied instead of always claiming success, and a hint explains how to select text in fullscreen
      • Improved the error when effort xhigh/max is used with thinking turned off: it now names the level, the setting that disabled thinking, and /effort high as the fix
      • Improved /loop: consecutive wake-ups where Claude has nothing to do now fold into a single line in the terminal instead of printing each one
      • Changed the sandboxed Bash tool prompt to no longer list allowed network hosts, so Claude attempts requests (and you can approve new hosts) instead of assuming unlisted hosts are blocked
      • Updated the /model picker and the bundled claude-api skill to show Sonnet 5's $2/$10 per Mtok pricing as its standard list price rather than a limited-time promo
      • Changed computer use on macOS so clicking the desktop, Dock, or a Finder window requires granting Finder via the access dialog, like any other app
      • Changed /model, /fast, and /effort to also run immediately instead of queueing until the turn ends on Bedrock, Vertex, and Foundry and when telemetry is disabled
      • Fixed claude remote-control exiting and stranding attached Remote Control sessions when the server drops its environment mid-session; it now recovers
      • Fixed Remote Control sessions served by claude remote-control sometimes getting stuck after it was stopped and restarted, for Team and Enterprise members without an admin or owner role
      • Changed the cross-session messaging inbox socket to close connections that send no complete line within 30 seconds; scripts posting to it should connect once their data is ready
      • Improved the notice when resuming a conversation whose Remote Control is held by another terminal: it now says sessions on other machines can't be seen from, or reach, this one
      • [VSCode] Improved history trimming in long sessions: older tool-activity rows are dropped first so your messages and Claude's replies stay visible
      • [VSCode] Improved attribution of the extension's own usage telemetry to your organization when you are signed in with a Claude account, so its data-handling settings apply
    2. đź”— roboflow/supervision supervision-0.30.1 release

      0.30.1: Numeric-precision and stability fixes

      supervision 0.30.1 is a bug-fix patch release. It corrects numeric-precision issues that only surface on specific inputs — large-coordinate oriented boxes (geospatial data, stitched frames), large integer boxes for box_iou, and rotated tracks in DetectionsSmoother — where prior versions could silently return imprecise or self-inconsistent results instead of erroring. It also fixes a duplicate-libavdevice-load crash risk on macOS when both av and opencv-python are installed, plus smaller fixes to list_files_with_extensions and the cv2-free RGBA fallback. No public API was added or removed, and no signature changed — a drop-in upgrade from 0.30.0 for virtually all users. See Migration guide below for the one narrow exception (box_iou on complex-valued coordinates) and for the precision caveats on the numeric fixes.

      ✨ Spotlights / highlights

      1. Oriented-box area/IoU precision fix for large coordinates

      sv.Detections.area and sv.oriented_box_iou_batch now translate OBB coordinates to a local origin before floating-point math. Previously, large- coordinate inputs could lose enough precision that a box's IoU with itself collapsed below 1.0.

      pair_origin = np.minimum(origin_i, origin_j)
      offset_i = (origin_i - pair_origin).astype(np.float32, copy=False)
      offset_j = (origin_j - pair_origin).astype(np.float32, copy=False)
      

      2. sv.box_iou no longer overflows on large integer boxes

      Area computation now takes coordinate differences before casting to float, avoiding int32 overflow. For realistic coordinate magnitudes, box_iou's scalar result now matches box_iou_batch.

      3. Duplicate libavdevice crash fixed on macOS

      import supervision no longer loads PyAV's native libraries when the OpenCV backend is active — PyAV is now imported lazily, only where it's used, preventing a duplicate libavdevice warning (and possible crash) when both av and opencv-python are installed.

      4. DetectionsSmoother keeps oriented-box corners consistent

      Smoothed OBB corners are now aligned (start index + winding) to a reference before averaging, so rotated tracks smooth correctly instead of averaging mismatched corner orderings.

      5. sv.get_polygon_center precision fix for large-coordinate polygons

      Centroid calculation now translates to the first vertex and computes in float64 before adding the origin back, preventing integer overflow and precision loss for realistic coordinate magnitudes.

      🔄 Migration guide

      No public signature changed. One item below (box_iou on complex coordinates) does make one specific previously-succeeding call now raise — narrow and deliberate, not classified as breaking since complex-valued box coordinates were never a documented/supported input. The rest only change output values for inputs that were already edge cases:

      • sv.box_iou on complex-valued coordinates: previously silently discarded the imaginary part and returned a real number. Now raises TypeError("box coordinates must be real-valued").
      • OBB precision fixes : results for oriented boxes with large coordinates or rotated tracks may differ slightly from 0.30.0 — the new values are the corrected ones. Re-calibrate any hardcoded IoU/area thresholds tuned against the old (imprecise) output.
      • sv.box_iou / box_iou_batch agreement: for realistic integer coordinate magnitudes (below 2^53), box_iou's scalar result now matches box_iou_batch. Not a universal guarantee — box_iou subtracts before casting to float, box_iou_batch still casts to float64 before subtracting, so the two can diverge at coordinates ≥ 2^53 (~9 quadrillion), far outside any real use case.

      📝 Notable changes

      🚀 Added

      • RF-DETR example scripts (rfdetr_example.py) added to the count_people_in_zone, heatmap_and_track, speed_estimation, tracking, and traffic_analysis bundled examples. (#2497)

      🌱 Changed

      • sv.box_iou now raises TypeError for complex-valued box coordinates instead of silently discarding the imaginary part. (#2485)
      • Performance: DetectionsSmoother.update_with_detections now checks active tracker IDs via set membership instead of scanning per tracked object. No output changes. (#2496)
      • Documentation and API-reference examples now default to RF-DETR instead of Ultralytics YOLO. (#2493, #2494, #2497)

      đź”§ Fixed

      • RF-DETR speed estimation now measures elapsed source-frame intervals, including gaps when tracked detections are temporarily missed. (#2497)
      • sv.get_polygon_center now calculates polygon centroids in translated float64 coordinates, preventing integer overflow and precision loss for realistic-magnitude large-coordinate polygons. (#2491)
      • sv.Detections.area and sv.oriented_box_iou_batch now translate oriented-box coordinates to local origins before floating-point math, preventing self-IoU collapse for large-coordinate inputs. (#2492)
      • DetectionsSmoother now keeps oriented-box corners aligned with smoothed xyxy geometry, including rotated tracks and mixed metadata windows. (#2489)
      • sv.box_iou now calculates overlap in float64, preventing int32 area overflow for large boxes; its scalar result now matches sv.box_iou_batch for realistic coordinate magnitudes. (#2485)
      • sv.list_files_with_extensions no longer includes directories when listing all files without an extension filter. (#2486)
      • sv.pillow_to_cv2 now accepts RGBA images when the cv2-free fallback backend is active, matching OpenCV by dropping alpha and returning BGR channels. (#2488)
      • import supervision no longer loads PyAV's native libraries when the OpenCV backend is selected; PyAV is now imported lazily on first use, preventing a duplicate libavdevice warning (and possible crash) on macOS when both av and opencv-python are installed. (#2509)
      • Docstring examples converted to executed doctests across annotators/core.py, dataset/formats/coco.py, dataset/formats/createml.py, and Detections.from_vlm; previously wrong documented outputs corrected for several VLM examples. (#2474, #2475, #2479, #2484)

      Also in this release: routine dependency bumps (dependabot: astral-sh/setup- uv, wheel, pymdown-extensions x2, pypa/gh-action-pypi-publish, twine, cryptography), CI/docs-workflow maintenance, and test-only additions (geometry contract test, sklearn parity test) — none change installed package behavior. (#2028, #2470, #2472, #2473, #2480, #2481, #2482, #2483, #2499, #2501, #2506, #2507, #2508)

      🏆 Contributors

      • lawliet (@lawliet206) — oriented-box area/IoU precision fix at large coordinate origins
      • Zhewen Tan (@tandede) — polygon centroid overflow/precision fix
      • Tamil Adhavan S K (@adhavan18, LinkedIn) — DetectionsSmoother oriented-box corner alignment fix; added geometry contract test
      • NIKHIL (@Nikhi00718) — fixed box_iou int32 overflow; added complex-coordinate TypeError guard
      • shao (@shaoming11, LinkedIn) — DetectionsSmoother tracker-ID lookup performance improvement
      • Tyyyy (@uczltw6) — RGBA image support in the cv2-free fallback conversion
      • ZZZZZ (@BruceWae) — fixed list_files_with_extensions to exclude directories
      • FootysHands (@ayo0la) — converted docstring examples to doctests; corrected wrong documented VLM example outputs
      • Swapnil Gautam (@Swapnil-gautam) — converted docstring examples to doctests in dataset format modules
      • Daniiiil1 (@Daniiiil1) — added sklearn parity test for metrics
      • Christoph Deil (@cdeil, LinkedIn) — repo maintenance docs

      Full changelog : 0.30.0...0.30.1

    3. đź”— MetaBrainz Blocked ListenBrainz services/User Agent strings rss

      Unfortunately some legitimate services got caught up in our recent attempts to mitigate (yet another) bot-net attack on ListenBrainz.

      You may find that a service you use is now being blocked, including Navidrome. We have also had reports of multi- scrobbler submissions being blocked, and there may be other affected services that haven't yet been reported to us.

      These services got caught up in recent blocks because they are/were not setting a proper user agent when calling the LB API.

      Navidrome and multi-scrobbler are already pushing fixes!

      If you are experiencing issues on another service, we would like to let you through, but without a user agent (UA) string we can't identify the service's traffic. Please ask your service to add a meaningful UA string (in a format like described in https://musicbrainz.org/doc/MusicBrainz_API/Rate_Limiting) so we can get you back up and running.

      Implementing a good back off when they receive a 429 error will help avoid blocks too. For example, extending the waiting time between resubmissions, if the service repeatedly returns a 429. Note that some of the blocked services had this implemented already, but it can help.

      Developers, you are always welcome to talk to us on the dev channel in ChatBrainz (Matrix/IRC/Discord) if you have any questions.

    4. đź”— smol-machines/smolvm smolvm v1.12.0 release

      What's Changed

      • Add an opt-in virtio-gpu scanout with a host-side VNC server and virtio-input so machines can run an interactive Linux desktop by @BinSquare in #1027
      • Ship virtio-input-capable guest kernels and an input-enabled macOS libkrun by @BinSquare in #1043
      • Harden forked workloads and add transactional embedded batch forking by @BinSquare in #1044
      • Make large pack pushes reliable with upload-scoped timeouts and a chunked fallback by @BinSquare in #1045
      • Rewrite a loopback proxy host to the host's outbound address so guests can reach it by @BinSquare in #1046
      • Cut v1.12.0 with the display-capable libkrun and rebuilt platform libraries by @BinSquare in #1048
      • Harden live fork execution for rollout sandboxes by @BinSquare in #1049
      • Pack a machine created from a local image archive or rootfs directory by @BinSquare in #1047
      • Pin the Vulkan driver on exec only when the container actually has the bundle by @BinSquare in #1052
      • Bump the workspace crates to 1.12.0 so the library crates ship at the engine's version by @BinSquare in #1051
      • Mount the bundled Vulkan driver into pod and overlay containers too by @BinSquare in #1053
      • Boot a pod sandbox with a virtio-gpu device when the pod asks for one by @BinSquare in #1054

      Full Changelog : v1.11.1...v1.12.0

    5. đź”— PrimeIntellect-ai/prime-agent Beta (v0.8.0-beta.546.1.a9b5d88) release

      Automated beta build from main (a9b5d88b50db50860088772a408e867f8071b507).

    6. đź”— MetaBrainz GSoC 2026: Playlists Sorting and Organization rss

      Helloo Everyone!
      My name is Yateen, a final year cse student at Indian Institute of Technology Jodhpur. My matrix username is (@yateen) and GitHub. I started open source at the beginning of this year. I was selected as a gsoc contributor and worked on Playlists Sorting and Organization project. It was a wonderful experience working on Tech Stack like React, Databases, API's, Jest + Testing Library, etc and what was more amazing was to work under the mentorship of Ansh Goyal (Github), Monkey (Github) and Jade (Github) and be a part of wonderful MetaBrainz team.

      Pre-selection Contributions

      Before GSoC officially started, I contributed to ListenBrainz through several smaller PRs that helped me learn the codebase and review process. Firstly I started with exploring some small UI , UX issues such as preventing duplicate error toasts and fixing toast overlap with the YouTube player, accessibility improvements like adding aria-labels to icon-only playback buttons. Then I started solving tickets which are feature-oriented like including auto-save for settings, showing artist name relationships. This pre-selection period helped me get comfortable with ListenBrainz patterns and mentor feedback before taking on the larger GSoC features.

      Project Overview

      Over the summer I worked on the playlist features , improved the existing playlist structure . I shipped four related features that turn ListenBrainz playlists from a flat list into something you can search, tag, sort for listening, and import from MusicBrainz collections.

      Feature 1 — Playlist Search

      The first thing I tackled was search on the user playlists page. If you had a lot of playlists, finding one usually meant scrolling forever or jumping over to global search.

      I started with a simple search bar wired to the existing user playlist search API: type at least three characters, hit search and get matching playlists back with pagination. But there was a problem with it especially once you mixed search with sorting and paging.

      Ansh suggested to treat search like the rest of the playlists page that is put the query in the URL, load data through the route loader . The main issue now was the search results were automatically sorted before getting displayed with the existing sort option (maybe by Date Created , Date Modified , Title etc) which doesn't provide a good search experience . So I introduced a way for search results to default to “Best Match ” while a search is active and later you can sort by date or title and get a consistent order across pages. I also added small but important pieces — loading state while rendering and empty messages when "No playlist found".

      Feature 2-Tagging Playlists

      Search helps when you remember a name. Tags help when you remember a use /category — gym, road trip, focus, whatever. ListenBrainz didn’t have real playlist tags yet.Playlists already had additional_metadata, but we needed a proper structure to organize them with tags

      On the backend , I added a playlist_tag table in admin/timescale/create_tables.sql , with normalization (lowercase, trim whitespace, length limits).Each tag ≤ 40 chars, you can add up to 25 tags per API call; a playlist can hold at most 50 tags overall , and owner-only add/remove. Collaborators can see tags but can’t edit them. Tags show up in playlist JSPF when we need them for the UI, and there’s a sidebar endpoint that returns each tag with how many playlists use it — separately for owned vs collaborative playlists. Filtering supports multiple tags , and it works together with search.

      Table

      Table: playlist.playlist_tag

      Column| Type| Notes
      ---|---|---
      id| SERIAL| Primary key
      playlist_id| INT NOT NULL| FK to playlist.playlist(id), ON DELETE CASCADE
      tag| TEXT NOT NULL| The tag string
      created| TIMESTAMPTZ| Defaults to NOW()

      UNIQUE (playlist_id, tag) — same tag only once per playlist

      On the frontend , you can add tags when creating or editing a playlist, see them on playlist cards and on the playlist page, and filter from a sidebar. Active tags filters are included in the URL (?tag=…), so they compose cleanly with the search and sort .

      Designing the UI for the tags sidebar was bit challenging , Consulted with Aerozol, Ansh and Monkey and finally came with a UI which reuses the existing components from Listenbrainz.

      BEFORE :

      Main playlist page without tags sorti ng

      AFTER:

      Playlists sorted by tags

      Feature 3 - Sorting tracks inside a playlist

      After search and tags, the next issue was browsing tracks inside a playlist. Tracks always showed in the saved order. That is fine for editing, but not always for listening. Sometimes you want A–Z, by artist, newest first, or shuffle — without changing the playlist forever.

      So I built this only on the frontend. On the playlist page, there is a “Sort by ” menu next to Play all. Options are Default, Recently added, Title, Artist, and Shuffle. Default is the real saved order. Drag and drop works only in Default. Other sorts are temporary.

      For Shuffle, if you add or remove a track, the list does not reshuffle again. Play all also uses the order you see on screen.This was a smaller feature than search or tags, but it made long playlists easier to use.

      **Feature 4 - Importing Musicbrainz collections **

      ListenBrainz already imported playlists from Spotify, Apple Music, and SoundCloud — but not from MB itself.The goal was to preview MB collections in ListenBrainz and optionally save them as normal ListenBrainz playlists .

      Recording collections first

      We started with recording collections. Instead of calling the MusicBrainz web API, we read live from the MusicBrainz database using MB_DATABASE_URI.

      On the backend:

      • GET /1/playlist/import/musicbrainz/collections lists the logged-in user’s collections.
      • /collection/<mbid>/ shows the collection page which follows the same SPA pattern as other ListenBrainz pages . GET returns the HTML shell, and POST returns the JSON data.
      • Public collections can be viewed by anyone. Private collections are only for the owner, checked with their MusicBrainz editor id.

      On the frontend:

      • A MusicBrainz option was added to the import modal. Clicking a collection opens a preview page where tracks load in pages of 100, with virtual scrolling for large collections. The page also supports cover art, Play all, and Save as playlist. Saving uses the existing playlist create API (POST /1/playlist/create).
      • After mentor review, we improved the page to better match ListenBrainz patterns. The first page of data now loads through RouteLoader, more tracks are fetched with useInfiniteQuery instead of a hand-written fetch loop.

      Release Collections

      Now on the preview page, a release collection does not show a flat list of tracks. It shows the releases themselves — title, artist, and cover art when available. Clicking a release opens the ListenBrainz release page at /release/<mbid>/, so the user can explore that album in the normal ListenBrainz UI.

      Saving works a bit differently from recording collections. A release collection is not already a list of recordings, so the backend flattens each release into its tracklist. The frontend requests this with ?flatten=tracks on the collection page. That query walks the MusicBrainz release → medium → track → recording path and returns normal recording rows. Those rows are then sent to the existing playlist create API, so the final result is a normal ListenBrainz playlist that you can play, edit, and manage like any other playlist.

      Testing

      Writing tests was one of the biggest learning curves for me this summer. Before GSoC, I mostly checked features by hand and did not have a strong habit of adding tests. Working on ListenBrainz changed that. Mentors often asked for coverage of edge cases, auth rules, and validation paths, so writing tests became a normal part of finishing a feature.
      For each feature I used a mix of both manual checks with automated tests:

      • Frontend tests in Playlists.test.tsx for playlist search.
      • Integration tests in test_playlist_api.py for tags.
      • Frontend tests in Playlist.test.tsx for in-playlist sorting.
      • Integration tests in test_musicbrainz_collections_import.py for MusicBrainz collections.

      Overall GSoC Experience

      GSoC with MetaBrainz was my first time working on a large open-source project with real users and a real review process. I learned a lot more than just writing features. Mentors pushed me to think about URL state, loaders, error codes, empty states, and tests — things I used to skip or only check by hand.

      I would like to thank Ansh , Monkey , Jade for guiding me throughout the process . I learned professionalism from them and their dedication to their work motivates me to improve my own. I realized that handling such large organization with limited members requires high skills built on strong fundamentals and obviously a problem solving mindset is must . I would also like to thank Aerozol for helping me in UI related issues.

      What feels most rewarding is knowing the work I shipped will remain in the project and will be used by users across the world.

      My PR's around the GSoC period and Proposal can be found here - PRs

      Proposal

      Post GSoC Plan

      I plan to take a short break and then with fresh energy again start contributing to ListenBrainz and other MetaBrainz products. My next steps will likely include polishing the playlists further and solving other tickets so I stay active in the community (I love Monday meetings 🙂). Long term, I hope to keep growing as an open-source contributor and continue improving ListenBrainz.

    7. đź”— tintinweb/pi-subagents v0.18.1 release
      • settings -> showModel to show effective model and thinking in widgets
      • markdown in conversation viewer

      image

    8. đź”— r/LocalLLaMA Qwen 3.8 27B in 9th position on code arena. Gemma 4 31B is 80th. rss
    9. đź”— r/LocalLLaMA Apple M5 Server rss

      Apple M5 Server | Credit to Twitter Post submitted by /u/Rymssss
      [link] [comments]
      ---|---

    10. đź”— r/LocalLLaMA I irradiated LLMs and found that they die really quickly rss

      I irradiated LLMs and found that they die really quickly | I randomly bit flipped a llm to simulate what would happen if you ran your spark in low earth orbit i hope it's ok to share this here, I was told this community might enjoy it. submitted by /u/BenniJesus
      [link] [comments]
      ---|---

    11. đź”— earendil-works/pi v0.84.3 release

      New Features

      • PowerShell tool — Use optional native PowerShell command execution on Windows. See PowerShell Tool.
      • Safer managed updates — Stage, verify, and atomically activate updates for installer-managed installations. See Install and Manage.
      • Model and thinking controls — Select thinking levels with /thinking, search defaults, keep selections session-scoped, and persist them explicitly with Ctrl+S. See Models and Thinking.

      Breaking Changes

      • Renamed the inherited GoogleThinkingLevel type to GoogleApiThinkingLevel and added ResolvedGoogleThinkingLevel for normalized adapter levels.

      Added

      • Added an optional powershell tool for Windows, configurable through defaultTools and the SDK. See PowerShell Tool.
      • Added a /thinking selector and searchable default choices to the model and thinking selectors; Ctrl+S saves the selected model as the global default. See Models and Thinking.
      • Added optional routing session IDs to exported compaction summary helpers so callers can preserve provider routing without enabling prompt cache writes.
      • Added transcript usage notices for compaction and branch summaries when cache miss notices are enabled.
      • Added session_compact_failed extension events so compaction failures and aborts expose their reason, retry state, source, and error message to handlers (#8175).
      • Added inherited provider-neutral toolChoice support to simple stream requests.
      • Added inherited automatic Anthropic server-side refusal fallback for supported first-party models, including returned-model usage pricing (#8017).
      • Added inherited configurable OpenAI-compatible thinking-token budget fields for vLLM, Qwen/SGLang, and llama.cpp servers. See OpenAI Compatibility (#8275 by @bnsd55).
      • Added inherited China-specific ZAI Coding Plan models, including GLM-4.6V vision support and API-equivalent usage cost estimates (#8220).
      • Added inherited deepseek-v4-pro-0813 support to the Qwen Token Plan Individual catalog (#8194).

      Changed

      • Changed experimental installer-managed installations so pi update stages, verifies, and atomically activates the selected release in place. See Install and Manage.
      • Changed inherited built-in xAI models to use the Responses API with encrypted reasoning replay and made Grok 4.6 the default xAI model (#8124 by @Jaaneek).
      • Changed inherited Anthropic, Azure OpenAI, Google, Mistral, and OpenAI adapters to send Pi's default User-Agent unless overridden (#8305).
      • Changed Windows and WSL keybinding defaults to avoid terminal-reserved shortcuts for image paste, model cycling, editor undo, fullscreen transcript navigation and search, and message queueing (#8372).
      • Changed Bun release archives to ship the native clipboard binary only inside the wrapper package, removing a duplicate platform package from each archive.
      • Changed package resource glob expansion to use Node.js's built-in implementation with deterministic visible-path matching, reducing the installed runtime dependency tree.
      • Changed the bundled Node.js runtime to load jiti only when importing an extension and Babel only when uncached source needs transformation, reducing CLI startup time and bundle size.
      • Changed syntax highlighting to initialize only twenty common languages eagerly and defer the remaining grammars until after the initial TUI render, reducing CLI startup time.
      • Changed the Node.js CLI and RPC entrypoints to load a bundled runtime, reducing startup filesystem reads while keeping the public library and legacy module paths on the modular runtime for normal dependency identity.
      • Changed session sharing to render clickable terminal links, display only the canonical Radius artifact URL, and include the current system prompt and active tool definitions in Radius session shares.

      Fixed

      • Fixed failed extension factories leaving event subscriptions, provider registrations, and default flag state active (#8424 by @acmerfight).
      • Fixed models.json typings omitting the documented OpenAI-compatible compat.supportsFinishReason provider and model override (#8487 by @petrroll).
      • Fixed /model and /thinking selections being persisted globally unless explicitly saved with Ctrl+S (#5263).
      • Fixed JSON and RPC toolcall_start events omitting the tool call id and name (#7953 by @christianklotz).
      • Fixed extensions failing to load when the Node.js CLI runs as a single-executable application (#8237).
      • Fixed nested Markdown skills inside .agents/skills/ grouping directories not being discovered.
      • Fixed compaction and branch summarization requests exposing tools to providers.
      • Fixed single-object edit tool inputs failing validation by accepting them as one-edit arrays in both coding-agent and harness edit tools (#7835).
      • Fixed root Markdown files such as README.md and AGENTS.md in skill directories being reported as broken skills unless they declare valid skill frontmatter (#7805).
      • Fixed the default Cerebras model referencing an unavailable Z.AI model.
      • Fixed inherited OpenAI-compatible Chat Completions reasoning replay to preserve and resend assistant-level reasoning_details verbatim and in order (#7994).
      • Fixed inherited Anthropic server-side fallback responses being priced with the requested model instead of the returned fallback model (#8285).
      • Fixed inherited GitHub Copilot login triggering model-policy rate limits by limiting policy updates, retrying model discovery once, and honoring server retry delays (#7850).
      • Fixed inherited Amazon Bedrock dropping and failing to replay opaque redacted reasoning from non-Anthropic models (#8314 by @seiji).
      • Fixed inherited Z.AI Coding Plan models deriving incomplete reasoning-effort metadata, including missing GLM-5.3 low, high, and max levels (#8336).
      • Fixed inherited DeepSeek V4 Flash on OpenCode and OpenCode Go omitting its supported low thinking level (#8181 by @tianshuang).
      • Fixed inherited Azure OpenAI Responses ignoring toolChoice in provider-specific stream requests.
      • Fixed inherited Amazon Bedrock response hooks receiving only a synthesized request id instead of the raw response headers (#8234).
      • Fixed inherited Kimi usage reporting so top-level cached_tokens count as cache reads instead of normal input tokens (#8075).
      • Fixed inherited Google custom models ignoring thinkingLevelMap, which dropped extended thinking controls (#8135).
      • Fixed writes to auth.json and models-store.json overriding administrator-managed file permissions and ACLs (#7779).
      • Fixed UTF-8 BOM markers preventing frontmatter and user configuration files from loading (#8337).
      • Fixed invalid settings files being easy to miss during interactive startup by rendering warnings with the file path inside the TUI (#7829).
      • Fixed the subagent example repeatedly prompting before running project-local agents in trusted repositories (#8261).
      • Fixed npm package update checks treating older registry versions as available updates, preventing pi update from downgrading already-newer installed packages (#8226).
      • Fixed built-in llama.cpp models disappearing from /model when /llama refreshed a configured server under PI_OFFLINE, and included idle-slept sleeping router models in the selectable catalog (#8167).
      • Fixed pi.registerFlag() accepting default values that do not match the declared flag type (#8064).
      • Fixed Z.AI Coding Plan defaults referencing the removed GLM-5.1 model (#8096).
      • Fixed repeated ambiguous truncated-response recovery being mislabeled as context overflow (#8130).
      • Fixed duplicate fullscreen right-click paste in VS Code-based terminals on Windows (#8186).
      • Fixed inherited padded text exceeding narrow terminal widths (#8252).
      • Fixed inherited wrapped Markdown table links leaking color into borders and neighboring cells, including tables inside blockquotes (#8335).
      • Fixed llama.cpp login guidance to direct users to /llama before /model when no local models are loaded (#8203).
      • Fixed hung pi.dev model catalog requests consuming the entire refresh deadline without retrying (#8198).
      • Fixed inherited Xiaomi model catalogs listing shut-down MiMo V2 models in /model and --list-models (#8187).
      • Fixed branch summary entries recording the navigation destination in fromId instead of the pre-navigation source leaf.
      • Fixed threshold auto-compaction being skipped when providers omit streaming usage data (#8328).
      • Fixed dash-prefixed prompts being parsed as options by supporting -- as an end-of-options delimiter (#7269).
    12. đź”— r/LocalLLaMA Xiaomi AI Cube announced with 1.2TB/s memory bandwidth rss

      Xiaomi AI Cube announced with 1.2TB/s memory bandwidth | Xiaomi announced a prototype for their Xiaomi AI Cube. 3 chip system:
      - Xiaomi Xuanjie O3
      - Xiaomi Xuanjie O100
      - Xiaomi Xuanjie D100 The specs are impressive, but a bit confusing. The D100 chip (originally for their EVs) supports up to 160GB of RAM, but O100 has the 1.22TB/s memory bandwidth. Perhaps the 1.22TB/s figure is for SRAM? Hard to say definitively. Source: https://www.ithome.com/0/993/546.htm submitted by /u/Mysterious_Finish543
      [link] [comments]
      ---|---

    13. đź”— HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss
      sync repo: +1 plugin, +1 release
      
      ## New plugins
      - [ida-func-call-rank](https://github.com/uky007/ida-func-call-rank) (0.1.1)
      
    14. đź”— smol-machines/smolvm smolvm v1.11.1 release

      What's Changed

      • Carry a machine's remote volumes on serve API execs so a bucket is present for API-driven sessions by @BinSquare in #1039
      • Remove a previous install's bundled agent rootfs so an upgrade cannot keep booting the old agent by @BinSquare in #1040
      • Bind a machine's overlay and remote volumes to one call so launch and exec sites cannot set one without the other by @BinSquare in #1041
      • Bump the workspace to 1.11.1 by @BinSquare in #1042

      Full Changelog : v1.11.0...v1.11.1

    15. đź”— MetaBrainz GSoC 2026: Compose Multiplatform Migration of ListenBrainz-Android rss

      Hi everyone,

      I'm Nirvan Jain (nirvan_jain on IRC, nirvan73 on GitHub), I’m currently a pre-final year student at IIIT Jabalpur. This summer I was offered this opportunity to work with MetaBrainz through Google Summer of Code on migrating the ListenBrainz android app to Kotlin Multiplatform and Compose Multiplatform, so that most of the same codebase can eventually run on iOS under the mentorship of Jasjeet Singh (jasje on IRC).

      This post covers what the project was, everything I worked on, the parts that went wrong, what's still left, and what the summer was actually like.

      How I got here

      I started contributing to ListenBrainz in December 2025. It was the first external open source project I'd worked on. Everything before that was coursework, side projects, or intra-college events.

      My first PRs were small work which helped me a lot to understand the codebase from the ground, the shimmer effect across the Feed and Profile tabs, then extending search to cover playlists, artists, albums and tracks, plus some bug fixes. Small changes, but they taught me the codebase and how review works when nobody knows you and the code has to stand on its own.

      I picked ListenBrainz because music is a constant in my day, whether I'm coding or not, and because I like that it treats your listening history as something you own.

      The Problem

      ListenBrainz has an Android app but no iOS version. A previous Swift attempt just duplicated the codebase, so every bug fix had to be written twice.

      This project solves that by migrating to Kotlin Multiplatform, one shared codebase for both platforms. A large part of the work is replacing Android- only libraries with multiplatform equivalents across navigation, dependency injection and paging. Media playback is the harder case. ExoPlayer and WorkManager are tied too closely to Android to share, so both go behind common interfaces, with ExoPlayer on Android and AVPlayer on iOS underneath.

      Getting this foundation right is what makes the rest cheap. Once it's in place a feature or a bug fix is written once, instead of the same business logic being implemented twice and two apps being kept in sync by hand.

      One thing genuinely can't move. The notification listener that reads what's playing in Spotify depends on an Android-only permission, and iOS has no equivalent to offer. Those screens stay Android-only. Everything else runs from one codebase on both platforms.

      Project overview

      ListenBrainz is a platform for tracking your listening history, sharing what you're into, and building a community around music. The Android app is its mobile face, and this project was about rebuilding its foundations so that face isn't Android-only forever.

      The main goals were:

      • Shared logging with Kermit - Replacing the Android-only logger, with file writing and log submission split across platform implementations (#742)
      • Realtime events in the shared module - Moving off the Android-only socket.io-client so listen and playing_now work from commonMain on both platforms (#731)
      • ViewModels, repositories and the BrainzPlayer & ListensSubmission database into shared - Roughly twenty separate migrations, on top of the KMP lifecycle dependencies (#743 and #744 through #765)
      • A shared work manager - with listen submission and its data models and utilities moved into the shared module (#767)
      • Permissions in shared - with configuration for both Android and iOS (#770)
      • Screen migration - Starting with onboarding, which is where I am now

      Each of these gets its own section below, with what broke, what review caught, and where I diverged from the original proposal.

      Community bonding

      I spent bonding mostly auditing rather than coding. The shared module scaffold and the DataStore work already existed, so the useful question wasn't how to start but what exactly was still Android-only and what would replace each thing.

      That meant going through the dependency list one by one. The logger, socket.io, WorkManager, ExoPlayer, Accompanist, Lottie, the shimmer library, the WebView clients, the paging setup. For each one: is there a KMP-compatible replacement, does it need an interface with two implementations, or can it simply not exist on iOS and therefore has to stay Android-only forever?

      I also discussed with my maintainer and agreed on a migration order during this period. We settled on logging and sockets first, then ViewModels, then services and background work, then UI, so that each layer already had its dependencies migrated by the time it needed them.

      Coding Period

      Shared Logging: replacing the Android logger with

      Where it started

      The app used com.limurse.logger (Logger-Android) behind a thin Log interface:

      // app/util/Log.kt — before interface Log { fun e(message: Any?, tag: String? = null) fun d(message: Any?) fun w(message: Any?) companion object : Log { override fun e(message: Any?, tag: String?) = Logger.e(tag, msg = message.toString()) override fun d(message: Any?) = Logger.d(msg = message.toString()) override fun w(message: Any?) = Logger.w(msg = message.toString()) } }
      

      Two problems. It's a JVM library, so it can't cross into commonMain. And because Log is a companion object called statically from many files, every single one of those files had a hard, untestable dependency on Android. This one had been started by another contributor PR - #728 before I picked it up, the Kermit swap and a first pass at file logging existed.

      What I did was take it apart and rebuild the layering, because the first version had every platform's DI wiring duplicated and the file writer had almost all of its logic sitting in androidMain even though most of it was plain Kotlin.

      The interface stays, the backend changes

      The first decision was to keep theLog interface and its companion. It's called from everywhere, changing the call sites would have made the diff unreadable and the review impossible. So Log moved to shared/util/Log.kt, kept its shape, gained i/v/log and a throwable parameter, and started delegating to a Kermit Logger pulled out of Koin.

      interface Log { fun e(message: Any?, tag: String? = null, throwable: Throwable? = null) fun d(message: Any?, tag: String? = null) // w, i, v, log ... companion object : Log, KoinComponent { private val logger: Logger = get() override fun e( message: Any?, tag: String?, throwable: Throwable? ) { logger.withTag(tag ?: "ListenBrainz").e(throwable) { message.toString() } } // ... } }
      

      KoinComponent on the companion is what makes a static-looking API injectable. The object stays a singleton, but what it is now decided by DI, per platform.

      Splitting the file writer

      The old file writer was one Android class doing five things: formatting timestamps, collecting device metadata, serialising writes, formatting log lines, and actually touching the filesystem. Only the last one is platform- specific.

      So SharedFileLogWriter is an abstract class in commonMain that extends Kermit's LogWriter and does everything except the write. Click to see the implementation

      abstract class SharedFileLogWriter(private val buildConfig: BuildInfo): LogWriter() { private val loggerQueue = Channel<String>(capacity = Channel.UNLIMITED) protected fun initBlock() { loggerScope.launch(Dispatchers.IO) { for (entry in loggerQueue) writeLineToFile(entry) } } override fun log(severity: Severity, message: String, tag: String, throwable: Throwable?) { val level = when (severity) { /* Verbose -> "VERBOSE", ... */ } writeToFile(message, tag, level) throwable?.let { writeToFile(it.stackTraceToString(), tag, level) } } protected abstract suspend fun writeLineToFile(entry: String) }
      

      The Channel is the interesting bit. Logging happens on whatever thread the caller is on, and file I/O has to be serialised or you get interleaved half- lines. An unlimited channel consumed by a single Dispatchers.IO coroutine gives you a non-blocking log() call and a strictly-ordered writer, with no locks.

      As for the iOS implementation, I haven't added it in this PR yet. I wanted to get the base shared setup merged first so the rest of the PRs isn't blocked on moving logger-dependent files into the shared module. Once every file involving logger in their code is migrated over, I’ll follow up with the actual iOS file writer in a separate PR.

      I made one BuildInfo, a plain data class which consists of -> application id, version code, version name, build type, bound in DI by the app. Since commonMain cannot see BuildConfig, so anything that wants build metadata takes a BuildInfo instead.

      Log submission

      "Submit logs" means:- zip everything in the log directory. I have created an interface named LogSubmitter, a contract in common which only have one method as:-

      interface LogSubmitter { suspend fun submitLogs() }
      

      AndroidLogSubmitter is one of the extension of LogSubmitter in androidMain which zips the .txt files, exposes the archive through FileProvider, and fires an ACTION_SEND chooser. Two review-driven fixes landed here: -

      • Passed the PlatformContext as applicationContext through the parameters of the class
      • Handled thread switching explicitly, file compression runs on Dispatchers.IO, while building and launching the chooser intent switches back to withContext(Dispatchers.Main)

      The iOS side (IosLogSubmitter, IosFileLogWriter) is not implemented yet and will be added in a follow-up.

      The DI shape, and what review changed

      My first version had a SharedAppModule.android.kt and a SharedAppModule.ios.kt for all the platform specific modules, each defining a full Koin module. Review corrected this:- it means every new binding has to be added twice, and the two modules drift. The fix was to have one module in commonMain under platformModule and make only the factories expect/actual like provideLogger. Click to see the example of the same

      // commonMain/Platform.kt expect fun provideLogger(buildInfo: BuildInfo): Logger expect fun provideLogSubmitter(buildInfo: BuildInfo): LogSubmitter // commonMain/di/SharedAppModule.kt val platformModule = module { single<Logger> { provideLogger(get<BuildInfo>()) } single<LogSubmitter> { provideLogSubmitter(get<BuildInfo>()) } // ... }
      
      
      // androidMain/Platform.android.kt actual fun provideLogger(buildInfo: BuildInfo): Logger { val writers = mutableListOf(platformLogWriter()) applicationContext.getExternalFilesDir(null)?.let { dir -> val logDir = File(dir, ANDROID_LOG_DIR_NAME).apply { mkdirs() } writers.add(AndroidFileLogWriter(logDir.path, buildInfo)) } return Logger( StaticConfig( minSeverity = Severity.Debug, logWriterList = writers ), tag = "ListenBrainz" ) }
      
      
      // iosMain/Platform.ios.kt actual fun provideLogger(buildInfo: BuildInfo): Logger { val writers = mutableListOf(platformLogWriter()) (NSSearchPathForDirectoriesInDomains( NSDocumentDirectory, NSUserDomainMask, true ).firstOrNull() as? String)?.let { writers.add(IosFileLogWriter(it, buildInfo)) } return Logger( StaticConfig( minSeverity = Severity.Debug, logWriterList = writers ), tag = "ListenBrainz" ) }
      

      Same module, same binding, one line of difference per platform. This became the template for every other platform-backed dependency in the project -RemotePlaybackHandler, PermissionHandler, ListensRepository, the Room builder. Platform.kt is now the single file where you can read off everything the shared module needs a platform to supply.

      Realtime Events in the Shared Module

      "Listening Now" is fed by a Socket.IO connection to listenbrainz.org that pushes two events, listen and playing_now. The existing implementation used io.socket:socket.io-client, which is JVM-only and pulls in org.json:

      // before — app module private val socket: Socket = IO.socket( "https://listenbrainz.org/", IO.Options.builder().setPath("/socket.io/").build() ) socket.on("playing_now") { json.decodeFromString<Listen>(it[0] as String) }
      

      Attempt one: Engine.IO by hand

      Ktor's websocket client is multiplatform, so my first instinct was to drop the Socket.IO library entirely and talk the protocol directly. Socket.IO over websockets is really Engine.IO framing:

      My first implementation did it the hard way. I wrote the Engine.io and Socket.io protocol handling by hand…. on top of ktor-client-websockets.

      • manual handshake with the 40 frame to open the session
      • heartbeat by answering every incoming 2 with a 3
      • and event subscription parsing JSON payloads out of the frames myself.

      Click to see the implementation

      // the version that worked, and that I threw away :( httpClient.webSocket("wss://listenbrainz.org/socket.io/?EIO=4&transport=websocket") { send(Frame.Text("40")) send(Frame.Text("""42["json",{"user": "$username"}]""")) for (frame in incoming) { val data = (frame as? Frame.Text)?.readText() ?: continue when { data == "2" -> send(Frame.Text("3")) // heartbeat data.startsWith("42") -> { val array = json.parseToJsonElement(data.removePrefix("42")) as JsonArray when (array[0].jsonPrimitive.content) { "playing_now", "listen" -> trySendBlocking( json.decodeFromString<Listen>(array[1].jsonPrimitive.content) ) } } } } }
      

      It connected. It received listens. It was also, on reflection a bad idea, reimplementing a wire protocol inside an application repository means the app now owns a protocol implementation it has to maintain and debug and keep in sync with a spec it doesn't control. Thats why I have to switch to using a KMP SocketIO - OSS library.

      Attempt two:

      I switched to com.piasy:kmp-socketio, which is a real Socket.IO client for KMP and crucially lets you hand it your own KtorHttpClient, so realtime traffic goes through the same configured, logged, engine-agnostic client as everything else. Click to see the implementation

      class SocketRepositoryImpl( 
          private val httpClient: HttpClient, 
          private val json: Json, 
          private val logger: Log = Log, 
      ) : SocketRepository { 
          override fun listen(usernameProvider: suspend () -> String) = callbackFlow { 
              val username = usernameProvider() 
              val options = IO.Options().apply { 
                  httpClient = this@SocketRepositoryImpl.httpClient 
                  transports = listOf("websocket") 
              }
      
              var activeSocket: Socket? = null 
              IO.socket("https://listenbrainz.org", options) { socket -> 
                  activeSocket = socket 
                  socket.on(Socket.EVENT_CONNECT) { 
                      socket.emit("json", buildJsonObject { put("user", username) }) 
                  } 
                  listOf("playing_now", "listen").forEach { event -> 
                      socket.on(event) { data -> 
                          runCatching { 
                              val payload = data.firstOrNull()?.toString() ?: return@on
      
                              trySendBlocking(json.decodeFromString<Listen>(payload)) 
                          }.onFailure { logger.e("SocketRepository: $event error ${it.message}") } 
                      } 
                  } 
                  socket.open() 
              }
              awaitClose { activeSocket?.close() } 
          } 
      }
      

      The callbackFlow + awaitClose shape survived the rewrite unchanged, which is the nice thing about having had a decent boundary in the first place, SocketRepository.listen() returns a Flow<Listen?>, and neither the ViewModel nor the UI ever knew which library was underneath.

      KMP Lifecycle, ViewModels and Repositories

      This is where most of the raw hours went and it's the least interesting part to write about, which is exactly why it's worth writing about. This is the bulk of the project by volume: ~20 PRs, one feature each.

      The dependency swap that unlocks everything

      AndroidX lifecycle ships two artifact families: lifecycle-viewmodel-ktx (Android-only) and lifecycle-viewmodel (multiplatform since 2.8). They have the same API. Switching the whole project to the base artifacts is a three- line diff in the version catalog and is the entire technical prerequisite for shared ViewModels.

      The KMP lifecycle dependencies had to land first so migrated ViewModels had a ViewModel base and a viewModelScope that exist on both platforms. Then, one at a time: Settings, Artist, Album, Song, Playlist ,etc ViewModels, the remote playback handler, the BrainzPlayer database, and SocialRepository.

      One PR each, about twenty of them.

      After migrating the viewmodels, repositories and network services to shared module, they needed to be wired up through Koin. I organized these dependencies into dedicated shared modules so the platform app module could easily consume them without caring about their internal package structure:

      • SharedViewModelModule -> Registers all shared ViewModels.
      • SharedRepositoryModule -> Binds the shared repository layer.
      • SharedNetworkServiceModule -> Configures shared API clients and network services.
      • SharedAppModule -> Handles core utility implementations (like RemotePlaybackHandler).

      Retrofit to Ktorfit, OkHttp to engine-agnostic

      Services became Ktorfit interfaces, which look almost identical:

      interface ListensService { 
          @GET("user/{user_name}/listens") 
          suspend fun getUserListens( 
              @Path("user_name") username: String, 
              @Query("count") count: Int, 
              @Query("max_ts") maxTs: Long? = null, 
          ): Listens
      
          @POST("submit-listens") 
          suspend fun submitListen(@Body body: ListenSubmitBody?): PostResponse 
      }
      

      I created an expect fun of the engine with its platform-specific actual fun implementation. Click to preview

      // commonMain 
      expect fun getPlatformNetworkEngine(): HttpClientEngineFactory<*> 
      expect fun configPlatformEngine(config: HttpClientEngineConfig, context: PlatformContext)
      
      // androidMain — OkHttp, plus Chucker in debug builds 
      actual fun getPlatformNetworkEngine(): HttpClientEngineFactory<*> = OkHttp 
      actual fun configPlatformEngine(config: HttpClientEngineConfig, context: PlatformContext) { 
          if (config is OkHttpConfig && BuildKonfig.DEBUG) {
              config.addInterceptor(ChuckerInterceptor(context)) 
          }
      }
      
      // iosMain — Darwin 
      actual fun getPlatformNetworkEngine(): HttpClientEngineFactory<*> = Darwin
      

      The awkward cases

      Not everything I migrated went cleanly. Those are the parts I found interesting, so I'm giving them the most space here.

      String resources in ViewModels

      Several ViewModels emit user-facing success messages by resource id, and commonMain has no R. I could have moved res/, but that's a much larger change than I wanted to make inside a feature PR, so I wrote small provider interfaces keyed by enum instead:

      // shared/util 
      enum class StringResource { 
          TRACK_ADDED_SUCCESSFULLY, 
          PLAYLIST_DUPLICATED_SUCCESSFULLY, 
          /* ... */ 
      }
      
      interface StringProvider { 
          fun getString(res: StringResource): Int 
      }
      

      The app implements it as a one-line when mapping enum to R.string.*, and I bound it in Koin. I wrote three of these: StringProvider, DrawableProvider, ArrayProvider. I made them deliberately boring. They let me migrate a feature today and let someone migrate the resources later, on their own schedule.

      Repositories that really are platform-specific

      ListensRepository needs getPackageLabel(pkgName), which turns com.spotify.music into "Spotify". That's a PackageManager call with no iOS analogue.

      Rather than leak it into common, I kept the interface common and picked the implementation with an expect fun, so I ended up with an AndroidListensRepositoryImpl and an IosListensRepositoryImpl sharing a common parent. I did the same thing for RemotePlaybackHandler, which is Spotify App Remote on Android and a stub I wrote on iOS.

      The BrainzPlayer database

      My proposal listed the local databases as a migration target, and i did the work. Room Multiplatform, schema in commonMain, builder behind expect. The PR consists the moving of four entities, four DAOs, TypeConverter and Transformer across, and deleting the app-side database and converter files outright.

      The boundary turned out narrower then I expected, Only the builder is platform-specific. The driver, the migration list and build() all stay in common DI, so the part I'd most hate to see diverge across platforms is written exactly once.

      // commonMain - the entire platform surface of the database 
      expect fun getBrainzPlayerDatabase(context: PlatformContext): RoomDatabase.Builder<BrainzPlayerDatabase>
      
      single<BrainzPlayerDatabase> {
          getBrainzPlayerDatabase(get())
              .setDriver(BundledSQLiteDriver())
              .addMigration(Migrations.MIGRATION_1_2,Migrations.MIGRATION_2_3)
              .build()
      }
      

      Android supplies a Context and getDatabasePath().absolutePath. iOS supplies a path from NSFileManager. One line of diff , each platform. BundledSQLiteDriver() in common means both platforms ship the same SQLite built. This is the same "one module in common, only the factories are expect/actual", temp late I settled on during the logging migration, and it held up on a much heavier target.

      Room's KMP mode also made me do something I'd never done on Android, The database object needs a generated constructor. Click to preview

      @Database(entities = [SongEntity::class, AlbumEntity::class, ArtistEntity::class, PlaylistEntity::class], version = 3) 
      @TypeConverters(TypeConverter::class) 
      @ConstructedBy(BrainzPlayerDatabaseConstructor::class) 
      abstract class BrainzPlayerDatabase : RoomDatabase() { 
          /* ... */ 
      }
      
      @Suppress("KotlinNoActualForExpect") 
      expect object BrainzPlayerDatabaseConstructor : RoomDatabaseConstructor<BrainzPlayerDatabase>
      

      That @Suppress isn't style. KSP generates the actual, but the Kotlin compiler goes looking for it before KSP has run.

      A drawable resource living in a database column

      The interesting problem in this PR was PlaylistEntity.art. It was an @DrawableRes Int, and commonMain has no R:

      // shared — no idea what a drawable is 
      val art: String = "ic_queue_music"
      
      // app 
      fun getPlaylistArtMapper(art: String): Int = when (art) { ... }
      

      That's the same resource-indirection trick as my StringProvider and DrawableProvider, but with two costs those don't carry. The column is persisted, so changing its type forced a schema migration. And it's stringly- typed, so the compiler stops checking my work. Both costs came due. The migration showed up in review, the lost type safety showed up right after.

      SQLite can't ALTER COLUMN, so MIGRATION_2_3 rebuilds the table. The part I actually thought about is that it back-fills the new keys from the row ids rather than defaulting every playlist to the generic icon, and then repairs sqlite_sequence so AUTOINCREMENT doesn't restart into ids that still exist.
      Click to see the SQLite code

      INSERT INTO `PLAYLISTS_TEMP` (`id`,`title`,`items`,`art`) 
      SELECT `id`, `title`, `items`, 
          CASE WHEN `id` = -1 THEN 'ic_queue_music_playing' 
               WHEN `id` = 0 THEN 'ic_liked' 
               ELSE 'ic_queue_music' END 
      FROM `PLAYLISTS`
      

      Where my plan changed

      Two weeks after this merged, the plan changed underneath it, Since the local music player used ExoPlayer, an android specific component and was tightly coupled to UI components and viewModels that shouldn't have been concerned with, complicating our migration to CMP.

      So my migration turned into a deletion. including the database I had just finished moving. That meant the app also had to clean up after itself for users upgrading from a version that had it:

      private fun cleanupBrainzPlayerResources() { 
          context.getDatabasePath("brainzplayer_database") 
              .takeIf { it.exists() } 
              ?.let { context.deleteDatabase("brainzplayer_database") 
          }
      
          if (Build.VERSION.SDK_INT >= Build.VERSION_CODES.O) { 
              (getSystemService(Context.NOTIFICATION_SERVICE) as? NotificationManager) 
                  ?.deleteNotificationChannel("Music") 
          } 
      }
      

      Shared work manager

      This was the one of the trickiest part of my project and the PR for the same is under review and not merged yet , because listen submission is the one piece of the app that is inherently Android (it works by listening to other apps' media notifications) and yet almost none of its logic actually is.

      Here's the pipeline I ended up with:

      ListenSubmissionService (app, NotificationListenerService — Android-only entry point)
      
      ListenSessionListener (shared/androidMain - MediaSessionManager callbacks)
      
      ListenServiceManagerImpl (shared/androidMain — whitelist)
      
      ListenSubmissionState (shared/androidMain — timers, builds PlayingTrack, schedules work)
      
      ListenSubmissionWorker (shared/androidMain — KMP worker: POST, or persist for retry)
      

      I left only the first box in :app, and only because NotificationListenerService has to be declared in the app manifest. I moved everything downstream of it.

      From androidx.work to KmpWorkManager

      For background work I replaced Android's WorkManager with KmpWorkManager, updated ListenSubmissionWorker to match, and removed the native WorkManager DI wiring. This is one of the places where i diverged from my proposal, which described hand-rolling a BackgroundTaskScheduler interface with WorkManager on Android and BGTaskScheduler on iOS. Using an existing KMP library meant less code to write and less to maintain for the same result.

      I annotate my workers and let KSP discover them:

      @Worker("ListenSubmissionWorker") 
      class ListenSubmissionWorker : AndroidWorker, KoinComponent {
      
          private val appPreferences: AppPreferences by inject() 
          private val repository: ListensRepository by inject() 
          private val pendingListensDao: PendingListensDao by inject()
      
          override suspend fun doWork(input: String?, env: WorkerEnvironment): WorkerResult { /* ... */ } 
      }
      

      I schedule by string name and JSON payload, because a KMP scheduler can't take a Class<*> or an androidx Data:

      scheduler.enqueue( 
          id = "listen-${playingTrack.id}-${System.currentTimeMillis()}", 
          trigger = TaskTrigger.OneTime(initialDelayMs = 0), 
          workerClassName = "ListenSubmissionWorker", 
          inputJson = Json.encodeToString(ListenWorkerInput(playingTrack, ListenType.SINGLE)), 
          constraints = Constraints(requiresNetwork = true), 
      )
      

      so my input model is just:

      @Serializable 
      data class ListenWorkerInput(
          val track: PlayingTrack, 
          val listenType: ListenType
      )
      

      plus an explicit KmpWorkManager.initialize(context, AndroidWorkerFactoryGenerated()) alongside startKoin initialising KMP WorkManager.

      Then ListenSubmissionState moved into the shared module under androidMain, rewired to use the shared notification manager and shared work manager, with the data models and utility functions it depends on coming across with it. ListenSubmissionService in the app module was updated to consume the shared utilities and services, and the Koin registry updated accordingly.

      Permissions in the shared module

      The PR for the same is under review and not merged yet. Last year's contributor built a PermissionEnum that put all permission logic in one place: title, rationale, permanently-declined copy, image, minSdk, maxSdk, and the raw permission string. I think it's a genuinely good design, and it made the onboarding screens trivial to write. It's also, top to bottom, Android:

      enum class PermissionEnum( 
          val permission: String, // "android.permission.BIND_NOTIFICATION_LISTENER_SERVICE" 
          val image: Int, // R.drawable.* 
          val minSdk: Int, // Build.VERSION_CODES 
          val maxSdk: Int? = null, 
      )
      

      Every field except the copy is Android-specific. I couldn't make a single shared enum work, and I didn't want to duplicate the whole thing per platform.

      Splitting the enum without losing the enum

      What I settled on was making the contract an interface, and letting each platform contribute its own enum implementing it. Click to see the implementation

      // commonMain 
      interface AppPermission { 
          val id: String 
          val title: String 
          val permanentlyDeclinedRationale: String 
          val rationaleText: String 
          val image: DrawableResource // enum, not an Int 
      }
      
      // commonMain — permissions that exist everywhere 
      enum class SharedPermissionEnum(..) : AppPermission { 
          SEND_NOTIFICATIONS( 
              id = "send_notification", 
              title = "Send Notifications", 
              rationaleText = "Needed to send updates on activity, recommendations, and system alerts…", 
              image = DrawableResource.IC_NOTIFICATION, 
          ) 
      }
      
      // androidMain — permissions that only exist here 
      enum class AndroidPermissionEnum(
          ..., 
          val systemPermission: String,
          val minSdk: Int, 
          val maxSdk: Int? = null
      ) : AppPermission { 
          READ_NOTIFICATIONS(systemPermission = "android.permission.BIND_NOTIFICATION_LISTENER_SERVICE", minSdk = 33, ..), 
          BATTERY_OPTIMIZATION(systemPermission = "android.settings.REQUEST_IGNORE_BATTERY_OPTIMIZATIONS", minSdk = 23, ..), 
      }
      

      I made image a DrawableResource enum resolved by the DrawableProvider, so my shared code can name an icon without knowing what an R.drawable is. That left me one problem. SEND_NOTIFICATIONS lives in common but still needs an Android manifest string and a minSdk on Android.
      I solved it with an extension in androidMain that supplies the Android facts for shared constants

      The handler

      I moved everything behavioural behind one interface:

      interface PermissionHandler {
      
          fun getAllRelevantPermissions(): List<AppPermission> 
          fun getPermissionsForPermissionScreen(): List<AppPermission> 
          fun isPermissionApplicable(permission: AppPermission): Boolean
      
          suspend fun isGranted(permission: AppPermission): Boolean 
          fun storageKey(permission: AppPermission): String
      
          suspend fun requestPermission( 
              permission: AppPermission, 
              activity: Any? = null, 
              permissionRequestedOnce: List<String> = emptyList(), 
              dangerousPermissionLauncher: (permission: String) -> Unit = {}, 
          ): Boolean? 
      }
      

      activity: Any? is the one compromise in my whole design, and I want to be upfront about it. commonMain cannot name Activity, and Android's rationale APIs (shouldShowRequestPermissionRationale) genuinely require one. So my Android implementation casts (activity as? Activity) and degrades gracefully to a FLAG_ACTIVITY_NEW_TASK intent when it's null.

      I kept all of last year's special cases in the Android implementation, including the two "permissions" that aren't runtime permissions at all.

      My iOS handler is much smaller, and that's the point. It only has to answer for the permissions iOS actually has, which is just SEND_NOTIFICATIONS since iOS sandbox security and privacy rules don't allow the other permissions anyway.

      One detail which is storageKey(). Whether a permission has been requested once is persisted in DataStore, and the obvious key is the enum constant's name, which means renaming a constant would silently reset everyone's onboarding state. On Android I use the system permission string instead, which is stable by definition. On iOS I use the explicit id field, and that's the only reason I put id on the interface at all.

      Screen migration: onboarding

      I'm currently working through the UI layer starting with onboarding.

      Onboarding is a reasonable place to start for two reasons. It's the first thing a user sees, so regressions are visible immediately and get caught fast.

      The back half is different. Listen submission setup and the third-party app selector both depend on NotificationListenerService, so by the same reasoning as above those screens stay Android-only and won't exist in an iOS build. The shared onboarding graph walks both platforms through the first three screens, Android then hands off to its own two, and iOS ends the flow there.

      A side quest: token login

      While working on the auth screens, I added a direct-token login path alongside the existing WebView flow. Due to ongoing server-side auth migrations, we needed a more direct and temp, resilient fallback while keeping the door open for multiplatform support. Click to see the implementation

      fun submitToken(onLoginFinished: () -> Unit) {
          val token = uiState.value.token.trim()
          if (token.isBlank()) return setError("Token cannot be empty")
          if (uiState.value.loginState is TempLoginState.VerifyingToken) return
      
          viewModelScope.launch {
              val result = withContext(ioDispatcher) { listensRepository.validateToken(token) }
              val validation = result.data
              if (result.isSuccess && validation?.valid == true) {
                  appPreferences.username.set(validation.username ?: "")
                  appPreferences.lbAccessToken.set(token)
                  onLoginFinished()
              } else {
                  setError(validation?.message ?: "Invalid token. Please check and try again.")
              }
          }
      }
      

      What's left

      I'd rather say this plainly than bury it. My proposal was ambitious and several sections of it are still open:

      1. iOS file logging and log submission are TODO(). The shared machinery (queueing, formatting, startup metadata, the LogSubmitter contract) is all done and platform-neutral, the two iOS leaves are stubs.
      2. System bar control away from accompanist-systemuicontroller.
      3. Browser and external URL handling via expect/actual.
      4. Lottie to Compottie.
      5. Shimmer to a KMP shimmer implementation.
      6. Onboarding screen migration and all other composable screens migration to CMP, started but not complete.
      7. Testing migration to Kotlin Test with shared tests in commonTest

      Two reasons for the gap. The foundational work, logging, sockets, ViewModels, notification and work manager, permissions, took considerably longer than I estimated, largely because each piece went through multiple review rounds that improved it but slowed it down. And the OAuth login change arrived mid-project and cost time I hadn't planned for.

      Post-GSoC plan

      I 'm not going anywhere. The unfinished list above is my roadmap, roughly in this order.

      • The UI dependency cluster:- WebView, system bars, browser handling, Lottie, shimmer. These are individually small and mostly independent, so they can be done steadily instead of needing a large block of time.

      • Then finishing the screen migration, continuing from onboarding through the home navigation shell, settings, dashboard and feed.

      • Then the testing migration, moving platform-independent tests into commonTest so the shared module has an actual safety net. This one matters most for whoever picks the project up after me. A migration without tests is a liability handed to the next person.

      • And eventually the real OAuth login flow, replacing the temporary token-paste screen with something users shouldn't have to put up with.

      Outside the migration I still want to build the playlist sorting feature from my proposal, and keep fixing bugs.

      What I learned

      The clever solution was usually the wrong one. My instinct on the socket migration was to build the impressive thing, hand-rolled protocol handling and all. The right answer was the boring maintainable one, and I now read the urge to be clever as a sign I haven't thought hard enough about who maintains this in two years.

      Almost everything I actually learned came out of review. Thread safety, DI hygiene, why println doesn't belong in production code. Having changes requested three times on one PR taught me more than any PR that merged first try, though getting comfortable with that, treating requested changes as information rather than as a verdict, took a few weeks.

      Final Thoughts

      I am truly grateful for this amazing opportunity and thanks Jasjeet for his constant guidance and reviewing an enormous amount of my code carefully and for pushing back every time I was overcomplicating something. A fair amount of this post is his review comments with more words around them.

      More than anything, this project showed me the gap between code that works and code that lasts. I learned to think in terms of clean contracts, edge cases, and long-term maintainability rather than quick fixes. It gave me real confidence in navigating complex codebases, embracing tough reviews, and contributing to industry-scale projects with purpose.

      And Finally, thanks to the MetaBrainz community for their support. This was my first serious open source project and it's a welcoming place to have started. I'll be around well past this summer.

    16. đź”— smol-machines/smolvm smolvm v1.11.0 release

      What's Changed

      • Carry remote volumes on the embedded machine spec so SDK machines can mount buckets by @BinSquare in #1034
      • Mount remote volumes for runs without a persistent overlay so ephemeral runs see their bucket by @BinSquare in #1036
      • Carry a machine's remote volumes on every exec so the bucket is present whichever container serves the session by @BinSquare in #1037
      • Bump the workspace to 1.11.0 by @BinSquare in #1038

      Full Changelog : v1.10.1...v1.11.0

    17. đź”— Armin Ronacher Anger, Anxiety and Agency rss

      Sean Goedecke wrote a post arguing that you should never be angry at work — a post with which I strongly agree. Anger can be a useful signal, but being angry at work rarely improves the situation. More often, it makes life worse for the people around you, many of whom have no more power over the source of your anger than you do. I did learn that lesson, but it did not come naturally. One thing in particular that I learned is that in a company there is a shared vision, and if you don't agree with it and are not in a position to change it, you should not start a mutiny, not even a small-scale one. Nothing good comes from that.

      In the discussion around that topic, one of the most upvoted comments on the Lobsters thread asked a question I had to think about quite a bit:

      How can you work in tech right now and not be angry?

      In the context of the thread, this was clearly also about AI and agents. For me, the emotions I would expect in tech vis-a-vis these new developments are disorientation and anxiety, but not anger.

      Anxiety as an emotion does not require someone to blame. Right now, I find it reasonable to feel anxious about an uncertain future. Who knows what our professions will turn into and what kind of world my kids will find themselves in when they enter the workplace? And if you've been in the industry for a long time, will the skills you've spent years acquiring still matter?

      But anger is different from anxiety because anger needs to be directed somewhere. The feeling of anger suggests that somebody or something is doing something to you.

      Who are you going to be angry at and why are you angry in the first place? One narrative that is pretty pervasive is that if AI will usher in productivity gains, those gains are going to benefit companies rather than employees. And well at least someone at Meta wants that. Yet I also find that plenty of people in leadership positions express doubt about AI. They see that an increasing share of their costs is being funneled directly to some large AI labs. They express worries about what will happen to their data and whether these large companies will step into their space instead of being partners.

      My answer to the question of how you can not be angry in tech is that it's by no way the most only possible feeling. First of all, instead of being angry, you can simply be unsure. The feeling of uncertainty is a much more productive emotional state because it can lead to curiosity. Even if you don't find what's happening right now exciting, you can at least find it interesting. We have access to magic machines, and we can poke at them and see what happens. The second way is to feel genuine excitement. Once you move beyond curiosity, you can come away with a newfound feeling of power and freedom. A lot of the gains from AI aren't turning into productivity gains that are reflected in company profits but they're showing up instead in the number of side projects shipped by everybody not on their company's time.

      The fact that this is happening shows us that owners and founders don't necessarily know what will happen. Ownership comes with agency, but it does not provide foresight, and this change is disorienting for everybody. I engage with plenty of people who project confidence in public and are much less certain in private. Many of them are placing bets, but they are talking with confidence about those bets, trying to keep their business afloat while the ground moves under them. They experience that uncertainty from a position where they can act on it, and they are often standing somewhere with a megaphone to get others on their side to improve their odds.

      I feel that contradiction myself: I am simultaneously tremendously excited, but I am also unsure what will happen next. I do not know what it will mean to be a programmer in the future, and, as the owner of a company, I am also not sure where the high ground will be when this all settles. Much of what I learned over the years is changing rapidly, including ideas I considered fundamental to my craft and business. Some days that feels liberating, but on others I wake up feeling like the ground is crumbling beneath me.

      Anxiety is an uncomfortable emotion because it acknowledges that you do not know what will happen and might not be able to stop it. On the other hand, anger can feel more actionable because, instead of saying "I don't know," you already have someone to blame. It turns a loss of control into a comforting story with a villain. But I feel that particularly when it comes to AI, it's easy to pick the wrong villain because of how disruptive the change is for everyone. Your engineering manager or leadership team might themselves feel uncertain about their future and just try to bolster their own confidence by projecting clarity and certainty.

      That does not mean there are no villains. When this all plays out, some will profit and many will not. I'm afraid we're completely ignoring the impact this has on society at large, the climate, and the balance of the world as a whole. As excited as I am about the technology, I worry about Europe's lack of ambition and growing dependence on other countries. I have a lot of complex thoughts about what we're doing as an industry right now.

      I don't know what the future of this industry will look like, and I don't know who will benefit from it and I don't think I'm alone with that. However I can only urge anyone who feels anger and looks for a villain right to instead remain curious instead. To be curious enough to understand what is changing, excited enough to experiment with it. And then, from what we learn, earn the right to decide when resistance is warranted and where to direct it.

  3. August 23, 2026
    1. đź”— IDA Plugin Updates IDA Plugin Updates on 2026-08-23 rss

      IDA Plugin Updates on 2026-08-23

      New Releases:

      Activity:

      • AiDAPrivate
      • disrobe
        • 61e5c9ba: js: reuse module names across independent factories
        • 88fe49f3: php: recover fetch_is variable reads
        • d1bb0686: provision php 8.4 for op array differentials
        • 2e586db4: wasm: grade threaded auto output and json refusals
        • be5b597f: native: route boundary traps through every x86 leaf consumer
        • 7829a85c: php: recover variadic and named call arguments
        • d46764c4: native: refuse int3 at declared function boundaries
        • 77e35e38: jvm: require private unreferenced lambda helpers for declaration elision
        • c1a4eff1: as3: pin short-circuit and merge reconciliation boundaries
        • b72d90cb: php: recover list destructuring assignments
        • 179722ea: wasm: bound module source rendering
        • 5d1f819c: javascript: refuse unproven for-of subjects
        • 711c0d40: workspace: partition windows tests by package
      • headless_ida_9.4_claude_skill
        • c0603394: Revise README for Claude IDA skill version 3
        • 246e84aa: Harden Bash discovery when no initial IDA paths exist
        • e0098097: Document setup parameters, discovery, and v3 feature branch
        • ff99d97c: Bring Bash setup to parity with PowerShell parameters and discovery
        • 1f0cf229: Discover all local IDA 9.1-9.4 installs and prefer 9.4
        • eca3657e: Fix trailing IDA path separator breaking idapro imports
        • 5439c23b: Fix PowerShell setup path discovery crash
        • c944e974: Merge pull request #1 from shefben/feature/intelligence-speed-v2
        • eac7b12e: Document project-scoped global skill state
        • 48cfd960: Document global-skill project state isolation
        • b0deab5f: Record project identity in evidence databases
        • 6687bd42: Use project-scoped default graph database
        • 4e12bbb0: Namespace persistent state by project identity
        • 64630853: Document 3.0 intelligence and speed upgrade
        • 00d663de: Bump skill version for intelligence layer
        • 1242e77c: Wire Claude to new intelligence and speed layers
        • 0d434521: Make finding application transactional and verifiable
        • 9302edfc: Add planner runtime recovery indexer and investigation frontier
        • c54fceb1: Add multi-binary project graph
        • c2790090: Add SQLite evidence graph and contradiction tracking
      • ida-free-mcp
        • 6e08fd04: fix(release): build universal macOS binary and clean up its rpaths
      • ida-func-call-rank
        • 919d023e: Add Plugin Manager metadata for Hex-Rays repository
      • ida-nexus
        • 0b4e1ebc: Mark registered tools as essential in omp per default
      • twdll
        • 4e6c3d9d: test(military_force): ensure dynamic target bodyguard key in AppointC…
        • f985c8f5: feat(military_force): support custom bodyguard_key option in AppointC…
        • f4d5961f: feat(military_force): implement AppointCharacter method
        • 605f43dd: fix(tweakers): validate SetInt lookup result and preserve float value…
        • e4f0619f: docs(changelog): release version 0.10.0
        • b3385736: fix(core): reset lua stack before module registration in luaopen_twdll
        • e3613b37: refactor(tweakers): summarize tweaker and campaign variable restore l…
    2. đź”— r/LocalLLaMA New qwen3.8:27b on a 39k line C to single-file HTML / three.js port rss

      New qwen3.8:27b on a 39k line C to single-file HTML / three.js port | I was just curious how the new qwen3.8:27b does on a hard C to HTML porting job against Opus 5 in a default Claude Code. The job: my fun side project is a procedural shooter in a single C file. Port it to a single-file html / three.js with one bot. One prompt, no follow-ups, no help from me. game.c is 2.1 MB, roughly 600k tokens of C, so it doesn't fit in the window and the agent has to walk the file and work out what matters. Setup: qwen3.8:27b in FP8 on vLLM, FP8 KV cache, full 262144 context, RTX 6000 Pro 96GB. Nothing truncated on my side, and the file is still more than twice the window. | agent | model | wall clock | lines out | result
      ---|---|---|---|---
      claude code | Opus 5 (cloud reference) | 21 min | 1759 | okay
      hermes | qwen3.8:27b | 4h 18m | 949 | bad
      codehamr | qwen3.8:27b | 1h 40m | 1056 | bad

      Video has the C original first, then the three ports in table order. Only the Opus port is something in "okay" quality.

      What I actually wanted to know is whether the HTML comes out playable at all. One run each and a one-shot prompt for 39k lines of C, so this isn't representative of anything, and I knew it was brutal for a local LLM.

      My take: local models still live or die on the prompt. Same weights under two very different harnesses gave me the same broken port. hermes carries a lot more machinery, and a single turn with a thin prompt gives it nothing to use it on, so it spent four hours reaching the same place. A verbose harness doesn't rescue a thin prompt, it just burns GPU time.

      No deep take here, unfortunately. The thing I keep staring at is the wall clock: hours of GPU on decent local hardware against 21 minutes for the cloud run. If anyone knows where those hours actually go, I'm listening.

      The C original: https://github.com/codehamr/skill-issue
      My experimental local-first, no plugins codehamr harness: https://github.com/codehamr/codehamr

      All free.

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

    3. đź”— MetaBrainz GSoC 2026: Modernize search storage format for the MusicBrainz database rss

      Hello Everyone!

      I’m Junaid (fettuccinae), an undergraduate Computer Science student at MGIT in India. This summer, I returned to MetaBrainz for my second GSoC project, where I worked on modernizing the MusicBrainz search under the mentorship of @kartikohri13 and @bitmap.

      Project Overview: MusicBrainz uses Apache Solr for search queries. The previous implementation serialized all the response data into a single _store field. The response writers reads _store, unmarshal the XML into a MusicBrainz XML Metadata Format (MMD) object and then serialize it again as XML or JSON for the response. Few problems with this design are: 1. The indexer must construct a complete XML representation for every document, even though much of the same information is already available in normal Solr fields. 2. Most of the response data is stored in an opaque _store XML blob. This project focused on moving the fields from one _store XML blob into their own flat fields (and JSON strings for nested fields). The main goals of this project were: 1. Upgrade the Solr schema version from 1.5 to 1.7 2. Add fields (in configsets and indexer) to store all the data to be returned 3. Create response writers to return data from fields The proposal for this project can be found here. Result: This project replaced the _store blob with stored fields and JSON string fields across all 16 search entities. I reindexed both the old and new configurations using the sample MusicBrainz database, then force-merged the indexes before measuring them. I wrote a python script to measure their sizes using Solr's status API and compared them. The total core size went from 3.8 GiB to 2.8 GiB, saving around 1 GiB or 26%. Collection| Old core| New core| Difference% ---|---|---|--- annotation| 15.8 MiB| 14.8 MiB| 5.8% area| 7.9 MiB| 4.5 MiB| 42.9% artist| 131.3 MiB| 81.2 MiB| 38.2% cdstub| 94.0 MiB| 56.0 MiB| 40.5% editor| 5.6 MiB| 1.9 MiB| 65.6% event| 2.3 MiB| 1.4 MiB| 39.7% instrument| 542.8 KiB| 405.2 KiB| 25.4% label| 10.7 MiB| 6.3 MiB| 40.6% place| 6.2 MiB| 3.7 MiB| 40.1% recording| 3.0 GiB| 2.2 GiB| 26.1% release| 37.2 MiB| 25.9 MiB| 30.5% release-group| 42.1 MiB| 31.7 MiB| 24.7% series| 1.2 MiB| 624.5 KiB| 49.6% tag| 3.6 MiB| 1.6 MiB| 56.0% url| 65.7 MiB| 44.4 MiB| 32.3% work| 363.0 MiB| 307.1 MiB| 15.4% Total| 3.8 GiB| 2.8 GiB| 26.1% With codec enabled, it reduces to 2 GiB with a size difference of 1.8 GiB or 47.9%. (The trade-off here is the search speed performance) Collection| Old| New| Difference % ---|---|---|--- annotation| 15.8 MiB| 12.1 MiB| 23.4% area| 7.9 MiB| 4.0 MiB| 49.7% artist| 131.3 MiB| 66.2 MiB| 49.6% cdstub| 94.0 MiB| 49.8 MiB| 47.1% editor| 5.6 MiB| 1.7 MiB| 68.9% event| 2.3 MiB| 1.2 MiB| 47.5% instrument| 542.8 KiB| 370.2 KiB| 31.8% label| 10.7 MiB| 5.5 MiB| 48.5% place| 6.2 MiB| 3.2 MiB| 48.7% recording| 3.0 GiB| 1.5 GiB| 49.5% release| 37.2 MiB| 19.6 MiB| 47.2% release-group| 42.1 MiB| 20.2 MiB| 52.1% series| 1.2 MiB| 570.6 KiB| 53.9% tag| 3.6 MiB| 1.4 MiB| 61.2% url| 65.7 MiB| 38.1 MiB| 42.0% work| 363.0 MiB| 236.1 MiB| 34.9% Total| 3.8 GiB| 2.0 GiB| 47.9% Implementation details:

      Upgrading the schema:

      The Solr schema change from 1.5 to 1.7 enables docValues by default for primitive field types.
      Most primitive fields are already stored directly with stored="true". Since docValues are mainly used for faceting, sorting, and function queries, I added docValues="false" to primitive field types to avoid storing the same value twice.
      ref_count is used in boost functions in some cores , which needs docValues.
      I created a new int_dv field type with docValues="true" and used it for ref_count and the other count fields used by boost functions.
      Finally, I bumped the schema version from 1.5 to 1.7 in each core and verified that indexing and search continued to work.

      Schema upgrade PR

      Configset:

      I changed fields that can be stored directly to stored="true" and added the remaining fields with indexed="false" and stored="true".
      I then removed _store field from the schemas and request parameters.

      I replaced ngram with edge-ngram, since we don't require non-edge permutations of a query during search.

      Configset PRs

      Indexer:

      In the SearchEntity class, I added a preserve_og flag. When converting a result dictionary into a Solr document, this flag preserves the original field order instead of converting the values to a set.
      I also added an objconverter method, which allows a specific field’s structure to be converted before it is sent to Solr.
      The preserve_og flag is enabled for simple parallel fields, such as tags. These fields do not need to be stored as JSON, instead, they use two parallel multi-valued fields. Preserving their order is necessary so that each tag_count remains associated with its corresponding tag_name.
      The objconverter method is used to convert nested fields into JSON strings.

      In each Search, I moved fields from extrapaths to their respective fields and added the required objconverter methods for nested fields.
      The existing wscompat converter logic for nested objects was mirrored to create these objconverter methods.
      The remaining logic for creating MMD objects is now handled by the response writers.

      Indexer PRs

      Response Writer:

      I added MBFlatXMLWriter, a field based response writer that reads the stored fields and, by mirroring the logic in wscompat's converters, create a MMD object and write it to the response.
      I added entity-specific builders to construct MMD object from its stored fields. MBFlatXMLWriter uses these builders as helper classes.

      I made MBJSONWriter which is currently used by MusicBrainz website search, to extend MBFlatXMLWriter instead of MBXMLWriter and verified that search works.

      I also updated the tests to validate the new flat field logic instead of the old _store logic.

      Response Writer PR

      Future

      The next steps for this project are to:
      1. Benchmark it in production and measure disk, RAM, and CPU usage to see whether the optimizations hold up in a real environment or introduce any regressions.
      2. Use Solr’s default response writers instead of custom response writers, and build the MMD objects in musicbrainz-server itself.

      Conclusion

      This project was more complex than my previous one. I spent a good amount of time understanding and deep-diving into Apache Lucene and Solr internals.

      The implementation was a lot of fun because I was constantly experimenting with different approaches and reporting my findings. Each time I triggered a reindex, I stared at the terminal, hoping that indexing would not throw a wall of errors and that the core size would at least remain the same as the baseline.

      Overall, the project gave me a much better understanding of search engines, some of the distributed-system techniques used by Solr, and the complexity of MusicBrainz itself.

      I’m thankful to my mentors, @kartikohri13 and @bitmap, for their support and guidance. It has been a pleasure working with you all. Thanks for an incredible summer!

    4. đź”— Confessions of a Code Addict Demand Paging: What Happens When Linux Handles a Page Fault rss

      Welcome back to the video series on virtual memory based on my article on the same topic. It is also available in ebook format on Gumroad (pdf/epub) and Amazon Kindle, if you prefer those formats.

      Buy PDF/Epub

      Get Kindle Edition

      So far in this video series we have covered the foundational pieces behind virtual memory:

      From here on, the next set of topics is going to be more advanced and important for debugging memory issues in real-world systems. The topic of this video is demand paging, which is central to how memory allocation works inside the kernel.

      Demand paging simply means that when you ask the kernel for more memory, it reserves a virtual address range for you but does not perform physical memory allocation until you actually need it. This can lead to tricky situations and unpredictable system performance if you do not design your systems keeping this in mind.

      The famous OOM killer that appears and kills your processes is also a result of demand paging, because the kernel may end up overcommitting more memory than what is physically available, and ultimately it has to kill a process to free up some memory to recover the system.

      In this 45-minute video, we cover in depth what demand paging is, what its benefits are, and how it works inside the Linux kernel. And if you watch the full video, you would also get an idea of how the kernel handles page faults for various situations, such as when the page has been swapped, illegal address access, accessing file-backed pages, accessing an unmapped, copy-on- write fault, etc.

      In the next follow-up video, I plan to do a hands-on demo of demand paging in action. We will use mmap and inspect the virtual memory of the process to see that merely calling mmap does not cause a physical page allocation, but accessing a page does. Wait for the next video!

      Read more

    5. đź”— smol-machines/smolvm smolvm v1.10.1 release

      What's Changed

      • Remote volumes: mount S3 and any rclone remote with the volume flag by @BinSquare in #986
      • Rebuild the Windows krun.dll so machines boot on WHP again by @BinSquare in #1025
      • Resume and bound-retry a broken blob download so a stalled registry cannot hang a machine create indefinitely by @BinSquare in #1026
      • Bump libkrunfw to the guest kernel with IPv4/IPv6 policy routing so TUN-based VPN and proxy clients work by @BinSquare in #1024
      • Bump libkrun so Windows 10 hosts can start machines and aarch64 fork rollback keeps the golden alive by @BinSquare in #1028
      • Gate the guest's IPv6 on real host reachability and default its resolver to IPv4-first by @BinSquare in #1023
      • Bump the workspace to 1.10.0 by @BinSquare in #1029
      • Install the rebuilt agent into the rootfs directory the current platform actually uses by @BinSquare in #1031
      • Mount S3 volumes natively from the agent instead of requiring rclone in the image by @BinSquare in #1032
      • Bump the workspace to 1.10.1 by @BinSquare in #1033
      • net: verify host IPv6 reachability probe caching and gate Unix fabric tests by @swar09 in #1030

      New Contributors

      Full Changelog : v1.9.2...v1.10.1

    6. đź”— r/LocalLLaMA Don't want to be this guy, but I need Qwen 3.8 35B A3B rss

      Qwen 3.8 27B is great, however it takes me ages to do tasks on xhigh. I need Qwen 3.8 35B A3B. It'll be a little dumber but faster. I am also aware of the fact that 27B gets its "intelligence" from the long thinking time. I therefore assume that 35B would also be a long-thinking model, however running Qwen 3.8 27B over night on my M1 Max for just one task is impractical and no fun.

      I love the progress and the work of alibaba with 27B but... yeah I sadly don't own a faster RTX. What are you guys wishing or hoping for? Where do you see the future going? - Longer thinking times for higher intelligence?

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

    7. đź”— Register Spill Joy & Curiosity #96 rss

      When I compare the first 10 years of my professional life as a software developer to the last two it's mind-boggling how many things that seemed foundational, or: institutional, in the life of a software developer from, say, 2008 to 2022 are now anything but that:

      GitHub and open source contributions (maintainers are closing down pull requests; who cares about their GitHub contribution graph anymore? When was the last person hired due to their open source contributions?), StackOverflow (you just said "ahh, right, StackOverflow", didn't you?), O'Reilly books, FANG as the hottest place to work, 2-week sprints (2 weeks, man! You know how long that is now?), TDD (I wrote books that use TDD! I loved TDD! And yet at some point in the last 2 years I wrote my last test by hand), text editors (man, I had heated arguments about text editors; I worked on a text editor; I was close to getting Vim tattooed on my body at some point), …

      It's like Lenin said: "There are decades where nothing happens; and there are weeks where decades happen."

      • My Laracon talk now on YouTube: How I Prompt. What an intro from Aaron. I swear I didn't pay him to say all of that.

      • I love this idea for a Greasemonkey 2.0: "Modern coding agent + browser use + a custom personal extension that allows you easily modify your most frequently visited sites. Have extension track which sites you visit and then coding agent proactively suggests modifications to make sites less distracting / more efficient." I just checked, though: 2.0 was released in 2014, so this will need to be called Jellymonkey 1.0.

      • This is the best and most beautiful and most inspiring and most thought-provoking and humbling thing I've read this week: Canon. There are many great things in this post, but here's one special snowflake of a paragraph that I want to present to you: "Cant is a language designed to be frustrating in enlightening ways. A reasonable objection might be that it will teach bad coding habits. But from my own childhood experience, what it will actually teach is why the good habits are good and how the layers of abstraction and expressibility get built one on top of another."

      • Stripe acquired OpenRouter for $7.5 billion and the letter to investors leaked. What writing! You can tell it's the Collisons: "Stripe is, of course, a private company today. We view this as a growing advantage as we venture into the vicissitudes of the singularity. The world is becoming harder to predict and we expect that deft helmsmanship will be required of every company. We're fortunate to have a corporate structure that helps us steer the right long-term course."

      • On that acquisition, I found this post by Martin Casado interesting (even though, of course, when you read his "what a time to be alive!" chant at the end and know that he invested in Cursor and OpenRouter, it's hard not to go "yeah, I bet, mate"): "AI has given us two modern miracles. The first one everyone knows, which is that we can turn electricity into intelligence. But the second one is more subtle but equally miraculous. It's that we now have intelligence as a universal medium of exchange, in the form of tokens." Tokens as an exchange medium is very interesting.

      • The Vicent Marti post on the history of scaling Git is as good as everyone says it is: Git at any scale.

      • A lot of people are shitting on GitHub for their outages but, dude, look at the numbers: 2.9 billion commits per month, 24 million new repos. "Since April, monthly commits have grown from 1.4 billion to 2.9 billion." Since April! "We have since added more than 3 million CPU cores, 120 petabytes of high-speed storage". Hot damn.

      • Thomas Dullien / Halvar Flake: Three important steps in my maturation process. The whole thing is very good and I feel bad about highlighting one of the three steps here, but, well, this bit here was very neat: "The monocausal determinism that young computer enthusiasts get used to is an illusion that generations of electrical and process engineers spent their lives perfecting and maintaining. It is because of these engineers that computer scientists could largely get away without probabilities or any empirical grounding in the past. There is an argument that you have so many natural scientists that crossed over into AI because CS education was for a long time too focused on reasoning within the deterministic monocausal illusion."

      • I need someone to explain the Nvidia & Poolside deal to me.

      • Thought-provoking, nearly sci-fi level stuff on emergency alerts: And then the men with guns tell you to do it anyway.

      • Someone tweeted a photo of a handout that David Foster Wallace gave to his students in 2002 in his Advanced Fiction class and I loved it so much that I threw the photo into Amp and had it build a nice HTML version for me that I can reference: Your Liberal-Arts $ at Work. The punctuation in dialogue is fascinating. Not only because it just seems like arbitrary rules, but also because it's completely different in German writing, or French.

      • David Senra interviewed Travis Kalanick. Listened to the whole thing and still don't know what to think of Kalanick. There's some good entrepreneur porn in there ("I can take more pain than the other guy") and Kalanick obviously loves big statements and big visions and big numbers, but I found some half-sentences here and there surprisingly nuanced and interesting. And how he thinks about "work" vs. "management capacity" matches what I think we're seeing with AI now: you still need humans, you still need to hire humans, because, yes, the AI can do the work, but you only have so much management capacity to manage that work.

      • Derek Sivers is "building my dream house without predicting - by living in a bare cabin in the woods, then adding only what I find I actually need." Here's my bet: there are at least (!) six paragraphs in there that will make you go "wait, what", each one with more incredulity than the last. But then at the end, you think: what a guy, I'm glad he's out there and doing this and writing about it.

      • People of ACM - Russ Cox. "Ousterhout introduces the term 'tactical tornado' for a programmer who churns out tons of working but overly complex code that doesn't fit well into the existing system. Worse, a bad manager often sees a tactical tornado as the most productive programmer on a team, failing to recognize the complexity and code debt left behind for the rest of the team to clean up. If we aren't careful managers, AI agents can easily become the ultimate tactical tornadoes."

      • Really, really enjoyed this Invest Like The Best episode with Ben Thompson. Listening to Thompson speculate on token prices and talk about depreciation of GPUs makes me happy.

      • Do this for me: open the Bun 1.4 release notes but before you do anything I want you to look at the scroll bar. Yes, that's a single release. I bet that whole post is AI-generated, but that's also probably the whole point of this post.

      • Same: I'm becoming AI-blind. We've had Amp post messages into our Slack when something went wrong or when something was shipped and it took just a couple of days for everyone to glaze over them. Disabled it right after someone mentioned it.

      • Very good: Responsibility Is Taken Before It Is Given.

      • Dan Luu: There's no reason for software to be slow anymore. That's right. As I was saying: if you have more bugs due to AI now, that's on you, not the AI. Dan also quotes Marc Brooker who talked about "workload-specific optimizations", i.e. optimizations of a program for a particular customer and workflow, and, man , right! AI and agents could be super compilers!

      • Gabriel Valdivia's beautiful personal timeline. Go and open this in a desktop browser, hover over the age in the top right corner, and then slide left and right.

      Hey, we're nearly there: 1 million subscribers. You could be the one that gets us over the line:

    8. đź”— smol-machines/smolvm smolvm v1.10.0 release

      What's Changed

      • Remote volumes: mount S3 and any rclone remote with the volume flag by @BinSquare in #986
      • Rebuild the Windows krun.dll so machines boot on WHP again by @BinSquare in #1025
      • Resume and bound-retry a broken blob download so a stalled registry cannot hang a machine create indefinitely by @BinSquare in #1026
      • Bump libkrunfw to the guest kernel with IPv4/IPv6 policy routing so TUN-based VPN and proxy clients work by @BinSquare in #1024
      • Bump libkrun so Windows 10 hosts can start machines and aarch64 fork rollback keeps the golden alive by @BinSquare in #1028
      • Gate the guest's IPv6 on real host reachability and default its resolver to IPv4-first by @BinSquare in #1023

      Full Changelog : v1.9.2...v1.10.0

    9. đź”— r/LocalLLaMA Qwen 3.8 27B is a game changer. rss

      Our devs got their hands on it a few days ago. One wired it into Codex to compare with GPT Luna, our usual workhorse right now for its cost effectiveness. Another tried it out on one of our OCR pipelines.

      It's comparable to Luna for coding and OCR quality appears to be better than Gemini 3.5 Flash Lite. That's huge. We pay a ton of money for OCR.

      This is the first local model that feels like more than a toy. It's truly as capable as the frontier models from a year ago. For the first time ever there's serious discussions about buying our own hardware. With estimates that such an effort would pay for itself in less than 2 months.

      Hyper scalars are in big trouble this time. Their whole "moat" is buying up all the hardware. And thanks to sanctions on China we're seeing the quality of small local models skyrocket. As someone who's been around a while, this feels like an "IBM moment". Where the industry assumed that databases would always run on huge mainframes. Only to be wiped out by cheaper local solutions a few years later.

      I have a feeling this release will trigger another Llama style open source Renaissance. We're already getting better quants. Inference will be further improved. We might even see a comparable MoE with 500+ Tok/sec on consumer hardware soon.

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

    10. 🔗 r/LocalLLaMA “The All Spark” Cluster: Upgrading from 16 - 36 DGX Sparks rss

      “The All Spark” Cluster: Upgrading from 16 - 36 DGX Sparks | Earlier this year I posted about building what at the time I believe was the first 16x DGX Spark Cluster.
      I’m now adding 20 more Sparks to the cluster in my homelab server rack, giving me 4.6TB of unified memory. • 36x Sparks • 1x 200Gbps FS 24 x 200Gb QSFP56 + 8x 400Gb Switch • 24x QSFP56 DAC cables • 6x 400gb to 2x 200gb breakout cables Over the last 4+ months i’ve been running nearly every notable model that’s landed. The cluster however isn’t just being used to serve single inference points, I’ve split the cluster up to house “inference modules” that get managed into a single persistent agent using a combination of Hermes + a custom memory sidecar system i’ve built. It’s become an agent capability cluster more than just one big inference machine: I’m expanding the cluster to 36 now because I want 16 nodes dedicated to SOTA models such as Kimi K3 while being able to retain enough nodes to perform rerank/embeddings tasks, video generation, Image gen, audio processing etc all simultaneously. Now, you may ask why not just buy 6000 Pros, or B200s or even a B300 and the answer comes down to a few reasons. 1) This server rack will also have 2 6000 pro systems (a 4x Max Q low power build + an 8x enterprise server) which replace my H100s and GH200 I had earlier in the year. 2) B200/B300 for a homelab create substantial cooling and energy problems than even this currently absurd homelab and a big point of this build is to be completely sovereign with zero datacenter or third party storage reliance. 3) Sparks in my view are still the greatest value for scalable unified memory you can get. When M5 Ultras come out I think adding Mac Studios and investing in figuring out disaggregated inference will be a massive win. 4) Sparks + 6000 Pros give massive flexibility for configuration, power optimization and relatively easier liquidity access when I want to offload and upgrade to something new submitted by /u/Kurcide
      [link] [comments]
      ---|---

    11. đź”— anthropics/claude-code v2.1.241 release

      What's changed

      • Bug fixes and reliability improvements
    12. đź”— Ampcode News Friendly URLs for Sharing Orbs rss

      We use orb portals all the time to share what we're builing and get feedback.

      But the URLs were ugly and auto-generated. So, we made them nice and friendly. Now, instead of sharing t-01a0095e-9568-whatever-p1234.onamp.dev, you can share foo--yourname.onamp.dev or even use your own domain like park.mixfox.org (which is on an orb, basically).

      Sharing an orb portal in Slack with a rich preview and an Open Portal button

      This is especially nice when a portal is a long-lived application, not just a preview of changes to your local dev server. And that's increasingly how teams are using portals.

      Click the in the Portal tab to set the hostname, or ask Amp to do it for you in an orb. You can set up a personal custom domain or a workspace custom domain, or just customize the hostname prefix before --yourname.onamp.dev.

      The Portal Hostname dialog with a friendly onamp.dev hostname

  4. August 22, 2026
    1. đź”— IDA Plugin Updates IDA Plugin Updates on 2026-08-22 rss

      IDA Plugin Updates on 2026-08-22

      Activity:

      • REToolSync
        • f74fa218: Add some error logging and fix websocket shutdown
      • twdll
        • 1ca38ad6: fix(core): ensure luaopen_twdll idempotency via registry caching and …
        • aef7cdb7: refactor(attila): introduce typed TW_VectorNcc and TW_OneToOneLink te…
        • e639862f: refactor(world): resolve max units limits via campaign model initiali…
        • 70e5cb85: refactor(world): manage character max traits limit via engine tweaker…
        • 54fcf456: refactor(attila): resolve refresh_settlements_display via tweaker reg…
        • 3ef93ba6: refactor(core): remove obsolete offset_tag and raw-offset Getter cons…
        • 3bf93c8f: refactor(attila): structure political parties hash map with typed buc…
        • f012ff0f: refactor(attila): clean up reverse engineering notes, standardize com…
        • f22cc342: refactor(attila): clean up reverse engineering comments from engine h…
        • f3d038aa: feat(tweakers): implement engine tweakers and campaign variable routing
        • ee129ba1: refactor(attila): model engine tweaker with typed TW_Tweaker struct
        • 5a0f0543: fix(character): use native string assignment operators in name setters
        • fff36d3a: refactor(attila): standardize includes, remove diagnostic scaffolding…
        • 29643fb0: fix(test): use native save/load persistence for reload check and fix …
        • 468fc97d: feat(test): add automated multiplayer smoke test suite and dual-insta…
        • 535fee7e: tests: remove previously added usless test
    2. đź”— anthropics/claude-code v2.1.240 release

      What's changed

      • Bug fixes and reliability improvements
    3. đź”— r/LocalLLaMA This is a great sub, regardless of what complaints people have about it. rss

      This is a genuine community of real generally respectful adult human beings. Despite the enthusiasm all of you have for local AI, you can recognize that there are times when local LLMs are flawed, and even how practical they are to use for the majority of people to use. Go over to r/linux and you'll see the contrast in maturity and employment.

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

    4. đź”— smol-machines/smolvm smolvm v1.9.3 release

      What's Changed

      • Remote volumes: mount S3 and any rclone remote with the volume flag by @BinSquare in #986
      • Rebuild the Windows krun.dll so machines boot on WHP again by @BinSquare in #1025
      • Resume and bound-retry a broken blob download so a stalled registry cannot hang a machine create indefinitely by @BinSquare in #1026

      Full Changelog : v1.9.2...v1.9.3

    5. đź”— HexRaysSA/plugin-repository commits sync repo: +2 releases, -1 release rss
      sync repo: +2 releases, -1 release
      
      ## New releases
      - [ida-nexus](https://github.com/hexrayssa/ida-nexus): 0.7.0
      - [ida-rpc](https://github.com/bkerler/ida_rpc): 0.1.9
      
      ## Changes
      - [BinSync](https://github.com/binsync/binsync):
        - removed version(s): 5.11.2
      
    6. đź”— Armin Ronacher Fast and Hard Code rss

      One of the memes on Twitter is that "programming is solved now." I'm not sure to what degree it is, but one thing is pretty clear: the act of familiarizing yourself with a language no longer matters and some of the friction that mattered for humans does not matter for agents.

      As a result, LLMs make language choice much less consequential than it used to be. If you don't like the choice, you can seemingly rewrite it in another language and you can make it pick a language that you, as a programmer, are entirely unfamiliar with.

      Which in turn means that people can, and do, choose based on the marketing of languages much more. As a long-term Rust programmer I found it quite fascinating to see people now ship Rust code who previously might not have chosen it. I attribute at least one part of this to two recent vibe shifts: there is a lot more talk about wanting fast software, and about LLMs being exceptional at optimizing code without regressing behavior.

      Folks like Mitchell Hashimoto, Charlie Marsh, Jarred Sumner, Daniel Lemire and quite a few others always carried a certain level of obsession with fast and performant software and they also all happen to be receptive to agents writing code. Maybe as a result, or unrelated others are now joining in. That's because with things like autoresearch you don't even necessarily need to know all the tricks: you just need to put an agent on it — though knowledge greatly helps!

      If you look around, there are plenty of projects that want to be fast and small, and they increasingly pick "hard languages". And it's not just Rust that is benefiting. Even Zig — despite the fact that the creators and parts of the core community are pretty negative on the whole AI thing — is too. For instance Cloudflare's new Artifacts service uses a pure-Zig Git-protocol engine, compiled to a roughly 100 KB WebAssembly module and Vercel released fx, a Zig coding agent advertised to be small and fast. From what I can tell, all these projects are largely LLM- assisted.

      But it's not just people picking less common languages but also that they are increasingly working with "much harder" technologies. All of a sudden I have seen people do some really impressive stuff with DWARF files, eBPF, custom network drivers, custom crypto and really old computing hardware. Many of these things were previously off-limits for lots of developers. In some cases (eg: crypto) you were even pushed away because those things were intentionally gatekept by the people in the know.

      So maybe the world will have more slop, but it might also have more developers in it, that want things to be fast and small.