I Built llm-cost.io on Free Tiers: 400+ LLM API Prices, Updated Daily

Tags: ai, webdev, nextjs, cloudflare, opensource

When I started building AI products, I kept hitting the same question: which model should I use for this feature, and what will it actually cost me at scale? Not in theory, but in real dollars per month once token usage ramps.

Pricing pages were fragmented. Some were stale. Some used different units. Some buried output pricing in footnotes. I found myself copying numbers into spreadsheets before I could even make a product decision.

So I built llm-cost.io: a free, no-login site that compares 400+ LLM API prices side by side using a single unit: USD per 1M input tokens and USD per 1M output tokens.

This post is a practical breakdown of what I built, why I built it this way, and what I learned shipping a data-heavy developer site entirely on free tiers.

Why price transparency matters for AI developers

If you are building with LLM APIs, pricing is not a secondary concern. It is product architecture.

A model choice affects:

• your gross margins
• whether a feature can be enabled by default
• whether you can offer a free plan
• how aggressive your context windows can be
• whether retries and guardrails are affordable

A 2x or 5x pricing difference can turn a viable feature into a cost sink overnight. And since most applications use multiple model types (chat, embeddings, reranking, moderation, vision), understanding blended cost becomes even harder.

I wanted a tool where I could answer quickly:

• “What are the cheapest decent options for this use case?”
• “How much more do I pay for higher output quality?”
• “If traffic doubles, what changes first?”

That is the core value of llm-cost.io: less guessing, fewer tabs, faster tradeoff decisions.

What llm-cost.io includes

I focused on features that help developers decide and ship, not just browse numbers.

1) Comparison tables

The main table normalizes pricing across providers and model families. Every row shows input and output pricing in the same unit so comparisons are immediate.

I added sorting and filtering for common workflows:

• cheapest input
• cheapest output
• provider-specific scans
• model name search

This sounds basic, but normalization is most of the work. Many pricing pages are human-readable, not machine-friendly. A clean table is only possible if ingestion and normalization are strict.

2) Cost calculator

Developers usually think in workload, not raw token rates. So the calculator lets you estimate monthly spend from token volume assumptions.

You can plug in your expected input/output token totals and compare estimated spend across selected models. It turns abstract price sheets into planning numbers for engineering and product decisions.

3) Bill shredder

The bill shredder is my favorite utility: paste your projected usage pattern, and it breaks down where the money goes.

In practice, this helps answer:

• Are outputs dominating spend?
• Is prompt bloat the real problem?
• Does switching one model tier change the budget meaningfully?

It is a fast way to stress-test architecture decisions before committing engineering time.

4) Free-tier tracker

A lot of early-stage teams and solo devs start on free credits. I added a free-tier tracker so people can quickly see where they can prototype without immediate spend.

For many projects, this is the difference between “idea this week” and “idea next quarter.”

Tech stack and why I chose it

I deliberately optimized for reliability, low maintenance, and zero hosting cost.

Next.js with static export

I used Next.js and shipped as a static export.

Why:

• straightforward developer experience
• easy component reuse for tables/calculators
• fast static delivery
• no server runtime required

For a site that is mostly read-heavy and data-display focused, static export keeps things simple and robust.

Cloudflare Pages for hosting

I host on Cloudflare Pages.

Why:

• global CDN out of the box
• simple CI/CD integration
• generous free tier
• good performance without tuning

This gives me low-latency delivery worldwide with basically no infrastructure babysitting.

OpenRouter API as data source

For model and pricing data, I pull from the OpenRouter API.

Why:

• broad model coverage across providers
• structured data that is script-friendly
• enough breadth to keep comparisons useful

The target is not “perfect forever truth”; the target is “consistently refreshed, normalized, and transparent.”

GitHub Actions for daily refresh

Data refresh runs on GitHub Actions once per day.

Why:

• cron scheduling in repo
• versioned data pipeline
• visible logs and failures
• free automation for this scale

The workflow fetches data, normalizes it, regenerates artifacts, and deploys through the existing Pages flow.

Lessons learned shipping a data-driven site on free tiers

Building on free tiers is absolutely viable, but there are constraints you need to design for early.

1) Normalize aggressively, display conservatively

Raw pricing metadata can be inconsistent. Units, naming, and missing fields happen.

I learned to build strict normalization rules and to avoid pretending data is precise when it is incomplete. If a field is missing, show that clearly instead of inferring silently.

2) Treat freshness as a feature

For pricing data, stale equals wrong. The daily pipeline is not ops overhead; it is product functionality.

I added checks and logs so failed refreshes are obvious. A transparent “last updated” timestamp builds trust with developers.

3) Keep runtime complexity near zero

Static export + CDN delivery removed an entire class of operational failure. No app servers. No scaling incidents. No idle cost anxiety.

For this product shape, dynamic backend logic was unnecessary.

4) Build tools users can reason about

The best feedback I got was not “nice UI.” It was “I can justify a model decision faster now.”

The table, calculator, and bill shredder work because they map to real workflow questions. Utility beats novelty.

5) Free-tier architecture forces better product decisions

Free limits pushed me toward:

• simpler deployment
• deterministic data jobs
• fewer moving parts
• measurable value per page

In hindsight, those constraints improved the product.

What I would do next

If I keep expanding llm-cost.io, I want to add:

• historical pricing deltas over time
• alerts for significant price changes
• scenario presets for common app patterns (chatbot, RAG, agent loops)
• exportable comparison snapshots for team discussions

The goal remains the same: help developers make cost-aware model decisions quickly.

Closing

I built llm-cost.io because I needed it myself while shipping AI products. Price transparency should not require ten tabs, manual spreadsheets, and guesswork.

If you are building in public or running lean, you do not need a complex paid stack to ship useful infrastructure for other developers. A static Next.js app, Cloudflare Pages, GitHub Actions, and a clean data pipeline can go surprisingly far.

That combination let me launch and maintain a practical, always-free tool that answers one question well: what will this model choice cost me?