Phi-4 is the Runtime. MAI-1 is the Reason.

Everyone keeps asking the wrong question, is MAI one better than 5/4? Which one should we standardize on? That question was already outdated, the moment Microsoft shipped both of them on purpose in the same month. Here is the tension nobody is naming. Microsoft just released two completely different types of intelligence, not a bigger version and a smaller version of the same thing, two different organs built for two different jobs. Most of the coverage treats them like they are fighting for the same spot on the podium. But they are not MI1 and 5/4 are not rivals, they are not competing for the same job inside your stack. By the end of this, you are going to understand the actual architecture Microsoft is building toward, not a feature list, not a benchmark chart, the real system. If you are the kind of person who has to design this stuff for a living, subscribe now. Because this split is going to define how M365 admins and architects build systems for the next five years. The question everyone is getting wrong. So let's start with how most people are covering this. It explains why so many teams are about to make expensive mistakes. Watch any breakdown of MI1 and 5/4 and it turns into a leaderboard battle, which one scores higher on this benchmark, which one is faster, which one is smarter per parameter, bigger versus smaller. Like it is a heavyweight fight and somebody has to lose. That framing comes from consumer AI thinking. It is the same instinct that made everyone argue about which chatbot writes better emails. And look, that instinct isn't stupid, it is just built for the wrong problem. When you are a consumer picking one assistant for one phone, which model is better is actually the right question. You only get to pick one, but enterprise system design does not work that way. It never did. Nobody runs one server for every workload. Nobody uses one storage tier for every file. So why would anybody assume there is supposed to be one model for every request? This is worth naming directly. It is the assumption sitting underneath almost everything written about this launch. Call it the model thinking. The old belief that one system has to win. The idea that intelligence is a single throne and somebody is sitting on it. That belief made sense when there was basically one option, rent GPT or rent something else, but that is not the world Microsoft just built. Here is the reframe. Microsoft is not choosing a winner between MI1 and 5/4. It is building a division of labor. Once you see it that way, the leaderboard question falls apart because you are not supposed to pick one. You are supposed to know when to use which. So let's set up the two words that are going to anchor everything from here forward. Reason and runtime. Reason is the deep layer, the part that plans, the part that weighs options, it figures out what should actually happen next in a complicated multi-step problem. Runtime is the fast layer, the part that executes, the part that responds instantly. It lives close to wherever the work is actually happening. MI1 sits in the reason slot, 5/4 sits in the runtime slot. Once you frame it that way, comparing their benchmark scores directly is a mistake. It is like comparing a company's strategy team to its shipping department and asking which one is better. Wrong question. They are not measured against each other. They are measured against the job they were built for. That is why benchmarks alone cannot tell you what to do with either of these models. A number on a leaderboard does not tell you where a model belongs in your architecture. What tells you that is understanding what actually happened at Bill 2026? That is when Microsoft laid this whole strategy out in public and what actually happened at Bill 2026. So here is what actually got announced. The framing matters more than the coverage. Mustafa Suleiman walked on stage and unveiled seven new MI models in one sitting, not one flagship, not a single headline model. Seven spanning reasoning, coding, image generation, voice and transcription all released together, all trained by Microsoft's own team from scratch. And alongside that, 5/4 kept expanding too. More variance, more sizes, still shipping on its own track, two families growing at the same time in the same event. Microsoft didn't call this a product launch. They called it humanist superintelligence. State of the art capability across modalities, but explicitly designed to serve people and organizations not replace them. You can take that branding with a grain of salt if you want. That's fair. But underneath the phrase is a real claim. These models are meant to work across text, code, image, voice, and reasoning as one coordinated system, not a scattered side projects. Now here is the part that actually explains why this happened right now in this exact window and not two years ago. Until late 2025, Microsoft literally could not build frontier models. That wasn't a strategy choice. It was contractual. The original OpenAI partnership signed back in 2019, restricted Microsoft from independently pursuing frontier level AI or superintelligence on its own. So for years, Microsoft's entire AI story was really OpenAI's AI story, wearing a Microsoft badge. Every leap in capability ran through somebody else's lab first. That changed when the contract got renegotiated. And once that restriction lifted, Microsoft didn't ease into building its own models. It sprinted. Think about what that actually means strategically. In under a year, Microsoft went from being a distributor of intelligence to being a builder of it. Those are completely different businesses. A distributor's job is picking the best thing off somebody else's shelf and packaging it well. A builder's job is deciding what gets made in the first place, what trade-offs get baked in, what the model is actually for. Microsoft crossed that line in months, not years. And normally, when you hear seven new models shipped in one announcement, you assume some giant sprawling org chart behind it. Thousands of researchers, endless review cycles. The usual big company machinery. That's not what happened here. Suleiman described teams of around 10 people building these models. Flat structure. No bureaucracy stacked on top of them. More like a trading floor than a research lab. People working shoulder to shoulder. Moving fast because there was nobody above them slowing the decision down. That detail matters more than it sounds like it should. Small teams building frontier class models in parallel only works if each team has a narrow, clear job. You can't have 10 people own AI broadly. You can have 10 people own reasoning. 10 people own transcription. 10 people own image generation. The org structure itself is already a division of labor before a single line of code gets written. And that's the real signal buried in this announcement. Speed like this. Across seven models plus a whole separate 5/4 track doesn't happen when everyone's building slightly different versions of the same general purpose thing. It happens when the jobs are already split. Small teams move fast because they're not fighting over what the model should be. They already know. Which means the reason and runtime split we just laid out wasn't an accident that emerged later. It was baked into how Microsoft built these models from day one to different design philosophies. So now that you know why these teams moved fast, let's get into why they built two different things instead of one better thing. MAI-1 is built for scale and reasoning depth. 5/4 is built for density and deployment speed. That's not a difference in quality. It's a difference in what problem each model is solving before it even gets asked a question. Here's where you need two words that sound technical but really aren't. Dense and Sparse. Think about a company where every single employee has to sit in on every single meeting no matter what it's about. That's a dense model. Every parameter fires for every request. Whether the question is what's two plus two or restructure our entire supply chain. Nothing gets to sit out. That's 5/4 approach and on purpose. It's a dense transformer with a small parameter count. Meaning there's less total headcount in the building but everyone who's there is working every time. Now picture a different company. Hundreds of specialists on staff. But for any given meeting only the three or four people who actually know that topic show up. Everyone else stays at their desk. That's Sparse. That's MI1. It's a mixture of experts model. Meaning there's a massive total roster of expertise sitting inside it but only a slice of that roster activates per token. Huge capacity on paper, partial activation in practice. That distinction is why you can't just say bigger is smarter and move on. MI1's total size is enormous but it's not paying the full cost of that size on every single request because most of the model is sitting quiet at any given moment. If 5/4 doesn't have that luxury and doesn't need it, it's small enough that using all of itself every time is still cheap. High quality per parameter is the whole design goal. Nothing wasted, nothing held in reserve because there's nothing to spare in the first place. Here is why this isn't just an engineering detail you can skip past. Picking the wrong one for a workload doesn't just make things slightly worse. It actively burns money or staff's capability depending on which way you get it wrong. Send a two sentence customer question through a Sparse, Frontier Scale Reasoning System and you're paying for a roster of specialists to show up for a meeting that needed one intern. Send a genuinely complex multi-step planning problem through a small dense model and you're asking a lean, fast team to solve something that actually needed deep, specialized reasoning they don't have on staff. Neither failure shows up as the model was bad. It shows up as a budget line that's too high or an output that's quietly, consistently shallow. That's the stakes, not which model wins a benchmark but which one you handed the wrong job. And this is where the abstract idea of dense versus Sparse turns into something you can actually put a number on because once you look at what these architectures cost to run and what they can actually hold in memory at once, the gap between reason and runtime stops being conceptual and starts being a line item. The compute economics nobody talks about, let's put actual numbers on this. The story of dense versus Sparse models only becomes real once you see what it costs to run them. Start with the context window. MI1 reportedly holds two million tokens in a single window which is roughly double what GPT-5 carries. But this isn't just about having more room. It is the difference between feeding a model a single chapter and feeding it the entire book, the footnotes and the author's previous three drafts all at once. That window matters for the exact jobs MI1 is supposed to handle. We are talking about sprawling multi-step reasoning problems. We're losing context halfway through means the entire answer falls apart. Now look at the price. MI1 runs around $0.001 per 1,000 tokens. 5.4 has a marginal cost that is close to zero once it is sitting on your local hardware. It is not literally zero because electricity costs money but it is close enough that it stops feeling like a meter of expense. That is a massive gap. It is the difference between paying a monthly utility bill and using a subscription you already bought and paid for. And here is why that gap exists in the first place. MI1 is a cloud-hosted model so every single request has to travel to a Dytacenter and hit Microsoft's infrastructure to get billed. Even with Sparse activation keeping the costs down you are still paying for the trip. 5.4 does not make that trip at all once it is loaded onto a laptop or a Windows endpoint. You already own the hardware and the model is just sitting there ready to work. The throughput number is back this up too. MI1 reportedly pushes around 145 tokens per second on Microsoft's own Maya 200 chips. That is a real performance number rather than a marketing figure. And it determines if a frontier class model is actually usable at scale. It is fast enough to serve real traffic in production instead of just looking good during a keynote demo. The reason that throughput exists traces back to how the model was trained. Microsoft claims they cut training costs by 40% by running on Maya co-designed infrastructure instead of standard Nvidia clusters that is not just a footnote. Training a frontier scale model is one of the largest expenses in this industry and saving 40% changes what Microsoft can afford to build next. It also changes how aggressively they can price the models they have already built. None of this is really a technical story. It is a business story wearing technical clothes. Cost per token is not an abstract metric that only engineers care about. It is the number that decides if a project is even viable. If you drop the cost far enough, a use case that used to be too expensive to automate suddenly gets greenlit without a second thought. If the cost stays high, even a useful feature gets shelved because the math does not work. Microsoft is not just cutting costs for the sake of it. They are expanding the list of problems that are actually worth solving with AI. But here is the catch with these efficiency numbers. A low cost per token and fast throughput do not mean anything on their own. They only matter once you know where each model is supposed to live and what kind of request is supposed to reach it. Cheap and fast is great, but cheap and fast in the wrong place is just a different way to waste your money. Five four as the runtime, what that actually means. Let's define the word runtime plainly because it is doing a lot of work in this episode. A runtime is the thing that executes. It is not the strategist deciding what should happen, but the part that actually does the work right where the action is. It happens instantly. There is no queue, no roundtrip, and no waiting on a data center somewhere to weigh in. That is the specific job fee four was built for. Look at the actual sizes and the picture gets concrete fast. Five four mini sits at 3.8 billion parameters, while five four multi-model sits at 5.6 billion. Both of them ship under the MIT license. That licensing detail sounds boring until you are the person who has to get a model approved for production. Most frontier models come wrapped in usage restrictions or revenue thresholds that need a lawyer sign off before anyone touches them. MIT licensing skips that entire process that there is no legal friction and no need to check with procurement before you embed the model. You can drop five four into a product or an internal tool without waiting on a contract review for a runtime layer. That matters because these tools are supposed to be everywhere, rather than gated behind a vendor agreement. Function calling is built directly into five four mini, and that is what makes it function as a runtime instead of just a small chatbot. The model is not just generating text because it can recognize when a task requires a decision point. It then hands off the task to a specific tool or function to act on it. That is the difference between a model that describes what should happen and one that can actually trigger the action. Small agents that need to make a call and act quickly run perfectly on this kind of setup, picture where this actually shows up in the real world. You could have a laptop running a local coding assistant that checks a file for errors and fixes them without ever sending that data anywhere. A Windows endpoint could run a small agent that triages an incoming request and decides which internal tool should handle it next. There is no cloud call, no latency spike, and no data leaving the machine during the process. That is execution living close to the work. The response feels instant because there is no travel time involved and the device has everything it needs locally. This is also where data sovereignty stops being an abstract conversation about compliance. If the model runs on the endpoint, the request never leaves the endpoint. That is not a policy you have to enforce after the fact. It is just how the architecture of the system works. But we have to be honest about the limits here. Execution alone does not explain intelligence. A runtime can act fast and act locally, but it cannot plan five moves ahead through a genuinely complicated problem. Five fork and catch an error or trigger a function to resolve a routine case. It cannot sit there and reason through something that requires holding a massive set of trade-offs in its head at once. That is not a flaw in the system. It is the design. The deep planning work was never supposed to live at the edge. That is the job for MI1. And we need to see what actual reason looks like once you get past the marketing label. MI1 as the reason, what that actually means. Reasoning means something very specific in this context. It isn't the part of the brain that remembers what happened yesterday. It's the part that decides what should happen next. It weighs options, it holds trade-offs, and it plans out five steps before a single line of code is written. That is a different job than what five orders. And because the job is different, it needs a different model underneath it. Microsoft put that job into my thinking one. It runs on 35 billion active parameters with a context window of 256,000 tokens. On the AIME 2025 math benchmark, it scores 97%. That isn't just a high score on a test. That specific benchmark is designed to trip models up with layered multi-step problems. Hitting 97% means the model can hold a complex problem together across a long chain of logic without losing the thread. But there is a detail here that matters more than the math scores. MI thinking one was built with zero distillation. In this industry, most models are built by training a small system to mimic a big one. You essentially teach the student to copy the teacher's homework. That's distillation, it's fast, but it has a hidden cost. You inherit every bias, every gap, and every licensing red flag that was baked into the original model. Zero distillation means none of that. MI thinking one was built from the ground up, using data with a clean, commercially licensed lineage. Nothing was borrowed from a black box source. If you work in a regulated industry like healthcare or finance, this isn't just a nice feature. It is the difference between a model your compliance team signs off on and one that gets stuck in review forever because nobody knows where its knowledge came from. This isn't just about math either. On SWEBench Pro, which tests real world software engineering, MI thinking one hits 53%. That puts it right next to Opus class models for a long time, Opus has been the gold standard for complex coding. Landing in that range proves MI one can handle the messy, ambiguous, multi-file reasoning that actual engineering requires. But we need to break a common instinct here. We've talked about how 5.4 is efficient, but bigger doesn't always mean better. Sparse activation proves that smaller footprints can outperform brute force. However, deeper reasoning still requires more active compute. That part is not negotiable. You cannot compress genuine, multi-step planning into a few billion parameters and expect the same result. Those 35 billion active parameters aren't there for show. They are the literal cost of holding a hard problem together long enough to solve it. This is where the two layers stop being separate stories. 5.4 executes its fast, cheap, and local. MI one reasons its deep, deliberate, and expensive. Neither one replaces the other and neither one is complete on its own. The real architecture isn't about picking one model. It's about the handoff. It's about how a request starts at the runtime layer and moves to the reason layer the moment it needs real judgment. That handoff is the part nobody is talking about. And it's the most important piece of engineering to understand. The handoff, how reasoning becomes execution. Here's what that handoff looks like when you treat it as a system instead of an abstraction. A request comes in. Something has to look at it first before either model touches it to decide what it actually is. It isn't looking at the surface level. It's looking at what kind of problem it represents. Is this a two-line question with an obvious answer? Or is this something that needs five steps of planning before a response makes sense? That classification happens first. Then and only then the request gets routed. Simple, high volume tasks go to 5.4. It might be running on your device or hosted as a small model in Foundry. Complex multi-step reasoning gets escalated to MAI1. The pattern is simple. Classify, then route. But here's the problem. Everyone wants to talk about which model is smarter. Almost nobody wants to talk about the routing layer. This is the infrastructure that decides which model even sees the request in the first place. It isn't a glamorous build. It won't get a keynote moment. But it is the difference between a system that works and two expensive models sitting next to each other with no logic connecting them. Think about a support ticket system. 80% of the tickets are routine. People want to reset passwords, check order status, or find an invoice. These questions have one clear answer and don't require weighing trade-offs. Those tickets resolve entirely at the 5.4 layer. They are fast, they are cheap, and they are done. The other 20% are different. Maybe it's a billing dispute that touches three different systems or a technical issue that needs a root cause analysis across a chain of dependencies. Those get escalated and MAI1 picks them up. That 80/20 split isn't a guess. It matches the data we see across the industry. Most requests are routine and only a small minority need deep reasoning. The routing layer's entire job is telling the difference correctly every single time without a human checking the work. This matters for more than just the budget. Yes, it's cheaper to solve routine tickets with a small model instead of paying frontier rates for a simple question. But the real win is latency. Think about the user experience for that 80%. They ask a question and the answer comes back almost instantly because the request never left the local layer. There is no queue. There is no wait for a massive system to spin up its experts for a question that didn't need them. The handoff to MI1 happens invisibly. It only happens for the cases that actually justify the wait. Most users will never notice a handoff even occurred. They just experience a system that feels fast all the time. It only takes longer on the genuinely hard stuff and they never have to know why. That invisibility is the whole point. A well-built routing layer doesn't announce itself. It makes the system feel like one single intelligence even though two different models are doing the work. And here is the thing to consider. This pattern of classifying, routing, and escalating only when necessary isn't something Microsoft invented in a vacuum. It isn't unique to MI1 and 5.4. This pattern is showing up everywhere. Company after company is moving toward this, regardless of which models they use. And that raises a real question. If everyone is converging on the same architecture, what does that tell you about where this is headed? Why the industry already agrees on this split? This shift is bigger than one company's product strategy. Gardner is projecting that by 2027, organizations will use small, task-specific models three times more often than general-purpose LLMs, not slightly more. Three times. That isn't a niche trend tucked into a research footnote. It's analysts describing what's about to become the default shape of enterprise AI. The do everything models, stop being the norm. The task-specific small models take over the majority of the workload. And this isn't some future prediction with nothing behind it yet. In AI-major markets, 68% of enterprises are already running at least one small model in production today. Not piloting, not testing in a sandbox, running it in production right now. That number alone should tell you the industry didn't wait around for a keynote to figure this out. Companies were already building toward exactly this split before Microsoft ever said the words MI1 or 5-4 out loud. Here's the economic driver underneath all of it, stated plainly. Serving a 7-billion parameter model can be 10 to 30 times cheaper than serving a model in the 70-billion plus range, 10 to 30 times. That isn't a rounding error you absorb into overhead. It's the difference between a workload that scales sustainably and one that gets quietly killed in a budget review six months in. Because the ongoing cost never made sense once volume actually showed up. Once you see that math, the industry wide shift stops looking like a trend. It starts looking like the only rational move available. If a small model handles the routine 80% of requests that are fraction of the cost, and the frontier model only gets pulled in for the genuinely hard 20%, you aren't choosing between quality and savings, you're getting both. Because you stopped paying frontier prices for questions that never needed frontier reasoning in the first place. So here's the point worth being honest about. Microsoft didn't invent this pattern. This isn't some proprietary insight that only came out of a Redmond Lab. What Microsoft did was productize it at their own scale, running on their own silicon. Maya chips underneath MIA1, MIT licensed 5-4 models built to sit on endpoints, and the whole reason and runtime split dressed up in shipped as a coordinated platform. But the underlying logic, small models for volume, large models for depth, was already the direction the entire industry was moving. Microsoft just built the most visible, most vertically integrated version of it, which raises an uncomfortable question for anyone who hasn't caught up yet. If this split is already the industry consensus, and the data shows 68% adoption with a three-fold shift coming within a couple of years, what does it actually cost a company that hasn't built this architecture on purpose? What happens when every request, simple or complex, still gets rooted through the exact same frontier model? Because nobody ever built the routing logic to do anything else? That isn't a hypothetical. That's the default state most organizations are still sitting in right now. And it's worth looking at exactly what that default costs. The old model, one model to rule everything, here's what that default actually looks like inside a company that never built the split, every request comes in, and every request goes to the same place, a frontier model, general purpose, expensive. Handling a two-sentence password reset the exact same way it handles a genuinely hard multi-step planning problem. There's no classification step, no routing logic, no decision about what a request actually needs. There's just one door, and everything walks through it. This is the floor default, and it's still the reality for most organizations right now, not because anyone chose it deliberately, but because nobody built anything else. When you only have one model available, route everything through it isn't a strategy. It's just what happens by omission. Here's what that omission costs. Companies stuck on this pattern report monthly cloud AI bills running $50,000 to $100,000 or more. For workloads that never needed frontier level reasoning in the first place. That isn't the cost of doing hard, valuable work. It's the cost of asking an expensive specialist to sit through a meeting that only needed an intern. Over and over, thousands of times a month because there was no cheaper option on the roster, and the cost isn't only financial. There's a latency tax buried in here too, one that's easy to miss because it doesn't show up on an invoice. Picture a model built to hold a two million token context window, architected to reason across entire code bases and sprawling document sets, and then someone asks it a two-sentence question. The system still has to spin up, it still has to prepare for the possibility of holding that much context, even though this particular request needed almost none of it. The user waits on infrastructure that was built for a different kind of problem entirely. Here's the belief worth breaking, and it's an uncomfortable one for a lot of teams. When the setup feels slow or expensive, the instinct is to blame the model. Upgraded, tune it, throw more compute at it, but that's misdiagnosing the problem. This isn't a technology failure, it's an architecture failure. The model was never the bottleneck. The bottleneck was the absence of a system that knew which request deserved that model's full capability and which ones didn't. A frontier model performing exactly as designed on a task that never needed frontier level reasoning isn't a broken model. It's a broken decision about where that model belongs. No amount of upgrading fixes a routing problem because the model was never what needed fixing. This is exactly the Gap MI1 and 5.4 were built to close. Not by making one model do everything better, but by making sure everything doesn't have to go through one model in the first place. To understand how that Gap actually gets closed in practice, it helps to look inside what each of these two models is actually built from, starting with the one designed to live closest to the work. Inside 5.4's actual architecture. Let's open this up and look at what is sitting inside 5.4 because the architecture explains why it can live at the edge in the first place. It starts with grouped query attention. In a normal transformer, every single query head does its own separate lookup work. It is thorough, but it is also expensive for your memory. Grouped query attention changes that by having clusters of query heads share the same lookup work instead of each one duplicating it. The same basic job gets done, but you spend less memory doing it. This is not a shortcut that hurts quality. It is a shortcut that removes waste that was never buying you anything. When you pair that with a 200,000 word vocabulary and shared input output embeddings, the model changes. A bigger vocabulary means the model can represent language more precisely without breaking words into awkward fragments. By sharing the embeddings between input and output, the model does not have to store two separate copies of the same vocabulary knowledge for reading and writing. It reuses the same table for both directions. This means fewer parameters are spent on redundancy and more of the model's budget goes toward actually understanding what you are asking. The multi-modal version follows a similar logic. 5.4 multi-modal is not just a text model with a camera bolted on as an afterthought. It runs a vision encoder and an audio encoder side by side and both feed into that same compact backbone using a mixture of low-res approach. Instead of training three entirely separate models for text, image and audio, Microsoft trains small, lightweight adapters that plug into the core model depending on what kind of input shows up. You have one backbone and three sets of ears and each one only activates when it is actually needed. There is one detail here that is genuinely surprising. 5.4 was trained on five trillion tokens. That number sounds huge until you compare it to frontier scale models that often train on two or three times that amount. 5.4 is working with a noticeably smaller training diet than the giants it competes with. So why does it still perform well? It works because those five trillion tokens are heavily synthetic and heavily curated. Microsoft is not just scraping the open internet and hoping the quality averages out. They are generating targeted training data specifically designed to teach the model math coding and reasoning patterns. They filter hard for quality before any of it gets used. This is quality of a volume. A frontier model might need 10 times the raw data because a huge chunk of what it eats is noisy or repetitive. 5.4's approach front loads the curation work so every token it sees is pulling more weight. You have less data but that data was built to teach exactly what the model needed to learn. Then there is SambaY. This variant is a genuine architectural departure rather than just a size adjustment. SambaY is a hybrid design that blends Mamba style state space layers in with traditional attention. State space layers process long sequences differently than attention does and they are often more efficient for certain kinds of context. By combining the two, Microsoft is testing whether the next efficiency gain comes from a smarter core architecture instead of just smarter training data. When you put all of this together, you get a model built to run at the edge on modest hardware without the cloud. But a runtime that lives at the edge only matters if it can connect to something bigger when a request outgrows it. That is where MI1's architecture comes into the picture. Inside MI1's actual architecture. Now we flip to the other side of the stack. MI1's architecture is solving a completely different problem than the one 5.4 just solved. It uses a sparse mixture of expert system. Imagine a roster of specialists. Way more than you would ever need in one room at once. Where each one is trained on a different slice of knowledge. When a request comes in, the system does not wake up the whole roster. It picks a small handful of experts relevant to that specific question and only those experts do any work. Everyone else on the roster stays idle. That is the many experts, few active structure. You have massive total capacity sitting on the shelf but only a sliver of it is switched on for any single token. This is the key to controlling cost. A dense model of a similar size would have to activate everything for every single request. That is fine when the total size is small but it stops being fine once the model gets frontier large. At that scale you would be paying full compute for the entire roster on every query whether the question needed three specialists or 300. Sparse activation breaks that link. MI1 can carry an enormous total parameter count without paying full price for that capacity on every request. You get the scale without inheriting the normal price tag. Then you have to layer in the hardware side. Microsoft co-designed MI1 with its own Maya 200 chips and the reported payoff is a 1.4 times gain in performance per what compared to generic GPUs. This is not just a small tuning win. It is the difference between squeezing gains out of hardware you did not build for this job and using hardware that was shaped around the model's actual activation pattern from the start. This co-design is a strategic move. Not just an engineering flex, anyone can rent GPU capacity because that is a commodity available to whoever has the budget. But designing your chip and your model together so the activation pattern maps onto the silicon underneath it is not something a competitor can just buy. It is a mode built out of years of coordinated engineering between teams that do not normally sit in the same building. Copying the model architecture is possible but copying the chip model relationship behind it is a much longer road. And that is exactly the point Suleiman has been making. The goal is not just building good models. It is AI self-sufficiency. Microsoft wants to reach a point where they are not permanently renting someone else's compute to run their own intelligence layer. Owning the chip, the model and the relationship between them is what makes self-sufficiency more than a talking point. On paper, this is a genuinely elegant design. You have sparse activation for cost control, custom silicon for efficiency and a strategic goal tying it all together. But an architecture diagram is not proof of anything. None of this actually matters unless it holds up outside a keynote slide. Under real workloads with real deadlines and real budgets on the line, the Excel proof point. So here is what all of that architecture actually produced when Microsoft pointed it at a real problem instead of a benchmark chart. Microsoft wanted agentic Excel tasks that actually held up under real use. They didn't want a demo where the model reads a spreadsheet and summarizes it once for an audience that claps and moves on. They needed real agentic work. The kind where a model has to look at a workbook understand what is actually being asked, take multiple steps and get it right every single time. And it has to do that across the massive volume of requests an actual Excel user-based generates every day. But here is the problem. General purpose frontier models could technically do this. But at the volume Excel operates at hundreds of millions of users and an enormous number of daily requests. Those models were either too slow to feel usable or too expensive to run at scale without the economics falling apart. You can build an impressive demo with a frontier model answering one spreadsheet question. But you cannot afford to run that same model at that same depth for every formula question and data cleanup task hitting Excel in production. So this is the exact gap we have been building toward. This isn't a hypothetical. It is an actual product decision Microsoft had to make. And here is the shift. M.A.I. tuned models ended up matching GPT 5.4 on the relevant bench marks while running a 10 times greater cost efficiency. Read that again. Because it is the whole thesis of this episode compressed into one result, it wasn't close enough performance for a discount. It was matching performance at a 10th of the cost. That is not a trade-off. That is what happens when a model gets tuned specifically for a task instead of being asked to be brilliant at everything. And this was not a one-off. The same pattern repeated with McKinsey's task-specific tuning. When M.A.I. got tuned on McKinsey's actual workflows, it delivered the highest win rate of any model tested and out performed GPT 5.5 on their specific tasks. It landed at that same 10 times efficiency gain to completely different organizations, two completely different workloads. Spreadsheets on one side and consulting workflows on the other. The same result shows up both times. So what is actually happening is a pattern. One win could be a fluke or a bench mark that happened to favor M.A.I.I's training data. But two wins in unrelated domains landing on the same 10 times efficiency number means something. It is a sign the gain isn't specific to spreadsheets or consulting. It is what shows up whenever reasoning and runtime get tuned together against a real narrow workflow instead of being asked to perform generally. And that is the real point here. This is not a demo. Demo's show you what is possible in ideal conditions. This is what happens when the architecture we have described gets pointed at actual production workloads with actual volume and actual cost pressure. These are real users who would notice if it broke, which raises a question worth sitting with. If tuning a model on your own workflows gets your results like this. What does that actually mean for who ends up owning the model that comes out the other side? Frontier tuning and wired changes who owns the model. The answer starts with a piece of infrastructure Microsoft calls reinforcement learning environments. Or RLEs. Think of an RLE as a training gym built for exactly one company's problems. It is not a general gym with treadmills for anybody off the street. It is a facility custom built around the specific movements one team actually needs to get good at. Microsoft used its own RLEs combined with M.A.I.I models to climb to what better performance on Excel tasks specifically. McKinsey did the same thing with their own tasks in their own environment. The gym isn't shared. It is built around one organization's actual work. And the model only gets strong at the things that gym trains it on. But here is the differentiator that matters more than anything else. You don't rent shared intelligence. You keep the resulting model. Sit with that for a second. Because it is a genuinely different relationship than most companies have with A.I.I right now. Most SAS A.I.Tools work the opposite way. You use the tool. Your usage feeds a shared system. And every improvement that comes from your data gets folded into the same general model every other customer is also using. Your competitor uses the same tool and benefits from the exact same improvements your usage helped create. You are not building anything proprietary. You are contributing to somebody else's product one query at a time. And you don't get to walk away with what you helped build. Frontier tuning breaks that arrangement. When you tune M.A.I.I models inside your own RLE on your own tasks, the resulting model is yours. It is not a shared checkpoint everyone draws from. It is a model shaped specifically by your workflows and your institutional know-how. Nobody else gets to touch what came out of that process. And this is the shift where your workflows become your mode instead of a vendor's mode. Every company has some version of tribal knowledge. The specific way they handle a certain kind of customer complaint or the particular judgment calls that separate a senior employee from a junior one. Normally that knowledge stays locked inside people's heads or scattered across documentation. Nobody reads. Frontier tuning turns that same knowledge into a model asset. The workflows that make your company good at what it does become the thing the model gets tuned on. The resulting intelligence belongs to you. Not to whoever built the underlying model. Now connect this back to the architecture we have been describing. Phi 4 becomes the tunable runtime. The fast and local layer that can be shaped around your specific execution needs. M.I.I.I.I sits underneath as the reasoning foundation. The deep layer custom agents draw on when a request actually needs planning instead of just action. Frontier tuning is what lets both layers get shaped around one company's actual work instead of staying generic and shared across every customer using the same off-the-shelf model. And this is where things change for IT decision-makers up until now choosing an AI vendor mostly meant choosing a tool. Now it means choosing whether the intelligence your company builds through daily use stays yours or quietly becomes part of somebody else's shared product. That is not a question engineering teams have historically had to ask, but it is about to become one of the most consequential calls they make. If this changed how you think, follow me, Mirko Peters, on LinkedIn. And if you want more of this, leave a review. It helps more people find it. Share this with your team, especially if you are dealing with this right now. What this means for IT architects and admins. So here is where this lands for the people who actually have to build it. For years, the standard IT question was simple. Which model should we standardize on? You pick the vendor, you pick the model, you roll it out across the org, and then everyone built against that one choice. That question made sense when there was only one kind of model to pick from. It does not make sense anymore. Standardizing on a single model in an architecture built around a reason and runtime split is like hiring one person to do every job in your company. You wouldn't ask the same person to file paperwork and negotiate a merger. The question was never wrong because the answer was hard. It was wrong because it assumed the wrong thing needed choosing. The actual question is different. What is our rooting logic? And who owns the decision layer? That is the only question that matters now. Not which model, but who decides which model? And based on what? Because as we saw, the routing layer is the part nobody wants to build and everybody needs. Someone in the organization has to own that decision layer. Someone has to be responsible for the classification logic that sends a routine request to 5/4 and a genuinely hard one up to my one right now in most organizations. Nobody owns that. It is nobody's job, which means it is not getting built, which means every request still defaults to whatever single model happens to be plugged in. That ownership gap points to a skill most IT teams do not have yet. Workload classification, not model tuning, not prompt engineering, workload classification. This is the ability to look at an incoming request and judge whether it is simple or reasoning heavy. Before it ever reaches a model, that is a genuinely new skill. Most architects were never trained to do this, because until recently, there was no reason to do it. Every request went to the same place regardless. Now, that distinction is the whole game. And most teams are starting from zero. There is a governance layer sitting on top of all this too. On-prem 5/4 deployments become the answer when data sovereignty is non-negotiable, when a request can never leave the building, or the endpoint, or the country. You go local. Cloud-based MI1 becomes the answer when you need centralized reasoning, when you need shared context across a whole organization, or the kind of planning work that benefits from sitting in one place. Go to the cloud. That is not a technology decision anymore. That is a governance decision. And it has to be made deliberately, not by default. And here is the real friction point, stated plainly. Most organizations do not have this rooting infrastructure yet. It does not exist. The models exist. 5/4 is sitting there. MIT licensed. Ready to deploy. MI1 is available through Foundry. But the layer that decides which request goes where? The classification logic, the ownership, the governance rules. That is the actual work still ahead. Nobody sells you that off the shelf. You have to build it, which is a very different conversation depending on who is sitting in the room for architects and admins. This is an infrastructure problem. For the people signing the budget, it looks like something else entirely. What this means for decision makers and budget owners. Here is how that conversation changes once it reaches whoever signs the check. Most executives still frame this as, how much does AI cost? The wrong question. The real question is, how much mis-rooted AI costs? Because that is the number nobody is tracking. It is not the invoice from the model provider. It is the invisible cost sitting underneath it. Every request that got sent to an expensive model when a cheap one would have handled it just as well. Is a loss. That is not a line item on any budget report. It is a leak. And leaks do not show up until someone finally goes looking for them. Look at what correct rooting actually produces in practice. In one case, fuel cost reduction was tied directly to model routing decisions. Those savings showed up because the right model was matched to the right task at the right layer. We see the same pattern on the support side. Latency was cut from 15 seconds down to under two. That drop did not come from a faster frontier model. It came from rooting routine requests, somewhere that never needed frontier depth in the first place. That is the whole argument made concrete. The game was not capability. It was placement. Now, here is the number that turns this into a real financial decision instead of a technical preference. Self-hosted small models break even against managed frontier APIs inside 18 months. Once you are operating at volume, 18 months that is not a speculative payback period stretched out over a decade to make the math look better on a slide. That is a timeline a CFO can actually plan around. At real volume, the math does not stay close. It tilts hard toward whichever company built the rooting infrastructure early, which is exactly why this stops being purely an engineering decision and becomes a board level conversation. Engineering teams can debate architecture patterns all day, but an 18 month break even on infrastructure spend. Tied to a measurable latency and cost outcome is a different story. That is the kind of number that gets a line in a quarterly review. Once the payback period is that short and that provable, the decision is not, should we let the engineers experiment with this? A, the decision is, why haven't we already funded it? And here are the stakes worth sitting with. Because it does not stay contained to one budget cycle. The companies that get routing right are not just saving money on this quarter's cloud bill. They are operating at a structurally lower cost basis than competitors who never built the split. That is not a temporary advantage that erodes once everyone catches up. It compounds. Every request processed at the correct layer. Instead of defaulting to the most expensive option available, is margin the other company does not have. It stays that way, quarter after quarter, at whatever scale they are operating at. So the case for budget owners is straightforward. This is not a bet on which model wins. It is a bet on whether your cost structure looks like the company is still routing everything through one expensive door, or the ones who build the infrastructure to stop doing that. But before this turns into an uncritical pitch, there is a tension worth being honest about, one that sits uncomfortably next to everything just described. The trust gap Microsoft hasn't solved yet. There is a tension here. It is worth saying out loud, instead of skipping past it. Microsoft pitches Copilot as a serious enterprise tool. They wire it into Excel. They put it in Teams. They tell you it belongs in the exact workflows we have been talking about. But then you look at the fine print. Copilot's own terms of use still describe the product as being for entertainment purposes only. That is the actual language. It is not a marketing footnote. It is a legal disclaimer telling you not to treat the outputs as reliable. And Microsoft is not alone. Open AI and XAI have versions of the same language in their own terms. This is an industry-wide pattern. Corsion is baked into the legal layer of every major AI provider. It does not matter how confidently they talk about the technology in public. So here's the problem. These companies want AI to be critical infrastructure. They wanted to be the engine behind your Excel agents and your support systems. They wanted to handle decisions that affect real budgets and real customers. But at the same time, the legal language says, don't actually rely on this. You have critical infrastructure and legally-disclamed unreliability sitting in the same product at the same time. That gap matters if you are planning to actually use this in a business. It is not a reason to avoid the architecture we have been building, but it is a reason not to build dependencies that you cannot reverse. Nobody is willing to formally stand behind these outputs yet. If a workflow can handle an occasional wrong answer, that is one thing. You catch it. You correct it. You route it to a human when confidence is low. But if your workflow assumes the model is simply correct, you are taking a massive risk. That is the risk the terms of use are warning you about whether you read them or not. Now, we should add some context here. Microsoft has acknowledged that this wording is outdated. That matters. A company saying the language does not reflect the product is different from a company defending it as accurate. It suggests this is just a lagging artifact. It was written years before Copilot could do what it does today. But acknowledging outdated language and actually fixing the gap are two different things. Only one of those has happened. This does not change the strategy we have covered. The reason and runtime split still works. The routing logic and the cost math still hold up. What it means is that governance has to catch up to the technology. The architecture is ahead of the paperwork right now. And until that paperwork catches up, the responsible move is to build verification into your workflow. Do not assume the legal language will update itself before something important breaks. Multimodality as the next layer of the runtime. Now zoom out from governance for a second. There is another layer to this runtime story. It lives inside the word multimodal, whether when you look at 5 or 4 multimodal, it does not run vision, audio and text as three separate products. It is not a text model with a camera and a microphone bolted on as afterthoughts. Those setups have separate pipelines and separate failure points. This is one backbone. One core handles all three kinds of input. Here is what that looks like in the real world. You get OCR accuracy that holds up on messy documents. You can hand the model an image and ask specific questions about what is in it. You get answers grounded in what is actually there. You get audio transcription and translation in one single pass. There is no separate translation step added on afterward. It is one model, one forward pass, three different senses feeding into the same understanding. Why does this matter for developers? Because the alternative is a nightmare. Separate pipelines mean separate failure points and separate latency budgets. You have to keep different versions synchronized. Things break quietly and you do not notice until a user complains. A unified backbone collapses all of that. It gives you one thing to deploy, one thing to monitor, one thing to update. That is the difference between a runtime you can actually maintain and one that becomes unmanageable as you add more inputs. This pattern shows up on the MAI side too. They use different names like MAI voice or MI image. But they follow the exact same logic we have been describing. Reasoning heavy work sits in one place. Fast specialized execution sits somewhere else. It stays closer to where the input is happening. It is easy to think multi-modal is a separate category. It isn't. Even inside these systems, the same split holds. Heavy reasoning needs deep context and multi-step planning that stays with the reasoning layer. Fast execution needs to transcribe audio or read text off a scan in real time. That stays with the runtime layer. Adding vision and audio did not break the reason and runtime pattern. It just gave the pattern more kinds of input to sort through. The architecture does not get more complicated as you add modalities. It just gets applied more broadly, which leads to the next question. If this split holds true across text, vision, and audio today, where does Microsoft take it next? And what does that tell you about what is coming? The trajectory where this architecture goes next. Microsoft is signaling where this is headed. And it is much bigger than the seven models we saw at build. The plan does not stop at task-specific models. Mustafa Saliman has been very direct about the goal here. They are building full-frontier LLMs to compete with systems like GPT-4. They aren't just building narrow tools for coding or transcription. Everything we have looked at so far, the MAI thinking models, the Excel tuning, the McKinsey results, that is just the current chapter. It is not the whole book. Microsoft is moving toward a world where general frontier capabilities sits right alongside the specialized layer. It is not an either/or strategy. We see the same expansion happening on the runtime side. 5.4 is not staying a small line-up of two or three models. It is already growing toward 10 different versions. These will span from 3.8 billion parameters up to 15 billion. And every single one of them is still MIT licensed. That licensing detail is just as important now as it was earlier. It means this isn't just Microsoft growing its own internal layer. It is a runtime layer that any developer can use. You can pick the size that fits your hardware without needing a legal team to sign off first. But here is a signal you should pay close attention to. Look at the Mayo Clinic partnership. Microsoft is not just licensing a generic model to a hospital and walking away. They are jointly building a frontier model specifically for healthcare. They are combining frontier reasoning with Mayo's own clinical data and deploying it at a massive hospital scale. This is not a demo. This is the reason and runtime pattern applied to one of the highest stakes domains in the world. You have a major institution putting its name on the outcome. So what does that tell us about the future? It points toward vertical specific pairs of reason and runtime. We are going to see the show up industry by industry. Healthcare gets its own tuned pairing built on clinical data. Legal gets its own. Manufacturing, logistics and financial services will likely follow the same path. Each industry ends up with a frontier reasoning layer shaped around its specific problems. And that layer is paired with a fast local runtime tuned for daily execution. If you push that idea forward, you can see what it looks like inside a single company. You won't have one shared model bolted onto every department just because that is what the license allowed. Instead, every department runs its own tuned runtime. It is shaped around their specific workflows, just like the Excel and McKinsey examples. Each of those runtimes connects back to a shared reasoning layer underneath. That foundation provides the deep planning capability that the individual runtimes don't need to carry themselves. Finance gets a runtime for finance. Support gets one for support. Underneath all of them, the whole company draws from one reasoning foundation instead of rebuilding it every time. That is the direction of travel. It is not one giant model absorbing everything. It is also not a scattered pile of small disconnected tools. It is a structure. You have many tuned runtimes on top and one shared reasoning layer underneath. It happens industry by industry and department by department. Now we need to step back. We need to look at how the models, the routing, the governance and the trust gap all fit together. They aren't just parts. They are one single architecture. Tying the architecture together. Here is the whole stack laid out in one place. You have models that split by design. You have a runtime layer built to execute as close to the work as possible. There is an orchestration layer that decides where each request needs to go. You have a governance layer trying to solve sovereignty questions and trust gaps. And at the very bottom, you have silicon built in lockstep with the models. The models aren't trying to fit into whatever hardware was available. The hardware was built for them. These are five layers and none of them work in isolation. If you skipped to this part of the video, here is the one sentence you need to hear. Five four executes and MI1 decides. That is the entire reframe. They are not competitors. This is not a contest of big versus small. It is not a leaderboard with a winner and a loser. These are two different jobs based on two different philosophies. They are working together on purpose, but we should be very clear about something before we finish. This is not unique to Microsoft. Every major AI provider is moving towards some version of this same split. You have a heavy reasoning layer for the hard problems and a fast specialized layer for everything else. The economics of AI force everyone toward this answer eventually. Microsoft just happened to turn it into a product first. They did it at their own scale and on their own chips. The pattern belongs to the whole industry, not just one company road map. Because of that, the competitive question has changed. It is no longer about who has access to the models. The organizations that win the next few years won't be the ones with the best license. Model access is basically a commodity now. If you have a budget, you have a model. What is not a commodity is your rooting logic. The real value is in the classification work and the governance decisions. It is the willingness to build the layer that actually decides where a request goes. That part does not come prebuilt. That is what separates companies that are structurally faster from companies that still send every request through one expensive door. Now I want to add a quick caveat here. This deserves honesty rather than just acting like everything is a settled fact. Some of what we talked about is reported. It comes from post-built coverage, analyst reports and public statements from Microsoft. It is not all confirmed line by line in technical docs yet. The 5.4 architecture is well documented, but some of the newer MEI details and the exact benchmark numbers are still coming out as the system matures. It is worth watching, but don't treat it as final truth just because the numbers sound precise. That distinction is important, but it does not change the core point. The architecture pattern is real, it stays real, regardless of what the final numbers look like. And that leaves one big question on the table. If model access is a solved problem and rooting is the real battleground, what does that change? It changes how organizations have to think. It isn't just about AI anymore, it is about how you build anything from here on out. The real shift, nobody's naming, zoom all the way out. There is a bigger shift buried underneath everything we just covered. And it is not really about Microsoft, this is the end of the pick one AI vendor era. That instinct made sense a few years ago when you were just picking a horse. One contract, one model, one API key and you were done. That world is over. It is over because the winning architecture was never going to be a single model. It was always going to be a system, layers doing different jobs. And the system does not come from a single vendor relationship. It comes from design, which points to the actual shift worth naming. Architectural literacy is becoming a business skill, not just a technical one. For years, understanding AI meant knowing which model scored higher on a benchmark. That conversation lived entirely inside engineering, but that is not where the conversation lives anymore. Knowing why a request should go to a fast local model instead of a frontier one, knowing what rooting logic costs to skip, knowing where governance sits relative to where reasoning happens. That is business judgment now. It shows up in budget meetings and board decks. The people who need to understand this split are no longer just the ones writing the code. Go back to how this whole episode opened. The question everyone kept asking was which model wins? M-A-I-1 or F-I-4? Bigger or smaller? Faster or smarter? That question was never the real one. The real question, the one worth asking from the very first minute, was how these systems divide labor. It is not a contest. It is a design decision. Every section since has just been unpacking what that division looks like in practice. What it costs to get wrong and what it is worth to get right. So here is the belief breaking statement worth sitting with. The companies still asking which model is smarter are already behind the ones asking how to root intelligently. That gap is not going to close. It is going to widen quietly, one quarter at a time. Eventually the company is still fighting over leaderboard positions will look up and realize the race was never about the leaderboard. So here is what to actually do with this. Take your current A-I workloads and sort them into two piles. Needs reasoning, needs fast execution. Most of what is running through a frontier model right now belongs in that second pile. Pick one high volume low complexity task this month. Test it against a small model before you default to the expensive option out of habit. If this changed how you think about your own A-I stack, follow me, Möko Peters on LinkedIn. And if you want more of this, leave a review. It helps more people find it. The architecture is already being built. The only open question left is who builds the routing layer first?