Most work does not need a frontier model

The AI industry still talks as if there is one model.

Not one model per company. One model for everything. The next, larger, more general system that will write your code, review your contracts, search your wiki, draft your strategy and answer a question about fourteenth-century maritime law with equal confidence.

That is a useful story if you sell tokens from a data centre.

The frontier labs have built businesses on it. Axios argues today that routing is coming for them: once organisations stop sending every request to the most expensive model, the labs only get paid for the hard work.

It is a poor description of how organisations actually use AI.

Look at the work

A software team asks the model to review a pull request, write a test, explain a failing build. A legal team asks it to summarise this contract against the house playbook. Operations asks it to find the relevant policy and draft a reply in the organisation's voice. An agent runs overnight through a queue of tickets it has seen a thousand times before.

Three kinds of work dominate that list: data-sensitive requests, high-volume tasks, and domain-specific jobs. The documents are proprietary. The code is the company's. The policy is internal. The queue is the same shape it was yesterday.

The right answer is not "the best generalist on earth". It is a model that is good at this job, fast enough to use all day, and running where the data is allowed to be.

A frontier model can do that work. It is just an expensive, leaky and slightly wrong tool for most of it.

Specialists win the bulk of the load

A smaller model specialised for software engineering will review that pull request with less latency, at a fraction of the cost, without sending source code to someone else's GPU. A model specialised on an organisation's documents will be more useful on those documents than a generalist that has never seen them.

And because the model is smaller, it fits on hardware you can put in the office.

That last point is the one that changes the economics. Cloud frontier pricing is usage-based. Every extra employee, every extra agent step, every extra document is another line on the invoice. A specialised model running on-prem has a known cost. The hundredth request of the day does not cost more than the first.

Specialists are also, often, better at the job you hired them for. Not because they are more intelligent in the abstract, but because they were built for the capability that matters and allowed to forget the rest.

That is the opposite of how most compression works.

What the model needs to be good at

Traditional compression asks: how much of this model can we remove while keeping it as similar as possible to the original?

The result is a shrunken generalist. A bit worse at everything. Small enough to be interesting. Not small enough to be a product.

With SPACE, we ask a different question.

What does this model actually need to be good at?

Preserve the subnetworks behind those capabilities. Strip back the rest. The result is not a miniature version of a frontier model. It is a specialist that still competes where you pointed it, and fits on the hardware you have.

Juno-N is the example we shipped. We took NVIDIA Nemotron 3.5 Lightning and specialised it for software engineering and agentic workloads. It retains competitive performance on those tasks and becomes deliberately narrower everywhere else.

That narrower profile is the point. We are not trying to squeeze an entire general-purpose frontier model into a box. We are identifying the capabilities an organisation actually needs.

Over time that becomes a family: coding, documents, scientific research, finance, law, healthcare. Different specialists, same idea. Organisations can also run compatible open-weight models alongside them. The appliance is not locked to a single brain.

Frontier still matters

None of this means frontier models go away.

A specialist is not a substitute for a frontier model on a problem that needs complex reasoning. Broad world knowledge, tasks outside the specialist's envelope, work that needs the current ceiling of thought: that is still frontier territory.

Pretending otherwise is how local-AI arguments lose people who have actually used both.

The useful picture is not local versus cloud. It is a default path and an overflow.

Routing is the architecture

Most requests should never leave the building. They are data-sensitive, high-volume, or domain-specific. A specialised on-prem model handles them. When the task needs complex reasoning, you send it out.

And the cloud is not one destination either. Once a request is allowed to leave, it should go to the cheapest model that can actually do the job. Frontier pricing is for the work that genuinely needs frontier reasoning, not for everything that happens to be leaving the building.

That decision can be a policy: how sensitive is this data, what kind of task is it, how good does the answer need to be, what are we willing to spend, what happens if the local model is unsure. The person asking should not have to choose a model. They know what the job in front of them needs; the system should know where that work belongs.

That is model routing. It is not a new idea inside a mixture-of-experts model, where a router already sends each token to a handful of experts. It is the same idea one level up: send each job to the model that should do it.

That is now how the rest of the industry is starting to build. Easier, high-volume work goes to a cheaper, smaller model. Complex reasoning goes to the frontier. NVIDIA's Switchyard was built for that split inside agent workflows; evals around the launch found the bulk of turns could sit on a 30-billion-parameter model, with only a small fraction escalating.

It is not one vendor's idea any more. Cursor and Kilo put model choice inside the product. Databricks and DigitalOcean made it a governed platform feature. LiteLLM's auto-router reserves flagship models for the requests that actually need reasoning. Lemonade routes across local, hybrid and cloud. Xunzhuo Liu, who builds the open-source vLLM Semantic Router, calls this the semantic routing moment: a decision layer sitting above a changing pool of models, instead of one model for everything.

Two things in that work matter for anyone applying it to their own estate. The first is that the router reads the request before it picks anything: the job is classified, then dispatched. A request does not arrive pre-labelled. The second is that the inputs to that decision are not all the same kind of input. Task intent is a judgement call. Data residency is a rule. Sensitivity is not a preference to be traded off against cost; it is the constraint the rest of the decision has to respect.

That work also describes the enterprise case as hybrid by default: keep domain knowledge and private data on the GPU fleet you own, and allow controlled access to external providers for the rest. Which is the part we care about. The cheap, default path does not have to be another API bill. It can be a specialist on hardware you own.

None of this requires a clever classifier on day one. Organisations already know that source code should not go to a third-party API, that a coding agent should hit the coding model, that a one-off research question can go to the frontier. Start with the rules you can already write down.

Imagine a typical Tuesday in a professional services firm. Morning: fifty contract summaries, all against the same playbook, all containing client names. Data-sensitive and high-volume: on-prem, every time. Mid-morning: someone asks what the expenses policy actually says. Domain-specific: same path. Afternoon: should the firm acquire a company it has never looked at? That is complex reasoning the local model was never trained to hold. That can go to the frontier, with the sensitive attachments stripped or left behind. Overnight: agents process the backlog on the local model, because the tasks are repetitive and the data is the firm's.

The mix will differ by organisation. A software company will send more to the coding specialist. A hospital will send almost nothing off-prem. The structure is the same.

The architecture is a default, plus a fallback, with data-sensitivity as a hard constraint rather than a preference.

On-prem is the path work takes by default. The frontier model is overflow.

What that changes

Most prompts, documents and agent traces never leave the network. Token bills stop tracking the volume of ordinary usage. The organisation owns the intelligence it depends on every day, and rents the ceiling only for the cases that require it.

This is also how you get out of the one-model trap. If every request goes to the same giant generalist, you are stuck waiting for that generalist to get cheaper, smaller and more willing to run on your floor. If you route, you can put a specialist on the floor now, keep using a frontier model for the rest, and move more of the distribution in-house as more specialists exist.

That is the work we are doing at Locai. SPACE exists to turn strong general-purpose models into smaller specialists. Juno is the family of those specialists. Locai One is the appliance they run on, with Locai OS serving them to the people and tools already in the organisation.

We are not arguing that organisations should never call a frontier model again.

We are arguing that they should stop calling one for everything.

Own the intelligence you use every day. Reach out when you need to.