sqlite-utils 4.0rc2: Claude Fable helped ship fixes ($149.25)

sqlite-utils 4.0rc2 was released on 5th July 2026 by Simon Willison. Much of the work on this release candidate was produced with the help of the Claude Fable coding agent, at a reported cost of about $149.25.

What changed in sqlite-utils 4.0rc2?

The RC focuses on transaction handling and a set of bug fixes identified during an automated review cycle, with the release including comprehensive documentation on the library's new transaction model. The documentation states that "Every method in this library that writes to the database... runs inside its own transaction and commits it before returning," and clarifies when db.atomic() or manual db.begin() are needed.

The development cycle led to 34 commits and code churn of +1,321 additions and -190 deletions across 30 separate files, after a sequence of 37 prompts used to drive the agent-assisted work. The release specifically addressed transaction edge cases introduced by the new per-method commit behavior, and corrected issues that could leave connections in a persistent in-transaction state.

How was Claude Fable used to produce the release?

Simon Willison used Claude Fable (on the Max subscription) interactively, starting from a prompt asking for a final review before shipping a stable 4.0 release. Over 37 prompts the model identified problems, produced fixes, and suggested documentation and tests; the process produced 34 commits and edits in 30 files.

Fable flagged five issues it categorized as "release blockers." The most severe reproduced a delete bug: Table.delete_where() executed a DELETE without the atomic() wrapper used elsewhere, leaving the connection with conn.in_transaction set to True. Willison reproduced the failure by inserting rows, calling delete_where, performing more inserts, closing and reopening the DB, and finding the deletes and subsequent inserts lost. The work flow included switching between a phone-based Claude Code session and final review via GitHub's pull request interface.

The review also covered compatibility with Python 3.12's new autocommit option. Willison found that connections created with sqlite3.connect(..., autocommit=True) or autocommit=False behaved differently and initially caused the test suite to fail; he worked with the model to make the library robust to that difference.

What issues remained after the agent-assisted pass?

A subsequent review by GPT-5.5 turned up two notable problems worth investigating. First, db.query() rejects non-row-returning SQL only after calling db.execute(), but db.execute() may auto-commit writes, so db.query("update...") could raise ValueError while already having committed the update. Second, INSERT... RETURNING through db.query() only commits after the returned generator is exhausted, an ordering that GPT-5.5 flagged for further attention.

Willison links the detailed pull request and a shared transcript for the full step-by-step record of the agent interaction and the code changes.

Why it matters

The release shows a practical workflow where a developer used a coding model to find complex, real-world bugs and apply fixes across many files, turning a list of blockers into concrete commits and documentation edits. The specific fixes to transaction handling affect data safety: the reproduced delete_where bug demonstrates how a missing atomic wrapper can leave a connection in a state that effectively discards later writes. The numbers involved—37 prompts, 34 commits, and +1,321 -190 changes—make the scale and impact of the session concrete.

What to watch

Look for the final stable 4.0 release and a follow-up point release addressing the two P1 issues noted by GPT-5.5, plus any additional adjustments for Python 3.12's autocommit behavior. Also watch the linked PR and transcript for the exact patch set and test coverage changes.