Insights

Selecting the right AI model: A leadership guide to the frontier and open ecosystems

Adnan Masood, PhD, Chief AI architect, UST.

Frontier models are the largest and most capable general-purpose models from major labs, including the Claude, GPT, and Gemini families. Open-weight models are their counterparts, with trained weights published for download so an enterprise can run, fine-tune, and host them on its own infrastructure. Between the two sits a growing middle of small and mid-size models that handle narrow tasks at a fraction of the cost, and a new class of decision models that answer a fixed-choice question with a selected option and a probability, and produce no prose. Selecting the right AI model means choosing across all four.

Ask a board which AI model the company chose and you will get a vendor's name. Ask which workloads that vendor serves, what it costs per correct answer, and what happens when a better model ships next quarter and the answers get thinner. At the time of this writing, the top five or six frontier models sit within a few points of each other, and the open-weight tier matches last year's closed frontier on the tasks most businesses run.

The decision has moved from choosing a vendor to designing a portfolio, and that shift matters because it changes what gets measured and who owns it. A vendor decision gets scored once, on benchmark rank and brand comfort, and nobody owns it afterward. A portfolio decision must be scored continuously on what each workload costs per correct outcome, how quickly a model can be swapped, and whether governance holds when the underlying model changes, which means someone has to own it.

DIVIDER

Tier the workloads before anyone evaluates a model

Three questions remove most candidates: what the model must take in and produce, how much reasoning the task demands, and what latency and volume production will impose. A fraud screen that runs forty million times a day and a regulatory summary that runs once should never share the same model.

High-stakes work such as clinical decision support, credit adjudication, and legal drafting justifies the strongest reasoning model available plus a human reviewer, because a wrong answer costs far more than inference. Interactive work needs a model fast enough that the wait feels instant, usually a mid-tier model with good tool use. High-volume work rewards the smallest model that clears your accuracy bar, and that bar is increasingly cleared by 3-billion to 14-billion-parameter models on hardware you already own, or by a decision model.

DIVIDER

Choose ecosystems by operating model, then choose models

The four ecosystems differ more in operating model than in raw capability, which is what procurement, security, and finance live with.

Anthropic's Claude family (Haiku, Sonnet, Opus, and Fable) is the strongest default for agentic and coding work. Distribution matters as much as capability: the same models are available through Anthropic's API, Amazon Bedrock, Google Vertex AI, and Microsoft Foundry, so a Claude decision leaves the cloud decision open. UST, as an Anthropic Global Premier Partner, helps enterprises choose the right model for each use case across the hyperscalers and the frontier labs.

OpenAI's GPT-5 line reaches most enterprises through Azure, where Foundry wraps it in Microsoft's identity, networking, and compliance layer, an advantage if you already run Microsoft 365 and Entra. Google's Gemini models are tied to Vertex AI and fit best where the data already lives in BigQuery and Workspace.

The open-weight tier is now a fourth ecosystem. Qwen 3.x (Apache 2.0), Mistral Large 3 and Small 4 (Apache 2.0), GLM-5 (MIT), Meta's Llama 4 Scout and Maverick (a community license with usage limits), and Microsoft's Phi family (MIT) can be fine-tuned on your data and run behind your own firewall.

Decision models belong in the high-volume tier. TypeSafe's Jev shipped in September at $0.042 per million input tokens with sub-second latency. OpenAI's Decisions API, a constrained GPT-6 Luna announced at DevDay, accepts text and images and remains in limited preview. Microsoft-Decision-1, a 9-billion-parameter model in Foundry since October, scores fixed choices for routing and agent control. For classification, triage, and an agent's next-action choice, these displace small language models because they are cheaper, faster, and return a probability you can threshold.

DIVIDER

Make evaluation and routing the control plane

Public leaderboards narrow the list, because two models with identical scores can behave differently inside your application. The evaluation that matters runs on a few hundred examples from your own traffic, scored against ground truth or a rubric graded by a stronger model. That evaluation set is a corporate asset and deserves an owner.

Per-token price lists mislead, because a price list describes one call and a bill describes a session. Reasoning models bill for thinking tokens, multi-turn agents carry context on every step, and the total grows faster than linearly with session length.

Routing is the step most teams skip. A model router sends each request to the cheapest model that meets the quality threshold, turning model selection from a one-time decision into a tunable policy. Once routing is in place, swapping a model becomes a configuration change.

This is how UST runs it with clients. We inventory and tier the workloads, stand up an evaluation harness (UST-Eval) on the client's own traffic, and run Claude alongside GPT, Gemini, the open-weight candidates, and the decision models in the client's own cloud. Claude's presence on all three hyperscalers usually lets us leave the client's cloud contract untouched. Red-teaming and governance go in through ResponsibleRails before anything reaches production.

DIVIDER

Govern for the model you will have next year

Compliance review should assume the model will change. Clinical, compliance, and customer-script workloads need version pinning and rollback, and the provider's deprecation policy belongs in the contract. For data residency, open-weight models with local inference remain the cleanest answer, and the EU AI Act's high-risk provisions are making that a requirement in regulated sectors.

The strongest objection is the commoditization argument: the models are converging, so selection is becoming moot and advantage lies in proprietary data and harness engineering. I believe this underestimates how much operating models differ, because models that tie on a benchmark can differ by an order of magnitude in cost at scale, in agent tooling, and in whether your auditors accept the data path.

This method is a discipline, and disciplines decay. Evaluation sets go stale, routers drift toward the expensive default, and the engineers' favorite model outgrows the budget. The fix is operational: a quarterly re-benchmark, a named owner for the evaluation set, and a cost view by model and workload that the CFO sees.

DIVIDER

What a leader should decide now

Decide that model selection is a tiered portfolio with routing as the control plane. Measure cost per correct outcome on your own data, by workload. Assign an owner to the evaluation set and to the quarterly re-benchmark. Then choose the ecosystem whose operating model fits your estate, and hold the specific model loosely, because it will change within the year and the method has to outlast it.

The best AI strategy isn't tied to a single model. It's built to evaluate, route, govern, and evolve as the market changes. Discover how UST AlphaAI helps enterprises select, deploy, and optimize the right AI portfolio for every workload.