Token Cost Calculator: Price Any LLM Request in Seconds

A token cost calculator answers one question: how much did this request actually cost? The answer is not the per-token price in the docs — it is that price multiplied by the tokens your request used, split across the three lanes that bill at different rates: input, cached input, and output.

This guide gives you the current per-million-token rate table, a Python calculator you can reuse with real usage objects, and the one accounting rule that prevents the most common over-counting mistake. It is the practical companion to the LLM API pricing guide, which covers how to turn that into a monthly number.

Verification status: All prices in the rate table below are dated 2026-10-29 and were read from the live OurToken model pages. Prices change; re-check the model page before budgeting against this table.

The Current Rate Table

Prices are per million tokens, shown as the OurToken rate with the official reference in parentheses. Cache writes are listed only where the route has a separate write price; $0 means no charge.

The full list lives on the OurToken models page. The table above is the subset most people ask about; the calculator below works against any of them. Discounts vary by route — most list 40-60% off the official reference, while a few (such as GPT-5.6 Sol) list a different markdown, so always confirm the live page before budgeting.

The One Rule: Cached Tokens Are a Subset

The single most common mistake in token cost math is double-counting cached input.

A Chat Completions response reports prompt_tokens and, on routes that support caching, a prompt_tokens_details.cached_tokens value. Those cached tokens are part of prompt_tokens, not extra tokens on top. If your request used 60,000 prompt tokens and 45,000 were cached, you did not use 105,000 input tokens. You used 60,000, of which 45,000 bill at the cached-input rate.

The correct split is:

uncached_input = prompt_tokens - cached_tokens
cost = uncached_input * input_rate
     + cached_tokens * cache_read_rate
     + completion_tokens * output_rate

Get this wrong and every cached workload looks roughly 10x more expensive than it is, which pushes you toward the wrong model. The prompt caching guide covers the accounting and the stable-prefix discipline in depth.

A Python Token Cost Calculator

This calculator takes a real usage object and returns the cost. It prices from a rate registry so a provider price change is a one-line edit, not a code change.

from typing import Any


def to_dict(value: Any) -> dict:
    if value is None:
        return {}
    if isinstance(value, dict):
        return value
    if hasattr(value, "model_dump"):
        return value.model_dump()
    return dict(value)


RATES = {
    "gpt-6-astra": {"in": 2.00, "out": 10.00, "cache": 0.20},
    "claude-opus-4-8": {"in": 2.00, "out": 10.00, "cache": 0.20},
    "deepseek-flash": {"in": 0.18, "out": 0.72, "cache": 0.0036},
    "glm-5.3-flash": {"in": 0.09, "out": 0.30, "cache": 0.018},
    "qwen3.8-flash": {"in": 0.09, "out": 0.282, "cache": 0.0096},
}


def calc_cost(model: str, usage: Any) -> float:
    data = to_dict(usage)
    rate = RATES.get(model)
    if not rate:
        raise ValueError(f"no rate for model {model}")

    prompt = data.get("prompt_tokens", 0) or 0
    completion = data.get("completion_tokens", 0) or 0

    details = to_dict(
        data.get("prompt_tokens_details") or data.get("input_tokens_details")
    )
    cached = details.get("cached_tokens", 0) or 0
    uncached = max(prompt - cached, 0)

    cost = (
        uncached / 1_000_000 * rate["in"]
        + cached / 1_000_000 * rate["cache"]
        + completion / 1_000_000 * rate["out"]
    )
    return round(cost, 6)


# Example usage object (illustrative).
usage = {
    "prompt_tokens": 60_000,
    "prompt_tokens_details": {"cached_tokens": 45_000},
    "completion_tokens": 5_000,
}

print(calc_cost("deepseek-flash", usage))
# 15_000 uncached * $0.18 + 45_000 cached * $0.0036 + 5_000 * $0.72
# = 0.0027 + 0.000162 + 0.0036 = ~$0.0065

The max(prompt - cached, 0) clamp matters: if a provider returns inconsistent telemetry, you price zero uncached tokens rather than negative ones. Log the raw usage object alongside the computed cost so you can investigate anomalies later.

Reading the Three Lanes on a Real Response

The calculator only matters if you know where each number comes from.

• prompt_tokens is the full input. Everything you sent, cached or not.
• completion_tokens is the output, including any thinking the model did.
• prompt_tokens_details.cached_tokens is the cached subset of the input, when the route reports it.

The field names vary slightly between compatibility layers — some return input_tokens and output_tokens instead of prompt_tokens and completion_tokens, and cached tokens may sit under input_tokens_details. The to_dict and the fallback lookups in the calculator absorb that variation, which is why the normalization step comes first.

If a route never returns cached-token details, the calculator still works — cached is simply zero and everything bills at the full input rate. You are not missing cost in that case; you are just not receiving the cache discount that the prompt caching guide would otherwise let you exploit.

From One Request to a Bill

A per-request cost becomes useful when you multiply it out. The DeepSeek V4 API pricing guide has a fuller cost-calculator pattern, and the LLM API pricing guide shows how to convert a request mix into a monthly number. The short version:

monthly_cost = average_request_cost * requests_per_month

But the average hides everything. Two requests can average $0.01 while one is $0.0004 (a short cheap-model answer) and the other is $0.06 (a long frontier-model reasoning call). The calculator is most useful when you run it per request and aggregate by model and stage — the AI cost tracking guide covers that tagging discipline.

Conclusion

A token cost calculator is three rates and one rule. Read the input, cached-input, and output rates from the live model page; split cached tokens out of the prompt total before pricing; multiply. Do that per request and aggregate by model, and your LLM bill stops being a surprise number and becomes something you can predict.

Keep the rate table above as a starting point, but treat the OurToken models page as the live source of truth — the point of a single registry is that you update one place when a price changes.

FAQ

How do I calculate the cost of an LLM request?

Multiply uncached input, cached input, and output tokens by their per-million-token rates and sum them. Cached tokens are a subset of input and bill at a lower rate.

What is the most common token cost mistake?

Double-counting cached tokens. Cached tokens are part of prompt_tokens, not additional input, so bill them at the cached rate instead of the full input rate.

Where do the token counts come from?

From the response's usage object: prompt_tokens, completion_tokens, and prompt_tokens_details.cached_tokens when the route reports caching.

What is the cheapest model on OurToken?

At the rates above, GPT-5.6 Luna ($0.04 input / $0.24 output) and the Flash-class routes (DeepSeek Flash, GLM 5.3 Flash, Qwen3.8 Flash at $0.09 input) are the cheapest, with GLM 5.3 Flash also carrying multimodal support.

Do I need to price cache writes?

Only where the route has a separate cache-write line. Several routes list cache writes at $0; the ones that charge list it separately from input.