back
288 comments
I'm not sure you need a "DeepSeek native coding agent" to take advantage of DeepSeeks cache, yesterday as the Codex quota usage issue still wasn't solved for me, I wrote a tiny little bridge so I could use DeepSeek V4 Pro via Codex, and seems most of everything I did was basically cached as far as I can tell: https://i.imgur.com/7eKn6wN.png (2026-05-23 Input (Cache hit): 39,123,200 tokens, Input (Cache miss) 1,692,286), and the bridge is doing not special, just massage the DeepSeek API shape into what Codex expects, nothing particular about caching at all.

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.

This would be a better page to link to https://github.com/esengine/DeepSeek-Reasonix/blob/main/docs...

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.

Opencode has really bad cache stability issues that they seem uninterested in fixing at the moment.
Yep exactly my thoughts, went and looked at the code for the deepseek provider in my coding agent. and basically all of what the author wrote there is implemented... http://github.com/tontinton/maki for the curios
> I wrote a tiny little bridge so I could use DeepSeek V4 Pro via Codex

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.

this appears to be native to the terminal, as in, there's no special application that runs or wraps an agent inside a tui. So basically instead of commands you type plain english?
This website seems to have been generated by Codex - I asked Codex to create an HTML overview of a feature for my team and it made an overly produced monstrosity - complete with the same large stat boxes that were for the most part devoid of meaningful information - using the same font, colors, layout, hero section, etc. It was also terrible on mobile just like this is.

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.

A lot of LLM-driven design now looks like this. I don’t understand how people don’t find ugly the pairings with an heavily italicised serif. You also can’t read much of the page on mobile, because the code example keeps shifting the content around.

Now, that is overly critical, I’m sure their heart is in the right place. But a simpler website would do :)

> 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.

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.

Claude Opus 4.7 defaults to exactly this design language for a lot of "just make me a rich html presentation page" requests without further specification.
strange, I got the same design with claude design, same fonts, same title designs with the strange character etc...
As someone who has been writing harnesses for a year: the people at opencode etc aren't stupid, when they decide to break the prefix cache [usually partially] it's always because they've tested it and it gives better results overall.

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.

Not a fan of that page. The animated typing and resulting continuous resize of the example keeps moving the content beneath it down and up. Such bad UX.
If only author would understand, that some people want single, self sustained binary that doesnt take half of computer memory and would rather write it in rust or golang.
It's pretty funny, i'm a $200/m Claude subscriber and i've had little need to use anything else. However the more Claude has been restricting my workflow (notably around the recent IDE/-p usage change) the more i've been wanting to go elsehwere.

I'm concerned since i really want SOTA reasoning, but DeepSeek still has me interested.

I love the focus on cache hit efficiency. Hats off to the deekseek team for creating a great product that maximizes cost efficiency for the user.
Unusable thanks to the top animation pushing the rest of the site down repeatedly as you’re trying to read.
Okay, I'm curious.

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?

> no reordering, no marker-based compaction

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.

I would've liked benchmarks against other harnesses showing the caching performance
Maybe the first problem this tool can tackle is creating a better web page? Content continually shifting, super annoying.
Performance is horrible when you type but caching is magical.

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.

The prevalence of chinese training datasets has likely biased the model incorrectly. The model is still intelligent enough to flag this as a gap in its own abilities.

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.

High caching rates for coding agents can drastically reduce latency and API costs. I am curious to see how the caching strategy handles context invalidation across multiple files.
God, I whish there was a code harness I don’t have to install a JavaScript runtime for
Side note: In DeepSeek API docs they mention that coding clients automatically are assigned the highest thinking effort, despite any settings. This is what I suspected when using OpenCode with V4; it keeps reasoning in very long cycles, this felt like a flaw in the model. May just be a weird API thing.

Overall I find their API design and docs so messy. It's a shame, since it's the main entrypoint to using their service.

> The loop is append-only, engineered around DeepSeek's byte-stable prefix cache — long sessions hold 90%+ cache hit and input-token cost collapses to ~1/5. Terminal-first, leave it running.

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.

So what's best low cost coding agent these days? Kimi 2.6? Qwen's latest closed model? Composer 2.5? DeepSeek?
I don't think it's helpful, you can already get a 99+% cache hit on claude code, just change the api settings to deepseek. I would like to use a agent built by deepseek itself using deepseek models. Deepseek should make their own agent based on their model, just like OpenAI and Anthropic.
Doesn't Pi Agent do exactly this? Assuming "append only" means they do some kind of compaction as well.
Well folks here we have it: DeepSeek’s brand is now strong enough people want to jump on their brand recognition.
Can it instruct DeepSeek during an LLM call to start removing old tool calls from the context instead of waiting for the LLM call to finish if the context size approaches DeepSeek's dumb zone? Claude Code can't do that, /compact can only happen after the LLM call; it's often preferable to start cleaning up context during an LLM call, especially when tool calls are huge like reading markdown files; implementation-wise all that is needed is to start removing earliest <tool call start> ... <tool call end> and replacing them just with some log entry stating this tool call was already performed, then re-running KV cache prefill (so the "online" compaction would get 0.5s latency hit every time it's performed). That way one can read 1000 files in one LLM call.
I tried it and the text input area was black with a dark font. I checked the documentation, and asked DeepSeek v4, Claude, and Gemini for help with the fonts/style and nothing works except to run in a terminal with a dark theme. Crazy. None of the devs on the project use a light theme?
Good timing given the cost spike across other frontier models.
This is a nice companion to the token saving context app I made. Even has the same Claude Design site, which I think looks awesome! Even though something is cheap, the concepts that make using Deepseek more efficiently can surely be applied elsewhere. Cool stuff!
Isn't caching a server-side thing? How does the agent affect it, significantly at least?
What AI model did you use for the website design? This is the second one I see with the exact same font and color scheme. Just curious because Claude models lean towards purples for example. Thank you!
Wow the UI looks exactly what I vibe coded yesterday. What a coincidence
In the open-source contributors section, when you see a lot of anime or cartoon avatars, you know most of the devs are Chinese.
> Tool-call repair

> 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?

It's probably good, and the best for Deepseek models, but do we really need one harness per model?
Can someone give me a eli5 version of what this is? It really sounds useful to Claude subscribers.

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?

i cant find anything substantiated in the code that actually differentiates it from any other harness.

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

For those of you that use deepseek v4 occasionally, what harness do you use it with? I’m only familiar with claude code and codex.

Any comments on what you can or cannot rely on it for relative to cc and codex would be appreciated too!

The caching strategy here looks really solid for keeping API costs down. Curious how it handles state invalidation when the agent context gets too large though.
This is not an agent by DeepSeek, so the title is misleading.
I don't think it's particularly effective to create a new coding agent when there's existing open-source agents (especially extremely extensible ones like Pi) that already optimize for cache hits, have far larger communities, and work for providers other than Deepseek.

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.