Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

DeepSeek Harness developer preview

deepseek.com

Post reply on HN
Print view View original

211–220 of 346 posts

Re: DeepSeek Harness developer preview

#211

Post by alienbaby »

francislavoie wrote: post #28
rco8786 wrote: post #17

But like, what is it? Odd that this reached #1 on HN. The README is pretty bare outside of installation instructions and a link to "Cordis", which is "A Meta-Framework of Spatiotemporal Composability." and "under active development. The API is not yet stable and may change without notice.".

A "harness" is basically what you call Claude Code and such, i.e. a TUI to run the agent.

A harness is any wrapper around llm calls that manipulates llm interactions to achieve the process for which it is designed. Claude code et al are just one type of harness, focusing on writing code. The kind of UI used to interact with the harness and underlying models does not matter.

Re: DeepSeek Harness developer preview

#212

Post by mickeyp »

kamranjon wrote: post #33
rco8786 wrote: post #17

But like, what is it? Odd that this reached #1 on HN. The README is pretty bare outside of installation instructions and a link to "Cordis", which is "A Meta-Framework of Spatiotemporal Composability." and "under active development. The API is not yet stable and may change without notice.".

New coding harness that seems to have some novel concepts and one of the pretty cool things on their landing page for it here: https://deepseek.com/harness/en/ is the Every Run is Traceable view: "Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records…

I'm glad they're doing this also and that more people are adopting it. Event sourcing [0] is the right way to represent informaiton like tool calls, user interactions, etc. --- it makes it easy to fork conversations and maintain a cohesive conversation stream and stable message history that does not break the cache.

[0] https://www.dreamcoder.ai -> scroll down to the event graph.

Re: DeepSeek Harness developer preview

#213

Post by alienbaby »

schafberg wrote: post #120
flaburgan wrote: post #73

Is there a comparison of harness somewhere? Like, the same prompt to the same model, but with different harnesses, and comparing the quality of the results. I am trying to run as much as possible only on free software, so I always only used Zed plugged with anthropic models, but I am wondering what is the quality of Zed harness compared to the one of claude code or pi or others... I would love some feedback.

I want to have the same thing, but tbh it's too complicated with so many configuratios and plugins. I doubt if any comparison of harness make sense now and can be applied in real coding works.

Can't that be sidestepped by comparing harnesses 'out of the box'

Re: DeepSeek Harness developer preview

#214

Post by mring33621 »

mring33621 wrote: post #101

I just installed DeepSeek Harness with the latest Bun version and am using it with a local 9B, speculative decoding Qwen 3.x variant, running in llama.cpp and it works GREAT for small python projects, so far. It was very easy to connect the harness to the local model and it seems to run quite fast, compared to other harnesses that I have tried.

Sadly, it doesn't ship with support for "dsh --profile acp"

Re: DeepSeek Harness developer preview

#215

Post by badlogic »

lxdlam wrote: post #58

I have read the underlying paper, and found it may be useful, but not that useful. For those who want to know what it achieves: it adds hot-reload and dynamic enable/dispose capabilities to a plugin system, like the one in Pi agents, though they push the boundaries further, to the UI components and so on. For those who want to know what it does: if you have some PLT knowledge, ask your agent to explain the algebra to…

just read the paper, and there aee definitely some interesting ideas in it.

a plugin's registrations returning individual cleanup handlers is nice. in pi, you clean up all registrations in one go in the session-shutdown handler.

i also like the use of generator to to clean up partial registrations nicely.

the cross-plugin dependency injection and resolution i'm not so sure about. it comes with a lot of footguns and limitations as pointed out in the paper.

works ok within a single compilation unit, i.e. a plugin with many modules. does not help with typing of cross-plugin dependencies.

most plugins do not have dependencies on each other, so this more complex system doesn't win you much, e.g. with load order and conflicting registrations (i.e. two plugins registering the same tool).

being able to reload a single plugin on change while letting the others not in its dependents list jug along is neat. but that also only works if plugins actually declare dependencies (see last paragraph), and also has a lot of limitations. and the simple case, a plugin with no dependencies or dependents, which i'd say is the 90% case, does 't need that complexity either.

definitely cool stuff tho! remains to be seen how well it works in a real plugin ecosystem.

> they push the boundaries further, to the UI components

can you elaborate on this? pi extensions support contributions to the UI. in pi v1, they are limited to in-process UI. v2 splits server and client, and with that UI.

Re: DeepSeek Harness developer preview

#216

Post by miroljub »

SwellJoe wrote: post #175

