Which of your models should actually run the workload?

Where the estimate went wrong

The buyer said $18.00/month. Here is every named reason that number is not what this workload costs, and what each one is worth.

Each row changes one thing about the buyer's own assumptions and reprices the whole bill. The dollar figure is what that mechanic was worth given everything changed above it, so the steps sum to the gap between the buyer's own assumptions and the measurement, not to the column total. Negative means the correction made the bill cheaper.

The table below is the same walk, frozen at the numbers current when this page was generated.

Steps run from the most fundamental quantity to the most specific. Each dollar figure is what that mechanic was worth, given everything changed before it. A different order would give different per-step figures and the same total.

Mechanics this route never exercised

Absent rather than zero. A row reading $0.00 beside a mechanic that never ran looks like a saving nobody took; these are mechanics that were never available here.

• tiered rates: this model publishes no tier thresholds, so the prompt size cannot change its rate
• provider choice: route A does not let the buyer pick a provider, so there was no provider decision to price
• per-call charges: this workload makes no web searches and sends no image as input, so no charge outside token arithmetic applied

Every candidate, at your volume

The shortlist is an input, not a finding. These are the models the buyer named, spanning $0.1400 to $10.0000 per 1M input tokens — about a 71x spread across both procurement routes, out of 458 text models in the catalogue. The job is to test whether the cheap one clears the bar, not to rank the market, and the reason each candidate is here is printed on its own row.

Quality and latency are locked: they were measured against a golden set at a timestamp and cannot be recomputed in a browser. Cost per call and per month respond to the panel at the top of the page.

"Effective" is the blended input rate after caching, computed from the measured profile. It is printed beside the list price because the two columns rank candidates differently, and the list price is the one nobody pays.

The same measurement, cut by question kind

One accuracy figure per candidate hides which questions the candidates separate on. This is the same run, re-cut: how many of each kind of question each candidate answered correctly, over the calls that were served. A question that was never answered is named under the cell rather than counted as a wrong answer.

No candidate answered a Not answered by the contract question wrongly. Every difference the quality bar actually found is in “Stated in one clause”, “Needs two clauses combined”, and it is what fails GPT-4o-mini. A workload made only of the first kind has no measured reason to prefer the more expensive candidate. A low score on a kind is a failure to weigh against that candidate's price; a perfect score on a kind everyone passes is not a reason to buy it.

The same workload, bought asynchronously

The Batch API is asynchronous and text-only, one provider per batch chosen at submission with no fallback, and it returns no per-request latency. What it does return is usage.cost for the whole batch — so this route can be priced in two independent ways, and this section keeps them apart. The published columns are what the catalogue lists for the :batch card. The measured columns are what the calls were really charged: the synchronous bill from the sum of that run's per-call costs, the batch bill from the batch's own usage.cost. 1 of these candidates were bought as a batch on this workload.

The two ratios answer different questions and neither substitutes for the other. The published ratio compares two rate cards and is true of every workload. The measured ratio compares two bills for these 14 questions and is true of this one — a model can publish 50% and settle somewhere else entirely, because caching, tiers and reasoning tokens are not uniformly discounted. OpenRouter's own docs say so about non-token components; this table is what it looks like when it happens.

Pricing a monthly volume off the batch bill

The batch API reports one cost for the batch and none per request, so there is no per-call price to measure. The figures below are the batch bill divided by the calls it completed — arithmetic, not observation — and they are in their own table for that reason. They are what a monthly commitment would be priced from; they are not a per-call measurement, and nothing here should be quoted as one.

Candidates the asynchronous leg could not run

A model with no :batch entry in the catalogue cannot be run asynchronously at all. The leg names them rather than leaving a silent gap in the table above, because a missing row reads as an oversight and this is a fact about the catalogue.

Across the whole catalogue, the discount is a typical case

