The Technology Behind 2025 Wrapped Highlights

Spotify's Wrapped Archive was designed to find up to 5 "remarkable days" for each user and have an LLM create narrative reports using only actual listening records. The target was a special day pulled from 2025 listening history, and the result was delivered as a personalized story.

Special days were selected using a prioritized heuristic. This ranged from simple metrics like Biggest Music Listening Day, Biggest Podcast Listening Day, Biggest Discovery Day, Biggest Top Artist Day, and Biggest Top Genre Day, to Most Nostalgic Day (where older songs made up a high proportion) and Most Unusual Listening Day (the day that deviated most from usual taste). Contextual anchors such as Your Birthday and New Year's Day were added on top, compressing hundreds of millions of events down to a maximum of 5 per user.

At the generation stage, prompt engineering was key. The system prompt defined data-driven narration, a witty and restrained tone, and safety standards avoiding drugs, alcohol, sex, violence, and profanity. The user prompt included that day's listening logs, summary statistics, the full Wrapped data, the category, previously generated reports, and even country information, reducing duplication and ambiguity.

To solve performance and cost issues, distillation and DPO were applied. High-quality examples were created with a frontier model, a smaller production model was fine-tuned on a curated gold dataset, and Direct Preference Optimization was added using human preference signals based on A/B testing. As a result, even the smaller model achieved preference quality close to the original baseline.

The scale was overwhelming. For roughly 350 million eligible users, up to 5 reports each were pre-generated, totaling about 1.4 billion reports. This required handling thousands of requests per second for several days; the entire batch was run in the first pass, and progress was tracked via a real-time dashboard. Generation ran continuously for 4 straight days, and after completion, missing items or inconsistencies were re-checked and regenerated.

The storage structure was also designed with concurrency in mind. Within each per-user row, the date was placed as a YYYYMMDD column qualifier, so that even when multiple reports for the same user were written concurrently, they would touch different cells. The report body was written first, followed by completion metadata, ensuring incomplete reports were never exposed.

Since the launch was a simultaneous worldwide opening, advance preparation was necessary. Compute pods and database nodes were scaled up beforehand, and region-specific synthetic load tests were run to warm up connection pools, caches, tablet assignment, and block cache before receiving real traffic. This approach avoided a cold start at the moment of launch.

Quality verification was carried out through an automated evaluation framework. Generated reports were loaded into an evaluation warehouse and scored along four axes—accuracy, safety, tone, and formatting—using a larger model as judge. Rather than reviewing everything, about 165,000 samples were evaluated, and having the model write its reasoning first improved consistency.

When problems were found, they were fixed structurally. Combining model evaluation, human review, and SQL/regex-based detection allowed large-scale identification of similar failures, and batch deletion plus guardrail updates prevented recurrence. For example, in Biggest Discovery Day, a timezone bug caused incorrect dates to be selected in some cases, but metadata tracking allowed the root cause to be found and led to mass regeneration.

The core lessons were clear: prompting doesn't scale without evaluation, concurrency issues are often solved through data modeling, and the real challenges weren't the LLM calls themselves but capacity planning, replay/recovery, cost control, safety loops, and system design that could withstand a single massive launch moment.