When Opus 4.7 builds a Next.js app, it defaults to the App Router (app/ directory, React Server Components) — not the legacy Pages Router.

The ratio

Across the Opus 4.7 corpus:

Pattern Repos
App Router (app/**/page.tsx) 1,109
Pages Router (pages/**.tsx) 576
Has layouts (app/**/layout.tsx) 601
Has route handlers (app/**/route.ts) 835
Has middleware (middleware.ts) 443

App Router beats Pages Router 1,109 to 576 — roughly 2:1.

What “has route handlers” means

835 repos — 75% of App-Router repos — have app/**/route.ts files. These are Next.js’s built-in REST endpoint pattern:

// app/api/users/route.ts
export async function GET(request: Request) { ... }
export async function POST(request: Request) { ... }

This replaces the Pages Router’s pages/api/ pattern and is the Opus 4.7 default for backend. Combined with the earlier finding that tRPC is used in only 17 repos, the picture is clear: Next.js route handlers are the default backend pattern in Opus 4.7’s Next.js output.

Layouts and middleware

  • 601 repos (54%) have layout.tsx — using nested layouts
  • 443 repos (40%) have middleware.ts — auth, redirects, rate limiting

Both percentages are higher than they’d be in typical Next.js codebases (where many start without layouts and never add middleware). Opus 4.7 uses the full App-Router toolbox.

Why App Router wins

Three structural reasons:

1. Server Components by default

React Server Components fit naturally into how AI models reason about code — “this runs on the server, this runs on the client” is a cleaner mental model than Pages Router’s “all components run everywhere until you add getServerSideProps.”

2. Co-location

App Router lets you keep page.tsx, loading.tsx, error.tsx, layout.tsx, and API routes (route.ts) in the same directory. That’s good for AI agents: one directory, one feature, all files visible together.

3. It’s the current docs default

Next.js’s official documentation defaults to App Router examples. Training data from 2024+ is skewed App-Router-heavy. The model reproduces what it was trained on.

The 576 Pages Router holdouts

These aren’t random. Sampling shows:

  • Older projects (pre-2024 Next.js versions)
  • Larger codebases where migration has costs
  • Projects using features that weren’t yet ready in App Router when they started (older Next.js 13 issues, specific auth patterns)
  • A few cases where the user explicitly requested Pages Router

What we didn’t measure (yet)

  • "use client" / "use server" directive frequency
  • Suspense boundaries per repo
  • Parallel routes (@modal) and intercepting routes ((..)path) usage
  • App Router generateStaticParams patterns

These are the next-level details that distinguish a casual App-Router user from a sophisticated one. We’ll cover them when our symbol parser catches up.

Implication for fine-tuning

If you’re training a model to produce Next.js code that matches Opus 4.7:

  1. Default to App Router in scaffolds
  2. Include layouts in all but the simplest apps
  3. Use route handlers (not pages/api) for backend
  4. Add middleware whenever auth is part of the prompt

Don’t bother training on Pages Router patterns heavily — they’re the minority and declining.

Related: The Real Opus 4.7 Stack Combinations.