🏡


to read (pdf)

  1. I don't want your PRs anymore
  2. JitterDropper | OALABS Research
  3. DomainTools Investigations | DPRK Malware Modularity: Diversity and Functional Specialization
  4. EXHIB: A Benchmark for Realistic and Diverse Evaluation of Function Similarity in the Wild
  5. Neobrutalism components - Start making neobrutalism layouts today

  1. June 19, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-19 rss

      IDA Plugin Updates on 2026-06-19

      Activity:

    2. 🔗 HexRaysSA/plugin-repository commits sync plugin-repository.json rss
      sync plugin-repository.json
      
      No plugin changes detected
      
    3. 🔗 r/LocalLLaMA What's more impressive, GLM 5.1 -> 5.2 or Qwen 3.5 -> 3.6? rss

      What's more impressive, GLM 5.1 -> 5.2 or Qwen 3.5 -> 3.6? |

      Write a single HTML file with a full-page canvas and no libraries. Simulate a realistic Döner Style kebab skewer rotating (vertically) in front of a gas powered heating element.

      Mentioning Döner activates GLM 5.2s german weights or something (Spiess = Skewer, Brenner = Burner). Qwen 3.6 35B, Qwen 3.5 and Gemma 4 using Unsloth Q8 K XL quants via llama cpp. The others via OpenRouter. Full data here submitted by /u/Excellent_Jelly2788
      [link] [comments]
      ---|---

    4. 🔗 HexRaysSA/plugin-repository commits fix duplicated plugin idalib-rust-bindings (#33) rss
      fix duplicated plugin idalib-rust-bindings (#33)
      
    5. 🔗 Hex-Rays Blog IDA 9.4: Apple Dyld Shared Cache workflow improvements rss

      IDA 9.4: Apple Dyld Shared Cache workflow improvements

      Over the years, the Apple ecosystem (iOS, macOS, …) has seen steady gains in security, application load-time, and more. One of the cornerstones enabling those is the "Dyld Shared Cache" (DSC): a highly specific collection of common system libraries, pre-optimized on many fronts and used across applications.

    6. 🔗 r/LocalLLaMA Researchers trained a Deep Research agent with 32 H100s and open-sourced everything rss

      Researchers trained a Deep Research agent with 32 H100s and open-sourced everything | Ohio State University's NLP team released QUEST-35B, an open-source Deep Research agent trained using ~32 H100s and ~8K synthetic samples. The team open-sourced the training recipe, code, weights and datasets. Benchmark results show competitive performance against several frontier Deep Research systems. What do you think is the biggest remaining gap between open-source Deep Research agents and frontier closed systems? Source: Professor Yusu submitted by /u/BuildwithVignesh
      [link] [comments]
      ---|---

    7. 🔗 earendil-works/pi v0.79.8 release

      New Features

      • Selective provider base entry points - SDK users can pair @earendil-works/pi-ai/base and @earendil-works/pi-agent-core/base with explicit provider registration to keep bundled applications from including unused provider transports. See pi-ai Base Entry Point and pi-agent-core Base Entry Point.
      • Mistral prompt caching - Mistral sessions now use provider-side prompt caching with session affinity and cached-token usage/cost accounting. See API Keys and Environment Variables.
      • Post-compaction token estimates - Compact results and compaction events now include estimated post-compaction token counts so clients can show the approximate context reduction. See RPC compact and compaction events.
      • OpenRouter Fusion alias - openrouter/fusion is available as a built-in OpenRouter model alias. See API Keys.

      Added

      • Added inherited @earendil-works/pi-ai/base and @earendil-works/pi-agent-core/base entry points for selective provider registration in bundled applications (#5348 by @FredKSchott).
      • Added inherited Mistral prompt caching using the pi session ID as prompt_cache_key, including cached-token usage and cost accounting (#5854).
      • Added estimated post-compaction token counts to compact results and compaction events (#5877).
      • Added the inherited OpenRouter Fusion alias as openrouter/fusion (#5866 by @dannote).

      Fixed

      • Updated vulnerable runtime dependencies, including undici and the packaged protobufjs transitive dependency.
      • Fixed compaction to refuse sessions with no eligible messages instead of producing empty summaries (#4811).
      • Fixed successful overflow-triggered auto-compaction to avoid retrying completed assistant responses (#5720).
    8. 🔗 MetaBrainz Phishing attempts using MetaBrainz messages rss

      There have been reports of users receiving phishing messages via the MetaBrainz messaging service.

      Remember: MetaBrainz staff will never ask for your password. MetaBrainz staff will never ask you to log in to a third-party site (or 'verify' your username and password in any other way).

      Staff are also likely to email you about account issues directly from an @metabrainz account rather than the user-to-user messaging service.

      You can go a step further and apply these rules to every website and service… you are now 99% phishing-proof!

      Below is an example of a reported phishing message. This is not a message from staff. It is an attempt to compromise a MetaBrainz account by getting a user to enter their username and password into a third-party website.

      If you receive phishing attempts (or spot other scams) via MetaBrainz services please leave a comment here. There is also a thread on the community forums discussing the phishing messages.

    9. 🔗 Ampcode News Custom Agents rss

      You can now create custom agents in Amp with plugins.

      You can use these custom agents as your main Amp agent, or as subagents. You can use them as a small part of a tool pipeline that you invoke with amp -x. Or you can spawn 25 custom worker agents, then switch between them.

      Each custom agent comes with a custom orb color.

      Here is how you define a custom agent in an Amp plugin:

      // .amp/plugins/focused-reviewer-agent.ts
      import type { PluginAPI } from '@ampcode/plugin'
      
      export default function (amp: PluginAPI) {
          // Create the agent
          const reviewer = amp.createAgent({
              name: 'focused-reviewer',
              model: 'openai/gpt-5.5',
              instructions: [
                  'You are a focused code-review subagent.',
                  'Inspect only the files and concerns named by the caller.',
                  'Return concise findings with severity, evidence, and suggested fixes.',
              ].join(' '),
              tools: 'all',
              display: { label: 'reviewer', color: '#d97706' },
          })
      
          // Register a tool. This agent acts as a subagent
          amp.registerTool({
              name: 'focused_review',
              description: 'Run a focused code-review subagent.',
              inputSchema: {
                  type: 'object',
                  properties: {
                      request: { type: 'string' },
                  },
                  required: ['request'],
              },
      
              async execute(input, ctx) {
                  // Run a one-shot agent turn
                  const result = await reviewer.run(input, {
                      parentThreadID: ctx.thread.id,
                  })
                  return result.text
              },
          })
      
          // Or register the agent as a selectable main thread mode
          amp.registerAgentMode({
              key: 'focused-reviewer',
              description: 'Code Review Expert',
              agent: reviewer.definition,
          })
      }
      

      Threads

      Once you have defined an agent, you can create threads:

      // Spawn a new thread
      const thread = await reviewer.createThread({
          // Tell the UI switch to this thread
          show: true,
      })
      
      // Get an existing thread
      const thread = amp.threads.get(input.threadID)
      

      The Thread object lets you interact with a thread in many different ways, and is where the real power comes in.

      Send a message to a Thread

      Add a new user message to a thread by calling thread.appendUserMessage(). The call returns as soon as Amp has accepted the message; it does not wait for inference to complete before returning.

      await thread.appendUserMessage({
          type: 'user-message',
          content: 'Review the auth changes in this branch.',
      })
      

      Wait for the Agent's response

      When you do want to wait, call waitForResponse() on the thread. It resolves with the next assistant message after the agent finishes its turn.

      const reply = await thread.waitForResponse()
      

      Example: Spawn an async thread that responds to the main thread

      These are just a few primitives provided by the Plugin API. Together, they compose into unique workflows. An example used on the Amp team: spawn an agent in an asynchronous thread, and give it the tools it needs to respond to the parent when it needs to.

      amp.registerTool({
          name: 'start_async_review',
          description: 'Start a review in a background thread.',
          inputSchema: { type: 'object', properties: {} },
          async execute(_input, ctx) {
              const thread = await reviewer.createThread({
                  parentThreadID: ctx.thread.id,
              })
      
              await thread.appendUserMessage({
                  type: 'user-message',
                  content: [
                      'Review the auth changes in this branch.',
                      `When you are done, call send_to_thread with threadID ${ctx.thread.id}`,
                      'and include your review in the message.',
                  ].join(' '),
              })
      
              return `Started background review in ${thread.id}.`
          },
      })
      

      Full documentation is in the manual. Happy Hacking.

  2. June 18, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-18 rss

      IDA Plugin Updates on 2026-06-18

      New Releases:

      Activity:

      • atelier
        • 88b48395: chore: bump to v0.4.20
        • 515396b9: chore: bump to v0.4.19
        • 04079e76: fix(install): pick newest wheel, clean stale ones; cache statusline s…
        • 5fca8f2c: chore: bump to v0.4.18
        • 148f2372: fix(install): make dev kills prod-path MCP servers, spares only .venv…
        • 6b59442d: chore: bump to v0.4.17
        • f9ccf622: feat(index): show 'N of X commits (rest in background)' in git histor…
        • 43269d9a: Merge: linearize grep symbol-span extraction (vscode grep ~240s -> <1s)
        • bd87f039: perf(search): linearize grep symbol-span extraction (quadratic -> lin…
        • 427b2a69: chore: bump to v0.4.16
        • 64998584: fix(init): -no-index on install, 10s lock timeout (was 30s hang)
        • 6cd943cb: fix(install): follow redirects for Content-Length; make release target
        • 6cb7451d: fix(install): bundle AGENTS.atelier.md; show host error output; 30s i…
        • 7ee2f930: chore: bump to v0.4.13
      • capa
        • 29575cac: Merge pull request #3110 from mandiant/dependabot/npm_and_yarn/web/ex…
        • e2154630: build(deps): bump form-data from 4.0.4 to 4.0.6 in /web/explorer (#3109)
        • f28a1505: Merge pull request #3105 from mandiant/dependabot/npm_and_yarn/web/ex…
      • disrobe
        • a9907897: native: detect obfusheader.h by its strip-surviving pointer-shuffle c…
        • e39d29fd: native: detect guardian-rs x86-64 virtualizer by its embedded .vm/.by…
        • b8691069: native: detect rust-obfuscator/cryptify by its CRYPTIFY_KEY decrypt s…
        • 9ccae3de: skip the mio (0.8/1.x) and yaxpeax-arch (0.2/0.3) transitive duplicat…
        • 69983fc9: native: detect obfus.h by its .obfh signature section
        • 818c5e3d: shell: detect real Chameleon long-random variable renames (Invoke-Ste…
        • fc8cfe9e: cover Protector::BitMono in the chain quality_for match (the chain-fe…
        • b887f1d2: dotnet: detect BitMono + tolerate its anti-static-tooling header corr…
        • 47fff2fc: jvm: fold skidfuscator xor-seed integer obfuscation back to literals
        • c61daac2: native: fold real -O0 ollvm -bcf opaque-predicate-or-real-condition b…
        • cde7b2ad: native: lift real -O0 ollvm -sub through stack slots and reduce its x…
        • c5c8bdf6: native: make the synthetic packer-detection test buffers valid PE images
        • af4fe246: rustfmt the frisk-gauntlet temp-dir join (i committed the race fix wi…
        • 191e63df: native: label the Tigress CFF self-authored fixture as not-real-proof…
        • 4ce3b000: native: label the self-authored iced ollvm tests as the linear-chain/…
        • 4a8cb6ec: native: recover real ollvm-16 flattened LOOPS - resolve a case block'…
        • 0c79b882: give each frisk-gauntlet staged corpus its own temp dir (the per-pid …
        • 9bb85f99: native: recover REAL ollvm-16 control-flow flattening - generalize th…
        • aa7fcd7e: php deob: CFG-restructure pass that recovers yakpro goto-flattened co…
        • 32cb2c7b: regenerate the js/jvm/beam chain goldens after the decimal-radix, fin…
      • doki-ida
        • 17a72dfe: Fixing the sticker and adding crawling asset
      • hrtng
        • 13f20220: deinline: fix single block mode
      • ida-domain
        • 1819169c: Fix problems with invalid license for CI tests (#88)
      • project
        • cb289b8d: added access path shortening
      • showcomments
      • zenyard-ida-public
        • 8edba8e6: Sync with 3c18c5fe1f2ddd30b17f09d629f3362309e4913d
    2. 🔗 Simon Willison Datasette Apps: Host custom HTML applications inside Datasette rss

      Today we launched a new plugin for Datasette, datasette-apps, with this launch announcement post on the Datasette project blog. That post has the what, but I'm going to expand on that a little bit here to provide the why.

      The TL;DR

      Datasette Apps are self-contained HTML+JavaScript applications that run in a tightly constrained <iframe> sandbox hosted on your Datasette application. They can use JavaScript to run read-only SQL queries against data in Datasette, and can run write queries too if you configure them with some stored queries.

      Here's a very simple example and a more complex custom timeline example - the latter looks like this:

      Screenshot of a web app titled "Datasette timeline" with "All apps", "Edit app", and "Pin" buttons top-right and a "Full screen" button below them. Inside a bordered panel, the heading "Datasette timeline" sits above a search box reading "Search news, blog posts and releases…" with three checked checkboxes labeled News, Blog, and Releases. Below, text reads "Showing 200 of 1,953 items", followed by a scrollable list of timeline entries. Each entry has a colored tag (blue "BLOG" or green "RELEASE"), a date, a blue linked title, and a paragraph of description. The visible entries are a "BLOG" post dated 2026-06-11 titled "Datasette 1.0a33 with JSON extras in the API", a "RELEASE" dated 2026-06-11 titled "datasette 1.0a33", and a "RELEASE" dated 2026-06-09 titled "llm 0.32a3", each with body text and a "▶ Show more" toggle. A separate panel at the bottom shows a collapsed "▶ 2 log entries" toggle.

      Apps are allowed to run JavaScript and render HTML and CSS. They are limited in terms of access - the <iframe sandbox="allow-scripts allow-forms"> they run in prevents them from accessing cookies or localStorage and they also have an injected CSP header (thanks to this research) which prevents them from making HTTP requests to outside hosts, preventing a malicious or buggy app from exfiltrating private data.

      Datasette Apps started out as my attempt at building a Claude Artifacts mechanism for Datasette Agent, but I quickly realised that the sandboxed pattern is interesting for way more than just adding custom apps in a chat interface and promoted it to its own top-level concept within the Datasette ecosystem.

      They're also a fun way to turn my multi-year experiment in vibe-coded HTML tools into a core feature of my main project!

      You can try out Datasette Apps by signing in with GitHub to the agent.datasette.io demo instance.

      Why build this?

      Since the very first release, Datasette has offered a flexible backend for creating custom HTML apps via its JSON API.

      One of my earliest Datasette projects was an internal search engine for documentation when I worked at Eventbrite - it worked by importing documents from different systems into SQLite on a cron and then serving them through a Datasette instance with a custom HTML+JavaScript search interface that directly queried the Datasette API.

      I had client-side JavaScript constructing SQL queries, which originally was intended as an engineering joke but turned out to be a really productive way of iterating on the app!

      That project, combined with my experience building my HTML tools collection and my experiments with Claude Artifacts, has convinced me that adding a Datasette-style backend to a self-contained HTML frontend is an astonishingly powerful combination.

      Imagine how much more useful Claude Artifacts could be if they had access to a persistent relational database. That's what I'm building with Datasette Apps!

      Neat ideas in Datasette Apps

      Here are a few of the ideas and patterns I've figured out building this which I think have staying power.

      <iframe sandbox="allow-scripts" srcdoc="..."> + <meta http-equiv="Content-Security-Policy" content="default-src 'none'; script-src 'unsafe-inline'; style-src 'unsafe-inline'; img-src data: blob:;">

      This is the magic combination that makes Datasette Apps feasible in the first place. I need to run untrusted HTML and JavaScript on a highly sensitive domain - an authenticated Datasette instance can contain all sorts of private data. The sandbox= attribute lets me run that untrusted code in a way that cannot interact with the parent application - it can't read the DOM, or access cookies, or steal secrets from localStorage. It can however use fetch() and friends to load content (or exfiltrate data) from other domains. But... it turns out if you start an HTML page with a <meta http-equiv="Content-Security-Policy"> header you can set additional policies that lock down access to other domains. I was worried that malicious JavaScript would be able to update or remove that header but it turns out that doesn't work - once set, the CSP policy is immutable for the content of that frame.

      Locked down APIs with postMessage() and MessageChannel()

      Having locked down those iframes to the point that they couldn't do anything interesting at all, the challenge was to open them back again such that they could run an allow-list of operations, starting with read-only SQL queries against specified databases.

      I built the first version of this with postMessage(), which allows a child iframe to send messages to the parent window. I created a simple protocol for requesting that the parent run a SQL query - the parent could then verify it was against an allow-listed database before executing it.

      One of the LLM tools, I think it was GPT-5.5, suggested that postMessage() on its own can be exploited if the iframe somehow loads additional code from an untrusted domain. I don't think that applies to Datasette Apps, but I also believe in defense in depth, so I had GPT-5.5 help me port to a MessageChannel() based transport instead.

      MessageChannel() has the advantage that if a page navigates to somewhere else the channel closes automatically, removing any chance of executing commands sent from an untrusted external page.

      Visible logs, for queries and errors

      If you navigate to the timeline demo and search for the string usercontent you'll pull in some search results that embed images from the user-images.githubusercontent.com domain. This domain is not in the CSP allow-list, so it trips an error.

      Those errors are captured and transmitted back to the parent frame, where they can be displayed in a useful error log. This is meant to make hacking on apps more productive by surfacing otherwise-invisible problems.

      I built an experiment demonstrating that you can even turn this into a one-click-to-allow mechanism for building the CSP allow-list based on what breaks, but I haven't integrated that idea into datasette-apps just yet.

      SQL queries are also visibly logged - scroll to the bottom of the timeline page to see that in action.

      Stored queries for write operations

      I want apps to be able to conditionally write to the database, but this is an even more dangerous proposition than SQL reads!

      My solution involves Datasette's stored queries feature, rebranded from "canned queries" and given a major upgrade in the recent Datasette 1.0a31 - work that was directly inspired by Datasette Apps.

      Users can create a stored write query that performs an insert or update, then allow-list that specific query for an app to use. Usage from code inside an app looks like this:

      const result = await datasette.storedQuery("todos", "add_todo", {
        title: "Buy milk",
        due_date: "2026-06-20",
        priority: "high",
        completed: false
      });

      I'm only just beginning to explore the possibilities this unlocks myself, but my goal is to support full read-write applications built safely as Datasette Apps.

      Copy and paste a prompt to build an app

      The Datasette Apps plugin has no dependency on LLMs at all, but these self-contained apps are the perfect shape to be written by a modern LLM.

      The create app form includes a copyable prompt at the end. This prompt has everything a model needs to know to build a new app, including the schema of any selected databases.

      Screenshot of the lower part of a "Create app" page. At the top is the tail end of an HTML code editor (lines 35–43, closing the script, body, and html tags) and a blue "Create app" button. Below is a section headed "Use AI to build this app" with the text "Describe the app you want in an LLM chat, then copy this prompt in as context so it can generate or revise the app HTML. Paste the result into the HTML editor above." A blue "Copy prompt" button sits above a "▼ Show full prompt" toggle. An expanded text box shows the prompt: "Build a Datasette HTML app. App name: Latest news. Return a complete single-file HTML document. Include <DOCTYPE, CSS, and JavaScript in the same file. This app will run inside a sandboxed iframe protected by a strict Content Security Policy. Important limitations: – Direct network access is disabled by default. – The app cannot fetch from Datasette, localhost, or arbitrary origins. – External fetch() requests only work for exact https:// origins explicitly granted in the app's network access settings. – Remote images are allowed from those same exact https:// origins. Local file previews using data: and blob: image URLs are allowed. – External script tags are allowed from those same exact https:// origins. – External stylesheet links and style elements are allowed from those same exact https:// origins. – history.replaceState(), history.pushState(), history.back(), history.forward(), and history.go() are no-ops in the sandbox. – CORS still applies even when an origin is granted. Use this API for data access: – await datasette.query(database, sql, params?)"

      This means you can click "copy", paste it into ChatGPT or Claude or Gemini, tell it what you need, and there's a good chance the model will spit out the code necessary to build the app.

      If you have Datasette Agent installed your AI assistant will also gain tools to both create new apps and edit existing ones, Claude Artifacts style.

      Screenshot of a "Chat" interface with a "← Back" link top-left and an "EXPORT" button top-right. A blue user message bubble reads "Build an app showing the 5 most recent headlines from the blog_posts table". Below are two collapsed toggles: "► Tool: describe_table" and "► Result: describe_table". A thinking line reads "Thinking: …will transition to creating the application using app_create as the next step." A section headed "Querying Latest Posts" reads "I've successfully queried the blog_posts table for the 5 most recent titles. The SQL query, SELECT title FROM blog_posts ORDER BY datetime_utc DESC LIMIT 5, is working as expected. Now, I will transition to creating the application using app_create as the next step." An expanded "▼ Tool: app_create" box shows escaped JSON HTML: { "html": "...." Below: "Recent Blog Headlines created." with "View app" and "Edit" buttons, a collapsed "► Result: app_create" toggle, and a final message: "The app "Recent Blog Headlines" has been created. It displays the 5 most recent headlines from the blog_posts table in the content database."

      Built with so much AI assistance

      Datasette Apps started life back in April as datasette-agent-artifacts, a plugin I have since renamed to datasette-agent-edit keeping only its editing tools. I built that as one of the first plugins for Datasette Agent, to help get the plugin hooks into the right shape. That first prototype was mainly built using Claude Opus 4.6 in Claude Code.

      When I switched track to Datasette Apps I started with a plan constructed using Codex Desktop and GPT-5.5 xhigh, based on extensive dialog and feeding in both datasette-agent-artifacts and other prototypes I had built.

      Most of the work that followed stuck with Codex, but in the few short days that we had access to Claude Fable 5 I had it run a security evaluation of the product (an ability that would get it banned by the US government shortly afterwards) and it found a very real problem.

      I was allowing users to allow-list CSP hosts for their apps, but Fable pointed out the following attack:

      1. A less privileged user with create-app permission creates an app that queries SQLite for all available tables and selects and exfiltrates all of the data to a host they had allow-listed via CSP.
      2. They then trick an administrator user with access to private data into visiting their app.
      3. ... and the app can now run queries as that user and steal their private data!

      That's clearly unacceptable. I fixed it by restricting the ability to allow-list any domain to a new apps-set-csp permission, which is intended just for trusted staff. Site administrators can also configure Datasette with a list of allowed_csp_origins, which regular users can then select. This means you can do things like allow cdnjs.cloudflare.com and your users will be able to build apps that load extra JavaScript libraries from the cdnjs CDN.

      I've reviewed Datasette Apps extremely closely, especially the security-adjacent parts of it. The critical sandbox and CSP configuration are based on multiple AI-assisted prototypes and tests.

      It's looking good so far

      I'm really pleased with this initial release.

      Datasette is growing beyond its origins as an application for serving read-only data into a much richer ecosystem of tools for doing useful things with that data once it has been collected.

      Datasette's roots are in data journalism. I've always been interested in the question of what comes next after a journalist gets their hands on a giant dump of data about the world. Datasette supports exploring and publishing it. Datasette Agent adds interrogating it with AI assistance. Now Datasette Apps expands that to building custom interfaces and visualizations to help unlock the stories that are hidden within.

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

    3. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss
      sync repo: +1 plugin, +1 release
      
      ## New plugins
      - [idasvg](https://github.com/chichou/idasvg) (0.1.0)
      
    4. 🔗 oxigraph/oxigraph v0.5.9 release

      Store: make Transaction and BulkLoader Send and Sync.

    5. 🔗 earendil-works/pi v0.79.7 release

      New Features

      • Automatic theme mode - /settings can choose separate light and dark themes and follow terminal color-scheme changes. See Selecting a Theme.
      • Self-only updates by default - pi update now updates pi only, with pi update --all for updating pi and packages together. See Install and Manage.
      • Extension API helpers - extensions can use CONFIG_DIR_NAME for project config paths and import edit diff helpers for edit-style diffs. See ctx.cwd and SDK Exports.
      • Warp inline images - Warp terminals now get inline image rendering through Kitty graphics detection. See Image.

      Added

      • Added automatic theme mode so /settings can use separate light and dark themes and follow terminal color-scheme changes (#5874).
      • Added inherited Warp terminal image capability detection so inline images render through Warp's Kitty graphics support (#5841 by @dodiego).
      • Exported CONFIG_DIR_NAME from the coding-agent public API so extensions can resolve project config paths without hardcoding .pi (#5869 by @xl0).
      • Exported edit diff helpers (generateDiffString, generateUnifiedPatch, and EditDiffResult) from the public API for extensions that need edit-style diffs (#5756 by @xl0).

      Changed

      • Changed bare pi update to update only pi, added pi update --all for updating pi and extensions together, and clarified extension update prompts.
      • Reserved / in theme names for automatic light/dark theme settings.
      • Updated extension docs, examples, runtime help, trust prompts, and config labels to use the configured project config directory instead of hardcoded .pi paths.

      Fixed

      • Fixed RPC unknown-command errors to include the request id so clients do not hang waiting for a response (#5868).
      • Fixed /model autocomplete and model selection searches to match provider/model queries regardless of whether the provider or model token is typed first.
      • Fixed the tree navigator to horizontally pan deep entries so the selected item remains readable (#5830).
    6. 🔗 r/LocalLLaMA My suitcase robot gets high now off a real gas sensor wired straight into the LLM sampler. Smoke raises temperature/top_p/top_k live, so his speech genuinely gets loopier and never repeats. rss

      My suitcase robot gets high now off a real gas sensor wired straight into the LLM sampler. Smoke raises temperature/top_p/top_k live, so his speech genuinely gets loopier and never repeats. | Follow-up on Sparky, my offline suitcase robot I keep overdeveloping. He gets high now, and there's no scripted "stoned mode" anywhere in it. A real MQ-2 gas sensor sits in the case. Every 0.5s I read it against an adaptive clean-air baseline and turn a smoke hit into a 0 to 10 phase that climbs as you blow at him and decays on its own over minutes. The fun part is that phase rewires his sampler per token. Temperature 1.0 to ~1.6, top_p 0.95 to 0.99, top_k 64 to 120 as he climbs. His word choice flattens and wanders to lower-probability, more associative tokens, so his cognition genuinely gets noisier. It's the live sampler doing the work, so every high reply is freshly generated and never the same. A per-phase persona nudge makes him show it without ever announcing "I am high." The body does the rest: a slight drawl, eyes that droop and go bloodshot, and the sensor display that escalates to a full smoke-and-plasma freakout at phase 10, keeping him blitzed there for the next 7 minutes. Honest caveat so nobody has to call it out: it's a smoke and VOC sensor, so a cigarette or incense probably trips it too. But blowing smoke and watching him unravel is watching a real measurement scramble a real model, live - and it's funny! Just an added Easter Egg to an already goofy suitcase robot. A real question for the hardware folks: is there a sensor, or a combination, that could actually distinguish cannabis smoke from generic smoke and VOCs? The MQ-2 can't really tell a joint from a candle, and I'd love to make the detection more specific if possible. submitted by /u/CreativelyBankrupt
      [link] [comments]
      ---|---

    7. 🔗 r/LocalLLaMA GLM-5.2 inference is free on Hugging Face for the next 6 hours rss
    8. 🔗 r/LocalLLaMA GLM's founder says GLM-fable before the end of the year?! rss

      GLM's founder says GLM-fable before the end of the year?! | submitted by /u/Charuru
      [link] [comments]
      ---|---

    9. 🔗 HexRaysSA/plugin-repository commits Fix/EA-762 cap ida versions (#32) rss
      Fix/EA-762 cap ida versions (#32)
      
      * fix(merger): cap idaVersions at latest released IDA (EA-762)
      
      The upstream HCLI index expands open-ended specs like >=9.0 into a concrete
      list that includes unreleased placeholders (e.g. 10.0), so plugin pages
      advertised compatibility with non-existent IDA releases.
      
      - cap_ida_versions() trims idaVersions to <= the latest released IDA in both
        transform paths (sp-aware comparison); prettified ranges follow.
      - LATEST_RELEASED_IDA resolves from env, defaulting to a reviewed constant.
      - justfile + deploy.yml derive it dynamically from the hcli download catalog
        (hcli download --list-tags, authed via HCLI_API_KEY in CI); falls back to the
        default when hcli is unavailable/unauthenticated, so the build never fails.
      
      Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
      
      * revert(EA-762): drop hcli download --list-tags wiring; keep env-overridable cap
      
      plugin-repository is public, so we don't want a Hex-Rays portal API key in CI
      even as a secret. Remove the hcli-based dynamic derivation from the justfile
      (latest-ida recipe) and deploy.yml (HCLI_API_KEY + --list-tags).
      
      idaVersions are still capped via merge_plugins.py's LATEST_RELEASED_IDA — a
      reviewed default (9.4) overridable with the LATEST_RELEASED_IDA env var when a
      new IDA ships. No auth, no secret.
      
      Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
      
      * chore(EA-762): drop redundant cap comments from justfile and deploy.yml
      
      The override mechanism is documented at LATEST_RELEASED_IDA in merge_plugins.py;
      these were duplicate notes on now-generic merger invocations.
      
      * feat(EA-762): derive LATEST_RELEASED_IDA from hcli download catalog in CI
      
      Re-introduce the dynamic IDA-version cap: justfile (latest-ida recipe + dynamic
      merge-plugins) and deploy.yml derive LATEST_RELEASED_IDA from
      `hcli download --list-tags`, authenticated via the HCLI_API_KEY repo secret.
      Falls back to merge_plugins.py's reviewed default when hcli is unavailable or
      unauthenticated, so the build never fails on this.
      
      A GitHub Actions secret is encrypted, runtime-only and log-masked (not in the
      public source); neither sync nor deploy runs on fork pull_request, so there is
      no fork-PR exfiltration path. Use a dedicated download-scoped portal key.
      
      Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
      
      ---------
      
      Co-authored-by: fnania <fnania@hex-rays.com>
      Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
      
    10. 🔗 r/LocalLLaMA Leaked financial docs show OpenAI is losing billions of dollars a year rss
    11. 🔗 Console.dev newsletter databow rss

      Description: CLI to query any ADBC database.

      What we like: Run SQL against any ADBC database e.g. DuckDB, BigQuery, Postgres, SQLite. Syntax highlights the query. Output in a table, CSV, JSON, or Apache Arrow. Supports non-interactive queries from the CLI rather than using the TUI.

      What we dislike: Requires an ADBC driver to exist, which means you can’t query some popular databases like MySQL, Clickhouse, etc.

    12. 🔗 Console.dev newsletter Epiq rss

      Description: Issue tracker backed by Git.

      What we like: Manage issues from a TUI, locally-backed by Git so issues live with the code. Works offline and uses append-only events to avoid conflicts (later events take precedence). Uses worktrees to isolate sync from the main dev workflow. Built in kanban board and a web UI.

      What we dislike: The tradeoff is no public web UI for others to view / submit issues.

    13. 🔗 Ampcode News A Faster Librarian rss

      The Librarian is now ~3x faster and 43% cheaper, with the same quality.

      It now runs on GPT-5.5 (no reasoning) with websocket mode and an updated system prompt that encourages more parallel exploration. The Librarian fires ~8 tool calls in parallel per turn, up from ~3 with Sonnet, and wraps up a search in ~5 turns instead of ~15.

      In our internal eval, about a quarter of that speedup comes from OpenAI's websocket mode and the rest from switching to GPT-5.5 with no reasoning:

      Sonnet-4.6 (medium) GPT-5.5 (none)
      Latency (mean) 237s 81s (2.9x faster)
      ↳ gain from websocket ~1.3x
      ↳ gain from model ~2.2x
      Quality (F1, mean) 0.47 0.48
      Average cost $1.21 $0.69

      Here's a comparison:

      How does Kubernetes' HorizontalPodAutoscaler handle missing pod metrics when scaling down — does it assume missing pods are at 100% of their resource requests, or 100% of the target utilization? Cite the function and logic in the source.

      Sonnet 4.6 (left) took 2 minutes and cost $1.08, while GPT-5.5 (right) took 40 seconds and cost just $0.47.

  3. June 17, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-06-17 rss

      IDA Plugin Updates on 2026-06-17

      Activity:

    2. 🔗 Simon Willison GLM-5.2 is probably the most powerful text-only open weights LLM rss

      Chinese AI lab Z.ai released GLM-5.2 to their coding plan subscribers on June 13th, and then yesterday (June 16th) released the full open weights under an MIT license. Similar in size to their previous GLM-5 and GLM-5.1 releases, this is 753B parameter, 1.51TB monster - with 40 active parameters (Mixture of Experts). GLM-5.2 is a text input only model - Z.ai have a separate vision family most recently represented by GLM-5V-Turbo, but that one isn't open weights. GLM-5.2 has a 1 million token context window, up from GLM-5.1's 200,000.

      The buzz around this model is strong.

      Artificial Analysis, who run one of the most widely respected independent benchmarks: GLM-5.2 is the new leading open weights model on the Artificial Analysis Intelligence Index.

      GLM-5.2 is the leading open weights model on the Intelligence Index v4.1. At 51, it leads MiniMax-M3 (44), DeepSeek V4 Pro (max, 44) and Kimi K2.6 (43)

      They did however find it to be quite token-hungry:

      GLM-5.2 uses more output tokens per task than other leading open weights models: the model uses 43k output tokens per Intelligence Index task, up from GLM-5.1 (26k) and above MiniMax-M3 (24k), Kimi K2.6 (35k) and DeepSeek V4 Pro (max, 37k)

      The model is also now ranked 2nd on the Code Arena WebDev leaderboard, behind only Claude Fable 5. That leaderboard measures "front-end web development tasks, including agentic coding workflows". I'm impressed to see it rank so highly given the lack of image input, which I had incorrectly assumed was a key part of building a truly great frontend coding model.

      I've been trying it out via OpenRouter, which has it from 9 different providers, almost all of which are charging $1.40/million for input and $4.40/million for output. For comparison, GPT-5.5 is $5/$30 and Claude Opus 4.5-4.8 is $5/$25.

      Excellent pelican, disappointing opossum

      GLM-5.1 gave me one of my favorite pelicans and my all time favorite opossum (for the prompt "Generate an SVG of a NORTH VIRGINIA OPOSSUM ON AN E-SCOOTER".) Interestingly, in both of those cases the model chose to return SVG wrapped in an HTML document that added additional animations using CSS.

      Let's try GLM-5.2. For "Generate an SVG of a pelican riding a bicycle" I got this:

      It's a really good bicycle - all the right bits, spokes on the wheels, wheels and pedals rotating - and a very good pelican, red scarf, good beak, bobbing up and down. The feet don't stay on the pedals though.

      It's a self-contained fully animated SVG, and the animations aren't broken! Often I'll see eyes falling off or wheels rotating independently of the bicycle but here everything works great. It's a very nice vector illustration of a pelican too. Very impressive.

      Sadly, the NORTH VIRGINIA OPOSSUM ON AN E-SCOOTER did not come out nearly as well:

      Weird background gridlines, scooter is green and not very scooter like, possum is wearing a red safety helmet and has a hairy tail but is hardly recognizable as a possum. It's just bad.

      This is such a step down from GLM-5.1! As a reminder, that possum looked like this:

      This is so great. It's dark, the possum is clearly a possum, it's riding an escooter, lovely animation, tail bobbing up and down, caption says NORTH VIRGINIA OPOSSUM, CRUISING THE COMMONWEALTH SINCE DUSK - only glitch is that it occasionally blinks and the eyes fall off the face

      5.2 didn't even try to animate it.

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

    3. 🔗 r/LocalLLaMA I released Inflect-Nano, an ultra-extreme tiny 4.63m parameter TTS model. rss

      I released Inflect-Nano, an ultra-extreme tiny 4.63m parameter TTS model. | I’ve been experimenting with how small a usable neural TTS model can realistically get, and I just released Inflect-Nano-v1. Inflect-Nano is one of the smallest TTS models, and it performs surprisingly well for its model weight. Even if you have a certified potato computer, it can run on that. It is not SOTA, and I’m not pretending it beats large models. The interesting part is the size-to-functionality ratio: - 4.63M total inference params - 3.46M acoustic model - 1.17M vocoder - 24 kHz audio - English-only, single male voice - Runs locally with a simple PyTorch inference script For comparison, it is ~17x smaller than Kokoro , ~108x smaller than Chatterbox , and almost 1000x smaller than Fish Audio S2 Pro. The quality is still limited: it can sound robotic, stumble on difficult, unseen text, and the vocoder is also a big bottleneck. But for under 5M parameters total, I think it is an interesting baseline for extremely tiny local speech synthesis, offline assistants, embedded devices, browser/WASM-style projects, and local voice agents. Model : https://huggingface.co/owensong/Inflect-Nano-v1 (audio examples in README) I’d love feedback, especially from people interested in tiny models, local voice assistants, efficient inference, or small vocoders. If people find it useful and the model is successful, I'm open to making a v2 with a much larger training budget! submitted by /u/b111ue
      [link] [comments]
      ---|---

    4. 🔗 r/LocalLLaMA We need a 80-160B model urgently. The unified memory device market needs more Models. rss

      Hello guys,
      I will keep myself short.
      There are so many people that have a lot but not enough of "slow" RAM.
      Anybody with a Apple Device with >96GB
      Anybody with a Ryzen AI 395 Device with >96GB
      Anybody with a DGX Spark
      Even people with RTX 6000 Pros or 4x3090s or other configurations.
      Or People with 128GB DDR4/5 RAM

      Yet the models that came out in the last 3 months
      were particulary made for high speed low capacity machines
      (27B Qwen, 31B Gemma)
      or the other extreme, massive models
      (GLM 5.2, Deepseek V4 Pro, Kimi 2.7, Mimo 2.5 Pro, MiniMax M3)

      We people with unified memory devices or other 80-128GB configurations
      have to either use older models that are not great at all currently as the frontier has expanded.
      (Glm 4.5 Air, GPT OSS 120B, Qwen 3.5 122B, Nemotron 3 Super 120B, Qwen 3 Coder Next 80B)

      Or we have to use small models due to our slow bandwidth RAM/VRAM
      (Qwen 3.6 35B or Gemma 4 26B)

      We need something in the range of 100B 10B Sparse. Something that people with a AMD 9700 AI Pro or a Rtx 3090/5090 and 64GB Vram could use. Something that DGX Spark Users, Ai395+, Apple Users, etc.

      Something like Gpt OSS 120B V2, Gemma 4 122B, Qwen 3.6/3.7 122B, GLM 5.2 Air, Deepseek V4 Mini with 100B, Mimo 2.5 Mini with 100B or anything similar to that class of models. Or heck even a Qwen 3.6 Coder 80B would be something people would love.

      I really hope we are gonna get something - else I am left with Qwen 3.5 122B on my Spark for now.

      Cheers.

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

    5. 🔗 r/LocalLLaMA Gemma 4 E2B running in-browser at 255 tok/s using WebGPU kernels written by Fable 5 rss

      Gemma 4 E2B running in-browser at 255 tok/s using WebGPU kernels written by Fable 5 | Before Fable 5 was shutdown, it helped us optimize our Gemma 4 WebGPU kernels, reaching around 255 tokens per second on my M4 Max. Today, we're releasing the demo and kernels for you to try out yourself. Hope you find it interesting! Links:
      - Demo (+ kernels): https://huggingface.co/spaces/webml- community/gemma-4-webgpu-kernels
      - Model: https://huggingface.co/google/gemma-4-E2B-it-qat-mobile- transformers submitted by /u/xenovatech
      [link] [comments]
      ---|---

    6. 🔗 @HexRaysSA@infosec.exchange ⏱️ IDA 9.4 pre-release teasers start now. mastodon

      ⏱️ IDA 9.4 pre-release teasers start now.
      First up: wider processor and platform support.

      The upcoming release adds a Qualcomm Hexagon module, MCore and C-SKY V1, complete AArch64 SVE/SME, improved TriCore analysis with proper calling conventions, and expanded RISC-V coverage including Hazard3/RP2350 and new vendor extensions.

      👉 https://hex-rays.com/blog/ida-9.4-wider-processor-and-platform- support

    7. 🔗 Jessitron Symmathesy and Ai with Kent Beck rss
    8. 🔗 r/LocalLLaMA GLM-5.2 is a win for local AI rss

      I know GLM 5.2's massive 753B footprint means none of us are running it at home without an enterprise cluster, but having a true frontier-level, MIT- licensed coding agent out in the wild makes me optimistic. The distillation potential here is massive. Once the community starts fine-tuning smaller 8B and 70B architectures on GLM 5.2's reasoning and synthetic datasets, our daily driver local setups are going to see huge improvements over the next few months.

      Edit: I did not expect so many people saying they can run it on local hardware. Here is the data spec:

      Quantization Level | Memory Required | Minimum Hardware Setup
      ---|---|---
      FP8 Weights | 744 GB to 890 GB | 8x H200 (141GB) or 8x H100 (80GB) server node
      4-bit (Q4_K_M) | 476 GB to 500 GB | Mac Studio cluster or 6x 80GB enterprise GPUs
      2-bit (Q2_K_XL) | 241 GB to 280 GB | Single 256GB Mac Studio (Ultra) or RTX 4090 + 256GB system RAM
      1-bit Dynamic | 176 GB to 180 GB | 192GB Mac Studio or 24GB GPU + 192GB system RAM

      Model & Dataset Facts

      • Pre-Training Data: Trained on a corpus of 28.5 trillion tokens.
      • Architecture Scale: 753B total parameters, activating roughly 40B parameters per token during inference.
      • Context Capacity: Natively supports a 1,000,000-token context window and up to 131,072 output tokens per response.

      KV Cache VRAM Scaling (Per 100k / 1M Tokens)

      Utilizing the 1M context window requires significant additional VRAM strictly for the KV cache. This scaling depends entirely on your cache quantization:

      • 16-bit (FP16/BF16): Adds 15–20 GB per 100k tokens (~150–200 GB extra for the full 1M context).
      • 8-bit (FP8/INT8): Adds 7.5–10 GB per 100k tokens (~75–100 GB extra for the full 1M context). This balances accuracy and memory.
      • 4-bit (INT4): Adds 3.5–5 GB per 100k tokens (~35–50 GB extra for the full 1M context). Drastically lowers memory requirements but can degrade long-context retrieval accuracy.

      NOTE: I gathered this information online and these are estimates. For full transparency, I did use AI to generate the table and break the data down. I lack the editing patience to format this all myself...I am only human!

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

    9. 🔗 gchq/CyberChef v11.2.0 release

      See the CHANGELOG and commit messages for details.

    10. 🔗 r/LocalLLaMA Local models went from mostly useless to actually useful really fast. What changed? rss

      Local models went from mostly useless to actually useful really fast. What changed? | https://preview.redd.it/knc4ht7bft7h1.png?width=1048&format=png&auto=webp&s=49abdb8b0f358e799ecb06aa49134d9b0fd49336 Mitchell Hashimoto had a good point earlier: local models went from basically useless to actually useful in what feels like one year. I think thats pretty accurate. A year ago I mostly treated local models like toys for privacy, simple chat, or small RAG tasks. Now people are actually using Gemma, Qwen, GLM, Kimi, etc. for coding, private docs, local workflows and even replacing some API calls. I dont think they fully replace the best closed models for long repo work yet. The gap is still obvious when the task needs planning, context, and fixing its own mistakes. But the jump in usable quality feels real. For people running local models every day, what changed the most for you? Better base models, better quants, better tools like llama.cpp/Ollama, more VRAM or something else? submitted by /u/BTA_Labs
      [link] [comments]
      ---|---

    11. 🔗 r/LocalLLaMA GLM-5.2 (max) is currently the third best model available, across both open and proprietary. rss