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?