Canva slashed its 2026 revenue forecast by a third. CEO Melanie Perkins told shareholders that several first-party models were not yet ready for release, and that pricing, consumption models, and usage controls had not caught up with outsized demand. Canva had built its AI features on frontier models from other providers. When those providers changed the economics underneath the product, Canva's revenue forecast collapsed.
Microsoft's AI revenue depends on OpenAI for roughly 70 percent. The largest software company on earth, with more AI engineers than almost any competitor, is essentially reselling another company's models. If OpenAI changes its roadmap, raises prices, or slows down, Microsoft's AI revenue is exposed.
Your Model Is Not Your Product (Note #130, July 16) argued the next trillion-dollar opportunity is implementation, not models. Seven Weeks at the Top, Then Irrelevant (Note #121, July 7) showed that model churn is permanent. This is the financial consequence of those two facts. When your product runs on a model you do not control, your revenue is a tenant on someone else's roadmap. And the landlord can raise the rent whenever they want.
WHAT CANVA ACTUALLY LOST
Canva relied on third-party frontier models to drive its AI features. The bet was simple: integrate frontier model capabilities, ship AI-powered design tools, grow revenue on the back of AI differentiation. The reality was different. First-party models were not ready. Pricing and consumption models did not catch up with demand. The revenue forecast was cut by a third.
When you build a product feature on a third-party API, you are making three bets. You are betting the model will stay capable enough for your use case. You are betting the price will stay within your margin. You are betting the provider will not change the API, the terms, or the availability. If any one of those bets fails, your feature is hostage. Canva's case shows what happens when all three bets are exposed at once.
This is not a failure of execution. Canva is a well-run company. It is a failure of architecture. The architecture assumed the model layer was stable enough to build a revenue forecast on. It was not.
THE 70 PERCENT PROBLEM
Microsoft's dependency on OpenAI for 70% of its AI revenue is not a startup problem. It is a structural problem at scale. Microsoft has more AI engineers, more compute, and more capital than almost any company on earth. Its AI revenue is still 70% dependent on a partner whose roadmap it does not control.
Bloomberg reported the figure based on Microsoft's own disclosures. In FY2026, Microsoft recorded $24.1 billion in revenue from commercial arrangements with OpenAI. Microsoft's stated AI annual run rate was $37 billion. The math is straightforward. OpenAI is not a supplier. OpenAI is the business.
If Microsoft cannot diversify its model dependency at its scale, a startup building on a single frontier API has a concentration risk that is orders of magnitude worse. The question is not whether you depend on a third-party model. Most teams do. The question is what percentage of your revenue is exposed, and what happens to that revenue if the model provider changes the terms.
For Microsoft, the answer is $24.1 billion. For Canva, the answer is a third of the forecast. For your company, the answer is whatever percentage of your revenue depends on a model you do not control.
WHY THE PROVIDERS ARE VERTICALLY INTEGRATING
Anthropic confirmed plans to build an in-house custom silicon team to design chips for running its models. OpenAI unveiled a custom inference chip called Jalapeno developed with Broadcom. Google, Meta, and Mistral are all pursuing custom silicon. The frontier model providers are vertically integrating down the stack: model, inference runtime, and now silicon.
The providers are not just building better models. They are building the entire stack, from the chip to the API. Every layer they own is a layer they can optimize for their own economics, not yours. When Anthropic designs its own chips, it optimizes for Anthropic's margin. When you call the Anthropic API, you pay the price that Anthropic's silicon economics dictate. You have no leverage.
The GPU Era Is Not Ending. It Is Fragmenting (Note #153, August 8) showed that the hardware layer is splitting into proprietary stacks. The model layer is commoditizing. The companies that own both layers will set the price. The companies that own neither will pay it.
This is the same pattern that played out in cloud computing. AWS built its own chips. Google built TPUs. The customers who depended on generic Intel instances paid more per unit of compute than the customers who optimized for the provider's proprietary stack. The difference in AI is that the stack is moving faster, and the price swings are larger.
THE COMMODITIZATION TRAP
The company that made open weights mainstream is now competing primarily on price discounts. Meta released Muse Spark 1.2 at 20 cents per million output tokens in exchange for user data. The standard tier is $4.25 per million output tokens. Western competitors charge between $10 and $30 per million output tokens. Chinese providers start at 18 cents.
The model layer is commoditizing. When models compete on price discounts, the capability gap has closed enough that buyers choose on cost. This is good news if you are a model consumer (prices go down). It is bad news if you built your product on the assumption that your model provider's capability advantage would persist. If your AI feature was differentiated because it ran on the best model, and now every model is roughly equivalent, your differentiation is gone. Your product is a commodity riding on a commodity.
Alibaba is testing new business models for its Qwen open-source line, exploring premium services and enterprise support layered on top of free models. The next Qwen model will stay open-weight, but the largest commercial users may have to negotiate a revenue-sharing agreement. Moonshot has experimented with this model, asking partners for up to 30% revenue sharing once they cross $20 million in annual sales, though such terms shift as release schedules and model roadmaps change.
The open-source model is evolving into a freemium model. Free for the many, paid for the few who make serious money from it. If you are one of the few, your cost structure just changed.
THE COST CONTROL LAYER
Atlassian is urging companies to rein in AI spending. The company implemented monthly AI wallets with caps ranging from $500 to $2,000 per employee depending on role. Uber reportedly exhausted its AI budget within four months. Amazon has instructed staff to curtail discretionary AI use.
Rippling found it was burning 40% of its R&D budget on AI tokens. One engineer was spending $50,000 a month. Spending was growing 80% month over month. If the trend continued, Rippling would spend almost as much on AI tokens as it spent on its entire R&D headcount.

Model routers are becoming standard infrastructure. OpenRouter, Not Diamond, LiteLLM, and Salesforce are all building routing layers that direct queries to the cheapest model that can handle the task. Salesforce president David Ward says cost control is only the first phase. The real value is building an architecture that lets you swap models without rewriting your product.
The AI Cost Control Crisis Is Here (Note #145, July 31) showed that architecture, not budget, determines who survives. Your Router Is the Moat, Not Your Model (Note #141, July 27) showed that routing is the architectural moat. The cost control story has been told from the operator side (how to manage your token spend). Canva's story is the product side (how your dependency on a model provider becomes a revenue liability).
Cost control and vendor dependency are the same problem viewed from different angles. The operator managing token spend is managing the symptom. The product leader whose revenue depends on a third-party model is managing the cause. If you control your model layer (through fine-tuning, distillation, or open-weight deployment), you control your cost. If you do not, your cost is whatever the provider charges, and your revenue is whatever you can charge on top of that spread.
THE DECISION FRAMEWORK
Here is a concrete framework for evaluating model dependency risk. Three bets, each with a hedging strategy.
Bet 1: Capability. The model stays capable enough for your use case.
Hedge: Fine-tune a smaller open-weight model on your specific task. LoRA Can't Teach Your Agent Procedures (Note #142, July 28) showed full fine-tuning beats LoRA on procedural tasks. If your use case is procedural, invest in full fine-tuning of an open-weight model. You lose frontier flexibility, but you gain capability you control.
Bet 2: Price. The model's price stays within your margin.
Hedge: Build a model router. Route simple tasks to the cheapest model that can handle them. Route complex tasks to the frontier model. The router is the moat (Note #141). It lets you swap models without rewriting your product. Rippling cut its token cost from 40% of R&D headcount budget to about 15% by routing to cheaper models. The cost of July's token spend was 37% of April's cost, even though usage stayed flat.
Bet 3: Availability. The provider does not change the API, terms, or access.
Hedge: Maintain a fallback model. If your primary provider changes terms, you need a second model that can take over. This means abstracting your model calls behind an interface, not hard-coding to a specific API. If your code calls OpenAI's API directly in 50 places, you cannot switch. If it calls your own abstraction layer, you can switch in one place.
WHAT TO DO TODAY
- Calculate your model dependency ratio. What percentage of your AI-powered revenue depends on a single model provider? If it is above 50%, you have a Canva-level concentration risk.
- Audit your API integration. Is your model call abstracted behind an interface, or is the provider's API hard-coded throughout your codebase? If it is hard-coded, you cannot switch providers without a rewrite.
- Identify your top 3 AI features by revenue. For each, ask: if the model provider raised prices 2x tomorrow, would the feature still be profitable? If no, you have no margin buffer.
- Test an open-weight fallback. Pick one feature and get it running on an open-weight model (Qwen, Kimi, Llama). It does not need to match the frontier model. It needs to be good enough to ship if your primary provider changes terms. For a local fallback, a single 24GB GPU (like an RTX 4090) runs a 7B to 13B model comfortably, and a 48GB card (like an A6000) handles a 30B model. If you do not have the hardware, rent a cheap GPU instance or use a hosted open-weight endpoint instead of buying silicon up front.
- Build or buy a model router. Route your simplest tasks to the cheapest model. Measure the quality difference. If your users cannot tell, you have found your hedge. Two ways to set this up: use a hosted gateway like OpenRouter, which exposes one API and lets you set per-model price and quality rules without writing code, or run LiteLLM as a self-hosted proxy that sits in front of your providers and routes by cost, latency, or capability. Both let you swap the underlying model by changing a config line, not by rewriting your product.
- Read Note #130 again. Your Model Is Not Your Product. The model is the engine. The product is the car. If you do not own the chassis, the engine supplier decides where you drive.
THE UNCOMFORTABLE QUESTION
Canva built its AI features on someone else's model and lost a third of its revenue forecast. Microsoft, the largest software company on earth, depends on OpenAI for 70% of its AI revenue. If your product runs on a model you do not control, what percentage of your revenue is actually yours?
Get More Articles Like This
Getting your AI agent setup right is just the start. I'm documenting every mistake, fix, and lesson learned as I build PhantomByte.
Subscribe to receive updates when we publish new content. No spam, just real lessons from the trenches.
Build Real AI Infrastructure
PhantomByte teaches you to build real AI infrastructure yourself: local AI stacks, autonomous agents, multi-agent orchestration, web scraping, and custom tools. Step-by-step PDF tutorials you download, follow, and deploy. No subscriptions. No fluff. Just skills that ship.
