DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost
esengine.github.ioDeepSeek makes the V4 Pro price discount permanent - https://news.ycombinator.com/item?id=48237663 - May 2026 (384 comments)
DeepSeek makes the V4 Pro price discount permanent - https://news.ycombinator.com/item?id=48237663 - May 2026 (384 comments)
Besides being even better at the caching, I'm not sure what benefits you'd get compared to just firing up OpenCode with the DeepSeek API yourself, it'll similarly do caching for sure and also "talks directly to api.deepseek.com" if that matters, and you'll get a much more mature harness.
They explain some of the the reasons why they have a better solution and why they are very opinionated
>Automatic prefix caching activates only when the exact byte prefix of the previous request matches. Most agent loops reorder, rewrite, or inject fresh timestamps each turn — cache hit rate in practice: <20%.
So they optimize on this plus other techniques to improve cache hits, making it cheaper.
Can you share the bridge. DeepSeek v4 is awesome paired with claude-code or opencode. I found that claude code costs me less than opencode and I am presuming this is due to a better engineered harness.
In the end I had Claude produce a one-page html file that was 95% of the way there and it took minor editing to clearly explain the intent of the feature.
Now, that is overly critical, I’m sure their heart is in the right place. But a simpler website would do :)
That doesn't say much about any model though. For starters, any software engineer can tell you that leaving out features can drastically simplify any project.
If you think that dsv4 behaves differently enough from the aggregate of other models, submit a PR with a patch to special case that to your harness of choice with evidence. Just blindly assuming "append only all the time because cache" is a waste of everyone's time.
I'm concerned since i really want SOTA reasoning, but DeepSeek still has me interested.
From the FAQ, I see:
>Can I point it at a self-hosted / private DeepSeek endpoint?
>Yes. Since 0.30 we accept non-standard key prefixes for self-hosted DeepSeek endpoints. Just point `baseUrl` at your internal address — the loop, cache strategy, and tool protocol are unchanged.
But my question is: If I use Reasonix to talk to a deepseek endpoint through openrouter, am I still getting the cache-hit benifits of this agent harness?
Is this really the behavior you want? Yes, doing tool-result clearing and such will blow your cache, but if you do it only occasionally, it's still likely a win. Yes, cache hits are good, but not so good that it's okay to be profligate with context to preserve those precious, precious KVs.
Extremely pro consumer tool. I have been hammering it hard with 97% cache utilization and barely $0.03 dollar spent for me constantly exploring a codebase.
Here is an example of Reasonix resuming a feature in a project managed by Codex thus far.
> ● reasoning · 107 tok · 2 ¶ · 3.2s v4-flash ↳ The search engine is still completely broken - returning Chinese dictionary entries, Kick streamer profiles,… c. It's not just broken for ** content, it's broken for everything. The error from earlier said to switch … ⋯ 2 lines elided I need to be honest with the user that `web_search` is fundamentally non-functional regardless of what query I try. Let me clearly communicate this and suggest alternatives.
‹ reply 198 tok · 92 t/s v4-flash I'm sorry — I've now tried multiple queries across multiple attempts this session, and the web_search tool is fundamentally broken regardless of query phrasing. Every single query returns either Chinese dictionary entries, Kick streamers, YouTube homepages, or Swiss restaurants. Nothing even remotely related to the search terms.
The error message from the tool itself says:
"switch engine with /search-engine bing|searxng|metaso|tavily|perplexity|exa"
This is a user-side setting — I can't change it with any tool I have. Could you run this in chat?/search-engine bing
That would switch from the current broken Chinese-language engine to Bing (or one of the others like perplexity ). Once that's done, I'll batch-search all 322 centers efficiently — the web_search tool is the fastest way to do this since I can search multiple names in parallel.
Overall I find their API design and docs so messy. It's a shame, since it's the main entrypoint to using their service.
AI marketing slop. This is how all models and coding harnesses work, isn't it?
The author claims (in another AI-written post):
> LangChain — along with every generic agent framework I checked — rebuilds the prompt every turn. Timestamps get injected. History gets reordered. Tool schemas re-serialize with different whitespace.
I haven't touched LangChain in a long, long time, but don't think any of the current harnesses, Claude Code, Pi, Crush, OpenCode etc do that except if you change configuration? Keeping the context stable for caching is a very basic principle and not a wild innovation.
This posing as DeepSeek-specific is also a mystery.
> Tool arguments the model produces occasionally have JSON typos, unclosed quotes, or shape mismatches. Reasonix runs a schema-aware repair pass before dispatch so malformed args still execute.
So Deepseek API doesn't have a structured output option where you give a grammar and the model promises the output will follow this grammar?
Or it does, but it's buggy?
Is this improving the cache hit and hence overall efficiency of coding workflows?
Does it also let me host a local llm (deepseek)? What are model min requirements for this?
my fork of oh my pi that i have a lot of experiments in, is lterally designed to only work well with models that have decent reasoning levels, like deep seek models. check it out!
https://github.com/cartazio/oh-punkin-pi/blob/main/scripts/b... — thats the install script for after clone
fair warning: tis my dog food test bed as i build even fancier stuff
Any comments on what you can or cannot rely on it for relative to cc and codex would be appreciated too!
I specifically use multiple different models and providers, so this wouldn't be useful for me.
And it contributes to the problem of each person vibe-coding their own, incompatible, half-baked tool in a space, instead of contributing to a small set of tools and expanding them.
It'd be better to just extend an existing tool.