{"slug": "deepseek-s-response-api-isn-t-openai-responses-that-one-parser-mistake-drops-the", "title": "DeepSeek's Response API Isn't OpenAI Responses. That One Parser Mistake Drops the Reasoning.", "summary": "A developer warns that DeepSeek's response API is not compatible with OpenAI's Responses API, and that a common parsing mistake can silently drop the `reasoning_content` field. DeepSeek V4 models use `/chat/completions` with `reasoning_content` in the message object, and developers should explicitly parse this field to avoid losing thinking output. The developer also notes that old model names like `deepseek-chat` and `deepseek-reasoner` are deprecated in favor of `deepseek-v4-flash` and `deepseek-v4-pro`.", "body_md": "I keep seeing developers use \"DeepSeek response API\" and \"OpenAI Responses API\" as if they mean the same thing.\n\nThey do not.\n\nThat small naming mistake can make your integration look like it works while quietly dropping the most important field in the response: `reasoning_content`\n\n.\n\nI spent time checking the DeepSeek V4 docs and the live TokenMix model catalog. The practical answer is simple:\n\nDeepSeek is OpenAI-compatible at the Chat Completions layer. It is not documented as OpenAI `/responses`\n\ncompatible.\n\n`/responses`\n\nAPI. It is `/chat/completions`\n\n.`choices[0].message.reasoning_content`\n\n.`message.content`\n\n, you may lose DeepSeek's thinking output.`deepseek-v4-flash`\n\nand `deepseek-v4-pro`\n\n; old `deepseek-chat`\n\nand `deepseek-reasoner`\n\nnames are scheduled for deprecation.DeepSeek V4 moved the model naming story forward.\n\nThe old mental model was:\n\n| Old model name | What people assumed |\n|---|---|\n`deepseek-chat` |\nnormal chat |\n`deepseek-reasoner` |\nreasoning model |\n\nThe newer V4 model IDs are:\n\n| New model | Best read |\n|---|---|\n`deepseek-v4-flash` |\ncheaper/high-throughput V4 |\n`deepseek-v4-pro` |\nstronger reasoning/coding V4 |\n\nDeepSeek's docs say the older `deepseek-chat`\n\nand `deepseek-reasoner`\n\nnames are compatibility aliases heading toward deprecation on 2026-07-24 15:59 UTC.\n\nThat means I would not build new production code around the old names.\n\nIf you are used to OpenAI Chat Completions, this will look familiar:\n\n```\n{\n  \"choices\": [\n    {\n      \"message\": {\n        \"content\": \"final answer\",\n        \"reasoning_content\": \"thinking output\",\n        \"tool_calls\": []\n      },\n      \"finish_reason\": \"stop\"\n    }\n  ],\n  \"usage\": {\n    \"prompt_tokens\": 123,\n    \"completion_tokens\": 456,\n    \"completion_tokens_details\": {\n      \"reasoning_tokens\": 300\n    }\n  }\n}\n```\n\nThe trap is that most basic wrappers only do this:\n\n```\nanswer = response.choices[0].message.content\n```\n\nThat gets the final answer.\n\nIt does not get the thinking output.\n\nFor some products, that is fine. For debugging, evals, agent traces, and tool workflows, it is not fine.\n\nI would parse DeepSeek responses explicitly:\n\n``` python\ndef parse_deepseek_response(response):\n    choice = response.choices[0]\n    message = choice.message\n\n    return {\n        \"answer\": getattr(message, \"content\", None),\n        \"reasoning\": getattr(message, \"reasoning_content\", None),\n        \"tool_calls\": getattr(message, \"tool_calls\", None),\n        \"finish_reason\": choice.finish_reason,\n        \"usage\": getattr(response, \"usage\", None),\n    }\n```\n\nThat is not fancy. It is the minimum safe parser.\n\nThe point is not to show chain of thought to users. The point is to avoid silently losing fields that affect debugging, evals, and tool-call continuation.\n\nThis is the part I would not ignore.\n\nDeepSeek's thinking-mode docs distinguish normal multi-turn chat from tool-call workflows.\n\nFor ordinary multi-turn conversations, you do not need to pass prior chain-of-thought content back.\n\nBut when tool calls are involved, DeepSeek says the intermediate `reasoning_content`\n\nafter a tool call must be passed back in the following request.\n\nThat means a generic OpenAI wrapper can fail in a very boring way:\n\n`reasoning_content`\n\n.`role`\n\nand `content`\n\n.That is the kind of bug that does not always crash. It just makes the agent worse.\n\nHere is how I would decide what to implement:\n\n``` python\ndef deepseek_integration_plan(app):\n    if app[\"uses_old_model_names\"]:\n        return \"Migrate from deepseek-chat/deepseek-reasoner to deepseek-v4-flash or deepseek-v4-pro.\"\n\n    if app[\"uses_tools\"] and app[\"thinking_enabled\"]:\n        return \"Preserve reasoning_content across tool-call turns. Do not use a content-only wrapper.\"\n\n    if app[\"needs_json\"]:\n        return \"Use response_format={\\\"type\\\":\\\"json_object\\\"} and still validate the result.\"\n\n    if app[\"high_volume\"]:\n        return \"Start with deepseek-v4-flash and track cache hit/miss tokens.\"\n\n    if app[\"hard_reasoning\"]:\n        return \"Benchmark deepseek-v4-pro with reasoning enabled.\"\n\n    return \"Use Chat Completions compatibility, but parse DeepSeek-specific fields explicitly.\"\n```\n\nI like this tree because it avoids the biggest false choice.\n\nThe question is not \"Is DeepSeek OpenAI-compatible?\"\n\nThe question is \"Which compatibility layer are you depending on?\"\n\nTokenMix exposes DeepSeek through an OpenAI-compatible base URL:\n\n```\nhttps://api.tokenmix.ai/v1\n```\n\nThe live catalog currently lists:\n\n| Model | Reasoning | JSON | Tools | Streaming | Prompt cache |\n|---|---|---|---|---|---|\n`deepseek/deepseek-v4-flash` |\nyes | yes | yes | yes | yes |\n`deepseek/deepseek-v4-pro` |\nyes | yes | yes | yes | yes |\n\nThat is useful because you can route DeepSeek alongside OpenAI, Claude, Gemini, Qwen, GLM, and other models through one endpoint.\n\nBut the same caveat remains:\n\nOpenAI-compatible routing gets the request through.\n\nCorrect parsing still belongs to you.\n\nThe cost story is also easy to misunderstand.\n\nDeepSeek direct pricing separates cache-hit input, cache-miss input, and output tokens.\n\nTokenMix publishes catalog rates for routing through its endpoint.\n\nFor example, using the live TokenMix catalog rates I checked:\n\n| Model | Input / 1M | Output / 1M |\n|---|---|---|\n| DeepSeek V4 Flash | $0.132353 | $0.264706 |\n| DeepSeek V4 Pro | $0.419118 | $0.838235 |\n\nSo a 10M input / 2M output workload is roughly:\n\n```\nFlash = 10 * 0.132353 + 2 * 0.264706 = $1.85\nPro   = 10 * 0.419118 + 2 * 0.838235 = $5.87\n```\n\nThat makes Flash the obvious first route for high-volume tasks.\n\nI would only pay for Pro where Flash fails on your actual evals.\n\nIf I were shipping DeepSeek V4 this week, I would:\n\n`content`\n\n, `reasoning_content`\n\n, `tool_calls`\n\n, `finish_reason`\n\n, and `usage`\n\n.`reasoning_content`\n\nin thinking-mode tool workflows.That last point matters.\n\nOne endpoint does not remove the need for fallback.\n\nIt just makes fallback less painful.\n\nIf you want DeepSeek, OpenAI, Claude, Gemini, Qwen, GLM and other models behind one OpenAI-compatible endpoint, that is roughly what [TokenMix](https://tokenmix.ai) does. Disclosure: I work on the research side. Full cited breakdown is on the [original article](https://tokenmix.ai/blog/deepseek-response-api-protocol-2026).\n\nDeepSeek response compatibility is real, but it is not the OpenAI Responses API.\n\nTreat it as Chat Completions compatibility plus DeepSeek-specific fields. Parse `reasoning_content`\n\nintentionally, migrate to V4 model IDs, and do not let a generic wrapper quietly erase the data you need for reasoning, tools, and evals.\n\nHave you seen OpenAI-compatible wrappers drop provider-specific fields like `reasoning_content`\n\nor cache usage? How did you handle it?", "url": "https://wpnews.pro/news/deepseek-s-response-api-isn-t-openai-responses-that-one-parser-mistake-drops-the", "canonical_source": "https://dev.to/tokenmixai/deepseeks-response-api-isnt-openai-responses-that-one-parser-mistake-drops-the-reasoning-2818", "published_at": "2026-06-27 02:47:04+00:00", "updated_at": "2026-06-27 03:03:53.702203+00:00", "lang": "en", "topics": ["large-language-models", "developer-tools", "artificial-intelligence"], "entities": ["DeepSeek", "OpenAI", "DeepSeek V4", "deepseek-v4-flash", "deepseek-v4-pro", "deepseek-chat", "deepseek-reasoner"], "alternates": {"html": "https://wpnews.pro/news/deepseek-s-response-api-isn-t-openai-responses-that-one-parser-mistake-drops-the", "markdown": "https://wpnews.pro/news/deepseek-s-response-api-isn-t-openai-responses-that-one-parser-mistake-drops-the.md", "text": "https://wpnews.pro/news/deepseek-s-response-api-isn-t-openai-responses-that-one-parser-mistake-drops-the.txt", "jsonld": "https://wpnews.pro/news/deepseek-s-response-api-isn-t-openai-responses-that-one-parser-mistake-drops-the.jsonld"}}