← All insights

News analysisLens: United States3 min read

Microsoft's own chips already run Copilot. Maia 300 cuts Microsoft's costs first; yours depend on the contract

Microsoft plans multi-gigawatt Maia deployments from 2027 and projects 40% more tokens per megawatt than GPU systems. Customers can't select the chips; they get capacity, price and terms.

Listen to this article · 5 min

AI-generated narration of the full article.

Electricity pylons and power lines at sunset, in La Madre duotone, beside the words Tokens per megawatt
Photo: rawpixel (CC0)

If your company uses Microsoft Copilot, some of its answers are already being generated on chips Microsoft designed itself. Microsoft confirmed on October 12 that “Maia 200 is now serving Microsoft production workloads, including Microsoft Copilot,” and that GitHub Copilot and Microsoft Foundry are slated to move onto it by the end of 2026.

The bigger news was the plan. Scott Guthrie, executive vice president of Cloud and AI, announced that Microsoft will scale its Maia system to multi-gigawatt deployments starting in 2027, with Maia positioned as the primary inference system for Microsoft’s products and services. The next generation, Maia 300, “will begin production deployments in 2027.”

The claims, with their status

Microsoft expects Maia 300 “to deliver 40% more tokens per megawatt compared to leading GPU-based systems,” and, in a full 96-accelerator configuration, up to seven times the rack-scale token throughput of Maia 200. Both are projections for hardware not yet in production. For the chip already running, Microsoft reports up to 1.7 times more tokens per watt than leading GPU infrastructure for built-in AI in Teams, Copilot and Cowork. These are vendor figures without independent measurement.

The design target is specific: long-context, memory-intensive, decode-heavy work, which is what agents generate. A chat answer is short. An agent run that reads a codebase, keeps a long history and produces output step by step for an hour stresses memory and decoding, not just raw compute. Microsoft is building for that profile, with low-precision formats such as an enhanced MXFP4 meant to make larger context windows affordable.

What customers get, and what they don’t

The post does not mention pricing, SKUs or any way for customers to select Maia directly. You will not choose Maia in a deployment form the way you choose a GPU virtual machine. It sits underneath Microsoft’s own services, and Maia 200 runs OpenAI models, Microsoft’s MAI models and open-source model families there.

That means the benefits, if they arrive, arrive indirectly:

  • Capacity. More inference supply under Microsoft’s control could ease quota limits for Copilot and Foundry workloads, if Microsoft chooses to pass it on.
  • Price. Microsoft’s cost per token falls if the efficiency claims hold. Whether customer prices fall is a commercial decision, not an engineering one.
  • Long-context economics. If the hardware makes long contexts cheaper to serve, the per-token gap between short and long requests may narrow, which affects how agents are designed.

And some things move further out of sight. When the hardware under a managed service changes, behavior can change at the margins, in latency, throughput limits and, where serving precision changes, small differences in output. Customers have no visibility into which hardware served a request.

Where the chips run

Maia 200 is deploying across the United States, Europe and Australia. The post does not give regions for Maia 300. For enterprises with data residency requirements, the question is not which chip but which region; hardware changes underneath a service do not change the region a customer selected, and the contract terms on processing location still apply.

What to ask, and what not to change

There is no reason to redesign anything because of Maia. There are reasons to adjust the questions you ask Microsoft:

  1. Capacity commitments. If inference capacity is growing, ask for it in writing for your critical workloads: throughput guarantees, quota increases, and the notice period for limits.
  2. Price trajectory. Ask how lower inference costs will be reflected in Copilot and Foundry pricing over the contract term, especially for agent workloads billed per token.
  3. Change notice. Ask whether infrastructure migrations under managed models are announced, and whether evaluation results can shift. Keep your own regression set running, the discipline we argued for in model retirement as the new API deprecation.

The broader pattern is that every hyperscaler is now building its own inference economy, and the competition will show up in what a completed task costs, not in which chip computed it. We made the case for measuring exactly that in cost per completed task. Maia is Microsoft’s bet on lowering its side of that equation. Your contract decides how much of it reaches yours.

Have an AI use case stuck between prototype and production?

Tell us what you’re trying to ship. We’ll reply with honest next steps.

Discuss a use case