OpenRouter's announcement says batch requests "generally charge 50% (and sometimes less) of their normal per-token price", and that is accurate as a description of the usual case. It is not a rule, and a buyer pricing an async workload against it will be wrong on 7 of the 72 cards that carry a rate on both sides.

Read from the catalogue at 2026-09-28T09:03:36.555Z, at no cost: every :batch entry is a full model entry with its own pricing, so the comparison needs no submission. It is a price list, not a bill — the two columns above are labelled accordingly.

The three procurement routes

Route C is an estimate built from named assumptions, not a quoted price, and it is the only row in the repository with no monthly cost field. Sorting it beside A and B as though it were one more price is the mistake this table exists to prevent.

The monthly figures for routes A and B price each candidate's own measured token profile at this workload's stated volume, and they are fixed. They are not the candidates table above, which moves with your inputs; where the two differ, they are pricing different configurations and both are right.

Assumptions this page rests on

What this tab cannot tell you

Where the estimate went wrong

The buyer said $25.00/month. Here is every named reason that number is not what this workload costs, and what each one is worth.

Each row changes one thing about the buyer's own assumptions and reprices the whole bill. The dollar figure is what that mechanic was worth given everything changed above it, so the steps sum to the gap between the buyer's own assumptions and the measurement, not to the column total. Negative means the correction made the bill cheaper.

The buyer's stated estimate plus every change below it comes to $77.43 against the $77.42 on the total row, because each row is rounded to the cent on its own. The bridge closes to $77.4229 before that rounding. The bold line is a running subtotal, not another amount to add.

Steps run from the most fundamental quantity to the most specific. Each dollar figure is what that mechanic was worth, given everything changed before it. A different order would give different per-step figures and the same total.

Mechanics this route never exercised

Absent rather than zero. A row reading $0.00 beside a mechanic that never ran looks like a saving nobody took; these are mechanics that were never available here.

• tiered rates: this model publishes no tier thresholds, so the prompt size cannot change its rate
• prompt caching: The measurement found no cache hits, so a discount this route does publish was never taken.
• provider choice: route A does not let the buyer pick a provider, so there was no provider decision to price
• per-call charges: this workload makes no web searches and sends no image as input, so no charge outside token arithmetic applied

The candidates, and what they drew

There is no quality gate on this workload, and that is a statement about the measurement rather than about the models. Image output has no correct-share to compute, so the only machine gate is the buyer's own 15,000ms latency ceiling. The pictures are shown so the judgement that the machine cannot make is one a reader can.

Google: Nano Banana (Gemini 2.5 Flash Image) current PASS

openrouter · route A

OpenAI: GPT-5 Image Mini FAIL

openrouter · route A

The same runs, as numbers

Latency and cost are summed over different sets of runs on purpose. A call that returned no picture took some amount of time that was not a generation time, so it is left out of the latency figures; it was billed for the tokens it burned getting there, so it is left in the cost. Two rules pointing opposite ways, and dropping the failed runs from the cost would understate the monthly figure this workload exists to produce.

The open-weight route on this workload, read rather than measured

Neither of these was called. The Hugging Face router catalogue carries 140 models and none of them declare an image output, and the BFL routes that would serve FLUX directly are behind an account with no credit balance - so there is no route to run and no published rate to quote. What is readable is the model card's licence field, and that is what this table reports.

A licence is the one thing on this page that costs nothing to read and cannot be measured. It is still a purchase decision: the permissive row and the restricted row are the same weights with different terms, and the terms decide whether the cheaper one is usable at all.

The three procurement routes

Route C is an estimate built from named assumptions, not a quoted price, and it is the only row in the repository with no monthly cost field. Sorting it beside A and B as though it were one more price is the mistake this table exists to prevent.

The monthly figures for routes A and B price each candidate's own measured token profile at this workload's stated volume, and they are fixed. They are not the candidates table above, which moves with your inputs; where the two differ, they are pricing different configurations and both are right.

Assumptions this page rests on

What this tab cannot tell you