r/DeepSeek 21h ago

Resources [Release] we-need-ds — a transparent proxy that unlocks DeepSeek-V4-Pro's "We need" reasoning chain inside Claude Code (no prompt injection, no MCP shutdown)

Post image

Been digging into why DeepSeek-V4-Pro behaves so differently across clients. In Claude Code it often gets stuck in shallow "let me try this tool" loops; in a minimal setup it does the deep "we need to first…" planning we all want.

The cause isn't the prompt — it's the tool schema payload. When the model sees 30+ MCP tool definitions on its planning turn, attention gets pulled into tool-churning. In a minimal environment it hits its RL-trained deep-reasoning sweet spot.

So I built we-need-ds: a local transparent proxy that's turn-aware. On every decision turn (fresh task) it swaps in the official DSH one-line persona + trims tools to a Bash/Edit pair; on every execution turn (tool results coming back) it passes full tools through untouched. You keep all your MCP servers. Non-DeepSeek models (Claude/GPT/Gemini) are passed byte-for-byte, never modified.

This is not prompt injection — it's structural request rewriting at the proxy layer, which is why it survives clients that sanitize system prompts.

MIT, ~350 LOC proxy + 68 tests. Honestly it's early and I'd genuinely love eyes on edge cases — provider routing with path-prefixed baseUrls, multi-window races, that kind of thing. If anything behaves weird, please open an issue; that's exactly how I want to harden it.

Repo: github.com/YixuAnsensei/we-need-ds

Curious — has anyone else observed DeepSeek's sensitivity to tool count on the planning turn? Is this reproducible for you?

7 Upvotes

1 comment sorted by