The short answer
Bloomberg reported on 7 July 2026 that Microsoft has started routing some Microsoft 365 Copilot requests in Excel and Outlook to its own in-house MAI models rather than OpenAI and Anthropic, to cut third-party AI costs. Tens of thousands of prompts a week now run on MAI — still a small share of total Copilot volume — and AI chief Mustafa Suleyman said the aim is to keep trimming outside spend, eventually ending payments to Anthropic entirely.
For teams building software in US and EU markets, the takeaway is not “pick MAI” or “drop OpenAI.” It is architectural. When the biggest AI buyer diversifies away from single providers, provider concentration becomes a first-class design concern — and the cheapest insurance is a model-abstraction layer that makes switching or mixing providers a configuration change, not a rewrite.
What did Microsoft actually change?
The change is about which engine runs behind the same button, not a new feature. Microsoft 365 Copilot — the AI woven into Excel, Outlook, Word and Teams — has leaned heavily on OpenAI models, with Anthropic models added for some tasks over the past year. According to Bloomberg's 7 July report, Microsoft is now quietly routing a slice of those requests in Excel and Outlook to its own MAI family instead. Users see the same Copilot; the model answering has changed underneath.
Two numbers frame the scale. The in-house models handle tens of thousands of prompts per week, which sounds large but is a small fraction of total Copilot traffic — this is a gradual, measured migration, not a hard cutover. And it is set to widen: Microsoft has signalled the MAI models will extend to GitHub Copilot and Teams, and that its own speech-transcription models will move into Teams video calls. If your product embeds Copilot or builds on the Microsoft AI stack, the model behind your AI and data features may shift without any action on your part — a good reminder to know which model you actually depend on.
Microsoft has not walked away from its partners. It remains a major backer of OpenAI and still routes plenty of Copilot work to external models. The accurate framing is diversification: adding an owned option alongside bought ones, then shifting the mix where its own models are good enough and cheaper.
Why in-source models it helped fund?
Cost and control, in that order. Serving frontier models to hundreds of millions of Office users is one of the largest inference bills on earth, and every prompt sent to an outside provider is margin handed to a supplier. Owning the model collapses that per-token cost, removes a dependency, and lets Microsoft tune models tightly to its own products and telemetry. Suleyman has been explicit that reducing outside spend — and ultimately ending payments to Anthropic — is the goal.
What makes it viable now is that MAI has become good enough for a growing share of real work. At its Build conference in June 2026 Microsoft unveiled seven new models at once, and reporting indicates one of them approaches Anthropic's previous-generation Opus 4.6 on code generation at a lower price point. That is the quiet part of the whole story: for routine assistant tasks — summarising an inbox, drafting a formula, cleaning a spreadsheet — a cheaper in-house model now lands close enough to a frontier model that the price difference wins. The frontier still matters for the hardest work; it is no longer the only defensible choice for the easy work.
Why is this a signal, not just a Microsoft story?
Because of who is doing it. Microsoft is among the largest buyers and distributors of AI in the world, and it co-invested in the very models it is now routing around. When a customer with that much leverage and inside knowledge decides the smart move is to build its own option and diversify supply, it is telling the market something: capable models are commoditising, switching costs are the real risk, and depending on one provider is a position to engineer out of — not a partnership to lean into.
Most teams cannot copy the tactic; almost no one should build a frontier model. But the strategy generalises cleanly. You do not need Microsoft's scale to treat models as an interchangeable, competitive input rather than a fixed dependency. The teams exposed here are the ones that wired their product to exactly one provider's API, with that provider's quirks and pricing baked through the codebase, and no tested path to anything else. When that provider reprices, rate-limits or deprecates a model, they discover how much of their architecture was really the vendor's.
What it means for US & EU software teams
Turn the headline into three engineering habits. First, put a provider-agnostic abstraction between your business logic and any model, so provider and model name are configuration rather than assumptions scattered across the code. Second, evaluate at least one cheaper or open-weight alternative per task, on your own data and your own quality bar — the Microsoft story is proof that “good enough and cheaper” beats “best and priciest” for a large share of routine work. Third, keep a fallback model configured and tested, so a price change, quota cap or outage degrades gracefully instead of taking the feature down.
The stakes are higher in regulated verticals. In FinTech and other audited domains, “we depend on a single AI provider with no alternative” is a concentration risk that operational-resilience and vendor-risk reviews will flag by name. A portfolio approach — a primary model, a tested fallback, an abstraction that makes the swap routine — is not just cheaper; it is the posture a resilience assessment expects. Design it in early, because retrofitting an abstraction into a product that assumes one vendor is far more expensive than building it from the start.
None of this means chasing the cheapest model everywhere or churning providers for sport. It means treating your model choice as a portfolio you rebalance as prices and quality move — match capability to task, keep the option to change your mind cheaply, and never let a single supplier hold your product's roadmap.
A model-portability checklist
No new deadline here — just the work that turns a vendor's next move into a shrug:
- Add an abstraction layer. Route every model call through one internal interface so provider and model are config, not code sprinkled across the app.
- Know your dependency. Write down which model powers each AI feature and what breaks if it changes — you cannot manage a dependency you have not named.
- Benchmark an alternative per task. Test a cheaper or open-weight model on your own data for each task; keep the ones that land within your quality bar.
- Configure and test a fallback. Wire at least one alternate provider and actually exercise the failover, so it works when you need it.
- Instrument cost and quality per feature. Log tokens, latency and an eval score so rebalancing is driven by evidence, not vibes.
- Rebalance on a cadence. Model prices and rankings shift monthly; revisit the mix on a schedule instead of treating the first choice as permanent.
This is not investment or procurement advice, and the right model mix depends on your workloads, quality bar and markets. But the strategic signal from Microsoft's move is clear: even the biggest buyer refuses to be locked in — so build the machinery that keeps your options open.
Frequently asked questions
What did Microsoft actually change?
Bloomberg reported on 7 July 2026 that Microsoft has started routing some Microsoft 365 Copilot requests in Excel and Outlook to its own in-house MAI models instead of OpenAI and Anthropic. Tens of thousands of prompts a week now run on MAI, though that is still a small fraction of total Copilot volume. Microsoft AI chief Mustafa Suleyman framed the goal as cutting third-party AI spend over time, and said Microsoft eventually wants to stop paying Anthropic entirely.
Why is Microsoft moving away from OpenAI models it helped fund?
Cost and control. Serving frontier models at Microsoft's scale is enormously expensive, and Microsoft now has its own MAI family — including seven models unveiled at Build in June 2026, one reportedly matching Anthropic's previous-generation Opus 4.6 on coding at lower cost. Owning the model lets Microsoft cut per-token spend, reduce dependency on outside providers and tune models to its own products. It has not dropped OpenAI or Anthropic; it is diversifying.
Does this mean teams should build their own models too?
For almost all teams, no. Microsoft has data-centre scale, research staff and demand that justify building. Most product teams should keep buying frontier models but stay portable — put an abstraction layer between the product and the provider so you can switch or mix models as price and quality change. The lesson is not build-your-own; it is do not hard-wire a single vendor.
What is model in-sourcing and why does it matter as a signal?
In-sourcing is when a company that buys AI heavily starts building and serving its own models to reduce reliance on outside providers. It matters because Microsoft is one of the largest AI buyers in the world; when the biggest customer diversifies away from a single supplier, it signals that capable models are commoditising and that provider concentration is a cost and resilience risk worth engineering around.
What should engineering leaders do this quarter?
Put a provider-agnostic abstraction between your app and any model, evaluate at least one cheaper or open-weight alternative per task on your own data, configure a fallback model, and instrument cost and quality per feature so a price or availability change is a config edit rather than an incident. Treat model choice as a portfolio you rebalance, not a one-time bet.
Sources
Bloomberg — Microsoft Replaces OpenAI, Anthropic With Own AI in Some Apps (7 July 2026)
CNBC — Microsoft unveils new AI models to lessen reliance on OpenAI and lower costs for developers (2 June 2026)
The Decoder — Copilot goes cheap as Microsoft phases out OpenAI and Anthropic models to cut costs (July 2026)