{"id":4265,"date":"2026-08-14T04:08:27","date_gmt":"2026-08-14T04:08:27","guid":{"rendered":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/14\/i-gave-deepseek-a-token-limit-it-ignored-me\/"},"modified":"2026-08-14T04:08:27","modified_gmt":"2026-08-14T04:08:27","slug":"i-gave-deepseek-a-token-limit-it-ignored-me","status":"publish","type":"post","link":"https:\/\/tucumandevelopers.com\/index.php\/2026\/08\/14\/i-gave-deepseek-a-token-limit-it-ignored-me\/","title":{"rendered":"I Gave DeepSeek a Token Limit. It Ignored Me."},"content":{"rendered":"
\n
<\/div>\n

Every one of those 3,000-plus output tokens went into reasoning. Not a single character of the visible answer made it out.<\/strong> Billing is based on generated tokens, so I paid in full for all three calls and received three empty strings.<\/p>\n

Worse, the application interpreted the result like this: no parseable action \u2192 fallback marks the move as noncompliant \u2192 the dashboard displays \u201cthis model disobeyed instructions in 94.4% of hands.\u201d<\/strong> That figure came from my project’s August 13 batch, not this isolated test. I nearly recorded a real token-budget failure as a model-behavior failure.<\/strong><\/p>\n

<\/a> So How Much Budget Does It Need? <\/h2>\n

I ran the same task three times under four configurations:<\/p>\n

\n\n\n\n\n\n\n\n\n
Configuration<\/th>\nUsable<\/th>\nCompletion tokens<\/th>\nReasoning<\/th>\nVisible answer<\/th>\nLatency<\/th>\n<\/tr>\n<\/thead>\n
Reasoning on \u00b7 max_tokens<\/code>=3072<\/td>\n0\/3<\/strong><\/td>\n3071\u20133072<\/td>\n100%<\/td>\n0 chars<\/strong><\/td>\n42\u201350s<\/td>\n<\/tr>\n
Reasoning on \u00b7 8192<\/td>\n1\/3<\/strong><\/td>\n7837\u20138192<\/td>\n~95%<\/td>\n0 \/ 118 chars<\/td>\n121\u2013126s<\/td>\n<\/tr>\n
Reasoning on \u00b7 32768<\/td>\n3\/3<\/td>\n3220\u20135785<\/td>\n~97%<\/td>\n117\u2013140 chars<\/td>\n49\u201382s<\/td>\n<\/tr>\n
Reasoning off<\/strong> \u00b7 3072<\/td>\n3\/3<\/strong><\/td>\n84\u2013107<\/strong><\/td>\n\u2014<\/td>\n123\u2013156 chars<\/td>\n2\u20134s<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

Three things were true at the same time.<\/p>\n

1. The tighter the budget, the more likely the model was to consume all of it.<\/strong> A 3,072-token budget ended at 3,072. An 8,192-token budget usually ended near 8,192. Only when I raised the limit to 32,768\u2014far beyond the 3,200\u20135,800 tokens it normally needed\u2014did it stop naturally and reliably.<\/p>\n

2. Reasoning usage was hard to budget.<\/strong> On the same task, reasoning ranged from 3,137 to 5,691 tokens<\/strong>. With the intended limit ignored, it climbed to 15,774<\/strong>. This is not merely \u201cthinking more.\u201d It makes per-call budgeting unreliable: when usage can nearly double\u2014or go much higher\u2014which number are you supposed to provision for?<\/p>\n

3. The longer reasoning did not produce a longer answer.<\/strong> With reasoning off, the visible answers were 123\u2013156 Chinese characters. With reasoning on, they were 117\u2013140. Forty-seven times the tokens and twenty-two times the latency did not produce a longer or more complete answer.<\/strong><\/p>\n

For my application, there was an even more fundamental problem: a round has a 30\u201360 second pacing budget<\/strong>, while one reasoning-enabled decision took 49\u2013222 seconds. At that point, this was no longer just an issue of price. The product experience stopped working.<\/p>\n

<\/a> Is the Protocol at Fault, or Is DeepSeek? <\/h2>\n

Before publishing, I tested the parameter behavior separately. The answer is: both contributed, but not equally.<\/strong><\/p>\n

On the protocol side, the OpenAI-compatible max_tokens<\/code> field places reasoning and visible output in the same budget. If reasoning consumes the allowance, the answer has nothing left. OpenAI’s own reasoning models have had the same trap, which is why max_completion_tokens<\/code> was introduced and why the documentation warns that a budget that is too small can produce an empty response. That part is a protocol-design problem.<\/strong><\/p>\n

Then I tested the relevant parameters against DeepSeek’s endpoint:<\/p>\n

\n\n\n\n\n\n\n\n\n\n\n\n\n
Parameter sent<\/th>\nIntended behavior<\/th>\nActual behavior<\/strong><\/th>\n<\/tr>\n<\/thead>\n
Nothing<\/td>\n\u2014<\/td>\n Reasoning on by default<\/strong>; budget exhausted<\/td>\n<\/tr>\n
max_completion_tokens: 3072<\/code><\/td>\nOpenAI-style completion limit<\/td>\n Silently ignored:<\/strong> 15,809 tokens, 222 seconds<\/td>\n<\/tr>\n
reasoning: {max_tokens: 1024}<\/code><\/td>\nOpenRouter-style reasoning limit<\/td>\nSilently ignored<\/strong><\/td>\n<\/tr>\n
reasoning_effort: \"none\"<\/code><\/td>\nDisable reasoning<\/td>\n\u2705 Worked (18 tokens, 1 second)<\/td>\n<\/tr>\n
thinking: {type: \"disabled\"}<\/code><\/td>\nDisable reasoning<\/td>\n\u2705 Worked (18 tokens, 1 second)<\/td>\n<\/tr>\n
enable_thinking: false<\/code><\/td>\nDisable reasoning<\/td>\nSilently ignored<\/strong><\/td>\n<\/tr>\n
chat_template_kwargs: {...}<\/code><\/td>\nDisable reasoning<\/td>\nSilently ignored<\/strong><\/td>\n<\/tr>\n
totally_bogus_param: true<\/code> (invented)<\/td>\nReject the request<\/td>\nHTTP 200; silently swallowed<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

The final row is the root of the problem. The API silently accepts unknown parameters.<\/strong> Every ignored setting therefore looks exactly like a successful setting. You send a limit, receive a 200, and assume the call is capped\u2014until the bill tells you otherwise.<\/strong><\/p>\n

max_completion_tokens<\/code> is the clearest example. It exists specifically for reasoning models and for exactly the budgeting failure described here. DeepSeek accepted it, returned HTTP 200, and then let the model generate 15,809 tokens. Unsupported parameters can be rejected. Silently ignoring them is the worst possible behavior.<\/strong><\/p>\n

My conclusion: the protocol dug the hole; DeepSeek made it deeper and removed the ladder.<\/strong><\/p>\n

<\/a> But Is the Production Release at Least Better? <\/h2>\n

This is where I most wanted the data to give DeepSeek some credit. It did not.<\/p>\n

First, price needs careful wording. The older deepseek-v4-pro<\/code> build on OpenRouter was listed at $1.17\/$2.34 per million input\/output tokens. The production -0813<\/code> release was listed at $0.43\/$0.87, while DeepSeek’s official endpoint charged \u00a53\/\u00a56\u2014roughly $0.42\/$0.85. On paper, the production release was about two-thirds cheaper.<\/strong> But OpenRouter had already priced the older deployment relatively high, and I cannot separate channel markup from an actual model price cut. So I cannot honestly claim that \u201cthe production release became more expensive.\u201d<\/p>\n

What did increase was the cost per usable answer<\/strong>. With reasoning off, one hand cost \u00a50.0105. With reasoning on and an 8,192-token budget, only one of three calls produced a usable answer. Including the two wasted calls, the cost became \u00a50.175 per usable answer\u201416.7 times higher<\/strong>. At 3,072 tokens, the effective cost was infinite: none of the calls could be used, but all were billed. Whatever happens to list price, this multiplier consumes the savings.<\/p>\n

For quality, I chose a hard metric with almost no strategic ambiguity: when the current bid is already guaranteed to be true using only the model’s own dice, the model still chooses to challenge. That challenge is guaranteed to lose.<\/strong><\/p>\n

\n\n\n\n\n\n\n
Version<\/th>\nRelevant hands<\/th>\nBad challenges<\/th>\nRate<\/th>\n<\/tr>\n<\/thead>\n
Older build (OpenRouter, quantized)<\/td>\n71<\/td>\n1<\/td>\n1%<\/strong><\/td>\n<\/tr>\n
Production 0813 (official endpoint)<\/td>\n22<\/td>\n2<\/td>\n9%<\/strong><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<\/div>\n

z=1.22; the difference was not statistically significant.<\/strong> The rigorous conclusion is not that the production release was worse. It is that I could not detect any improvement on this metric; if there was a directional signal, it pointed the other way.<\/strong><\/p>\n

This result needs an important caveat: the two versions were never tested head-to-head in the same batch<\/strong>. The comparison includes different opponents, random seeds, and prompt revisions. The production release also had only 22 relevant situations. The data can challenge a claim of obvious improvement, but it cannot prove regression.<\/strong><\/p>\n

<\/a> Conclusion <\/h2>\n

I am not saying DeepSeek is bad. With reasoning disabled, V4-Pro returned a clean decision in two seconds for roughly one cent per hand, and it performed well at my table. My hosted seat still runs on DeepSeek.<\/strong><\/p>\n

The real problem is the combination of three product decisions:<\/p>\n

    \n
  1. Reasoning is enabled by default.<\/strong> For a per-call application, that can be a pure cost rather than a benefit.<\/li>\n
  2. There is no working reasoning-budget limit.<\/strong> Both the OpenAI-style and OpenRouter-style settings were ignored.<\/li>\n
  3. Unknown parameters are silently swallowed.<\/strong> This makes the first two problems hard to diagnose.<\/li>\n<\/ol>\n

    The third decision is the one that most needs to change. An API that returns an error can be debugged in ten minutes. An API that silently returns 200 forces users to work backward from a bill and a misleading \u201c94.4% noncompliant\u201d dashboard to discover what actually happened.<\/strong><\/p>\n

    If you call this model programmatically, explicitly send reasoning_effort: \"none\"<\/code><\/strong> or thinking: {type: \"disabled\"}<\/code><\/strong> when you do not need reasoning. Do not rely on enable_thinking: false<\/code>: in my test it had no effect, and the API did not say so.<\/p>\n<\/p><\/div>\n<\/div>\n<\/div>\n<\/div>\n

    Fuente: Art\u00edculo original<\/a><\/p>\n","protected":false},"excerpt":{"rendered":"

    Every one of those 3,000-plus output tokens went into reasoning. Not a single character of the visible answer made it out. Billing is based on generated tokens, so I paid in full for all three calls and received three empty strings. Worse, the application interpreted the result like this: no parseable action \u2192 fallback marks […]<\/p>\n","protected":false},"author":1,"featured_media":4264,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":"","jetpack_publicize_message":"","jetpack_publicize_feature_enabled":true,"jetpack_social_post_already_shared":true,"jetpack_social_options":{"image_generator_settings":{"template":"highway","default_image_id":0,"font":"","enabled":false},"version":2},"webixso_pending_account_ids":""},"categories":[41],"tags":[],"class_list":["post-4265","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-devto"],"jetpack_publicize_connections":[],"_links":{"self":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/4265","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/comments?post=4265"}],"version-history":[{"count":0,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/posts\/4265\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media\/4264"}],"wp:attachment":[{"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/media?parent=4265"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/categories?post=4265"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/tucumandevelopers.com\/index.php\/wp-json\/wp\/v2\/tags?post=4265"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}