Microsoft's April 30, 2026 deadline for shutting down its public Prebid Cache service has pushed most publishers into a straightforward migration exercise: find a new cache, point Prebid at it, and move on. But video technology company Primis took a different route. Before deciding whether to replace the cache, its team asked whether the cache was still doing anything useful at all.

The answer, according to internal logging across the Primis network, was that it largely was not.

What the cache was built to do

To understand the significance of that finding, it helps to work through what the Prebid Cache was designed to solve in the first place. In a typical Prebid video setup alongside Google Ad Manager, the flow runs as follows. A Prebid auction executes in the browser. Bidders respond with their bids, and crucially, each response carries the VAST XML payload - the actual video creative. The winning Prebid bid is then passed to Google Ad Manager, which runs a second auction against its own demand.

If the Prebid bid wins that secondary auction, the video player needs to retrieve and render the creative. The problem is timing. Google Ad Manager expects to retrieve the creative via a URL, but the bidder returned the creative as raw VAST XML during the auction. The cache layer fills that gap: it stores the VAST XML temporarily and returns a URL that the ad server and player can later call when the auction is settled.

AppNexus introduced this public caching service years ago. Microsoft inherited it through its June 2022 acquisition of Xandr from AT&T. The endpoint at prebid.adnxs.com/pbc became a quiet dependency - something publishers added without cost, and left in place because it worked.

That dependency is now expiring. According to PPC Land's coverage of the announcement, Microsoft announced on December 12, 2025 that it would deprecate the service on April 30, 2026, following an earlier August 2025 notification that had initially set the shutdown for January 31, 2026. Analysis from Ian Meyers, formerly of Sincera and now at The Trade Desk, suggests the Microsoft-hosted cache represents more than 60 percent of configured Prebid cache endpoints across the ecosystem. That is a substantial share of programmatic video infrastructure tied to a single endpoint that is about to go dark.

What Primis found in production

Rather than treating the deprecation as a replacement exercise, Primis ran detailed logging across bidder responses throughout its network. According to Lotem Karmon, VP Operations at Primis, the results were unambiguous: every bidder returned a full VAST XML payload as part of the auction response. Not a subset. Not a URL-only response without the underlying creative. The full creative arrived in the browser at the moment the auction completed.

That single observation changes the economics of the caching step entirely. If the creative is already present in browser memory when the auction closes, sending it to a remote server and retrieving it again later via URL adds a network round-trip without adding information. The creative never needed to leave the environment where it already existed. The cache had become, in the document's framing, "an extra relay point."

This is not a theoretical argument. It depends on how bidders in Primis's specific network actually behave, and the company is careful to note that context matters. But the logging data covered production traffic at scale, across multiple bidders, over a meaningful period.

How Primis rebuilt the delivery flow

Based on those findings, Primis redesigned its delivery pipeline to eliminate the external cache dependency entirely. The implementation addresses two specific constraints.

First, Prebid.js expects a URL reference as part of its normal execution. Bypassing this requirement outright would break Prebid's workflow. Primis resolves this by injecting a placeholder URL - a dummy reference that satisfies Prebid's execution path without triggering an actual cache registration or retrieval. Prebid continues operating normally. It simply never calls a remote cache.

Second, rather than retrieving the creative from a remote cache when the video player needs it, Primis passes the VAST XML that already exists in browser memory directly to the player. The creative moves from the bidder's auction response to playback without ever touching an external server.

The resulting delivery flow is considerably shorter. A bidder returns VAST XML. Prebid runs the auction, with a dummy URL injected for compatibility. The video player receives the VAST XML already held in memory and begins playback. The cache step, and the network hop it represented, simply does not occur.

Technical consequences of removing the cache

The practical implications break down into three areas: latency, reliability, and architectural simplicity.

On latency, removing the cache eliminates one network request from the critical path between auction completion and ad playback. In video advertising, where latency directly affects fill rates and user experience, shortening that path has measurable value. The cache round-trip - browser to remote server and back - is gone.

On reliability, remote caches introduce failure modes that in-memory delivery does not. Cache servers can experience timeouts. Capacity constraints under high load can cause requests to fail. Creatives stored in cache carry expiration windows, and if delivery is delayed beyond that window, the creative becomes unretrievable. Removing the cache removes this entire category of potential delivery failure. According to the Primis document, eliminating the dependency "removes an entire category of potential delivery failures" and makes video rendering "more stable and predictable."

On architecture, the change reduces the number of external dependencies in the delivery chain. Each external dependency is a potential point of failure and a source of operational overhead - something to monitor, maintain relationships with, and depend on for uptime. An architecture that requires fewer external systems is inherently easier to operate.

The April 30 deadline in context

