Bypassing RevenueBench to Buy the Feedback Loop
We have seen an accelerating pace of model release cadence over the last few weeks. Frankly speaking, this may be a new normal for the rest of this year instead of being an anomaly. If you haven’t got there already, my guess is by the end of this year most of us will feel like the below tweet when it comes to opining on any new model.
Indeed, even the benchmarks are starting to act a little strange and perhaps finding it difficult to keep up with the model release cadence as frontier models start to saturate most benchmarks out there. I increasingly find myself leaning towards Elon Musk’s philosophy around benchmark: “RevenueBench”. You got to think that almost nothing is as reliable as people voting with their wallet and if a new model succeeds in changing wallet share noticeably, that is a much stronger indication of a model’s performance than anything else. Of course, the biggest challenge here is that revenue is a lagging indicator whereas benchmarks could be more of a leading indicator. So, there will still be massive demand for benchmarks or evals to gauge such leading indicator but as I said, differentiating the signal from the noise here will become more challenging over time.
The other challenge here is that there are companies such as Meta who is deliberately playing the catch up game to the frontier by avoiding the “RevenueBench” altogether. Given the importance of good coding data, Meta is effectively giving their latest models away for free if you allow them to train their future models on your data.
But are the developers willing to make that trade-off? OpenCode’s data suggests that such strategy is working very well for Meta. Following Muse Spark 1.3 release, Meta’s tokens processed on OpenCode exceeded 5 trillion yesterday!
In fact, following Muse Spark 1.3 release, Meta’s token share on OpenCode went from 25% to 40% and is approaching half of all tokens on OpenCode today. Let me contextualize what 5 trillion tokens per day means. Back in June 2026 while proposing $80 Billion equity raise, Sundar Pichai mentioned the following (emphasis mine):
“The Antigravity coding harness has accelerated how we build internally. Every few weeks, we’re doubling the number of tokens we’re processing across our developer tooling. Recently, we reached more than three trillion tokens a day. This scale creates a powerful feedback loop to improve our current and future models.”
So, only on OpenCode Meta is essentially processing almost twice that of what Google was processing for their coding harness couple of months ago. Of course, Google’s antigravity is processing more tokens today; so I am just pointing it to help you contextualize that Meta’s aggressive pricing strategy has helped them gain Google-shaped coding data and if Pichai is right that such data creates “a powerful feedback loop”, Meta is doing the right thing to bypass the “RevenueBench” for now.
Meta also has other strong incentives to ensure their model is on par with frontier models at coding. Recent media reports suggest that Meta is expected to spend $10 Billion on Anthropic’s models and I assume the amount could be even higher when we include OpenAI’s models. So, even if Meta’s models are barely monetized externally via paying customers, Meta can save a sizable amount internally just by not paying the margins for frontier models.
Moreover, it can be increasingly difficult to compete against frontier model developers if they decide to keep their best model internally for first-party products while the models via API only get to use older and less capable models. Zuckerberg has been paranoid about this possibility for a while and if OpenAI’s Tibo’s tweet yesterday is any indication, he was correct to entertain such possibility. This lopsided risk-reward for not owning the frontier model is perhaps only tangibly felt if you are the founder which may partly explain why the founder-led companies seem to feel this risk most acutely while the manager-led companies are mostly focused on selling compute.
Even before reaching the frontier, Meta has been radically changing how it approaches its own product development. Their pace of release has clearly accelerated even for their Family of Apps (FOA) business as they have launched Forum (a standalone app for Facebook Groups), Facebook Creator Studio (for Facebook creators), and Seller (for Facebook Marketplace sellers) just in the last three months! In a recent podcast, Jagjit Chawla, Meta’s VP behind Facebook’s Feed and Reels, explained why such standalone apps are helping their FOA ecosystem. Some key excerpts from the podcast:
“we have somewhat of a two-sided or maybe I can say three-sided marketplace, right? We acquire the world’s best content from creators. That’s number one. And creator could be like a group producer or I’m talking about the production side. Then we distribute that content to people who find that useful as consumers, and then we take consumer time and trade it for advertiser dollars and we take those dollars and flow that back into production. Now, the question is that if you have a 2 billion app, which is largely focused on the consumers, people who are going to consume all of this content, there is always going to be a set of power users who are on the other side, which are much smaller always. Producers always are going to be small in size compared to consumers. Will you ever be able to justify a new app for the producer segment?
And if they produce more and you can then take that content in terms of liquidity and distribute on both platforms, let’s say forum and Facebook app, by definition, you have more blood in the ecosystem, which in this case “content”. More blood means more oxygen is reaching many places. I’m using a poor body analogy.
But I think in my mind that assumption has now been validated that if you give producers a powerful surface that is unconstrained, they will produce more. The more they will produce, the more consumption So that’s why it’s not cannibalistic. And that was the first proof point we were looking for.
We got that proven with a bunch of work on forum. And then we basically said, why not Facebook sellers? Because they are also producers. There’s a bunch of features we could give them.
If you were to try to do that in a 2 billion daily user app like Facebook, it’ll get cluttered for a lot of existing users. So it kind of liberates both the teams and unconstrains the product to go do different things. And I think it’s additive to the ecosystem.
We already have this definition of what we call family of apps. Traditionally, the big apps are Facebook, Instagram, WhatsApp, and Messenger. And now we have a bunch of these standalone constellation apps for each of the apps, which is actually helping the ecosystem overall.
One of the big challenges with working in a big company setup like this is that there are different people who own different services. So most of the time, even speaking as an executive or even as an IC, a lot of the time goes into solving what I would, what in your vocabulary is inside the building problems, which is I need to go convince these set of five people before they will let me, allow me to ship something on the surface that they own because there is going to be the right conversation on trade-offs. There is going to be a conversation on opportunity costs and so on and so forth. All of those constraints actually slow you down. And that is one of the big challenges of big tech is because there is a lot to lose, so to speak, when you have 2 billion users, hundreds of billions of revenue, you can’t really be messing things up. That like 0.1% change is a meaningful change to the business and to our users. So in that sense, there was a lot of constraints in terms of what is the right lane. And there was a lot of process to make sure that you’re not going to break things inadvertently and not cause effects. So there was a lot of this emphasis on ecosystem thinking end to end.
There was a lot of careful judgment required to navigate that process. And as you can imagine, that is onerous because you need to be in the system for a while. You need to have tenure to understand the ecosystem. You need to have tenure to have the right relationships to be able to influence those set of people.
Now, if you contrast it to now, so if I am a groups PM, I used this example before. I have a small app called Forum, which has tens of millions of users. I am unconstrained. I don’t need any approvals from service owners like the feed team. I have my own ranking team, and it’s a small pod of people who sit next to each other, and I can move much, much faster. And as and when we prove the right features to happen in forum, it’s a much easier sell, much lighter process to port them over to the main application.”
Indeed, Zuckerberg was perhaps too enamored by the ability of small teams to outcompete larger teams as a recent Reuters report suggests that he was actually thinking of a much larger lay-off than the 10% Meta actually ended up doing in May. Gergely Orosz had a very critical piece on Meta’s approach to managing their employees, especially engineers and he estimated the actual lay-off Zuckerberg was perhaps thinking of is closer to ~30-40%. Orosz did make an attempt to understand where Zuckerberg might be coming from, especially in light of OpenAI and Anthropic potentially building a similar sized market cap companies with a fraction of Meta’s employee base, but he ultimately made the case that Meta might end up destroying too much goodwill as an employer to become an AI-native company.
As a shareholder, I actually do share Zuckerberg’s concern. It’s always going to be painful to adapt to the new world in the age of AI as a public company that is always under the scanner. I don’t discard Orosz’s concerns either; it’s hardly ever fun to work in a setting where you can’t quite trust if you’ll be around in a few months. But if having a larger company becomes a barrier to keep up with the productivity harnessed in smaller, AI-native companies, this is a choice that many public tech companies may face. That’s also going to be very politically fraught as few people expect companies to downsize when revenues and profits are soaring. Having said that, Chawla in the aforementioned podcast made the point that the restructuring led to fewer processes which resulted in higher productivity. From the conversation:
“I think now that it has been a few months, we are behind that and it's all publicly known in terms of what we did there in terms of team restructuring. But I do think it goes back to the point we were talking about earlier where fewer people means fewer processes. Fewer process means more time available to build. And the output is clear, right? We were able to launch three new apps in the last three months. There are a bunch of other apps in the work which are standalone. These are conversations we were not even willing to entertain, let's say, last half or let's say last year.”
Moreover, for all the complaints around data labeling and criticism around MSL hiring spree last year, Meta’s model release cadence in the last couple of months is a vindication that Meta’s top management is perhaps treated too cynically by most observers. Zuckerberg has perhaps a longer time horizon than most of the shareholders and employees (which is a recurring source of tension among these stakeholders) and as the largest and controlling owner of the company, Zuckerberg will continue to optimize for the long-term and endure through the skepticism around his decisions in the short-term.
Subscribers get the daily journal and five+ years of Deep Dives, i.e. full-length analyses with financial models on 65+ companies. The daily is just how I think out loud between the Deep Dives!
Current Portfolio:
Please note that these are NOT my recommendation to buy/sell these securities, but just disclosure from my end so that you can assess potential biases that I may have because of my own personal portfolio holdings. Always consider my write-up my personal investing journal and never forget my objectives, risk tolerance, and constraints may have no resemblance to yours.
My current portfolio is disclosed below: