Reference · Model landscape

Frontier AI and leading market competitors

Vendors ship faster than procurement cycles run. This is a one-page orientation: which tier a model belongs to, what the nearest equivalent is elsewhere, and which names are already retired.

Use it to frame a build-versus-buy or self-hosting conversation — not as a benchmark. Capability claims move monthly; tier logic does not.

By Yousef A. Salam

The frontier AI expansion, 2018 to 2026: model timelines for Meta, OpenAI, Anthropic and Google, each model labelled with its specialisation, dates and active, retired or in-testing status

Eight years of releases across four frontier labs, as published. The status indicator matters more than the specialisation line.

Four tiers, and what each one is for

Tier 01

Flagship & reasoning

Complex reasoning, coding and long context. The tier you use for work that would otherwise need a senior human review — and the tier whose cost per call makes finance leaders ask for a business case.

Tier 02

Lightweight & speed

Cost-effective, low-latency and often good enough for classification, extraction and routing — the majority of finance automation volume. Open small models in this tier are what make local deployment realistic.

Tier 03

Media generation

Image, audio, video and multimodal understanding. Rarely on the critical path for a finance function, but the tier most likely to arrive as an unbudgeted departmental subscription.

Tier 04

Retired & legacy

Foundational research models and superseded generations. Their names persist in vendor decks, RFP responses and internal proposals long after they stop being available — check status before evaluating capability.

How to use this in a procurement conversation

Fix the tier before the vendor. Decide what the task actually needs. Most finance automation sits in the lightweight tier, and paying flagship rates for extraction is the AI equivalent of shelfware.
Then ask open or closed. Open-weight models can be downloaded, owned and self-hosted; closed models are reached through someone else's API. For a regulated business this is a data-residency and control question first.
Price the runtime, not the model. A single-user laptop runtime and a production serving stack behave nothing alike under load. The same weights can be cheap or ruinous depending on how they are served.
Check status, not reputation. If a proposal names a retired model, the proposal was not written this quarter.

Model choice is a procurement decision wearing engineering clothes. Fix the tier, then the access model, then the runtime.

Model names, tiers and availability change frequently — verify current status with each vendor before committing to a configuration.