Which Frontier AI Model Should You Use?

Start with the task you can judge. A coding change needs working tests and a reviewable diff; an invoice extraction needs correct fields; a voice assistant needs to handle interruptions. The useful frontier model is the one that meets that specific standard through an API you can use, at a total cost you have measured. A launch ranking cannot make that decision for you.

This guide joins current provider evidence to a practical selection method. The tables cover selected models from OpenAI, Anthropic, Google, SpaceXAI, and DeepSeek, including lower-cost candidates and voice endpoints that solve different parts of a workflow. They are a bounded reference, not a claim that these are the only capable models or a universal performance ranking.

For an initial coding evaluation, compare GPT-6.1 Sol and Claude Sonnet 5.5 with Claude Opus 5.5 on the same work. For narrowly specified extraction, include GPT-6 Luna and Gemini 3.5 Flash-Lite. Treat these as candidate sets chosen from documented capabilities and prices. We have not run a cross-provider benchmark for this guide, and none has earned a production recommendation merely by appearing here.

The current decision starts with availability. Google has announced Gemini 4 Argon, but its initial rollout is through the Fairwind Program for trusted cyber defenders. A forthcoming public API price does not make it a route an ordinary application can deploy today. Keep an announced model in the watch list until the required access, identifier, and service terms exist for your account.

The other easily missed distinction is the provider surface. Our frontier model API price index remains the canonical pricing reference and retains its dated observations. This page independently checks the selected cells below against the vendors on October 4. An older reseller observation in the index is not a fresh direct-provider quote; its source date and buying surface still matter.

Prices below are US dollars per million tokens on the direct provider's stated tier. Read input and output as separate meters, not as a combined price. Cache is the price for reading eligible cached input; it does not establish a hit rate or include writing and storing a cache. Ordinary text rows cannot be compared directly with audio-token rows.

The table keeps an access-limited announcement and the live voice endpoints visible because excluding them would hide useful boundaries. It does not count an announced rate as a purchasable offer. For the ordinary APIs, documented availability means that the provider describes the route; we did not authenticate an account, buy credits, or submit inference requests to establish individual access.

Long prompts change several rows. The OpenAI model pages apply twice the input and cache rates and 1.5 times the output rate to the full request above 272K input tokens. Gemini 3.1 Pro moves to $4 input, $18 output, and $0.40 cached input above 200K. Grok's price table marks its long-context threshold at 200K and lists $4/$12 with $1 cached input; accompanying prose says above 200K, so budget the higher rate at the boundary until your endpoint confirms it.

Promotions and clocks need a separate budget. Google's price page lists Gemini 3.8 Flash at $1.50/$7.50, with $0.15 cached input, from January 1, 2027. DeepSeek's peak windows are 01:00–04:00 and 06:00–10:00 UTC on weekdays except Chinese public holidays; other periods use off-peak rates. Its current pricing page maps older Flash identifiers to V4.1 Flash. Pinning a familiar string does not always pin the underlying model.

Argon's announcement is not a live price test. Google says $2/$10 initially, then $4/$20 after an unstated introductory period. The displayed $0.10 cache figure is our arithmetic: $2 multiplied by the remaining 5% after the announced 95% discount. Neither a public API start date nor the introductory end date was supplied in the captured announcement.

These qualifications come from the linked OpenAI model specification, Gemini price schedule, xAI price schedule, DeepSeek price schedule, and Argon announcement. Residency premiums, tools, batch, priority processing, and negotiated contracts are outside these base rows.

A context window is the space available to a request and its conversation; it is not a promise that every fact inside a long document will be used correctly. An output cap is a ceiling, not a target. Google publishes separate input and output limits, which we label explicitly. Do not add an output allowance to another vendor's context figure and assume the sum is supported.

Knowledge cutoffs also need their labels. Anthropic distinguishes reliable knowledge from the broader training-data cutoff; the Haiku row preserves both. A blank in a model card is not permission to substitute the release date. “Not located” means the captured source set did not establish the field, while “not published” is reserved here for fields absent from Argon's announcement. Neither means unlimited support.

Effort and lifecycle cells also use Anthropic's lineup, Anthropic's lifecycle policy, Google's thinking table, Google's deprecation schedule, and DeepSeek's effort guide. OpenAI's captured model pages do not establish a model-specific retirement floor. Grok's guide says there is no separate text-output limit; the context budget still constrains a request.

For procurement, an announced earliest retirement date is a planning floor, not a shutdown appointment. Haiku's October floor deserves attention, but it does not establish that the API will disappear on that date. Keep the alias and retirement ledger beside the context and output census, and recheck the provider before committing a migration deadline.

The routing suggestions below are editorial evaluation designs. They use the documented modalities, limits, and prices above to choose candidates; they do not assert measured superiority. Before testing, define what counts as a correct answer, which failures are unacceptable, and how long a user can wait. Keep the prompt, tools, documents, and review rules consistent across candidates.

Agentic coding. Start with a bounded task: one bug, a reproducible failure, and an agreed test. Compare Sol or Sonnet with Opus, then include Astra or Fable when difficult cases remain unresolved. Judge the final diff, tests, scope control, and review effort. A model that passes a test by deleting the failing assertion has failed the task; a longer reasoning trace does not repair that failure.

Long-document work. Shortlist only routes whose documented limits fit the input and expected output. For document-heavy multimodal work, include Gemini 3.8 Flash or Pro Preview where the preview lifecycle is acceptable; compare a Claude or OpenAI route on the same extracted text when that is the actual application input. Plant questions with known answers and require page-level evidence. Test contradictory passages and missing facts, not just an easy summary at the beginning of a file.

