WorkBuddy DeepSeek Reasoning Proxy

Problem: WorkBuddy drops reasoning_content in multi-turn calls

DeepSeek's reasoning mode requires reasoning_content to be passed back on multi-turn API calls. If the field is missing, DeepSeek may return an error such as “The reasoning_content in the thinking mode must be passed back to the API.” In WorkBuddy’s Agentic mode, spawning sub-agent or assistant-message assembly can lose that field, breaking deepseek-v4-pro thinking-mode conversations.

Approach: a local proxy that caches and re-injects reasoning content

The skill does not change the model itself. It inserts a local HTTP proxy between WorkBuddy and DeepSeek, with deepseek_proxy.py as the core component. The behavior is intentionally narrow:

• Intercept requests: WorkBuddy sends requests to a 127.0.0.1 proxy port instead of calling DeepSeek directly.
• Inspect assistant messages: If an assistant message lacks reasoning_content, the proxy restores it from a cache keyed by message position.
• Forward the real request: The completed request is forwarded to api.deepseek.com.
• Cache reasoning output: After the response returns, the proxy extracts reasoning_content and stores it by assistant-message index for later turns.
• Support response formats: Both streaming SSE and non-streaming JSON responses are handled.

The helper tools deepseek_tool.py and 启动深度思考.bat start the proxy, update ~/.workbuddy/models.json, and switch back to direct mode. Prerequisites include an existing deepseek-v4-pro config, a valid API key, and Python 3.7+ standard-library support. The intended boundary is local WorkBuddy-to-DeepSeek usage, not public deployment, gateway authentication, or multi-tenant isolation.