Thinking models: when to enable reasoning and what it costs

A thinking model produces two kinds of text before you see a reply: a reasoning trace it works through internally, and the final answer. Both are tokens, and both get billed the same way — as output. That single fact explains most of the surprise bills people report the first time they turn enable_thinking on for a busy endpoint.

Which models support it

enable_thinking: true is a genmux extension on top of the standard OpenAI schema, and it only does something on models built for it:

Sending enable_thinking to a model in the second group doesn't error — it's silently ignored, so it's safe to leave in a shared code path that calls different models depending on the task. GLM, Kimi and Qwen's Plus/Coder variants are off the roster while their upstream is fixed; their thinking support will be documented here again once they're back.

Why reasoning tokens count as output

There's no separate "thinking" price tier and no discount for reasoning text versus the visible answer — both come out of the model as generated tokens, and usage.completion_tokens counts all of it. If you enable thinking on a model that would otherwise answer in 80 tokens, and it reasons through 600 tokens before answering, you're billed for roughly 680 completion tokens, not 80.

from openai import OpenAI

client = OpenAI(base_url="https://api.genmux.tech/v1", api_key="nb_live_...")

resp = client.chat.completions.create(
    model="deepseek-v4-pro",
    messages=[{"role": "user", "content": "Is 8191 prime? Show your reasoning."}],
    max_tokens=1200,
    enable_thinking=True,
)

print(resp.choices[0].message.content)
print(resp.usage)
# Usage(prompt_tokens=14, completion_tokens=643, total_tokens=657,
#       cost=0.092, cost_source="vendor")

That 643-token completion is mostly reasoning trace, not the one-sentence answer a non-thinking call would have produced for maybe 20 tokens.

A worked comparison

Same question, same model, thinking off versus on, priced at DeepSeek V4 Pro's $1.782/1M output rate:

A roughly 25x cost difference for one call is easy to absorb; the same ratio applied to 100,000 daily requests turns a $4/day endpoint into a $115/day one. Neither number is wrong — it's a genuine trade of cost for reasoning depth — but it needs to be a deliberate choice, not a default left on from testing.

When it's worth turning on

• Multi-step math, logic, or planning — the class of task thinking models are built for. The accuracy gain is usually worth the cost here.
• One-off or low-volume calls — a support-tooling script that runs a few hundred times a day can afford the multiplier.
• Ambiguous or adversarial inputs — reasoning helps the model catch edge cases a direct answer would miss.

When to leave it off

• High-volume classification, extraction, or short-form chat — tasks a non-thinking model already handles well don't need the extra spend.
• Latency-sensitive UI — reasoning adds real wall-clock time before (or interleaved with) the visible answer starts streaming.
• Anything running per-request in a hot path — flip it on for a sample of traffic first and measure the token delta before rolling it out everywhere.

Streaming and thinking together

Reasoning content streams through the same delta.content field as the final answer — there's no separate SSE event type for it — so a naive UI will render the reasoning trace to the user unless you filter for it. usage, including the full reasoning-plus-answer completion_tokens count, still arrives only in the final chunk before data: [DONE]; see the SSE streaming guide for the parsing details.

Getting started

enable_thinking costs nothing to try — add it to one request, check usage.completion_tokens before and after, and decide from real numbers rather than a guess. Model-by-model rates are on the pricing page, and the full parameter reference is in the docs.