Your LLM Cost Tracker Can Go Blind for 54 Days and Never Tell You

The bill shows up before the price does

Say you moved a workload to Kimi K3 the week it launched. The API works, the answers look good, and you get on with your week. Your dashboard shows nothing unusual.

That could be because it isn't showing anything at all. Moonshot launched Kimi K3 on July 16. LiteLLM didn't list moonshot/kimi-k3 until August 22, 37 days later. At 300 million input and 80 million output tokens a month, that's about $2,590 of spend with no cost attached to it.

I wanted to know how often this happens, so I traced 31 model launches through four price tables. The answer depends almost entirely on who made the model.

OpenAI gets a same-day entry. Everyone else waits in line.

For each launch I took the official release date, then found the first day the exact API model ID appeared in each table. The 22 launches from OpenAI, Anthropic and Google were almost boring. The nine from xAI, DeepSeek, Mistral and Moonshot were not.

Small teams and volunteers keep these files alive, and adding a GPT launch the same day is a real achievement. But a median hides the part that costs you money. If you chase cheap tokens at smaller labs, you're exactly the person the slow cases hit.

Read the last row again. Fifteen days after launch, Kimi K3.1 Pro high-speed still isn't among LiteLLM's first-party Moonshot entries. It costs twice as much as the standard version, $4 and $20 against $2 and $10, which makes it a bad model to be blind on.

A missing price doesn't look like an error

This is the part that bothered me. I installed LiteLLM 1.108.2 and ran two mock completions, so no paid call was involved. One used a known model. One used a made-up model ID.

gpt-4o-mini             response_cost = 0.0000135
openai/gpt-99-newmodel  response_cost = None

Both calls returned normally. A logging callback saw the same None. The "This model isn't mapped yet" message only appeared when I called completion_cost directly, and plenty of apps never do that. I tested the Python library, not the LiteLLM proxy UI, so check what your own dashboard does with an empty value.

The genai_prices package is louder. It raised LookupError for the same made-up model. That's better, unless a try block around your cost logging swallows it, which is what cost logging code tends to do.

The prices themselves were better than I expected

I went in expecting a mess, and that isn't what I found. I compared 81 current public text models against our verified first-party rates, exact ID to exact ID, for input and output.

My first pass looked much worse, and a good share of that was my own parser, which read a scheduled January price as today's price. Some of what's left deserves a kinder reading too. DeepSeek charges double during peak hours, and LiteLLM and genai-prices both model those windows, which is more than most tools manage.

A few entries are simply out of date. Perplexity's Agent API model table lists Sonar at $0.25 and $2.50, while several tables still say $1 and $1. Portkey had DeepSeek V4 Pro at $0.435 and $0.87, against an official $0.66 and $1.98 off-peak or $1.32 and $3.96 at peak. Helicone's public cost API had 11 of its 24 Mistral rows about 1,000 times too high, with mistral-large at $2,000 per million input tokens. I checked that API, not Helicone's dashboard.

And tokencost, a package with about 2,000 GitHub stars, last touched its price file on September 1, 2025. If you rely on that one, you're missing more than a year of launches.

Three checks that take ten minutes

You don't need a new tool for this. You need to stop treating a blank as a zero.

• Alert on empty cost, not just high cost. Count the requests where the cost field is null. A healthy number is zero, so anything else is your signal.
• Register the price yourself the day you add a model. In LiteLLM that's litellm.register_model with the input and output cost per token. Copy the numbers from the provider's page and include the cache rates.
• Check your model list against the table, not just your bill. Run the IDs you actually send through the cost map on a schedule. Any miss is a model you're paying for without seeing it.

import litellm

litellm.register_model({
    "moonshot/kimi-k3.1-pro-highspeed": {
        "input_cost_per_token": 4e-06,
        "output_cost_per_token": 2e-05,
        "litellm_provider": "moonshot",
        "mode": "chat",
    }
})

LiteLLM pulls its cost map from GitHub at startup unless you set LITELLM_LOCAL_MODEL_COST_MAP. So a fix on main reaches most installs at the next restart. If you run with the local map or pin genai-prices, add your own upgrade delay to every number above.

Want to see how often this bites? The LLM API price history lists every price move we've verified, with dates. Check it against your tracker and you'll spot a stale rate in about a minute, before it reaches a monthly report.

How I measured this, and what could be wrong

• Launch dates and reference prices come from our own dataset, which we check against official pages. We publish a competing price table, so weigh that. Our data can be wrong too.
• The sample is 31 public text models launched from April 24 to October 26, 2026. Only nine are from smaller labs, so one slow case moves those medians a lot.
• Dates are calendar days in UTC, and a listing dated before our launch date counts as 0. LiteLLM uses the merged PR date, and I confirmed its largest gaps by reading the file at historical commits.
• genai-prices, models.dev and Portkey use the first commit that added the model to the file. A commit may reach your install later.
• I left out restricted models, cloud-hosted listings and Mistral Medium 3.5, which some tables price through aliases. I only counted first-party keys, so a model priced under another provider's key doesn't count as listed.
• Portkey keys Gemini by context tier, so I counted the lowest tier as the listing.

FAQ