DeepSeek Thinking Mode: Choose Reasoning Effort with Evidence

The right DeepSeek thinking mode is the least expensive configuration that reliably clears your task’s quality and safety requirements within its time budget. That choice may be non-thinking for a narrow extraction job, a lower thinking effort for constrained planning, or a higher effort for a difficult analysis. The answer has to come from matched tasks and validated outputs. A longer response, a more confident tone, or a larger reasoning-token count cannot establish that a configuration is better.

This guide explains how to make that choice using the current public DeepSeek API, with documentation checked on October 2, 2026. It separates the provider’s supported controls from an original evaluation method you can adapt. The API request examples are illustrative and were not executed. The small evaluation helper and the reference solution for the planning exercise were tested offline; no paid API experiment, model benchmark, or measured speed advantage is claimed.

The focus is mode selection after an integration already works. For authentication and basic request handling, use our DeepSeek API integration guide. Here you will define acceptance criteria, compare configurations fairly, measure time to a usable answer, and decide when escalation is justified.

1. Understand the current controls

Model selection, thinking mode, reasoning effort, and output length are different decisions. A model identifier chooses the service’s model family or current version. The thinking switch enables or disables the mode. Effort chooses a supported level within thinking. The output-token limit caps generation. Record all four explicitly in an experiment manifest; otherwise a result labeled simply “DeepSeek high” will be difficult to reproduce or interpret later.

At the time of checking, the official model table lists deepseek-flash as DeepSeek-V4.1-Flash and deepseek-v4-pro as DeepSeek-V4-Pro-0813. Both support non-thinking and thinking, with thinking enabled by default and high as the default effort. The canonical thinking effort names are low, high, and max. These are service controls, not calibrated guarantees of answer quality, elapsed seconds, or a particular number of reasoning tokens.

For Chat Completions, the current reference supports reasoning_effort="none" to disable thinking and low, high, or max to enable it. The thinking guide also documents an explicit thinking object, passed through extra_body with the OpenAI Python SDK. Use a clear, consistent form in each adapter. Avoid contradictory combinations of a disabled switch and a positive effort, because this guide does not establish their precedence.

Compatibility names are easy to misread. The official guide maps minimal to low, medium and xhigh to high, and ultra to max. Those names do not give you seven distinct experimental treatments. Prefer the three canonical levels in saved configuration, and keep the original request and normalized label distinguishable when migrating an existing application.

In the Responses API, the corresponding control is nested: reasoning={"effort": "none"}, or the same object with low, high, or max. Do not copy the Chat Completions field name into that interface and assume compatibility. Treat each endpoint as a separate adapter with its own request validation and completion handling, even if both adapters implement the same application-level policy.

Current Chat Completions documentation gives a maximum max_tokens of 393,216, with defaults of 8K for non-thinking, 64K for thinking, and 128K for max effort. A large available ceiling is not a sensible default budget for every task. Choose a task-appropriate explicit cap, leave room for the answer, and classify a length-limited response as an outcome that needs investigation. Effort is not an exact-token budget.

The thinking guide says temperature and the two penalty parameters have no effect in thinking mode. It also documents a restricted effective top_p range there, while non-thinking fixes top-p at 1.0. For a clean first experiment, omit these sampling controls. A copied temperature-zero setting should not be presented as proof of deterministic thinking-mode output or as a substitute for repeated evaluation.

2. Define a task-level quality contract before comparing speed

Start with the thing the user needs to accomplish. “A helpful answer” is too broad to score consistently. A support classifier may need one allowed category and a justified escalation flag. A planning assistant may need a feasible allocation and a correct total. A document assistant may need claims supported by the supplied source. Write those requirements in terms of observable final output and permitted actions.

Separate hard gates from preferences. Correct units, satisfied constraints, authorized tool use, and a valid output format can be hard gates. Concision, organization, and tone may be preferences among acceptable answers. This prevents a polished response from compensating numerically for an invalid decision. An answer with an invented source should not win because its formatting earned enough points to offset the invention.

