Pinterest just cut its AI infrastructure costs by 90%. Not by switching vendors. Not by negotiating better contracts. By going inside the model itself and removing a piece that wasn't earning its keep.
That decision — surgical, data-driven, and counterintuitive to anyone who equates "frontier model" with "best outcome" — contains more strategic signal for senior leaders than most AI briefings will give them this year.
The problem with treating AI like a utility
Most organisations approach AI spending the way they once approached cloud: sign the enterprise agreement, pay the usage bill, assume the vendor has optimised the stack on your behalf.
That assumption made some sense in the early days of cloud. It makes almost none in AI.
Cloud infrastructure is largely commoditised. The performance difference between one provider's compute and another's, at equivalent specs, is marginal. AI models are not like that. They are shaped by the data they were trained on — and that data was not your data. The model does not know your customers, your product catalogue, your terminology, or the specific signals that matter in your context. When you call it at scale, you are paying for capability you may not need, and missing precision you very much do.
Pinterest's CTO Matt Madrigal made this point with unusual clarity: "If you've got really unique data that you can then fine-tune an open source model with, data quality will, frankly, outweigh or overcome model size."
Pinterest's team essentially removed Qwen3-VL's vision encoder layer and fine-tuned the model on proprietary multimodal embeddings — embeddings built from their own pins, images, and metadata. The result was a model that understood Pinterest's content in a way the original never could. Accuracy went up 30%. Cost went down 90%.
That is not an engineering story. That is a strategy story.
The frontier model assumption
There is a working assumption in many executive teams that the best AI model for any given task is the largest, most capable frontier model available. OpenAI's latest. Anthropic's latest. Google's latest. The assumption is understandable — these models are genuinely impressive, and defaulting to the market leader feels like a defensible decision.
The problem is that "most capable in general" and "most effective for your specific use case" are not the same thing. A frontier model trained on the entire public internet will know a great deal about many things. It may know very little about the specific patterns in your data that actually drive outcomes.
Without proprietary embeddings, developers would have to call and encode each image at runtime, one at a time — resulting in inference latency 20 times worse. The precomputed, offline embeddings allow for personalised experiences that a generic model simply cannot replicate.
The cost gap is not incidental. It reflects a fundamental difference in architecture. When you call a frontier model for every inference, you are paying for the full weight of a general-purpose system. When you precompute your own embeddings offline and query a fine-tuned model, you are paying for what you actually need. At 620 million monthly active users, that difference is not academic — but even at a fraction of that scale, the economics shift quickly.
Three questions every leadership team should ask
The Pinterest decision points to three questions that belong in any serious AI strategy conversation.
How much of your frontier model spend is compensating for data you haven't structured yet?
The most expensive AI pattern is using a powerful model to do work that better data infrastructure would make unnecessary. If your team is prompting a frontier model to extract, classify, or interpret information that already exists in your systems but hasn't been properly organised, you are paying inference costs for what is essentially a data engineering problem.
Madrigal's team had invested in understanding their own data — pins, images, user activity signals — at a granular level. That investment created the foundation for the embedding approach. Organisations that skip the data work and go straight to model procurement will keep paying the frontier model premium indefinitely.
Where is your proprietary data actually underused?
Pinterest built what Madrigal calls a "taste graph" — a dynamic representation of what individual users actually like, not just what they click on. User embeddings capture evolving preferences and are constantly updated based on activity and new content signals. This is data that exists nowhere else. It is not something a frontier model trained on public data can replicate, regardless of how capable it is.
Every organisation with meaningful scale has analogous data. Purchasing patterns that reflect how your customers actually behave, not how the average internet user behaves. Support interactions that reveal how your product actually fails, not how products in general fail. Pricing signals, churn indicators, preference clusters — the specific patterns that are unique to your context.
The question is whether that data is being used to shape the AI systems you deploy, or whether it is sitting in a warehouse while you pay a frontier model to make general-purpose inferences.
Are you buying a model, or buying a capability?
These are different things. A model is a system with particular architecture, training data, and general strengths. A capability is a specific outcome — accurate visual recommendations, reliable document extraction, relevant product ranking. The model is a means to the capability. When organisations treat them as the same thing, they optimise for the wrong variable.
Pinterest did not decide to use the cheapest model. They decided to build the most accurate visual discovery capability for their specific context, and then worked out what that required architecturally. The cost reduction was a consequence of that decision, not the starting point.
The open-source variable
There is a separate strand of the Pinterest story that deserves attention: the role of open-source models.
"Open-source models, especially with open Apache licenses where you can truly tweak a lot of open weights and customise for unique use cases — that's where we've found open source to be so powerful for us," Madrigal said.
This is a meaningful shift in the AI market calculus. For most of the past three years, the dominant narrative in enterprise AI has been that frontier closed models — from OpenAI, Anthropic, and Google — represent the quality ceiling, and open-source models are a cost-saving compromise that trades performance for price.
That narrative is increasingly outdated. Open-source models have closed much of the general capability gap, and in specific domains — particularly when fine-tuned on proprietary data — they can outperform closed frontier models on the tasks that matter. Pinterest's history reflects this trajectory: the company has applied open-source models for visual search and discovery going back to Google's BERT and OpenAI's CLIP, fine-tuning its own Pin CLIP on the latter and incorporating proprietary visual embeddings and image metadata.
The strategic implication for leadership teams is not "switch everything to open-source." The implication is that the build-versus-buy calculus in AI has changed. Organisations that treat frontier model APIs as the only serious option are not looking at the full market. And organisations that dismiss open-source as a quality compromise are working from assumptions that may be two years out of date.
What "foundational investment" actually means
Madrigal used a phrase worth sitting with: his team has been "heavily investing in customising open-source models foundationally in-house."
The word "foundationally" is doing a lot of work there. He is not describing prompt engineering or wrapper-layer customisation. He is describing changes at the architecture level — removing a layer of a model, replacing it with something built from proprietary data, retraining. That is a serious technical investment that requires specific capabilities.
Not every organisation can or should replicate it exactly. But the underlying principle — that AI systems need to be shaped by your data, your context, and your specific performance requirements — is transferable regardless of technical scale.
The practical question for most leadership teams is not "can we gut and rebuild a vision encoder?" It is "are we treating AI procurement as a configuration problem, when it should be a data problem?" The organisations that are getting the best returns from AI right now are generally the ones that started by understanding what their data can do, and then matched the model architecture to that understanding.
The build-or-buy line has moved
For most of the past decade, the standard enterprise technology posture was: buy the platform, configure it for your needs, and reserve building for genuinely differentiated capabilities that no vendor can provide.
AI is forcing a recalibration of where that line sits. Madrigal's position is direct: "If it's going to be critical for our end users, that's going to drive engagement, that will have to scale to over 600 million monthly active users, we're going to either probably build it or we're going to leverage open source and customise the heck out of it."
The logic is sound beyond Pinterest's specific context. If an AI capability is central to your product or service — if it directly touches your customer, drives your core commercial outcome, or represents a competitive differentiator — then the question of whether to build or buy deserves more scrutiny than a standard SaaS procurement decision.
Outsourcing that capability entirely to a frontier model API means accepting that your AI-driven output will be shaped by someone else's training data, someone else's architectural choices, and someone else's cost optimisation decisions. For peripheral workflows, that trade-off is often sensible. For core capabilities, it is worth interrogating.
What this means for the leadership conversation
Most C-suite conversations about AI cost are framed around unit economics: cost per query, cost per token, cost per user. Those metrics matter, but they are downstream of more fundamental decisions.
The Pinterest story suggests the more important leadership questions are structural. Is your AI architecture actually using your proprietary data advantage? Are you relying on frontier model capability to compensate for data infrastructure gaps? Have you mapped the difference between what a general model can do and what your specific context requires?
A 90% cost reduction is a headline number. The mechanism behind it — building proprietary embeddings, replacing a generic vision layer, precomputing at scale — reflects months of foundational investment in data and architecture. The cost saving was not found in the procurement negotiation. It was built.
That is the lesson most worth carrying out of the boardroom. The organisations that will have durable AI cost advantages are not the ones with the best vendor relationships. They are the ones that treated their proprietary data as a first-class asset from the beginning, and built their AI systems accordingly.
The frontier model is a starting point. What you do with your own data determines where you finish.