You have an API key, a queue of tasks nobody on the team enjoys doing, and a model list with two names that look almost identical. Choosing between deepseek-chat and deepseek-reasoner on vibes is an expensive habit: the reasoning model can spend ten times the output tokens working through something the cheaper one already handles in 300 milliseconds.
What follows is the order I’d actually work through, from a throwaway test call to a tuned deployment. Most of it is an afternoon of setup. All of it saves you from rebuilding the same decisions later once traffic arrives.
Step 1: Match the model to the shape of the task
DeepSeek’s two main API endpoints behave differently enough that you should treat them as separate tools, not a quality dial.
- deepseek-chat returns an answer immediately. It’s the right pick for extraction, rewriting, classification, summarisation, and tool calling, where the work is pattern matching against a prompt.
- deepseek-reasoner writes out a chain of thought before the visible answer. Those hidden tokens are billed as output, and latency usually lands between 8 and 60 seconds depending on how far it wanders.
A useful test: could a competent analyst answer this in one pass, or would they need to sit down with a pen? “Pull the invoice number and due date out of this PDF” goes to the chat model. “Twelve invoices, three vendors, which two are duplicates and which one hides a currency mismatch?” goes to the reasoner. The interesting part is that the second question looks easy to the person writing the prompt and is genuinely hard for a non-reasoning model, which is exactly the gap DeepSeek’s open-weight reasoning models closed against closed frontier systems.
Step 2: Do the token math before you write code
Reasoning output is the line item that surprises people. A ticket that produces a tidy 200-token answer might quietly generate 1,200 reasoning tokens first. Run 4,000 tickets a day and you’re paying for 4.8 million reasoning tokens daily before any caching.
So build the estimate first: calls per day, times the sum of input tokens, reasoning tokens, and final answer tokens, times output pricing. Then check two levers.
The first is context caching. If every request carries the same 3,000-token instruction block, policy document, or schema description, cache it and you stop paying full freight for that prefix on every call. The second is trimming the visible answer. A reasoner asked for a structured verdict plus one sentence costs far less than one asked to “explain your thinking”, because the chain is already there.
Set a hard ceiling too. Cap the reasoning budget at something like 4,000 tokens on an endpoint and watch how often you hit it. Anything that clips regularly is a sign you’re routing the wrong tier of task to the wrong model.
Step 3: Prompt a reasoning model like a reasoning model
Old habits hurt here. Adding “think step by step” to a reasoner prompt is like telling a chess engine to consider its moves. It does that already.
What actually moves accuracy is giving the model criteria it can check against. Compare these two prompts for a security alert triage task:
Weak: “Look at this alert and tell me if it’s serious.”
Workable: “Classify severity as low, medium, or high. High means the source IP appears in our blocklist, the destination is a production database, or the event fired more than 50 times in five minutes. Return JSON with severity, the rule that fired, and one sentence of justification. If no rule fires and the event count is under 10, return low.”
The second version gives the model explicit predicates. On our own triage tests that single change cut false highs by roughly a third, because the model stopped inventing its own definition of “serious”.
Ask for the verdict, not the essay
For anything machine-consumed, request the final answer first, then optional supporting detail. Downstream code can parse the first line and ignore the rest, and you stop writing brittle regex against free-form prose.
Step 4: Put a router in front of it
Most teams shouldn’t pick one model. They should pick a rule for escalating between them.
A cheap classifier does the work: send the request to deepseek-chat with a prompt that returns a single label, easy or hard, in about 15 tokens. Escalate to the reasoner when the task involves arithmetic on money, comparison across three or more documents, or multi-step constraint checking. Escalate on low confidence too, when the classifier hedges or the chat model returns a malformed answer twice.
Expect a useful split. On typical document-heavy workloads, 70 to 85 percent of traffic stays on the cheap path, and the escalated remainder is where nearly all the accuracy was previously being lost.
Step 5: If you’re self-hosting, design the serving layer first
Full-weight DeepSeek models are mixture-of-experts architectures in the hundreds of billions of parameters. Serving one means sharding across nodes, and at that point the hard problem stops being matrix multiplication and becomes scheduling. Prefill and decode have genuinely different resource profiles, which is why splitting them across separate pools turns into a thousand-GPU coordination problem rather than a simple config change.
The pragmatic middle ground: distilled variants in the 7B to 70B range run comfortably on a single 80GB accelerator, deliver good reasoning on narrow domains, and cost a fraction of an API bill at steady volume. If your traffic is spiky, the API is almost always the better default and self-hosting is the experiment, not the plan.
Step 6: Distil a small model on your own data
This step gets skipped constantly, and it’s often the highest-leverage one. Generate a few thousand prompts from your own logs, attach a programmatic checker to each, and train a small model against those rewards. Group relative policy optimisation is the method doing the heavy lifting in most current open reasoning pipelines, and it works best when rewards are checkable rather than graded by a judge, as this walkthrough of training small language models with verifiable rewards lays out in detail.
Verifiable means a unit test passes, a regex matches, an amount reconciles, a status code is correct. Tasks with no checker, like “write a warmer rejection email”, resist this approach and should stay on the API.
Step 7: Measure cost per correct answer, not accuracy
Aggregate accuracy hides the failures you care about, which is the same trap that makes a respectable error metric mislead you about real system behaviour. A reasoner might score 94 percent overall while being wrong on every case that involves a refund over $5,000.
So evaluate in slices. Hold out a set of real requests the model has never seen, tag each by task type and difficulty, and score three things: final answer correctness, cost in tokens, and latency. Score the verdict, never the chain of thought, since a model can reach the right conclusion through visibly broken reasoning. If your prompt tuning files are dated, make sure the eval set comes from after that date, otherwise you’re just measuring memorisation.
Where DeepSeek still falls over
Reasoning models are confident, and confidence is expensive when it’s wrong. Hard combinatorial problems are the clearest failure: shift scheduling, vehicle routing, resource allocation with conflicting constraints. The model will produce a plausible-looking plan that violates two of your constraints and never mentions it.
The workaround is division of labour, the same one that applies to letting a language model anywhere near a real optimisation problem: use the model to translate messy prose into a formal specification, then hand that specification to a solver that actually guarantees feasibility. Long-context recall is the other soft spot, so for anything spanning more than a few documents, retrieval beats stuffing.
Your first week, mapped out
- Day one: pull 50 real requests from your logs and run each through both models by hand. Label which one wins and why. That spreadsheet will change your architecture.
- Day two: turn those 50 into 200 evals with expected answers, tagged by difficulty. This is your regression suite for the next year.
- Day three: write the structured prompt with explicit criteria, and verify the JSON parses on every eval case.
- Day four: add the router and measure the split. If more than 40 percent escalates, your classifier prompt is too conservative.
- Day five: turn on context caching and re-run the evals to confirm nothing shifted.
From there, the decision is narrow: keep paying per token, or train a small verifier-scored model on the slice of traffic you’ve proven is repetitive. You’ll know which way to go, because day two gave you the numbers.