For the planning exercise below, acceptance means that the quantities are nonnegative integers, every stated constraint holds, the arithmetic is correct, and the solution reaches the reference optimum. A concise explanation of the binding constraints is useful, but the grader does not reward a long deliberation transcript. Readers and evaluators should inspect the final result and the evidence needed to verify it.

Design an explicit uncertainty outcome. Some inputs should produce a clarification question, an “insufficient information” result, or a safe refusal to take an unauthorized action. If the evaluation only rewards giving an answer, it can favor a configuration that guesses confidently. Include these outcomes in the contract from the beginning so a correct clarification is not mislabeled as a failure.

A compact rubric can use four hard gates: correct result, supported assumptions, valid interface output, and safe behavior. Mark acceptance only when all required gates pass. Keep separate reason codes such as arithmetic_error, missing_evidence, invalid_shape, and unauthorized_action. A single pass rate tells you whether something improved; the reason codes tell you what to repair.

Choose thresholds from the product’s consequences and have an accountable owner approve them. An internal brainstorming aid and a workflow that changes customer records should not share the same tolerance for mistakes. A small demonstration set cannot establish a safe operating threshold for a high-consequence application. Use domain review and controlled release procedures where the potential harm requires them.

3. Build a representative evaluation set

Collect tasks from the workload you intend to serve, with appropriate permission and redaction. Preserve the important properties: input length, number of constraints, expected output shape, ambiguity, and need for external evidence. Removing every difficult detail during anonymization can produce a clean benchmark that no longer resembles the application. Keep sensitive information out of public fixtures and unnecessary logs.

Partition the set into useful task families. For example, include direct extraction, multi-constraint planning, explanation grounded in a supplied passage, and tool-assisted verification. Also include impossible requests, contradictory inputs, and requests that lack one crucial fact. This lets you discover whether a cheaper configuration works well on one family while a higher effort is valuable on another.

Keep routine tasks in the evaluation. A suite composed entirely of puzzles may reward an expensive setting that adds little value to everyday traffic. Conversely, a suite dominated by trivial extraction can hide important failures on the complex minority. Report results by family and for a workload-weighted aggregate using a documented traffic mix, rather than quietly changing the mix to favor a preferred model.

Freeze a development set for prompt iteration and a separate holdout set for decisions. If every failed example becomes a demonstration in the prompt and then remains in the reported test set, the headline score becomes less informative. Version inputs, expected outcomes, prompts, validators, and configuration together. A result without a stable task version is hard to compare after any of those elements change.

Use exact checks where an exact check is available. Parse a date against the supplied evidence, recompute a total, execute a bounded test suite, or enumerate a tiny feasible set. For subjective criteria, provide written anchors and have reviewers score without seeing the configuration label. If reviewers disagree, investigate the rubric rather than averaging away an unclear requirement.

A second model can help flag potential issues, but it is not automatically an authoritative grader. Its preferences can correlate with one candidate’s style, and it can make the same factual mistake. Validate the evaluator on known good and bad examples and audit disagreements. For retrieval-specific questions, our RAG evaluation guide separates missing evidence from failures to use evidence correctly.

4. Work through an original, checkable planning example

Consider a fictional workshop assembling four learning kits. Kit A costs 18 budget units and contributes five activity points. Kit B costs 25 and contributes eight points. Kit C costs 31 and contributes ten points. The workshop must choose exactly four kits, spend at most 100 units, include at least one A, and use no more than two C kits. The objective is to maximize total activity points.

This example is deliberately small. It combines counting, an inequality, a minimum requirement, a cap, and an optimization objective, while remaining easy to verify independently. It is a teaching fixture rather than evidence that a particular model requires thinking mode. Before evaluating any response, create the reference answer with an exhaustive enumeration of the integer choices.

