Live data from Hacker News

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

esengine.github.io

281–290 of 325 posts

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

#281

Earlier quoted context omitted.

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: So they opt…

>Most agent loops reorder, rewrite, or inject fresh timestamps each turn That's really surprising, since it'd defeat the whole point of KV caching. I mean I buy it considering how sloppily coded the harnesses seem to be, but this like obvious low hanging fruit. I've also often wondered why LLMs aren't trained with a format of having a dedicated contextual system-instruction role at the _end_, which you could use to p…

Its not surprising, that doc is full of AI slop.

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

#282
post #151

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.

github.com/charmracelet/crush The company that had that acrimonious split from OpenCode. Still, fully written in Go and compared to node-based harnesses, uses 1/5th the RAM. (At least for me.) Works with any provider (including OpenRouter free ones). No conflict of interest here, just a happy "customer" of this excellent resource.

it's a 404

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

#283
post #282

Earlier quoted context omitted.

github.com/charmracelet/crush The company that had that acrimonious split from OpenCode. Still, fully written in Go and compared to node-based harnesses, uses 1/5th the RAM. (At least for me.) Works with any provider (including OpenRouter free ones). No conflict of interest here, just a happy "customer" of this excellent resource.

it's a 404

https://github.com/charmbracelet/crush (Haven't used it, but also hit the 404 and wanted to see it)

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

#285
post #261

Earlier quoted context omitted.

Did you read the OP when he's exactly chiding the model you're glazing?

Did you intentionally miss the point of my comment? Substitute Opus for GPT-5.5 if you will. I use both as well as locally hosted models using some of your branches, even.

Fair enough. I agree with you - although DS4 Pro is a GPT 5 class model which scores 46% on ARC-AGI-2[^1]. It's behind by maybe 9 months, I think it's still good enough for a lot of complex tasks as well. They definitely need to work on a "just fucking works" harness like CC/Codex. Also thanks!

[^1] https://www.nist.gov/news-events/news/2026/05/caisi-evaluati...

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

#286
post #164

Earlier quoted context omitted.

It’s sad to see companies not spending a bit more on design. Sure, ai will help you get something decent out fast. But there’s a threshold where design becomes an indicator of trust. Especially for b2b software that tailor to large corps. Good design, character, adds directly to the bottom line.

> It’s sad to see companies… The article is about an open source agent harness, Reasonix, that is built to leverage the DeepSeek native api. There’s no company here. No design budget. These people are graciously sharing a project they made in their free time.

You're right, but I find as a solo engineer it's still important to check the frontends I create on mobile

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

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

There are some that are specific to certain models like qwen/gemma

I switched to vLLM and those went away. Need to look at my opencode config and adjust some others based on things I see here

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

#288
post #74

Earlier quoted context omitted.

> Ah, reminds me of good old "There are only 2 hard problems in computer science: cache invalidation, naming things, and off-by-1 errors." You quip, but LLM KV caching (from the harness side) is quite easy: You get a cache hit on stable prompt prefixes, period. That means you want to keep the prefix stable, and only append at the end of the conversation. Made up example: Don't put the git branch name into the system…

That sounds like the experience of writing Containerfiles; since steps are cached you want to pull the thing you are iterating on as far down as possible.

It's even closer to prefix matching on super long strings by chunk

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

#289
post #68

Earlier quoted context omitted.

That'd be really easy to spot and also fix, most likely. Any open issue you could point us to, must surely been reported already?

Opencode (and other coding agents) have hundreds of open issues reported. It is quite discouraging when they are not being closed/fixed.

These projects have also been the recipients of PR spam, lots of duplicates and unconfirmed in there for less technical people and clawd operators

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

#290

Earlier quoted context omitted.

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: So they opt…

The last time I heard about something like this, it was Claude Code intentionally injecting random strings to break caching when you're not using a Claude model. Aside from that kind of intentional sabotage, I don't think any coding agent would just ignore prefix caching.

I haven't heard about this, could you please share more info, some reference on that Claude Code intentional bug?
Post reply on HN