Microsoft's decision to shut down the public cache fits into a broader pattern of the company withdrawing from open programmatic infrastructure. The company announced in May 2025 that it would discontinue Microsoft Invest, its demand-side platform formerly known as Xandr, effective February 28, 2026. That shutdown removed one of the more transparent platforms in the programmatic ecosystem. The Trade Desk and Amazon DSP subsequently moved to absorb displaced advertisers, while Microsoft Monetize continues operating on the supply side.

The Prebid Cache shutdown follows similar logic. Microsoft characterised local caching as the preferred migration path, describing it as offering "a smoother customer experience and reduced bandwidth for all participants," according to the original deprecation documentation. But local caching carries its own complications. Community discussion documented in PPC Land's reporting on the deprecation showed that enabling local caching caused severe performance degradation for certain bidders that maintain their own caching infrastructure - including Rubicon, Xandr, and Nativo - because Prebid was storing all bids in the local cache regardless of whether they had already been cached server-side.

The range of migration options is not small. Publishers can switch to another remote cache provider. Magnite, PubMatic, Mediavine, and JW Player already offer Prebid video caching as a paid option. Publishers can deploy their own server-side cache. Or, as Primis did, they can investigate whether caching remains necessary given how their specific bidders behave.

What this means for publishers evaluating their options

The Primis approach is not universally applicable. It rests on the empirical finding that every bidder in its network returns the full VAST XML payload in memory at auction close. Publishers whose bidder mix includes participants that return only a URL reference without the underlying creative would need the cache, or an equivalent mechanism, to retrieve the creative later.

The critical step is the one Primis took before making any infrastructure decision: logging bidder responses at production scale to understand what is actually arriving in the browser. Most migration conversations in the industry have started from the assumption that the cache must be replaced. Primis's experience suggests that assumption deserves to be tested against real data before acting on it.

Patrick McCann, SVP of research at Raptive and Prebid board member, has previously estimated that monthly caching costs can run between $50,000 and $250,000 for publishers with significant video volume, according to reporting in PPC Land. For publishers at that scale, the difference between replacing the cache and eliminating it entirely is not trivial.

The Prebid ecosystem continues to evolve alongside these infrastructure questions. Prebid has taken on stewardship of new agentic advertising tools in early 2026, and Amazon Publisher Services has launched a new Prebid adapter providing access to Amazon demand alongside more than 60 third-party buyers - developments that add fresh complexity to the already shifting programmatic video landscape.

A structural question raised by one deadline

The retirement of the public Prebid Cache is primarily an operational event. Thousands of publishers need to update a configuration before April 30, or lose the ability to deliver video creatives through their current setup. That part of the story is not in dispute.

What Primis adds to the conversation is a structural question: at what point does an infrastructure component become a legacy dependency rather than an active service? The cache existed to bridge a timing gap between auction response and ad server retrieval. If bidders are already returning the full creative in the auction response, that timing gap may not exist in the way the architecture assumed it did.

According to the Primis document: "Sometimes infrastructure changes reveal an opportunity to rethink assumptions that have been part of the ecosystem for years. This may be one of those moments."

Whether other publishers can reach the same conclusion will depend on their own bidder data. But the question - whether the cache is still doing what it was built to do - is a reasonable one to ask before committing to new infrastructure that replicates a function that may no longer be necessary.

Timeline

Summary

Who: Primis, a video technology company focused on publisher monetisation, with Lotem Karmon - VP Operations - as the author of the technical analysis; Microsoft, which is shutting down the public Prebid Cache it inherited via its June 2022 acquisition of Xandr; and publishers across the programmatic video ecosystem who depend on the infrastructure.

What: Primis conducted logging of bidder responses across its network ahead of Microsoft's Prebid Cache shutdown and found that every bidder already returns the full VAST XML creative payload in browser memory at auction close - making the cache's retrieval function redundant. The company redesigned its video delivery pipeline to eliminate the external cache dependency entirely, injecting a dummy URL for Prebid compatibility while passing the in-memory VAST XML directly to the video player.

When: Microsoft formally announced the Prebid Cache deprecation on December 12, 2025, with an April 30, 2026 shutdown date. Primis published its technical analysis on April 16, 2026, two weeks before the deadline.

Where: The change affects programmatic video delivery infrastructure globally. The public cache endpoint is prebid.adnxs.com/pbc, operated historically by AppNexus, then Xandr, then Microsoft. The Primis implementation applies across the Primis publisher network.

Why: Microsoft is withdrawing from open programmatic infrastructure as part of a broader strategic shift toward AI-driven advertising products, leaving publishers to find replacement caching solutions. Primis questioned whether the cache remained functionally necessary given how bidders actually behave in production, and found through empirical logging that it could eliminate the dependency rather than replace it - reducing latency, simplifying architecture, and removing a category of external failure points.

Share this article
The link has been copied!