What a million tokens actually costs in rupees

A million tokens does not have a price. It has two, because input and output are billed at different rates, and for most workloads the output rate is the one that decides the bill. On P/9 the gpt-oss 120B global route published Rs 30.08 per million input tokens and Rs 180.47 per million output tokens on 8 September 2026, which is a six-fold difference on the same route.

That asymmetry is why estimates built on a single blended number are wrong in both directions, and why the useful exercise is to price a workload rather than a model. Rates move; the method below does not.

Current rates per million tokens, for every route

Why output costs more than input

Input is processed in one pass and can be handled in parallel. Output is generated one token at a time, and each token requires another full pass through the model, so a long answer occupies the accelerator for a long time while a long prompt does not.

A provider charging one blended rate would be subsidising verbose answers with terse ones. Splitting the rate makes the pricing honest and, more usefully for you, makes the lever visible: shortening answers is worth several times more than shortening prompts.

Tokens are not words, and they are not words in Urdu especially

A token is a fragment produced by the model's tokenizer, and the mapping to visible text is not stable across languages. English prose lands near four characters per token as a rule of thumb. Urdu, romanised Urdu, code and JSON all fragment further, so the same paragraph costs more tokens in one language than another.

Do not budget against a words-to-tokens ratio. Every response the API returns carries its own token counts, and the request log records them per call, which turns the question from an estimate into a measurement after the first day of real traffic.

Price a workload, not a model

Take a support summariser: roughly 1,200 input tokens of ticket history per call, roughly 200 output tokens of summary, five thousand calls a day. At the gpt-oss 120B rates above, that is six million input tokens and one million output tokens a day.

The input side costs about Rs 180 a day. The output side, at one sixth the volume, costs about Rs 180 a day as well. The two halves land in the same place despite a six-to-one difference in tokens, which is the shape of most production workloads and the reason a per-million headline rate tells you almost nothing on its own.

Thirty days of that is roughly Rs 10,800, on a route where the input rate looks almost free. Run the same arithmetic on a larger model and the figure moves by an order of magnitude, which is what makes route selection a budget decision rather than a preference.

Four things that move the bill more than the model does

Teams reach for a cheaper model first. These usually save more, and none of them require changing anything a user sees.

• Conversation history resent on every turn: a ten-turn chat can pay for the same opening context ten times unless something truncates it
• Retrieval that stuffs context: an extra few thousand tokens per call is invisible in code review and very visible in a month of invoices
• Retries: a failed request that is retried three times is billed three times, and a retry storm during an incident is a spend incident too
• Reasoning models spending completion budget before answering: that thinking is billed at the output rate, which is the expensive one

Read the real number instead of estimating it

The gateway reports what a call cost. On a streaming request, send the debug metrics header and the stream carries one extra chunk after the terminating event, holding the time to first token, the throughput and the cost of that request in micro-rupees, which is the same figure the ledger settles. Stock OpenAI clients discard that chunk, so a client that reads it has to be told to look.

The dashboard playground shows the same three figures for any prompt, which means a route can be priced against a genuine workload before a line of integration code is written. That is the fastest path from a guess to a number.

curl https://api.paranine.com/v1/chat/completions \
  -H "Authorization: Bearer $P9_API_KEY" \
  -H "Content-Type: application/json" \
  -H "X-P9-Debug-Metrics: true" \
  -d '{
    "model": "paranine/gpt-oss-120b(Global)",
    "stream": true,
    "messages": [{ "role": "user", "content": "Summarise this ticket in one line." }]
  }'

Put a ceiling on it before you need one

An estimate is a forecast and a limit is a control. A per-key credit limit in rupees turns the worst case from an emptied balance into a rejected request, which is a difference that only matters once and matters a great deal then.

Rate limits, spend caps and expiry, one key at a time

The short version

Multiply your input tokens by the input rate, your output tokens by the output rate, and the two by your call volume. Then check the result against what the gateway actually reports after a day of real traffic, because the difference between those two numbers is the part of the workload nobody had written down.