[numlocked]

(I work at OpenRouter)

We have solved this problem by working with the providers to implement a prices and models API that we scrape, which is how we keep our marketplace up to date. It's been a journey; a year ago it was all happening through conversations in shared Slack channels!

The pricing landscape has become more complex as providers have introduced e.g. different prices for tokens depending on prompt length, caching, etc.

I do believe the right lens on this is actually the price per token by endpoint, not by model; there are fast/slow versions, thinking/non-thinking, etc. that can sometimes also vary by price.

The point of this comment is not to self promote, but we have put a huge amount of work into figuring all of this out, and have it all publicly available on OpenRouter (admittedly not in such a compact, pricing-focused format though!)

[tekacs]

I tried making it compact and easy just now! Thanks so much for the effort!

https://github.com/tekacs/llm-pricing

[sureglymop]

Hey! I am currently very close to having blown through the yearly token budget of my Kagi subscription, which I used mainly for Kagi Assistant.

Does OpenRouter offer a similar way to select any model in a user friendly way? Meaning, can I add some budget, hook it up to a desktop application and then just have a convenient selection of models that I can start using?

And also, which model would you use to not break the bank? Currently I am mostly using Gemini 2.5 Pro but perhaps there is already a cheaper and better option.

[osigurdson]

By endpoint, do you mean price by token by API shape? Perhaps my phrasing is even more confusing but that is how I see it. I.e. there are API "shapes" for which as long as the shape of the API is the same, my application can use it interchangeably with others. Other dimensions are quality, speed, acceptable error rates, etc., which naturally influence pricing.