15B tokens per minute, the real cost of OpenAI’s superapp strategy

AI 요약

• What happened: OpenAI formalized a $122B capital raise at an $852B post-money valuation.
  • The announcement reads less like a financing note and more like a map of how ChatGPT, API usage, Codex, enterprise adoption, and compute reinforce one another.
• Core numbers: OpenAI says its API processes more than 15B tokens per minute, while Codex has more than 2M weekly users.
• Why it matters: The company is trying to combine ChatGPT, Codex, browsing, and agentic capabilities into an agent-first superapp.
  • For builders, the harder question is no longer only model quality. It is platform concentration, operating cost, and how much of the workflow should be routed through one vendor.
• Watch: The raise strengthens OpenAI, but it also makes compute dependency, pricing pressure, and product lock-in more visible.

OpenAI announced a $122 billion capital raise on March 31, 2026. Read only by date, this is already more than a month old. Read alongside Codex, Deployment Company, Dell's on-premises collaboration, Realtime API, and the broader enterprise governance push, it starts to look like a reference document for OpenAI's product strategy rather than a one-off financing headline.

The headline numbers are large. OpenAI said it raised $122 billion in committed capital at an $852 billion post-money valuation. The round was co-led by SoftBank, a16z, D. E. Shaw Ventures, MGX, TPG, and T. Rowe Price, with BlackRock, Blackstone, Coatue, Fidelity, Sequoia, Temasek, Thrive Capital, and other institutions also participating. OpenAI also said more than $3 billion was made available to individual investors through bank channels, and that several ARK Invest ETFs were expected to include OpenAI exposure.

But the valuation is not the most useful part for developers and AI product teams. The more important sections come later in the announcement. OpenAI describes a flywheel in which consumer reach, enterprise deployment, developer usage, and compute all reinforce one another. ChatGPT creates consumer habits. Those habits flow into workplace adoption. The API and Codex try to become default developer surfaces. Revenue and capital then flow back into compute.

The product bundle matters more than the money

OpenAI's post begins like a capital-markets announcement, then gradually turns into a product strategy memo. The company says ChatGPT has more than 900 million weekly active users and more than 50 million paid subscribers. It says enterprise now represents more than 40% of revenue and is expected to approach parity with consumer revenue by the end of 2026. It says the API processes more than 15 billion tokens per minute. It presents Codex as having more than 2 million weekly users, 5x growth over the prior three months, and more than 70% month-over-month growth.

Taken separately, those are growth metrics. Taken together, they tell a different story. OpenAI is treating the consumer app, enterprise product, developer API, coding agent, and compute supply chain as one system. Consumers build habits in ChatGPT. Companies adopt ChatGPT Enterprise and the API. Developers build products and internal tools with Codex and the API. That usage then becomes the reason to secure more data centers, chips, and cloud capacity.

Codex is especially important in that structure. It is becoming hard to read Codex as only a coding assistant. OpenAI's own "unified AI superapp" language puts ChatGPT, Codex, browsing, and broader agentic capabilities in the same sentence. Codex is a developer product, but it is also one part of the action layer that can move into the ChatGPT experience. A user writes an intent, Codex implements part of it, browsing retrieves information, and agentic capabilities keep work moving across tools and data sources.

That means OpenAI is not only selling "a better model API." It is trying to make user intent, developer execution, enterprise deployment, and compute supply part of one distribution surface. That is why the superapp language matters. The word is rough, and the product may not integrate cleanly in practice. But the direction is clear: OpenAI does not intend to be only an infrastructure provider behind other apps. It wants to own the surface where work starts.

Compute is not just a cost line

Large AI financing rounds are often consumed as a simple question: how much money did the company raise? In OpenAI's post, compute is not merely a cost item. It is described as the engine behind every layer of AI. More compute creates stronger models. Stronger models create better products. Better products increase adoption and revenue. Revenue and capital then buy more compute.

The infrastructure strategy is also notable. OpenAI names Microsoft, Oracle, AWS, CoreWeave, and Google Cloud as cloud partners. On the silicon side, it mentions NVIDIA, AMD, AWS Trainium, Cerebras, and a custom-chip partnership with Broadcom. For data centers, it points to work with Oracle, SBE, and SoftBank. This is a different picture from the older one-axis OpenAI-Microsoft narrative. The announcement deliberately emphasizes a multi-supplier compute portfolio.

That diversification has two meanings. First, OpenAI sees compute supply as a core bottleneck for product speed and pricing power. Second, it is trying to reduce the risk of being too deeply tied to a single cloud or chip path. In practice, dependency on NVIDIA GPUs and large cloud capacity remains substantial. Still, publicly naming many suppliers tells investors and customers that "compute portfolio" itself has become a strategic asset.

For developers, this is practical. Model pricing, latency, context-window availability, tool-calling reliability, and long-running agent stability all connect back to infrastructure. If OpenAI secures more compute, API limits may loosen, Codex-style agents may run more reliably, and Realtime voice or multimodal work may become easier to deploy at scale. If compute competition intensifies, that cost will eventually show up somewhere in product pricing. Behind every claim that a model has improved is the follow-up question: who pays for the inference?

A superapp is convenient, and it captures defaults

The agent-first superapp OpenAI describes is attractive from a user perspective. A single environment where someone can search, draft documents, edit code, browse the web, use personalized memory, and call tools is plainly convenient. Today's AI products are fragmented. People chat in one app, code in another, search in a third, then move results into company tools. OpenAI is trying to compress that fragmentation.

