In DeepSeek's API, why must you strip reasoning_content before the next turn?

## The stateless loop DeepSeek's `/chat/completions` endpoint keeps nothing between calls. Every request carries the full `messages` array, and the usual pattern is to append each assistant reply to a list and send the grown list next time. On `deepseek-chat` you can append the entire message object and it works. On `deepseek-reasoner` that same code fails, because the object you appended now contains `reasoning_content`. ## What actually happens DeepSeek documents that including `reasoning_content` in the input messages produces a 400 error. This is a deliberately loud failure rather than a silent strip: the API refuses the request so you cannot accidentally build a conversation history whose semantics the model was never trained for. The failure mode is characteristic — the first call succeeds, the second call in the same session 400s — which is exactly the signature to recognise in an interview answer. ## Why the design says no A reasoning model is trained to generate its thinking for the current problem, then answer. Its own past thinking is not part of the dialogue: the conversation the model is meant to condition on is the sequence of user turns and the answers it gave. Replaying old traces would bloat the prompt with scratch work, push out real context, and push the model toward re-committing to earlier reasoning instead of reconsidering. So the contract is simply: the visible turns carry the state, and the model re-derives whatever thinking the next turn requires. The cost consequence is worth being explicit about. Because each turn re-thinks, thinking tokens are paid per turn, not once. Turning a task into ten chatty turns pays for ten separate reasoning passes; keeping the same task in one well-specified turn pays for one. That is a real design lever in agent loops. ## The correct multi-turn shape After a call, split the response: - `message.content` goes into the history as the assistant turn. - `message.reasoning_content` goes to your logs, your debug panel, or the bin. If you need continuity of the model's earlier judgement, carry it in the visible answer — a reasoning model that concludes something important should say it in `content`, where the next turn can see it. Some teams add a summarisation step: distil a long trace into a couple of sentences and put those into the next user or system message. That is legitimate, because it is ordinary text you authored, not the `reasoning_content` field being echoed back. ## Practical implementation notes Build the history explicitly instead of pushing SDK objects into it. A one-line helper that maps a response to `{"role": "assistant", "content": msg.content}` removes the whole class of bug, and keeps your history serialisable for storage or replay. If you already persist raw responses (a good idea for auditing), strip on the way out — sanitise when constructing the request, not when storing. The same discipline applies when a conversation moves between models. History assembled from a reasoner call must be safe to send to `deepseek-chat` and vice versa; a history containing only roles and `content` always is. Watch out for framework abstractions too. Some client libraries and agent frameworks serialise every field of the assistant message back into the next request. If you see 400s from DeepSeek only on multi-turn reasoning conversations, inspect the actual outbound JSON rather than your application-level history object — the extra field is often added by the layer in between. ## Diagnosing it Symptoms that point straight here: single-turn calls always work; the failure appears on turn two; switching the model to `deepseek-chat` makes the error disappear; and the outbound payload, when dumped, shows a `reasoning_content` key inside `messages`. The fix is one line of message construction, not a retry policy — this is a request-shape error, so retrying it unchanged will fail identically every time.