Microsoft Matches GPT-5.6 with a Small Model
Microsoft says its in-house MAI model has reached GPT-5.6-level performance on common Excel tasks and can run on H100 and A100 GPUs. What truly matters is not its ranking on the leaderboard, but that Microsoft is beginning to use task-specific models to take over high-frequency workloads.
Microsoft Is Saving the Most Expensive Models for the Hardest Problems
July 25 — Microsoft CEO Satya Nadella recently disclosed that the company’s in-house MAI family of models already performs on par with GPT-5.6 across most common Excel tasks. However, it does not rely on the latest generation of AI accelerators for deployment and can run on NVIDIA H100 and A100 GPUs, resulting in lower costs.
This is not a routine model benchmark announcement. Microsoft is not trying to prove that MAI outperforms GPT-5.6 across all general capabilities. Instead, it is sending a more practical message: for production scenarios like Excel, where workflows are well defined, request volumes are enormous, and results are easy to verify, enterprises may not need to route every request to the most powerful—and most expensive—frontier model.
In other words, Microsoft is transforming its AI products from systems that “call the flagship model by default” into tiered orchestration systems—simple tasks go to inexpensive specialized models, while complex tasks are escalated to frontier models from vendors such as OpenAI and Anthropic.
That is closer to a profitable business than simply chasing the top spot on model leaderboards.
When It Comes to “Catching Up,” the Qualifiers Matter More Than the Conclusion
Microsoft’s statement contains two qualifiers that cannot be overlooked: common Excel tasks and real-world product feedback.
AI workloads in Excel are not a single problem. At a minimum, they include:
- Generating or correcting formulas from natural-language instructions;
- Cleaning, splitting, and standardizing tabular data;
- Identifying outliers and relationships in data;
- Generating pivot tables, charts, and summaries;
- Performing multi-step operations based on workbook context;
- Explaining formula errors or modifying existing analytical workflows.
These tasks differ from open-ended reasoning. They generally have clear tool boundaries, structured inputs, and results that can be automatically verified. For example, whether a formula executes, whether it references the correct range, and whether its output matches expectations can all be checked directly within Excel.
That makes them particularly well suited to reinforcement learning: the model does not merely learn whether an answer “looks right”; it can receive feedback based on whether the task was actually completed.
Microsoft says that its MAI models undergo further training in product-specific reinforcement learning environments, or RLEs. The basic idea is straightforward: start with a model checkpoint that already has coding and tool-use capabilities, place it in simulated or real Excel workflows, have it repeatedly perform tasks, and adjust its strategy based on the outcomes.
What the model learns here is not more encyclopedic knowledge, but “how to get things done in Excel.”
Therefore, saying that MAI is comparable to GPT-5.6 does not mean that it has comprehensively caught up with GPT-5.6 in general question answering, long-form text comprehension, mathematical proofs, or cross-domain agent tasks. A more accurate interpretation is: across a selected set of high-frequency Excel workflows chosen by Microsoft, a smaller, specially trained model has already reached the usability level of a flagship model.
The publicly available information does not yet include the complete evaluation set, sample size, success-rate ranges, latency data, or human-review criteria. Whether Microsoft’s claim of “comparable” performance means similar average scores or similar results on most high-frequency tasks remains to be validated with more transparent data.
The conclusion is therefore worth taking seriously, but it should not be generalized beyond the specific scenarios involved.
From Code Models to Excel, the Key Is “Climbing the Mountain,” Not Building a New One
According to Microsoft, this approach was first validated in GitHub Copilot. MAI models learned real-world workflows through product-specific reinforcement learning environments, after which those capabilities were transferred to scenarios such as Excel.
Additional information shows that Microsoft’s previously launched lightweight coding model, MAI-Code-1-Flash, achieved a higher code acceptance rate in VS Code than peer models in the same class while consuming fewer tokens. Microsoft then placed the relevant model checkpoints in Excel reinforcement learning environments for further training, transforming them from models primarily focused on code generation into task models capable of understanding spreadsheet workflows.
This approach can be compared to “climbing a mountain”:
- General pretraining first takes the model halfway up the mountain by teaching it language, code, and basic reasoning;
- Product logs and task environments provide a clearer route to the summit;
- Reinforcement learning continuously rewards actions that actually complete the task;
- Tools, context, and permission systems prevent the model from taking the wrong path;
- The result is a model that may not be able to do everything, but is sufficiently reliable in its target scenario.
The value of this approach is that Microsoft does not need to train a frontier foundation model from scratch for every Office product. It can reuse existing checkpoints and then perform separate post-training and system optimization for products such as Excel, Outlook, PowerPoint, and GitHub Copilot.
This also explains why model parameter count is not the central point of this announcement. In enterprise software, the final outcome often depends on more than the model itself. It also depends on how workbook context is organized, whether tool interfaces are stable, whether execution results can be verified, whether failures can be rolled back, and when the router escalates a task to a more powerful model.
Running on H100s and A100s Saves More Than Just GPU Procurement Costs
Nadella specifically emphasized that MAI does not require the latest generation of AI accelerators and can be deployed on H100 and A100 GPUs.
It should be noted that H100s and A100s are neither inexpensive nor ordinary hardware. However, for Microsoft and enterprise customers that have already built large-scale data centers, the supply chains, operations tools, inference frameworks, and capacity planning for these two generations of GPUs are relatively mature. The ability to continue using existing clusters means they do not have to migrate to the latest hardware every time a model is upgraded.
The true cost of enterprise AI deployment is also not limited to the listed price per million tokens. It is the sum of multiple expenses:
- GPU time consumed by each inference request;
- The number of input and output tokens;
- Time to first token and total task completion time;
- Peak capacity that must be reserved as concurrency increases;
- Memory usage caused by long contexts;
- The cost of retrying failed tool calls;
- Procurement costs and contractual risks associated with external model APIs;
- Costs related to data residency, auditing, and private deployment.
If a smaller MAI model can maintain the same success rate on common Excel tasks, its advantages will be magnified by the enormous scale of requests. Saving a few cents on a single formula-generation task means little, but when Office products process massive volumes of requests every day, the difference directly affects Microsoft’s gross margin.
More importantly, task-specific models can often reduce unnecessary token usage. General-purpose models typically need to ingest extensive instructions and context to understand the state of a product. A deeply integrated specialized model, by contrast, can complete operations using structured state, fixed tools, and shorter prompts. The cost reduction comes not only from a smaller model, but also from a system that understands the product better.
However, Microsoft has not yet published standardized inference pricing, throughput, power consumption, or specific cost reductions relative to GPT-5.6 for Excel workloads. At this stage, it is possible to conclude that the hardware requirements are lower, but not to infer the cost savings under every deployment scenario.
“Frontier Diffusion & Control” Is What Microsoft Really Wants to Sell
Nadella calls this strategy “Frontier Diffusion & Control.” Its central premise is that enterprises will not remain tied to a single model for every task over the long term. Instead, they will dynamically orchestrate models based on performance and cost.
In the system Microsoft describes, frontier models from OpenAI and Anthropic will continue to coexist with MAI. Models are only one component of an agent system. Product performance is also shaped by:
- Control: determining which actions a model may perform and when it should stop or escalate;
- Memory: retaining user preferences, historical actions, and long-term task state;
- Context: providing the model with the current workbook, code repository, or email thread;
- Tools: allowing the model to read cells, run formulas, and modify files;
- Skills: packaging reliable multi-step workflows as reusable capabilities;
- Interaction: asking users for confirmation before high-risk actions and clearly displaying changes.
This effectively weakens the narrative that “one supermodel can do everything.”
A mature enterprise AI system might use routing logic like this: highly deterministic requests, such as formula completion and formatting cleanup, go to MAI; tasks involving cross-workbook reasoning, ambiguous business requirements, or complex planning are routed to frontier models such as GPT-5.6; and requests involving sensitive data are switched to deployment modes that comply with specific data-boundary requirements.
This architecture is not unfamiliar to developers. A growing number of applications already implement model routing, fallback mechanisms, and closed-loop evaluation. The difference is that Microsoft controls Azure, Office, GitHub, and vast amounts of real-world product feedback, allowing it to connect training, distribution, monitoring, and monetization into a complete pipeline.
The value of multi-model API aggregation platforms will also increase as a result. Platforms compatible with the OpenAI API format, including OpenAI Hub, can reduce the cost of switching among models such as GPT, Claude, Gemini, and DeepSeek. But the truly difficult challenge has shifted from “how many models can be integrated” to “how evaluations and business metrics should determine which model handles each request.”
Does This Mean Microsoft Is Starting to Replace OpenAI?
The answer is: for some high-frequency tasks, yes; at the overall strategic level, no.
The relationship between Microsoft and OpenAI is evolving from straightforward procurement and investment into a more explicit mix of competition and collaboration. Microsoft needs OpenAI’s frontier capabilities to maintain Copilot’s performance ceiling, while it also needs MAI to control costs, latency, and product release cycles.
If every Office request depends on external frontier models, Microsoft faces three problems:
First, its unit economics are controlled by external suppliers. The more active Copilot users become, the higher inference costs may rise, while subscription revenue may not increase enough to cover them.
Second, product iteration becomes dependent on model release cycles. If the Excel team wants to improve formula generation, it should not have to wait for the next generation of general-purpose models to be released.
Third, Microsoft cannot fully embed the advantages created by product data into its own models. By training MAI through RLEs, it can directly turn real-world workflows into a proprietary capability moat.
Frontier models nevertheless remain important. Specialized small models excel at high-frequency tasks with clearly defined boundaries, but are more likely to fail on out-of-distribution problems. Microsoft needs a fallback mechanism that calls a stronger model when the system is uncertain, rather than forcing a weaker model to struggle merely to save costs.
The proper positioning of MAI, therefore, is not as an “OpenAI killer,” but as Microsoft’s private-label offering within its model supply chain: high-frequency components that it can produce itself no longer need to be entirely outsourced, while the most advanced and hardest-to-replace capabilities will still be procured and jointly developed.
A Lesson for Developers: Optimize Routing Before Obsessing Over Upgrades
The most valuable lesson for development teams from Microsoft’s move is not that they should immediately train their own foundation models, but that they should reconsider how they select models.
One practical approach is:
- Extract the highest-volume task categories from production logs;
- Build evaluation sets that reflect business outcomes rather than relying only on general-purpose leaderboards;
- Compare the task success rates, latency, and total costs of models at different tiers;
- Use small models, fine-tuned models, or fixed workflows for clearly structured tasks;
- Automatically escalate to frontier models when confidence is low or tool execution fails;
- Continuously collect user edits, acceptances, and undo actions to create new training and evaluation data.
The easiest mistake to make here is comparing only API prices. If a cheaper model has a low success rate and requires repeated retries, its final cost may be higher. If an expensive model completes a complex task in one attempt, it may offer better value. What should be compared is the total cost per successful task, not the price of an individual token.
This is essentially what Microsoft means by the “cost-outcome frontier”: finding the least expensive, fastest, and most scalable combination that meets an acceptable quality threshold.
MAI’s Significance Is Not About Winning a Leaderboard
As of July 25, Microsoft has not provided enough complete data for outsiders to independently determine exactly how close MAI is to GPT-5.6 on Excel tasks. For now, the claim that it has “caught up” should still be regarded as Microsoft’s conclusion based on internal evaluations and product feedback, rather than a general fact verified by third parties.
The strategic direction, however, is already quite clear.
Frontier models will continue to raise the capability ceiling, while specialized models will distribute those capabilities to hundreds of millions of users at lower cost. Microsoft intends both to use models from OpenAI and Anthropic and to have MAI handle workloads that are standardized, verifiable, and extremely high in volume.
Over the past two years, industry competition has centered on who can train the most powerful model. The next, more practical phase of competition will take place at another layer: who can organize different models, contexts, tools, memory, and permissions so that every request is affordable and actually gets the job done.
From this perspective, MAI matching GPT-5.6 on Excel tasks is not the destination, but a cost-control blueprint. It shows how the capabilities created by frontier models are being broken down into smaller, more specialized, and more easily deployable production components.
For Microsoft, this is not only technological autonomy, but also control over its own profitability.
References
- ITHome: Nadella Says Microsoft’s In-House MAI Model Performs on Par With GPT-5.6 on Excel Tasks at Lower Deployment Cost—Summarizes Nadella’s main statements regarding “Frontier Diffusion & Control,” Excel reinforcement learning environments, and deployment on H100 and A100 GPUs.



