Your v0 or Next.js app fetches a public catalog, CMS entry or shared list on every visit. You enabled fetch(..., {cache: 'force-cache'}) to spare your origin, then stopped thinking about the Data Cache counter. That counter may now matter to your bill. On October 30, 2026, Vercel announced that Data Cache is moving into Runtime Cache. This is not a reason to remove caching indiscriminately. It is a reason to find out what your app stores, how often it reads it, and when your team migrates.

What changes, and when?

The migration covers Next.js fetch caching and unstable_cache; Vercel says existing code will continue to work. Teams created from October 30 use Runtime Cache by default. Existing Hobby teams are scheduled to migrate on November 29, 2026. Pro teams will receive their migration date and billing details; Enterprise teams should hear from their account team. Hobby includes one million read units and 200,000 write units a month across the team. On Pro, usage first draws from the $20 monthly infrastructure credit, then follows regional rates. Published rates start at $0.40 per million read units and $4 per million write units. These are neither HTTP request counts nor AI model tokens.

A 20-minute audit before changing code

1. In Vercel, open Usage, then Observability → Runtime Cache. Compare equal windows for the same project and environment. Check reads, writes, hit rate and revalidations. If your team has not migrated, select the Data Cache view when needed.
2. Search your repository for force-cache, next.revalidate, unstable_cache, use cache: remote and getCache. A reproducible local command is rg -n 'force-cache|next\.revalidate|unstable_cache|use cache: remote|getCache' app src lib; adjust paths to match your project.
3. For each route, ask whether the data is shared, changes infrequently and is expensive to obtain. User-specific data or data that must be fresh on every request is a poor fit for a shared cache. Vercel's Runtime Cache documentation spells out those boundaries.
4. Compare function invocations, reads per invocation and entry size before optimizing. More reads without more traffic can point to a recent code change; more billed units with a stable read count can point to larger entries.

A concrete cost example

Vercel's optimization guide says each operation is rounded up in 8 KB units. Imagine 100,000 function invocations. Each reads three separate 2 KB entries and writes one 2 KB entry. That is 300,000 read units and 100,000 write units. At the published starting rates, the arithmetic is $0.12 for reads plus $0.40 for writes, before any free allowance or credit. $0.52 is an illustration, not a forecast of your bill. Region, plan, cache hit rate and actual code paths matter. If a server render reads the same key three times, sharing the result within that request can cut operations while retaining cross-request caching.

A useful test for an AI product this week

Start with shared configuration, a public prompt catalog or templates: these can be read often but updated rarely. Look for a loop that fetches one cache key per item, or a key that changes for every visitor. Change just one route in staging and compare reads, hits, latency and origin calls. Never put private user output under a shared cache key. Also distinguish data caching from CDN caching: Runtime Cache holds data consumed by functions, while the CDN can serve whole HTTP responses when those responses are safe to share. Vercel explains both in its documentation.

Your team's exact Pro migration date, region, operation mix and origin savings are unknown here. Measure them before opting in early or disabling cache. This article is based on Vercel's primary sources; I did not inspect a private account or measure production costs.