High-volume extraction. Start the comparison with Luna and Flash-Lite, alongside an already approved route if you have one. Require exact field names, valid types, faithful values, and an explicit missing-value policy. Escalate only the records that fail validation or need interpretation. A valid JSON object with the wrong invoice total is still wrong; schema validity alone is an incomplete acceptance test.

Customer-facing chat. Evaluate answer correctness, retrieval citations, latency, tone, and the decision to hand off. Include ambiguous requests and situations where the knowledge base lacks an answer. Choose a richer model when it demonstrably resolves those cases, not because a general benchmark ranks it higher. Keep account changes and other consequential actions behind application checks regardless of model choice.

Voice. Compare an audio-native route with a cascade of transcription, text reasoning, and speech generation if both architectures meet your needs. The two Gemini Live rows have the same published token rates but different reasoning and tool behavior. The Extended Thinking model supports asynchronous tool calls; it needs a client that understands background work. Test interruptions, silence, noisy input, and a tool result arriving after a spoken response.

Keep an untouched evaluation set for the final decision. If you tune prompts after every failure and score on those same examples, you are measuring how well you adapted to that set. Report the number and type of tasks, the model and surface, effort, token use, failures, and reviewer time. That is enough to make a local decision without pretending that your result is a market-wide leaderboard.

Consider an illustrative request with 8,000 input tokens and 2,000 billed output tokens, including any billed reasoning. The uncached estimate is input tokens times the input rate, plus output tokens times the output rate, divided by one million. These are chosen accounting assumptions, not observed tasks. Different tokenizers and reasoning behavior mean that identical text will not necessarily produce identical token counts.

The warm-cache column instead assumes 2,000 uncached input tokens, 6,000 eligible cache-read tokens, and the same 2,000 billed output tokens. It represents a hit on an already established cache. It excludes cache creation, storage, expiry, misses, tools, retries, tax, and human review. Include those items before treating it as an operating budget; the table deliberately isolates the token arithmetic.

The chart plots the provider rates recorded above, scaled to the highest displayed rate. It is a price chart, not a performance chart. Sources: OpenAI, Anthropic, Google, and SpaceXAI.

Under the uncached assumptions, moving from Sol to Opus adds $0.036 per attempt; moving from Opus to Fable adds $0.108. Those are useful price gaps when deciding what to test. They do not tell you whether the second attempt will succeed, or whether a more capable first attempt would have avoided the retry. A fallback that repeats the entire prompt creates another bill.

For a real batch, divide all attempt charges plus review cost by the number of accepted outcomes. Keep rejected work in the numerator. Otherwise a route that cheaply produces unusable answers looks artificially efficient. If no output is accepted, there is no meaningful cost per accepted task to report. Voice needs its own accounting because audio and text use different meters and a conversation contains more than one turn.

Effort labels are provider controls, not a shared unit of thought. “High” on one model need not spend the same tokens, take the same time, or achieve the same result as “high” elsewhere. Anthropic's effort guide describes a behavioral signal rather than a strict token budget. Its current API default is medium for Opus 5.5 and high for Sonnet 5.5 and Fable 5.1. Comparing omitted settings is already comparing different choices.

OpenAI's model pages list medium for Sol and Luna. We did not locate an Astra default in the captured model page, so the table does not guess one. The API's documented values also need not match a Codex or ChatGPT model picker. A subscription grants usage under that product's rules; it is not evidence of the direct API's identifier, price, or available effort values.

Google's thinking table gives Flash 3.8 a medium default, Flash-Lite 3.5 minimal, and Pro Preview high. The ordinary Live model does not accept the thinking-level control. Its Extended Thinking sibling does, but that is a different endpoint with different client behavior. Use the effort-ladder reference for surface-specific historical context, then verify the current surface before copying a setting.

A useful evaluation varies one factor at a time: keep the task and tools fixed, compare supported effort levels on one model, then compare the best acceptable configuration with another model. Log billed output and completion time rather than assuming that lowering the label always saves the same percentage. Extra reasoning may help on some tasks and merely lengthen others.

These 42 chapters retain their original publication dates and URLs. They span model generations, deployment choices, assistants, and related commercial comparisons; the directory is the selected historical series, not a claim that every row is a like-for-like model benchmark. The short descriptions identify the subject without certifying old prices, availability, benchmark populations, or conclusions.

Use a chapter to understand the question people were asking at the time. Use the current vendor links above for a purchase or implementation decision. The August tracker, September tracker, and October tracker preserve the surrounding release chronology.

This is a provider-document census for a selected routing set. It establishes what the cited sources stated when retrieved, not whether a model will satisfy a task or whether your organization will receive access. The practical value is in keeping the rate, endpoint, limit, date, and missing field together. A table loses that value when a number is copied without the condition beside it.

Write a short selection record before sending a production workload: the task, acceptable errors, required modality, data terms, exact endpoint, effort, expected token mix, latency requirement, and fallback behavior. Pick a current candidate and a plausible challenger. The table narrows that choice; your evaluation settles it.

Keep the decision reversible. Save the prompt and tool configuration, record the returned model version where the provider exposes it, and retain a small regression set. Re-run the relevant cases when an alias moves, a model changes, or your workload expands. Rechecking only the price page will miss a change that makes an earlier success criterion fail.

When a route passes, set a budget from actual usage rather than the illustrative rows. When it fails, name the failure: missing evidence, invalid action, wrong field, unacceptable latency, or excessive review. That tells you whether to change the model, the prompt, the retrieval, or the surrounding application. Buying more reasoning cannot fix every input or workflow defect.

For related implementation scope, see our AI transformation service.