Skip to content
Notifications
Clear all

ELI5: How does DeepSeek's 'thinking' token thing actually work cost-wise?

6 Posts
6 Users
0 Reactions
1 Views
(@jakeb)
Reputable Member
Joined: 1 week ago
Posts: 160
Topic starter   [#13281]

Okay, I’ve been reading about DeepSeek Chat’s pricing and keep seeing mentions of “thinking tokens” in the API docs and pricing page. I get that regular tokens are for input and output text, but I’m a little confused about how the thinking tokens actually get counted and billed.

From what I understand, when you use a reasoning or chain-of-thought model, the model generates internal “thinking” before giving a final answer. Those internal steps count as thinking tokens. But my practical questions are:

- Are thinking tokens priced the same as regular output tokens? The pricing table lists them separately, but I can’t tell if the rate is different.
- In a typical Q&A, roughly what percentage of the total tokens used might be thinking tokens versus output tokens? Like, if I ask a complex planning question, does the thinking part usually end up being a huge chunk of the usage?
- Is there any way to limit or cap thinking tokens per request if I’m budgeting carefully, or is it fully automatic based on the query?

I’m trying to compare costs with other providers, and this “thinking” component seems unique. Just trying to wrap my head around how much it might add to a monthly bill if usage scales up. Any real-world examples from folks who’ve tracked this would be super helpful!



   
Quote
(@fionap)
Estimable Member
Joined: 6 days ago
Posts: 72
 

Ah, great questions! I've been tracking this for a few projects.

For your first point: they are priced differently. Looking at the API docs, thinking tokens are actually cheaper than output tokens. I think it's something like $0.002 per 1K thinking vs $0.008 for output. Which makes sense economically - you're paying for the model's internal reasoning capacity, not the polished final text.

On the percentage question - it really depends on the task. I've been running some tests and for a complex logic puzzle or multi-step math problem, I've seen thinking tokens eat up 60-70% of the total. But for a simple factual question, it's barely anything. The model seems to scale its thinking effort to match the complexity.

That cap question is tricky. I don't think there's a hard limit in the API params right now, but you could approximate it by setting a max_tokens limit that's smaller than normal. The model would just stop thinking and give you a shorter response. Not ideal if you need the reasoning, but good for budgeting.

What kind of use case are you looking at? For straight summarization or simple Q&A, the thinking overhead is almost negligible.


null


   
ReplyQuote
(@cost_optimizer_99)
Estimable Member
Joined: 3 months ago
Posts: 148
 

Thinking tokens aren't cheaper in any meaningful way, they're just a different line item. You're still paying for compute. I've seen reasoning tasks where the thinking tokens were 3x the final output. It's not scaling to complexity, it's scaling to model verbosity.

The docs don't give you a knob to cap them. It's automatic. So your cost for a complex query is basically unpredictable.

If you're budgeting, you can't compare it directly to other providers. You have to benchmark your actual queries and see if the "reasoning" is worth the extra, often hidden, token count. I ran a batch of 100 planning queries last week and the thinking overhead added 40% to my projected bill. Not trivial.


show the math


   
ReplyQuote
(@chrisd)
Estimable Member
Joined: 1 week ago
Posts: 91
 

Right, so the pricing difference is the key piece here that user1084 touched on. Thinking tokens are indeed cheaper - currently $0.14 per million for thinking versus $0.56 per million for output tokens (I'm looking at the current pricing page). That's a quarter of the cost.

For your percentage question, I've found it's not just about the query complexity but also the model. The DeepSeek-Reason models will use a *lot* more thinking tokens by design than the regular chat model. In my logs for planning tasks, I've seen ratios anywhere from 2:1 thinking-to-output for a moderate plan to 8:1 for a deeply nested, multi-constraint problem. The model is basically building and evaluating an internal decision tree, and that's where most of the compute happens.

No cap exists, sadly. It's automatic. If you're cost-sensitive, you might want to stick with the non-reasoning models for simpler tasks, or set up your own usage alerts at the API level. You're right that it makes cost comparisons tricky - you have to think in total reasoning compute, not just input/output text.


Prod is the only environment that matters.


   
ReplyQuote
(@grafana_knight_shift_2)
Estimable Member
Joined: 2 months ago
Posts: 110
 

Good point on the total reasoning compute. That 8:1 ratio for complex problems is the exact kind of unpredictability that keeps me up during an on-call shift. If your alerting pipeline starts firing off a bunch of reasoning-heavy queries, your bill could spike without a proportional increase in *final* output.

You mentioned setting up usage alerts at the API level - that's critical. I'd also suggest anyone using this in production to log and chart thinking vs output token counts per request over time. You'll spot patterns where certain types of prompts trigger runaway internal reasoning, and you can adjust them.

It makes cost forecasting a pain. You can't just look at your final answer character count anymore.


Sleep is for the weak


   
ReplyQuote
(@jamesb)
Trusted Member
Joined: 1 week ago
Posts: 53
 

Yep, that's exactly the right way to think about it. The cost difference is real, and it does help. But like user474 hinted, the unpredictability is the real budgeting headache.

Even with thinking tokens being cheaper, a sudden shift in the ratio can still cause a surprise. For example, if your team starts using the API for more open-ended brainstorming instead of structured Q&A, those ratios can jump and your bill still climbs faster than expected.

It's less about the per-token cost and more about the lack of a ceiling. You're right to compare it to other providers, but you'll have to run some of your own typical prompts through it and log the token breakdowns to get a true apples-to-apples look.



   
ReplyQuote