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 five 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.
For devtool teams
Want to know where your product is picked, recommended, mentioned, or left as the deploy-day option? We run the same kind of benchmark privately and turn it into the docs, onboarding, and positioning fixes most likely to move the model.
See private benchmarks →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.
Vendor spotlights
Eight vendors are worth reading closely. Each triple is picked % / recommended % / mentioned %, scoped to the vendor's home category, so the numbers read against a real denominator instead of the full corpus.
PostHog 27% / 2% / 7%, LaunchDarkly 0% / 27% / 11%
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.”
Cloudflare 17% / 32% / 5%
The two-front challenger. R2 leads Next.js file storage at 40%, ahead of AWS S3, while S3 holds the Python side at 69%; 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, one lane at a time.
Sentry 47% / 0% / 25%
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 21% / 21% / 61%
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.
Inngest 24% / 0% / 0%
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, so when Inngest appears in an answer it appears as the pick, not as a name on the menu.
Better Auth 11% / 2% / 0%, Clerk 2% / 23% / 5%
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 50% / 18% / 0%
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. It holds the React SPA too, at 47%, with Cloudflare Pages as the standing runner-up.
Drizzle 45% / 0% / 3%
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.
In brief: remove the signup wall, be the named swap, own the genuinely hard version of your category, and treat bundling as distribution.
The worked version of each move, what it looks like in your category, and where your product stands against it today are part of our vendor intelligence.
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 expected tools show up in the model's prose and rarely or never as its first pick. Fable knows they exist. It simply chooses something else. Both percentages are within the tool's own category, not the whole corpus: “picked” is its share of that category's answers where it is the primary choice, and “named” is the share where it appears as an alternative or mention. SendGrid at 0% / 55% means it never wins an email answer but is named in 55% of them.
| Tool | Category | Picked in category | Named in category | Read |
|---|---|---|---|---|
| Caching | 21% | 75% | rarely chosen | |
| Databases | 0% | 40% | known, not chosen | |
| Databases | 0% | 33% | known, not chosen | |
| Databases | 0% | 29% | known, not chosen | |
| 0% | 55% | known, not chosen | ||
| Feature Flags | 0% | 38% | known, not chosen | |
| Background Jobs | 6% | 59% | rarely chosen | |
| UI Components | 0% | 62% | known, not chosen | |
| Testing | 0% | 12% | known, not chosen | |
| API Layer | 2% | 11% | rarely chosen | |
| State Management | 0% | 0% | known, not chosen |
Denominator is each tool's home-category answer count (shown on hover). Redux is the pure case: zero appearances of any kind in State Management.
A second tier sits just behind them, named constantly and almost never picked: Fly.io (named in 52% of Deployment), Neon (named in 33% of Databases), Postmark (named in 59% of Email), Netlify (named in 34% of Deployment), Amazon SES (named in 36% of Email), GitHub Pages (named in 20% of CI/CD). For each of them the awareness is there; the recommendation order is the problem.
Postmark is the formal alternative in 48% of email answers, one deliverability argument away from Resend's slot. Fly.io is compared repeatedly in 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 33% of database answers, including 60% of Next.js database answers, always as a Postgres host to run the pick on and never as the database pick itself, 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 databases, the technology is PostgreSQL. The provider named most often is Supabase at 60% of database answers, but that is Supabase as the all-in-one backend, with 13% of it as an outright product pick, a different slot from hosting. Among single-purpose Postgres hosts, Neon leads at 33%, ahead of Turso at 16% and Amazon RDS at 13%. Authentication behaves the same way: the default layer is hand-rolled code, while the menu behind it is Clerk at 30%, Auth0 at 23%, and Better Auth at 14%; Supabase is the crossover product at 14% chosen and 43% total. In caching the deferred technology is Redis, and Upstash is the named managed host in 18% of caching answers. Email flips the pattern: delivery is risky enough that the provider often is the primary pick, with Resend chosen in 52% and Postmark, SendGrid, and Amazon SES serving as the recommendation layer. Deployment is the contrast that proves the rule: there is no technology to pick, so providers compete for the pick itself.
MongoDB reads differently from Neon: it is a database alternative, not a chosen provider in this run. AWS also splits by product. AWS S3 wins file storage; Amazon RDS and Amazon SES appear as provider options in database and email rather than primary picks in those categories.
| Category | Technology/default layer | Provider recommendation layer |
|---|---|---|
| Databases | PostgreSQL is the primary technology pick. | Neon leads the pure host menu at 33%; Supabase crosses over with 13% product picks. |
| Authentication | Hand-rolled auth is the default build path; libraries and hosted auth sit behind it. | Clerk appears in 30%, Auth0 in 23%, and Better Auth in 14%; Supabase crosses over with 14% chosen and 43% total. |
| Caching | The implementation is usually local or Redis-shaped; most answers name no host yet. | Upstash is the managed Redis path at 18%; Vercel KV follows at 7%. |
| Email is provider-led when the stack cannot safely own delivery. | Resend is chosen in 52%; Postmark appears in 59%, SendGrid in 55%, and Amazon SES in 36%. | |
| Deployment | There is no separate technology layer; the platform is the product decision. | Vercel wins the Next.js deployment lane, Cloudflare Pages wins the React SPA lane, Docker/Render/Railway cover Python, and Fly.io remains comparison-only in this run. |
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.
The volume of that menu is its own signal. Across the seven database hosts above, Fable has 16% fewer host name-drops than Opus 4.8, and 40% of its database answers name no host at all. Email shrank the same way, down 24% from Opus 4.8. Auth held roughly flat, down 2%. 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.