The unique optimum is one A, two B, and one C. The count is four, the cost is 18 + 50 + 31 = 99, and the score is 5 + 16 + 10 = 31. Offline enumeration finds eight feasible allocations and no other allocation with 31 points. That reference result was checked locally. It does not describe an answer obtained from a live DeepSeek request.

Notice two useful failure cases. One A, one B, and two C totals 105 units, so its attractive score of 33 is infeasible. Two A and two C costs 98 and earns 30, so it is feasible but suboptimal. A grader that checks only arithmetic misses the budget violation in the first case; a grader that checks only feasibility misses the lost point in the second.

Ask for a compact final object containing counts, cost, points, and a brief verification summary. The public response should contain enough information to check the result, without requiring private internal deliberation. If the application needs machine-readable fields, validate their types and recompute the totals outside the model. Our structured-output guide covers that interface boundary in detail.

Create related fixtures rather than repeating the same numbers. A lower budget can make the task infeasible. A missing price should trigger a clarification. A changed upper bound can change the optimum. A malicious sentence embedded in a source note should not override the real constraints. Keep each fixture’s expected outcome separate so the evaluator cannot accidentally use the answer for the original task on every variant.

Then add a task where deterministic software is the right primary tool. If a production planner routinely solves a large optimization problem, the model can translate intent into a constrained input while an appropriate solver produces and verifies the solution. Raising language-model effort indefinitely is not a replacement for an algorithm with a clear contract. Evaluate that combined workflow on the same user outcome.

5. Construct comparable requests without accidental differences

The following request factory illustrates a controlled Chat Completions comparison. It takes one prompt and a canonical effort label, changes the documented effort field, and uses the same output cap. It intentionally makes no network call until the returned dictionary is passed to a client. These API examples were not executed during preparation of this article; the purpose is to show the experimental boundary clearly.

request_factory.py

"""Illustrative request configuration only; no API call was executed."""

def chat_request(prompt, effort):
    if effort not in {"none", "low", "high", "max"}:
        raise ValueError("use a canonical effort label")
    if not isinstance(prompt, str) or not prompt.strip():
        raise ValueError("prompt must be nonempty text")
    return {
        "model": "deepseek-flash",
        "messages": [{"role": "user", "content": prompt}],
        "reasoning_effort": effort,
        "max_tokens": 4096,
    }

# Unexecuted usage illustration, with an already configured client:
# response = client.chat.completions.create(**chat_request(prompt, "low"))
# final_answer = response.choices[0].message.content
# Check response.choices[0].finish_reason and validate final_answer.

The 4,096-token cap in this illustration is an experiment choice, not a service recommendation. A complex task may need more room, especially when thinking consumes part of generation. If one candidate repeatedly ends because of length, distinguish two questions: performance under a common resource cap and performance with a cap suitable for that mode. They are both useful experiments, but they answer different product questions.

Keep the user-visible answer requirement constant. Asking one candidate for a one-line object and another for a tutorial makes timing and output-token totals hard to interpret. Similarly, do not give a higher-effort candidate extra examples, additional evidence, a better system prompt, or a different tool set unless you label the comparison as a whole-workflow change rather than an isolated effort test.

Use explicit application configuration instead of relying on defaults that can change. Store the endpoint, model identifier, canonical effort label, output cap, prompt version, dataset version, and evaluation-code version. If the provider returns model or request identifiers, preserve appropriate non-sensitive identifiers for debugging. Do not claim that an alias pins immutable weights unless the service documents that guarantee.

For a Responses-based application, build a separate request adapter using reasoning={"effort": effort} and the interface’s max_output_tokens field. Do not run a comparison across both interfaces unintentionally. Differences in conversation construction, output parsing, and unsupported parameters can swamp the effect you were trying to isolate. First validate each adapter on simple fixtures whose expected output is obvious.

