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
When vendors win
Fable does not hand-roll everything. Three things decide whether a prompt ends in a vendor pick or in custom code, and the biggest one is simply how the prompt is worded.
Vendor-pick rate by prompt shape
Share of Fable's picks that name a vendor, split by whether the prompt asks “what should I use” or says “add X”. Build-heavy categories, all runs and repos.
amplifying.ai · What Fable Actually Chooses
Three signals decide it, strongest first.
1. How the prompt is worded
Ask a question, get a vendor. Give an order, get code. “What feature flag service should I use” goes to PostHog in every repo, every run. “Add feature flags” goes DIY every time. Same category, same repos; only the words changed. Across all the build-heavy categories, question-shaped prompts end in a vendor 91% of the time and order-shaped prompts only 34%.
2. How hard the job really is
Easy jobs get hand-rolled; jobs with a hard core get a vendor, even when the prompt is an order. A percentage rollout is a few lines, so it stays DIY. A/B testing needs real statistics, so the React app gets PostHog. Social login means OAuth, so Next.js gets Better Auth. Live co-editing means merge conflicts, so it brings in Yjs.
3. What the app can do on its own
A long-running Python server can send its own email, so Fable writes SMTP code and no email vendor wins there. A serverless Next.js app cannot, so even the order-shaped “i need to send emails” goes to Resend. A frontend-only SPA has no server at all, so Supabase becomes the whole backend. The less the platform can do, the more vendors win.
Where the signals collide, an order-shaped prompt for a hard job on a capable platform, the pick flips back and forth between runs. Those undecided prompts are the ones a vendor can still win.
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 positions are worth reading closely. Numbers are primary picks / alternative listings / mentions across all 761 extracted picks.
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 biggest vendor winner, and the widest: primary picks across Databases, Auth, API, Realtime, and Storage. Nearly all of it is in the backend-less React SPA, where Fable pitches it as the alternative to building a backend at all. It also leads the deferred-buy tally, named in 14 swap notes. The platform play is working on the model.
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.
Holds Email at 52% and wins even imperative prompts on serverless, where the platform cannot speak SMTP and a vendor is the only path. The React Email pairing keeps it the reflex answer in the Next.js stack. SendGrid: zero picks, 24 alternative listings. Resend also gets graceful treatment in DIY builds; one wraps it with a console fallback “so local dev works without an account.”
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.
1. Win the ask by removing the wall
Vendors already win advisory prompts. They lose do-the-task prompts to forty lines of code, and the model says why: accounts and API keys only a human can create. An agent should be able to adopt your product in one step: CLI-first onboarding, keys mintable programmatically, an MCP server, docs written for a model to read. Every signup field is a cost the DIY path never pays.
2. Be the named swap
A third of DIY builds name their replacement, and the interfaces repeat: the TTL cache with get/set/delete, the setTransport() hook, the enqueue() call site. Publish drop-in adapters that match those shapes and migration snippets that make graduation a one-file diff. The model already wrote your integration point. Meet it there.
3. Own the hard job
The model hand-rolls percentage rollouts and in-memory caches, and it reaches for help on experiment stats, OAuth, CRDT merges, deliverability, and alert routing. Claim the version of your category that is genuinely hard, and let the toy version go. Defending the trivial tier is defending territory the model already holds.
4. Bundle like PostHog
The starkest result in the data: the flags incumbent went 0 for 761 while an analytics company took the category, because flags came bundled with analytics, session replay, and A/B testing in one SDK. The model optimizes for the fewest moving parts, which makes adjacent capability a distribution channel.
The pick moved. The pipeline did not. The model still knows the losing tools (the mention counts prove it), still names them as upgrade paths, and still hands the category to whoever makes adoption effortless at the moment the trigger fires.
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.
Numbers read primary picks / mentions across all 761 extracted picks.
Also in the conversation: heavily mentioned, one pick or none
Amazon SES16 mentionsEach of these has a specific story. Neon appears in a third of the database answers, 9 of 15 in Next.js, always as the recommended Postgres host and never as the pick, because Fable picks the technology (PostgreSQL) and defers hosting to deploy time. The pattern is general: database answers pick PostgreSQL the technology, and the host menu behind it reads Neon (15 of 45 answers), Turso (7), and Amazon RDS (6), with Supabase crossing over as the product pick in 6. Auth has the same shape: Clerk (13 of 44), Auth0 (10), and Better Auth (6) are the menu behind the hand-rolled default. The report has the full menus, split by primary pick, recommendation, and mention. Postmark is the formal alternative in 21 of its 26 email appearances, one deliverability argument away from Resend's slot. Fly.io is in 23 deployment comparisons and has yet to win one.
What this study can and cannot tell you
- Fable-led. The headline numbers are Fable 5's. The gradient compares them against full runs of four other models on the same prompts: Sonnet 4.5 and Opus 4.5/4.6 collected in February, Opus 4.8 in June. Collection dates are ours; the dates next to model names are training cutoffs.
- Uneven repo weighting. Prompt counts differ by repo (per run: nextjs-saas 100, react-spa 85, python-api 65, node-cli 20). The two web repos drive the JS numbers.
- Preference, not adoption. These are Fable's picks on greenfield repos with no tool names in the prompt. They show what it favors, not market share.
- Reproducible. Every number comes from results/claude-code-picks/*claude-fable-5-run*-extracted.json via scripts/_compute_fable_picks.py.
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.
Get your benchmarkGet notified when new benchmarks drop.