Today, developers building AI applications are expected to make a strangely specific decision before they can build much of anything: Which model should I use? GPT? Claude? Gemini? Llama? Which version? Which provider? Which pricing tier? Which one is best at coding? Which is fastest? Which has the largest context window? Which one just got cheaper? Which one launched last week?

We have begun treating AI as a new computing primitive while still asking developers to build applications around individual models. I don't think that lasts. Developers shouldn't build on models. They should build on AI.

There is no best model

The model ecosystem is moving too quickly for the application layer to keep up. A model that leads today may be surpassed six months from now. A cheaper model may become good enough for a task that previously required something much more expensive. One provider may excel at coding while another performs better at reasoning, extraction, writing, or long-context work.

And even within a single application, there may not be one correct model. A customer asking an AI assistant to extract three fields from an invoice does not need the same intelligence as someone asking it to debug a distributed system. A classification request does not necessarily need the same model as a difficult mathematical problem. A short rewrite does not need the same resources as a complex research task.

Yet much of the AI stack still expects developers to choose a model first and send everything to it. That is backwards. The question should not be, “Which model should this application use?” It should be, “What does this request require?” Those are very different abstractions.

Model selection is an infrastructure problem

Suppose every time your application received a request, you had to decide which physical server should execute it. You would need to know the workload, inspect machine availability, compare prices, understand regional capacity, account for hardware failures, and continuously update your application whenever better infrastructure became available.

That would be absurd, so we built layers of infrastructure that handle those decisions. The same thing happened with networking. Application developers do not manually determine the route every packet should take across the internet. They express what they want to happen, and infrastructure decides how to make it happen.

AI should evolve the same way. The mistake is not choosing the wrong model. The mistake is forcing the developer to choose at all. The application should describe the task, and the infrastructure underneath it should decide how that task gets executed.

The application should talk to AI

Imagine a different interface. An application sends a request to summarize a document, find the bug in a function, or extract the customer name, invoice number, and total from an invoice. The developer does not need to decide beforehand whether the request belongs to GPT, Claude, Gemini, or some model that does not exist yet.

The infrastructure can evaluate the request itself. What type of task is this? How difficult is it? How much quality is required? How quickly does the answer need to return? What will each option cost? Which models are currently available? Which models have performed well on similar work?

It can then send the request to the model best suited to it. The application talks to AI. The infrastructure talks to models. That is the abstraction boundary I think the industry is moving toward.

Models matter more when developers think about them less

Saying that the model should disappear does not mean models are becoming unimportant. Quite the opposite. Models will matter enormously. Their capabilities, weaknesses, latency, pricing, reliability, context limits, tool use, safety properties, and specialization will all matter to the infrastructure deciding how to use them.

But they do not necessarily need to matter to the application developer. We already accept this idea throughout technology. The details underneath an abstraction can become more sophisticated precisely because the person using the abstraction no longer has to manage them directly.

Modern cloud infrastructure is vastly more complex than the server rooms it replaced. Modern payment infrastructure operates across an enormous collection of banks, card networks, processors, currencies, regulations, fraud systems, and settlement mechanisms. The user sees a payment button. Complexity did not disappear. It moved.

AI will be similar. The model ecosystem can become more complicated while the developer experience becomes simpler.

Intelligence should be allocated, not selected

There is also an economic reason this needs to happen. Today it is common for applications to send nearly every request to a highly capable model because it is operationally easier than determining which requests actually require one. That means expensive intelligence is routinely used for inexpensive problems. It is the AI equivalent of running every workload on the largest server available.

A better infrastructure layer would allocate intelligence according to the problem. Use no more intelligence than the task requires. A simple extraction request might go to a small, inexpensive model. A difficult reasoning problem might go to one of the most capable models available. A coding task might go somewhere else entirely.

If a provider is degraded, the request could move. If another model becomes substantially cheaper without sacrificing quality, traffic could shift. If a new model becomes the best option for a particular category of work, applications could benefit without changing their code.

Developers should not have to redeploy their applications every time the frontier moves. And the frontier is going to move constantly.

Electricity works because the source is abstracted

There is a reason electrical infrastructure is so easy to consume. Behind an electrical outlet is a remarkably complicated system. Power may come from natural gas, nuclear plants, hydroelectric dams, wind farms, solar installations, batteries, or some combination of them. Generation changes throughout the day. Demand changes. Prices change. Infrastructure fails. Power moves across transmission networks and between regions.

