Next.js 16.3's cacheComponents is a build gate, not a config toggle

Someone scaffolded a fresh `create-next-app` on Next.js 16.3.1, set `cacheComponents: true` and `partialPrefetching: true` in `next.config.ts`, and added the most boring dynamic route available: a product page that awaits its own `params` ^[1][2]. `next build` failed outright, exit code 1 ^[3][6]. That is the part of the release worth planning around, because it means the flag is a contract change enforced at build time rather than an optimisation you switch on when convenient.

The failing page had no database, no external API, and not even a real `fetch` ^[2]. Its data function awaited a 300ms `setTimeout` and returned a hardcoded object ^[2]. The error names the tripwires: `fetch(...)`, `cookies()`, `headers()`, `params`, `searchParams` or `connection()` accessed outside of `<Suspense>` prevents the route from being prerendered ^[4]. Since the only request-time input in that file was the route param, the gate fires on reading `params` alone, with no I/O involved ^[12].

The error offers three ways out, and they are not equivalent: stream, by wrapping the data access in `<Suspense fallback={...}>`; cache, by marking the access `"use cache"`, which the message says does not apply to `connection()`; or block, by exporting `const instant = false` to allow a blocking route ^[5]. The cache route is described as being for uncached data such as `fetch` and database calls, which leaves streaming or blocking as the practical answers for a page whose dynamic input is a URL segment ^[13].

Streaming worked, but not as an annotation. The param-awaiting logic had to move out of the page component into a child, `ProductDetails`, with the page rendering it inside `<Suspense fallback={<p>Loading product...</p>}>` ^[7]. That is one file becoming two components plus a boundary: a code change, not a config change ^[14]. The build then succeeded and reported the route as a partial prerender, static HTML with dynamic server-streamed content ^[8]. Everything outside the Suspense boundary, the shell, was prerendered; the product-specific part streams behind it ^[9].

That shell is also the dependency chain worth noting. According to the dev.to writeup, Partial Prefetching, the client-side navigation feature 16.3 adds, is described as a reusable shell per route cached on the client, and it depends on the same shell existing in the first place ^[10]. So the two flags are not independent purchases. The author's conclusion is that with Cache Components on, every uncached or runtime access found during prerendering needs an answer the moment you flip the switch, and that this is a larger adoption cost than "add two lines to your config" suggests ^[11].

Two things to watch on your own codebase. First, the count: run the flag on a branch and total the routes that fail, because that number is your refactoring backlog, and every one of them is a decision about whether users see a shell or wait. Second, the temptation of `instant = false`, which will clear a build quickly ^[5]. A route allowed to block is not the partial-prerender output the build reported for the streamed version, so mass-applying the escape hatch appears to trade away the prerendered shell that partial prefetching is built on ^[15]. That is a defensible choice per route. It is a bad default applied by find-and-replace.