These three rows show up on the same shortlists because they are widely used hosted names from three large vendors. They are not interchangeable. At the prices on their listings when this page was updated, the input rates span roughly a factor of seven and the output rates a factor of six. That gap is the decision.

The table below is generated from the directory rows, not typed by hand. Read it as a set of constraints, then read the sections for the part a table cannot show: what each price buys.

What the table is good at

The table is reliable for the fields it stores: company, context window, modality, license, benchmark values where a source published them, and the two price rows. Those are the constraints that eliminate options. If the work needs audio input, one row is out. If the output must be generated in a jurisdiction the vendor does not serve, another is out.

The table is not a quality ranking. A higher directory score means a model sits higher on a public index, not that it will do your task better. A benchmark row is one test set, and the row you are reading is one column of a table you did not design. Use the table to build a shortlist of two, then run your own prompt through both.

The price gap is a routing decision

The honest use of a price spread this wide is to pay it only where it changes the outcome. Route by consequence, not by category:

  • Cheap by default. Classification, extraction, summarisation of short passages, drafting that a human edits, and any call whose wrong answer is caught by a schema or a test.
  • Expensive by exception. Multi-step code changes, long documents with cross-references, tool-using agents where a wrong action has a side effect, and anything where a plausible wrong answer reaches a customer.
  • Measure the escalation rate. A cheap model that handles seventy percent of traffic is a saving. A cheap model that handles thirty percent and escalates the rest costs you the routing logic and the delay.

Write the rule down before launch, log which route each request took, and review the split after a week. A routing rule that nobody measures is a way of feeling sophisticated while paying for both models.

Where the gap is real

The expensive model earns its price on work where the cost of a wrong answer is higher than the cost of the call. That is usually work with several dependent steps, work where the input is long and the relevant detail is buried, and work where the output is an action rather than a paragraph.

It also earns its price on reliability. A model that follows a format on the first attempt saves a retry, and the retry is part of the unit cost. If the cheaper row needs a second attempt on one request in five, multiply its price by 1.2 before you compare. If it needs a longer prompt to hold the format, add those tokens too.

Where the gap is not

Context window. All three advertise windows of roughly a million tokens, and none of them uses that window evenly. Accuracy tends to fall as input length grows, and a detail in the middle of a very long prompt is recovered less reliably than the same detail near the end. A large window is capacity, not quality. Sending fewer, better-chosen tokens is usually cheaper and more accurate.

Benchmark differences of a point or two. The test sets are fixed and therefore leaky, the harness differs between vendors, and the aggregate hides the distribution. A one-point gap does not survive contact with your data.

The label "Flash." It describes a position in a family, not a measured latency on your workload. Time to first token depends on prompt length, region, and load. Measure it.

Variants are separate rows

The listings also include batch and fast endpoint variants. A batch row is the same weights with an asynchronous contract and a lower price; a fast row is the same weights with a higher price and a latency promise. They belong in a different comparison, because they answer "how should I call this model" rather than "which model should I call." The endpoint comparison walks through that decision for one family.

A rule to write down

Start with the cheap row as the default. Escalate when the task matches a named condition, not when the cheap answer feels weak. Set a budget per request and per account. Log the route, the cost, and whether the answer was accepted. After a week, compare the accepted-answer cost of the two routes, not their token prices.

If the escalation rate is above half, the cheap row is not saving you anything; move the default. If it is near zero, check that the escalation condition is actually firing and not silently unreachable. The point of a shortlist this wide is to buy the expensive call only where it is doing work.