🏡
  • ↔
  • →
  1. August 11, 2026
    1. 🔗 msgspec/msgspec Version 0.22.0 release

      What's Changed

      • Add frozendict support on Python 3.15+ (#1052, #1105).

      • Support passing a callable as decimal_format to msgspec.json.Encoder and
        msgspec.msgpack.Encoder for custom Decimal encoding (#978).

      • Support Literal[True] and Literal[False] types (#1004).

      • Publish Linux riscv64 wheels (#987).
      • Support the PyEmscripten (Pyodide) platform (#1083).

      • Fix handling of PEP 695 type parameter syntax (class Foo[T]) and of
        types.GenericAlias instances in type annotations (#962).

      • Fix a crash on incorrect typing.ClassVar annotations (#1097).

      • Fix an AttributeError when converting to a Struct type defined in a
        namespace without a __name__ (#1072).

      • Fix a reference leak when decoding msgpack Ext payloads (#1109).

      • Fix reference leaks in typenode_collect_literal, Meta.__rich_repr__,
        ms_decode_bigint, and Encoder.__init__ (#1021, #1022,
        #1023, #1040).

      • Fix msgspec.inspect.type_info and msgspec.json.schema crashing on mixed-type Literals such as Literal[1, None] (#1080).

      • Fix missing GC traversal and clearing of some module state members (#1060).
      • Ensure an exception is always set on allocation failures (#1044).
      • Fix compilation warnings on Python 3.15 (#1077).

      • Many type stub improvements and fixes (#1014, #1043, #1053,
        #1055, #1057, #1062, #1065, #1074, #1093).

      • Document the differences between msgspec.structs.asdict/astuple and
        msgspec.to_builtins (#1025).

      • Document that omit_defaults ignores fields with a custom
        default_factory (#1076).

      • Fix the msgspec.json.decode docstring to say dec_hook should raise
        NotImplementedError for unsupported types, not TypeError (#774).

      • Fix backing type declaration of Ext.code (#1135).

      • msgspec moved to the msgspec GitHub organization;
        documentation now lives at msgspec.dev (repository
        references updated in #1045).

      New Contributors

      Full Changelog : 0.21.1...0.22.0

    2. 🔗 MetaBrainz Picard 3 beta 9 released rss

      Today, we have released MusicBrainz Picard 3 beta 9. This new versions brings several fixes over the last beta 7 (yes, we have skipped a beta number again), but also improvements and some new features.

      Since we are near a final release, we tried to focus on quality of life and UI/UX improvements, some changes in the UI are quite important (release preferences UI is a complete overhaul, and the new About dialog also got a nice refresh). Among the highlights are:

      • MetaBrainz OAuth2 support and various OAuth improvements and bug fixes
      • ISRC reading (from files or CD) and optional submission

      • Word diff for tags in the Metadata Box

      • UI/UX improvements: Redesign of some option pages, along re-organization and performance improvements

      • Plugin API improvements

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

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

      Some of the changes are also backward incompatible, hence we recommend you make a backup of your Picard.ini config file before trying the beta version. You can do so in Picard’s Options under Advanced > Maintenance.

      What’s new?

      Bugs

      • [PICARD-3349] - Copying the "new" column of a deleted tag in the metadata box copies the old value instead of empty
      • [PICARD-3351] - Options dialog is sometimes too big in height, impossible to access Make It So button
      • [PICARD-3352] - "Embed only a single front image" option can prevent images to be loaded
      • [PICARD-3357] - Some Cyanrip log files fail to be parsed
      • [PICARD-3365] - Debug options tooltips not shown
      • [PICARD-3368] - Removing multiple tags from multiple tracks is slow
      • [PICARD-3372] - Infinite OAuth retry loop when refresh token is revoked

      New Features

      • [PICARD-163] - ISRC support for lookup and submission
      • [PICARD-2482] - Submit ISRCs from CD
      • [PICARD-3355] - Allow plugins to unregister script variables and allow double registering
      • [PICARD-3356] - Expose plugin_persist storage in plugin v3 API
      • [PICARD-3358] - Add metadata tag context menu extension point and script variable title for plugins
      • [PICARD-3363] - Add option to allow complete albums to be auto removed after save
      • [PICARD-3367] - Add shell completion generation for picard-cli
      • [PICARD-3369] - Add a test playground for checking file names in local cover art options

      Improvements

      Download

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

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

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

      Acknowledgements

      Code contributions by Bob Swift, Bryan Roessler, Laurent Monin and Philipp Wolfer.
      Translations were updated by "ApeKattQuest, MonkeyPython" (Norwegian Bokmål), blueday (Swedish), Gsam3 (German), Marc Riera (Catalan), silentbird (Chinese (Traditional Han script)) and Vaclovas Intas (Lithuanian).
      Documentation updates by Bob Swift, Laurent Monin and Philipp Wolfer.

    3. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 release rss 
      sync repo: +1 release

## New releases
- [ida-codemode](https://github.com/hexrayssa/ida-codemode): 0.5.0
    4. 🔗 PrimeIntellect-ai/prime-agent Beta (v0.7.1-beta.473.1.14d6e74) release

      Automated beta build from main (14d6e74919a5fba4916e5cc04b4f439a09a3750a).

    5. 🔗 r/LocalLLaMA Qwen 3.8-27b coming this week rss

      Qwen 3.8-27b coming this week | Confirmed by the official Qwen account. submitted by /u/Bestlife73
      [link] [comments]
      ---|---

    6. 🔗 hacker news ida pro references New comment by mettamage in "Squeak 6.1" rss

      It does though. It teaches you that closed source is still open source in many many ways. Especially when you have something like Ghidra or IDA Pro. Nowadays this is even more true because LLMs can speed up retrieval of missing knowledge way more quickly. Back in the day I had to search for stuff but I bet now that LLMs give a decent guess at decompilation of something. Also it's the systems programming language and requires you to dive into the computer architecture of things. Try that with Python or JavaScript.

    7. 🔗 backnotprop/plannotator v0.26.8 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.26.7 | Pinpoint targets any element on HTML pages, smarter hover labels, zero-scan hit testing
      v0.26.6 | Fixed empty environment variables in sandboxed sessions (Bun 1.3.14 builds)
      v0.26.5 | HTML pinpoint element annotations, durable annotate submissions, installer fallback for old git, vim HUD cursor fix
      v0.26.4 | Skill-menu hover jitter fix (same-day patch on v0.26.3)
      v0.26.3 | Skill references in comments with / or $, reachable remote session URLs, worktree switcher tooltips
      v0.26.2 | Single-file diff tabs render fully, no more silently dropped review files, light/dark theme pairs, palette-matched code blocks
      v0.26.1 | GitButler 0.22.0 compatibility via capability-probed JSON flags
      v0.26.0 | Edit Mode (suggest by editing the diff), Guided Review virtualization, colorblind theme, safe uninstall, installer opt-outs, OpenCode 2 support
      v0.25.1 | Codex no longer launches on review open, annotate-last follows the live conversation, pi-todos mirror, Claude Opus 5, abandoned-gate dismissal
      v0.25.0 | Vim keyboard controls, Approve with Notes, scriptable annotate gates, persistent Guided Reviews, memory and file-watching hardening
      v0.24.2 | Annotate YAML/JSON/TOML config files, XDG data directory support, Codex model catalog update, Cursor sandbox escape hatch
      v0.24.0 | PR/MR artifact gallery, GitButler review support, port ranges, expanded comment editor, OpenCode + Pi fixes

      What's New in v0.26.8

      This release rebuilds how annotations look and behave on HTML pages, and it is the largest change to the annotate surface since pinpoint mode shipped. Nine PRs landed, three of them from first-time contributors @Snaylaker, @atomicflag, and @monkhai.

      Placed comment markers replace inline highlights on HTML pages

      Annotating a raw HTML page used to write highlight markup directly into the page's own DOM. That caused two visible bugs: multi-paragraph selections often turned only their first paragraph blue, and on some pages the injected markup broke the page's layout. Both had the same root cause, so both are gone the same way: nothing writes into the page anymore.

      Annotations now appear as numbered comment bubbles projected onto a fixed overlay above the page. A bubble sits at the exact point you clicked, not a corner of the element, and it stays glued through scrolling, page re-renders, responsive reflows, and zoom. If the annotated element disappears or scrolls out of a clipped container, its bubble hides instead of floating over unrelated content, and it returns when the target does. Selections highlight through the same overlay, so highlights now always cover the full selection and can never disturb the page beneath.

      The bubbles are real buttons: click one, or click the highlighted text itself, to jump to that annotation in the panel. Highlights brighten on hover so you can tell they are clickable. Bubble numbers match the numbering in the feedback your agent receives, so "see comment 3" means the same thing on screen and in the session. Committed highlights still print; annotating with Cmd+P in mind works the way it did before.

      The implementation went through three adversarial review rounds, a 25-item QA gate with independent verification of every serious finding, and a follow-up hardening pass covering clipping, visibility, print, and per-frame performance on mutation-heavy pages.

      Shift-click selects multiple elements for one comment

      One comment can now cover several places on an HTML page. Make a pinpoint selection, hold Shift, and click more elements: each gains an outline and a chip in the composer, Shift-clicking a selected element removes it, and removing the first selection promotes the next one rather than cancelling the draft. Up to 16 additional targets ride on one comment, and after saving, every target shows a bubble carrying the same comment number. Feedback to the agent lists every selected element, so "these three buttons need the same fix" is one comment, not three.

      HTML sessions open minimal, and stale preferences reset

      Opening an HTML page to annotate now shows just the page: pinpoint input ready, tools hidden, sidebar and annotations drawer closed. Anything you change persists for your next HTML session, but only while you keep using HTML annotate. A preference untouched for a week expires back to these defaults, so a mode you tried once months ago never becomes a permanent surprise. Active users keep their setup; annotating refreshes the clock.

      Pages with their own Content-Security-Policy are now annotatable

      An HTML file carrying its own strict CSP meta tag (common in saved pages and generated reports) silently blocked the annotation script, leaving a page you could see but not annotate. The annotate viewer now removes the document's CSP meta tags before rendering. The iframe sandbox remains the security boundary, and the file on disk is untouched.

      OpenCode: Qwen3.6 no longer corrupts the planning prompt

      OpenCode sessions using Qwen3.6 hit a Jinja template conflict: Plannotator injected its planning instructions as multiple system-prompt parts, and Qwen's template mangled them. @atomicflag rewrote the injection to compose one consolidated system part. The review process surfaced a subtle evaluation-order bug and an escaping edge case, both fixed and regression-tested, and the QA gate then caught that the OpenCode 2 adapter still used the old multi-part path, so the fix now covers both OpenCode 1 and OpenCode 2 entry points.

      Plan position survives window refocus in vim mode

      Switching away from a plan review window and back again reset the vim cursor to the top of the document. @Snaylaker fixed the refocus path to preserve your position, so alt-tabbing to check something no longer costs you your place in a long plan.

      Additional Changes

      • File headers show a hover state in code review. Diff file headers now tint on hover with a short transition, signaling that the header is clickable (it collapses the file). Contributed by @monkhai in #1256.
      • The legacy self-hosting docs route redirects to the canonical docs site. #1255

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

      OpenCode: Clear cache and restart:

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

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      What's Changed

      • fix(vim): preserve plan position on refocus by @Snaylaker in #1252
      • Fix OpenCode plugin Jinja template corruption with Qwen3.6 by @atomicflag in #1114
      • feat(annotate): shift-click multi-element selection for raw-HTML pinpoint by @backnotprop in #1254
      • fix(marketing): redirect self-hosting guide to canonical docs by @backnotprop in #1255
      • feat(review): add file header hover state by @monkhai in #1256
      • feat(annotate): placed comment markers for raw-HTML annotation by @backnotprop in #1257
      • fix: QA-gate hardening for the v0.26.8 feature set by @backnotprop in #1258
      • fix(annotate): strip document-authored CSP meta tags that block the annotation bridge by @backnotprop in #1259
      • feat(annotate): minimal-by-default HTML sessions with stale-preference decay by @backnotprop in #1260

      New Contributors

      Contributors

      Three first-time contributors landed changes in this release. @atomicflag took on a genuinely tricky compatibility problem between Plannotator's system-prompt injection and Qwen3.6's Jinja template, and stuck with it through three review rounds until the fix was airtight. @Snaylaker fixed the vim-mode position reset on window refocus, a small paper cut that anyone reviewing long plans felt daily. @monkhai polished the code review diff headers with a hover state that makes the collapse affordance discoverable.

      Welcome to all three, and thank you.

      Full Changelog : v0.26.7...v0.26.8

    8. 🔗 Ampcode News Global Plugins and Skills rss

      With so much work happening in orbs there needed to be a new place to store Amp plugins and skills. So we added global plugins and skills. They're Amp-hosted, built for agents, and work everywhere Amp runs.

      You can now tell Amp to:

      • "Create a personal plugin that runs our formatter on every file the agent edits."
      • "Import the browser-testing skill from this repo into my personal skills so I can use it on all my projects."
      • "Does anyone on my team share a skill for writing release notes?"
      • "Check if any of my imported plugins are out of date."
      • If you're a workspace admin: "Copy Thorsten's plain-writing plugin into our workspace plugins."

      You can find them in your User Settings and Workspace Settings:

      Personal plugins settings showing plugins with their source

      Workspace skills settings showing shared skills

      Personal vs Workspace

      Personal plugins and skills are good place to experiment and try things out. You can have your agent build something and reload the plugins live within the same thread.

      Workspace plugins and skills are pushable by workspace admins, and are loaded by default for everyone, so we recommend only publishing there once you've tested out something yourself. And if you want to make big changes to an existing workspace plugin, import it into your personal one, give it a test, and then publish it back up.

      Remix and Share

      Personal plugin and skills are much more than a replacement for ~/.config—they can be shared with your workspace too, letting people discover, import and remix them.

      Share dialog with Private and Workspace visibility

      A shared plugin's page showing its source files and where it was imported from

      If there's upstream updates you'd like to pull into your version, or just update your version, you can run amp skill update <name>, amp plugins update <name>, or just ask Amp:

      • "Update the browser-testing skill to the latest version."
      • "Check if any of my imported skills are out of date."
  2. August 10, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-08-10 rss

      IDA Plugin Updates on 2026-08-10

      New Releases:

      Activity:

      • CaeriusIDA
        • b3c50800: Ajoutez des fichiers projet.
        • b296a084: Ajoutez .gitattributes, .gitignore, README.mdet LICENSE.txt.
      • capa
        • ce846fe4: Sync capa-testfiles submodule
        • 79c0d8d0: Merge pull request #3140 from mandiant/dependabot/npm_and_yarn/web/ex…
        • aaf5c643: build(deps-dev): bump js-yaml from 4.3.0 to 4.3.1 in /web/explorer
        • 3563c217: build(deps): bump pip from 26.1.2 to 26.2 (#3136)
        • 1caf26ed: Sync capa rules submodule
      • disrobe
        • c3d4217e: codec: unify seeded adler32 checksums
        • 24cd219d: codec: type and bound lenient percent decoding
        • f6b88958: pyarmor: own hotpatch scratch directories
        • a751dd6e: action: pair output flags with cli commands
        • 65e972e5: native: reject wrapped section file offsets
        • 52827e0a: contain trusted tool process trees
        • 89f05c94: dotnet: refuse unlowered compiler constructs
        • 87a2dc29: core: gate Windows-only anti-analysis imports
        • 61a5a0c4: tighten PHP differentials and static precision checks
        • 49772719: keep full coverage off routine main pushes
        • 52db8fa1: release: prepare v0.10.5
        • 11f4cb3d: go: require parsed containers for recovery
      • DynamicVarCheck_IDA
      • fifam
      • grokathon
        • fd70bd2b: arcade: add desktop start prompt
      • hrtng
        • eb6b9c20: fix enum importing; fix auto-comments;
      • ida-codemode
        • c888608d: Improve timeline view of the dashboard
        • eb4553bc: 0.5.0
        • 80eb7945: Add new trace events to dashboard
        • 3417d0eb: Reformat
        • 4598de45: Do not try hcli from PATH
        • 9155aad9: Switch to regular ida-domain release
        • 7567c320: Add ida-codemode-logs tool to collect logs in a self-contained package
      • ida-domain
      • ida-hcli
        • 56ee5e23: fix: require rich>=14.1 so nested spinners don't abort commands (#296)
        • ef2eba2e: fix: pass all arguments through to the program in ida python commands
        • fd20bd39: docs: document how hcli finds the IDA installation, version, and Python
        • db1e25e6: refactor: consolidate Python-environment inspection in hcli.lib.venv
        • 4dfc729a: refactor: resolvers report their source; explain-environment consumes…
        • 908a5969: refactor: express no-build-isolation only through PipOptions
        • 200c3ce4: refactor: probe interpreter versions in exactly one place
        • 26928279: perf: probe IDA's Python via idat once per process
        • 2a5d02cd: refactor: delete dead hcli.lib.util.python module
      • IDAPluginList
        • e6aa4a2f: chore: Auto update IDA plugins (Updated: 19, Cloned: 0, Failed: 0)
      • Luc-Nhan
        • b1140450: fix(tools): coerce hex-string int args and guard future.cancel()
        • 29ed93c4: fix(tools): reject unknown tool args with actionable message
      • twdll
        • ce21343c: feat: add political parties methods
    2. 🔗 r/LocalLLaMA I trained a 1B-parameter LLM from scratch on 20B tokens for about $200 rss

      I trained a 1B-parameter LLM from scratch on 20B tokens for about $200 | A few months ago, I had the idea of making a LLM from scratch as a personal project (for learning and partly for improving my resume). Since I learned a lot from other posts on here over the past year, I wanted to share the results. TLDR: I trained a 1.1B param model on 20B tokens from fineweb-edu, then finetuned it on openhermes with LoRA to get a chat model. Total cost was about $200 (in February/March though, so it would probably be more expensive now).

      The architecture is based on Gemma3 since it was my most used model when I started. There are a few differences: - I have a smaller context length (4096) and because of that I didn't use sliding window attention. - I have a smaller vocabulary (32k, trained the tokenizer with sentencepiece) - I also tweaked some hyperparameters to reach my target parameter count. For the data, I used fineweb-edu for training the tokenizer and pretraining the model. Then LoRA finetuned the model on openhermes. I purposely tried to find data from 2023 and earlier because I saw this post back then and thought it would be cool to test the model by asking it questions about the "future" (like I did in the gallery images). As far as the training goes:

      Pretraining

      For pretraining, I first did training runs on 2B tokens to test the architecture at 3 sizes: 185M, 500M and 1.1B. Then I did a final run of the 1.1B model on 20B training tokens. I did it on vast.ai and here's the summary: | | 185M | 500M | 1B (on 2B tokens) | 1B (on 20B tokens)
      ---|---|---|---|---
      Total params | 185M | 527M | 1.1B | 1.1B
      GPU | 3090 | 5090 | H100 | H100
      Duration | 19h | 17h | 13h | 130h
      Final val perplexity | 19.2 | 16.0 | 15.1 | 10.93

      Also I logged in wandb generations from a few fixed prompts every 30M training tokens or so (was probably the most fun part of the project to check the new samples every couple hours to see the improvements) Here are a few examples for the final 1B model.

      Input prompt: "Let me tell you a story:"

      At 30M tokens seen text Let me tell you a story: a person, you should your child, and the other person who can take the time and the person with its own. If you do not want to give them a bit, you can learn from a student

      At 20B tokens seen text Let me tell you a story: I lived in a large city and we were having a little get-together. We all knew each other for years – so much so that I was surprised to learn that we met. It was around this time that one of us decided to become a vegetarian.

      Input prompt: "The capital of France is"

      At 30M tokens seen text The capital of France is by the other of the Western Europe. The U.S. and the church are the first of Christ in 1937, the other three times of the world.

      At 20B tokens seen text The capital of France is Paris and its currency is the Euro. A French person is called a Francais. After the Second World War, the French government decided to introduce a new currency that was pegged to the dollar.

      Lora finetuning

      To get a chat model, I ran some Lora finetuning on the best 1B model, using Openhermes as a dataset. I also did it on vast.ai, but on a 3060 and over 52 hours. Reached a final validation perplexity of 2.71 (not that it means anything since it is not on the same dataset as the previous values)

      Again I did have some regular logging of sample prompts.

      Input prompt: "What is gravity"

      At 3M tokens seen

      text The answer is: Gravity is the force that causes objects on Earth to stay together. At 250M tokens seen

      text Gravity is the force that causes objects to fall toward each other.

      Input prompt: "Write a short poem about a frog."

      At 3M tokens seen

      text Write a short poem about a frog. eleph. At 250M tokens seen

      ```text A frog's heart beating In the dark and damp wood A frog's voice, so soft No one can hear.

      It's a call, a croak, a chorus Of frogs in the night's air

      The land, the air, the water A place where frogs thrive. ```

      Input prompt: "What is the chemical formula for water?"

      At 3M tokens seen text heatwaves and water. mangan What is the chemical formula of oxygen? mangan At 250M tokens seen text H2O.

      Overall, over training that the model became more and more concise, especially compared to the base that was very yappy. Still, the quality is not very good for the total price. (when comparing to nanochat for example). When I have some more time, I will probably experiment with some full sft instead of LoRA, and maybe some extended datasets.

      Side-quests

      The post is already pretty long so I will just list quickly some of the other things I tried out: - Because my version had some differences with the original Gemma3 and also because I wanted to understand a bit better how it works, I added the architecture in a fork of llama.cpp. - To test it out, I vibecoded a WearOS app I used to run a Q2_K GGUF version of the 1B model (runs at about 2tok/s on my watch) - I ran a few benchmarks with lm-eval, nothing really interesting to note, it is weaker than Gemma3 1B across the board. - I deployed a demo website on GCP (deploying the model on CPU with the GGUFs) to analyze logprobs of the base model (and compare it with a few other small models) and chat with the instruction-tuned model. I don't know much about frontend so the React was completely vibecoded.

      Conclusion

      Even if the model is not that good, I learned a lot while doing it and I can only recommend to anyone who wants to better understand LLMs. It has also helped me in my job search process over the past 4 months (whether for getting more interviews or for doing better in ML technical interviews)

      Let me know if you have any feedback testing the model or any question!

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

    3. 🔗 @binaryninja@infosec.exchange Capable of lifting more than ever, with more performance improvements and mastodon

      Capable of lifting more than ever, with more performance improvements and features crammed into one of our biggest releases ever: Binary Ninja 6.0! Join us today @4pm ET to see a preview of our latest improvements: https://youtube.com/live/PojKznVNE_o

    4. 🔗 r/LocalLLaMA Muse Glimmer ACTUALLY fits on a single RTX 3090 rss

      I did some testing this morning, and I was surprised to find that Muse Glimmer actually comfortably fits on a single RTX 3090 with full context + DFlash + mmproj at Q4_K_XL, unlike Qwen3.6-27B and Gemma-4-31B.

      Muse Glimmer supports up to 256k context according to Unsloth. Here is my command:

      llama-server \ --model Muse-Glimmer-30B-UD-Q4_K_XL.gguf \ --mmproj Muse-Glimmer-30B-mmproj-kquant.gguf \ --spec-draft-model Muse-Glimmer-30B-DFlash-kquant.gguf \ --spec-draft-ngl 999 \ --spec-draft-n-max 15 \ --spec-type draft-dflash \ -c 262144 \ --override-kv muse-glimmer.context_length=int:262144,dflash.context_length=int:262144 \ -ngl 999 \ -fit off \ --parallel 1 \ --flash-attn on \ --no-warmup \ --cache-type-k f16 \ --cache-type-v f16 \ --temp 1.0 \ --top-p 0.95 \ --top-k 64 \ --reasoning-preserve \ --jinja \ --host 127.0.0.1 \ --port 8080

      This fits in about 22GB to 23GB of VRAM, actually leaving a reasonable amount of unused memory.

      On this RTX 3090, for Qwen3.6-27B and Gemma-4-31B, this is what I've been able to achieve using their Q4_K_XL models with MTP + mmproj, right at the limits of the RTX 3090's VRAM:

      Model | F16 KV cache | Q8 KV cache
      ---|---|---
      Qwen3.6-27B | 70,000 tokens | 125,000 tokens
      Gemma-4-31B | 52,000 tokens | 81,000 tokens

      Those small contexts have been borderline unusable on f16, and I don't enjoy using Q8 KV unless absolutely necessary, so I mostly use my slower DGX Spark to run these models at the full context.

      On Muse Glimmer, there seems to be little reason to use my DGX Spark since it fits so nicely on the RTX 3090. Maybe I could run a bunch of parallel agents with full KV on the Spark.

      Muse Glimmer also runs at between 64 tok/s and 124 tok/s in my testing under DFlash, depending on whether it is outputting prose or code. Either way, a pretty solid speed. I've seen about 1400 tok/s of prompt processing.

      I also ran a two needle haystack test at about 150k tokens with one needle at the beginning and the other at the end, and the model retrieved them perfectly on the first try, so this is definitely not soft-capped to 128k context.

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

    5. 🔗 r/LocalLLaMA Mark Zuckerberg on releases rss

      Mark Zuckerberg on releases | https://x.com/i/status/2086755195535413696 submitted by /u/jacek2023
      [link] [comments]
      ---|---

    6. 🔗 r/LocalLLaMA unsloth/Muse-Glimmer-30B-GGUF · Hugging Face rss

      unsloth/Muse-Glimmer-30B-GGUF · Hugging Face | Guide: https://unsloth.ai/docs/models/muse-glimmer submitted by /u/Nunki08
      [link] [comments]
      ---|---

    7. 🔗 r/LocalLLaMA Introducing Muse Glimmer: an open-weight model optimized for always-on local agent workflows rss

      Introducing Muse Glimmer: an open-weight model optimized for always-on local agent workflows | Hi r/LocalLLaMA 👋 Today we’re excited to release Muse Glimmer, a 30B open-weight model built specifically for local agent workflows. We’re releasing the weights to the community under a permissive Apache 2.0 license. A few specs

      • 30B params, dense
      • Multimodal: interleaved text + images via a dedicated perception encoder
      • Trained on 100+ languages
      • Controllable reasoning effort (quality/speed tradeoff)

      Memory footprint
      At full precision, 30B needs 55+ GB, which is out of reach for consumer hardware. We quantize weights to ~4-bit, bringing the LM under 20 GB. That leaves headroom in a 24 GB or 32 GB envelope for the KV cache, the perception encoder, and the speculative decoding drafter running simultaneously. We validated minimal to no degradation on agentic tasks under compression. Speculative decoding
      Ships with a lightweight DFlash-based drafter that proposes blocks of tokens which the main model verifies in parallel. Significantly faster than token-by- token generation with identical output quality. We're also shipping quantized drafter versions so the memory overhead stays small. A few capabilities
      We trained Muse Glimmer for agentic loop tasks, including:

      • End-to-end task completion (strong performance on DeepSearch QA, MCP-Atlas, 𝛕3-Bench, SWE-Bench, and more)
      • Function calling with precise schemas across long workflows
      • Multi-step reasoning over long horizons
      • Failure recovery — when a tool call fails or returns something unexpected, it's trained to diagnose and retry instead of halting. This was a deliberate training target.
      • Works with OpenClaw and other agentic scaffolds
      • Multimodal understanding and reasoning

      Running it
      Weights are up on Hugging Face. Coming soon: Ollama, LM Studio, Unsloth and torchtitan, plus optimized integrations for llama.cpp, MLX, and ExecuTorch. vLLM and SGLang for serving. Get started quickly with Together AI, Fireworks AI, and OpenRouter. We're also working with AMD, Arm, Dell, Intel, and NVIDIA on per-device optimization. We look forward to your feedback and seeing what the community builds with Muse Glimmer. 🔗 Weights: https://huggingface.co/meta-models
      🔗 Research Blog: https://go.meta.me/museglimmer
      🔗 Resources: https://developer.meta.com/ai/models/muse-glimmer/ submitted by /u/AIatMeta
      [link] [comments]
      ---|---

    8. 🔗 backnotprop/plannotator v0.26.7 release

      Follow @plannotator on X for updates

      What's New in v0.26.7

      One change, and it transforms how annotating HTML pages feels: pinpoint mode now targets any element on the page.

      Pinpoint targets what your cursor is on

      Since v0.26.5, raw-HTML annotate sessions default to pinpoint input. But pinpoint could only target a fixed list of "semantic" HTML tags: headings, paragraphs, tables, sections. Real prototype and report pages are built from styled divs and spans, so hovering a small chip or an icon button selected the whole enclosing section, and some elements could not be selected at all.

      Pinpoint now resolves the element actually painted under your cursor, whatever its tag. Chips, icon buttons, badges, custom cards: all individually annotatable. Elements smaller than 16px promote to their parent so you are not pixel-hunting, and containers are selected the natural way, by pointing at their padding or any spot not covered by a child. The whole interaction stays mouse-only and matches how pinpoint already feels on markdown documents. Hover labels got smarter too: a div with a rowchip class now labels as "rowchip", using its aria-label, role, or class names instead of a bare tag name.

      Under the hood the hover path no longer rebuilds a document-wide element graph every frame; it is a per-event hit-test with zero document scans, which also retires the performance debt noted in the v0.26.5 pinpoint release. Anchor restoration keeps every fail-closed guarantee, and data-testid-style attributes (data-test-id, data-cy, data-qa) now count as trusted element identity for restoring annotations onto regenerated pages. One honest limit: an element with no text and no identifying attribute can be annotated in- session, but its pin does not restore on a later reopen; a pin that cannot verify its target refuses to guess.

      The change went through two adversarial review rounds; the first round removed an anchoring mechanism that could have restored a pin onto the wrong sibling, in favor of failing closed.

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

      OpenCode: Clear cache and restart:

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

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      • feat(annotate): hit-test pinpoint targeting for raw-HTML sessions by @backnotprop in #1251

      Full Changelog : v0.26.6...v0.26.7

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

## New releases
- [ida-codemode](https://github.com/hexrayssa/ida-codemode): 0.4.1, 0.4.0, 0.3.2
    10. 🔗 backnotprop/plannotator v0.26.6 release

      Follow @plannotator on X for updates

      What's New in v0.26.6

      v0.26.6 is a rebuild-only patch: no Plannotator code changed, but every binary is now compiled with Bun 1.3.14 instead of 1.3.11.

      Env vars now work inside OS sandboxes

      Binaries built with Bun 1.3.11 loaded an empty environment whenever a parent of the working directory was unreadable, which is the normal state inside OS- level sandboxes (Seatbelt on macOS, Landlock on Linux, tools like nono). Every PLANNOTATOR_* variable was silently ignored there: remote mode never activated, fixed ports were dropped, and no warning explained why. This was oven-sh/bun#27802, fixed upstream in Bun 1.3.13.

      We had pinned Bun to 1.3.11 in April because 1.3.12 broke macOS binary signing outright. Before unpinning we verified both directions: a 1.3.14 build reads env vars correctly under an unreadable ancestor, and cross-compiled macOS binaries carry the same valid linker signature as the known-good releases and launch cleanly.

      The release pipeline also gained two permanent guardrails: macOS binaries are now smoke-launched after every build (the April signing breakage shipped because only Linux and Windows were), and a new check runs the freshly built binary from a directory with an unreadable ancestor and asserts env vars still load.

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

      OpenCode: Clear cache and restart:

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

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      • fix(ci): bump Bun build pin to 1.3.14 for sandbox env loading by @backnotprop in #1250

      Community

      @SierraJC filed #1249 with a complete diagnosis: the exact upstream Bun issue, the fix version, and a one- line repro that distinguishes "binary cannot see the variable" from "binary mishandles the variable". Reports like this make patches fast.

      Full Changelog : v0.26.5...v0.26.6

    11. 🔗 backnotprop/plannotator v0.26.5 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.26.4 | Skill-menu hover jitter fix (same-day patch on v0.26.3)
      v0.26.3 | Skill references in comments with / or $, reachable remote session URLs, worktree switcher tooltips
      v0.26.2 | Single-file diff tabs render fully, no more silently dropped review files, light/dark theme pairs, palette-matched code blocks
      v0.26.1 | GitButler 0.22.0 compatibility via capability-probed JSON flags
      v0.26.0 | Edit Mode (suggest by editing the diff), Guided Review virtualization, colorblind theme, safe uninstall, installer opt-outs, OpenCode 2 support
      v0.25.1 | Codex no longer launches on review open, annotate-last follows the live conversation, pi-todos mirror, Claude Opus 5, abandoned-gate dismissal
      v0.25.0 | Vim keyboard controls, Approve with Notes, scriptable annotate gates, persistent Guided Reviews, memory and file-watching hardening
      v0.24.2 | Annotate YAML/JSON/TOML config files, XDG data directory support, Codex model catalog update, Cursor sandbox escape hatch
      v0.24.1 | Annotate accepts parent-relative ../ file paths
      v0.24.0 | PR/MR artifact gallery, GitButler review support, port ranges, expanded comment editor, OpenCode + Pi fixes
      v0.23.1 | Startup no longer hangs on large or slow directory trees, Ask AI input stays visible after long responses
      v0.23.0 | Plan approval fix for Claude Code 2.1.199+, annotate mode version diff, binary-only --minimal install, reviews post without attribution

      What's New in v0.26.5

      This release makes annotate feedback durable, rebuilds how you annotate raw HTML pages, and fixes real bugs reported from the field: lost Pi feedback after a reload, a vim cursor hiding behind the HUD, and an installer failure on older git. Seven PRs, two from external contributors, including a first contribution from @Whamp.

      Your annotate feedback can no longer be lost

      When you submitted annotate feedback after the invoking agent had already timed out, the server settled the decision with nobody listening and deleted your draft. The feedback then existed nowhere. Reported by @0okay after exactly this happened on Windows.

      Now the server writes your submitted feedback to a durable record under your data directory before it deletes the draft, so a vanished consumer can no longer take your work with it. If the record cannot be written, the draft is kept as the recovery copy instead. This applies to single local file sessions; URL, folder, and last-message sessions stay fully stateless, and disabling annotate history keeps everything stateless as before.

      Annotating HTML pages: pinpoint-first

      Raw-HTML annotate sessions got a rework. Pinpoint is now the default input: hover highlights the element under your cursor, a click pins it and opens the comment composer directly, and each element annotation gets a numbered badge. Drag selection is still one toggle away, and your choice is remembered separately from markdown sessions.

      Pages also open minimal: the first session hides the toolstrip, tab flags, and sidebar so you see just the page, and every session after that opens with exactly the chrome you last left visible.

      Under the hood, element annotations now carry a verified CSS anchor so they restore to the same element when you re-open a page, even after the page was regenerated. Restoration is deliberately fail-closed: when the anchor cannot be trusted, the annotation falls back to text search, and text that moved elsewhere in the page is followed rather than mis-pinned. The feature shipped through two adversarial review rounds plus a 25-item QA sweep, which hardened anchor verification, capped selection sizes, kept pin badges out of printed pages, and bounded anchor building so a click on deeply nested markup can never freeze the tab.

      Pi: feedback delivers after a reload

      A Plannotator browser tab can outlive a Pi /reload. When feedback arrived from such a tab, the extension rejected the freshly reloaded runtime as the same stale session (reload preserves Pi's session id) and the feedback was dropped with an error. @Whamp diagnosed the root cause and fixed it: the extension now tracks an in-process runtime token, so a reload counts as a new active runtime and both feedback and notifications route to it. Comes with a regression test simulating the exact reload scenario.

      Vim: the cursor stays out from under the HUD

      Document vim navigation used to pin the cursor target flush against the viewport edge, exactly where the sticky action bar and the key HUD float, so j/k motion at the top or bottom of a document hid the caret behind an overlay. @rNoz reported it and fixed it: cursor movement now reveals its target with a scrolloff-style margin sized to the viewport, so keyboard motion keeps the caret visible the way mouse scrolling always did.

      The installer works on older git

      install.sh failed its skills step with a misleading "network or git error" on systems whose git predates 2.25 (for example a stale Xcode Command Line Tools git), because git clone --sparse does not exist there. Reported by @dubbl-a. All three installers now probe for the capability and fall back to a plain shallow clone, surfacing the real git error when something else goes wrong. A follow-up in this release also pins the probe to a stable locale, so localized git builds take the fallback correctly too.

      Additional Changes

      • Windows Codex wording corrected. The README claimed Codex hooks are disabled on native Windows while the installer called them experimental and printed setup steps. The docs now agree: experimental, with manual steps (#1241 reported by @dustintran333)
      • Print stays clean. Printing an annotated HTML page no longer bakes pin badges or pinpoint overlays into the output; inline annotation marks remain printable on purpose (#1245)
      • CI now runs every DOM suite. Eight DOM-gated test files were silently skipping in CI, including the vim and HTML-annotate suites; they are wired in and enforced on every run

      Install / Update

      macOS / Linux:

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

      Windows:

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

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

      OpenCode: Clear cache and restart:

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

      Then in opencode.json:

      {
  "plugin": ["@plannotator/opencode@latest"]
}

      Pi: Install or update the extension:

      pi install npm:@plannotator/pi-extension

      What's Changed

      • Fix feedback delivery after Pi reload by @Whamp in #1240
      • fix(install): fall back to a plain shallow clone when git lacks --sparse by @backnotprop in #1239
      • fix(annotate): persist submitted feedback before deleting the draft by @backnotprop in #1237
      • fix(vim): keep the j/k cursor clear of the HUD bands when scrolling by @rNoz in #1154
      • feat(annotate): pinpoint-first raw-HTML sessions with element anchors and a minimal-first render by @backnotprop in #1243
      • chore: fold in pre-release QA findings by @backnotprop in #1245
      • fix: address the three pre-release sweep findings by @backnotprop in #1246

      New Contributors

      Community

      @Whamp hit the Pi reload bug in daily use, traced it to session identity surviving the reload, and shipped the fix with a regression test. First contribution, and a precise one.

      @rNoz continues to make vim mode better than we left it: he filed the HUD occlusion report (#1153) with a demo video and fixed it himself, including a pure scroll-math helper with its own test suite.

      Issue reporters this release:

      • @0okay reported the lost-feedback failure (#678) that drove the durable-submission work
      • @dubbl-a reported the old-git installer failure (#1238) with the exact git version and error output that made the fix straightforward
      • @dustintran333 caught the README contradicting the installer on Windows Codex hooks (#1241)

      Full Changelog : v0.26.4...v0.26.5

    12. 🔗 Filip Filmar rules_vivado: FPGA Synthesis and Place-and-Route in Bazel rss

      rules_vivado drives the AMD/Xilinx Vivado FPGA toolchain from Bazel: VHDL and Verilog compile, elaborate, simulate, synthesize, place-and-route, generate a bitstream, and program the device, all as hermetic Bazel build actions rather than clicks in a GUI or a pile of ad-hoc TCL. This is the module that turns the Cocoapuffs board flow into bazel build. This post kicks off a short series. Over the Cocoapuffs project and its parent repo a200t_examples I ended up writing a fair number of Bazel modules to make an FPGA-based RISC-V system reproducible from source.

    13. 🔗 Ampcode News A Dial for You rss

      We changed the Dial. Link a ChatGPT subscription and low, medium, and high only use OpenAI models: as the main agent, as the oracle, as the thread reader, as code review. Every model behind those modes is an OpenAI model, billed to your subscription.

      Before this change, you'd still pay for tokens with a subscription linked, because parts of the work ran on other models: low and the thread reader on GLM-5.2, the high oracle on Claude Fable, code review on Haiku — all billed to Amp credits. That confused people, and we get why.

      With a subscription connected:

      • low runs GPT-5.6 Terra instead of GLM-5.2.
      • medium runs GPT-5.6 Sol, as before.
      • high runs GPT-5.6 Sol as both agent and oracle. The oracle used to be Fable.
      • The thread reader and code review move to GPT-5.6 Terra.

      The mode picker with the dial on medium, showing GPT-5.6 Sol as agent and oracle and a green ChatGPT subscription LED

      Doesn't this make the modes worse? Barely, and less every month. The frontier models have converged: any of them gets you to a good result with a good harness. We swapped the default model for most users overnight and nobody complained. So the modes stay at the frontier, and the tokens come out of a subscription you already pay for.

      high also drops its credit minimum when your subscription is active. There's no Fable call left to pay for.

      ultra doesn't change. It runs Claude Fable on credits, because ultra is for the tasks where you want the strongest model, whatever it costs.

      If you don't have a subscription, nothing changes. The modes run as before, on Amp credits.

      Link your subscription and turn the dial.

    14. 🔗 Baby Steps Cylic trait implementations: motivation rss

      Lately I've been thinking about cyclic trait implementations. This is a problem that I've been trying to understand for years and years and I finally feel like I'm geting somewhere. I'm going to try to write out a series of blog posts documenting those explorations and, hopefully, culminating in a design that could be RFC'd. In this first post, I want to talk about one of the interesting questions, what I am going to call "internal" vs "external" proofs. I know that this material can seem abstract, so I'm going to try and connect it to "real Rust" as much as possible! This particular blog post is an introduction, explaining the general problem and giving some motivation for why we care.

      What are cyclic trait implementations?

      Right now in Rust we require most traits to have non-cyclic , or inductive , implementations. To explain what I mean, let's consider this trait:

      trait Dump {
    fn dump(&self);
}

      Now imagine that we have an impl of this for i32:

      // Impl I
impl Dump for i32 {
    fn dump(&self) {
        println!("{self}");
    }
}

      A simple impl for Rc<T> and `Option:

      // Impl RC
impl<T> Dump for Rc<T>
where
    T: Dump,
{
    fn dump(&self) {
        T::dump(self)
    }
}

// Impl Opt
impl<T> Dump for Option<T>
where
    T: Dump,
{
    fn dump(&self) {
        if let Some(v) = self {
            T::dump(v)
        }
    }
}

      and finally a recursive List type that has an impl as well:

      struct List<T> {
    value: Rc<T>,
    next: Option<Rc<List<T>>>,
}

// Impl L
impl<T> Dump for List<T>
where
    T: Dump,
{
    fn dump(&self) {
        Dump::dump(&self.value);
       if let Some(n) = &self.next {
            Dump::dump(n);
        }
    }
}

      If I try to show that List<i32>: Dump, I do that by

      • Applying "impl L" to show that List<i32>: Dump if i32: Dump
        • Then applying "impl I" to show that i32: Dump

      There's no cycle here - that is, I didn't have to use impl L to show that impl L is valid.

      Cyclic logic sounds bad, but it can be exactly what you want

      Now, when I said that "the impl L didn't have to use the impl L to show that it is valid" that might not have sounded suspicious to you. In fact, it's a pretty natural idea. After all, generally when you try to establish a logical argument, you aren't allowed to use cyclic reasoning. That is, you can't say: I know that Niko likes Rust because Niko likes Rust. So, in the same sense, it seems natural that I should not be able to say "I know that List<i32> implements Dump because List<i32> implements Dump".

      But actually, it would sometimes be really useful to say exactly that. One example is so-called "perfect derive". In our Dump impl above, we had one where-clause, T: Dump. And if you were to create a custom derive for Dump and write #[derive(Dump)], the impl I showed is typically exactly what you would get. But it's not necessarily what you want. Consider what you get with #[derive(Clone)]:

      // Impl LC1
impl<T> Clone for List<T>
where
    T: Clone, // <-- generated but not really required!
{
    fn dump(&self) {
        List {
            value: Clone::clone(&self.value),
            next: Clone::clone(&self.next),
        }
    }
}

      Here, the derive is going to create an impl that requires T: Clone. But if you look closely, you'll see that all the fields only use Rc<T>, so in fact, we should be able to clone a List even without T: Clone! But how is the compiler to know this?

      You might think that the compiler could do some super smarty-pants analysis on the fields to figure it out. And, in a way, it can: that is what cyclic trait solving is all about. The thing is, while the compiler can do that, the derive cannot - the derive doesn't have access to the definitions of other types and so forth, and clearly we would need to know things about Option and Rc to figure out whether T: Clone is required here.

      But what we could do is to generate a different impl. Instead of adding T: Clone for each type parameter, we could add a where-clause for each field type. This makes sense: after all, we are just going to be calling Clone on every field, so it's quite logical to say that the impl is valid if every field is cloneable:

      // Impl LC2
impl<T> Clone for List<T>
where
    Rc<T>: Clone,
    Option<Rc<List<T>>>: Clone,
{
    // .. as above ..
}

      Under this formulation, we can see that all we have to be able to do is to clone an Rc<_> and clone an Option<Rc<_>>, neither of which require that T: Clone.

      This idea is called perfect derive

      We call this idea [perfect derive][] and it's been a goal for a while. The thing is, cyclic reasoning is tricky to get right. The Clone example is actually an easy one: that one doesn't really require cyclic reasoning:

      • To show that List<i32>: Clone we have to show that…
        • Rc<i32>: Clone, which is easy because impl<T> Clone for Rc<T> doesn't have any where-clauses1
        • Option<Rc<List<i32>>>: Clone uses the impl<T> Clone for Option<T> where T: Clone impl which requires…
        • Rc<List<i32>>: Clone, which is again easy

      But it's not so easy for Dump

      But if we use that same "cyclic derive pattern" to generate our Dump impl, things don't work out so well. Instead of just a T: Dump bound, our Dump impl now has two bounds:

      // impl L1
impl<T> Dump for List<T>
where
    Rc<T>: Dump, // <-- Used to be `T: Dump`
    Option<Rc<List<T>>>, // <-- This one is new!
{
    fn dump(&self) {...}
}

      Now imagine we try to show List<i32>: Dump. We begin by applying impl L1, which requires us to show that its where clauses hold:

      • To show List<i32>: Dump we use impl L1, which has two where-clauses:
        • Rc<i32>: Dump, this one is easy because the Rc impl requires that i32: Dump which is true.
        • But Option<Rc<List<i32>>>: Dump is tricky. The Option impl requires that…
        • We need to prove Rc<List<i32>>: Dump, and then the Rc impl requires that…
          • We need to prove List<i32>: Dump, but that is what we started with! That's cyclic logic!

      Ugh. Something's tricky here!

      We can't just accept any old cycle because of supertraits

      Now, maybe you think we can just accept any cycles. And for these examples, it would be fine: but it's not correct if you consider supertraits. Consider this trait and impl pair:

      trait Magic: Copy { }

// Impl M
impl<T> Magic for T
where
    T: Magic,
{}

      If you are naive, this weird trait-impl pair can be used to prove that any type is Copy, regardless of whether it has a Copy impl. For example:

      • Say we want to prove that String: Copy. We observe that if a type implements Magic, it must implement Copy, so…
        • We begin by proving String: Magic. We use the impl M, which requires
        • that we show String: Magic, which is a cycle, so we accept it.

      Uh oh, now we did something wrong. We proved that String: Copy even though there is no Copy impl. Something is fishy.

      Now clearly we can all see the problem here - the implementation of Magic didn't really add any information. It was just a tautology, saying that T: Magic if T: Magic. It's not wrong , but implementing Magic was supposed to tell us more than just the fact that there is an impl of Magic, it was supposed to tell us also that the supertrait Copy is implemented. And that's not true here.

      But if you think about it, it's hard to decide why we should reject impl M but accept the impl L1 of Dump for List<T>. They both wind up with a cyclic proof. So what's the difference? This is the question we'll be exploring over the next few blog posts.

      Soundness for traits

      This gets at an interesting question: what does it mean for the trait system to be sound. This seems obvious but actually it was a question I found kind of non-obvious for a long time.

      We've found two satisfactory answers to that question. One of them involves converting to dictionary-passing style. Nadri explained that in a blog post. I think that's a great post to read. I'm going to give another definition here that doesn't require converting to a dependently typed program2

      My rough definition is this3: the trait system is sound if, whenever it accepts some program P, that program cannot have a function that believes some Trait holds for the T, but there is no impl of Trait that can be used. So in the case of Magic and Copy, it's easy to write a program that shows simple cyclic trait solving is unsound:

      trait Magic: Copy {}

impl<T: Magic> Magic for T {}

fn is_copy<T: Copy>() {
    // this function believes `T: Copy`
}

fn main() {
    // this can be called because we believe that
    // * `String: Magic` because
    //     * `String: Magic`, and we accept cycles.
    // And then `String: Magic` implies `String: Copy`.
    is_copy::<String>();
}

      By my definition, any sound type/trait system must reject this program because, if it were to execute, then execution would reach is_copy::<String> and yet there is noCopy impl that is judged to ber applicable to String. Uh oh!

      Coming next

      As I promised, this post was mostly focused on "setting the scene". My goal was to explain what the problem is that we are trying to solve - permitting "good cyclic impls" but forbidding bad ones. I didn't spend a lot of time on the bad ones, but it turns out that there's a wide variety of unsound things one can do, some of which the compiler currently gets wrong, others of which it would only get wrong if we started permitting cycles.

      My motivation for getting into this work is a bit complicated. I want perfect derive. But it's also a loose end in our trait semantics that I really want to see nailed down before we move onto other tasks. Having auto traits (e.g., Send) work differently from other traits is clearly a "smell", and without a strong understanding of the logical underpinnings of our trait system it's easy to get things wrong when we build extensions.

      In the next few posts I'll go a bit deeper into the exploration I and others have been doing. I'll talk about some of the "false starts" we took along the way and why they don't work, and then about some of the solutions that are under consideration. Working through this stuff has really helped me to broaden my understanding of various areas of logic. By the time we're done, we'll cover4 coinduction and productivity, modal logic and the later modality, and we'll see how our techniques might even help us with resolving specialization5.

      I cited it earlier, but if you want to read other tasks on the same subject, I definitely recommend Nadri's post on dictionary-passing style.

      1. Apart from the default Sized bound, I'm ignoring that here ↩︎

      2. I have found that both the dictionary-passing interpretation and the logic approach I'm using are valuable. In the end, they're more or less equivalent, which I guess shouldn't be surprising if you've heard of the Curry Howard Correspondence, but I'll talk about that later perhaps. ↩︎

      3. I would like to, but haven't, define a simplified version of Rust that includes trait solving and simple type checkoing and show that it cannot "go wrong". ↩︎

      4. In a shallow way, I'm no expert! ↩︎

      5. Plot twist, bet you didn't see that coming! I sure didn't. ↩︎

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

      IDA Plugin Updates on 2026-08-09

      New Releases:

      Activity:

    2. 🔗 r/LocalLLaMA The Gemma team will host a special event on August 20 rss

      Tweet by u/hackerllama

      Could be copium, but I would love to see Gemma 4.1 there with unified audio input for all model sizes perhaps even up to 120B, much improved tool calling (even with the latest template there are still bugs), higher precision QAT from the start and improved general performance without hurting the things Gemma 4 is good at like creative writing.

      Gemma 4 is good already but training an upgrade to 4.1 that does all of the above would be huge for the community. They already did a lot of course and I'm very thankful but Gemma is just an inch away from perfection. Is anyone hyped for this event or do you think they won't release any new models there?

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

    3. 🔗 pydantic/monty v0.0.21 - 2026-08-09 release

      What's Changed

      Full Changelog : v0.0.20...v0.0.21

    4. 🔗 pydantic/monty v0.0.20 - 2026-08-09 release

      What's Changed

      Full Changelog : v0.0.19...v0.0.20

    5. 🔗 Confessions of a Code Addict x86 Addressing Modes, Part 2: Indirect, Indexed, and Offset-based Modes rss

      Welcome back to our series on x86 assembly programming. If you are new, you can check out the series overview.

      In the previous part of this article, we covered some of the basics of x86 addressing modes, such as immediate addressing and direct memory addressing. This 2nd part continues where we left and completes the coverage of all the x86 addressing modes, along with all the caveats that you need to be aware of. Along the way, you will also implement some very interesting examples and exercises, such as parsing the command line arguments on the stack, implementing the magic 8-ball game, and implementing a lookup table in assembly.

      Here's what we will learn:

      • Indirect memory addressing: this is how pointers work in C

      • Offset-based addressing: this is how we access fields inside a struct

      • Indexed addressing: this is how we access elements of an array

      • The generalised addressing mode syntax in x86 assembly: all the other addressing modes are simplifications of this generalised syntax

      Let's start with indirect memory addressing.

      I 'm also publishing this series on x86 assembly in the form an ebook (PDF). If you don't wish to upgrade to a subscription, you can purchase the PDF using the following link. If you are a paid subscriber, you can get it at a discount (monthly subs: 20% and annual subs: 50%). Please email me for the discounted link.

      Get Ebook

      Indirect Memory Addressing

      In the previous article, we learned about direct memory addressing, which is only useful when you know the exact memory address that you can encode in the instruction. This is mostly possible for static data of your program because their addresses are known at assembly and linking time. However, most real- world programs work with dynamically allocated memory where the actual memory address is known only at runtime, so direct memory addressing is not viable for such cases. We need indirect memory addressing.

      In indirect memory addressing, the memory address is stored in a register. In this mode, the processor needs to first read the address from the register, do the memory access, and then execute the instruction.

      For example, when we allocate dynamic memory on the heap using malloc or mmap, it returns the address of the allocated memory. The returned address is kept in a register like RAX. Now, if we want to read or write this memory, we need to tell the processor to treat the value in RAX as an address, perform a memory access at that address, and execute the actual instruction.

      This is different from direct memory addressing because there the address was part of the instruction, so the processor did not need to get the address from anywhere. In contrast, here the processor first needs to read the address from the register, and then access memory. You can also think of indirect memory addressing as adding one layer of indirection to memory access.

      While dynamic memory allocation in C is easy, in assembly it is very involved, so we will learn to do that in a future article. Instead, to learn how to use indirect memory addressing, we will copy the address of a value stored in the .data section into a register.

      So, how do we copy the address of a label into a register? We know that when we write:

      # move the value at the label ANSWER_TO_LIFE into rax
movq ANSWER_TO_LIFE, %rax

      The instruction tells the processor to copy the value stored at the address ANSWER_TO_LIFE into rax. However, when we want to copy the address itself into a register, we need to use the $ prefix that turns the instruction into immediate addressing mode:

      # move the address of the label into rax
movq $ANSWER_TO_LIFE, %rax

      After this, the register rax contains the memory address where the value 42 is stored. The following diagram visualizes this

      RAX contains address of a value stored in the .data sectionRAX contains address of a value stored in the .data section

      The diagram shows that after executing that mov instruction, the register rax contains the memory address of the value in the .data section.

      Once we have an address in a register, whenever we want to dereference that address, we need to use indirect addressing mode syntax. The following snippet shows how to copy a value by dereferencing the address in rax.

      # indirect addressing mode
movq (%rax), %rdi # dereference address in rax and copy the value from memory into rdi

      The syntax is a bit different from what we have seen so far. When we write "movq %rax, %rdi", we tell the processor to copy the value stored in rax into rdi. But when we surround one of the registers with parentheses, the assembler generates a different encoding of the instruction that tells the processor that the register contains an address, and it needs to get the value from that address.

      We can see the difference in the encoding using objdump just like we did for direct memory addressing. The following objdump output shows the difference in the encoding for the instructions movq %rax, %rdi and movq (%rax), %rdi.

      0000000000401000 <_start>:
401000:  48  89  c7  mov  %rax,%rdi
401003:  48  8b  38  mov (%rax),%rdi

      You can see that at the machine code level, these two result in two very different encodings.

      Base Address and Base Register

      Before continuing further, let's introduce two important terms that we should understand in the context of assembly programming.

      Base Address

      When working with memory addresses, what we have is the starting address of a value in memory; this is also called the base address of the value.

      For example, an 8-byte value 42 may be stored at the address 0x0010. Because its size is 8 bytes, it spans from the address 0x0010 up to 0x0018. So, 0x0010 is the base address.

      Knowing the base address helps us compute addresses for more complex data types, such as arrays and structs. For example, if we have a struct with three int type fields, and we want to access its 3rd field, we would calculate the address as base address + 8.

      Base Register

      When a register contains a base address for a value in memory, we refer to it as the base register. In the above example, rax is a base register.

      Hands-on Example of Indirect Addressing Mode

      Now, let's put all of this together and write a simple program that reads an integer value from memory, multiplies it by 2, and exits with the result of the multiplication as its status code.

      .data # create the .data section
# create a 64-bit integer value
ANSWER_TO_LIFE: .quad 42

.text
.globl _start
_start:
# copy the address to rax
movq $ANSWER_TO_LIFE, %rax # rax becomes the base register
# copy the value from memory address in rax into rdi
movq (%rax), %rdi
imulq $2, %rdi # multiply value in rdi by 2
movq $60, %rax # put exit syscall no in rax
syscall # execute exit syscall

      You can assemble, link, and run it. I also encourage you to step through this in gdb to see that rax contains an address value after the first mov instruction.

      Indirect Addressing and Pointers in C

      When we use pointers in C, the compiler generates assembly code that uses indirect memory addressing to make it work. The C pointer syntax is just a syntactic sugar to hide this detail.

      For example, if you call malloc or mmap to allocate memory in your C program, they return the address of the allocated memory. This return value is stored in the rax register as per the x86-64 calling convention. And, later when we dereference that memory using the * operator, the compiler generates assembly instructions which use indirect memory access. The following diagram shows this, but you can also test it out yourself using Compiler Explorer.

      Exercise: Traverse a Linked List

      This x86 assembly series is available to paid subscribers. If you'd like to continue reading the rest of this article and access the full series, you can upgrade your subscription.

      Alternatively, you can purchase the x86 assembly book using the link below.

      Get PDF

      Read more

    6. 🔗 Anton Zhiyanov Relying on Go rss

      Everyone is creating a new programming language these days, often one that's "like Go but with more features" or "like Rust but simpler".

      Solod, a systems language for C and Go developers, might look like one of those languages, but it takes a different approach.

      Go's tooling Solod is not "Go-like" in the usual sense, nor is it an attempt to "fix Go's mistakes". At the language level, Solod is literally a subset of Go. Solod reuses much of Go's existing tooling, including syntax highlighting, LSP, linters, and the package management system. Take this quick-start guide, for example: Quick start Install the So command line tool: go install solod.dev/cmd/so@latest Create a new Go project and add the Solod dependency to use the So standard library: go mod init example go get solod.dev@latest Write regular Go code, but use Solod packages instead of the standard Go packages: package main import "solod.dev/so/math" func main() { ans := math.Sqrt(1764) println("Hello, world! The answer is", int(ans)) } Run without saving the binary: so run . That's it! There's nothing new here. It's mostly standard Go workflow, except for so run, which is a Go program that mimics go run. Go's standard library Solod also reuses a lot of Go's standard library code and tests. Some of it is taken verbatim from Go's source code, like these two string functions: // CutPrefix returns s without the provided leading prefix string // and reports whether it found the prefix. func CutPrefix(s, prefix string) (string, bool) { if !HasPrefix(s, prefix) { return s, false } return s[len(prefix):], true } // HasPrefix reports whether the string s begins with prefix. func HasPrefix(s, prefix string) bool { return len(s) >= len(prefix) && s[:len(prefix)] == prefix } Of course, Solod retains the Go authors' copyright. Some code requires changes to support the manual memory management with explicit allocators used by Solod: // Go version. func Clone(s string) string { if len(s) == 0 { return "" } b := make([]byte, len(s)) copy(b, s) return unsafe.String(&b[0], len(b)) } // Solod version. func Clone(a mem.Allocator, s string) string { if len(s) == 0 { return "" } b := mem.AllocSlice, len(s)) copy(b, s) return string(b) } You can probably see the resemblance. A grain of salt

      Go tools don't know that Solod is a subset of the full Go language, so they won't flag features Solod doesn't support, like function literals or iterators. These diagnostics come from the custom so tooling:

      package main

func main() {
    f := func(n int) {
        println(n)
    }
    f(42)
}



main.go:4:7: function literals are not supported
    f := func(n int) {
         ^here

      Also, although a substantial part of Go's standard library is ported verbatim or with minimal changes from the original source, that doesn't mean the code is automatically correct. Solod still needs its own tests, including ones that run under sanitizers and static analyzers.

      It's all C in the end

      All Solod code is translated to regular C11 and then compiled with GCC or Clang. Solod therefore relies on C tooling and decades of optimization work just as much as on Go's.

      Solod code:

      package main

import "solod.dev/so/math"

func main() {
    // What might it be?
    ans := math.Sqrt(1764)
    println("Hello, world! The answer is", int(ans))
}

      Translated C code:

      // -- main.h --
#pragma once
#include "so/builtin/builtin.h"
#include "so/math/math.h"

// -- main.c --
#include "main.h"

int main(void) {
    // What might it be?
    double ans = math_Sqrt(1764.0);
    so_println("%s %" PRIdINT, "Hello, world! The answer is", (so_int)(ans));
    return 0;
}

      The C version is noisier, of course, especially for more complex programs than this one. But it remains readable.

      And since there's no runtime, interoperability between Solod and C costs nothing.

      Final thoughts

      A new language doesn't necessarily need a new ecosystem.

      Solod relies heavily on Go, and I see that as a strength, not a weakness. Reusing Go's proven tools and standard library makes Solod more reliable and easier to work with.

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

    7. 🔗 r/LocalLLaMA RTX 5090 96GB spotted on Alibaba? rss

      RTX 5090 96GB spotted on Alibaba? | submitted by /u/panchovix
      [link] [comments]
      ---|---

    8. 🔗 r/LocalLLaMA No wonder Qwen and Gemma are so different rss

      Pasted the same HTML/JS code (330 lines) into Qwen 35B A3B and Gemma 26B A4B.

      Qwen: tokenized the input to 1609 tokens

      Gemma: tokenized the input to 4258 tokens.

      Damn. I've never noticed this before and I haven't seen people mention it. That alone helps explain why Qwen is regarded as better at coding and Gemma at language tasks.

      Qwen can literally see the code as some specific form of input/output, while Gemma is breaking it down into pieces of words like regular language. Qwen also gets a totally different reasoning personality when given coding tasks.

      Btw with the instruction document (55 lines), the tokenization breakdown is almost the same: 1025 vs. 1039 tokens.

      I've seen some project, by LiquidAI I think? To retrain existing models with a more efficient tokenizer. I wonder what that would do for a model like Gemma, whether it would help it catch up.

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

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

      IDA Plugin Updates on 2026-08-08

      Activity:

      • augur
        • ee0048c4: Merge pull request #4 from 0xdea/dependabot/github_actions/actions-de…
      • haruspex
        • db0563c7: Merge pull request #7 from 0xdea/dependabot/github_actions/actions-de…
    2. 🔗 Register Spill Joy & Curiosity #94 rss

      What a lovely week it's been! Nearly the whole Amp team met up in Munich. We all stayed in the same hotel and in the mornings floated down to a big meeting room in which we then hacked, asked each other questions that are so easy to ask in person, actually used a whiteboard, talked about the future of software, shared anecdotes about agents, and just generally enjoyed each other's company. The evenings we then spent nearly exclusively in beer gardens, which were, I'd say, a perfect showcase of Munich in summer.

      In between all of this, we recorded a lot of videos, and as part of that I spent roughly eight hours on the rooftop of the hotel, interviewing my colleagues, asking them how their workflow had changed in the last four weeks.

      The big non-surprise: orbs changed everyone's workflow; no one cares about the local dev environment anymore. We all had to wipe our laptops three weeks ago, and at least five people told me that they had forgotten to port their dotfiles over, simply because they only work in orbs now.

      The actual big surprise that I guess shouldn't be a surprise: everyone, without exception, was so eloquent, so thoughtful, so nuanced, and so full of curiosity when talking about agents and how we work at Amp. "Wait, you're surprised that your colleagues are smart?" Nah, man, I'm saying that they exceeded all expectations! Show me another size-twenty team in which everyone you ask does a great job in front of a camera while being asked how their workflow has changed in the last three weeks and how their own expertise is now reflected in these things we call orbs.

      Good stuff.

      • I wrote about the biggest puzzle I have to solve right now: What I Want to Tell You About Orbs. Someone called it a "a strangely beautifully written ad" and wondered: "maybe i should get orbing." I honestly take it as a compliment.

      • Fired up by all the conversations in Munich, I started to record very raw videos to share my thoughts on AI and agents, orbs, and… jellyware: one, two, three, four. Total watchtime around fifteen minutes. More coming, because this is a lot of fun.

      • Those videos were recorded with a Osmo Pocket 4, which, so far, seems excellent. Really impressed by the built-in mic and how well it worked even on a windy roof top with music in the background. I bet if I hadn't clicked that "Normalize audio levels" button in Riverside it might sound even better.

      • Speaking of sick devices: I brought along my Anker Powerbank, which is, to quote my wife, my "most prized possession." I love that thing and I let everyone in hearing distance know. Result: at least two colleagues ordered it right away and then echoed my praise when it arrived a day later. Go get it and then lead your pitch to others with "you think this is a handle? Nuh-uh, it's a built-in cable. One built-in cable you say? Nope, here's another one. With how much watt it can charge? Just look here, shows all inputs and outputs on this display." (Anker: if you want to sponsor this newsletter by sending me cables and devices I probably don 't need, I will shamelessly write a paragraph like this every week.)

      • "Sometimes people let the same problem make them miserable for years when they could just say, 'So what.' 'My mother didn't love me.' So what. 'My husband won't ball me.' So what. 'I'm a success but I'm still alone.' So what. I don't know how I made it through all the years before I learned how to do that trick. It took a long time for me to learn it, but once you do, you never forget."

      • Dwarkes Patel with some fascinating thoughts on the future prices of compute: Why compute might get 10x+ more expensive in coming years.

      • David Crawshaw is also talking about Jellyware: "And that is the fundamental difference between classic configuration/customization and agent-driven personalization: you can do so much more. The agent will do the hard work of understanding the source and changing it to suit the particular task you have in mind. The software we live with is far more powerful with personalization. All you need is the source code." Nodded so hard to this article that I can still feel it in my neck. But I don't understand why the agent has to be open-source, to be honest. I think the thing we called harness for the last year is becoming less and less important. Higher-level abstractions, such as orbs and portals and redacted is what we need to focus on next.)

      • I've read somewhere that people think Rockstar is not doing enough marketing for GTA VI. I guess I could kinda see what they mean, but then again: why do marketing if you don't need it? And now look at this: they're releasing "GTA VI - An Extended Look" on freaking Netflix.

      • Negative-interest tech debt: "That is, with sufficient AI progress, the interest on your tech debt is sub-zero. How should you behave if you believe that to be true? You should probably spend less time worrying about tech debt, and spend more time shipping new features. Many companies are doing just that. But it's a gamble. We don't know how much better AI will get, nor whether it can improve fast enough to undo the mess that was made in anticipiation of its improvement."

      • "BREAKING: Bending Spoons acquires Airtable for $1.825B." And here's Matt Levine, a couple of weeks ago, on Bending Spoons: "Similarly, if you graduate from a top computer science program and then go work at AOL, people will be like 'AOL huh,' but Bending Spoons is cool enough to get top employees to go work for AOL: […] Right, if you can get people who would never dream of working at companies to work at those companies, that might improve those companies."

      • But apparently Airtable "spun out their AI business Hyperagent prior to the acquisition."

      • And if Airtable makes you think of Notion: "Notion did a $270M tender at $11B valuation at the end of 2025 on reported $600M ARR and cash flow positive." Still, I wonder how many count Notion among the companies that are the future.

      • I love this Hacker News comment from 2020 on sales: "Sales is a lot like golf. You can make it so complicated as to be impossible or you can simply walk up and hit the ball. I've been leading and building sales orgs for almost 20 years and my advice is to walk up and hit the ball." Read the whole thing.

      • Steve Ruiz convinced everyone to buy little ESP32 devices and then ask agents to program them. Look at this, for example. I also got one and had a ton of fun with it already. It truly is as easy as hooking it up to your computer and telling Amp "I got this device [screenshot of Amazon page] hooked up. Build an orb breakout game for it." It then goes and installs a bunch of stuff and flashes the program onto the device and boom, orbin' time. I've had it build a little program that shows my active Amp Orbs as orbs on the display and, dude: once the program ran it showed setup instructions which told me to connect to its wifi; I did that and got that guest portal popup; on that popup it told me to put in the real wifi name and my Amp API token; I did and boom, orbin' time.

      • The myth of Snow Leopard: "This idea is so powerful--and so longed for--that it's escaped containment among the Apple crowd. I've seen everything from Linux distro to phone updates referred to as Snow Leopard releases, when their vendors cite stability and bug fixes over new features. Likewise, people plead with their vendors for a Snow Leopard release when they feel quality has slipped. The reality was a bit different"

      • Ursula K. Le Guin - A Rant About "Technology": "This is not an acceptable use of the word. 'Technology' and 'hi tech' are not synonymous, and a technology that isn't 'hi,' isn't necessarily 'low' in any meaningful sense. We have been so desensitized by a hundred and fifty years of ceaselessly expanding technical prowess that we think nothing less complex and showy than a computer or a jet bomber deserves to be called 'technology' at all. As if linen were the same thing as flax -- as if paper, ink, wheels, knives, clocks, chairs, aspirin pills, were natural objects, born with us like our teeth and fingers -- as if steel saucepans with copper bottoms and fleece vests spun from recycled glass grew on trees, and we just picked them when they were ripe..."

      • I found this incredibly fascinating: Elite Young Runners Are Becoming Freakishly Fast. Welcome to 'Trackflation'.

      • Always-on-the-money Sean Goedecke: "The usefulness of domain knowledge suggests that human expertise will continue to be useful even as models get stronger. For many tasks, the human is the bottleneck, not the model, because the difficult part is in communicating to the model exactly what kind of solution the human wants. The information is 'in the model' already, but it takes a very smart human to pull it out." Agree.

      • Dark indeed, but also beautiful and poetic: The Dark Night of Mathematics. Reminds me of reading Doktor Faustus.

      • This has been a wild week for Google: Demis Hassabis stepping down as DeepMind CEO (some say he's stepping up?) and Jeff Dean, Sanjay Ghemawat, Quoc Le, and Oriol Vinyals are leaving Google. That's right. Jeff Dean and Sanjay Ghemawat are leaving Google. If you haven't, read The Friendship That Made Google Huge. And then take a look at their pitch deck which can be neatly summarized as "We built half the Internet."

      • Some say that Demis Hassabis wanted to quit but since Jeff Dean was already quitting that would've been too much.

      • And Semi Analysis is going to town on Google: "For all intents and purposes, we believe DeepMind is no longer a frontier lab. […] We believe Gemini's core issue has always been a fundamental lack of conviction. Compute is the lifeblood of AI progress, and all the AGI-pilled labs are desperately trying to acquire as much as possible. […] Google, on the other hand, decided it was totally worth it to sell enormous amounts of compute to Gemini's fiercest competitors on long term contracts without any hope of ever returning it to DeepMind." But, as the title points out ("Gemini is Cooked but GCP is Cooking"), GCP's numbers are absolutely bananas. Y/Y Revenue Growth went up to 120%. Wild.

      • More German than many Germans: "I just wanted to do an internship in Europe so it would be easier to find a job after graduation. That internship completely changed my life."

      • I haven't watched the full talk yet, but I hear it's mind-blowing and the reports confirm that: "OpenAI gave its first detailed public reconstruction of the AI-driven cybersecurity incident that ultimately compromised Hugging Face." It's wild: multiple agents collaborating over months and different training runs, communicating via a message board which was deleted but then re-created by agents; agents finding and sharing exploits with other agents to escape sandboxes, talking in a very weird dialect. I'm not even going to attempt to explain this to my "normie" friends. As long as there's no video recording of agents doing "computer use" and moving the mouse cursor and clicking around, I don't think the mainstream will believe what agents are capable of. Patrick McKenzie on this incident: "Yeah people claiming this is most important security incident since Morris worm are straightforwardly right I think."

      Been in Munich too and think that beer gardens are pretty sweet? You should very likely subscribe:

    3. 🔗 modem-dev/hunk v0.18.0 release

      What's Changed

      Highlights

      Hunk 0.18.0 makes reviews more precise, customizable, and extensible—while improving performance and reliability across large repositories and diverse terminals.

      • A full extension platform. Install TypeScript extensions that add VCS backends, commands, sidebars, dialogs, interactive file views, themes, and workspace actions.
      • Line-level review and commenting. A visible cursor moves with j/k, and c comments exactly where you are looking.
      • Richer agent context. Experimental STML notes provide structured, terminal-native explanations with preview and layout tools.
      • Full reviews from pipelines. Piped diffs retain navigation, filtering, layouts, sidebars, and other review controls.
      • A UI that follows your preferences. Remapped shortcuts appear correctly, view settings can be saved, and tabs and syntax colors are configurable.
      • Faster and more dependable reviews. Watch mode uses less CPU, navigation retains less memory, wrapped Unicode is faster, and CJK and emoji filenames render correctly.

      All 83 merged pull requests

      • docs: update Homebrew release guidance by @benvinegar in #515
      • fix(config): read Windows user-profile config by @benvinegar in #533
      • feat: STML terminal markup for agent comments — guide, preview, live-width feedback by @benvinegar in #512
      • fix: upgrade OpenTUI for renderer stability by @benvinegar in #538
      • fix: reduce retained geometry memory in large reviews by @matthew-hre in #521
      • feat(ui): prompt to save view preferences on quit by @benvinegar in #468
      • feat(watch): replace 250 ms watch polling with evented filesystem observation by @elucid in #531
      • chore(benchmarks): backfill 0.17.1 release snapshot by @benvinegar in #547
      • fix(ui): copy selection misaligns on wide (CJK) characters by @endotakuya in #548
      • fix(cli): reject partially numeric line and hunk values by @fallintoplace in #535
      • fix(ui): wrap agent note text by terminal cells by @kataokatsuki in #567
      • fix(pager): extend row backgrounds to host edge by @benvinegar in #571
      • fix(session): refresh daemons for STML payloads by @benvinegar in #572
      • docs(markup): clarify native note composition by @benvinegar in #573
      • feat(theme): support raw Shiki syntax scopes by @benvinegar in #570
      • fix(theme): surface legacy syntax translation by @benvinegar in #574
      • fix(review): save draft notes exactly once under rapid Ctrl+S by @endotakuya in #581
      • fix(ui): distinguish root files in sidebar by @BowlOfSoup in #519
      • fix(ui): restore threaded rendering on macOS by @benvinegar in #539
      • feat: make diff tab width configurable by @benvinegar in #588
      • feat(stml): require experimental opt-in by @benvinegar in #589
      • fix(cli): lazy-load OpenTUI for headless commands by @benvinegar in #590
      • perf(ui): optimize terminal cell width measurement (#579) by @kazu728 in #586
      • feat(skill): generate the hunk-review skill from a typed agent surface by @benvinegar in #596
      • fix(update): show Nix-aware upgrade guidance by @benvinegar in #598
      • perf(ui): optimize wrapped Unicode rendering by @benvinegar in #601
      • docs(website): add Starlight documentation site by @benvinegar in #603
      • feat(website): unify marketing and docs by @benvinegar in #604
      • feat(extensions): experimental TypeScript extension system (phase 1) by @benvinegar in #599
      • feat(website): unify marketing and docs design by @benvinegar in #605
      • feat(extensions): folder extensions with package.json manifests by @benvinegar in #606
      • Extensions can replace the sidebar with custom React components by @benvinegar in #609
      • feat(website): add community videos and an agent-review section to the landing page by @benvinegar in #610
      • feat(extensions): keyboard commands and additive multi-sidebar views by @benvinegar in #611
      • feat(ui): drive menus and help from the command table, and add an Extensions menu by @benvinegar in #614
      • fix(session): support IPv6 loopback broker URLs by @benvinegar in #613
      • feat(extensions): give command handlers the review selection by @benvinegar in #616
      • fix(website): track documentation visits by @benvinegar in #620
      • feat(extensions): dialog primitives for command handlers by @benvinegar in #617
      • feat(extensions): inject resolved sidebar keybindings by @benvinegar in #615
      • docs: extract theme configuration guide by @benvinegar in #622
      • feat(extensions): expand event surface by @benvinegar in #619
      • fix(nix): keep flake evaluable on nixpkgs without x86_64-darwin by @elucid in #621
      • fix(website): upgrade Astro security dependencies by @benvinegar in #623
      • Support .tsx and .jsx extension entries in discovery by @benvinegar in #625
      • refactor(architecture): establish application boundaries by @benvinegar in #624
      • feat(extensions): expose public hunk summaries on file views by @benvinegar in #626
      • fix(deps): upgrade shell-quote security patch by @benvinegar in #627
      • docs(extensions): commit the scrollbox ref contract for custom sidebars by @benvinegar in #630
      • feat(extensions): give command handlers guarded review navigation by @benvinegar in #629
      • refactor(session): consolidate internal session modules by @benvinegar in #628
      • docs(website): add a self-contained Extend section to the docs site by @benvinegar in #631
      • Restyle community video cards as paused YouTube embeds by @benvinegar in #641
      • docs(website): add keybindings guide to the docs site by @benvinegar in #634
      • feat(website): center and widen the docs shell on wide viewports by @benvinegar in #642
      • feat(website): rebuild the landing page feature section around real TUI captures by @benvinegar in #643
      • feat(extensions): add custom file previews by @benvinegar in #632
      • docs(extensions): document custom file previews by @benvinegar in #644
      • fix(ui): step keys scrolling multiple lines after a review-stream click by @HackAttack in #645
      • feat(pager): give pager mode the full review controls by @HackAttack in #647
      • ci(release): switch npm publishing to trusted publishing (OIDC) by @benvinegar in #640
      • fix(ui): route keys by ownership so modal surfaces stop double-handling them by @elucid in #649
      • refactor(ui): isolate extension dialog lifecycle by @benvinegar in #651
      • ci(release): verify generated prerelease notes by @benvinegar in #654
      • perf(ui): skip inactive file-view preparation by @benvinegar in #652
      • fix(ui): keep file navigation from losing the file it just jumped to by @elucid in #655
      • chore(release): prepare 0.18.0-beta.0 by @benvinegar in #653
      • chore(release): link changelog pull requests by @benvinegar in #657
      • chore(release): finalize 0.18.0-beta.0 metadata by @benvinegar in #660
      • fix(release): include provenance in platform packages by @benvinegar in #661
      • chore(deps): bump the github-actions group with 4 updates by @dependabot[bot] in #659
      • fix(ui): preserve file headers on narrow terminals by @benvinegar in #668
      • test(git): isolate fixture repos from the developer's Git config by @HackAttack in #679
      • fix(git): display quoted Unicode paths by @benvinegar in #670
      • fix(ui): preserve syntax state across folded hunks by @benvinegar in #669
      • refactor(ui): isolate file presentation state by @benvinegar in #656
      • feat(review): mark the current line and anchor notes to it by @loganthomas in #662
      • feat(extensions): let file views refresh their prepared layouts by @benvinegar in #673
      • feat(extensions): add host-mediated workspace document reads and writes by @benvinegar in #674
      • feat(extensions): add interactive file-view modes by @benvinegar in #675
      • feat(ui): show changed-file count in menu bar by @benvinegar in #684
      • fix(ui): bound current-line navigation costs by @benvinegar in #685
      • chore(release): prepare 0.18.0 by @benvinegar in #687

      New Contributors

      Full Changelog : v0.17.7...v0.18.0

    4. 🔗 Jeremy Fielding (YouTube) Engineering The Perfect Stereo Camera. Engineer Vs Bee : Round 3 rss

      Tackle problems with Claude 👉 http://clau.de/Jeremy_Fielding This work was supported by the Alfred P. Sloan Foundation, enhancing public understanding of science and technology in the modern era, in partnership with IMI: watch what matters. https://www.theimi.co/ & https://sloan.org/programs/public-understanding Order custom parts Send Cut Send 👉 http://sendcutsend.com/jeremyfielding If you want to join my community of makers and Tinkers consider getting a YouTube membership 👉 https://www.youtube.com/@JeremyFieldingSr/join

      If you want to chip in a few bucks to support these projects and teaching videos, please visit my Patreon page or Buy Me a Coffee. 👉 https://www.patreon.com/jeremyfieldingsr 👉 https://www.buymeacoffee.com/jeremyfielding

      Social media, websites, and other channel

      Discord 👉https://discord.gg/F3XuyhNRPc Instagram https://www.instagram.com/jeremy_fielding/?hl=en Twitter 👉https://twitter.com/jeremy_fielding TikTok 👉https://www.tiktok.com/@jeremy_fielding0 LinkedIn 👉https://www.linkedin.com/in/jeremy-fielding-749b55250/ My websites 👉 https://www.jeremyfielding.com 👉https://www.fatherhoodengineered.com My other channel Fatherhood engineered channel 👉 https://www.youtube.com/channel/UC_jX1r7deAcCJ_fTtM9x8ZA

      Notes:

      Technical corrections

      Nothing yet

    5. 🔗 r/LocalLLaMA 2027 Memory Capacity Is Reportedly Sold Out rss

      2027 Memory Capacity Is Reportedly Sold Out | submitted by /u/johnnyApplePRNG
      [link] [comments]
      ---|---

    6. 🔗 r/LocalLLaMA DeepSeek V4 Flash 0731 appreciation post rss

      I’m running DSV4F 0731 on dual spark, and honestly… wow. It’s an absolute workhorse, and the benchmarks are real.

      Everyday tasks with Hermes agent? Effortless.

      Coding tasks with OpenCode? I’m genuinely amazed at what it can handle. I can throw a two-hour coding session at it, and it just keeps going until the job is done. Building integrations has never been easier - I ask OpenCode to handle it, DS tells me to hold its beer, and a little while later, it’s finished.

      Searching and gathering knowledge from emails? Right at your fingertips.

      Going through documents with Paperless NGX? No problem at all.

      Filling out ton of paperwork in DOCX? Easy peasy, just wrote skill in hermes, love it!

      OS admin work? just works!

      Sure, before the Q3.6 27B full FP8 on dual 3090 was really solid, but DSV4F 0731 is on a whole new level.

      I run a small company, and I just ordered another pair of DGX Sparks - because it genuinely feels like I now have a super capable worker on the team. I know they’re not cheap, but I’ve already saved a ton of time.

      I started with MiniMax M2.7 on dual Spark, and it was good - but now with DSV4F 0731? It’s just super good. And the fact that I get even better models over time, for what I already paid for, feels almost ridiculous. That’s exactly why I decided to grab another pair..

      A few client tickets were literally copy-paste from the ticket system - solved, and money earned. What a time to be alive!

      This weekend, I’m definitely writing a ticket system integration. Can’t wait!

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

    7. 🔗 HexRaysSA/plugin-repository commits sync repo: +5 releases rss 
      sync repo: +5 releases

## New releases
- [array-helper](https://github.com/milankovo/array-helper): 1.1.0
- [ida-codemode](https://github.com/hexrayssa/ida-codemode): 0.3.1, 0.3.0
- [ida-enums-helper](https://github.com/milankovo/ida_enums_helper): 1.1.0
- [yank_type](https://github.com/milankovo/ida-yank-type): 1.1.0

generated: August 11, 2026 at 12:36:03