tRPC is one of the most-discussed TypeScript libraries of the past two years. It solves a real problem: end-to-end type safety between client and server, without code generation.
In 12,095 Claude Opus 4.7 repos, tRPC appears in 17 of them.
That’s not 17% — that’s 17. A rounding error. 0.14% adoption.
Why does Opus 4.7 avoid tRPC?
Three structural reasons based on what it uses instead:
1. Next.js Server Actions + Route Handlers are built in
When your frontend is Next.js App Router (which Opus 4.7’s is, at scale — 378 Next+React+Tailwind repos), the built-in primitives are:
- Server Actions — async functions marked
"use server"that the client calls type-safely - Route Handlers —
app/api/[...]/route.tsfiles handling arbitrary HTTP
Both ship with Next.js. Zero extra dependencies. Type safety through shared TypeScript — not via a library’s generic wizardry.
2. Zod fills the validation gap
The top TS imports in Opus 4.7 include Zod (3,191 imports). Zod handles the piece tRPC is sometimes used for — runtime validation of payloads. Combined with Server Actions:
"use server"
import { z } from "zod"
const schema = z.object({ id: z.string(), name: z.string().min(3) })
export async function updateUser(input: unknown) {
const data = schema.parse(input)
// ... db.update(data)
}
That’s idiomatic Opus 4.7. End-to-end type safety, validation, no tRPC.
3. tRPC is a conceptual layer, and generative models prefer primitives
When an LLM has to choose between “use this architectural library” and “use language-native primitives,” the LLM’s training tends toward primitives. The reason is subtle:
- Primitives appear in the training data in millions of contexts
- A specific library appears in thousands
- When generating new code, the model picks the more reinforced pattern
tRPC is excellent software. It’s simply underrepresented in training-data distribution vs native Next.js patterns.
What about the 17 that do use tRPC?
Looking at the tRPC-using Opus 4.7 repos:
- Most are older-style patterns from early 2024 — pre-Server-Actions
- A subset are explicit “T3 stack” (tRPC + TypeScript + Tailwind + Prisma) templates
- Some are by developers with strong tRPC preferences who prompted for it specifically
When Opus 4.7 picks up an existing tRPC repo, it writes tRPC well. But it doesn’t start new repos with tRPC.
Other notable absences
Continuing the “anti-patterns” theme, here’s what Opus 4.7 rarely uses despite their popularity:
| Library / pattern | Opus 4.7 uses |
|---|---|
| Redux / Redux Toolkit | almost never — TanStack Query + Server Actions replace it |
| MobX | essentially zero |
| Styled Components | very rare — Tailwind dominates |
| GraphQL | minority — REST via Next.js API routes is default |
| Axios | rare — native fetch + next/server handles HTTP |
| Moment.js | near-zero — native Date or date-fns |
| Lodash | minority — ES2022+ array/object built-ins suffice |
Each of these is a legacy or heavyweight choice compared to the path Opus 4.7 takes. The pattern is consistent: ship less, do more with language natives.
The “modern stack” is a moving target
What feels “modern TypeScript” in 2026 Opus 4.7 land:
Runtime: Next.js App Router or Vite + React
State (server): TanStack Query + fetch
State (client): useState + useReducer (Zustand for the rare heavier need)
API layer: Server Actions + Route Handlers (not tRPC)
Validation: Zod
Styling: Tailwind CSS
UI kit: shadcn/ui
Forms: React Hook Form + Zod resolvers
Auth: Supabase or NextAuth
DB: Prisma or Drizzle
Tests: Vitest + React Testing Library
Icons: Lucide
Animations: Framer Motion
Deployment: Vercel
Everything on that list has thousands of imports in the corpus. tRPC is not on that list.
For the tRPC fans
None of this is a value judgment. tRPC is excellent when the team picks it. But if you’re training a model to produce idiomatic Opus 4.7 code, don’t include tRPC as a default. The training data distribution doesn’t support it.
Related: The Top 30 Libraries Claude Opus 4.7 Actually Imports and Supabase Is Opus 4.7’s BaaS of Choice.