AI API Price Changes: 680 Routes Checked Over Two Days

We compared two complete OpenRouter catalogue captures from 26 and 28 October 2026. Of the 680 route IDs present in both, 24 had a changed pricing object and 656 did not. Six of the changed records were floating aliases. This is a small, reproducible observation of catalogue movement, not evidence that 24 model vendors changed their prices.

The distinction matters because a route can change its provider mix, expose a new cache field or point at a different model. The Terra alias, for example, moved from GPT-5.6 Terra to GPT-6.1 Terra. Counting that as a price cut on an unchanged model would misdescribe the event. Other records showed input and output rates moving in opposite directions, making a single “cheaper” label depend on the workload.

The complete 24-record change table, paired source extract and reproduction script are below. We kept increases, decreases, aliases and missing fields so another reader can reproduce the result or challenge the interpretation. No inference requests or paid model calls were made for this study.

The first capture contains 690 unique routes and the second 692. That small net increase hides twelve additions and ten absences. The overlap is 680 routes, which is the population used for the paired pricing comparison. Joining on exact identifiers prevents a newly listed route from being treated as though it had a historical price in the earlier capture.

Among those matched routes, 24 complete pricing objects changed, equivalent to approximately 3.53% of the matched population. This is our arithmetic on the saved data. It is not the percentage of AI models that repriced globally, and it is not weighted by requests, token volume or revenue. A rarely used route counts once, just as a popular route does.

The unchanged records matter. Without the denominator, a list of two dozen changes could imply that the entire market moved. Without the changed rows, a statement that most records were stable could hide material differences for an application using one of them. The useful result is both: the matched population was mostly stable, while particular route quotes changed enough to warrant checking the actual workload.

The source is the OpenRouter all-modality models endpoint. We use all output modalities because a text-only view would omit parts of the catalogue and distort route counts. The response metadata reported a total count matching the returned records and no next-page link at both captures. These checks establish the scope of the saved responses, not a guarantee that the catalogue covers every available AI model.

The comparison joins exact route IDs, then compares the complete nested pricing object. It preserves fields that were added or removed rather than converting absence into zero. Alias targets are retained as a separate field so a change in the thing being routed to can be identified. Descriptions and benchmark claims are unnecessary for this calculation and are excluded from the public extract.

The reproducible unit is a route record. Batch variants, free variants and floating aliases remain distinct because that is how the API exposes them. This choice is deliberate and limits the conclusion: route counts are not model counts. A researcher interested in unique underlying models would need a separate, documented deduplication method rather than simply deleting similar-looking names.

The table shows the 26 October value followed by the 28 October value. Scalar input, output and cache-read fields are converted from dollars per token to dollars per million tokens. A dash means the field was not present; it does not mean free caching or unsupported caching. The JSON retains the complete original pricing objects, including the Terra alias's cache-write and long-context override changes.

The displayed table is the full set of 24 changed pricing records, not a selection of the most dramatic examples. Eighteen are non-alias routes and six are floating aliases. The surrounding catalogue contains other routes with unchanged prices, as well as the separately listed additions and absences. Those inputs remain in the paired extract for readers who want to use a different definition of change.

Do not read a route's displayed scalar as a promise about every provider or request. Long-context tiers, media units and routing choices can affect what is charged. The table answers a narrower question: what did these saved public records say at two specified times? That is a useful evidence trail for a pricing discussion, provided the date and the route-level scope stay attached.

Complete changed-price set: 24 route records. USD per million tokens for the displayed scalar fields; 26 October → 28 October 2026. Missing values are —. Nested pricing and alias targets are preserved in the downloads.

Within the 24 changed pricing records, eleven base input rates increased, eight decreased and five stayed the same while another pricing field changed. The chart reports those counts, including aliases. Across all 680 matched routes, 654 numeric base input rates were unchanged and seven were not comparable because of missing or negative-sentinel values. Those are different denominators and should not be interchanged.

DeepSeek V4.1 Flash illustrates why direction depends on the request. Its displayed input rate moved from $0.02 to $0.14 per million, while output moved from $1 to $0.42. A hypothetical request with 10,000 uncached input tokens and 2,000 output tokens therefore moves from $0.0022 to $0.00224 before other charges. A large percentage increase in the small input price does not translate into the same percentage increase in that example's total.

