There Is No Best AI Model. So How Does Elektric Choose?

A customer-support application might ask AI to extract an order number, explain a refund policy, and investigate why a customer keeps running into the same problem. Those requests arrive through the same interface, but they ask for very different kinds of work.

Choosing one model for the entire application means making the same quality, cost, and capability tradeoff for all three prompts. Elektric makes that decision at the request level instead.

Elektric first classifies the request by task and difficulty. It then checks what models support the request’s requirements, and selects one to execute it. Benchmarks inform those routing policies, while fallback handles eligible execution failures.

That is the basic mechanism. Your application sends one request to Elektric. Elektric decides what kind of work it is, which routing policy applies, and which eligible model should handle it.

Start with the type of work

Before Elektric selects the model that will answer a request, it first classifies the request itself.

The classifier is not trying to answer the prompt. Its job is to identify what kind of work is being asked for and how difficult that work appears to be. It returns a task category, an easy-or-hard difficulty label, and a confidence value.

Today, Elektric uses six broad categories:

• Code

• Quantitative

• Knowledge and risk

• Reasoning and decisions

• Writing and transformation

• Extraction and classification

The important part is that the classifier focuses on the underlying intellectual work, not just the words in the prompt or the format of the answer.

Writing SQL is a coding task. Calculating a financial value is quantitative. Making a nonnumeric business recommendation is reasoning and decisions. Summarizing a document is writing and transformation, while copying specific fields from that document is extraction.

This gives Elektric a more useful way to think about model selection than simply asking which model is strongest overall.

Difficulty matters too

Elektric also classifies requests as easy or hard.

Easy work usually means something routine: direct extraction, a familiar pattern, a straightforward calculation, ordinary drafting, or a request with limited ambiguity.

Hard work is more likely to involve several dependent reasoning steps, conflicting evidence, advanced derivation, system-level debugging, difficult constraints, or substantial ambiguity.

Length alone does not make a task hard. A long prompt can still ask for a simple operation, while a short prompt can contain a genuinely difficult problem.

The goal is to estimate the demands of the task, because those demands help determine which part of the routing policy should be used.

From classification to routing

For ordinary text-based chat requests, selection follows two inputs: category and difficulty. Some specialized requests follow additional modality-specific rules.

That gives Elektric a simple structure:

category × difficulty

Each category and difficulty level maps to a routing policy containing one primary model or a pool of candidates, sometimes with a designated fallback. Elektric filters candidates for production eligibility and required capabilities. When multiple primary candidates remain, the current implementation selects randomly among them.

A request involving streaming, tools, web search, image input, or document input must still go to a model that supports those capabilities.

The classifier decides what kind of work the request represents. The routing policy decides which models are appropriate for that kind of work. The execution layer then checks whether those models can actually serve the request.

What a request looks like in practice

Consider a developer asking Elektric to diagnose a concurrency bug in a payment-processing service.

The classifier could identify that request as hard coding work. Elektric then filters model candidates against the request’s execution requirements, and selects a model to respond.

If the selected provider encounters an eligible failure before response content begins streaming, Elektric can attempt a compatible fallback.

Now compare that with a routine request to rewrite a short customer email. That request could be classified as easy writing and transformation, which would send it into a completely different part of the routing policy.

Benchmarks help shape the policy

Benchmarking helps Elektric decide which models are best suited for different kinds of work.

We test models on task-specific benchmarks across categories like coding, quantitative work, reasoning, writing, and extraction. Those evaluations look at more than just quality. We also consider things like cost, latency, reliability, and how often a model fails to complete the task.

For example, our coding benchmarks include real software-engineering problems like debugging concurrency issues, handling retries, validating webhooks, and working with transactions. We score the answers against task-specific rubrics that look at correctness, edge cases, safety, and testing.

This evaluation happens before customer requests are routed. Elektric does not send each live request to every model and compare the answers in real time. Instead, the benchmark results help us decide which models should be eligible for different types of requests.

That gives us a much better basis for routing than relying on one overall leaderboard score.

A concrete example

One historical internal hard "writing and transformation" pilot from August 23, 2026 included 10 prompts and 14 candidate models. All 140 candidate answers completed successfully, producing 280 valid blind judgments. GPT-5.6 Sol and GPT-5.6 Terra were used as judges for every answer.

This benchmark was not measuring unconstrained creative writing. The prompts emphasized things like following detailed constraints, reconciling information, staying faithful to source material, and expressing uncertainty appropriately.

The highest-scoring model was not the most expensive. GPT-5.6 Luna was by far the least expensive of the three, but it also produced a lower average judged score than Sol and had one prompt flagged for severe failure. Claude Fable 5 was more expensive than Sol in this pilot while also receiving a lower average judged score and one severe-failure flag.

That is why Elektric looks at more than one number. Quality, cost, and failure patterns can tell different parts of the story, and routing decisions need to consider them together.

Benchmark results are evidence used to inform routing policy. The models at the top of a particular benchmark are not necessarily the models currently receiving production traffic for that category.

Two routing preferences, one interface

Elektric currently offers Default and Smart Save as different routing preferences.

Default is intended to prioritize answer quality, while Smart Save places greater emphasis on reducing cost through a different set of model choices, while maintaining high quality standards.

What happens when execution fails

Selecting a model is only part of the problem. Providers can still fail.

An alternative model still has to satisfy the request’s capabilities and routing restrictions. Fallback can also come from the same provider. The goal is to recover execution when there is an eligible alternative, not necessarily to switch providers every time.

For streaming requests, fallback is limited to the period before response content starts streaming. Once Elektric has begun delivering the answer, it does not switch models in the middle of that response.

How new models enter the routing policy

When a new model comes out, Elektric evaluates it against the models already in the routing policy. We compare the new model on the same kinds of tasks and look at the tradeoff between quality, cost, reliability, and required capabilities.

If the new model performs better for a particular category and difficulty level, whether by delivering higher quality at a similar cost, similar quality at a lower cost, or a better overall balance of the two, we can update the routing policy and replace the existing model(s) or add the new one to the candidate pool.

That means the models underneath an Elektric application can improve over time without the developer changing their integration. As better models appear, we can update the routing policy behind the same stable interface.

The models can change. Your application shouldn't have to

As new models launch, prices change, capabilities improve, and providers become more or less reliable, Elektric can update the models used underneath the application while the developer continues using the same interface.

There may never be one best AI model. That is exactly why model selection belongs in infrastructure.