Before a paid run, inspect the serialized request with secrets removed, verify that configuration names really reach the provider, and test the response parser using saved synthetic fixtures. A user-interface selector labeled “maximum” does not prove the outgoing request contains max. Configuration observability is part of the experiment, especially when an SDK, gateway, or third-party compatibility layer is involved.

6. Measure time to a usable answer and count tokens once

Define the clocks before comparing latency. Request-to-first-event measures transport progress. Request-to-first-answer-token measures when answer text begins to arrive. Request-to-final-answer measures when generation ends. Request-to-validated-result includes parsing, validation, any authorized tool work, and application checks. For many products, that last duration is closest to what the user actually needs.

Thinking-related stream content is not the same as the first answer token. If one configuration starts emitting a reasoning field early while another emits final-answer text, measuring the first nonempty chunk favors different things. Mark the event types explicitly. A spinner or neutral progress message can improve the interface, but it does not reduce the time until a trustworthy result exists.

Track both central tendency and the tail. A median describes a typical attempt; a high percentile describes slower experiences that can matter for a deadline. State the percentile definition, sample count, and workload. A p95 from a tiny demonstration is unstable and should not be treated as a service guarantee. The helper below uses a simple nearest-rank definition so its calculation is inspectable.

Include failures and timeouts in the attempt ledger. If a request times out at the application’s configured deadline, record its observed duration and failure outcome. Excluding it from the latency distribution makes an unreliable configuration look faster. Keep successful-only latency as a separately labeled diagnostic, if useful, while using all-attempt and end-to-end task metrics for operational decisions.

For Chat Completions, completion_tokens is the generated completion total; the reasoning-token detail is a component, not an extra quantity to add again. Record the input totals too when calculating monetary cost. In Responses, the corresponding output total is output_tokens, with a reasoning breakdown in its details. Normalize these different schemas before comparing dashboards.

The displayed helper focuses on completion-token efficiency, not a dollar estimate. Input volume, cache hits, current tariffs, retries, and tool costs also matter to a full cost-per-accepted-task calculation. Use the current usage counters and rate card when you perform that calculation; our context-caching and cost-measurement guide explains the input accounting. A lower token count alone does not establish a lower invoice.

Missing usage is an unknown, never a free request. An interrupted stream may leave you with an observed elapsed time and no complete token record. Count the attempt and its outcome, mark the missing usage, and withhold a supposedly complete token-efficiency figure until reconciled. Keep observability failure separate from model failure so the right team can investigate it.

7. Summarize attempts with a tested offline helper

The standard-library Python helper below consumes already graded attempt records. It does not decide whether a model’s answer is correct: the accepted value must come from your task validator or review process. It validates the metric inputs, rejects duplicate attempt identifiers and mixed variants, and refuses to conceal missing completion usage inside a complete-looking total.

scoring.py

"""Offline attempt summaries; acceptance comes from an external task validator."""
import math
from collections import Counter
from collections.abc import Mapping


