Vibe Coder Daily
English
All fixes About RSS

general October 21, 2026 · 3 min read

Your AI-built Next.js page keeps showing old data, because the fetch cache default depends on your Next.js version

AI coding agents write a bare fetch in a Server Component and the page shows stale data. Next.js 14 cached it by default and 15 does not. Here is the change from the upgrade guide and the explicit cache options that fix it.

Jump to the fix
On this page

Your agent built a dashboard page at app/orders/page.js that calls fetch against your API or database layer. You add a row, reload the page, and the old list is still there. Restarting the dev server does nothing in production, and the data only changes after a redeploy. The code is plain and looks fine.

The cause is a caching default in Next.js that changed between versions, and your agent may be writing for the wrong one.

Why this happens

The Next.js 15 upgrade guide states it directly: “fetch requests are no longer cached by default.” The reverse is the problem here. On Next.js 14 and older, a fetch in a Server Component was cached by default, so the first response was reused instead of asking your API again.

The same guide lists two related changes that landed in 15:

  • GET functions in Route Handlers are no longer cached by default.
  • Page segments are no longer reused from the Client Cache when navigating with <Link> or useRouter. They are still reused on browser back and forward navigation, and layouts and loading states are still cached.

An agent has seen a lot of both eras. It will happily write a bare fetch('https://api.example.com/orders') and assume it behaves the way the version in front of it behaves. If the project is on 14 or older, you get stale data. If it is on 15, the same line is fresh every time, and an agent that “fixed” staleness by copying an older snippet can leave you with caching you did not ask for.

How to tell if this is your problem

  1. Check your version. Run npx next --version. On 14 or older the default is cached. On 15 or newer it is not.
  2. Find the fetch. Open the page or layout that shows the stale data and look for fetch( calls with no second argument.
  3. Check for the route handler case. If the page reads from your own app/api/.../route.js, look at that file for an exported GET. On 14 or older a GET with no dynamic input was cached too.

The fix

Say what you want on each request, so the answer does not depend on the version.

For data that must be fresh every time, opt out of caching on the call, as the docs show:

const res = await fetch('https://api.example.com/orders', { cache: 'no-store' })

For data that is fine slightly old, keep caching but give it a lifetime. next: { revalidate: 60 } is the documented way to refresh a cached response after that many seconds:

const res = await fetch('https://api.example.com/orders', { next: { revalidate: 60 } })

On Next.js 15 you may want the opposite, caching on purpose. The upgrade guide gives two options: pass cache: 'force-cache' to a single request, or export const fetchCache = 'default-cache' from a layout or page to cache every fetch in it that does not set its own cache option.

For a Route Handler on 15 that you do want cached, the guide says to export const dynamic = 'force-static' from the file.

If navigating between pages with <Link> should reuse page data on 15, the experimental.staleTimes option in next.config.js controls it, with dynamic and static values in seconds.

How to avoid this next time

Put the version and the rule in your agent’s instructions: “This is Next.js X App Router. Always pass an explicit cache or next.revalidate option to fetch in Server Components; never rely on the default.” In review, search the diff for fetch( with no options object and decide for each one whether the data should be fresh or cached.

Comments