Live data from Hacker News

DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

esengine.github.io

51–60 of 325 posts

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#51

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…

Yes*. At least from my limited usage of deepseek-flash for a few billion tokens on openrouter, the cache-hit rate is >95%. And I simply used the claude code harness pointed at the openrouter anthropic compatible endpoint with no fluff.

thank you!

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#52

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!

Frontend design skill by Anthropic specifically says not to use purple. I'd be surprised if it still uses purple. Have you seen that recently?

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#53
post #31

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,28…

Opencode has really bad cache stability issues that they seem uninterested in fixing at the moment.

[flagged]

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#54
post #36
post #5

Earlier quoted context omitted.

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

I’m feeling more a novice every day, but how isn’t this just handing over your code to team deepseek for whatever they might want

You’re not a novice, there are a lot of us who know exactly what we are doing and see this as a huge downside. We are just being told to go faster, faster, faster lest we miss out on… something?

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#55
post #15

Earlier quoted context omitted.

I've gone through ~600m tokens in Xiaomi Mimo though Claude, and it's been the most effective use of an agent I've had yet. It's very capable, but generally not ambitious, picking simple but effective solutions to most problems I give it. Going to write something longer about the experience when I get to a billion tokens.

Are you using Mimo 2.5 pro?

Yes. I tried a couple of weeks with non-Pro, and it was pretty good, but I had too many spare tokens, so I switched back to Pro. :)

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#57

Earlier quoted context omitted.

> Isn't it just a matter of not changing the previous context? Yes, but a lot of harnesses change previous context. E.g. the system prompt injects the current time/date, working directory, files in the working directory, etc. Compaction also changes the whole previous context. I _think_ changing the list of tools also invalidates cache, so invoking a subagent with different tools would invalidate the cache. My vague…

changing between plan/build mode in some agents will change the tools list, which breaks the cache.

Cache is always there, it’s just that it only caches up to the point where an input token changes. So if the tools list is early in the prompt, changing it would limit cache for most of the prompt. If the tools list is the last thing, you could still get 99% cache hits even if it changes every turn.

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

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

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#59

Earlier quoted context omitted.

Say you put the current time down to the second in the system prompt, which is the message that goes in front of the entire conversation, then basically nothing will be cached, every agent turn needs to ingest the entire session over and over. Contrast to not doing that, and the backend can leverage caching all the way up to the latest message, as nothing until then changed.

Surely other agent CLIs are not dumb enough to invalidate cache on every turn over something so obvious?

Probably not that exactly, but there is a tradeoff between effectiveness of the prompt and cache hit rate. If putting the user’s datetime in the middle of the prompt scores higher on evals but worsens cache hits, versus at the end of the prompt where it’s cache friendly but may not be as effective, what do you do?

This is still art as much as science and the different harnesses take different approaches.

Re: DeepSeek reasonix, DeepSeek native coding agent with high caching and low cost

#60

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.

Adding already cheap API cost and you probably could let it run for days and the same task..
Post reply on HN