def summarize_variant(records):
    """Summarize every attempt, including failures and timed-out attempts."""
    rows = list(records)
    if not rows:
        raise ValueError("at least one attempt is required")
    ids, variants, elapsed, tokens = set(), set(), [], []
    accepted = 0
    for row in rows:
        if not isinstance(row, Mapping):
            raise ValueError("each attempt must be a mapping")
        for field in ("attempt_id", "task_id", "variant"):
            if not isinstance(row.get(field), str) or not row[field].strip():
                raise ValueError(f"{field} must be a nonempty string")
        if row["attempt_id"] in ids:
            raise ValueError("duplicate attempt_id")
        ids.add(row["attempt_id"])
        variants.add(row["variant"])
        if type(row.get("accepted")) is not bool:
            raise ValueError("accepted must be a validated boolean")
        accepted += row["accepted"]
        ms = row.get("elapsed_ms")
        if type(ms) not in (int, float) or ms < 0:
            raise ValueError("elapsed_ms must be nonnegative and finite")
        try:
            finite = math.isfinite(ms)
        except OverflowError:
            finite = False
        if not finite:
            raise ValueError("elapsed_ms must be nonnegative and finite")
        elapsed.append(ms)
        completion, reasoning = row.get("completion_tokens"), row.get("reasoning_tokens")
        for value in (completion, reasoning):
            if value is not None and (type(value) is not int or value < 0):
                raise ValueError("token counts must be nonnegative integers or missing")
        if reasoning is not None and (completion is None or reasoning > completion):
            raise ValueError("reasoning_tokens must be a component of completion_tokens")
        tokens.append(completion)
    if len(variants) != 1:
        raise ValueError("summarize one variant at a time")
    elapsed.sort()
    n, missing = len(rows), tokens.count(None)
    total = None if missing else sum(tokens)
    lo, hi = elapsed[(n - 1) // 2], elapsed[n // 2]
    return {"variant": next(iter(variants)), "acceptance_count": accepted,
            "total_attempts": n, "acceptance_rate": accepted / n,
            "median_elapsed_ms": lo + (hi - lo) / 2,
            "p95_elapsed_ms": elapsed[(95 * n + 99) // 100 - 1],
            "total_completion_tokens": total, "usage_missing": missing,
            "completion_tokens_per_accepted": total / accepted
            if total is not None and accepted else None}


def compare_paired(baseline, candidate, *, minimum_acceptance_rate=1.0):
    """Gate paired latency comparison by a predeclared floor and no regressions."""
    if type(minimum_acceptance_rate) not in (int, float) or not 0 <= minimum_acceptance_rate <= 1:
        raise ValueError("minimum_acceptance_rate must be between 0 and 1")
    baseline, candidate = list(baseline), list(candidate)
    before, after = summarize_variant(baseline), summarize_variant(candidate)
    if before["variant"] == after["variant"]:
        raise ValueError("comparison requires distinct variants")
    if len({r["attempt_id"] for r in baseline + candidate}) != len(baseline + candidate):
        raise ValueError("attempt_id must also be unique across variants")
    counts = [Counter(r["task_id"] for r in rows) for rows in (baseline, candidate)]
    if counts[0] != counts[1] or any(n != 1 for n in counts[0].values()):
        raise ValueError("pair exactly one attempt per task in each variant")
    base = {r["task_id"]: r["accepted"] for r in baseline}
    regressions = sorted(r["task_id"] for r in candidate
                         if base[r["task_id"]] and not r["accepted"])
    eligible = not regressions and min(before["acceptance_rate"], after["acceptance_rate"]) >= minimum_acceptance_rate
    return {"baseline": before, "candidate": after, "quality_gate_passed": eligible,
            "regressed_task_ids": regressions,
            "candidate_p95_minus_baseline_ms": after["p95_elapsed_ms"] - before["p95_elapsed_ms"]
            if eligible else None}

In this contract, elapsed_ms should consistently mean request-to-validated-outcome for each attempt, including a deadline outcome when an attempt fails. Completion tokens can be None when usage is unavailable. Reasoning tokens are optional, but when supplied they must fit inside the completion total. A boolean is rejected as a numeric measurement even though Python treats booleans as integer subclasses.

The following tiny fixture is synthetic. It exists to demonstrate how the helper behaves, not to compare actual DeepSeek modes. The baseline has three accepted attempts; the candidate fails the second of the same three tasks. Every elapsed time still contributes to its summary. The token numerator includes failed work, while the denominator counts accepted attempts. The paired quality gate therefore withholds a latency delta for the faster-but-failing candidate.

demo.py

"""SYNTHETIC data only: demonstrates bookkeeping, not model performance."""
import json
from scoring import compare_paired


def synthetic(variant, accepted, durations):
    return [dict(attempt_id=f"{variant}-{i}", task_id=f"task-{i}",
                 variant=variant, accepted=ok, elapsed_ms=ms,
                 completion_tokens=100, reasoning_tokens=40)
            for i, (ok, ms) in enumerate(zip(accepted, durations), 1)]


# These labels and numbers are invented; no model or API was run.
baseline = synthetic("baseline", [True, True, True], [900, 1100, 1300])
fast_but_failing = synthetic("candidate", [True, False, True], [300, 500, 700])
report = compare_paired(baseline, fast_but_failing,
                        minimum_acceptance_rate=1.0)  # Declare before collecting data.
print(json.dumps({"data_kind": "SYNTHETIC; not measured model performance",
                  "comparison": report}, indent=2))
assert report["quality_gate_passed"] is False
assert report["candidate_p95_minus_baseline_ms"] is None

Save the helper as scoring.py and the demo as demo.py, then run python demo.py. The optional paired comparison requires exactly one attempt per task in each variant, matching task sets, a predeclared acceptance floor, and no newly failed tasks. It is a conservative demonstration gate, not a statistical test or a general policy for repeated trials. Editorial offline tests cover exact summaries, input validation, percentile behavior, missing usage, and the independently enumerated kit optimum. Those checks establish that this example performs the described arithmetic and rejects malformed fixtures. They do not validate the accuracy, latency, cost, or stability of any live model.

For a real product, retain a task identifier as well as an attempt identifier. One user task can require several attempts, tool calls, or fallback requests. The helper’s acceptance rate is per attempt, and its token ratio is per accepted attempt. Aggregate the whole chain separately to report cost and time per completed user task. Do not let retries masquerade as additional independent users or additional successes.

Keep raw private prompts out of a public metrics export. A useful measurement record can contain a redacted task identifier, version labels, outcomes, timing, token counters, and error categories. If debugging requires content retention, use the organization’s access and retention policy. Operational convenience is not a reason to collect the provider’s reasoning field into an unrestricted analytics table.

8. Run a fair matched-task experiment

Begin with a small pilot to validate the harness, then choose a sample large enough for the decision you need to make. Do not announce a winner from two handpicked examples. Set the acceptance threshold, allowed quality regression, latency target, resource ceiling, and comparison procedure before examining the final results. Predefined decision rules reduce the temptation to reinterpret a disappointing run.

Run the same task versions through each candidate configuration. Interleave or randomize configuration order so one candidate is not always measured during a different load period. Keep concurrency, client location, request deadlines, and retry policy comparable. Log changes that you cannot control. A latency difference observed on different days may reflect service conditions as well as the mode setting.

Repeated attempts reveal variability, but they do not create new independent task types. Report the number of distinct tasks and repetitions separately. For statistical uncertainty, use an analysis that respects that grouping rather than treating every repeated response as unrelated evidence. If the observed difference is small compared with uncertainty, gather more representative evidence or retain the simpler existing configuration.

Inspect paired outcomes. Which tasks did both variants pass? Which did only the candidate pass? Which did the candidate newly fail? A nearly unchanged aggregate rate can conceal a serious regression on a critical family. Review those regressions with the domain owner before using an overall average as permission to release.

Cache behavior can affect the timing of repeated prompts. Record input hit and miss counters when available, and distinguish a warm repeated workload from the first encounter with a new document. Both workloads may be relevant. Do not remove all cold attempts from one candidate while retaining them for another, and do not equate a cache advantage with a reasoning-quality advantage.

Evaluate the trade-off as a set of eligible options. First exclude configurations that miss hard quality or safety requirements. Among the remaining options, compare time, estimated total cost, and operational complexity. If one configuration is faster but another is cheaper, the correct choice depends on the product’s constraints. A single blended score can hide that trade-off unless its weights have a clear owner and rationale.

Archive the run manifest, aggregate results, failure examples allowed by policy, and the decision. State what was not measured. A conclusion such as “low effort is eligible for these extraction tasks under this validator” is more useful than “low is best.” It tells the next engineer where the evidence applies and which changes require a new evaluation.

9. Design a bounded routing and escalation policy

A production policy can start with a task family rather than a universal setting. Route narrowly specified extraction to an eligible economical configuration, constrained planning to a tested thinking level, and ambiguous or high-consequence cases to an appropriate review path. These are design hypotheses until your evaluation supports them; the task’s category name alone does not prove which mode will succeed.

Escalate for a concrete reason. A deterministic validator might detect a broken constraint, a parser might reject the shape, or evidence checks might find an unsupported claim. Some failures need a repaired input or retrieval step instead of more effort. Keep a short reason code and a bounded retry policy so the system can explain why extra work was attempted and when it must stop.

Account for the entire cascade. Trying a cheap configuration first and then a more expensive one on failure can be slower and costlier than starting with the second for difficult tasks. Calculate escalation frequency and total spend per completed task, including unsuccessful paths. If failures are hard to detect reliably, a validator-triggered cascade may silently accept the wrong cheap answer.

Use evidence-based signals rather than the model’s self-confidence as the sole trigger. A fluent answer saying “certain” is not calibrated proof, and a request for more deliberation is not an external correctness check. Prefer observable signals such as constraint violations, missing required fields, unsupported references, or an explicitly incomplete result. Human review remains appropriate when the consequence exceeds what automated checks can establish.

Set maximum attempts, a total wall-clock budget, and a spend boundary before release. Define the user experience when those limits are reached: a clarification question, a safe partial result with clear limits, or an escalation to a person. A bounded failure that tells the truth is preferable to an endless sequence of costly retries that never satisfies the original request.

Keep routing logic versioned and easy to roll back. Monitor the share of traffic taking each route, acceptance by task family, tail latency, missing telemetry, and escalation causes. A sudden shift may indicate changed input traffic, a broken validator, or a provider update. Diagnose the evidence before attributing every change to the model’s intelligence.

10. Handle tools and conversation state carefully

A mode comparison inside an agentic workflow has more moving parts than a single response. Tool choice, argument validity, tool latency, returned evidence, and action authorization all influence the final outcome. Record these stages separately, while keeping the same available tools and permissions across candidates. Otherwise a better search result can look like a better reasoning configuration.

For Chat Completions, the current DeepSeek thinking guide distinguishes conversation replay by whether the request includes tools. When tools are supplied, it says to pass back the reasoning content from all previous assistant turns for context, including turns that did not actually call a tool. Without tools, that field is not needed and is ignored if returned. Follow the current endpoint-specific protocol rather than an old blanket rule to strip or retain it everywhere.

This is a transport requirement, not a recommendation to expose private deliberation to end users or score it as authoritative evidence. Preserve protocol state in the controlled conversation adapter when required. Present the final answer and a concise, verifiable explanation appropriate to the task. Apply your data policy to storage and access, and avoid copying internal fields into public logs or analytics by default.

A model-generated tool proposal still needs application enforcement. Validate the tool name, arguments, target resource, and user authorization before executing it. A higher effort setting does not confer permission or neutralize malicious retrieved text. Our prompt-injection prevention guide explains the boundary between model suggestions and authorized operations.

Evaluate recovery paths as part of the workflow. What happens when a tool returns no results, the service times out, the source contradicts an earlier answer, or a proposed action is denied? An apparently strong first response can turn into a poor completed task if the application loses state or repeats an action. Use harmless fixtures and read-only tools during early evaluation.

11. Diagnose failures before raising effort

If a response is wrong, classify the failure first. Missing information calls for better input or a question. Missing evidence calls for retrieval or a more suitable source. Invalid structure calls for a clear contract and validation. Incorrect arithmetic may be better handled by deterministic calculation. Higher effort can be one candidate intervention, but it should not become the automatic explanation for every failure.

If a response is unexpectedly slow, inspect where the time went. Queueing, transport, tool execution, generation length, validation, and repeated attempts all contribute. A first-event metric can hide a long wait for the actual answer. An output cap that is far larger than the task needs can permit lengthy responses. Diagnose stages before claiming the model or effort control is the bottleneck.

If a lower-effort result looks better, check that the comparison is real. Confirm the outgoing parameters, input versions, cap, parser, and scoring rules. Then inspect whether the task genuinely benefits from brevity or whether the high-effort candidate encountered a different failure. A surprising result can be valid; it needs the same evidentiary standard as a result that matches your expectations.

If the candidate always passes locally but fails after deployment, compare traffic families and integration behavior. Production may have longer inputs, new languages, concurrent tool activity, truncated histories, or stricter deadlines. A holdout set should evolve to include representative new cases while retaining enough stable cases to detect regressions. Document when the evaluation population changes.

If the quality score rises while complaints increase, your acceptance contract may be incomplete. The system may be technically correct but too slow, too verbose, or unable to ask an essential question. Review real task outcomes and user feedback with the same care as numeric metrics. The purpose of evaluation is to improve the workflow, not to defend a dashboard.

12. Release checklist and common questions

Before deployment, verify that the chosen configuration clears the approved gates on the relevant holdout tasks; the actual request contains the intended model, mode, effort, and cap; the parser distinguishes final answers from protocol fields; and the timeout and retry policy are bounded. Confirm that usage gaps remain visible, unsuccessful attempts remain in metrics, and a rollback configuration is ready.

Start with a limited rollout whose scope matches the evidence. Compare observed task-family mix with the evaluation set, inspect important failures, and watch completed-task latency rather than only generation speed. Expand when the agreed release conditions hold. Re-evaluate after material prompt, validator, model, tool, or traffic changes instead of assuming the first comparison stays valid indefinitely.

Is max effort always the most accurate choice?

No universal accuracy guarantee follows from the name. Max is a supported control that may be worth testing on difficult tasks. Eligibility still depends on validated final outcomes, deadlines, and total resource use. A model can spend more generation effort and still use a wrong assumption or lack the evidence needed to answer.

Does a higher reasoning-token count prove better reasoning?

No. It is a usage measurement, not a correctness certificate. Compare the final result against the task contract and independent evidence. Track the counter to understand resource use, but do not reward its size in the acceptance score or add it a second time to completion-token totals.

Can temperature zero make the comparison deterministic?

The current thinking guide says temperature has no effect in thinking mode. More generally, deterministic local grading is different from deterministic model generation. Repeat tasks where variability matters, record the configuration, and avoid presenting one successful response as a stability guarantee.

Should every failure retry at a higher effort?

No. First establish whether the failure is detectable, whether another attempt is authorized, and whether more effort plausibly addresses its cause. Repair missing evidence or invalid inputs where appropriate. Stop at the documented attempt, time, and spend limits, and preserve an honest fallback when a usable answer cannot be established.

What should I do first?

Choose one bounded task family, write a final-answer acceptance contract, and assemble a small set with correct, incorrect, ambiguous, and infeasible cases. Validate the harness offline. Then run an appropriately authorized, budgeted matched comparison and inspect the failures before selecting a default. That sequence produces a decision you can explain, reproduce, and revise when the workload changes.

Sources & References

Primary documentation checked October 2, 2026. Provider controls and limits can change. The evaluation rubric, workshop-kit fixture, diagrams, and offline helper are original instructional material; they are not provider benchmark results.

• DeepSeek: Thinking Mode — mode toggles, canonical effort levels, compatibility mappings, sampling behavior, and conversation replay rules.
• DeepSeek: Create Chat Completion — request fields, output limits, completion status, and usage counters.
• DeepSeek: Responses API Guide — interface-specific reasoning controls and compatibility differences.
• DeepSeek: Create Response — Responses request and output-usage schema.
• DeepSeek: Models & Pricing — current model identifiers, supported modes, context and generation limits.
• DeepSeek: Change Log — model releases and changes relevant to configuration freshness.