sqlite-utils 4.0rc2: Claude Fable helped build it, $149.25

sqlite-utils 4.0rc2 shipped on 5th July 2026 after a final development push that Simon Willison attributes largely to Claude Fable; the work involved 37 prompts, 34 commits and "+1,321 -190" code changes across 30 separate files, with an estimated (unsubsidized) model cost of $149.25.

What did Claude Fable do for sqlite-utils 4.0rc2?

The model produced and reviewed large portions of the release candidate, identifying release-blocking bugs, proposing fixes, generating documentation edits and adding changelog entries; the run included a primary session on claude-fable-5 plus several subagents that together account for the $149.25 cost estimate. Willison ran the work interactively (initial prompts from his iPhone, final review via GitHub PR), and upgraded his subscription to Claude Max $200/month (he was previously on $100/month) to increase Fable allowance ahead of the July 7th "Fablepocalypse." The session list in AgentsView attributed $141.02 to the main claude-fable-5 session and smaller amounts to other agents, adding to the $149.25 total.

What bugs and design changes were found and fixed?

A short answer: the session found several P1 issues that would have caused data loss or surprising commits, and the release notes now document an explicit per-method transaction model. The most severe bug involved Table.delete_where(), which previously ran a DELETE without the library's atomic() wrapper and left the connection in_transaction=True, causing subsequent operations to join a savepoint branch and never commit; Willison reproduced the end-to-end failure that left deletions and later inserts lost on reopen. Additional high-priority findings came from GPT-5.5, which flagged db.query() auto-committing writes before rejecting non-row statements and an INSERT... RETURNING commit that only ran after the returned generator was exhausted. The RC2 changelog reflects multiple breaking or behaviour-changing items: write statements via db.execute() are now committed automatically unless a transaction is already open; db.query() executes SQL immediately and raises ValueError for statements that return no rows; Python API validation now raises ValueError instead of AssertionError; upsert behavior around missing primary keys was tightened; and db.enable_wal()/disable_wal() now raise TransactionError if called while a transaction is open.

Why it matters

The release centralizes and clarifies transaction semantics that previously led to silent rollbacks and surprising side effects. Users who relied on implicit, uncommitted db.execute() writes or on catching AssertionError will need to change code paths: the library now commits per-method writes and uses ValueError for API validation. Projects that depend on rollbacks from implicit transactions must adopt explicit db.begin() or db.atomic() usage to preserve behaviour.

What to watch

Track the stable 4.0 release after this RC and inspect client code for three concrete changes: places that relied on uncommitted db.execute() writes, code catching AssertionError for API validation, and patterns that used INSERT... RETURNING with next() or without iterating the returned generator. Also watch whether the July 7th Fable availability change alters how contributors use models in CI and local development.