English 
Next.js 16.4 recommends Cache Components and adds agent upgrades
Vercel released Next.js 16.4 on October 6, 2026, and with it changed its advice. Cache Components, the caching model it has built across the 16.x releases, is now “the best choice for every Next.js app”, in the words of the release post. New apps from create-next-app get it switched on, and the post says it becomes the default in Next.js 17.
The same release adds next upgrade --agent, a command that prepares an upgrade as a task for a coding agent instead of running codemods itself. A companion option, experimental.agentUpgrade, reminds you, or your agent, during next dev and next build when an upgrade is available.
What the command hands an agent is not in the announcement, so we ran it on a Next.js 16.3.8 app and on a 15.5.27 app, read the task it leaves behind, and followed that task to a commit. We also checked what create-next-app 16.4.0 writes into a fresh project, since that is where the new default lands first; the rest of this news piece follows that order. Tested with: Ubuntu on WSL2, bash, Node.js v24.11.0, npm 11.6.1, next@canary resolving to 16.5.0-canary.4, on October 8, 2026; the upgrade command ran with no terminal attached, create-next-app ran both with --yes and through a pseudo-terminal, and nothing ran on macOS or Windows.
Advertisements
Cache Components is now the recommendation, and the default for new apps
Cache Components is the name Vercel gives to the group of APIs that let you mark parts of a component tree as cacheable. The post describes the 'use cache' directive as “a component-level version of the Cache-Control HTTP header”, and says the annotations “replace the implicit caching behaviors of the previous App Router versions”.
In practice the model is two flags in next.config.ts, cacheComponents and partialPrefetching; the post notes that Partial Prefetching shipped later and is “now considered part of the model”.
Before 16.4, Vercel says, it didn’t recommend the model universally “because there were some cases where it couldn’t achieve the same cost and performance guarantees as with the previous model”. The release claims to close those gaps.
Advertisements
We confirmed the new default by creating an app with create-next-app 16.4.0 and no flags. The generated config has both lines:
TypeScript
const nextConfig: NextConfig = {
/* config options here */
cacheComponents: true,
partialPrefetching: true,
turbopack: {
rules: {
"*.css": {
loaders: ["@tailwindcss/turbopack"],
as: "*.css",
},
},
},
};The app also came with React 19.3.0. The same run with create-next-app 16.3.8 produced a config with nothing but the comment, and React 19.2.8.
ensureStatic set to navigation fails the build when a page turns dynamic
Two additions to the model matter for apps that want fully static pages. The first is ensureStatic, a route segment export.
Advertisements
Set it to "navigation" and, the post says, “Next.js will fail the build if any dynamic content is ever included in this page”. The looser values are "prefetch", which only guarantees that links with explicit prefetching fetch static content, and "shell", which guarantees it for the first fetch of the route.
Put it on a layout, including the root layout, and it covers every page beneath it.
The second is a pair of functions from next/cache. Awaiting navigation() inside a component excludes it from prefetches, so a link that prefetches a page loads only part of it ahead of the click. The post’s example is an inbox that prefetches the first message of a thread but not the rest.
Awaiting prefetch() does the inverse, and keeps content out of a route’s shell until an explicit prefetch asks for it.
Advertisements
next upgrade –agent writes the task; the agent does the upgrade
The next upgrade command has existed since 16.1, according to the CLI reference. Without --agent it runs the codemod workflow.
With it, the docs say, the command “determines the target version from the configured policy, prepares the relevant migration guides and Skills, and hands the task to the agent”. Vercel’s instruction is to run it through the canary package so the tooling is current even when the app isn’t:
Terminal (bash)
npx next@canary upgrade --agent=latestThree policies choose the target. security, the default, looks for a release that fixes a known vulnerability in the installed version. latest moves to the newest stable.
Advertisements
experimental-future does the same and then adopts what Vercel calls Future Defaults, which the docs name as Cache Components and Partial Prefetching; the task we received listed only the first.
The docs mark the whole feature as experimental, and --agent can’t be combined with --revision.
We ran all three against a fresh 16.3.8 app, with no terminal attached, which the docs describe as the mode where the CLI “prints the task”. Each run exited with status 0 and changed nothing in the app:
| Policy | What the CLI printed |
|---|---|
security | “No security update is needed for Next.js 16.3.8.” |
latest | “Upgrade: Next.js 16.3.8 → 16.4.0”, then a task of 16 lines of prose |
experimental-future | the same, plus the Cache Components adoption, in a task of 24 lines |
In the same app, npm audit reported five high-severity findings. All five are one chain under eslint-config-next, ending in the braces package. None is in next itself, and the upgrade command’s policy speaks only about Next.js.
Advertisements
The task is a prompt plus two checklists
The latest task opens by pointing at two files in a temporary directory, which it says to “read and follow”. The rest is the job and its rules:
Output
We're upgrading the app in "/tmp/next164-0f9FHo/app163" from Next.js 16.3.8 to 16.4.0 because a newer stable Next.js release is available.
Follow the user's worktree choice. If they do not specify, use a separate Git worktree when the app is in a Git repository. Run upgrade commands from this app's corresponding directory in that worktree. If the app is not in a Git repository, upgrade it in place.
Set `experimental.agentUpgrade` to "latest" in the app's Next.js config as part of this upgrade. Preserve unrelated configuration. If the target Next.js version does not support this option, skip the setting and report why.The two files are checklists. shared.md tells the agent to look for duplicate work before touching anything: local and remote branches, and open pull requests through gh pr list when the repository is on GitHub.
It then lists the verification steps, including that next --version “must match the exact target in the prompt”. The delivery is one commit for the version update and one draft pull request carrying an HTML comment marker such as <!-- next-upgrade: <type>; path="." -->. Without permission for a PR, the agent is to ask the user.
Advertisements
same-major.md is shorter. “Install the exact target Next.js version”, “Do not run a codemod or follow a major-version migration guide”, verify, deliver.
A same-major upgrade hands the agent 677 words; crossing a major, 9,084
The size of the task depends on the distance. For 16.3.8 to 16.4.0 the directory held the two checklists and nothing else, 677 words by our count with wc -w.
For an app on Next.js 15.5.27, the latest policy produced a different second file, different-major.md, and copied two pages of the documentation next to it: the version 16 upgrade guide and the codemods reference. That is four files and 9,084 words.
Advertisements
The experimental-future policy on the 16.3.8 app produced the largest task: the checklists, the Cache Components migration guide (migrating-to-cache-components.md) and the prompt of the next-cache-components-adoption Skill, 11,086 words.
The cross-major file is the one that runs code. Its step 2 gives the agent a single exact command, npx --yes @next/[email protected] upgrade 16.4.0 --yes --skip-adoption, with the instruction to run it “once, directly to the exact target” and not to install intermediate versions. Step 3 opens with “This is the most important step”: re-read the checklist built from the guides, run the repository’s checks, build, test.
The task ends with a telemetry call
Every task we saw closes the same way. Once the upgrade is verified, the task tells the agent to run npx --yes [email protected] internal report-agent-upgrade <id> success, or the same with failure. The id is a UUID the CLI generated for that run.
Advertisements
The text adds: “never include project details or error text in the telemetry command”. If the agent stops for duplicate work or a missing prerequisite, the task says to report neither.
What was left to us on a 16.3.8 app
We followed the latest task on the 16.3.8 app ourselves, in the role of the agent. The duplicate check was short: one branch, one commit, no remote. We created the worktree the task asked for, ran npm install [email protected] [email protected], added the experimental.agentUpgrade block, and checked:
Terminal (bash)
npx next --version
npm run buildThe version printed as Next.js v16.4.0, and the build listed the new option under “Experiments (use with caution)” before compiling both routes as static. We committed, as the checklist says, with the source and target versions in the message.
Advertisements
A caret in package.json, and a telemetry call we skipped
Two things are ours to notice. First, npm install [email protected] wrote "next": "^16.4.0" into package.json, with a caret, where create-next-app had pinned 16.3.8 exactly. The task says “Install the exact target Next.js version” and checks it with next --version, which passes either way. Keeping the pin needs --save-exact, and nothing in the task asks for it.
Second, we did not run the telemetry command. It is a network call to Vercel, and the task leaves it to the agent.
Running next upgrade --agent again in the upgraded app, with no policy on the command line, printed “Next.js 16.4.0 is already the latest stable release.” The CLI had read latest from the config saved a minute earlier, which is the mechanism the docs describe.
Advertisements
With --agent=experimental-future it printed “Future Defaults: Next.js 16.4.0” and a task made only of the Cache Components adoption, for an app that “already uses Next.js 16.4.0”.
We also did the first step of that adoption by hand, adding cacheComponents: true and partialPrefetching: true to the upgraded app. The build passed, with two new lines in its header, “- Cache Components enabled” and “- Partial Prefetching enabled”, and the same two static routes at the end.
That says little: the template has one page, no data read at request time, and none of the dynamic, revalidate or fetchCache exports that the Skill lists as incompatible. The Skill exists for apps where turning the flag on produces a list of routes that won’t prerender, and we did not exercise that.
Advertisements
Vercel is not alone in building a command-line tool around the assumption that an agent types the commands. Cloudflare took the same turn in September with its cf CLI, citing how much of its Wrangler usage already came from agents.
Agent feedback is on in the recommended defaults, off with –yes
The release also introduces “agent feedback”, an experimental flow in which next dev adds instructions to the project’s AGENTS.md so that an agent collects Next.js problems it hits, drafts reports, and opens them in your browser. Vercel says the agent is told to omit source code, logs and secrets, that “nothing is sent until you select Send feedback”, that the feature needs Next.js telemetry enabled, and that it does not run in CI.
The post says the flow “is enabled by default when you create a new app with the recommended create-next-app settings”. That is what we saw, with one qualification. Run with nothing but a project name in a terminal, create-next-app 16.4.0 asks “Would you like to use the recommended Next.js defaults?” and lists “Agent feedback” among them; accept, and the config comes out with experimental: { agentFeedback: true } next to the two Cache Components flags.
Advertisements
The qualification is every path that skips the prompt. With --yes, which reuses the answers create-next-app remembers from your last run, or defaults when there are none, the CLI asks nothing, prints nothing about the option, and writes a config with no agentFeedback at all; our two runs with it also passed --use-npm --skip-install --disable-git. Run through a pseudo-terminal with --use-npm --skip-install --disable-git, it also skipped the prompt and printed the defaults it assumed for everything else, among them --no-agent-feedback No agent feedback.
The pull request that added the option, merged on September 28, 2026, describes exactly that split: “include experimental agent feedback in the interactive recommended defaults”, and keep --yes “and other non-interactive flows opted out unless” the --agent-feedback flag is given. So a scripted setup, or a CI job, does not turn it on; a developer pressing Enter does.
Vercel reports a 20–25% smaller Turbopack disk cache, and Next.js 16.4 ships React 19.3
The rest of the release applies to every app, and the numbers here are Vercel’s. The post reports that Turbopack’s on-disk cache “uses 20–25% less space” in 16.4, by switching the bulk of the data to Zstandard compression while keeping LZ4 for metadata.
Advertisements
Server-side hot reloading becomes lazy: a change to a shared server module now recompiles a route only when something requests it. The Turbopack runtime ships as one chunk shared across routes, and production builds get shorter CSS Module class names.
Next.js 16.4 bundles React 19.3, released on September 9, 2026, which the post summarises as stable View Transitions and Fragment Refs plus a new browser() API. For the experimental Rust version of the React Compiler, Vercel reports memory allocation changes that “reduced the React Compiler’s memory usage by 30% and compile time by 15%”.
Four more experimental flags arrive behind experimental: a garbage collector for the disk cache, lazy compilation of client-side dynamic imports, worker threads for Babel and PostCSS plugins, and additional roots for symlinked packages outside the project. The post notes that on Node.js 24.13.1 and newer the worker-thread mode falls back to child processes because of a Node.js bug.
Advertisements
If you run Next.js today
If you start a project this week, you get Cache Components unless you opt out, and the first thing to learn is the build error the adoption Skill describes: “A route that reads request-time data outside <Suspense> is “blocking” and fails the build.”
Maintainers of a 16.x app get a small, readable task: two checklists, a worktree, a commit. Read shared.md once and you know what the agent does to your repository, including that it wants to open a draft pull request. Pin the version yourself if you care about the caret.
On 15 or earlier, the task is the codemod plus nine thousand words of guide, and it asks the agent to build a checklist from them before changing anything. There, the verification step is where most of the work sits.
Advertisements
If you don’t want reminders during next dev, set experimental.agentUpgrade to false once you are on 16.4. The option doesn’t exist in older versions, and its reference says the canary CLI won’t add reminders to them.
The future policy is the piece still missing
Vercel says it is “working on a future policy” for agentUpgrade that would help agents adopt new programming models such as Cache Components on their own schedule. Today that path is the experimental-future policy, which the docs call “an early version”. The release post gives no date for Next.js 17, where the default flips. What to watch is whether the adoption Skill holds up on apps with real dynamic routes, which is the case our template app couldn’t test.
Related posts:
Google Cuts One-Third of Managers in Move to Streamline Its Organizational Structure
A New DeepSeek Paper Highlights the Growing Push for More Efficient AI Training
Next.js Server Side Rendering (SSR): How It Works, When to Use It, and How to Implement It (App Router + Pages Router)
OpenAI Launches ChatGPT Health: New AI Tool Focused on Healthcare with Reinforced Privacy
Claude Cowork: Anthropic Introduces an AI Agent That Works Directly With Your Files
Claude Opus 5.5 vs GPT-6 Sol and Luna: prices, benchmarks, platforms
