Blog / Model watch

Track LLM API Price Changes: Changelogs, Model Catalog, Billing

2026-10-17cdnping editors8 min read

If you want to know promptly when an LLM API changes price, ships a new model, or retires an old one, the least painful approach is to watch three kinds of sources at once: vendors' official changelogs and pricing pages, the public model catalog of an aggregator such as OpenRouter, and anomalies in your own bills and request logs. The first two can be diffed automatically, and cdnping's site changes page /en/changes and model monitor /en/models cover one each. The third you have to wire up yourself. Below: what each source can tell you, how to subscribe, and how to build your own script.

#Vendors announce price changes, so why track them yourself

Vendors may email you when they change prices or retire a model, but the email usually goes to the address bound to the account, and the people who actually write code and configure routing may never see it. Several kinds of change also don't always come with a separate notice:

• A single row on a pricing page is quietly edited, or the cache-hit price or a long-context tier is adjusted on its own;
• A third-party inference provider switches the quantization of the same model, for example from fp8 to fp4;
• A model ID disappears from an aggregator's catalog, or a new ID with a date suffix shows up.

These changes affect cost or output quality. Checking web pages by hand once a week is easy to miss, so this is a good fit for automated diffing.

#The three sources to watch and what each can answer

A few things to keep in mind:

1. The official page is the source of truth. A price on an aggregator is that aggregator's own selling price and may differ from the vendor's direct price. For conclusions about a price change, go by the vendor's pricing page.
2. Watch changelogs and pricing pages separately. They are not always updated together, and watching only one can mean finding out days late.
3. Clean structured data before using it. The OpenRouter catalog contains special values, and taking a minimum over the raw data gives a wrong answer. An example follows below.

#What cdnping's /changes and /models can show you

#Site changes (/changes): line-by-line additions and removals on official pages

cdnping is a free network observability site for developers. /en/changes monitors 11 official changelogs, pricing pages and news pages, including DeepSeek, OpenAI, Codex, Claude, Gemini, xAI, Kimi (Moonshot AI) and Alibaba Cloud Model Studio. It periodically fetches the page body, compares it line by line with the previous snapshot, and records which lines were added and removed. What you see is which line of the original text was added or deleted; judging the impact is up to you.

The page offers an RSS feed. Subscribing to it is less likely to let something slip by than opening the page every day.

#Model monitor (/models): the OpenRouter catalog and inference providers

/en/models reads OpenRouter's public API and shows, for the latest models from each vendor, availability, latency, throughput and quantization on each inference provider. It automatically records four kinds of events: listed, delisted, price change, and quantization change.

Here is a single-day snapshot cdnping took of the OpenRouter public model catalog on October 17, 2026:

• The catalog contained 376 model entries;
• The maximum value of the input price field was 150;
• The minimum value of the input price field was -1000000. This is clearly not a real price but a placeholder used by special entries.

The last point is a trap when writing your own script: if you don't filter out negative numbers and placeholder values, the "lowest price in the catalog" comes out negative, and price-change alerts produce false positives. cdnping only started collecting on 2026-10-17, so this is a one-day snapshot and does not represent a long-term trend.

The provider data from the same day also shows differences in quantization: for the same model, some inference providers are labeled fp8, others fp4, mxfp4 or int4, and quite a few are unlabeled. If you call models through an aggregator, fluctuations in output quality may come from a provider switch rather than from the model itself changing. /models records quantization changes as events, so when troubleshooting you can first check the timestamps.

The /models page also links to several third-party "model got dumber" benchmark projects (Livenerf, AI Stupid Level, Is It Nerfed?, BridgeBench Nerf Bench). cdnping does not republish their data; go to the original sites when you need it.

#How to push price and release alerts to your team chat

The steps below go from personal to team.

#Step 1: Subscribe to the /changes RSS feed

Open /en/changes, copy the RSS URL from the page, and add it to your feed reader. If you only care about some vendors, filter by title keyword in the reader, for example keeping only entries containing "DeepSeek" or "pricing".

#Step 2: Pipe the RSS into your team chat

There are two common approaches:

• Group bots in Feishu (Lark), DingTalk and WeCom (WeChat Work), the main workplace chat tools in China, all support webhooks. Use a scheduled job to read the RSS and push new entries to the webhook; check each platform's official documentation for the exact parameters.
• If your team already uses a collaboration tool that supports RSS subscriptions, add the feed to a channel directly.

Create a dedicated "model changes" channel rather than mixing it with your alerting channel. Price changes and releases are information to read, not outages that need immediate action.

#Step 3: Add /models to a weekly routine check

