Two stories landed in the same week, and together they change how you should think about which AI models you build on. Anthropic's revenue run rate has reportedly reached around $30 billion, ahead of OpenAI's roughly $24 billion. And Meta — the company that made open-weight models a default option for developers — has reportedly moved its next flagship away from open release toward a proprietary model built by its Superintelligence Labs group.
If you ship software that calls a model API, or you fine-tune open weights, both facts touch your roadmap. Here is what we read into them, and what we would change.
The revenue flip is a signal about enterprise demand
The headline: Anthropic at a roughly $30B run rate, OpenAI at roughly $24B. Treat both as estimates. A run rate annualizes a single recent month, so it projects forward instead of reporting a finished year, and neither company publishes audited numbers. The direction matters more than the decimal place.
The mix is more telling than the totals. Anthropic's lead is reported to come from enterprise Claude adoption, with the number of customers spending more than $1 million a year roughly doubling in two months. Enterprise contracts behave differently from consumer subscriptions — they carry procurement cycles, security reviews, and multi-year commitments. A provider that wins them tends to keep them.
For you, that has two practical consequences. First, the model you pick is also a bet on which provider has the revenue to fund the next training run. Second, enterprise revenue pulls a provider's roadmap toward enterprise needs — longer context, reliable tool use, compliance features, predictable pricing — and away from chasing benchmark headlines. If you build developer tools, that pull usually works in your favor.
A run rate is not annual revenue. "$30B run rate" means a recent month multiplied by twelve. That is a useful momentum signal and a poor substitute for an audited annual figure. When a number like this drives a stack decision, write the assumption down next to it.
Meta closing Llama narrows the open-weight bet
For three years, "use Llama" was a real answer to "what happens if my API provider raises prices or changes its terms?" Open weights let you run a model on your own hardware, fine-tune it without asking permission, and keep data off a third party's servers. Meta funded the most visible version of that option.
The reported shift — Meta's next flagship arriving from its Superintelligence Labs group as a proprietary model rather than an open release — does not erase that option. Existing Llama weights still work, and other open-weight families from Mistral, the Qwen line, and others keep shipping. What it removes is the assumption that a heavily funded open model would keep pace with the closed frontier. The open-weight tier is now more clearly a deliberate trade: you accept a capability gap in exchange for control.
That trade still pays off for plenty of workloads — data that cannot leave your infrastructure, cost-sensitive high-volume tasks, latency-critical paths, anything you need to run air-gapped. What changed is that you should stop assuming the gap will close on its own. Plan around the model you can get today, not the one you hope gets open-sourced next year.
How to recalibrate your stack now
You do not need to rip anything out this week. You do need to make a few assumptions explicit.
Abstract the model boundary. If your code calls one provider's SDK directly in fifty places, a price change or a deprecated model becomes a fifty-file edit. Route model calls through a single internal interface — a thin wrapper you own, or a gateway — so swapping providers is a config change. Cursor does this at the editor level; your production code deserves the same seam.
Re-test prompts across providers. Prompts are not portable. One tuned on a single model can score noticeably worse on another. If you want provider flexibility to be real, keep an evaluation set and run it against at least two models on a schedule, not once.
Sort features into "needs the frontier" and "needs control." Frontier-capability work — hard reasoning, agentic tool use — argues for a closed API from a provider with revenue momentum. Control-sensitive work — private data, high volume, air-gapped deployment — still argues for open weights, with clear eyes about the capability gap.
Watch contract terms, not just benchmarks. With enterprise revenue now the battleground, the differences that bite you are rate limits, data-retention defaults, deprecation notice periods, and pricing tiers. Read those before you commit a production path to a provider.
A single hard-coded provider SDK spread across your codebase is the most expensive assumption on this list. You will not feel the cost until a model is deprecated or a price changes — and then it is an emergency migration instead of a config edit. Add the abstraction layer before you need it.
This week's news does not crown a permanent winner. Revenue leads change, and an open-weight resurgence is still possible. The durable lesson is narrower: build so the model is a swappable component, because the providers themselves are still trading places.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.
