Skip to content
AI Primer
update

Fable 5 users report $149.25 sqlite-utils work and X API hallucinations

Practitioners reported concrete Fable 5 coding outcomes, including sqlite-utils 4.0rc2 for $149.25 and hallucinations in X API and OAuth checks. Failures around tests, finance, production outages, and token-heavy loops kept review systems central.

8 min read
Fable 5 users report $149.25 sqlite-utils work and X API hallucinations
Fable 5 users report $149.25 sqlite-utils work and X API hallucinations

TL;DR

The sqlite-utils writeup includes the exact data-loss reproduction. The effort table puts one prompt at 73.2K tokens on low and 367.1K tokens on max. A Reddit cache analysis claims Claude Code subagents are overpaying 14% on prompt cache. The reMarkable demo is still the weirdest user-facing artifact: handwriting fades, model handwriting appears.

sqlite-utils 4.0rc2

sqlite-utils 4.0rc2, mostly written by Claude Fable (for about $149.25)

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 re

According to Simon Willison's Weblog writeup, the final sqlite-utils 4.0 review started from Claude Code for web on an iPhone with a prompt asking Fable to spot last-minute breaking changes before a stable major release.

Fable found five items it categorized as release blockers. The worst one was Table.delete_where(), which ran a DELETE through a bare self.db.execute() without the atomic() wrapper used by Table.delete().

The repro in the writeup left conn.in_transaction=True, pushed later atomic() calls into the savepoint branch, and lost the delete, a later insert, and a new table after close and reopen.

The 4.0rc2 release note points back to the same writeup. Willison's later note called the review humbling and put the estimated unsubsidized cost at $149.25.

Christmas come early for coding-agent nerds: a public Python package shipped with both a serious model-found data-loss bug and a line-item model bill.

X API hallucinations

mattpocockuk's first report said Fable produced two factuality hallucinations in 10 minutes. His follow-up listed the two misses: misunderstanding OAuth requirements for X API endpoints, and not knowing the X API had become cheaper.

mattpocockuk's clarification said Fable remains prone to the same failure modes as lesser models. A later reply labeled the issue a factuality hallucination rather than a faithfulness hallucination, and another reply said the model should have used a tool proactively instead of guessing.

The practical failure mode is not exotic. It is an uncited, tool-checkable claim about a live API.

Domain ceilings

The negative reports clustered around domains with hidden constraints, live systems, or exact external facts.

  • Steve_Yegge's report said Fable ran in circles across sessions on a production outage, then turned the failure into a new eval for future models.
  • badlogicgames' finance report said Fable “sucks at finance,” and his follow-up described using deterministic code for most tax automation instead.
  • theo's iOS report said Fable was strong at infra, databases, and web, but “easily confused” about mobile apps.
  • GergelyOrosz's accounting run found browser automation clunky, slower than doing the work manually, and halfway through quota before the accounting was done.
  • GergelyOrosz's follow-up said the business task still had manual work remaining, while his tooling note separated the promise of autonomous browser work from the current slowness of the model plus integration.
  • eliebakouch's xhigh test said Fable missed current AI-industry facts and that Opus did better on that prompt.

These are boring failures in the useful sense: OAuth, finance, iOS, accounting, outages, and current facts.

Verification stack

zeeg's thread argued that LLM-generated changes now demand large amounts of automated verification, and the follow-up said the gap between side projects and Sentry projects widened because Sentry has verification agents and supporting tools that personal projects do not.

The test debate got concrete fast:

mattpocockuk's review workflow described a three-stage loop: implementation, automated review in a separate session, then human review. zeeg's Warden example showed why mutation-style checks matter: a vacuous regression test passed until deleting the real guard made the test fail.

Orchestrator pattern

The dominant workaround is to spend Fable on judgment, not bulk code generation.

simonw's linked Fable's judgement post describes asking Fable to choose an appropriate lower-power model for coding tasks and run it in a subagent. simonw's reply said he did not trust Opus enough for that kind of decision yet, but was getting there with Fable.

The pattern showed up in several forms:

daniel_mac8's earlier post stated the compact version: Sonnet or Opus writes the code, Fable advises.

Token bill

Fable's capability reports almost always came with a usage story attached.

petergostev's effort table measured the same prompt across effort levels:

  • Low: 73.2K tokens, 27 tool calls, 12m 0s, 711 lines of code.
  • Medium: 190.3K tokens, 58 tool calls, 44m 0s, 1,702 lines of code.
  • High: 296.3K tokens, 88 tool calls, 1h 15m 42s, 1,660 lines of code.
  • XHigh: 261.7K tokens, 165 tool calls, 1h 35m 30s, 2,291 lines of code.
  • Max: 367.1K tokens, 122 tool calls, 1h 50m 40s, 2,425 lines of code.

yacineMTB's single-prompt report put one prompt above $130, and his daily-cost estimate said using Fable like Codex 5.5 would cost about $300 per day. zeeg's first-session report put one session at $400 and described a 1 to 2 hour human-in-the-loop task turning into 6-plus hours of inspection.

bridgemindai's subscription post said the weekly Fable limit died in about a day of real building and showed a third $200 Claude Max subscription. a Reddit quota report said one day of Fable use reached 96% of the user's weekly Fable quota.

Visual demos

The clearest wins were visual, interactive, or product-shaped.

The demo reel explains the hype better than the benchmark charts: Fable is unusually good at turning vague product taste into working artifacts, then spending a terrifying number of tokens polishing them.

Prompt-cache leak

r/ClaudeAI

Claude Code is quietly overpaying ~14% on subagent prompt cache — and it's Anthropic's to fix, not a setting you can change

0 comments

A Reddit analysis of Claude Code transcripts claimed Claude Code is overpaying about 14% on subagent prompt cache and about 8% of total spend in a heavy-subagent workflow.

The post said the analysis covered about 95 sessions, 1,800 subagents, and 6.8B input tokens. The author traced the excess cost to two structural issues: subagents resend about 30K tokens of static context on startup, and a parent's 5-minute cache can expire while it waits on a child.

The proposed fixes were narrow:

  • Put a 1-hour TTL on the write right before a child dispatch, modeled at about 6% savings.
  • Put a 1-hour TTL on identical per-type static prefixes and move dynamic content after them, modeled at 7.6% savings.
  • Keep the default 5-minute cache on the churning conversation tail.

The post points to the linked GitHub issue with the billing math and local transcript parser. Its nastiest detail: the obvious fix, giving subagents the 1-hour cache everywhere, was modeled as 8.6% worse.

Further reading

Discussion across the web

Where this story is being discussed, in original context.

On X· 8 threads
TL;DR5 posts
sqlite-utils 4.0rc21 post
X API hallucinations3 posts
Domain ceilings7 posts
Verification stack8 posts
Orchestrator pattern8 posts
Token bill5 posts
Visual demos5 posts
·
Other sources· 1 post

sqlite-utils 4.0rc2

Release: sqlite-utils 4.0rc2 See sqlite-utils 4.0rc2, mostly written by Claude Fable (for about $149.25).

Share on X