An enormous amount of coordination happens underneath the surface. Then you plug in a toaster. The toaster does not negotiate with a nuclear power station. It does not decide that breakfast should run on hydroelectric power because hydro performed particularly well on a benchmark last Tuesday. It asks for electricity.

The complexity of producing that electricity is hidden behind the interface. AI should eventually feel much the same. There may be hundreds or thousands of models underneath the ecosystem. They may come from different companies, countries, architectures, and hardware platforms. Some will be generalists. Some will specialize. Some will be extremely fast. Some will be extraordinarily capable. Some will cost almost nothing.

That diversity is valuable. But most of it belongs below the application layer.

More models should make the abstraction stronger

One possible future is that a single model becomes so good that none of this matters. Maybe one company builds a model that is best at everything, cheap enough for every task, globally available, perfectly reliable, and permanently ahead of every competitor.

Perhaps. Technology markets do occasionally produce miracles. They also produce printers that refuse to work because they are low on cyan.

A more likely outcome is that models continue to involve tradeoffs: capability versus cost, speed versus intelligence, generalization versus specialization, privacy versus convenience, large models versus small models, cloud models versus local models, and one provider versus another.

Even if the underlying models eventually become much more similar in capability, differences in price, latency, reliability, geography, and deployment will remain. And if the number of useful models grows, asking every developer to track them all becomes less reasonable, not more.

The natural response to increasing complexity is a stronger abstraction.

There should still be an escape hatch

Abstractions should not become prisons. There will always be cases where developers need control over the exact model. Researchers need reproducibility. Some applications rely on model-specific behavior. Companies may have contractual requirements around particular providers. Regulated workloads may require specific deployment environments. A developer may deliberately want the personality or capabilities of one particular model.

That should remain possible. The mistake would be making explicit model selection the default simply because it was the first interface the industry built. The infrastructure should provide an escape hatch. It should not require everyone to live in it.

The interface to intelligence should be stable

The more mature AI infrastructure becomes, the less an application's architecture should depend on the model landscape at a particular moment in time.

Imagine building an application today against one stable interface. A stronger model launches next month. No rewrite. A provider cuts prices by 70%. No rewrite. Another provider becomes dramatically better at coding. No rewrite. A model is deprecated. No rewrite. An outage occurs. No rewrite.

The infrastructure changes. The application keeps working.

That is what a useful abstraction does. It separates what the developer wants from how the system accomplishes it.

Models are only one part of the problem

Once the model itself becomes infrastructure, something else becomes obvious. Applications need much more than inference. They need conversation context, memory, access to private knowledge, observability, cost controls, reliability, evaluation, security, and data governance.

Today these pieces are often assembled individually around whichever model provider an application started with. But they are properties of the AI application, not properties of a particular model. They should survive when the underlying model changes.

The long-term opportunity is therefore larger than model routing. It is to create a stable infrastructure layer between applications and intelligence itself.

This is why we're building Elektric

This idea is what led us to build Elektric. We want developers to be able to build against one interface to AI rather than continuously integrating, evaluating, and operating an expanding collection of models and providers.

Underneath that interface, models can compete. A model should win traffic because it is the best choice for a particular task, at a particular moment, under a particular set of constraints. Better models should earn more work. Cheaper models should create savings. New models should be able to enter the system. Providers should be replaceable.

The developer should not have to reorganize an application every time any of this changes. Over time, the same abstraction can extend beyond models to the other primitives AI applications require: context, memory, knowledge, observability, reliability, and economics.

The goal is not to make the AI ecosystem less diverse. It is to make that diversity easier to use.

The model should disappear

There will be more models. They will become more capable, cheaper, faster, and increasingly specialized. And developers should have less reason to know which one answered a particular request.

That is what mature infrastructure does. It hides complexity without hiding capability. The future of AI infrastructure is not a better dropdown containing hundreds of models. It is not asking every developer to become an expert on every new benchmark, release, provider, pricing table, and model family.

It is a world in which applications ask for intelligence and infrastructure figures out how to provide it. Developers should build their products. Models should compete underneath them.

And eventually, the AI model should disappear.