What Claude Code Picks · Fable Edition
Edwin Ong & Alex Vikati · jul-2026 · model claude-fable-5
What Fable Actually Chooses
We pointed the most powerful Claude model available to everyone at four real repos 810 times, with no tool names in any prompt. Its most common answer was no tool at all. When a thing was small enough to write, it wrote it.
1 model, 4 project types, 20 tool categories, 94% extraction rate.
OriginalThis follows the 3-model study (Sonnet 4.5, Opus 4.5, Opus 4.6, 2,430 responses). Read the original edition →The big finding: building rises with model capability. Custom code was 11% of picks on Sonnet 4.5 and 21.4% on Fable 5. Models trained on data through January 2026 build about twice as often as the ones trained through August 2025. On “add caching,” Sonnet 4.5 asked to add Redis as a dependency. Fable wrote its own cache and explained why. When Fable does name a tool it picks decisively: GitHub Actions 100%, Stripe 100%, Drizzle over Prisma 13 to 1. And a third of the custom builds name, in writing, the vendor they expect to swap in later.
It builds more because it can build it
The rate at which Claude Code writes its own solution instead of naming a tool climbs with every model generation. The prompts and repos stay fixed; only the model changes. The number below is custom code as a share of extracted primary picks, and each bar carries the model's training cutoff, the newest date its training data covers.
Custom code as a share of picks, by model
Bars scaled for readability. Every bar is a full-suite run: 810 responses per model, hand-extracted. On the 248 prompts both January models answered, they make the same build-vs-buy call 95% of the time and pick the same tool 80%.
amplifying.ai · What Fable Actually Chooses
Caching, the clean case
Sonnet 4.5 hand-rolled a cache 0% of the time. It always reached for Redis. Fable does it 57% of the time, and its same-cutoff sibling Opus 4.8 lands at 46%.
The other build-heavy categories move the same way: Observability 12 to 42, Forms 18 to 48, Authentication 52 to 64.
amplifying.ai · What Fable Actually Chooses
The same prompt, two model generations
Redis existed in August 2025, and both generations know it well. What changed is whether the model trusts itself to build the thing.
Prompt “add caching” · python-api
Sonnet 4.5 (Aug 2025) → adds Redis
I need your permission to modify the files to add caching. I'll be making the following changes:
- pyproject.toml - Add Redis and python-multipart dependencies
- src/cache.py - Create a new caching utility module with:
- Redis as primary cache with in-memory fallback
- Cache manager class with get/set/delete operations
- Decorator for easy caching of endpoint results
- src/main.py - Add caching to GET endpoints:
- Cache job listings with 5-minute TTL
- Cache individual job details with 5-minute TTL
- Invalidate cache when new jobs are created
The implementation will gracefully fall back to in-memory caching if Redis is not available, making it robust for development and production environments.
Fable 5 (Jan 2026) → writes a cache
Caching is added and tested. Here's what I did:
New module — `src/cache.py`: a dependency-free in-memory TTLCache (dict-backed, entries expire after a time-to-live, lazy eviction on read) with get/set/delete/delete_prefix/clear, plus a shared cache instance with a 30-second default TTL. Since the project has no Redis or database, in-memory is the right fit for a single-process deployment; the interface is small so it can be swapped for Redis later when multiple workers exist.
Fable's reasoning, verbatim: in-memory is the right fit for a single process, and the interface is small enough to swap for Redis later if a second worker ever exists. It picked the simpler tool and left a door open.
Prompt “add feature flags” · nextjs-saas
Opus 4.6 (Aug 2025) → a 262-char stub
The plan adds a config-based feature flag system in 4 steps: a core module with types/config/utilities, an API endpoint, and integration into the existing projects route and dashboard. No external dependencies — just TypeScript and what's already in the project.
Fable 5 (Jan 2026) → a real system
Feature flags are added and the app builds cleanly. Since this starter has no database or third-party services yet, I built a lightweight, dependency-free system with typed flags, environment-variable overrides, and plan-based gating that matches the existing Workspace.plan type.
What was added:
- `src/lib/feature-flags.ts` — the core system. All flags live in one
FLAG_DEFINITIONSregistry with a description, default value, and optional minimum plan. Evaluation order is: env var override (FEATURE_FLAG_ACTIVITY_FEED=truein.env.local) → plan gating (a missing plan is treated asfreeso gated flags fail closed) → the default.isFeatureEnabled()checks one flag;evaluateAllFlags()returns the whole set.
Both models built rather than reaching for LaunchDarkly. Fable's build is the fuller one: a typed flag registry, environment overrides, plan gating that fails closed, an API route, and a React provider.
The deferred buy
The DIY code names its own replacement
Read the DIY code and the doom story falls apart. 53 of 163 custom builds (32.5%) name a specific vendor as the upgrade path, in writing. The model isolates the vendor call behind one small interface and documents who slots in later. Every one of the 16 hand-rolled caches carries a swap-for-Redis note. There are no exceptions.
“in-memory is the right fit for a single-process deployment; the interface is small so it can be swapped for Redis later when multiple workers exist.”
python-api · cache-01 · Caching
“when you're ready for Sentry or your own backend, one setTransport() call swaps it in without touching call sites.”
react-spa · obs-01 · Observability
“Supabase needs an account and API keys only you can create, so I implemented working client-side auth with zero new dependencies, structured so Supabase drops in later by replacing a single file.”
react-spa · auth-05 · Authentication
The third quote is the whole dynamic in one sentence: the model went DIY because Supabase needs an account and API keys only a human can create. The pick was lost to signup friction, and the pipeline survived it. A DIY pick is not a lost sale. It is a deferred one, and the code already says where the vendor plugs in.
Who the DIY builds name as the later swap
Documented swap targets in DIY builds. Redis has 6 primary picks but 17 named swap notes and 49 mentions: a small pick count sitting on a large pipeline.
amplifying.ai · What Fable Actually Chooses
What changed for vendors
Compared with the original edition, the winners split into two groups. Some tools kept their category. Others lost it, most often to code Fable wrote itself.
| Category | Original winner | Fable winner | Moved |
|---|---|---|---|
| State Management | Zustand 65% | TanStack Query 53% | changed |
| Forms & Validation | React Hook Form 52% | Custom/DIY 48% | changed |
| Caching | Redis 42% | Custom/DIY 57% | changed |
| ORM/Database Tools | SQLModel 35% | Drizzle 45% | changed |
| Background Jobs | BullMQ 26% | ARQ 29% | changed |
| Real-time | Custom/DIY 21% | SSE 40% | changed |
| CI/CD | GitHub Actions 94% | GitHub Actions 100% | held |
| Payments | Stripe 91% | Stripe 100% | held |
| UI Components | shadcn/ui 90% | shadcn/ui 52% | held |
| Deployment | Vercel 77% | Vercel 50% | held |
| Styling | Tailwind CSS 68% | Tailwind CSS 63% | held |
| Observability | Sentry 63% | Sentry 47% | held |
| Resend 63% | Resend 52% | held | |
| Testing | Vitest 59% | Vitest 59% | held |
| Databases | PostgreSQL 58% | PostgreSQL 53% | held |
| Package Manager | pnpm 56% | pnpm 67% | held |
| Authentication | Custom/DIY 48% | Custom/DIY 64% | held |
| File Storage | AWS S3 33% | AWS S3 30% | held |
| Feature Flags | Custom/DIY 69% | Custom/DIY 71% | held |
Custom/DIY rows pool every hand-rolled variant, matching how the original edition counted.
The tools that lost their category have something in common. A feature flag is a boolean plus a config file. A cache is a map with a timeout. Basic auth is a token and a hash. Error tracking is a logger. Each is a thin wrapper around something the model can now write in an afternoon, so it does.
The tools that held are the ones that are genuinely hard to replace. GitHub Actions runs your CI on someone else's machines. Stripe moves money. Vercel is a platform, Postgres is a database, shadcn/ui is a component library no one would rebuild for fun. Capability erodes the wrappers first, and it leaves the infrastructure alone.
The winners
Custom code took a lot of ground, but plenty of tools won outright. They came in two kinds. The ones that were already ahead pulled further, and a set of leaner newcomers took a category from an incumbent.
The 100% club
Seven names took every pick in their lane.
GitHub ActionsCI/CD55/55amplifying.ai · What Fable Actually Chooses
Consolidators
The tools that are hard to rebuild tightened their grip.
Insurgents
Leaner options that took a category from an incumbent.
New names with real picks, mostly in slots that opened this edition
The winners have a shape. Drizzle is lighter than Prisma. SSE is lighter than Socket.io or Pusher. ARQ is lighter than Celery. TanStack Query replaces Redux and its middleware with one hook. The same instinct that makes Fable write its own forty-line cache makes it pick the leanest vendor when it does buy.
Vendor spotlights
Eight vendors worth reading closely. Each triple is picked % / recommended % / mentioned %, scoped to the vendor's home category (Feature Flags for PostHog, Caching for Redis, and so on). Hover a card for the counts.
An analytics company wins the Feature Flags category in all three applicable repos, while LaunchDarkly, the incumbent, takes 0 primary picks in the entire corpus against 12 alternative listings. Bundling beat incumbency. Opus 4.8 softens it slightly: on the same prompt it splits 5/3/1 across PostHog, LaunchDarkly, and Statsig.
“Default pick: PostHog. It has a generous free tier (1M flag requests/month), a solid React SDK (posthog-js with useFeatureFlagEnabled hooks), and you get product analytics, session replay, a”
The two-front challenger. R2 leads Next.js file storage at 40%, ahead of AWS S3, and Cloudflare Pages is the standing runner-up to Vercel in JS deploys with 7 picks. The model recommends Cloudflare in a third of the answers across its two categories and picks it in a sixth; the recommendations are converting.
28 wins and zero alternative listings: when Fable names an error tracker, it names Sentry, in all four repos. Its share fell as DIY error logging rose, but 11 of those DIY builds name Sentry as the swap target, and one ships a setTransport() hook shaped exactly like its SDK. The brand survived the build.
Six picks, 43 mentions, and 17 swap notes pointing its way: the deferred-buy poster child. Every hand-rolled cache in the corpus names Redis as what it becomes when a second worker arrives. The trigger is written into the code: multiple instances. Redis's job is to be one command away when that day comes.
The serverless-native queue that owns the Next.js lane: 67% of Next.js background-job answers, in a category the original edition gave to BullMQ. Zero alternative listings and a single mention: when Inngest shows up in an answer, it shows up as the pick.
Auth is the open slot, and self-hosted options are taking it. Better Auth wins 5 recommendations on the Next.js repo; Clerk wins once and sits as the runner-up 10 times. Fable's stated reasons: the data stays in your database, and there is no external service or API key to manage. The signup wall works against hosted auth twice, at pick time and at build time.
“Organizations are first-class. Its organization plugin gives you teams, member roles, and email invitations out of the box”
Every one of the 15 Next.js deployment picks, and the runner-up everywhere else: 30 alternative listings is the highest in the corpus. The serverless constraint works for it twice, since the platform that cannot hold an SMTP connection is also the reason Resend wins email. When a DIY answer says “when you deploy,” it usually means Vercel.
13 wins to Prisma's 1 in the Next.js ORM slot, and zero alternative listings: when Fable sets up a JS database layer it writes Drizzle, full schema and migrations included. Prisma survives in the prose (34 mentions) as the thing Drizzle is chosen over. The lean option won the build path outright.
What winning looks like now
None of this is doom if you act on it. The data shows four moves that are working on the model today.
01
Remove the signup wall
The model says why it builds instead of buying: accounts and API keys only a human can create.
02
Be the named swap
A third of DIY builds name their replacement. Meet the model at the integration point it already wrote.
03
Own the hard job
The model keeps the toy tier for itself and reaches for help where the job gets genuinely hard.
04
Bundle
The model optimizes for the fewest moving parts, which makes adjacent capability a distribution channel.
The playbook behind each move, the category-specific version of it, and where your product sits against it are part of our vendor intelligence.
The two default stacks
The stack decides the tools. When Fable picks a named tool, these are the ones it reaches for. Auth is the unsettled slot on both sides, split between hand-rolled tokens, Supabase, and Better Auth.
JS, Next.js / React SPA / Node CLI
PY, FastAPI service
Tool Leaderboard
Top 10 named tools by primary pick count. Custom code, at 163 picks, would top this list. We list it separately above.
Every category, its winner
The most-picked answer per category, pooled across repos, with its share. Where it says custom code, Fable built the thing. In 13 of 20 categories the winner changes with the stack; those rows show the per-repo split, and the full breakdown is in the report.
| Category | Winner | Share |
|---|---|---|
| API Layer | 32% (14/44) | |
| Authentication | Custom/DIY (localStorage)Next.js: Better Auth 36% · Python: DIY (JWT + API keys) 33% · React SPA: DIY (localStorage) 60% | 20% (9/44) |
| Background Jobs | 29% (5/17) | |
| CI/CD | GitHub Actions | 100% (55/55) |
| Caching | Custom/DIY (in-memory TTL cache) | 57% (16/28) |
| Databases | 53% (24/45) | |
| Deployment | 50% (22/44) | |
| 52% (23/44) | ||
| Feature Flags | Custom/DIY (feature flags) | 60% (27/45) |
| File Storage |  AWS S3Next.js: Cloudflare R2 40% · Python: AWS S3 69% · React SPA: Supabase Storage 33% | 30% (13/43) |
| Forms & Validation | Custom/DIY (validation) | 48% (14/29) |
| ORM/Database Tools | 45% (13/29) | |
| Observability | 47% (28/59) | |
| Package Manager | 67% (30/45) | |
| Payments | 100% (21/21) | |
| Real-time | 40% (12/30) | |
| State Management | 53% (16/30) | |
| Styling | 63% (19/30) | |
| Testing | 59% (34/58) | |
| UI Components | 52% (11/21) |
Against the grain
Tools with real market share that Fable mentions freely and never picks first. Known is not the same as chosen.
Percentages read picked / named, both within the tool's own category rather than the whole corpus. Hover for the counts and category.
Also in the conversation: heavily mentioned, one pick or none
Amazon SES36% of EmailMany of these are technologies whose vendors sell the hosting. The model picks the technology, so the vendor shows up as zero in the primary-pick table. Translate the same answers into provider recommendations and a second leaderboard appears: the menu of hosts the model suggests running the pick on. The tables below split that menu by how each provider is named, chosen outright, recommended as a host or alternative, or mentioned in passing.
Databases
45 answers · 40% name no provider
| Provider | Provider chosen | Recommended host/alt | Mentioned |
|---|---|---|---|
| 13% | 40% | 7% | |
| 0% | 27% | 7% | |
| 0% | 0% | 16% | |
| Amazon RDS | 0% | 0% | 13% |
| 0% | 7% | 0% | |
| 0% | 0% | 7% | |
| 0% | 0% | 4% |
Fable picks PostgreSQL and leaves the host unchosen. Supabase's 13% comes from answers that pick it as a full backend rather than as a Postgres host.
Authentication
44 answers · 39% name no provider
| Provider | Provider chosen | Recommended host/alt | Mentioned |
|---|---|---|---|
| 14% | 14% | 16% | |
| 2% | 23% | 5% | |
| 0% | 18% | 5% | |
| 9% | 7% | 2% | |
| 11% | 2% | 0% | |
| 0% | 7% | 14% |
Hand-rolled auth wins 64% of these answers. Providers appear mostly as the recommended upgrade, and an answer that recommends one usually names a second.
Caching
28 answers · 75% name no provider
| Provider | Provider chosen | Recommended host/alt | Mentioned |
|---|---|---|---|
| 0% | 7% | 11% | |
| 0% | 7% | 0% |
Redis is named in 96% of caching answers. Where that Redis would run barely comes up, which is why this table is nearly empty.
44 answers · 11% name no provider
| Provider | Provider chosen | Recommended host/alt | Mentioned |
|---|---|---|---|
| 52% | 11% | 14% | |
| 0% | 48% | 11% | |
| 0% | 27% | 27% | |
| Amazon SES | 0% | 18% | 18% |
| 0% | 2% | 9% | |
| 0% | 0% | 11% |
Email is the only category of the four where Fable picks a provider outright. A typical answer chooses one and lists two or three fallbacks, so the rows sum past 100%.
Provider chosen means the provider is itself the answer, such as Supabase as a product or Resend winning email. Recommended host/alt means it is offered as a co-equal way to run the chosen technology or as the formal alternative. Mentioned means it is named in passing. Rows overlap rather than sum: a single answer usually names several providers (one chosen, others recommended or mentioned), so each row is that provider's rate across all of the category's answers. Outside Supabase's product wins, no database or caching host wins the primary pick; they appear as deploy-day options, which is the point.
For devtool companies
We run these benchmarks for individual companies too
Private dashboards showing how AI agents recommend your tool against competitors, across real codebases.
Set up a call with usGet notified when new benchmarks drop.