"Every run is traceable Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records by source. Resume, fork, search, and replay all operate on the same event stream." That's a killer feature, IMHO, and one that US models won't allow you to do, as their tra…

How is that different from what Pi already does?

Re: DeepSeek Harness developer preview

#217

Post by LeBit »

game_the0ry wrote: post #203
LeBit wrote: post #157

Earlier quoted context omitted.

I always thought nodejs was a weird choice for CLI tools. For web stuff, sure. But for CLI, it never made sense to me. Especially when Python and Go exist.

> But for CLI, it never made sense to me. Especially when Python and Go exist. But why? Not saying node is better, just want to know where you are coming from for my own knowledge. Bc I would have picked typescript + node too. It has types (where python just has type hints) and a lot of developers know it already (where go is more niche).

I guess the reasons are that I feel (no data to back this up) that having a Python runtime available is much more probable than having a nodejs runtime around.

I was going to say you cannot easily distribute a nodejs based CLI app, but that’s of course not true. devcontainer-cli is a nodejs app and so are many of the coding agent harnesses.

Yeah, thanks for pushing back. I guess my view was irrational.

Re: DeepSeek Harness developer preview

#218

Post by rescbr »

cmrdporcupine wrote: post #128
rescbr wrote: post #94

Earlier quoted context omitted.

The JVM has a fixed size heap which for me it is wasteful. IMHO, Microsoft made the correct approach on .NET. For LLMs, I prefer C# and C++ instead of TypeScript, JavaScript or Python as the static + compiled language factor keeps the coding agents on track. Plus, they have a true threading/async implementation.

It's only appearing wasteful if you're not understanding how memory management works on modern operating systems. It's not wasting any RAM at all if you pay attention to RSS vs VSS. The actual physical RAM is still entirely available to other applications. It's just made the OS know it might want that many pages. Until there's data in the pages, they will not count towards total RSS. It's the kind of things some sysa…

I know how mmap works. The JVM is/was terrible on freeing allocated memory though.

If the program is actively using that allocation, that's fine. My problem is with the runtime hoarding RAM when it should have been freed after GC back to the OS.

Then there's also the JVM not handling peaks well because it hit the max heap size, while you still could rely on the OS doing its job to shuffle stuff to swap temporarily. I still see JVM OOMs in my $dayjob's product while the OS has plenty of free physical memory. It is stupid.

I mean, we have malloc() and free(), they are in the stdlib for a reason :)

The JVM seems to follow a philosophy where it assumes it is the only process running besides PID 1, which is valid for some scenarios, but not for others.

Re: DeepSeek Harness developer preview

#219

Post by RussianCow »

Wowfunhappy wrote: post #80
syntaxing wrote: post #5

Is there a reason why so many of these agent harness are written in node.js?

Because: 1. The first significant agentic harness was made by Anthropic. 2. One of the most senior developers of client-side software at Anthropic is Felix Rieseberg, one of the original creators of Electron. [1] 3. After Claude Code blew up, everyone else copied Anthropic. --- 1: https://daringfireball.net/2026/07/claudes_criminally_bad_ma...

I think it also helps that it's basically the default platform for any software that AI writes, unless you tell it otherwise. And JavaScript is one of the most widely used and well known languages in the world, so there's that, too.

Re: DeepSeek Harness developer preview

#220

Post by SwellJoe »

miroljub wrote: post #216
SwellJoe wrote: post #175

"Every run is traceable Everything the model sees is recorded in an append-only session log: system prompts, reasoning, tool calls and results, subagent scheduling, and every context injection. In the Trajectory view, you can inspect these records by source. Resume, fork, search, and replay all operate on the same event stream." That's a killer feature, IMHO, and one that US models won't allow you to do, as their tra…

How is that different from what Pi already does?

Pi can only log what the model shows it. Many models keep their thinking traces hidden and only provide a hash or something to recover it on subsequent resumes. DeepSeek shows CoT traces, and is maybe the best model that does so, I think? Kimi stopped providing CoT traces a little while ago in their subscription service via Kimi Code, I believe. I haven't checked GLM or Qwen 3.8 Max, though I guess if you're hosting the open models yourself or using an alternative inference provider there's probably got to be some way to get at that data.

Anyway, this particular harness isn't doing anything unique, but the combination of an official agent intentionally keeping the data and making it accessible to the user and a model API that provides all the information is unusual and worth calling out. It used to be common, most APIs and models and agents showed the reasoning, or could be configured to do so. Most no longer offer it.

Post reply on HN