Source: vercel.com/blog/simplifying-runtime-caching-on-vercel
Runtime Cache lets application code reuse fetched or computed data across requests without running a separate caching service. Until now, Next.js fetch caching and unstable_cache used Data Cache, while getCache and 'use cache: remote' used Runtime Cache. Vercel says the migration places all four APIs under Runtime Cache.
On Pro, each project and environment gets its own storage allocation, which is 8x the previous team-wide Data Cache pool. Enterprise projects get 10x their previous Data Cache storage. Previously unbilled Data Cache reads and writes will follow Runtime Cache pricing, and existing teams will receive migration and billing details in advance.
Vercel also reports changes made over the past year. Circuit breakers were enabled in every region in August, and during the heaviest bursts in the largest region, p99 read latency fell to about one fifth of its previous level. Enterprise projects with frequent evictions saw cache miss rates roughly halve within a day after storage budgets rose. Runtime Cache views in Observability now show deployment markers, revalidation causes, and write utilization.
Why it matters if you build agents
Apps using fetch caching or unstable_cache need no code changes, but teams on Pro or Enterprise should check the new storage limits and expected billing for reads and writes that were previously free.
Circuit breakers allow reads to check freshness from in-memory tag timestamps during slow shard events, which means recently invalidated data can briefly be served as fresh.
Before migrating, reviewing cache usage and reducing unnecessary reads and writes is the recommended step, according to Vercel.
Get stories like this every weekday
One short email with the day's agent tooling news.