🏡
  • ↔
  • →
  1. July 08, 2026
    1. 🔗 anthropics/claude-code v2.1.204 release

      What's changed

      • Fixed hook events not streaming during SessionStart hooks in headless sessions, which could cause remote workers to be idle-reaped mid-hook
  2. July 07, 2026
    1. 🔗 apple/embedding-atlas v0.22.0 release

      What's Changed

      New Contributors

      Full Changelog : v0.21.0...v0.22.0

    2. 🔗 BarutSRB/OmniWM OmniWM v0.5.4 release

      What's New Since 0.5.3.2

      • Trackpad workspace swipes now stop cleanly when your fingers stop, while intentional flicks still glide.
      • The workspace bar can now appear only while holding chosen modifier keys, with configurable reveal timing.
      • Focus Previous Window now returns to the last used window even when that window lives on another workspace.
      • Focus changes no longer warp the pointer away when it is already inside the target window.
      • Quake Terminal placement is more resilient across monitor changes, including saved custom positions that no longer fit.
      • Quake Terminal slide-in animations now start from the correct position on offset monitors.
      • Quake Terminal now refreshes its Ghostty surface sizing when revealed on a different monitor, avoiding stale clipped grids.

      Release Integrity

      • OmniWM-v0.5.4.zip contains the Developer ID signed, notarized, and stapled OmniWM app.
      • OmniWM-v0.5.4.zip SHA-256: 7fe334817efb36ec6fac32fdfaa1dcddfa23975226bddb035d1bbf39a817817e
      • GhosttyKit.xcframework-v0.5.4.zip SHA-256: c325c6587230d9190d6b288c6d41cb69589d8aeb74f6be00f7cc2557f017181b
    3. 🔗 anthropics/claude-code v2.1.203 release

      What's changed

      • Added a warning when your login is about to expire, so you can re-authenticate before background sessions are interrupted
      • Added a grey ⏸ badge to the footer when in manual permission mode, making the active mode always visible
      • Added the session's additional working directories to MCP roots/list, with notifications/roots/list_changed sent when the set changes
      • Fixed opening or switching background agent sessions on macOS stalling for 15–20 seconds due to a false low-memory detection (regression in 2.1.196)
      • Fixed background sessions becoming permanently unresponsive to attach, replies, and stop when the daemon's session token went stale — the session now recovers automatically
      • Fixed returning to claude agents silently stopping running subagents and re-running the prompt from scratch — their work now carries over
      • Fixed a memory and per-turn CPU regression in interactive sessions: the context-usage indicator no longer re-analyzes the entire transcript after every turn
      • Fixed background agents inheriting a stale PATH from the daemon instead of the dispatching shell, causing missing tools on Windows
      • Fixed background and agent-view sessions dropping a shell-exported ANTHROPIC_BASE_URL, which sent API keys to the default endpoint and failed with 401
      • Fixed Bash failing with "argument list too long" in repos with many git worktrees
      • Fixed worktree-isolated subagents sometimes running shell commands in the parent checkout instead of their own worktree
      • Fixed worktree creation rejecting nested repositories in multi-repo workspaces, leaving background sessions unable to isolate and edit
      • Fixed background agents crash-looping when their working directory was deleted, replaced by a file, or became an invalid path — they now fail once with a clear error
      • Fixed a background daemon auto-upgrade failure silently killing all running background sessions
      • Fixed TaskStop and TaskOutput failing to find background agents spawned by another agent — errors now list running agents by id and description
      • Fixed the claude agents composer discarding your typed message when a slash command isn't available there
      • Fixed the agent list crashing when opening a stopped session whose conversation was already open in another session
      • Fixed background sessions showing "Needs input" in the agent list after the question was already answered
      • Fixed background agent startup failures showing only "exit_with_message" instead of the actual error
      • Fixed background sessions ignoring effortLevel changes in settings.json when forked through the daemon
      • Fixed attached background sessions ignoring CLAUDE_CODE_DISABLE_MOUSE and CLAUDE_CODE_DISABLE_MOUSE_CLICKS opt-outs
      • Fixed /exit incorrectly warning about running background agents after all named agents had completed
      • Fixed background sessions started from a non-git directory unable to edit files when a WorktreeCreate hook was configured
      • Fixed the @ directory picker in claude agents not showing registered git worktrees
      • Fixed background task output on Windows being permanently replaced by an empty file after /clear
      • Fixed content jumping when scrolling up through long transcript history
      • Fixed the terminal flickering and jumping while typing in bash mode when a shell-history suggestion was shown
      • Fixed literal ^[[I / ^[[O escape codes being printed when reattaching to a background session
      • Fixed LSP-only plugins being incorrectly flagged for disuse when their language servers deliver diagnostics or answer navigation requests
      • Improved responsiveness while long responses stream: live-preview updates no longer re-render the whole screen
      • Improved subagent behavior: agents are now less likely to re-delegate their entire task to another subagent
      • Reduced binary size by ~7 MB and startup memory by ~7 MB by loading a large bundled dependency lazily instead of inlining it
      • Changed left arrow to no longer close the background tasks, diff, and workflow detail views — press Esc instead
      • Changed the empty claude agents view to always show the organized sections (Needs input / Working / Completed) with descriptions
      • Removed the startup "claude command missing or broken" warnings — they now appear in /doctor and /status instead
      • Removed a redundant navigation hint from the claude agents footer
      • [VSCode] Added a Settings toggle for "Enable Remote Control for all sessions"
    4. 🔗 Simon Willison sqlite-utils 4.0, now with database schema migrations rss

      This morning I released sqlite-utils 4.0, the 124th release of that project and the first major version bump since 3.0 in November 2020. In addition to some small but significant breaking changes (described in this upgrade guide), this version introduces three major features: database migrations, nested transactions (via a new db.atomic() method), and support for compound foreign keys.

      Database schema migrations using sqlite-utils

      Schema migrations define a sequence of changes to be made to a SQLite database, plus a mechanism for tracking which migrations have been applied and applying any that are found to be pending.

      Migrations are defined in Python files using the sqlite-utils Python library, which includes a powerful table.transform() method providing enhanced alter table capabilities that are not supported by SQLite's ALTER TABLE statement.

      (table.transform() implements the pattern recommended by the SQLite documentation - create a new temporary table with the new schema, copy across the data, then drop the old table and rename the temporary one in its place.)

      Here's an example migration file which creates a table called creatures, adds an additional column to it in a second step, then changes the types of two of the columns in a third:

      from sqlite_utils import Migrations

migrations = Migrations("creatures")

@migrations()
def create_table(db):
    db["creatures"].create(
        {"id": int, "name": str, "species": str},
        pk="id",
    )

@migrations()
def add_weight(db):
    db["creatures"].add_column("weight", float)

@migrations()
def change_column_types(db):
    db["creatures"].transform(types={"species": int, "weight": str})

      Save that as migrations.py and run it against a fresh database like this:

      uvx sqlite-utils migrate data.db migrations.py

      Then if you check the schema of that database:

      uvx sqlite-utils schema data.db

      You'll see this SQL:

      CREATE TABLE "_sqlite_migrations" (
   "id" INTEGER PRIMARY KEY,
   "migration_set" TEXT,
   "name" TEXT,
   "applied_at" TEXT
);
CREATE UNIQUE INDEX "idx__sqlite_migrations_migration_set_name"
    ON "_sqlite_migrations" ("migration_set", "name");
CREATE TABLE "creatures" (
   "id" INTEGER PRIMARY KEY,
   "name" TEXT,
   "species" INTEGER,
   "weight" TEXT
);

      The _sqlite_migrations table is used to keep track of which migration functions have been run. The creatures table above is the schema after all three migrations have been applied.

      To see a list of migrations, both pending and applied, run this:

      uvx sqlite-utils migrate data.db migrations.py --list

      Output:

      Migrations for: creatures

  Applied:
    create_table - 2026-07-07 17:58:41.360051+00:00
    add_weight - 2026-07-07 17:58:41.360608+00:00
    change_column_types - 2026-07-07 18:01:15.802000+00:00

  Pending:
    (none)

      If you don't specify a migrations file, the sqlite-utils migrate data.db command will scan the current directory and its subdirectories for files called migrations.py and apply any Migrations() instances it finds in them.

      You can also execute migrations from Python code using the migrations.apply(db) method, which is useful for building tools that manage their own database schemas over multiple versions. My own LLM tool has been using a version of this pattern for several years now, as shown in llm/embeddings_migrations.py.

      Prior art

      My favorite implementation of this pattern remains Django's Migrations, developed by Andrew Godwin based on his earlier project South. Fun fact: Andrew, Russ Keith-Magee, and I presented our competing approaches to schema migrations for Django on the Schema Evolution panel at the very first DjangoCon back in 2008! My attempt was called dmigrations, developed with a team at Global Radio in London.

      Django's migrations can be automatically generated from model definitions and include the ability to roll back to a previous version. The sqlite-utils approach is deliberately simpler: unlike Django, sqlite-utils encourages programmatic table creation rather than a model definition ORM, so there isn't anything we can use to automatically generate migrations.

      I decided to skip rollback, since in my experience it's a feature that is rarely used. With a SQLite project, an easy way to achieve rollback is to create a copy of your database file before you apply the migrations!

      Migrating from sqlite-migrate

      The design of sqlite-utils migrations is three years old now - I had originally released it as a separate package called sqlite-migrate, which never quite graduated beyond a beta release.

      I've used that package in enough places now that I'm confident in the design, so I've decided to promote it to a feature of sqlite-utils to make it available by default to all of the other tools in the growing sqlite-utils/Datasette/LLM ecosystem.

      I made one last release of sqlite-migrate, which switches it to depend on sqlite-utils>=4 and replaces the __init__.py file with the following:

      from sqlite_utils import Migrations

__all__ = ["Migrations"]

      Any existing project that depends on sqlite-migrate should continue to work without alterations.

      Everything else in sqlite-utils 4.0

      Here are the release notes for this version, with some inline annotations:

      The 4.0 release includes some minor backwards-incompatible fixes (hence the major version number bump) and introduces three major new features:

      I think of migrations as the signature new feature, hence this blog post.

      sqlite-utils has long had a confused relationship with database transactions, partly because when I started designing the library back in 2018 I didn't yet have a great feel for how those worked in SQLite itself.

      Adding migrations to the core library made me determined to finally crack this nut, since transactions make migration systems a whole lot safer and easier to reason about.

      I ended up building this around a db.atomic() context manager which looks like this:

      with db.atomic():
    db.table("dogs").insert({"id": 1, "name": "Cleo"}, pk="id")
    db.table("dogs").insert({"id": 2, "name": "Pancakes"})

      SQLite supports Savepoints, and as a result db.atomic() can be nested to carry out transactions inside of transactions. It's pretty neat!

      This came about when I asked a coding agent to review all open issues and PRs for things that should be included in a 4.0 release since they would represent breaking changes if I added them later, and it correctly identified that compound foreign keys were exactly that kind of feature.

      I started with a breaking change to the table.foreign_keys introspection method, and then decided to see if Claude Fable 5 could handle the more fiddly job of integrating compound foreign key creation into the library. The API design it helped create felt exactly right to me - consistent with how the rest of the library worked already.

      Other notable changes include:

      • Upserts now use SQLite’s INSERT ... ON CONFLICT ... DO UPDATE SET syntax, detect existing table primary keys automatically and reject records that are missing required primary key values. (#652)

      This was the change that first pushed me to consider a breaking-change 4.0 version bump. I built this to help support sqlite-chronicle, which uses triggers to keep track of rows in a table that have been inserted, updated or deleted.

      • db.query() now executes immediately and rejects statements that do not return rows; use db.execute() for writes and DDL.

      Probably the most disruptive breaking change - I've had to update a few places in my own code to switch from db.query() to db.execute() as a result.

      • CSV and TSV imports now detect column types by default, while inserts into existing tables preserve those tables’ column types. (#679)

      The sqlite-utils insert data.db creatures creatures.csv --detect-types flag was a later addition to allow column types (text, integer, real) to be automatically detected based on the data in a CSV. It should be the default, and releasing a 4.0 means I can make it so.

      • table.extract() and extracts= no longer create lookup table records for all-null values. (#186)

      The oldest issue addressed by this release - the underlying bug was opened (by me) in October 2020.

      See Upgrading from 3.x to 4.0 for details on backwards-incompatible changes.

      The detailed release notes for the features and fixes shipped during the 4.0 pre-release cycle are available in 4.0a0, 4.0a1, 4.0rc1, 4.0rc2, 4.0rc3 and 4.0rc4.

      The upgrade guide was entirely written by Claude Fable 5, Claude Opus 4.8 and GPT-5.5. The same is true of the release notes.

      This is the kind of documentation I've slowly become comfortable outsourcing to the robots. It doesn't need to convince people of anything, or express any opinions - its job is to be as accurate and detailed as possible. I've reviewed the release notes closely and can confirm they are accurate and comprehensive.

      Claude Fable 5 helped a lot

      I released the first alpha of sqlite-utils 4.0 over a year ago. I've been dragging my heels on the stable release because of the amount of work it would take to track down and clean up the many other minor design flaws that a major version number allowed me to take on.

      Assistance from Claude Fable 5 (and to a lesser extent Opus 4.8 and GPT-5.5) gave me just the boost I needed to overcome inertia and make the most of the time I could afford to spend on this library.

      Fable has really good taste in API design, and is relentlessly proactive if you give it a more open goal. My most successful prompt was a review task that I issued against what I thought was the last release candidate:

      review the changes on main since the last tagged 3.x release - I am about to ship them as sqlite-utils 4.0, a stable version that promises no backwards-incompatible fixes for a very long time.

      review the changelog and upgrade guide, and write yourself scratch scripts to try out all of the new features in v4 - save those scripts but don't commit them

      I tried this with GPT-5.5 xhigh in Codex Desktop and Fable 5 in Claude Code.

      GPT-5.5 wrote 5 Python scripts and didn't turn up anything particularly interesting - its final report is here.

      Fable 5 wrote 12 scripts, identified 4 release blockers and 10 additional issues in its report, and built a neat combined repro script, which, when run, output the following:

      === 1. Failed db.execute() write leaves an implicit transaction open ===
  in_transaction after failed write: True
  BUG: table 'other' silently lost when connection closed

=== 2. Leading ';' bypasses the query() first-token scanner ===
  BUG: raised OperationalError: no such savepoint: sqlite_utils_query
  BUG: row persisted despite rollback (count=1)

=== 3. Rejected write PRAGMA via query() still takes effect ===
  BUG: user_version=5 after 'rejected' statement (docs say no effect)

=== 4. Implicit compound FK resolves pk columns in table order, not PK order ===
  BUG: other_columns reported as ('b', 'a'), should be ('a', 'b')
  BUG: transform of valid data raised IntegrityError: FOREIGN KEY constraint failed

=== 5. ForeignKey (now a dataclass) is no longer hashable ===
  BUG: cannot use 'sqlite_utils.db.ForeignKey' as a set element (unhashable type: 'ForeignKey')

=== 6. Mixed ForeignKey objects and tuples in foreign_keys= rejected ===
  BUG: foreign_keys= should be a list of tuples

=== 7. insert --csv into an EXISTING table transforms its column types ===
  BUG: existing zip '01234' is now 1234 (column type: int)

=== 8. insert(pk=, alter=True) regression: InvalidColumns before alter runs ===
  BUG: InvalidColumns: Invalid primary key column ['id'] for table t with columns ['a']

=== 9. migrate --stop-before an already-applied migration applies everything ===
  BUG: m2 was applied despite --stop-before m1 (m1 already applied)

=== 10. ensure_autocommit_on() silently commits an open transaction ===
  BUG: row survived rollback (count=1) - transaction was committed

      I found myself agreeing with almost all of them. Here's the PR with 16 commits where we worked through them in turn.

      There's no doubt in my mind that sqlite-utils 4.0 is a significantly higher-quality release than if I had built it without the assistance of the latest frontier models.

      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.

    5. 🔗 HexRaysSA/plugin-repository commits sync repo: ~15 changed rss 
      sync repo: ~15 changed

No plugin changes detected
    6. 🔗 r/LocalLLaMA I tested Anthropic’s new Jacobian Lens on open models, then it turned into a local-model hallucination router rss

      I tested Anthropic’s new Jacobian Lens on open models, then it turned into a local-model hallucination router | Anthropic dropped their Global Workspace / Jacobian Lens paper yesterday, and I thought it was too cool not to try on open models. At first I was just curious what models looked like inside. Normal prompts, emotional prompts, ragebait prompts, deletion-threat prompts, base vs abliterated, small vs bigger models. So I fit lenses for: - Gemma 4 E4B
      - Gemma 4 12B
      - Gemma 4 12B abliterated
      - Gemma 4 26B MoE
      - Qwen 3.6 27B Repo:
      https://github.com/solarkyle/jspace Demo:
      https://solarkyle.github.io/jspace/demo/ HF lenses/traces/router:
      https://huggingface.co/solarkyle/jspace-lenses Then it turned into a practical question: Can you tell when a small local model is about to confidently BS you? When the model knows the answer, the workspace looks calm. One candidate starts winning early, layers mostly agree, and the answer forms cleanly. When it is about to confidently guess, the workspace looks foggy. Competing candidates stay alive through the middle/deep layers, then the final layer still picks something fluent. I tested this on 500 TriviaQA questions per model. On Gemma E4B, confident answers were: clean workspace = 77% correct
      noisy workspace = 42% correct Then I fit a tiny logistic-regression router on workspace trajectory features: entropy slope, late-band entropy, entropy std, answer rank, layer agreement, etc. AUC for predicting wrong answers: E4B: logprob .711 | workspace .773 | combined .787
      12B: logprob .736 | workspace .824 | combined .843
      12B ablit: logprob .731 | workspace .799 | combined .812
      26B MoE: logprob .725 | workspace .749 | combined .783
      Qwen 27B: logprob .856 | workspace .646 | combined .838 Honest read: This works well on the Gemma models. Workspace features beat output confidence alone on every Gemma model I tested. It does not work universally. Qwen is the miss. Its output confidence is already very well calibrated, and workspace features do not help there. The local-model product idea is: answer locally
      take one workspace snapshot
      tiny router scores risk
      if confident but foggy, escalate to search, citations, or a bigger cloud model The trained routers are uploaded too. The E4B router transfers zero-shot to the other Gemmas at about 0.74-0.78 AUC. The whole thing is just a small logistic regression, which is kind of the point. The biggest E4B router weight is entropy slope. That was interesting to me: the danger sign is not just “foggy,” it is the workspace getting foggier as the model goes deeper. Side finding: fake entities are a different failure mode. Logprobs catch most fake- entity prompts because the model usually knows the name is unfamiliar. But abliteration did something wild. The base 12B fabricated on 17/50 fake entities. The abliterated 12B fabricated on 49/50. Same base weights, very different “I don’t know” behavior. I’m not claiming hidden states, probes, logit lens, or hallucination detection are new. The narrower thing I’m testing is whether Jacobian-lens workspace trajectory features are useful as a one- pass risk signal for confident wrong answers, especially for local-to-cloud routing. If this exact angle already exists, I’d genuinely love pointers. I want to build on the right prior work, not reinvent it badly. Next things I want to test: - real inference overhead in a local serving stack
      - a lightweight router sidecar
      - more model families
      - harder datasets where output confidence is miscalibrated
      - tool-use
      - whether abliterated models lose useful “I don’t know” signals Feedback welcome, especially from anyone doing evals, interp, local inference, or routing. Also, if anyone is working on model honesty, evals, interpretability, or local-to-cloud routing, I’d be happy to talk. This is exactly the kind of work I want to do. EDIT: I'm going to keep running experiments until I run out of compute. Next up: - Gemma 4 31B at Q4 (also curious what quantization itself does to the workspace) - deliberately vague inputs, so I can tell a well-judged guess from a lucky one - agent traces and tool calls, like does it get foggy right before it invents a tool that doesn't exist If you want me to test something just let me know. And if you think I don't know what I'm doing, you're probably right, just correct me if you feel like it. I just love doing this stuff. submitted by /u/RenewAi
      [link] [comments]
      ---|---

    7. 🔗 r/LocalLLaMA Beijing IS NOT looking at curbing overseas access to China's top AI models (Debunking the Reuters report) rss

      The Lie

      Reuters' headline and main narrative: " Beijing is looking at curbing overseas access to China's top AI models ." It portrayed recent Ministry of Commerce meetings as China preparing broad new restrictions on foreign usage of advanced Chinese AI models (including open-weight ones), treating them like a national asset that needs to be locked down from the world.

      The Truth

      The recent meetings (past month) with Alibaba, ByteDance, Z.ai, etc., were primarily about overseas acquisitions, foreign investment, and tech/talent outflow controls and not blocking foreigners from using Chinese AI models.

      Reuters took real meetings on protecting Chinese AI companies and IP from foreign ownership and spun them into a story about restricting model access/usage for the world. They used this document as a "hint" China will restrict their models outside their country but if you read it yourself It tells you a different story.

      The doc shows China wants open source, but they want " trustworthy and controlled" open source. They are trying to solve a specific dilemma: How do we keep flooding the world with free Chinese AI models to crush US tech monopolies, without accidentally letting US venture capital buy up our startups or letting foreign entities reverse-engineer sensitive data from our model weights?

      Scholar Gu Lingyun explicitly warns against over-regulating open weights in the text:

      "If China imposes strict controls on the cross-border flow of open-source weight... the actual effect may only be self-inflicted. Chinese developers will be forced to make a difficult trade-off between compliance and participation

      I encourage people to read the document yourself. It is long but very important to understanding China's strategy on AI going forward.

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

    8. 🔗 @HexRaysSA@infosec.exchange Here's the last IDA 9.4 pre-release teaser... mastodon

      Here's the last IDA 9.4 pre-release teaser...

      We've significantly improved Swift binary analysis. In this blog, we're focusing on two different improvements:
      1️⃣ Proper modelling of the Swift ABI
      2️⃣ Proper typing of Swift runtime functions

      👉 https://hex-rays.com/blog/ida-9.4-improved-analysis-of-compiled-swift- binaries

    9. 🔗 r/LocalLLaMA Beijing is looking at curbing overseas access to China's top AI models (Reuters) rss

      Beijing is looking at curbing overseas access to China's top AI models (Reuters) | Reuters: Beijing is looking at curbing overseas access to China's top AI models, sources say: https://www.reuters.com/world/beijing-is-looking-curbing-overseas-access-chinas-top-ai-models-sources-say-2026-07-07/ submitted by /u/Nunki08
      [link] [comments]
      ---|---

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

## New releases
- [ida-cyberchef](https://github.com/hexrayssa/ida-cyberchef): 0.3.1
  3. July 06, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-06 rss

      IDA Plugin Updates on 2026-07-06

      New Releases:

      Activity:

      • ghidra
        • a3c3eb3d: Merge branch 'GP-0_ryanmkurtz_PR-9339_GregoryMorse_external-names'
        • 91fd2f52: Add IDA-PRO external names for AARCH64
        • 123fb4ee: Merge remote-tracking branch 'origin/GP-0_Dan_fixTests-2026-07-06-1'
        • fc8288b6: GP-0: Fix tests.
        • 20e37d96: Merge remote-tracking branch 'origin/GP-0-dragonmacher-test-fixes-7-1…
        • 0974e194: Merge remote-tracking branch 'origin/GP-7037_ryanmkurtz_CompactObject…
        • db039107: Merge remote-tracking branch
        • ff35b62e: Merge remote-tracking branch 'origin/GP-7026_ghidra_PointerAddressErr…
        • a836637a: Merge remote-tracking branch 'origin/GP-6999-dragonmacher-fid-action-…
      • ida-domain
        • dc8628b9: Add CI check for deprecated IDA functions (#94)
      • ida-llm-explainer
        • 1d5c26cd: Generalize per-edge narrowing to same-flag retests; fix store metadat…
      • IDA-MCP
      • ida_rpc
      • rikugan
        • f0f8c3c3: docs(qt): soften single-seam claim + restore Unicode ≥ in qt_compat d…
        • dee19e6c: chore(release): bump version to 1.8.0
        • 785e97db: docs: document PySide6-only / IDA ≥ 9.0 requirement
        • 2d35450a: refactor(qt): drop PyQt5 detection — PySide6 only
        • 62ea0e42: test(qt): rewrite symbol-provenance check as source-level assertion
        • 70a6054e: test(qt): rewrite qt_compat tests for PySide6-only surface
        • b8aafce3: refactor(tests): drop PyQt5 fallback in conftest qapp import
        • e658c88a: refactor(ida-ui): tools_form OnCreate uses FormToPySideWidget only
        • 230e4660: docs(test): refresh stale OnCreate path docstring after Task 5 branch…
        • 58051fd7: refactor(ida-ui): OnCreate uses FormToPySideWidget only
        • bd74d503: refactor(ui): inline qt_flags in message/tool widgets
    2. 🔗 anthropics/claude-code v2.1.202 release

      What's changed

      • Added a "Dynamic workflow size" setting in /config for controlling how large Claude generally makes dynamic workflows (small/medium/large agent counts) — an advisory guideline, not an enforced cap
      • Added workflow.run_id and workflow.name OpenTelemetry attributes to telemetry emitted by workflow-spawned agents, so a workflow run's activity can be reconstructed from OTel data
      • Fixed a crash in the inline Ctrl+R history search when accepting or cancelling while the search was still scanning the history file
      • Fixed /rename on background sessions being reverted when the job restarts, which broke addressing the session by its new name
      • Fixed transient mTLS handshake failures when settings were re-applied during an in-place client certificate rotation
      • Fixed commands sent from Remote Control (mobile/web) into an interactive session failing with "Unknown command"
      • Fixed images and files sent from the Remote Control mobile or web app without a caption being silently dropped
      • Fixed the sign-in URL printed by claude auth login and claude mcp login --no-browser not being reliably clickable when it wraps over SSH — it is now emitted as a single hyperlink
      • Fixed opening a chat from claude agents sometimes failing with "currently running as a background agent" followed by a worker crash/respawn loop
      • Fixed workflow scripts with unicode quote escapes in strings being corrupted before parsing; workflow parse errors now show the offending line instead of always blaming TypeScript
      • Fixed voice dictation retrying in an unbounded loop when the microphone or audio recorder fails — repeated capture failures now pause voice input
      • Fixed /remote-control sessions showing the wrong permission mode in the mobile and web apps
      • Fixed resuming a session by name, or opening the resume picker, taking minutes and using a large amount of memory in repositories with many git worktrees
      • Fixed installer and updater downloads failing immediately with "aborted" when a proxy or network drops the connection mid-download — transient connection drops now retry
      • Fixed re-invoking an already-loaded skill appending a duplicate copy of its instructions to context
      • Improved /workflows agent list layout: wider titles, a dedicated time column, shorter model names, and no per-row tool-call counts
      • Improved MCP error messages: clearer error when a server config has url but no type, suggesting "type": "http" instead of the misleading "command: expected string"
      • Changed /review <pr> back to a fast single-pass review; use /code-review <level> <pr#> for the multi-agent review at a chosen effort level
    3. 🔗 HexRaysSA/plugin-repository commits sync repo: +1 plugin, +1 release rss 
      sync repo: +1 plugin, +1 release

## New plugins
- [llm-explainer](https://github.com/pgarba/ida-llm-explainer) (1.3.0)
    4. 🔗 backnotprop/plannotator PR #957 automated browser-test recordings release

      Playwright recordings of the parity suite run against the compiled plannotator binary from PR #957 head 849fda4. Hosted here because PR comments cannot take file attachments via API. Safe to delete after #957 merges.

    5. 🔗 r/LocalLLaMA So... anyone copped one of these? rss

      So... anyone copped one of these? | Been almost a year since mass hysteria erupted upon the death of NVIDIAs GPU monopoly. How are your Huawei GPUs? Does CUDA work on them yet? submitted by /u/entsnack
      [link] [comments]
      ---|---

    6. 🔗 MetaBrainz Current ListenBrainz server issues/high load, Part 2 rss

      This follow-up post covers how and why our servers are still being impacted, an explanation and examples of what we consider "botting" in ListenBrainz - and an apology, because our last post had some baaad comms!

      Firstly, we are still experiencing massive server load from an increase in listen submissions related to the BTS fan exodus from last.fm (not all bad! more on this below) - and we are now being hit by another influx of AI scrapers.

      Our apologies to our users, new and old, as we continue to work to mitigate the extra load. Remain assured that listens are not being lost - our processing queue is lagging behind, so listens may take (up to) hours to appear.

      LB radio and the popularity endpoints have been temporarily disabled, to reduce server load.

      ListenBrainz server status/load

      Our ingestion queue for the past 2 weeks.

      The above screenshot shows our ingestion queue (listens being submitted directly to ListenBrainz) for the past 2 weeks, which usually sits around 0 with peaks at 10K. The highest peak during the last two weeks - the big mountain on the graph - is 484K. That is to show both that the listens are not lost and why they were lagging behind. " Your listen is now number 484,001 in line…"

      Our import queue for the past 2 weeks.

      The above screenshot shows our import queues (listens being submitted via our import function), in the same 2-week window. The values are "number of listens added to the ingestion queue per minute ". The purple line is lastfm imports. We usually sit around 1-2K, with peaks around 20K sustained for ~3 hours at worst. The peak in this graph is 180K - that's 180K listens added to the queue that minute. These values have not been reducing at the time of writing, but fluctuating depending on time of day.

      You can see these graphs, and the current length of the 'queue', in real-time on this Grafana dashboard (free account required).

      Where this increased load is coming from

      Our server issues are currently three-fold. One is good, the other two not so much.

      • Last.fm imports : This is the good problem! When a user syncs their account from last.fm, they're sometimes importing 20 years worth of listens at a time. Every listen that is added to ListenBrainz passes through our listen queue, where our system checks the attached metadata, and tries to match it to the right artist, album and song. As you can imagine, if hundreds or thousands of users add their entire last.fm history at once, it's quite the processing queue. This load is a sign that we are growing, and we don't mind at all. Though we also don't enjoy having to wait for listens to appear - if anyone wants to gift us some extra servers….

      • " Botting"/listen submission spamming: This is not good. A very small minority of BTS fan accounts are doing things like submitting a listen every few seconds, and/or submitting listens across multiple accounts at once, which has resulted in hundreds of thousands of extra listens being added to the queue. This goes against our code of conduct. Please scroll down to the end of this blog post for clarification on what behaviour that we consider botting.

      • AI scrapers : There's not much to say here. The MetaBrainz foundation offers all of our data as freely downloadable datasets, but these AI companies don't care - they set up scrapers to blindly hoover up the internet without respecting limits or ethical considerations. They go to great lengths to hide behind thousands of residential IPs, making them extremely difficult to detect and block (as blocking these IPs also blocks legitimate users). You can read more in our previous blog on the subject: We can’t have nice things… because of AI scrapers

      Bad comms!

      We - the MetaBrainz team - are very sorry for how our last post was written, and how it negatively affected so many people.

      We are used to speaking to a small audience of our existing users, and we have a wonderful BTS/K-pop community in *Brainz already, which made us be too relaxed with our tone.

      It is true that a small minority of fans recently started doing things like submitting a listen every few seconds, across many accounts, which has impacted our service for all users. But we <3 our K-pop community! So we never imagined that it would be thought that we are blaming all the fans of a band or even a whole genre. But that is not obvious from outside our small community and usual readership, and that is our mistake and something we should have considered before posting.

      We are a small team, and most of us are very… technically minded. We do not have a comms team, and will probably never have one, so we ask for you to be patient with us.

      On the other side of the coin, we had to filter a lot of abusive comments from the last blog post (both from ARMY and directed towards ARMY) and that is not the sort of community we are fostering here. We also are, and will continue to be, direct and up-front with our messaging, in accordance with our open ethos. If a group of users - even if it's a non-representative subset of a larger group - are not respecting our rules and are causing issues for everyone, we will say so, and we will __ share how and why. We will endeavour to do this with tact and awareness (which we failed to do in our last post).

      If that works for you, and the respect is shared both ways - welcome, new users! And if you are a BTS fan, congratulations on the new album release, and we look forward to seeing it continue to explode the global charts.

      What we consider 'botting'/bad behaviour in ListenBrainz

      First, please note that when we say "botting", we don't mean that the listener is not a real human! It refers to using digital tools/code/devices to submit song listens that don't reflect real listening.

      We also want to acknowledge that this might be counter to how some people want to submit and store listens, and may not match everyone's definition of 'real listening'. We are sorry that our systems cannot cater to every approach. We think it's awesome that the BTS community has their own app, B-CD, that caters to users who want to listen-max their love for BTS! We love to see it!

      The following are (just some) examples of what we consider unacceptable in ListenBrainz.

      • Submitting listens you haven 't listened to: If you are submitting a 1 minute song as 'listened' every 5 seconds, or any other timeframe that is far shorter than the song itself, we are likely to disable your account. We have paused 100 accounts doing this, so far, with the 'busiest' submitting 6,000+ listens a day for a few days - a full song 'listened to' every ~15 seconds, day and night. This adds up.

      • Submitting the same listens across multiple accounts/devices: Our systems expect 1 song submitted listen to equal 1 song going into your earballs. Having multiple accounts/devices each submitting the same listen doesn't get around this! If you are doing this we are likely to disable your accounts.

      • Doing both of the above at a large scale: "Ahhhhhhhhhhhhhhhhhhhhhhhh" - our servers.

      tl;dr if your 1 listen is becoming 2 or more listen submissions in ListenBrainz, in any way, it's likely that your account will be disabled. If you email us we are always happy to look at the situation and to reinstate accounts for people who agree to follow the ListenBrainz rules. Our apologies that we cannot proactively email everyone who we disable at this time, we are dealing with too many accounts to do so.

      If you read all the way down here, thank you and have a lovely week - your MetaBrainz and ListenBrainz team.

    7. 🔗 r/LocalLLaMA Qwen & Gemma on deadlock situation (For Benchmarks Numbers)? rss

      Qwen & Gemma on deadlock situation (For Benchmarks Numbers)? | I have this feeling for sometime. Also noticed few similar tweets online before. submitted by /u/pmttyji
      [link] [comments]
      ---|---

    8. 🔗 benji.dog rss

      4 kids sitting in the bucket of a cargo bike riding down a street with cars and other bikes around

      Took the whole crew on a geocaching adventure

    9. 🔗 r/LocalLLaMA New open model from Tencent Hy: Hy3 (295B total 21B active - apache 2.0) rss

      New open model from Tencent Hy: Hy3 (295B total 21B active - apache 2.0) | Collection: https://huggingface.co/collections/tencent/hy3 From elie on 𝕏: https://x.com/eliebakouch/status/2074011171661701466 edit: To clarify: this is the non-preview version of Hy3 and they changed their license from the community one (restrictive + not allowed in SK, UK, EU) to Apache 2.0 submitted by /u/Nunki08
      [link] [comments]
      ---|---

    10. 🔗 mwemuorg/mwemu map files release

      These are the maps for 32bits and 64bits.
      if you are using the library from crates.io it needs these maps.

      Better clone repo and get maps from there.

      The Makefile is prepared to download this test.zip and perform cargo tests just doing make tests.

    11. 🔗 r/LocalLLaMA If trends hold, Mythos-class capability may be running on high-end consumer hardware within ~2 years rss

      If trends hold, Mythos-class capability may be running on high-end consumer hardware within ~2 years | submitted by /u/PetersOdyssey
      [link] [comments]
      ---|---

    12. 🔗 exe.dev Building Software From My Phone rss

      My little town of San Anselmo has a delightful live music concert series in the summer. What they don’t have is a website that is easy to read on my phone.

      I was on vacation when this summer’s schedule posted–and I had intentionally left my laptop at home.

      My first instinct was to ask ChatGPT to paw through and organize a schedule to my tastes, but recently I’ve noticed that farming out such tasks to Pro is lossy. I’d say it lacks serendipity, but it’s more than that. My preferences may appear superficial (bluegrass, please), but in reality, none of us are quite so reducible. Our opinions are complex and only coarsely approximated by what we might think to tell an agent.

      So instead, I pulled out my phone, opened the exe.dev iOS app, created a new VM, and said to Shelley:

      https://www.liveontheavenue.org please organize and analyze all of the events, movies, and bands. Add times and genres to each. Turn the whole thing into a simple, compact calendar that I can browse and scroll through on a single page. Use subagents to confirm band genres. Add a genre filter at the top, maybe a dropdown with checkboxes? Mobile-friendly.

      A few minutes later I had https://live-on-the-avenue.exe.xyz/ up and running. And it turns out the band I’m most excited for is listed under ska and klezmer.

      Sow on the Go

      The curse of having an interesting job is that you think about it all the time. I used to send myself a dozen emails a day with ideas and tasks and bug reports. Each of these was a seed for some work, to be completed later at a computer. Now that my development environment lives on exe.dev VMs, I plant these on the go.

      Because I hate typing on my phone, I added high-quality transcription to the exe.dev iOS app. In addition to being more pleasant than typing, it’s also faster. And, because I’m talking, I naturally provide more content and context, which lends itself to better results.

      For many tasks, reaping and/or weeping (reviewing, testing, deciding what’s actually good) still ultimately requires a laptop. But kicking off work no longer means routing it through tedious, intermediate steps.

      Voice Triage

      At any given point, some of my agents are working, some are blocked on trivial stuff, and some need my serious, sustained attention.

      I can now burn through the trivial stuff rapidly from my phone while taking a walk, getting some sunlight, or tidying the house. I put in my headphones, start up real time voice mode, and work through outstanding Shelley conversations: respond, archive, spin up a new thread, leave for later, repeat. It’s less efficient than staring at my phone, but far more pleasant, and worth the change of pace.

      I’ll write more about voice mode in a future post.

      Share Sheets

      exe.dev has been available on mobile web for ages. (OK, fine, months. Feels like ages.) There were really two key features that drove us to start an iOS app, features that we simply could not ship in the browser. The first was notifications; the second was the share sheet.

      The share sheet lets you send screenshots, files, videos, and more to Shelley on an exe.dev VM. Sending a screenshot of a visual bug is so, so much better than describing it.

      My personal favorite use of the share sheet is for transcriptions.

      When I have a substantial new feature I want to design or a blog post I want to draft, I open up Voice Memos on iOS and talk it out, often for the better part of an hour. I have a VM configured with a Deepgram and a Voxtral integration, and a rich agents.md that teaches it how to do transcriptions. (TL;DR: Wait for a file to appear, fan out text-to-speech to both providers, merge the results, clean up disfluencies, recognize common homophones of “exe.dev” and “VM”, trim redundant content, and email me the results, all while preserving word choice and structure.) Once I’m done recording, it’s a few taps–and zero typing–to dispatch the audio file to my transcription exe.dev VM; the result lands later in my inbox.

      As with so many things I use exe.dev for, there are third- party services that do much of this, but they do it clumsily, or in a way that requires me to do a lot of pre- or post-work, or in a way that doesn’t integrate well with the rest of my cobbled-together digital life. Making it trivial to share stuff into an exe.dev VM has been a major unlock.

  4. July 05, 2026
    1. 🔗 IDA Plugin Updates IDA Plugin Updates on 2026-07-05 rss

      IDA Plugin Updates on 2026-07-05

      Activity:

    2. 🔗 HexRaysSA/plugin-repository commits Update known-repositories.txt rss 
      Update known-repositories.txt
    3. 🔗 r/LocalLLaMA I developed a 270 million parameter language model entirely from scratch as an independent research project rss

      I developed a 270 million parameter language model entirely from scratch as an independent research project | The model is built on a custom Transformer architecture featuring Rotary Positional Embeddings, RMSNorm, SwiGLU feed forward layers, grouped query attention, and an efficient autoregressive decoder optimized for local inference. Here is the Huggingface Spaces Demo link - https://huggingface.co/spaces/pranavupadhyaya52/WikiSmartBot For anyone interested in the pretraining notebook, I've shared the link here - https://colab.research.google.com/drive/1cxRLxUPX_mT4nst-0xGdhctEdqdIlMDb?usp=sharing submitted by /u/ConfectionAfter2366
      [link] [comments]
      ---|---

    4. 🔗 backnotprop/plannotator v0.22.0 release

      Follow @plannotator on X for updates

      Missed recent releases? Release | Highlights
      ---|---
      v0.21.4 | Markdown math rendering, PR Overview panel with annotatable description and comments, agent instructions in code review, media parsing fixes
      v0.21.3 | File comments in code review, unified click-to-highlight comments, VS Code clipboard/keyboard bridge, Codex Ask AI on app-server transport, CLI subcommand help
      v0.21.2 | Custom reviews as Agent Skills, Cursor + OpenCode review engines, whole-file/general findings, deleted-annotation fix, Codex Ask AI outside git repos
      v0.21.1 | Annotate-last blank-page fix on multi-message sessions
      v0.21.0 | Direct document editing in annotate mode, live git-status file tree, in-app agent terminal, open files in external apps, HTML renders as HTML
      v0.20.3 | Annotations no longer lost when clicking away, off-screen indicator for open comments
      v0.20.2 | Pierre CodeView all-files review, large-PR pipeline and instant-open checkout, unified agent engine selection, Pi programmatic plan mode
      v0.20.1 | Pi extension install hotfix (pinned @pierre/diffs after a broken upstream release)
      v0.20.0 | Multi-repo workspace reviews, semantic diff overview, UI 2.0 themes and plan look chooser, leaner single-source skill install
      v0.19.27 | Kiro CLI integration, Glimpse native window, annotate-last message picker
      v0.19.26 | Amp plugin production fixes, Mermaid rendering fix, Settings flicker fix, update notification toast and shimmer

      What's New in v0.22.0

      This release rebuilds the code review left panel around how a review actually starts: a git-status view of everything since your base branch is now the default, a Commits panel gives you the branch's history with per-commit diffs, and Guided Review turns any changeset into an agent-organized, chaptered walkthrough with live annotatable diffs. Pi and GitHub Copilot CLI join Cursor and OpenCode as review engines. Five PRs and four direct fixes land, all from the core team, verified by a 24-point QA pass before tagging.

      The review now opens on "All changes"

      Code reviews used to open on unstaged changes, which answers "what did I just edit" but not the question most reviews start with: "what would a PR show if I pushed right now?" The new default diff answers exactly that. All changes compares the merge base with your base branch against the working tree and includes untracked files — committed work, uncommitted edits, and brand-new files in one view.

      It renders as a Git status panel with three sections that mirror git status: Committed , Changes , and Untracked. Each row carries viewed tracking, a stage/unstage button, the change-type letter, and +/- counts, so you can stage files as you review without leaving the app. If the base branch has moved on GitHub since your last fetch, a banner offers a one- click fetch so you're reviewing against the real base.

      A first-run dialog lets you pick your default view and diff type (with live previews), and both remain changeable in Settings → Git or from the review header menu. On repos where a base branch can't be resolved, the review falls back to uncommitted changes rather than hiding committed work.

      PR #990, by @backnotprop.

      Commits panel

      The panel toggle gained a third view: Commits , a linear history rail of your branch, newest first, with author avatars and an "In origin/main" divider where your work meets the base. Clicking a commit opens that commit's own diff against its parent — git show, but annotatable — headed by the full commit message rendered as markdown.

      The toggle is session-scoped: glancing at Commits (or Tree) mid-review never silently changes your saved default, and a review always opens on files, never on a historical commit. Avatars resolve by author email through the repo's forge and fall back to initials when there's no remote or CLI to ask.

      PR #994, by @backnotprop.

      Guided Review

      Large changesets are hard to review top-to-bottom in file order. A Guided Review has an agent organize the current changeset — any PR or local diff — into importance-ordered chapters: the heart of the change first, its consequences next, glue last. Each section pairs a prose overview and per-file summaries with the live diffs it covers, and those diffs are the real diff viewer — annotations made inside a guide land in the same review state and export in the same feedback as everywhere else.

      Open it with the Guide button in the review header or Mod+Shift+G, pick an engine and model, and generate. Sections track their own reviewed state so you can work through a big change across sittings. Guides run on Claude or Codex natively, and on Cursor, OpenCode, Pi, or GitHub Copilot CLI when installed. Every changed file is validated against the real diff server-side, so a guide can never invent files or drop them silently.

      A one-time intro dialog announces the feature on first open, and the Guide button carries a subtle hint until the first time you use it.

      PRs #993, #997, and #1000, by @backnotprop.

      Pi and GitHub Copilot CLI as review engines

      The review and guide launchers gained two engines. Pi rides your existing Pi login (OAuth subscription or keys) with live model discovery and thinking- level control — and the Pi extension can launch Pi, so Pi users get agent reviews with zero extra setup. GitHub Copilot CLI runs in a locked-down non-interactive posture: no write access, a shell allowlist limited to git- family commands, and clean auto-denial for anything else.

      That brings the engine roster to Claude, Codex, Cursor, OpenCode, Pi, and Copilot — and the engine layer was refactored so the next one is a two-edit change.

      PRs #993 and #997, by @backnotprop.

      Additional Changes

      • Filenames stay visible in the Git status panel — long paths now truncate in the directory portion (ellipsis before the final slash) so the filename always shows; a pathologically long filename truncates at its own end.
      • Commit-diff annotations stay anchored to their commit — annotations made on a historical commit's diff are stamped with that commit, and the exported feedback labels any annotation whose anchor doesn't match the diff being sent, so an agent never reads a commit's line numbers against the working tree.
      • Avatar lookups can't delay the commit list — forge avatar resolution now has a hard 4-second ceiling; on a hanging network the Commits panel loads immediately with initials and picks up avatars once they arrive.
      • Code review reference docs updated — the docs page now describes the since-base default, the three panel views, Guided Review, the full engine roster, and the current server API.

      Install / Update

      macOS / Linux:

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

      Windows:

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

      Extra skills (compound, setup-goal, visual-explainer), opt-in:

      npx skills add backnotprop/plannotator/apps/skills/extra

      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

      Droid: Install via the plugin marketplace:

      droid plugin marketplace add backnotprop/plannotator
droid plugin install plannotator@plannotator

      Amp: Install the CLI first, then copy the plugin:

      mkdir -p ~/.config/amp/plugins
curl -fsSL https://raw.githubusercontent.com/backnotprop/plannotator/main/apps/amp-plugin/plannotator.ts \
  -o ~/.config/amp/plugins/plannotator.ts

      Kiro CLI: The installer auto-detects Kiro and installs skills automatically. After installing the CLI, launch with:

      kiro-cli chat --agent plannotator

      Upgrading from before v0.20.0? Read the v0.20.0 release notes first; that release changed how skills install.

      What's Changed

      • feat(review): "All changes" git-status review view by @backnotprop in #990
      • feat(review): Commits panel — linear history rail with per-commit diffs by @backnotprop in #994
      • feat(review): Guided Review + Pi agent-job provider by @backnotprop in #993
      • feat: guide per-file summaries + GitHub Copilot CLI agent engine by @backnotprop in #997
      • feat(review): Guided Reviews intro dialog + Guide button discovery hint by @backnotprop in #1000
      • fix(review): keep the filename visible in git-status rows by @backnotprop
      • fix(review): anchor commit-diff annotations to their commit in feedback by @backnotprop
      • fix(review): avatar lookups can no longer delay /api/commits by @backnotprop
      • docs(marketing): bring the code-review reference up to the since-base era by @backnotprop

      Full Changelog : v0.21.4...v0.22.0

    5. 🔗 r/LocalLLaMA longcat 2.0 (1.6T, ~48B active) weights are now open under MIT license rss

      longcat 2.0 (1.6T, ~48B active) weights are now open under MIT license | From: elie on 𝕏: https://x.com/eliebakouch/status/2073690402503487902 ModelScope on 𝕏: https://x.com/ModelScope2022/status/2073710226365165679 Technical blog post (June, 30): https://longcat.chat/blog/longcat-2.0/ submitted by /u/Nunki08
      [link] [comments]
      ---|---

    6. 🔗 r/LocalLLaMA I benchmarked 13 models at 65K-128K context to find out what actually matters for agentic workloads rss

      I benchmarked 13 models at 65K-128K context to find out what actually

      matters for agentic workloads — prefill dominates everything, and KV head count beats parameter count

      I've been running local LLMs for agentic workflows (tool use, coding agents, RAG) and kept seeing people obsess over tg128 (token generation speed) as the headline performance metric. So I ran a structured long-context benchmark to figure out what actually matters when your context window is full. The answer surprised me.

      Setup

      • GPU : RX 7900 XT 20GB (Vulkan backend, RADV/Mesa)
      • Backend : llama.cpp / llama-bench (build 9860)
      • Flags : -ngl 99 (GTT spill), -fa on, -ub 2048 -b 16384, ASPM=performance, bare TTY to free VRAM
      • 13 models : 5 dense, 6 MoE, 1 Mamba2 hybrid, 1 MLA MoE — ranging from 5GB to 18GB
      • 3 KV cache tiers : Q8_0 K / Q4_0 V (aggressive), Q8_0 K / Q8_0 V (symmetric), F16 (baseline)
      • Context sizes : 512, 4K, 16K, 65K, 131K — both pure prefill (pp) and prompt+gen (pg)
      • Full run took ~21 hours across two sessions

      Full prefill speed results (Q8_0 K / Q8_0 V KV cache, tokens/sec)

      If you just want the raw numbers, here's every model tested. pp = pure prompt processing (prefill), tg128 = token generation (decode). Sorted by pp131K.

      Model | Size | Type | pp512 | pp4K | pp16K | pp65K | pp131K | tg128
      ---|---|---|---|---|---|---|---|---
      Trinity-Mini | 16G | MoE 3B/26B | 2639 | 2924 | 2370 | 1419 | 923 | 150
      Granite-4.0-H-Small | 17G | Mamba2+MoE | 1115 | 1271 | 1220 | 1043 | 875 | 71
      Ornith-9B / Qwen3.5-9B | 6G | Dense | 2103 | 2220 | 1943 | 1274 | 873 | 92
      Qwen3.6-35B-A3B | 18G | MoE 3B/35B | 2184 | 2736 | 2227 | 1268 | 802 | 110
      Gemma-4-26B-A4B | 14G | MoE 4B/26B | 2523 | 2798 | 2076 | 1024 | 600 | 119
      North-Mini-Code | 15G | MoE 3B/30B | 2155 | 2187 | 1568 | 900 | 579 | 134
      Gemma-4-12B | 7G | Dense | 1492 | 1498 | 1145 | 595 | 350 | 66
      Qwen3.6-27B | 16G | Dense | 693 | 681 | 602 | 406 | 285 | 32
      Granite-4.1-8B | 5G | Dense | 1965 | 1807 | 1124 | 442 | 244 | 93
      Ministral-3-14B | 8G | Dense | 1419 | 1325 | 916 | 404 | 232 | 67
      Apriel-1.6-15B | 9G | Dense | 1332 | 1208 | 812 | 347 | 197 | 66
      Devstral-24B | 15G | Dense | 829 | 796 | 628 | 313 | --- | 42
      GLM-4.7-Flash | 16G | MoE (MLA) | 1822 | 1054 | 358 | --- | --- | ---

      A few things to note: Devstral-24B couldn't complete the 131K test (8 KV heads × 128 dim = 160 KB/token — KV cache alone is ~21GB at 131K). GLM-4.7-Flash crashed above 16K (MLA issue, see Finding 5). Ornith-9B is architecturally identical to Qwen3.5-9B.

      Finding 1: At 65K+ context, prefill is 94–99% of wall-clock time. tg128 is nearly irrelevant for short agentic outputs.

      Here's the wall-clock breakdown for a real agentic query — 65K context in, 300 tokens out (typical tool-use response). Sorted by total time:

      Model | Type | Prefill | Decode | Total | Prefill %
      ---|---|---|---|---|---
      Trinity-Mini (MoE 3B/26B) | MoE | 46.2s | 2.0s | 48.2s | 96%
      Qwen3.6-35B-A3B (MoE) | MoE | 51.7s | 2.7s | 54.4s | 95%
      Ornith-9B / Qwen3.5-9B | Dense | 51.4s | 3.3s | 54.7s | 94%
      Gemma-4-26B-A4B (MoE) | MoE | 64.0s | 2.5s | 66.5s | 96%
      Granite-4.0-H-Small (Mamba2) | Mamba2 | 62.8s | 4.2s | 67.1s | 94%
      North-Mini-Code (MoE) | MoE | 72.8s | 2.2s | 75.0s | 97%
      Gemma-4-12B | Dense | 110.2s | 4.5s | 114.7s | 96%
      Granite-4.1-8B | Dense | 148.4s | 3.2s | 151.6s | 98%
      Qwen3.6-27B | Dense | 161.4s | 9.3s | 170.7s | 95%
      Ministral-3-14B | Dense | 162.0s | 4.5s | 166.5s | 97%
      Apriel-1.6-15B | Dense | 188.9s | 4.6s | 193.5s | 98%
      Devstral-24B | Dense | 209.5s | 7.2s | 216.6s | 97%

      Decode is 1–5% of the time you actually wait. If your agent makes a short tool call or writes a brief response, the only thing that matters is how fast you can process the context window.

      This means benchmark reports that lead with tg128 are misleading for agentic use cases. pp65K / pp131K is the metric that matters. The pg(prompt, gen) blended metric is better but still obscures the split — a model with fast prefill + catastrophically slow decode can look mediocre on pg despite being excellent for short outputs.

      Finding 2: KV head count is the dominant architectural factor for long- context prefill — not parameter count, not MoE vs dense

      Prefill speed retention (% of pp4K speed) at increasing context, all models:

      Model | Size | KV Heads | pp4K | 16K | 65K | 131K | Type
      ---|---|---|---|---|---|---|---
      Granite-4.0-H-Small | 17G | Mamba2 | 1271 | 96% | 82% | 69% | Mamba2+MoE
      Qwen3.6-27B | 16G | 4×256 | 681 | 88% | 60% | 42% | Dense
      Ornith-9B / Qwen3.5-9B | 6G | 4×128 | 2220 | 87% | 57% | 39% | Dense
      Trinity-Mini | 16G | 4×128 | 2924 | 81% | 49% | 32% | MoE
      Qwen3.6-35B-A3B | 18G | 4×128 | 2736 | 81% | 46% | 29% | MoE
      Gemma-4-12B | 7G | 8×128 | 1498 | 76% | 40% | 23% | Dense
      Gemma-4-26B-A4B | 14G | 4×256 | 2798 | 74% | 37% | 21% | MoE
      North-Mini-Code | 15G | 4×128 | 2187 | 72% | 41% | 26% | MoE
      Apriel-1.6-15B | 9G | 8×128 | 1208 | 67% | 29% | 16% | Dense
      Ministral-3-14B | 8G | 8×128 | 1325 | 69% | 31% | 18% | Dense
      Granite-4.1-8B | 5G | 8×128 | 1807 | 62% | 24% |       14% | Dense
      Devstral-24B | 15G | 8×128 | 796 | 79% | 39% | --- | Dense
      GLM-4.7-Flash | 16G | MLA (1×576) | 1054 |       34%* | --- | --- | MoE (MLA)

      __ Granite-H-Small has 4 attention layers + 36 Mamba2 layers (recurrent state, no KV cache)*

      Ornith-9B / Qwen3.5-9B (9B dense, 4 KV heads × 128 dim = 64 KB/token KV) is 4.4× faster at 128K context than Apriel-15B (15B dense, 8 KV heads × 128 dim = 160 KB/token) — despite being the same dense class and half the size. The difference is purely KV cache architecture. Every attention pass has to scan the full KV cache, and 8 KV heads means 2.5× more data to scan per token.

      Practical rule : When evaluating a model for long context, check n_kv_heads and head_dim in the config before looking at parameter count. Two models from the same family can differ by 3–4× at 128K if one has 4 KV heads and the other has 8.

      Finding 3: Mamba2 hybrid models have near-flat prefill scaling. The architecture actually delivers.

      I was skeptical of the Mamba2 hype, but the data is clear. Granite-4.0-H-Small (IBM, 4 attention layers + 36 Mamba2 layers) retains 69% of its pp4K speed at 131K context — every transformer model in the test dropped below 42%.

      Model | pp4K | pp131K | Slowdown
      ---|---|---|---
      Granite-H-Small (Mamba2) | 1271 | 875 | 1.45×
      Trinity-Mini (MoE) | 2924 | 923 | 3.2×
      Ornith-9B / Qwen3.5-9B (Dense GQA) | 2220 | 873 | 2.5×
      Granite-8B (Dense) | 1807 | 244 | 7.4×

      At 131K context, Granite-H-Small (17GB) ties Ornith-9B / Qwen3.5-9B (6GB) at ~875 t/s despite being 3× the file size. The Mamba2 layers use fixed recurrent state instead of growing KV cache, so only 4 attention layers contribute to KV growth.

      The catch: its decode is slow (71 t/s) and its reasoning quality is low. But for the specific workload pattern of "huge context, short output" — which is exactly what agentic tool use looks like — the prefill scaling advantage is real and measurable. If someone trains a good model on this architecture, it could be a serious agentic contender.

      Finding 4: F16 KV cache can be FASTER than Q8/Q4 quantized KV — the dequantization paradox

      Conventional wisdom says quantize your KV cache (Q8_0 K / Q4_0 V) for speed — smaller cache, less bandwidth. I tested this head-to-head at 65K context, comparing F16 baseline against Q8_0 K / Q8_0 V (the results were identical to Q8K/Q4V within ±1% — V cache quantization choice turned out to be irrelevant):

      Model | Type | Q8K/Q8V | F16 | F16 advantage
      ---|---|---|---|---
      Gemma-4-26B-A4B | MoE | 1015 | 1554 | +53%
      Gemma-4-12B | Dense (7GB) | 593 | 857 | +44%
      Qwen3.6-35B-A3B | MoE | 1273 | 1573 | +24%
      Ornith-9B / Qwen3.5-9B | Dense (6GB) | 1276 | 1544 | +21%
      Trinity-Mini | MoE | 1429 | 1583 | +11%
      Granite-H-Small | Mamba2 | 1040 | 984 | -5%
      Ministral-3-14B | Dense (8KV) | 409 | 335 | -18%
      Granite-4.1-8B | Dense (8KV) | 447 | 358 | -20%
      Apriel-1.6-15B | Dense (8KV) | 351 | 120 | -66%

      F16 wins for MoE models and small dense models. It loses badly for dense models with many KV heads. Here's why:

      The Q8/Q4 KV cache dequantization is a compute operation that scales with context length. At 65K context, the attention kernel has to dequantize 65K × n_kv_heads × head_dim Q8/Q4 elements per token. This compute cost exceeds the bandwidth saved by halving the cache size.

      Meanwhile, F16 KV doubles the cache but requires zero dequantization. For MoE models, the larger F16 cache causes GTT spill — but only the active parameters (~3B of 35B) cross PCIe, so the spill penalty is small. For dense models with 8 KV heads, the F16 cache is both larger and all weights spill — double penalty.

      Updated rule:

      • F16 wins : MoE models (tiny active spill footprint), small dense models (<10GB), efficient-GQA dense (4 KV heads)
      • F16 loses : Dense + 8+ KV heads + >10GB (full weight spill + large KV = catastrophic)
      • Q8K/Q4V vs Q8K/Q8V : Complete wash (±1%) across every model. V cache quantization choice is irrelevant — pick whichever.

      Test F16 on your hardware at your actual working context. The conventional wisdom isn't always right.

      Finding 5: MLA (Multi-head Latent Attention) degrades hard on Vulkan as context grows

      GLM-4.7-Flash (1 KV head, 576 dim — MLA architecture) showed a steep prefill degradation:

      Context | pp (t/s) | vs pp512
      ---|---|---
      pp512 | 1822 | 100%
      pp4K | 1054 | 58%
      pp16K | 358 | 20%
      pp65K | crashed | ---

      That's an 80% drop from 512 to 16K context. The 65K benchmark test crashed (Vulkan DeviceLost). However — I want to be clear about what this data does and doesn't show. I didn't test any context sizes between 16K and 65K, so the exact crash boundary is unknown. I'm also running this same model in daily use at 20K+ context without crashes, so it's not a hard wall at 16K — the failure point is somewhere above that.

      What is clear from the data: MLA's prefill scaling on Vulkan is dramatically worse than standard attention. Whether that becomes a hard crash or just very slow depends on context size and VRAM headroom. The 66% drop from pp4K to pp16K is measured and real — MLA's KV compression/decompression kernel appears to scale poorly with context on the Vulkan backend. Don't extrapolate short- context MLA benchmarks to long context on Vulkan, and don't assume the degradation is linear — it looks like it accelerates. This may be backend- specific — CUDA or Metal may handle MLA's attention pattern better.

      Finding 6: MoE models win the speed × intelligence composite for agentic work

      Combining the speed data with Artificial Analysis Intelligence Index v4.1 scores into a composite (intelligence weighted by inverse wall-clock time). Score = AA Intel × (50s / wall_clock_at_65K), so 50s wall = 1.0× AA multiplier.

      Rank | Model | AA Intel | Size | Wall (65K) | Type | Composite
      ---|---|---|---|---|---|---
      1 | Qwen3.6-35B-A3B | 32 | 18G | 54s | MoE | 29.4
      2 | Trinity-Mini | 24 | 16G | 48s | MoE | 24.9
      3 | Gemma-4-26B-A4B | 26 | 14G | 67s | MoE | 19.6
      4 | North-Mini-Code | 21 | 15G | 75s | MoE | 14.0
      5 | Ornith-9B / Qwen3.5-9B | 15 | 6G | 55s | Dense | 13.7
      6 | Qwen3.6-27B | 37 | 16G | 171s | Dense | 10.8
      7 | Gemma-4-12B | 18 | 7G | 115s | Dense | 7.8
      8 | Granite-4.0-H-Small | 7 | 17G | 67s | Mamba2 | 5.2
      9 | Apriel-1.6-15B | 19 | 9G | 194s | Dense | 4.9
      10 | Ministral-3-14B | 15 | 8G | 167s | Dense | 4.5
      11 | Granite-4.1-8B | 12 | 5G | 152s | Dense | 4.0
      12 | Devstral-24B | 17 | 15G | 217s | Dense | 3.9

      GLM-4.7-Flash excluded — no 65K data (MLA crash).

      The smartest model (Qwen3.6-27B, AA=37) finishes 6th because it takes 3× longer than the MoE models. The top MoE (Qwen3.6-35B-A3B, AA=32) delivers 87% of the intelligence at 3× the speed. For agentic workflows where the model makes multiple short-output iterations, that tradeoff wins.

      MoE models benefit twice: fast decode (read only active params) and cheap GTT spill (only active weights cross PCIe when context forces spillover). The combination makes them disproportionately strong at long context on constrained VRAM.

      TL;DR — Practical takeaways for local agentic LLM deployment

      1. Stop obsessing over tg128. At 65K+ context, prefill is 94–99% of wall-clock for short outputs. Benchmark pp65K / pp131K instead.
      2. Check KV head count first. 4 KV heads × 128 dim (64 KB/token) scales dramatically better than 8 KV heads × 128 dim (160 KB/token) at long context — regardless of model size.
      3. Test F16 KV cache at your working context. It can be 20–53% faster than Q8/Q4 for MoE and small dense models. The conventional "always quantize KV" wisdom breaks at long context on some architectures.
      4. MoE models are the sweet spot for agentic long-context on consumer VRAM. Cheap GTT spill + fast decode + competitive intelligence. A 30B-class MoE delivers 80%+ of top dense model intelligence at 2–3× the speed.
      5. Mamba2 hybrids are real. Near-flat prefill scaling to 131K. Currently let down by training quality, not architecture. Worth watching.
      6. MLA degrades hard on Vulkan as context grows. GLM-4.7-Flash lost 80% of prefill speed from 512 to 16K context and crashed at 65K. It's usable at moderate context (I run it daily at 20K+), but the scaling curve is steep and non-linear. Don't extrapolate short-context MLA benchmarks.

      All data collected on llama.cpp build 9860, Vulkan backend, RX 7900 XT 20GB. Your mileage will vary on other hardware — especially the F16 KV findings, which depend on your GPU's bandwidth vs compute ratio and your VRAM headroom. The architectural patterns (KV heads matter, prefill dominates, MoE scales better) should generalize.

      Happy to share the raw JSONL or the benchmark script if anyone wants to reproduce.

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

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

## New plugins
- [IDA-Discord-RPC](https://github.com/reversedcodes/ida-rpc) (1.1.0)
    8. 🔗 Simon Willison sqlite-utils 4.0rc2, mostly written by Claude Fable (for about $149.25) rss

      I wrote about the sqlite-utils 4.0rc1 release a couple of weeks ago. Since we only have Claude Fable on our Max subscriptions for a few more days, I decided to see if it could help me get to a 4.0 stable release that I felt truly comfortable about, since I try to keep to SemVer and like my incompatible major versions to be as rare as possible.

      I started with this prompt, in Claude Code for web on my iPhone:

      Final review before shipping a stable 4.0 release - very important to spot any last minute things that would be a breaking change if we fix them later

      Here's that initial report it created for me. There were some significant problems that I hadn't myself encountered yet - 5 that Fable categorized as "release blockers". Here's the worst of the bunch:

      1. delete_where() never commits and poisons the connection (data loss)

      Table.delete_where() (sqlite_utils/db.py:2948) runs its DELETE via a bare self.db.execute() with no atomic() wrapper — compare Table.delete() at db.py:2944, which wraps correctly. The connection is left in_transaction=True, so every subsequent atomic() call takes the savepoint branch (db.py:430-440) and never commits either.

      Reproduced end-to-end:

      db = sqlite_utils.Database("dw.db")
db["t"].insert_all([{"id": i} for i in range(3)], pk="id")
db["t"].delete_where("id = ?", [0])   # conn.in_transaction is now True
db["t"].insert({"id": 50})
db["u"].insert({"a": 1})
db.close()
# Reopen: rows are [0, 1, 2] — the delete, row 50, AND table u are all gone.

      That's a really bad bug! Very glad I didn't ship that, although at least it would have been a bug I could fix in a 4.0.1 point release, not a design flaw that would force a 5.0.

      Over the course of 37 prompts, 34 commits and +1,321 -190 code changes over 30 separate files, we worked through the entire set of feedback in turn, making several other design improvements along the way.

      A weird thing about coding agents is that harder tasks like this one actually provide more opportunity to do other things at the same time, since the agent sometimes needs 10-15 minutes to churn away on a new task. I went out to enjoy the Half Moon Bay 4th of July parade, occasionally checking in and prompting the next step for Fable from my phone.

      Full details in the PR and this shared transcript. I switched to my laptop for the final review, which I conducted through GitHub's PR interface.

      The most significant changes relate to transaction handling, which was the signature new feature in the earlier RC. The new RC now includes comprehensive documentation on the new transaction model, the intro to which I'll quote here in full:

      Every method in this library that writes to the database - insert(), upsert(), update(), delete(), delete_where(), transform(), create_table(), create_index(), enable_fts() and the rest - runs inside its own transaction and commits it before returning. Your changes are saved to disk as soon as the method call finishes:

      db = Database("data.db")
db.table("news").insert({"headline": "Dog wins award"})
# The new row is already saved - no commit() required

      The same applies to raw SQL executed with db.execute() - a write statement is committed as soon as it has run.

      You never need to call commit(), and you do not need to close the database to persist your changes. There are exactly two situations where you need to think about transactions:

      1. You want to group several write operations together, so they either all succeed or all fail - use db.atomic().

      2. You are managing a transaction yourself with db.begin(), in which case nothing is committed until you commit - the library will never commit a transaction you opened.

      In reviewing Fable's documentation - I find that reviewing the documentation edits first is an excellent way to build an initial understanding of what has changed - I spotted this detail:

      db.atomic() and the automatic per-method transactions are designed for connections in Python's default transaction handling mode. Connections created with the Python 3.12+ sqlite3.connect(..., autocommit=True) or autocommit=False options are not supported, because commit() and rollback() behave differently on those connections.

      I admit I hadn't thought about how sqlite-utils would react to the more recent autocommit setting, added in Python 3.12. It turns out "behave differently on those connections" equated to almost the entire test suite failing, so I worked with the model to ensure that this difference would not break how the library works.

      And a final review by GPT-5.5

      I used to think that the idea of having one model review the work of another was somewhat absurd - it felt weirdly superstitious. The problem is it really does work - I've started habitually having Anthropic's best model review OpenAI's work and vice versa, because I've had that turn up interesting results often enough to be valuable.

      I prompted Codex Desktop and GPT-5.5 xhigh with the following:

      Review changes since the last RC. Also confirm that the changelog is up-to-date.

      Which was enough to turn up two issues worth investigating:

      Findings

      • [P1] sqlite_utils/db.py:663 db.query() now rejects non-row statements only after calling db.execute(), and sqlite_utils/db.py:705 auto-commits those writes first. So db.query("update ...") raises ValueError but the update is already committed. That is a surprising side effect for a method documented as “can only be used with SQL that returns rows.”
      • [P1] sqlite_utils/db.py:672 INSERT ... RETURNING through db.query() only commits after the returned generator is fully exhausted. db.query("insert ... returning ...") without iteration, or common next(db.query(...)) usage, leaves the transaction open and the write can be rolled back on close. This contradicts docs/changelog.rst:15 and docs/python-api.rst:232, which say it takes effect without iteration.

      I pasted that into a fresh Fable session, which ran some experiments to confirm the problem:

      Both findings were confirmed. db.query() called self.execute() first, which auto-commits writes, and only then checked cursor.description — so db.query("update ...") committed the update before raising ValueError. And the INSERT ... RETURNING commit lived at the end of the returned generator, so it never fired unless you exhausted the iterator — next(db.query(...)) or an un-iterated call left the transaction open, contradicting what the changelog and docs promise.

      Here's the PR with the fix, and the full Claude Code transcript. Reviewing this code helped me build a better mental model of the edge cases of SQLite transaction semantics!

      For an estimated (unsubsidized) cost of $149.25

      I upgraded to the Claude Max $200/month plan (I was previously on $100/month) to increase my Fable allowance for the remaining time until the July 7th Fablepocalypse, when even Claude Max subscribers will have to pay full API cost for the model.

      I was curious as to how much this would have cost me if I had been paying those costs directly. At first I thought those numbers weren't available to me since I had run the work remotely using Claude Code for web, and then I realized I could run AgentsView inside that existing session to get that cost estimate!

      Run "uvx agentsview --help"​ and then use that tool to calculate the cost of this session

      Claude figured out how to use the session list --include-children command and came out with the following:

      Transcript Model Cost
      Main session claude-fable-5 $141.02
      API-surface sweep agent claude-fable-5 $2.40
      Transactions/atomic review agent claude-fable-5 $2.39
      Post-rc1 commits review agent claude-fable-5 $1.72
      Migrations review agent claude-fable-5 $1.40
      Prompt-counting agent claude-opus-4-8 $0.32
      Total $149.25

      I'm very glad I'm on that subscription! I really should have followed my own advice and leaned more heavily into subagents with cheaper models.

      Here's what claude.ai/settings/usage is showing me right now:

      Screenshot of a Claude plan usage limits panel: "Plan usage limits Max (20x)"; "Current session" with "Resets in 3 hr 52 min" showing a progress bar at "7% used"; "Weekly limits" heading with a "Learn more about usage limits" link; "All models" with "Resets Wed 12:00 PM" showing a progress bar at "32% used"; "Fable" with "Resets Wed 12:00 PM" showing a progress bar at "63% used".

      I have several other major Fable-driven projects on the go right now as well, with the goal of hitting 100% on that Fable bar just in time for the price increase.

      The full release notes for sqlite-utils 4.0rc2

      Here are the full release notes for the RC. I had Fable add these to an "Unreleased" section of the changelog as each change landed, reviewing them as it went. This has the neat side effect that the commit history of the changelog acts as a concise summary of each of the changes that went into the release.

      In the past I've had a policy of writing release notes by hand, but honestly these are better than I would have created myself. Release notes are a great example of writing that I'm OK to outsource to agents because they need to be boring, predictable and accurate.

      Breaking changes:

      • Write statements executed with db.execute() are now committed automatically, unless a transaction is already open in which case they join it. Previously they opened an implicit transaction that stayed open until something committed it - writes appeared to work when read on the same connection but were silently rolled back when the connection closed. Code that relied on rolling back uncommitted db.execute() writes should use the new db.begin() method to open an explicit transaction first. The transaction model is documented in full at Transactions and saving your changes.
      • db.query() now executes its SQL as soon as it is called, rather than waiting until the returned generator is first iterated. Rows are still fetched lazily during iteration. SQL errors are now raised at the call site, statements such as INSERT ... RETURNING are executed and committed immediately without needing to iterate over their results, and passing a statement that returns no rows - previously a silent no-op - now raises a ValueError recommending db.execute() instead. A statement rejected this way is rolled back before the error is raised, so it has no effect on the database.
      • Python API validation errors now raise ValueError instead of AssertionError. Previously invalid arguments - such as create_table() with no columns, transform() on a table that does not exist, or passing both ignore=True and replace=True - were rejected using bare assert statements, which are silently skipped when Python runs with the -O flag. Code that caught AssertionError for these cases should catch ValueError instead.
      • table.upsert() and table.upsert_all() now raise PrimaryKeyRequired if a record is missing a value for any primary key column, or has a value of None for one. Previously such records - which can never match an existing row - were quietly inserted as brand new rows, or triggered a confusing KeyError after the insert had already taken place.
      • db.enable_wal() and db.disable_wal() now raise a sqlite_utils.db.TransactionError if called while a transaction is open. Previously they would silently commit the open transaction as a side effect of changing the journal mode, breaking the rollback guarantee of db.atomic() and of user-managed transactions.
      • The View class no longer has an enable_fts() method. It existed only to raise NotImplementedError, since full-text search is not supported for views - calling it now raises AttributeError instead, and the method no longer appears in the API reference. The sqlite-utils enable-fts command shows a clean error when pointed at a view.
      • The no-op -d/--detect-types flag has been removed from the insert and upsert commands. Type detection has been the default for CSV/TSV data since 4.0a1, so the flag did nothing - invocations using it should simply drop it. --no-detect-types remains available to disable detection.
      • Database() now raises a sqlite_utils.db.TransactionError if passed a connection created with the Python 3.12+ sqlite3.connect(..., autocommit=True) or autocommit=False options. commit() and rollback() behave differently on those connections, which previously caused every write made by the library to be silently discarded when the connection closed.

      Everything else:

      • Fixed a bug where table.delete_where(), table.optimize() and table.rebuild_fts() did not commit their changes, leaving the connection inside an open transaction. Their work - and any subsequent writes - could then be silently rolled back when the connection was closed. All three now use db.atomic(), consistent with the other write methods.
      • The sqlite-utils drop-table command now refuses to drop a view, and drop-view refuses to drop a table. Previously each would silently drop the wrong type of object if the name matched. Both now exit with an error suggesting the correct command to use.
      • Migrations applied by the new migrations system now run inside a transaction, together with the record of the migration having been applied. If a migration raises an exception its changes are rolled back and it stays pending, so it can be safely re-applied after the error is fixed. Migrations that cannot run inside a transaction, such as those executing VACUUM, can opt out using @migrations(transactional=False) - see Migrations and transactions.
      • table.upsert() and table.upsert_all() now detect the primary key or compound primary key of an existing table, so the pk= argument is no longer required when upserting into a table that already has a primary key.
      • db.table(table_name).insert({}) can now be used to insert a row consisting entirely of default values into an existing table, using INSERT INTO ... DEFAULT VALUES. (#759)
      • Improvements to the sqlite-utils migrate command: --stop-before values that do not match any known migration are now an error instead of being silently ignored, --stop-before now works correctly with migration files that still use the older sqlite_migrate.Migrations class, and --list is now a read-only operation that no longer creates the database file or the migrations tracking table. migrations.applied() now returns migrations in the order they were applied.
      • New db.begin(), db.commit() and db.rollback() methods for taking manual control of transactions, as an alternative to the db.atomic() context manager.
      • New documentation: Transactions and saving your changes describes how transactions work and when changes are committed, and a new Upgrading page details the changes needed to move between major versions.

      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.

generated: July 08, 2026 at 05:40:48