Developers and enterprises, however, have to read convenience and dependency together. A superapp captures the starting point. If work begins in ChatGPT, OpenAI's design choices influence which model is used, which tools are called first, which memories are retained, which payments happen, and which logs exist. Even if a developer builds a separate app, users will ask whether the same task can be done inside ChatGPT.

This resembles the mobile app store dynamic, but it is not identical. App stores captured distribution. An AI superapp can capture intent interpretation and execution routing. When a user says "prepare me for this week's customer meetings," the superapp may decide whether to use calendar, email, CRM, documents, browsing, code repositories, payments, or presentation tools, and in what order. That decision power is much larger than UI convenience.

Multi-model strategy becomes more important

As OpenAI grows larger, the question "Should we just use OpenAI?" becomes more tempting. The answer is not simple. OpenAI has obvious strengths: model performance, API quality, consumer reach, enterprise trust, Codex, Realtime, and a large compute investment plan. For small teams, that bundle is powerful. It lets them ship on a surface users already understand without first building separate infrastructure and product habits.

That is exactly why a multi-model strategy matters. Deep dependence on one vendor's product surface and API makes teams vulnerable to pricing changes, rate limits, safety policy shifts, data residency constraints, model swaps, and tool-call schema changes. Agents create stronger lock-in than simple completions. It is not just a prompt that changes. Memory, tool schemas, file access, browser sessions, approval policies, audit logs, and retry behavior all vary by provider.

The conclusion is not that teams should avoid OpenAI. It is that OpenAI dependency should be designed deliberately. First, workloads should be split into model-independent units. Search, classification, code edits, document summarization, payment preparation, and security review do not have to use the same model by default. They can be routed by failure cost, data sensitivity, latency need, and verification burden.

Second, teams need internal evaluations. Public benchmarks and vendor numbers do not answer which model works best on your customer data, internal tools, codebase shape, and review process. Third, agent logs should exist outside the provider. A team needs to know which tools were called, why they were called, which files were read, what approvals were required, and how the agent retried after failure. Fourth, cost has to be measured per job, not only per token. A Codex-generated pull request has tool calls, test runs, review fixes, and human cleanup. A Realtime agent session has voice input, voice output, handoff logic, and failure recovery.

Capital does not replace trust

A $122 billion raise is a strong signal. It gives OpenAI fuel to buy compute, hire talent, and push consumer and enterprise products at the same time. But capital is not a substitute for trust. As the company gets larger, the verification burden grows with it. If an AI superapp connects personal memory, work documents, code repositories, browsing sessions, enterprise data, and payments, the blast radius of failure grows too.

Enterprise customers should ask more specific questions than whether OpenAI is big enough. Where is data stored? What permissions does a Codex session have when it touches a repository? How are log boundaries separated across ChatGPT, API, Codex, and an enterprise workspace? If a model update breaks an existing agent workflow, is rollback possible? How much external evaluation and internal red-team evidence is shared? The more convenient the integrated product becomes, the more important those questions become.

Skeptical community reactions are understandable. Reddit discussions around the raise included questions about why so much capital is necessary, whether the compute spend ultimately flows to NVIDIA, and whether "superapp" is an inflated phrase. Some readers saw OpenAI's consumer reach and enterprise revenue as a strength. Others saw the valuation and IPO expectations as running ahead of profitability. Both readings can be partially true. OpenAI has real usage and real product surfaces. It also needs enormous capital, electricity, chips, and data centers to sustain that usage.

Watch the integration, not only the launches

The next OpenAI model still matters. But after this announcement, a more useful question is what gets connected to what. How far does Codex move into ChatGPT? What permissions does Codex receive inside enterprise repositories and deployment pipelines? How are API and ChatGPT Enterprise logs joined or separated in admin controls? How does Deployment Company change customer workflows around implementation, governance, and support?

Another thing to watch is whether OpenAI's compute portfolio translates into pricing and availability developers can feel. Multi-cloud and multi-chip strategy looks good in a financing post. Developers experience it as API latency, outage frequency, regional data residency options, model-specific quotas, and predictable cost. If OpenAI's broader compute supply improves those indicators, the raise becomes more than an investor signal. If not, the scale of the financing may say more about capital-market confidence than about day-to-day developer leverage.

The simple conclusion is that OpenAI's $122 billion raise shows both the capital intensity of the AI industry and the direction model companies are moving. That direction is not just one bigger model. It is an attempt to bind the consumer habit of ChatGPT, the developer execution surface of Codex, the product infrastructure of the API, the purchasing channel of enterprise, and the physical base of compute into one agent-first distribution system.

For developers and AI teams, the immediate question is not whether OpenAI wins or loses. It is where your product and organization should sit on that flywheel, and which parts should remain intentionally separate. Using OpenAI can be the natural choice. Letting every execution path become a superapp default is a different choice. In the AI platform era, model selection is becoming only one part of the job. The larger work is dependency design.

Sources

• OpenAI: OpenAI raises $122 billion to accelerate the next phase of AI
• OpenAI Newsroom: Recent news
• OpenAI Design Guidelines
• TechCrunch: OpenAI raises $3B from retail investors in monster $122B fund raise
• Axios: OpenAI opens the door to individual investors