DeepSeek Response API и OpenAI Responses: как парсер теряет reasoning

OpenAI-совместимый транспорт не гарантирует полную семантику ответа reasoning-модели: если клиент читает только message.content, поле reasoning_content исчезает из цепочки — вместе с chain-of-thought, eval-трейсами и продолжением tool-call сценариев. разбор на Dev.to фиксирует типичную ошибку парсера и сверку с документацией DeepSeek V4.
Почему reasoning_content важнее финального content в агентных пайплайнах
Reasoning-модели отдают промежуточное рассуждение отдельным полем — choices[0].message.reasoning_content, на одном уровне с content. Для vibe coding и агентов, где важен не только ответ пользователю, но и ход мысли между вызовами инструментов, потеря этого поля не всегда бьёт по HTTP-статусу: запрос формально успешен, а контекст деградирует.
В usage ответа может появляться completion_tokens_details.reasoning_tokens — отдельный счётчик токенов рассуждения. Игнорировать его вместе с reasoning_content значит строить метрики и логи только по «видимой» части ответа.
Совместимость endpoint'а и совместимость полей ответа — разные контракты. Первое не спасает от второго.
Chat Completions DeepSeek — не OpenAI /responses
DeepSeek документирован как OpenAI-compatible на слое /chat/completions (base URL https://api.deepseek.com). Это не то же самое, что OpenAI Responses API на маршруте /responses: в разборе подчёркивается, что DeepSeek не позиционируется как совместимый с /responses.
Актуальные идентификаторы V4 — deepseek-v4-flash и deepseek-v4-pro. Имена deepseek-chat и deepseek-reasoner остаются compatibility aliases, но в официальной документации им назначена deprecation 24 июля 2026, 15:59 UTC — миграция на V4 IDs имеет жёсткий горизонт.
Ошибка парсера: читать только content
Типичный сбой — на клиенте: парсер берёт response.choices[0].message.content и не извлекает reasoning_content. Слой HTTP здесь ни при чём; ломается обёртка или SDK, заточенный под «универсальный» Chat Completions.
Минимально безопасный подход — явно собирать все нужные поля:
msg = response.choices[0].message
content = getattr(msg, "content", None)
reasoning = getattr(msg, "reasoning_content", None)
tool_calls = getattr(msg, "tool_calls", None)
finish_reason = response.choices[0].finish_reason
usage = response.usage
Класс generic content-only wrappers — те, что в историю диалога кладут только role и content — часто молча отбрасывают reasoning_content. Конкретные библиотеки по имени в источнике не перечислены; речь о паттерне, а не о единственном виновнике.
Как tool workflows «тихо» ломаются без reasoning_content
Сценарий из разбора — пять шагов:
- Обёртка получает ответ с
reasoning_content. - В историю сохраняются только
role+content. - Модель вызывает tool.
- Следующий запрос уходит без промежуточного reasoning.
- Контекст tool workflow теряется — пайплайн не обязательно падает, агент просто работает хуже.
Официальная документация DeepSeek для thinking mode ужесточает правило: при tool calls промежуточный reasoning_content assistant должен участвовать в контексте и передаваться на всех последующих user-turns. Если его не хватает, API отвечает 400 — явный сигнал, в отличие от «тихой» потери в content-only обёртке.
Рекомендуемый паттерн — добавлять в messages целиком объект response.choices[0].message, включая reasoning_content и tool_calls.
Gateway TokenMix: маршрутизация без снятия ответственности за парсинг
Автор разбора (tokenmixai) сверял DeepSeek V4 docs и каталог TokenMix; указывает affiliation с TokenMix («research side»). Relay даёт OpenAI-compatible endpoint https://api.tokenmix.ai/v1 и модели deepseek/deepseek-v4-flash, deepseek/deepseek-v4-pro с флагами reasoning, JSON, tools, streaming и prompt cache в live catalog.
Маршрутизация через multi-model gateway не отменяет клиентский контракт: корректный парсинг полей провайдера остаётся на стороне вашего кода.
Тарифы каталога в посте (input/output за 1M токенов: Flash — $0.132353 / $0.264706, Pro — $0.419118 / $0.838235) приведены автором на 27 июня 2026; актуальность цен на дату чтения отдельно не проверялась.
Чеклист для продакшен-агентов
Что стоит зафиксировать до выката:
- Парсить явно:
content,reasoning_content,tool_calls,finish_reason,usage. - В thinking-mode tool workflows сохранять и пробрасывать
reasoning_contentмежду ходами — не content-only history. - Учитывать cache hit/miss tokens в usage.
- Не строить новый код на legacy model names; перейти на V4 IDs до 24 июля 2026, 15:59 UTC.
- JSON mode — только с явными инструкциями в промпте и валидацией результата.
Потеря reasoning_content — не абстрактный баг парсера, а риск для любого стека, где OpenAI-совместимый клиент подменяет полный ответ урезанной схемой. Проверка контракта полей стоит той же строки кода, что и выбор модели.
Источники
- Разбор tokenmixai на Dev.to: Dev.to (доступ 2026-06-27 UTC)
- DeepSeek API documentation: https://api-docs.deepseek.com/ (доступ 2026-06-27 UTC)
- DeepSeek reasoning model guide: https://api-docs.deepseek.com/guides/reasoning_model (доступ 2026-06-27 UTC)
- DeepSeek thinking mode guide: https://api-docs.deepseek.com/guides/thinking_mode (доступ 2026-06-27 UTC)
- TokenMix models catalog: https://tokenmix.ai/models (доступ 2026-06-27 UTC)