DeepSeek through a relay: how standard and reasoning variants bill differently

The essential difference between the two kinds

Within the same DeepSeek family, the standard variant — chat or instruction tuned — and the reasoning variant are not related by "a bit more expensive". The billing structure is different.

Standard

One request costs input plus output tokens.

Output length is essentially governed by your max_tokens and the complexity of the task, so it is usually controllable.

Reasoning

One request costs input plus thinking tokens plus output.

The key point: thinking tokens are usually billed at the output price, and they routinely account for 70% to 95% of total output.

In other words: you see a 200-word answer, and the billable output may be 5,000 tokens.

Why thinking tokens run away

Thinking length is not linearly related to difficulty. Several situations stretch it dramatically:

1. Maths and logic problems, where the model rechecks its working repeatedly.
2. Agent tasks needing multi-step planning, where every step is re-planned.
3. Ambiguous questions, where it tries several interpretations.
4. Being asked to "think carefully", since the prompt itself induces longer thinking.

Conversely, a simple factual question can also produce very long thinking, because thinking length is not fully controllable and depends on the model's own reasoning strategy.

Four cost controls that actually work

One: tiered routing, the biggest win

Not every task needs a reasoning model.

The gain from tiering is especially visible in agent workloads: planning needs reasoning, execution does not. Handing execution steps to a reasoning model means paying a thinking fee over and over for every step.

Two: cap max_tokens

Set max_tokens explicitly rather than leaving the default, which is often the maximum.

Note: whether max_tokens includes thinking tokens depends on the implementation. Some count them inside, some separately. You have to confirm this by experiment, or your cost model will be wrong.

How to test: set a small max_tokens, 200 for instance, and see whether the combined thinking plus output length is capped at that value.

Three: read usage, not text length

Reconcile against the usage field, not against "the answer looked short".

A reasoning model's usage usually looks like this:

"usage": {
  "prompt_tokens": 85,
  "completion_tokens": 4820,
  "completion_tokens_details": {"reasoning_tokens": 4450}
}

When a reasoning_tokens field is present, use it directly for your accounting.

If a relay site's usage has no reasoning-related field at all, that is worth confirming separately. It may bill on total output, or it may hide the thinking portion while charging for it anyway.

Four: cache the thinking, where supported

Some implementations support reusing the previous turn's thinking in a multi-turn conversation, avoiding repeated reasoning. If the relay passes that capability through, the effect on multi-turn reasoning workloads is significant.

How to check: watch whether reasoning_tokens in usage falls as turns progress.

A common misjudgement

"Reasoning costs more than standard, so use standard whenever possible" is wrong.

The correct basis is total cost, unit price times the number of calls needed, not unit price:

• A complex task may take three attempts to get right on a standard model, so three calls, while a reasoning model gets it in one.
• Three standard calls can already cost more than one reasoning call.

So for accuracy-critical tasks, measure the first-attempt success rate before comparing prices. Cost per successful task is the comparable quantity.

Extra requirements this places on relay sites

Reasoning models impose three additional requirements:

1. Complete usage fields, including a reasoning token count, or you cannot reconcile.
2. The ability to separate thinking from output in streaming, because some clients display the thinking as well and the server has to distinguish the fields.
3. More generous timeouts, since reasoning takes significantly longer and hits gateway timeouts easily.

Item 3 is the most common cause of "it does not work": the request did not fail, it just exceeded the gateway's wait limit and was cut. A site timing out on reasoning models is not necessarily unsupported; its timeout configuration may simply never have been adjusted for this class of model.

Scenario guidance

Suited to reasoning models:

• Maths, algorithms, logical inference.
• Complex debugging where you need the root cause rather than a surface fix.
• Decision problems with several constraints.
• The planning phase of an agent.

Not suited:

• Simple extraction and classification.
• Translation and rewriting.
• High-concurrency, low-latency settings, since thinking is inherently slow.
• Batch data processing, where cost runs away.

A practical starting strategy: build the whole pipeline on a standard model first and record which requests produced unsatisfactory results. Then route only those to a reasoning model. That keeps reasoning usage where it is genuinely needed, with a limited cost increase and a clear quality gain.