The directory lists three rows with almost the same name: Claude Opus 5, Claude Opus 5 (batch), and Claude Opus 5 (Fast). They are not three models. They are three contracts for calling the same weights. The table below shows the difference in the price rows; the difference that matters is the latency and throughput each contract promises.

This is a useful comparison because it separates two questions that people merge: which model, and how do I call it. Answer the second one after the first, not before.

A batch row is not a cheaper model

The batch row is priced at half the standard rate because the request is asynchronous. You submit a job, the provider processes it without an interactive deadline, and the results arrive later. At the vendors we checked, the discount applies to both input and output, and the turnaround is measured in hours rather than seconds, with a service-level target that can be as long as a day.

That makes batch the right contract for work with no human waiting: evaluating a prompt across a thousand examples, classifying a stored corpus, generating reports, backfilling summaries. It is the wrong contract for a chat, a support widget, or an agent loop that a person is watching. Comparing the batch price with the standard price in the same budget is comparing a delivery truck with a taxi.

Two practical checks before you move a workload to batch: does the job tolerate a retry without double-writing, and do you have a place to store results until they arrive? A batch job is a data pipeline, not a function call.

Fast is a latency purchase

The fast row is priced at roughly twice the standard rate. What it buys is a latency and throughput commitment: the provider prioritizes the request, and the time to first token and tokens per second improve under load. It does not buy a better answer. The weights are the same.

That premium is worth paying when a person is waiting and the wait changes the product: an autocomplete, a live assistant, an interactive review tool. It is not worth paying for a background job, a nightly report, or an agent step that already spends most of its time in tool execution. Measure the end-to-end latency before you assume the model is the bottleneck.

The fast premium also compounds in an agent loop, because every step pays it. A ten-step task at twice the token price is not twice the cost of a one-step task; it is the sum of ten fat steps.

The standard row is the default

The standard row is the contract to use until something forces a change. It is interactive enough for most products, priced in the middle, and it is the row that the batch and fast variants are derived from. Start there, measure the two numbers that matter, and move only if one of them fails:

  • If the user waits too long, try the fast row on the slowest step, not on every step.
  • If the bill is too high and the work is offline, move the offline portion to batch and keep the interactive path standard.

This is a routing decision inside one model family, which makes it easy to test: the answers should be identical, so any difference you see is noise or a different endpoint configuration. That is a cleaner experiment than comparing two models, where quality and latency move together.

What the rows do not tell you

The price rows do not show rate limits, maximum output, or the actual queue depth. A batch job can finish in an hour or take most of a day; the SLA is a ceiling, not a promise. A fast endpoint can still be slow when the region is busy. Check the vendor's limits for your account tier, and measure the p95 latency on your own prompt rather than the median on a demo.

They also do not show the cost of waiting. A batch job that saves half the token bill but delays a report by six hours may be a bargain or a broken promise, depending on who reads the report. Put that number in the decision, not just the price column.

How to decide

Write down three facts before you choose a row: whether a person is waiting, how long the work can be delayed, and what share of the workload is offline. Then:

  • Interactive and latency-sensitive: standard, with fast on the step that misses its budget.
  • Interactive but latency-tolerant: standard; do not pay the fast premium by reflex.
  • Offline and delay-tolerant: batch, with an idempotent writer and a result store.
  • Mixed: split the workload by path, and measure the cost per accepted answer for each.

The weights are the same in all three rows, so the quality question is already settled. What remains is queueing, and queueing is an engineering decision, not a model one.