Change the token mix and the conclusion changes. At 10,000 input and 10,000 output tokens, the same calculation moves from $0.0102 to $0.0056. These are workload illustrations using catalogue quotes, not measured transactions or quality-equivalent task comparisons. They show why an operator should replay its own usage distribution through both price sets rather than label the model cheaper or dearer from one column.

The clearest identity event in this comparison is the Terra alias. Its target changes from GPT-5.6 Terra to GPT-6.1 Terra, while its pricing object also changes. A reader looking only at the input and output columns could mistake that for a discount on the same model. The saved target fields show that it is also a routing change to a newer model.

The other five changed aliases retain the same recorded target across these captures, yet their quotes move. That observation does not identify the underlying cause. An aggregator may reflect different provider availability or other catalogue metadata, and the captured records do not prove a first-party repricing announcement. Preserve that uncertainty rather than filling it with a market narrative.

For a production application, the operational response is to record exact routes and resolved targets when available. If following an alias is intentional, define which changes require renewed evaluation. A lower quote is not enough to prove that quality, tool support and behaviour stayed constant. The same principle applies to comparisons published elsewhere: route identity belongs next to the number because it determines what the number describes.

Several changed records concern cache-read metadata. Some gain a field, while others lose one. Treating a missing field as zero would manufacture a discount; treating it as proof that caching is unavailable would manufacture a capability claim. The safe interpretation is that the field was absent from that saved catalogue record.

This matters when estimating repeated agent workloads. An application with a stable instruction prefix may depend on cache behaviour, but a catalogue quote alone does not establish whether the application's requests actually qualify for caching. The relevant provider route, retention period and request structure still need checking. A spreadsheet that assumes a cache hit on every request can understate the bill even when the listed rate is correct.

Keep the missingness in the data and surface it in any downstream analysis. Our CSV uses blank cells for absent scalar values and the page shows a dash. The paired JSON distinguishes the full before and after objects. A researcher can choose a documented imputation rule for a different study, but that rule should remain visible rather than being silently applied to the primary observations.

Start with the routes the application actually uses, then inspect the selected provider and current contract. Multiply observed input, output and cache usage by the relevant price categories, preserving thresholds and tool charges. Compare the resulting task cost with the current budget. Do not use an unweighted average over the catalogue as a forecast for a workload concentrated on a few models.

Keep quality separate from the price calculation. Moving to a cheaper route can change the number of attempts, reasoning tokens or human corrections needed to finish a task. A price-only replay tells you what the same recorded usage would cost; it does not prove that another model or provider would produce the same usage or accepted result. That distinction is particularly important for aliases whose target changes.

The paired data is also useful for monitoring the reliability of a pricing reference. A maintained price table can drift even when there is no prominent launch announcement. This study does not create an automatic monitoring job or promise a particular refresh schedule. It provides one documented example of the kind of change a reference owner should preserve and verify before making a public comparison.

Suggested uses of this fixed historical study. None turns catalogue observations into provider billing guarantees.

Download the paired snapshots and the Python script into the same local directory, then run the script with Python 3. It reads the saved files and writes a comparison JSON and CSV; it makes no network requests and sends no prompts to a model. Decimal arithmetic is used for token-price conversion so small prices are not silently rounded into zero.

The public extract includes all routes from both captures, with route ID, pricing, alias target and modality fields. Metadata retains capture timestamps, source URL and the original response hashes. It is a field-preserving extract for this study, not a byte-for-byte copy of the original response; the original-response hash therefore should not be mistaken for a hash of the smaller downloadable file.

Use the result with its boundaries intact. This is a two-capture study over about two calendar days, not a measure of intraday volatility or a long-term trend. A price may have changed between captures and returned to its earlier value without appearing here. The evidence supports the observed endpoints and the exact changed-record set. It does not support a story about everything that happened between them.

Download the 24-row CSV, paired source extract, complete comparison JSON and reproduction script. Run python3 reproduce.py beside the paired JSON.

Continue with the maintained frontier price index, model catalogue interpretation, the Terra launch. For implementation support, explore our AI transformation services.