LLM Model Cost Comparison: Pricing Across Providers

Comparing LLM model costs isn't as simple as looking at a price-per-token number on a pricing page. Two models with identical headline prices can produce wildly different bills depending on how verbose their outputs are, whether they support prompt caching, how they handle tool calls, and how many retries your application triggers. This article gives you a repeatable way to compare models on cost, not just a snapshot of prices that will be outdated in a month.

The short answer: to compare LLM models fairly, calculate cost per request using (input tokens ÷ 1,000,000 × input price) + (output tokens ÷ 1,000,000 × output price), then multiply by your expected monthly request volume. Do this for your actual workload — not a generic benchmark — because the model that's cheapest per token is often not the cheapest per task once you account for output length and retry rates.

Why Sticker Price Isn't the Whole Story

Every major provider publishes a price per million input tokens and a separate, usually higher, price per million output tokens. That asymmetry matters more than most people expect. A model that writes long, chatty responses can cost more in practice than a model with a higher per-token price but tighter, more concise output. Before comparing vendors, always check:

• Input vs. output pricing split — output tokens are typically 3–5x the price of input tokens across providers.
• Context window size — larger context windows let you pass more history or documents, but every token in that window is billed on each request unless caching is used.
• Prompt caching support — some providers discount repeated context (system prompts, few-shot examples, long documents) heavily on subsequent calls.
• Tool/function call overhead — tool definitions and tool outputs count as tokens too, and multi-step agent loops can multiply token usage per user request.
• Batch or async discounts — some providers offer reduced rates for non-real-time, batched requests.

None of these show up in a simple "price per token" comparison, which is why teams that only look at the headline number are frequently surprised by their invoice.

A Practical Cost Formula

For any model you're evaluating, run this calculation against a representative sample of your own prompts:

cost_per_request = (input_tokens / 1_000_000 * input_price)
                  + (output_tokens / 1_000_000 * output_price)

monthly_cost = cost_per_request * requests_per_month

Do this with real prompts from your product, not synthetic benchmarks. A summarization tool and a customer support chatbot have completely different token profiles — the summarizer sends a lot of input and returns a little output, while a chatbot may send a moderate amount of input but generate long conversational responses. The "cheapest" model on paper can flip depending on which of those shapes your traffic matches.

A simple way to instrument this without building your own token counter is to read the usage metadata that most model APIs return alongside each response. If you're already calling Claude through an API layer, that metadata is available on every request:

curl https://api.subtoapi.app/v1/messages \
  -H "Authorization: Bearer $SUBTOAPI_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "claude-sonnet-4",
    "max_tokens": 512,
    "messages": [
      {"role": "user", "content": "Summarize this support ticket in two sentences."}
    ]
  }'

The response includes usage.input_tokens and usage.output_tokens, which you can multiply by current pricing to compute real cost per call. Logging this for every request over a week of production traffic gives you a far more accurate cost comparison than any published benchmark, because it reflects your actual prompts, your actual users, and your actual retry behavior.

Comparing Models Beyond Raw Token Price

Once you have real usage numbers, a few other factors change the comparison:

Retry and error rates. A model that occasionally returns malformed output or times out forces retries, and every retry is a fully billed request. A slightly more expensive model with a lower error rate can end up cheaper overall.

Latency and timeout costs. If your infrastructure has aggressive timeouts, a slower model can trigger cancelled requests that still consumed tokens (and sometimes still get billed), plus the downstream cost of a second attempt.

Streaming vs. non-streaming. Streaming doesn't change token pricing, but it does change perceived latency and can reduce abandoned requests in user-facing products, which indirectly affects cost per completed task.

Team and seat structure. If you're comparing not just model providers but how you access them, subscription-based access (a fixed monthly plan per person) behaves very differently on a spreadsheet than metered API billing. A team of five engineers each with their own Claude subscription is a fixed cost regardless of usage; the same team calling a metered API pays per token, which can be cheaper at low volume and more expensive at high volume.

This last point is where a lot of teams get their cost comparison wrong — they compare a subscription price against an API price without normalizing for usage. If your team already has Claude subscriptions, SubToAPI turns that access into a standard HTTPS API with sub_live_ application keys, so you can route production traffic through the same access your team is paying for, see per-key usage in one dashboard, and compare actual token consumption against what a fully metered API would have cost. Plans start at €9/month for a solo developer, €19/seat for teams, and €49/seat for larger scale usage — see current details on /pricing.

A Simple Comparison Checklist

Before picking a model based on cost, run through this:

1. Pull 50–100 representative prompts from your actual product.
2. Send them to each candidate model and record input_tokens and output_tokens from the response.
3. Apply each provider's current input/output pricing to get cost per request.
4. Multiply by expected monthly volume, including a realistic retry rate.
5. Add any fixed costs (seats, subscriptions, infrastructure) on top of the metered total.
6. Compare the final monthly number, not the per-token number.

If you want to test this against Claude without setting up billing infrastructure from scratch, the /docs/quickstart guide walks through getting an API key and making your first request in a few minutes, and /docs/messages documents the response fields — including usage metadata — you'll need for step 2 and 3 above.

FAQ

Is a lower price-per-token always cheaper overall? No. Output token pricing is usually much higher than input pricing, and models that produce longer responses can cost more per task even at a lower headline rate. Always calculate cost per request using real token counts.

How do I compare subscription-based access against metered API pricing? Convert both to a monthly total for your expected volume. Estimate metered API cost using average tokens per request times your monthly request count, then compare that figure against the fixed subscription or per-seat cost.

What's the easiest way to track real cost data instead of estimating? Log the usage field returned with every API response over a representative period of production traffic, then apply current pricing to those actual numbers rather than relying on published benchmarks.