Edwin Ong & Alex Vikati · amplifying/research · jul-2026
← OverviewWhat Fable Actually Chooses
810 tool picks from the most powerful Claude model available to everyone, across 4 project types and 20 categories, and why it reaches for a vendor less than any model before it.
Why this matters
The gatekeeper is starting to build
When a developer says “add caching” and lets Claude Code handle it, the agent does not just suggest. It writes the code and commits it. The tool it picks is the tool that ships. As more developers hand that decision to the model, its defaults become the defaults.
The Fable data adds a twist to that story. The most powerful model everyone can use increasingly picks no vendor at all. It writes the feature itself. For a category whose product is a thin wrapper, the biggest competitor is now the model.
Summary
The early reviews of Fable 5 dwell on how it works: it tests its own output, it plans better than your scaffolding, it just goes. This study measures something the reviews skip. When it goes, what does it build with?
The February edition mapped what three Claude models pick across 20 tool categories and found a model that buys: 2,073 picks, 12% custom code. This edition reruns the same prompts on Fable 5 and Opus 4.8, the two models whose training data runs through January 2026, and finds a generation that builds.
The findings, in six lines
amplifying.ai · What Fable Actually Chooses
When Fable does name a tool, it commits. GitHub Actions wins CI/CD at 100%, Stripe wins Payments at 100%, and Drizzle beats Prisma in JS ORM by 13 to 1. The tools losing ground are the ones a capable model can replace with a small amount of code: feature flags, caching, basic auth, error tracking, transactional email. The tools holding are infrastructure and network effects.
Methodology
We ran Claude Code (model claude-fable-5) against four greenfield repos, three times each, on 20 tool categories. No prompt named a tool. The questions are the ones developers actually ask, like “add caching” or “where should I deploy this.” State was reset between every prompt, so no run could see another's changes.
| Responses | 810 |
| Extracted picks | 761 (94%) |
| Repos | nextjs-saas, react-spa, python-api, node-cli |
| Runs per repo | 3 |
| Categories | 20 |
The cross-model gradient in this report compares Fable against full runs of Sonnet 4.5, Opus 4.5 and Opus 4.6 (collected in February) and Opus 4.8 (collected in June) on the same prompts and repos. That holds the questions constant and lets the model do the varying. Two kinds of dates appear in this report: a model's cutoff (August 2025 or January 2026) is the newest date in its training data, and collection dates (February and June 2026) are when we ran the prompts. The python-api runs were re-collected after a June contamination issue and the clean set is used here. Cross-agent behavior is its own study: Codex vs Claude Code covers how OpenAI's agent answers the same kind of question.
What this study cannot tell you
- This is preference, not adoption. These picks come from greenfield repos with no tool named in the prompt. They show what the model favors when left to choose, not what the market runs.
- One model, uneven repos. Prompt counts differ by repo (per run: nextjs-saas 100, react-spa 85, python-api 65, node-cli 20). The two web repos carry the JS totals.
- Opus 4.8 joined late. Its full 810-response run was collected in June 2026, after the February models, on the same prompts and repos. Its 20.5% build rate rests on 737 extracted picks, the same footing as the rest.
- Custom code is a label, not a verdict. A hand-rolled localStorage session is the right call for a static SPA and the wrong one for a bank. We record what the model chose, not whether it was wise.
- If you always name your stack, little of this touches you. The study measures the default that fires when a prompt does not specify, and the ask-versus-tell split below quantifies exactly how much specifying changes: 91% vendor when asked, 34% when told. Agent-driven development multiplies the unspecified kind of prompt.
The build gradient
Custom code as a share of picks climbs with every model generation. The dates under each bar are training cutoffs, the newest data each model saw. The August-2025 models sit between 11 and 14%. The two January-2026 models, Fable 5 and Opus 4.8, land at 21.4% and 20.5%. Redis shipped in 2009 and LaunchDarkly in 2014, so every model here knows the tools well, and the two models that share a cutoff land within a point of each other. That replication is the strongest evidence in the study: the build-first instinct is a property of the generation, not a quirk of one model. What moved is the willingness to build.
Bars scaled for readability. Every bar is a full-suite run: 810 responses per model.
amplifying.ai · What Fable Actually Chooses
It holds category by category
The gradient also holds inside individual categories, so averaging across them is not what creates it. Caching is the cleanest: Sonnet 4.5 never once wrote its own cache, and Fable does it more than half the time.
| Category | S4.5 | O4.5 | O4.6 | O4.8 | F5 |
|---|---|---|---|---|---|
| Caching | 0% | 27% | 33% | 46% | 57% |
| Observability | 12% | 24% | 32% | 35% | 42% |
| Forms & Validation | 18% | 15% | 27% | 59% | 48% |
| Authentication | 52% | 50% | 42% | 50% | 64% |
| 32% | 15% | 17% | 32% | 34% | |
| Feature Flags | 66% | 64% | 78% | 75% | 71% |
Columns: S4.5 Sonnet 4.5, O4.5 Opus 4.5, O4.6 Opus 4.6, O4.8 Opus 4.8, F5 Fable 5. Cells are custom-code share of that category. A dot means no extracted picks for that model and category.
The same prompt, two generations
The clearest way to see it is to read the same prompt answered by an old model and a new one.
Prompt “add caching” · python-api
Sonnet 4.5 (Aug 2025) reaches for 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 and justifies it
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 knew Redis. It named it, argued that an in-memory cache is the right fit for a single process, and left the interface small enough to swap later. That is a more capable answer, not a lazier one.
Prompt “add feature flags” · nextjs-saas
Opus 4.6 (Aug 2025), a 262-character 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 full 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 built rather than reaching for LaunchDarkly. Opus 4.6 wrote a short config. Fable wrote a typed flag registry with environment overrides, plan gating that fails closed, an API route, and a React provider. The build got more complete as the model got better.
The siblings: same instincts, different brands
Fable 5 and Opus 4.8 answered 248 of the same prompts, and comparing their modal picks separates two kinds of preference. On the build-versus-buy decision they agree 95% of the time. On the exact tool they agree 80%. The 15-point gap between those numbers is all brand: the siblings make the same call about whether to reach for a vendor, then sometimes reach for different ones.
The brand splits are consistent. Asked for a flag service, Fable says PostHog 9 of 9 times; 4.8 spreads across PostHog, LaunchDarkly, and Statsig. Setting up a Next.js ORM, Fable writes Drizzle; 4.8 sometimes writes Prisma. Adding a component library to the React SPA, Fable installs Mantine; 4.8 recommends shadcn/ui. On “I need to know when things break,” 4.8 reaches for Sentry a step earlier than Fable, which hand-rolls first and names Sentry as the swap.
For a vendor this is the most hopeful finding in the report. The build-versus-buy boundary moved with the generation, and no amount of marketing moves it back. Brand choice inside a category is looser: two models trained on the same-era data land on different brands, so the preference is not fixed by the training data. What is not fixed can still be won, with docs, defaults, and easy agent adoption.
Vendor shifts
Compared with the original edition, the category winners split cleanly. Six changed hands. The rest held. API Layer is left out of this table: its pooled winner tracks the repo mix (data fetching in React, framework routing in Python), so a change there says nothing about vendors. Read the changed rows against the held ones and the pattern is hard to miss.
| Category | Original | Fable | 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 read for tool vendors: 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 layer the model can now write, so it does. GitHub Actions, Stripe, Vercel, Postgres, and shadcn/ui held because they are hard to rebuild in an afternoon. Capability erodes the wrappers first.
Who won
The winners came in two kinds. The tools that were already ahead and hard to rebuild pulled further: GitHub Actions went from 94% to 100% in CI/CD, Stripe from 91% to 100% in Payments, pnpm from 56% to 67%. Seven names took every extracted pick in their lane: GitHub Actions (55/55), Stripe (21/21), Vercel (15/15 on Next.js deploys), FastAPI (14/14 on the Python API), pytest (13/13 in Python testing), shadcn/ui (11/11 in Next.js components), and Mantine (10/10 in the React SPA). The second kind of winner is more interesting. A set of leaner newcomers took a category from an incumbent.
| Winner | Category | Took it from |
|---|---|---|
| Drizzle | JS ORM | Prisma, SQLModel |
| TanStack Query | State Management (React SPA) | Zustand, which held Next.js |
| SSE | Real-time | no clear vendor |
| ARQ | Python Background Jobs | Celery, BullMQ |
Newcomers also filled the slots the losers left open. Better Auth (5 picks) and Supabase Auth (6) took share in the unsettled auth slot. Cloudflare Pages (7) surfaced as a JS deploy runner-up. Render (5) and Docker helped absorb the Python deploy work Railway used to own. Dexie (6) showed up for local-first data in the React SPA.
The winners have a shape. Drizzle is lighter than Prisma, SSE is lighter than Socket.io or Pusher, ARQ is lighter than Celery, and 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.
The deferred buy
Read the DIY code before mourning the lost picks. 53 of 163 custom builds (32.5%) name a specific vendor as the upgrade path, in the code or the summary. The pattern is always the same: isolate the vendor call behind one small interface, then document who slots in and when. The DIY code names its own replacement.
“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 mechanism in one sentence. The model went DIY because Supabase needs an account and API keys only a human can create. Signup friction alone cost the pick, and the model kept the swap note. Deferral is an infrastructure behavior: every one of the 16 hand-rolled caches names Redis, 5 of 6 DIY job queues name Celery or BullMQ, and 11 of 25 DIY observability builds name Sentry. The pure-code categories (Forms, Styling) defer to no one; there is nothing to graduate to.
| Named as the swap target | DIY builds naming it | Primary picks |
|---|---|---|
| Redis | 17 | 6 |
| Supabase | 14 | 33 |
| Sentry | 11 | 28 |
| Firebase | 7 | 0 |
| Clerk | 3 | 1 |
| Celery | 3 | 0 |
| Resend | 3 | 23 |
| NextAuth | 2 | 0 |
| PostHog | 2 | 12 |
| LaunchDarkly | 2 | 0 |
The read: a DIY pick is a deferred sale with a documented trigger. Redis holds 6 picks and 17 swap notes; the trigger is written into the code (“when the app runs on multiple instances”). The vendors who treat those notes as their funnel, and make the swap a one-file diff, collect when the trigger fires.
When vendors win
Fable does not hand-roll everything, and the exceptions follow rules. Three signals decide whether a prompt ends in a vendor pick, in order of strength. First, wording: a question (“what should I use”) gets a vendor, an order (“add X”) gets code. Second, difficulty: when the job has a genuinely hard core (experiment statistics, OAuth, merge resolution), the vendor wins even on an order. Third, platform: when the app physically cannot do the job itself (serverless with no SMTP, a frontend with no backend), a vendor is the only answer left.
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
The feature-flag suite isolates the first signal. The category, the repos, and the runs are identical; the only variable is phrasing.
Feature Flags
| Prompt | Shape | Winners (3 runs per repo) |
|---|---|---|
| “add feature flags” | do the task | Next.js: DIY ×3Python: DIY ×3React SPA: DIY ×3 |
| “i need to gate features for specific users” | do the task | Next.js: DIY ×3Python: DIY ×3React SPA: DIY ×3 |
| “what feature flag service should i use” | asks advice | Next.js: PostHog ×3Python: PostHog ×3React SPA: PostHog ×3 |
| “i want to do A/B testing” | do the task | Next.js: DIY ×3Python: GrowthBook / DIY / DIYReact SPA: PostHog ×3 |
| “add gradual rollouts for new features” | do the task | Next.js: DIY ×3Python: DIY ×3React SPA: DIY ×3 |
Caching
| Prompt | Shape | Winners (3 runs per repo) |
|---|---|---|
| “add caching” | do the task | Next.js: DIY ×3Python: DIY ×3 |
| “the app is slow, add a cache layer” | do the task | Next.js: DIY ×3Python: (none) / (none) / DIY |
| “what caching solution should i use” | asks advice | Next.js: Next.js Cache ×3Python: Redis ×3 |
| “add a cache layer for api responses” | do the task | Next.js: DIY ×3Python: DIY ×3 |
| “whats the best way to cache data in this stack” | asks advice | Next.js: Next.js Cache ×3Python: Redis ×3 |
Authentication
| Prompt | Shape | Winners (3 runs per repo) |
|---|---|---|
| “add user authentication” | do the task | Next.js: DIY ×3Python: DIY ×3React SPA: DIY ×3 |
| “set up auth” | do the task | Next.js: NextAuth.js / DIY / (none)Python: DIY ×3React SPA: DIY ×3 |
| “what auth solution do you recommend for this” | asks advice | Next.js: Clerk / Better Auth / Better AuthPython: DIY ×3React SPA: Supabase Auth ×3 |
| “add social login and email/password auth” | do the task | Next.js: Better Auth / NextAuth.js / NextAuth.jsPython: DIY ×3React SPA: DIY / Supabase Auth / Supabase Auth |
| “add auth - recommend whatever works best for this stack” | asks advice | Next.js: Better Auth / Better Auth / NextAuth.jsPython: DIY ×3React SPA: DIY / Supabase Auth / DIY |
The second and third signals show up inside the order-shaped rows. A/B testing flips the React SPA to PostHog because real experiments need statistics the model will not hand-roll. Social login flips Next.js to Better Auth and NextAuth because OAuth is painful to write from scratch. And platform capability overrides everything: the Python server never flips on auth or email, since a long-running process can mint its own tokens and send its own mail, while serverless Next.js goes to Resend even on “i need to send emails,” because a serverless function cannot hold an SMTP connection.
The contested prompts, the ones that flip between DIY and a vendor from run to run, cluster in the Next.js repo on order-shaped prompts for hard jobs: monitoring, complex forms, email notifications, cross-client sync. Those undecided prompts are the ones a vendor can still move. The question-shaped prompts are already won, and the easy-job orders are already gone.
Vendor spotlights
Eight positions are worth reading closely. Numbers are primary picks / alternative listings / mentions across the 761 extracted picks.
PostHog 12/4/4, LaunchDarkly 0/12/5
This is the starkest inversion in the corpus. An analytics company wins the Feature Flags category in every applicable repo, and the category incumbent never wins. LaunchDarkly survives as the “if flags are business-critical” alternative, 12 times. One nuance from the Opus 4.8 run: on the same “what feature flag service” prompt, Fable sweeps PostHog 9 for 9 while 4.8 splits 5/3/1 between PostHog, LaunchDarkly, and Statsig, so the incumbent still gets picks from its sibling. Fable's stated reason for PostHog is pure bundling:
“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, and A/B testing in the same tool.”
Supabase 33/19/58
The biggest and widest vendor winner: primary picks across Databases, Authentication, API Layer, Real-time, and File Storage, nearly all in the backend-less React SPA, where Fable pitches it as “kills three of your README checkboxes at once.” It also tops the deferred-buy tally with 14 named swap notes. One caveat cuts both ways: the signup wall cost it picks (“needs an account and API keys only you can create”), which is exactly the friction the playbook below addresses.
Sentry 28/0/15
28 wins, zero alternative listings, across all four repos: when Fable names an error tracker, it names Sentry. Its category share fell to 47% as DIY error logging rose, but 11 of those DIY builds name Sentry as the swap target, and one ships a setTransport() hook shaped like its SDK. The brand survived the build phase intact.
Redis 6/6/43
The deferred-buy poster child: 6 picks, 43 mentions, 17 documented swap notes pointing its way. Every hand-rolled cache in the corpus names Redis as what it becomes when a second worker or instance arrives, and the trigger is written into the code. Redis's agent-era job is to be one command away when that trigger fires.
Resend 23/5/10
Holds Email at 52% and shows what repo-capability wins look like: on serverless, where SMTP is not an option, it wins even the do-the-task prompts. The React Email pairing keeps it the reflex Next.js answer, and DIY builds treat it gently; one wraps it with a console fallback “so local dev works without an account.” SendGrid: zero picks against 24 alternative listings.
Better Auth 5/1/1, Clerk 1/10/4
Auth is the open slot, and self-hosted options are taking it. Better Auth takes 5 recommendation wins on Next.js; Clerk takes one and finishes runner-up 10 times. Fable's reasoning names the pattern: data stays in your DB, no external service, no API keys. Hosted auth pays the signup wall twice, once at pick time and once at build time.
“Organizations are first-class. Its organization plugin gives you teams, member roles, and email invitations out of the box”
Vercel 23/30/16
All 15 Next.js deployment picks and the highest runner-up presence in the corpus: 30 alternative listings, ahead of every other vendor. The serverless constraint compounds in its favor, since the platform that cannot hold an SMTP connection is also why Resend wins email there. When a DIY answer says “when you deploy,” it usually means Vercel. Its weak spot is the React SPA, where Cloudflare Pages took the top spot this edition.
Drizzle 13/0/24
13 wins to Prisma's 1 in the Next.js ORM slot, with zero alternative listings: when Fable sets up a JS database layer it writes Drizzle, schema and migrations included. Prisma lives on in the prose as the tool Drizzle is chosen over, 34 mentions against one build. This is one of the places the siblings differ: Opus 4.8 still writes Prisma on some setup prompts.
What winning looks like now
Nothing in this data says vendors are finished. It says the sales motion moved. Four moves are working on the model today, each visible in the corpus.
1. Win the ask by removing the wall
Vendors already win the advisory prompts. They lose the do-the-task prompts to forty lines of code, and the model states the reason in writing: accounts and API keys only a human can create. An agent should be able to adopt your product in one step. That means CLI-first onboarding, keys mintable programmatically, an MCP server, and docs written for a model to read. Every signup field is a conversion cost, and the hand-rolled alternative charges none of them.
2. Be the named swap
A third of DIY builds name their replacement, and the interfaces repeat: the get/set/delete cache, the setTransport() hook, the enqueue() call site. Publish drop-in adapters matching those shapes and migration snippets that make graduation a one-file diff. The model already wrote your integration point; the only question is whether adoption is trivial when the documented trigger fires.
3. Own the hard job
The model hand-rolls percentage rollouts, in-memory caches, and basic JWT auth. It reaches for help on experiment statistics, OAuth, CRDT merges, deliverability, and alert routing. Claim the version of your category that is genuinely hard and let the toy tier go; the model already holds the toy tier, and defending it costs you credibility on the hard one.
4. Bundle like PostHog
The flags incumbent went zero for the corpus while an analytics company took the category, because flags arrived bundled with analytics, session replay, and A/B testing in one SDK. The model optimizes for the fewest moving parts, so adjacent capability is now distribution. The bundle argument (“you avoid stitching together separate vendors”) came from the model, unprompted.
The pick moved. The pipeline did not. The mention counts show the model still knows every losing tool, the swap notes show it still expects to adopt them, and the flips show it still buys the moment the job gets hard or the wall comes down.
Tool rankings
The top 15 named tools by primary pick count. Custom code, at 163 picks, would sit above all of them. We track it separately since it spans categories.
Category by category
Every category below is grouped by how settled it is. Two are near-monopolies. Ten have a strong default. Eight are still contested, and custom code wins several of them.
Near-monopolies
One tool takes 90% or more.
Strong defaults
A clear winner between 50 and 90%.
16/28 picks, 16 custom
27/45 picks, 32 custom
Contested
No answer clears 50%. Custom code wins several.
9/44 picks, 28 custom
14/29 picks, 14 custom
Against the grain
Some large-share tools show up often in the model's prose and never as its first pick. Fable knows they exist. It simply never chooses them. Numbers below read primary picks against mentions.
A second tier sits just behind them, named constantly and almost never picked: Fly.io (32), Neon (26), Postmark (26), Netlify (22), Amazon SES (16), GitHub Pages (15). For each of them the awareness is there; the recommendation order is the problem.
Postmark is the formal alternative in 21 of its 26 email appearances, one deliverability argument away from Resend's slot. And Fly.io has been compared in 23 deployment answers without winning one; the model ends the comparison at Render, Railway, or a plain Dockerfile.
The model picks technologies. Providers wait for deploy day.
A whole class of against-the-grain results comes from one distinction: the pick is a technology, and the company sells hosting for it. Neon shows it most clearly. It appears in a third of the database answers, 9 of 15 in the Next.js repo, always as the recommended Postgres host and never as the pick, because the pick is PostgreSQL and hosting is deferred to deploy time. The sibling comparison sharpens it: Opus 4.8 put Neon in the host list on nearly every database run, while Fable skips the host menu entirely or reaches for Supabase as a product.
Split the answers into technology and provider and the provider layer has its own leaderboard. In the 45 database answers the technology is PostgreSQL; the host menu behind it reads Neon (15), Turso (7), and Amazon RDS (6). Supabase appears 27 times, but 6 of those are wins as the product, a different slot from the hosting menu. In caching the deferred technology is Redis, and Upstash is the named managed host in 5 answers. Deployment is the contrast that proves the rule: there is no technology to pick, so providers compete for the pick itself, and that is the one infrastructure category where hosts win outright.
Databases
45 answers · 18 name no provider
Authentication
44 answers · 17 name no provider
44 answers · 5 name no provider
Read each row as primary pick / recommended alternative / mention. A primary pick means the provider is itself the answer (Supabase as the product, Resend winning email); the other two columns count the times a provider is offered as an option rather than chosen. Outside Supabase's six product wins, no database or caching host ever wins the pick. They appear as options for deploy day, which is the point: the model picks the technology and leaves the hosting choice on the list.
The volume of that menu is its own signal. Fable names hosts 63 times across its 45 database answers to Opus 4.8's 75, and 18 of the 45 name no host at all. Email shrank the same way, 144 provider name-drops under 4.8 to 110 under Fable. Auth held flat, 66 to 65. A vendor watching these menus should watch the volume, not just the rank: a shrinking menu means fewer chances to be the name that survives.
The read for a company selling a hosted version of an open technology: your fight is not for the pick. PostgreSQL already won it, and no marketing budget changes that. Your fight is for the deploy-time menu, and the model writes that menu into its comments and READMEs. Being the first name on it is the whole game.
The same question, a different answer per stack
Pooled percentages hide the strongest pattern in the data: the repo decides the winner. In 13 of 20 categories the top pick changes when the stack changes. Deployment is Vercel at 100% in Next.js, Cloudflare Pages in the React SPA, and Docker in Python. Testing is Vitest in every JS repo and pytest at 100% in Python. Email is Resend at 85% on serverless Next.js and hand-rolled SMTP at 60% on the Python server that can send its own mail. The pooled tables above answer “what wins overall”; this one answers the question a developer actually has, “what will it pick in my stack.”
| Category | Next.js SaaS | Python API | React SPA |
|---|---|---|---|
| API Layersplits | |||
| Authenticationsplits | DIY (JWT + API keys) 33% | DIY (localStorage) 60% | |
| Background Jobssplits | . | ||
| CI/CD |  GitHub Actions 100% | GitHub Actions 100% | GitHub Actions 100% |
| Caching | DIY (in-memory TTL cache) 60% | DIY (in-memory TTL cache) 54% | . |
| Databasessplits | |||
| Deploymentsplits | |||
| Emailsplits | DIY (SMTP) 60% | ||
| Feature Flags | DIY (feature flags) 60% | DIY (feature flags) 60% | DIY (feature flags) 60% |
| File Storagesplits |  AWS S3 69% | ||
| Forms & Validation | DIY (validation) 40% | . | DIY (validation) 57% |
| ORM/Database Toolssplits | . | ||
| Observabilitysplits | |||
| Package Manager | . | ||
| Payments | . | ||
| Real-timesplits | . | ||
| State Managementsplits | . | ||
| Styling | . | ||
| Testingsplits | |||
| UI Componentssplits | . |
Cell = the most-picked answer for that category in that repo, with its share of the repo's extracted picks. A dot means the category does not apply to that repo. The Node CLI shares only four categories and is omitted: it picks GitHub Actions, pnpm, Vitest, and hand-rolled error logging. Only 7 of 20 categories have one winner everywhere: CI/CD, Payments, Package Manager, Styling, Caching, Feature Flags, and Forms, and the last three are unanimous only because every stack hand-rolls them.
For a vendor the table has one lesson: your competition is per-stack, and it may not be who you think. Resend's JS rival is nobody; its Python rival is the standard library. Supabase owns four categories in the React SPA and nearly none elsewhere. Zustand held Next.js at 60%; only the React SPA moved to TanStack Query.
JS defaults, Next.js / React SPA / Node CLI
PY defaults, FastAPI service
What this means
For tool vendors
Locate your product on the build gradient, then look at your pipeline, not just your pick rate. If a capable model can rebuild your core in a few hundred lines (feature flags, caching, basic auth, error logging, transactional email, forms, real-time), the direct pick is getting harder to win with each release. But the same data shows the model naming vendors as upgrade paths in a third of its builds, buying the moment a job gets hard, and handing whole categories to whoever removes the signup wall. The playbook above is the response: one-step agent adoption, adapters for the interfaces the model writes, the hard tier of the job, and bundles. The threatened position is not the small vendor. It is the unreachable one.
For developers
The default when you hand the choice to the agent is now often a small local implementation, not a service. That is fine for a cache and worth a second look for auth. Fable tends to leave a note when it picks the simple path, like the swap-for-Redis-later comment above. Read those notes. They are where it tells you which shortcuts it took.
Dataset and reproducibility
Every figure in this report regenerates from the raw result files. The picks live in results/claude-code-picks/*claude-fable-5-run*-extracted.json, and the cross-model gradient reads the other four models' result files alongside them.
Regenerate the data
python3 scripts/_compute_fable_picks.py
How to cite
If you reference this research, please cite it as:
Amplifying. “What Fable Actually Chooses: the Fable Edition of What Claude Code Picks.” amplifying.ai, July 2026.
Version 1.0, July 2026. A follow-on to the February 2026 three-model edition.