I built a pricing API for LLMs — then realized the real users might not be human

Anders Rasmussen — Sat, 08 Aug 2026 06:02:20 +0000

Klikk her: LLM Price Watch started as a simple problem: comparing per-token pricing across Claude, GPT, Gemini, DeepSeek, and Grok meant opening five pricing pages and doing the math by hand every time a new model dropped. So I built a calculator. Then I built an API behind it. Then I noticed something about who was actually going to call that API.

The obvious version

The first version of the API was exactly what you'd expect:

GET /v1/models — every tracked model with current pricing
GET /v1/models/:id — a single model
GET /v1/calculate?model=X&input_tokens=N&output_tokens=N — cost for a specific call

Straightforward. A human developer hits /calculate, gets a number, builds their cost estimate into a dashboard somewhere. Done.

The part that changed the design

The actual differentiator turned out to be a fourth endpoint: GET /v1/recommend?use_case=X. Instead of just returning prices, it returns a recommendation — which model fits a given use case (long-document summarization, high-volume classification, coding assistance, customer support) based on both price and the editorial analysis already written for the comparison pages on the site.

Once that endpoint existed, the actual audience for this API stopped being "a developer building a cost dashboard" and started including something else: AI agents doing their own tool selection at runtime. An agent framework deciding which model to route a task to doesn't want to read a blog post — it wants a structured answer to "given this use case, what should I use, and what will it cost me." That's a tool call, not a page view.

That reframing changed a few concrete decisions:

CORS is wide open on purpose. This isn't an API with a dashboard in front of it — it's meant to be called directly from wherever the calling code lives, including client-side agent code.
No API key required (for now). Every bit of friction between "an agent wants this data" and "an agent gets this data" is friction against the actual use case. A paid tier with rate limits is the natural future step once real usage justifies it, but gating from day one would have defeated the point.
/recommend returns reasoning, not just a model name. An agent — or the person who built it — needs to know why, not just what, or the recommendation is a black box nobody trusts enough to actually wire into a decision.

The unglamorous half of this

None of that matters if the numbers are wrong. Pricing data for five providers was verified directly against each provider's own official pricing page, not pulled from a third-party aggregator — aggregators lag, and stale pricing data is worse than no data for something meant to inform actual spend decisions. Updates are still a manual snapshot for now; an auto-refreshing worker is the obvious next step once there's enough usage to justify the engineering time.

The part I didn't expect

The API ended up feeding the other site I run, StackIndex AI — its cost calculator page calls this API live, gets a model recommendation plus a cost estimate, and returns it inline. Two separate sites, same backend, CORS'd across domains, tested end-to-end. I didn't plan the API to be reusable infrastructure when I built it — it just turned out that "structured, agent-callable, reasoning-included" is a useful shape for more than one problem.

If you're building something similar: design the response for a reader who can't ask a follow-up question. That constraint does more for API design than almost anything else.

DEV Community: Anders Rasmussen

I built a pricing API for LLMs — then realized the real users might not be human

The obvious version

The part that changed the design

The unglamorous half of this

The part I didn't expect