The events on /models are better reviewed periodically. Put it on your weekly checklist and read it together with the weekly stability report /en/reports, which is generated automatically every Monday and can also be subscribed to.

#Step 4: Agree on who judges the impact

An alert only solves the "knowing" part. It's best to name one person on the team who goes through the changes each week and judges them against this checklist:

• Does a model ID we use appear in a delisting or retirement entry? What is the retirement date?
• Does the price change affect input, output or cache-hit pricing? Estimate the effect on the monthly budget from your own usage.
• Is the new model worth trying? Compare with a small share of traffic in a test environment first, then change the production config.
• For models called through an aggregator, has the provider's quantization changed?
• Do hard-coded model IDs and unit-price constants in the code need updating?

#How to build your own tracking script

If you need to watch pages cdnping doesn't cover, or want to store the data in your own system, you can follow the approach below. It is written as pseudocode; choose the language and scheduler to fit your environment, such as cron, a CI scheduled job or a cloud function.

#Approach 1: Diff the OpenRouter catalog

OpenRouter's model list endpoint is public (GET https://openrouter.ai/api/v1/models) and returns each model's ID, context length and price. For field meanings and price units, refer to OpenRouter's official documentation.

Run every 6 hours (the interval is only an example):
  current = request the OpenRouter model list, take the data array
  previous = load the last saved snapshot (if none, save current and exit)

  Clean:
    for each model, convert prompt / completion prices to numbers
    if the price is < 0 or cannot be parsed, mark it as a "special entry" and exclude it from price comparison
    normalize to "USD per million tokens" so humans can read it

  Compare:
    added = model IDs in current but not in previous      -> record as "listed"
    missing = model IDs in previous but not in current    -> record as "delisted"
    for IDs present on both sides:
      if the price change exceeds a threshold (e.g. 0.5%, to avoid floating-point false positives) -> record as "price change", with old and new price
      if the context length changed                                                               -> record as "spec change"

  Output:
    push the event list to the chat bot webhook
    save current as the new previous

A few details:

• Only push models you actually use. The catalog has hundreds of entries, and a full push quickly stops being read. Maintain a watch list and just log the other changes.
• Confirm twice before alerting. The API may return incomplete data, and an ID that is temporarily missing is not necessarily delisted. You can require it to be missing from two consecutive snapshots before sending a "delisted" notice.
• Save the raw response. When there is a dispute, the raw JSON is more convincing than your summary.

#Approach 2: Diff official changelogs and pricing pages

Run once a day, for each URL you watch:
  html = fetch the page (with a reasonable User-Agent, low frequency, respecting the site's robots rules)
  text = extract the body: remove navigation, footer and scripts, keep table text, one entry per line
  previous_text = load the previously saved body

  diff = compare previous_text and text line by line
  if diff is empty: exit
  filter noise: ignore lines that contain only dates, view counts or random IDs
  if additions or deletions remain after filtering:
    push "page + added lines + removed lines + link to the original page"
  save text

The maintenance cost of this kind of script is mostly in the body-extraction step. A page redesign or a switch to client-side rendering makes the whole extracted text change, triggering one false alarm. When that happens, confirm manually and update the extraction rules. If you only care about the 11 pages cdnping already covers, subscribing to the /changes RSS is easier.

#Approach 3: Work backward from your own bill

A vendor's price change eventually shows up on your bill. Each day, multiply the token counts in your request logs by the unit prices you have on record to get an estimated cost, then compare it with the actual charge in the vendor's console. If the gap stays above some percentage (say 5%; set it to your own tolerance), the unit price may have changed or the billing rules may have been adjusted, and you should go back and check the pricing page.

#When you call through an aggregator gateway, whose price counts

If you call models through a multi-provider gateway, the price and the available models depend on the gateway's own pricing and model list, and an official price change does not necessarily pass through. Take AGI Plan as an example (AGI Plan is a commercial partner of cdnping): it is billed as a monthly subscription, settled in RMB, and metered in CU, with available models listed at agiplan.dev/models and plan prices at agiplan.dev/pricing. In this case, besides watching the upstream vendors, you also need to follow the gateway's own model page and announcements.

#Four things you can do today

1. Subscribe to the /en/changes RSS feed now and push it to your team's "model changes" channel.
2. Collect the hard-coded model IDs and unit prices in your code into one config file, so the next price change needs an edit in only one place.
3. Open /en/models, find the models you use, look at each inference provider's quantization and 1-day availability, and write down the current state as a baseline.
4. To check connectivity of the official API endpoints, you can also look at API status /en/status; for how the data is measured, see methodology /en/methodology.