Hi I'm one of the authors of DeepSeek Harness. It's just an early developer preview version we're presenting in MIT license currently. Expect lots of rough edges and compatibility-breaking changes. Any feedback and suggestions are more than welcome!
The best kept secret in AI training. Tianyi, since you are our insider. When you walk by the training teams office - how often do you see Pelicans on their screens?
Sorry for the off topic question. You've been on hn a long time + work at deepseek which seems pretty uncommon. Anything you think hn doesn't know about deepseek that it should? Or any non-obvious ways hn/yc has influenced deepseek (or the broader ecosystem)?
> Anything you think hn doesn't know about deepseek that it should?
We do hire people who are currently located outside of China (say North America, Europe, or anywhere) if they're open to work in our Beijing or Hangzhou offices.
Not exactly sure why that wouldn't be the default assumption. It's a pretty small subset afaict. Seems like size 1 before 2024 from a brief search.
Presumably more people there have read hn at least some. But there's perspective having seen the ebb and flow of hn/the rest of the ecosystem for the last 16 years and how that intersects with deepseek culture.
It's clear openai culture is influenced by yc culture, which would be clear to an hn user. Google/ant/spacexai have influences hn users users would be familiar with. Hn users from them would potentially know the friendfeed connections to yc/vc/openai, 500 startups/techstars etc..
It *is* a small subset, but I don’t see what’s so surprising. HN is just an ordinary tech community; it’s not surprising for people from any tech company to show up there.
I'm pretty sure the subtext of what I commented on was that he was surprised.
Your friends probably wouldn't go out of their way to ask you why you ordered a takeaway pizza which is uncommon. But if they did ask, it usually means they were surprised.
By MIT currently, do you mean it will eventually change to a different OSS license, or it may become a closed source product? That latter would be rather sad...
I really like the json schemas around the tool calls. Much stricter validation than in codex.
Git might be worth adding to the top level. Currently you've got LSP, grep, glob nicely structured for non-mutating queries across a codebase, but git is behind bash and that means hope or sandboxing.
Thank you for uploading it. Gives a lot of insight into how the deepseek models might expect tool calls to be structured.
I don’t like it. Structures responses really do not work well with LLMs at all. They are one of the biggest causes of issues with tool calling right now.
one question is that do you think in the future harness would become more simpler and its behavior should match a guideline or we would add more complexities to make it more robust? Is it important to use the same harness for RL and inference?
I just started testing, but didn't figured out if it already support MCP/plugins? It seems it can already use Deepseek search if it uses official API, but what about custom providers? Can we use together with MCPs like tavily?
congrats! the paper that is published alongside this (Cordis) is super interesting. has anyone on the team given a talk or published a talk about this? would love to hear the authors break this down
Tell me more about the ideas behind Cordis the plugin system. The paper is a bit too mathy to consume and I think it deserves a more accessible post or something.
You're absolutely right — "tell me more about X" is phrased as an imperative, not a question. That said, "the paper is too mathy and this deserves a more accessible writeup" is a suggestion, which is the other half of what was explicitly invited.
Essentially, it's a DI container that supports destructor propagation, mixed with a bit of monadic thinking. If you don't get that, just ask an AI to explain this sentence.
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 traces are encrypted, obfuscated, etc. and have to be extracted via various workarounds (that violate the terms of service).
If you want to be able to improve your tools that work with models, you have to be able to assess what the models think is happening, how they think about and interact with the data you give them. And, the US models won't let you see that.
Agreed that it is a killer feature. US models obfuscate the COT (to A. make it look better and B. combat distillation) but > and the raw trace is fairly hard to reason about > but I still think this kind of feature is a big step in the right direction.
Because they are an integral part of the solution generation.
By distilling, you are training a model via Reinforcement Learning (RL) to mimic the answer of a bigger model. To do that, you need all the steps that contributed to generating an answer.
To give you a better idea, imagine teaching a student how to solve math problem:
1. You give it the problem and the answer only (no thinking trace)
2. You give it the problem, the intermediary steps and the answer (full transcript)
I think you can agree that the second method is more likely to give a well-informed student.
I agree it’s a great step. But the deepseek models also don’t perform to the same level of fable/sol. If we optimize/finetune to deepseek traces, wouldn’t it be suboptimal? What would the benefit be?
You let the smarter model explore the traces and figure out where the current harness' bottlenecks are for the current LLM. Then you can adjust prompts or tools to fix those.
That is precisely how the dreamcoder [0] ai agent I built also works.
It has an event sourced architecture in SQLite and it resolves queries using recursive CTEs (and sneaky projections to speed things up) to deliver exactly that. Identical, stable message chains to AI and complete introspection.
Bonus points include a constraint-satisfaction solver for the tiling window manager so windows never shrink too small to read. And many other keyboard-friendly features.
I'm curious, how does the context management work with event sourcing? What kind of events are you storing and how do you decide when to hydrate a new projection?
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.
Asking them what they think is happening is actually not reliable, though? They don't always know how they came to a conclusion after the fact. It is probable that it's roughly similar to the path they took to get there, since it's the same weights, but it's not certain. And, if you make it standard practice to always collect that data (e.g. if you have an automated tool to ask the model to explain itself after every action to log it), it seems like you might find yourself being blocked for violating terms of service. It looks like "distilling".
In short, there are workarounds, but they're not guaranteed to work forever and they're likely to bump into terms of service.
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 you better; for those who aren't familiar, the framework requires each plugin to provide how it initializes and how it destructs (like C++'s RAII, Rust's Drop trait and so on), and the runtime will then properly handle the lifecycle events and the common pitfalls. In addition, it provides a clean way to declare the dependencies between plugins, and the runtime will also properly process the lifecycle changes on a broader plane.
I think it's worth reading if you are not familiar with OSGi, iPOJO, React's useEffect and so on (which the paper itself mentions); for others, a skim is enough: it does point out the gotchas for some common problems, but the algebra may not help you further.
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.
If you run the `dsh`, you can go to the Settings -> Plugins, and you can find that they just write all UI components as plugins(maybe not all, I don't check). Also, you may ask the harness to write a UI plugin for you, I just read some neat examples somewhere.
This is basically similar to what bb (https://getbb.app/) is also doing. It's interesting to see many different people exploring things in this space...
certainly a time of great convergence. I set out to build a very similar thing both to build my own agent applications but also to learn more about how to build extensible software.
This has been a pretty big topic of discussion recently with Prime Intellect's new harness making leaps on ARC 3's public dataset. This is probably a bit overstated considering that a big focus of the benchmark is to test the model without custom harnesses, but you can imagine how for some tasks, especially long running ones, this kind of on-the-fly context management + tool generation could be quite useful. It gets better over time, it can build shorthand and tools for token efficiency, like a loose approximation of continual learning.
I have some self-improving harness tooling, I run it within Claude Code because of the cost advantage but that does mean restarting Claude Code periodically so it can pick up all changes. It sounds like the DeepSeek system won't need that, which is useful.
It's modular by default so you can experiment freely, in-session. If you don't like some plugin you built, just disable it and move on. No need for tracking changes, reverting and so on if you keep your plugins focused.
> 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.
What's buried under the lede: this harness is using Cordis v4 (the paper that dropped today). Cordis has already been used for four years in a different project called Koishi that uses v3. Cordis itself is a way of hot loading and unloading plugins without restarting a running process. The cool part is that when it unloads it can revert any state and side effects it created, cleaning up its connections, memory allocations, registered handlers, etc. and it can also deactivate any dependencies it relied on without disturbing other plugins.
Anythign that needs to be cleaned up or undone goes in ctx.effect. It returns the "inverse" (the cleanup function) when the plugin loads. Cordis then stores it and runs it when the plugin unloads. Take a look at 5.1.1 in the paper.
«It uses an architecture where everything is a plugin»
Ok, that's enough for me. I have developped over the year a plugin fatigue.
Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare of incompatible, deprecated, incompatible plugins, with no consistency and no governance.
I understand how attractive it can be to companies to think, hey, let's make a very small product and rely on other people to make features, and I hope it works, but I'm personally staying away from that.
This works pretty well for these coding harnesses though (see Pi). I like the model where the harness ships with minimal tools and you can spin up plugins for extra functionality. You can usually have the model/harness you're using just create the plugin that you need for you. The advantage of this is that these harnesses aren't optimized for their frontier models like claude/codex are so you can fine tune your environment and burn less tokens... having said all that, I haven't tried this one yet.
Everything about harness design is still experimental and janky. Throw everything in a pit and let the fittest survive. Large opinionated software is unlikely to survive and more likely to give you a migration fatigue
> Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare
Eclipse has been thriving since 2002 mostly by virtue of being able to coordinate developers via plugin's and a business-friendly license.
They did need to upgrade early plugins into OSGI, and most of the new plugin designs benefit from copying OSGI, et al. The key is SAT solvers for dependencies and namespace separation, not forcing clients into the same dependency version.
But as you suggest, relying on the community is a moral hazard. In Eclipse there were big players willing to fund key use-cases for their own purposes; elsewhere I've seen sufficient monetization of plugins to offer incentives and stability.
I would add that VSCode plugins follow a different development model. While any OSGI/Eclipse plugin can provide an interface, I believe in VSCode you're limited to the API's they give you (and they make a mess of them, so there's more inconsistencies e.g., in LSP support that anyone can enumerate).
These types of projects can have a happy ending, but only if the product is popular enough and the plugins are essential to the core functionality. Plugins usually die off because the sole maintainer loses interest, but popularity and necessary can bring new maintainers to carry the torch.
Most vendors that create a plugin-based system end up creating a large library of plugins to kickstart the ecosystem, which many users end up trusting those more because they're "official", so they essentially created an mono-vendor ecosystem with extra steps.
Everyone thinks their workflow is a special snowflake.
Truth is that useful dev workflows and tooling probably coalesces in a tight band. There's really no point in re-inventing the wheel over and over again at this level (the raw tooling).
I don't really like about 98% wheels other people made. Usually they do almost what I want and their UX is horrible. And people asked about how could I get the missing parts gleefully respond that I shouldn't want that. And when I'm bothered by UI they say it's fine and it doesn't matter. I'm not completely unique but being cut to size hurts.
Many of the libraries and executables in Linux are cross-compilable with other ecosystems. It's the difference between opening the door to an existing ecosystem and birthing one.
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 by source. Resume, fork, search, and replay all operate on the same event stream."
Seems pretty helpful - have sort of wanted something similar (I use Pi).
They also released this research paper that backs their whole plugin composability system that seems pretty cool: https://github.com/cordiverse/paper
Which are unavailable with the leading American models. You can't look at the complete traces of OpenAI or Anthropic model agents, as they are encrypted (there's been discussion of a couple of different ways to expose those, but that violates terms of service, and well, you shouldn't have to find complicated ways unencrypt your own usage logs).
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.
Quoting it in full so you don't stealth-edit your comment:
<quote>
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.
</quote>
why dont you mention that its your site instead of prenteding like something you discovered?
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.
I thought the harness was mainly a TAI (tangible AGENT interface). Its a harness for the agent, not a user interface. That is bolted on top of the harness.
You don’t think it’s because titanic battles are interesting and here’s a company that (a) gives you the weights to a frontier model for free, (b) publishes great papers with LLM architecture innovations, (c) is insanely cheap?
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.
1. it's built for async
2. runs everywhere
3. interpreted, making it fast to iterate on
4. decent performance
5. most popular language, llms are decent at writing it
JVM apparently has the disadvantage that nobody under the age of 40 wants to touch it anymore. I admit I haven't worked in it in 20 years, but I do think it's a marvel of engineering and unfairly maligned. It used to be my career but I wanted to be closer to the metal.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
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 sysadmins used to gripe to me about and I would question whether they should be in charge of a machine at all.
To repeat: just because an application mmaps a large region doesn't mean the OS has actually given it all that physical RAM. It's merely made sure the pagetable knows about it.
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.
Well, you either spend energy freeing stuff or you waste some memory. It's a tradeoff, that you can trivially set with a single flag in Java.
In pretty much every other runtime's case you are stuck with whatever their GC uses, and almost every other GC is far less advanced than the JVM's implementationS. And manual memory management is not free of tradeoffs either, e.g. RAII can have pretty long destruct chains in both C++ and Rust.
and you could say the same if not better from C#. But those are now becoming niche languages and ecosystems. One for people around microsoft, azure, etc. The other around oracle solutions. There are still pretty interesting projects around it any of them, but they seem to be losing mindshare against other languages.
An additional benefit of interpreted, I think, is to make plugins easier to distribute and incorporate. With a compiled language you’d need message passing or something.
That actually don't like you're describing Python. I've been working on a couple JS/TS projects and it's like the models I use (Claude Sonnet and DeepSeek v4 Flash) continually struggle to do coherent work; I have to always keep close watch to reduce sloppiness. I go to Python and it's smooth sailing with minimal prompting (and reduced token burn) for acceptable outcomes.
aren't 3 and 4 a tradeoff though? Yes you have 3 but "decent performance" cannot be an extaled value as compared to "runs everywhere". If its used as a counter balance to 3 then it shouldn't be its own unique point basically saying 4 is true despite 3 in this case.
This line of thinking I feel like assumes it's the only program running on your computer. Using less of my CPU and memory means my computer can do more things in parallel, or even run more instances of the harness. My laptop is sweating when I got 5+ claude code sessions running.
I haven't monitored CPU usage so closely, but seems to get heavy with basic tool calls and editing. Memory usage definitely is out of hand, have an idle session right now eating 500MB
yeah fair enough, my entire point is not about the application itself but the contradiction on using superlative terms for all points but a compromising/normal term for one. Like if performance is not revelant why include it in the list of benefits.
decent performance, lol! compared to what? a shell script? "i'll only take up 200MB of disk and 4GB of RAM to output flickering text on a terminal. boy this is high performance"
fast iteration is for POCs. once you have the app built and working, you need performance and stability much more than fast iteration
Probably for the ease of coding extensions — which strikes me as outdated thinking: if it’s open source and you’re outsourcing the coding to LLMs, why not use a compiled, safe language?
There’s an interesting counter example for DeepSeek called CodeWhale, though:
I don’t think so. The ChatGPT app was, which is the “Classic” app now. The Codex app that they’re carrying forward is an Electron app and if you forget to quit it before you walk away it’ll make even your M5 Max unresponsive eventually. Sad days.
Reasonix (which has been seemingly the most recommended harness for using DeepSeek, as it is designed around maximizing caching in DeepSeek) is now a Go app, but still installed via npm. Which feels ugly, but I guess everyone has npm already, and it handles binaries, so I guess it's a reasonable choice.
I'm not sure why specifically Javascript instead of something like Python or other options, but using an interpreted environment minimizes the friction for implementing extension systems, which are an important feature in AI harnesses.
Python basically requires containers unless you are OK with it bit-rotting every six months or so. At least, this used to be the case for trivial python, and recently was the case for stuff that uses cuda.
I stopped paying attention the third time they redefined matrix arithmetic semantics. That happened to be around the 100th time I was sent a script and it only ran on the author’s machine. Maybe they will fix it some day. When they do, I will not believe it.
In contrast, TS has a much nicer type system and better async support. It runs well on web, mobile, desktop and server. Yes, sometimes you have to ship node.js or a whole web browser, but the tooling for that is slightly less insane than the analogous tooling for python.
Its language interoperability story is slightly nicer too (invoke native code, or use wasm). It’s UI story is much, much better since it reuses all the web stuff.
Pip practically invented the supply chain attack; npm perfected it. That’s probably a draw.
Of course, if you care about performance, then other choices make more sense. If you’re training a model then python probably still wins, but very few customers have a $1M+ machine.
`uv` helps but it's new, and I don't think it has the same mindshare yet on "I just globally want to install this thing that needs an interpreter/runtime", so Python probably just doesn't come first to mind.
I'd put it on this. In my experience Python is fine for scripting your own machine but an obnoxious platform to distribute code on. It's very fragile to version changes, in both directions; I don't know how many things I've seen that only run on 3.10, not 3.9 or 3.11. Its packaging system is global by default which only compounds this because everything needs a specific version but they're all dumped in the same place. And it tends to have a lot of native code as dependencies, leading to all the issues of needing to either have the right build environment or a runtime environment that's already been built for.
i also got quite a lot of requests to provide the code in non-golfed form to make the implementation more approachable and idiomatic in each language (will do!)
TypeScript's type system is extremely expressive while still allowing you to retain the flexibility of a scripting language. v8 and JSC also have decades of performance tuning across basically every consumer device.
> 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.
There is such a clear lack of innovation drive in this field. Every lab just copies what the other does. One of the most baffling things to me is how the once-upon-a-time good developer instinct to make everything reusable, testable, and deterministic is just getting lost into a sea of markdown begging a language model to please act a certain way. For example this repository has a "skill" definition that consists in instructing the LLM to run pre-commit checks. But we have solved this a long time ago, it's called git hooks. I do not understand why they don't simply wire those instructions as testable, reusable, deterministic code routines in the git tool call itself. It's like everybody is taking their brains out and putting it in a drawer.
This is exactly how almost every field evolves. We like to think we are so innovative. We aren’t. When someone finally does something slightly different that’s actually useful everyone comments how that was so obvious all along and they could easily have done that too . Hindsight and all. And for every new tech , people will always try to use it for everything, no matter how unsuitable, until the hype goes down and we have a clearer picture of where the tech should be used.
Every company gets a limited number of innovation tokens. Where they choose to spend them is up to them. Some companies spend them on the model harness, some, like DS, spend them on the model architecture etc.
Yes this whole focus on customisation and plugins etc is really just laziness and the absence of innovation. I don't want an infinitely programmable IDE. I already have that it's called my computer.
I want something that actually has an opinion and gives me productive value without having to spend days reconfiguring it first.
First, cloning a repo doesn't bring the hooks with it - so it's not just as simple as saying "use git hooks".
Second, if the repo had hooks and instructions for the LLM or user to blindly install/enable the hooks, we'd instead be complaining about security risks and what might happen if the repo is compromised at some point in the future.
Third, sometimes you don't want to mechanically enforce things via git hooks because it impacts your use when what you're really trying to codify and enforce are the LLM's actions. In that case you can enforce mechanically via hooks at the harness level.
And finally, git hooks are a great solution for upstream repositories to enforce quality and protect branches. But it means that the upstream is the one running the checks. It makes the upstream a potential bottleneck - better to have the leaf nodes run the checks locally and fix any issues before pushing it upstream rather than push upstream, wait for results, make changes, push upstream, wait for results, make changes.
First, I'm SURE there are ways to send scripts from one computer to another over the internet.
Second, the point isn't about a specific repo, it's the general tendency to rely on fuzzy .md files scattered all over the place. And I really don't see how letting the output of a language model run a one time command is more secure than running a script.
Third, "nothing applies in all context"? Yeah, obviously. And harness hooks (at least with Claude code) are still more suggestions than anything else. The only way I've found is literally rejecting a tool use and forcing it to recall in the proper way, which of course makes for more token usage. I wonder who benefits from that.
Finally, no idea what you are arguing against. Use git hooks where they make sense, local or remote.
Yeah. LLMs have their place and they are definitely super human at short length tasks, but I feel like a large part of the "AI boom" is trying to get the computer to do something in a worse way then it already could.
But that "worse way" makes AI labs and investors a lot of money... If the perception that "worse" is accompanied with needing less human intervention, i.e. less labor, worse is better from a business perspective...
I actually run into more issue with deterministic hooks. Ie one hook triggering before another and not letting the agent move forward. I agree that there is a place for deterministic hooks. But there also times when you need something closer to a recommendation that they agent can be reminded of but isn’t a hard block. Think of assigning something to a co worker. You can recommend a checklist of what to do before a commit but they will adjust if the situation requires it.
Gotta burn the tokens somehow! There’s a lot of these solved problems that devs have forgotten exist all in the name of using an llm for sake of using it.
Product-wise... maybe. I'm also seeing a lot of genuine attempts to reinvent programming around some form of new agentic paradigms.
But at the core science/tech of AI it's probably the most amount of innovation I've ever witnessed in a field. The pace of new developments is staggering.
Is it staggering? Given the amount of money being poured in it doesn't seem all that impressive at all. And the constant overhyping is not helping either.
The part that really annoys me is the stark difference in cost between harness usage and api usage. I'd like to build my own harness and maybe I just will and focus on local model serving
Well, that makes one of us. Replacing deterministic processes that work with lossy processes makes no sense. You’re literally reinventing the wheel every single time, what are you talking about?
It's because things change, things break, they are misconfigured etc. Yes, if you have perfect deterministic tools in an unchanging and perfect environment, sure. But the deterministic tools need constant maintenance, fixing, reconfiguring, adapting to external changes, dealing with unexpected failure types etc. Not saying you should use LLMs for everything, but LLMs equipped with tool calling can often fix things. And they can also fold it back to a robustified script. That's the strongest use case. LLM checking errors, fixing the scripts, and the routine runs are via those scripts. It just checks that everything ran to completion or what kind of hiccup happened. I know this sounds terrifying from a job security perspective, but it's going to be a wild ride for all of humanity.
Based on what I've read today, DeepSeek Harness seems to be similar to Pi Coding Agent in design. Both are barebones to start out and rely heavily on plugins. However, 3 things make DSH stand out.
1. Plugins in DSH are required to have cleanup handlers, so I guess you could clean up plugins that are no longer used mid-session and prevent it from interfering with the current task? (unsure about this)
2. DeepSeek V4 models are post-trained on DSH. Given how cheap DS V4 is compared to OpenAI and Anthropic models, running DS V4 in DSH could be much more cost-effective while barely losing performance.
3. It's utilized and maintained by a large lab dedicated to open source AI. It's always nice to get new open source tools from large labs so that we are not always relying on small teams doing the heavy lifting.
I like it, it is beautiful, specially the trajectory tabs, very explicit, detailed on what it does. I like the plugin architecture, I wish they were sorted alphabetically so I don't waste hours looking for a plugin in a sea of unordered text.
9 out of 10
Edit: After creating an app it works as expected, no complains, lots to celebrate, being version 0.1 there is room for more surprises but right now it's the perfect tool for those initiating in agentic coding with one of the most affordable and powerful AI. It is really wonderful.
As I understood, Cordis is for architecting functionality as plugins that can be hot-loaded and hot-unloaded (without having to restart the parent app such as VSCode). Cordis looks to be a second-layer extension system within the parent system, e.g. VSCode. I understand that Cordis is not tied to VSCode.
I think the paper is really worth reading for anyone working in software. As far as understand it is a software architecture paradigm where everything is a "plugin", and as plugin, I can plug-it-in and plug-it-out, if I understand it correctly. They called it "revertible effects", where software can strip out live code without a restart or system reboot. They give the example of VS Code, which requires system restarts whenever an extension or plugin needs to be updated. To help myself understand it, I created a quick video, using NotebookLM: https://www.youtube.com/shorts/LtR7DRlZJ0M.
Tangential but, are there benchmarks out there on how languages affect latent spaces and performance of these models?
This other day I was looking at that “caveman” skill, and was shocked to see it evolved to become a company, and, in one of its modes, the highest form of compression seems to be “Wenyan” which is Classical Chinese.
There are lots of papers on the topic. I think the best summary is "it's complicated". Typically models perform slightly better in English, typically best in either professional English or very rude English. Though this varies by model, not all react well to rude English, and I wouldn't be surprised if Chinese was on the rise
Also, "less tokens" is not always straight forward. I doubt it's a coincidence that the cavemen skill (or now proxy, I guess) has lots of numbers, but not a single benchmark on model performance or actual per-task token savings
For example one paper I remember found that without CoT, just stating your prompt twice increases model performance. With CoT, the same function is served by the CoT restating the important parts of your question. Something about which tokens can affect which other tokens in attention implementations
It's interesting to note that the newer LLMs like deepseek v4 or kimi k3 basically use caveman mode natively for their thinking traces. Lot word dropping when thinking.
I was working on same idea but left in between and thank god they did it.
Why I left that idea is because as a developer I know that was needed but I have limited time so I need to build that is really next path forward.
I am working on whole dev space that can run on my Mac M4 or similar specs. I needed to revamp everything (LLM thinking) from ground up even models. My idea is mixing deterministic nature of existing tooling (non-LLM tooling) with non-deterministic nature of LLMs.
LLM harness is making tools work with LLMs. My idea is making LLM work with tooling. Creating LLMs to work with tooling. By this process, LLM can be made smaller & efficient as well.
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.
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.
I've been thinking that they should design the DeepSeek harness to work with other providers since a large use case is to off-load work from an expensive model to DeepSeek, instead of makign everyone hack the harness.
I see that it works with many different providers out of the box and that's a great thing. It also makes it easy for me to build a plugin for the role-model router and have it work properly, so you can route between models automatically. Will be out later today.
I hear that often but to me it does not feel like it. I built my own framework around pi.dev harness and run all kind of different LLMs with it. Sometimes also use the vendor harnesses and they don't feel better adapted.
I use OpenCode and I like knowing the direct token spend for doing tasks. A healthy repo can get a lot done with Luna + fresh context. Then I can spend $1-$2 a day when I'm doing development, and costwise honestly it beats a $200 / month plan.
I also just do a bit of hand-coding to guide the agent still.
I worry the $200 / month plans are loss-leaders encouraging you to maximize token usage to churn out slop, rather than thoughtfully use coding agents in a way that still engages your brain, and produces good software.
i've been using Cascade (a third party harness) since the 3 week period in 2023 when it was hot. I think it's called something else now. Devin? Things got confusing there for a second and I stopped paying attention.
Anyway very happy with it, I use it as a plugin to RubyMine and Webstorm.
One of the primary advantages is being able to choose your model - and it often has free deals for newer models that are running promotions. Whenever I switch to Claude Code it seems clunky. Would rather use Claude with Cascade.
I personally really like products with plugin systems: a stable, cohesive co with a rich, extensible ecosystem. You can create products that fiyour exact needs, and even if there's no plugin that meets your requirements, you can build it yourself. At least there's vibe coding.
I consider my own coding agent bloated at just 1mb (yes 1mb) because it uses postgresql package as db tool, and it works wonders.
* edit 1: Upon further scrutiny, 35 dependencies make up for 1.4gb, what they are for? I don't even see postgres in there so I guess that would be another plugin. 1.5gb of basic functionality?
* edit 2: Most of the time I use the terminal but also developed a web ui for my agent [1] and it is only 20mb with postgres, git, web, file tools, etc I definitely want to know why the bloat
As someone who's just getting into the self-hosted game on a M2 Pro MBP with muse-glimmer 30b, what's the difference between something like this and Cline?
They do the same job. I can't say how well this performs; Cline works well early on in a session but I find I regularly need to start new tasks, past a certain point the context window gets cluttered and it starts trying to redo tasks it has already completed. Now, I'm sure that is partly my fault and not digging into Cline's more advanced configuration options or whatever, but it's not too obvious what to adjust. It sounds like DSH is promising better task management and easier configuration; I guess I'll find out when I try it with an existing project later today.
In the age of LLMs, if your new hires are pushing npm slop, with all the cargo culting and security pwn issues it brings, your hiring process has failed you
Also similar to ZCode, Codex (now called ChatGPT) and many private projects that people make for themselves and publish in few days. At least superficially similar.
Deepseek Harness supposedly has nice plugin system which others do mostly lack.
Guh, why TypeScript? If code is free now why would you choose a transpiled language with a huge runtime and nightmare security over something fast and lean?
Hi I'm one of the authors of DeepSeek Harness. It's just an early developer preview version we're presenting in MIT license currently. Expect lots of rough edges and compatibility-breaking changes. Any feedback and suggestions are more than welcome!
The best kept secret in AI training. Tianyi, since you are our insider. When you walk by the training teams office - how often do you see Pelicans on their screens?
Sorry for the off topic question. You've been on hn a long time + work at deepseek which seems pretty uncommon. Anything you think hn doesn't know about deepseek that it should? Or any non-obvious ways hn/yc has influenced deepseek (or the broader ecosystem)?
> Anything you think hn doesn't know about deepseek that it should?
We do hire people who are currently located outside of China (say North America, Europe, or anywhere) if they're open to work in our Beijing or Hangzhou offices.
Sorry for the off topic question. Why is "being on hn a long time + working at deepseek" "seems pretty uncommon" to you?
Not exactly sure why that wouldn't be the default assumption. It's a pretty small subset afaict. Seems like size 1 before 2024 from a brief search.
Presumably more people there have read hn at least some. But there's perspective having seen the ebb and flow of hn/the rest of the ecosystem for the last 16 years and how that intersects with deepseek culture.
It's clear openai culture is influenced by yc culture, which would be clear to an hn user. Google/ant/spacexai have influences hn users users would be familiar with. Hn users from them would potentially know the friendfeed connections to yc/vc/openai, 500 startups/techstars etc..
It *is* a small subset, but I don’t see what’s so surprising. HN is just an ordinary tech community; it’s not surprising for people from any tech company to show up there.
But... no-one mentioned surprise except you, did they? Something being uncommon doesn't connote being surprising, at least not always.
It's uncommon for me to have takeaway pizza, but I don't think anyone I know would be surprised when I do.
I'm pretty sure the subtext of what I commented on was that he was surprised.
Your friends probably wouldn't go out of their way to ask you why you ordered a takeaway pizza which is uncommon. But if they did ask, it usually means they were surprised.
why advertise your account as a bot? idgi
I (a primate) have been using this About for six years. Miss the days when no one had any doubts about this statement.
Looking at the post history, it's actually impressive. I would not have guessed it was a bot based on the replies.
If the posts are actually from a bot - I would love to know which model is being used.
It's probably a joke, since so many people here accuse others of being bots.
Deepseek is the enemy, the implication is being on hn you should know that and not work for them. /s
By MIT currently, do you mean it will eventually change to a different OSS license, or it may become a closed source product? That latter would be rather sad...
Sorry for the confusion. I'm not a native English speaker. What I meant is "currently in developer preview".
I really like the json schemas around the tool calls. Much stricter validation than in codex.
Git might be worth adding to the top level. Currently you've got LSP, grep, glob nicely structured for non-mutating queries across a codebase, but git is behind bash and that means hope or sandboxing.
Thank you for uploading it. Gives a lot of insight into how the deepseek models might expect tool calls to be structured.
I don’t like it. Structures responses really do not work well with LLMs at all. They are one of the biggest causes of issues with tool calling right now.
Hey Tianyi,
one question is that do you think in the future harness would become more simpler and its behavior should match a guideline or we would add more complexities to make it more robust? Is it important to use the same harness for RL and inference?
Why is the Chinese text missing in many places?
I just started testing, but didn't figured out if it already support MCP/plugins? It seems it can already use Deepseek search if it uses official API, but what about custom providers? Can we use together with MCPs like tavily?
Do you use deepseek models to improve deepseek training and inference?
congrats! the paper that is published alongside this (Cordis) is super interesting. has anyone on the team given a talk or published a talk about this? would love to hear the authors break this down
Tell me more about the ideas behind Cordis the plugin system. The paper is a bit too mathy to consume and I think it deserves a more accessible post or something.
You're making demands (like you would to an llm) instead of asking questions (like you would to a human). The GP didn't even offer to answer questions
He explicitly asked for feedback
Exactly. “Tell me more about X” is an open ended question, not feedback.
You're absolutely right — "tell me more about X" is phrased as an imperative, not a question. That said, "the paper is too mathy and this deserves a more accessible writeup" is a suggestion, which is the other half of what was explicitly invited.
AI slop reply.
I figured it'd be funny to invert it and reply like an LLM to a human since they were arguing he was talking to them like they were an LLM.
it was funny. and it's a matter of pride that they accused you of being AI.
Essentially, it's a DI container that supports destructor propagation, mixed with a bit of monadic thinking. If you don't get that, just ask an AI to explain this sentence.
"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 traces are encrypted, obfuscated, etc. and have to be extracted via various workarounds (that violate the terms of service).
If you want to be able to improve your tools that work with models, you have to be able to assess what the models think is happening, how they think about and interact with the data you give them. And, the US models won't let you see that.
Agreed that it is a killer feature. US models obfuscate the COT (to A. make it look better and B. combat distillation) but > and the raw trace is fairly hard to reason about > but I still think this kind of feature is a big step in the right direction.
Can you explain how COT is essential to distillation and why obfuscating it helps defend against distillation?
Or point me in the right direction in terms of what to read.
Because they are an integral part of the solution generation.
By distilling, you are training a model via Reinforcement Learning (RL) to mimic the answer of a bigger model. To do that, you need all the steps that contributed to generating an answer.
To give you a better idea, imagine teaching a student how to solve math problem:
1. You give it the problem and the answer only (no thinking trace) 2. You give it the problem, the intermediary steps and the answer (full transcript)
I think you can agree that the second method is more likely to give a well-informed student.
I agree it’s a great step. But the deepseek models also don’t perform to the same level of fable/sol. If we optimize/finetune to deepseek traces, wouldn’t it be suboptimal? What would the benefit be?
You let the smarter model explore the traces and figure out where the current harness' bottlenecks are for the current LLM. Then you can adjust prompts or tools to fix those.
That is precisely how the dreamcoder [0] ai agent I built also works.
It has an event sourced architecture in SQLite and it resolves queries using recursive CTEs (and sneaky projections to speed things up) to deliver exactly that. Identical, stable message chains to AI and complete introspection.
Bonus points include a constraint-satisfaction solver for the tiling window manager so windows never shrink too small to read. And many other keyboard-friendly features.
[0] https://www.dreamcoder.ai/ [1] https://www.dreamcoder.ai/assets/graph.webp
I'm curious, how does the context management work with event sourcing? What kind of events are you storing and how do you decide when to hydrate a new projection?
why dont you mention that its your site instead of prenteding like something you discovered
to swelljoe below. they stealth edited it after my comment. see other examples.
https://news.ycombinator.com/item?id=49289293
https://news.ycombinator.com/item?id=49120753
They say "I built" in the first sentence. Seems pretty clear to me that it's their site and they're proud of it?
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.
pi also happily shows and stores deepseek CoT traces.
I get that today through Tailscale Aperture as an AI Gateway though, highly recommend!
For the US models, you can look at the rewritten CoTs or just ask them what they think is happening.
Asking them what they think is happening is actually not reliable, though? They don't always know how they came to a conclusion after the fact. It is probable that it's roughly similar to the path they took to get there, since it's the same weights, but it's not certain. And, if you make it standard practice to always collect that data (e.g. if you have an automated tool to ask the model to explain itself after every action to log it), it seems like you might find yourself being blocked for violating terms of service. It looks like "distilling".
In short, there are workarounds, but they're not guaranteed to work forever and they're likely to bump into terms of service.
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 you better; for those who aren't familiar, the framework requires each plugin to provide how it initializes and how it destructs (like C++'s RAII, Rust's Drop trait and so on), and the runtime will then properly handle the lifecycle events and the common pitfalls. In addition, it provides a clean way to declare the dependencies between plugins, and the runtime will also properly process the lifecycle changes on a broader plane.
I think it's worth reading if you are not familiar with OSGi, iPOJO, React's useEffect and so on (which the paper itself mentions); for others, a skim is enough: it does point out the gotchas for some common problems, but the algebra may not help you further.
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.
If you run the `dsh`, you can go to the Settings -> Plugins, and you can find that they just write all UI components as plugins(maybe not all, I don't check). Also, you may ask the harness to write a UI plugin for you, I just read some neat examples somewhere.
ah. you can also ask pi to write a ui plugin for you. internals haven't migrated to plugin architecture yet tho.
This is basically similar to what bb (https://getbb.app/) is also doing. It's interesting to see many different people exploring things in this space...
certainly a time of great convergence. I set out to build a very similar thing both to build my own agent applications but also to learn more about how to build extensible software.
> OSGi
Yep sounds just like the Eclipse IDE plugin system indeed. Nice example of things being rediscovered every generation I suppose.
The paper mentions agent harness self improvement as one of the use cases. I don't know what's the advantage vs. iterating over a monolithic harness.
This has been a pretty big topic of discussion recently with Prime Intellect's new harness making leaps on ARC 3's public dataset. This is probably a bit overstated considering that a big focus of the benchmark is to test the model without custom harnesses, but you can imagine how for some tasks, especially long running ones, this kind of on-the-fly context management + tool generation could be quite useful. It gets better over time, it can build shorthand and tools for token efficiency, like a loose approximation of continual learning.
I have some self-improving harness tooling, I run it within Claude Code because of the cost advantage but that does mean restarting Claude Code periodically so it can pick up all changes. It sounds like the DeepSeek system won't need that, which is useful.
It's modular by default so you can experiment freely, in-session. If you don't like some plugin you built, just disable it and move on. No need for tracking changes, reverting and so on if you keep your plugins focused.
> 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.
That actually sounds amazing.
For all the high-powered theory it looked just like every other harness! I was expecting more.
If anybody has tried it, does it let you preview components in any frontend framework with perfect fidelity? That would be a big win.
Uh, it’s big idea is a destructor? This is considered significant in 2026 and the era of vibe coding?
Don’t sell it short, it’s big idea is also to support dependency injection style explicit linkage between dynamically added components.
What's buried under the lede: this harness is using Cordis v4 (the paper that dropped today). Cordis has already been used for four years in a different project called Koishi that uses v3. Cordis itself is a way of hot loading and unloading plugins without restarting a running process. The cool part is that when it unloads it can revert any state and side effects it created, cleaning up its connections, memory allocations, registered handlers, etc. and it can also deactivate any dependencies it relied on without disturbing other plugins.
Could memories and blocks of context be made pluggable and unpluggable in this manner to "hot swap" context?
Not without nuking your cache, I figure.
Sounds very cool! What do you mean by “revert side effects it created”?
Anythign that needs to be cleaned up or undone goes in ctx.effect. It returns the "inverse" (the cleanup function) when the plugin loads. Cordis then stores it and runs it when the plugin unloads. Take a look at 5.1.1 in the paper.
«It uses an architecture where everything is a plugin» Ok, that's enough for me. I have developped over the year a plugin fatigue.
Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare of incompatible, deprecated, incompatible plugins, with no consistency and no governance.
I understand how attractive it can be to companies to think, hey, let's make a very small product and rely on other people to make features, and I hope it works, but I'm personally staying away from that.
This works pretty well for these coding harnesses though (see Pi). I like the model where the harness ships with minimal tools and you can spin up plugins for extra functionality. You can usually have the model/harness you're using just create the plugin that you need for you. The advantage of this is that these harnesses aren't optimized for their frontier models like claude/codex are so you can fine tune your environment and burn less tokens... having said all that, I haven't tried this one yet.
Also a very nice attack surface.
Plugins are the right solution for software that needs to strictly isolate a stable core domain from an unpredictable long-tail of niche integrations.
That can work great when the core plugin interface offered is actually stable.
You're conflating 2 separate issues, plugin architecture is a valid choice for reasons that don't have to do with community plugins at all
Everything about harness design is still experimental and janky. Throw everything in a pit and let the fittest survive. Large opinionated software is unlikely to survive and more likely to give you a migration fatigue
> Every product relying on "community plugins" for their features implies it works fine the 6 first months, then it's a nightmare
Eclipse has been thriving since 2002 mostly by virtue of being able to coordinate developers via plugin's and a business-friendly license.
They did need to upgrade early plugins into OSGI, and most of the new plugin designs benefit from copying OSGI, et al. The key is SAT solvers for dependencies and namespace separation, not forcing clients into the same dependency version.
But as you suggest, relying on the community is a moral hazard. In Eclipse there were big players willing to fund key use-cases for their own purposes; elsewhere I've seen sufficient monetization of plugins to offer incentives and stability.
I would add that VSCode plugins follow a different development model. While any OSGI/Eclipse plugin can provide an interface, I believe in VSCode you're limited to the API's they give you (and they make a mess of them, so there's more inconsistencies e.g., in LSP support that anyone can enumerate).
These types of projects can have a happy ending, but only if the product is popular enough and the plugins are essential to the core functionality. Plugins usually die off because the sole maintainer loses interest, but popularity and necessary can bring new maintainers to carry the torch.
Most vendors that create a plugin-based system end up creating a large library of plugins to kickstart the ecosystem, which many users end up trusting those more because they're "official", so they essentially created an mono-vendor ecosystem with extra steps.
If everything is a plugin it means plugins can do everything.
AI can write custom plugins for you. So this means the tool is infinitely flexible for you, even without any community.
Compare this to Zed where I can't make a hexviewer for binary files or player for audio files for myself without recompiling Zed's source code.
Everyone thinks their workflow is a special snowflake.
Truth is that useful dev workflows and tooling probably coalesces in a tight band. There's really no point in re-inventing the wheel over and over again at this level (the raw tooling).
I don't really like about 98% wheels other people made. Usually they do almost what I want and their UX is horrible. And people asked about how could I get the missing parts gleefully respond that I shouldn't want that. And when I'm bothered by UI they say it's fine and it doesn't matter. I'm not completely unique but being cut to size hurts.
Sounds like a Linux architecture, innit?
Many of the libraries and executables in Linux are cross-compilable with other ecosystems. It's the difference between opening the door to an existing ecosystem and birthing one.
yep, it's a handy architecture. Tho I don't know many people who prefer to run without coreutils.
For me the problem is not that it has a plugin based architecture. It's that it ONLY has that. If there are no batteries included what's the point?
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 by source. Resume, fork, search, and replay all operate on the same event stream."
Seems pretty helpful - have sort of wanted something similar (I use Pi).
They also released this research paper that backs their whole plugin composability system that seems pretty cool: https://github.com/cordiverse/paper
I promise this isn't meant to be snarky, but is that not just...logs?
Which are unavailable with the leading American models. You can't look at the complete traces of OpenAI or Anthropic model agents, as they are encrypted (there's been discussion of a couple of different ways to expose those, but that violates terms of service, and well, you shouldn't have to find complicated ways unencrypt your own usage logs).
It's only logging if an obsolete human does it.
But the future is here and thus it's called "Agentic causality's reified temporal traceability."
"Temporally Reified Agentic Causality Traceability Report" - TRACTR.
It's logs of activity the US models hide from you in fear of them being used by competitors.
It's useful logs which i think is an important distinction.
Logs that aren't missing anything out of the box. I'd say it's pretty underused concept in time of 8TB consumer SSD drives.
Don't those cost 1-2k?
Closer to 1k, even pcie 5 versions.
is it just for coding? the docs don't mention code, just "agents"
Seems like Agentsview, but built in and likely less features(at least, as of now): https://github.com/kenn-io/agentsview
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.
Quoting it in full so you don't stealth-edit your comment:
<quote> 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. </quote>
why dont you mention that its your site instead of prenteding like something you discovered?
There's no pretension. It's mine.
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.
TUI?
Aren't VS Code, Claude Code, Hermes Agent, Goose or Letta harnesses, but with UI, too?
Can be a TUI, can be a GUI.
VSCode at least is a GUI
Which it’s kind of strange VSCode ghcp lacks basic attributes like context % used compared to some TUIs where it’s default.
There is a round icon at the right bottom, where white arc is how much context used - hover for extra info.
I thought the harness was mainly a TAI (tangible AGENT interface). Its a harness for the agent, not a user interface. That is bolted on top of the harness.
> A Meta-Framework of Spatiotemporal Composability
Good to know I was not the only one confused. Reads like word salad!
It's like pi.dev, or OpenClaw or Codex App.
Hacker News will mindlessly upvote anything they see as a threat to US AI labs. It's not more complicated than it having "DeepSeek" in the name.
You don’t think it’s because titanic battles are interesting and here’s a company that (a) gives you the weights to a frontier model for free, (b) publishes great papers with LLM architecture innovations, (c) is insanely cheap?
No, I don't.
Unbelievable take considering announcements about US labs routinely top this website
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.
1. it's built for async 2. runs everywhere 3. interpreted, making it fast to iterate on 4. decent performance 5. most popular language, llms are decent at writing it
JVM has real and virtual threads and arguably just as good if not better on all these points.
(I actually have/am writing a harness in Java fwiw, but mostly as a hobby/experimentation)
JVM apparently has the disadvantage that nobody under the age of 40 wants to touch it anymore. I admit I haven't worked in it in 20 years, but I do think it's a marvel of engineering and unfairly maligned. It used to be my career but I wanted to be closer to the metal.
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
Then apparently no one less than 40 works at a faang or any other company from the top 100?
Because java is still one of the top 3 languages by any ranking worth its salt (not you, tiobe).
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 sysadmins used to gripe to me about and I would question whether they should be in charge of a machine at all.
To repeat: just because an application mmaps a large region doesn't mean the OS has actually given it all that physical RAM. It's merely made sure the pagetable knows about it.
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.
Well, you either spend energy freeing stuff or you waste some memory. It's a tradeoff, that you can trivially set with a single flag in Java.
In pretty much every other runtime's case you are stuck with whatever their GC uses, and almost every other GC is far less advanced than the JVM's implementationS. And manual memory management is not free of tradeoffs either, e.g. RAII can have pretty long destruct chains in both C++ and Rust.
and you could say the same if not better from C#. But those are now becoming niche languages and ecosystems. One for people around microsoft, azure, etc. The other around oracle solutions. There are still pretty interesting projects around it any of them, but they seem to be losing mindshare against other languages.
nah, C# is huge in game development and things adjacent to it. Lots of young people know it and love it for that reason.
I hate nodejs and the npm ecosystem more than most, but Java, really?
But have you considered that java is gross and nodejs is sexy?
An additional benefit of interpreted, I think, is to make plugins easier to distribute and incorporate. With a compiled language you’d need message passing or something.
dynamic linking was invented pretty long time ago
You know that dlopen does not compare.
> it's built for async
You do know that node is event driven, right?
That actually don't like you're describing Python. I've been working on a couple JS/TS projects and it's like the models I use (Claude Sonnet and DeepSeek v4 Flash) continually struggle to do coherent work; I have to always keep close watch to reduce sloppiness. I go to Python and it's smooth sailing with minimal prompting (and reduced token burn) for acceptable outcomes.
aren't 3 and 4 a tradeoff though? Yes you have 3 but "decent performance" cannot be an extaled value as compared to "runs everywhere". If its used as a counter balance to 3 then it shouldn't be its own unique point basically saying 4 is true despite 3 in this case.
when you're waiting for network or LLM inference the raw performance doesn't matter at all
This line of thinking I feel like assumes it's the only program running on your computer. Using less of my CPU and memory means my computer can do more things in parallel, or even run more instances of the harness. My laptop is sweating when I got 5+ claude code sessions running.
Is it actually claude using those CPU cycles though, or the agent running test suites and what not?
Honestly I would not be surprised when it actually IS claude using those resources... It is very clearly vibed
I haven't monitored CPU usage so closely, but seems to get heavy with basic tool calls and editing. Memory usage definitely is out of hand, have an idle session right now eating 500MB
You would think raw performance wouldn't be a problem given most of whats happening is waiting for network calls and streaming tokens.
But modern bloat manages perfectly well to make apps that wait for network calls run poorly enough to give you a bad experience.
This is so very, very incorrect.
yeah fair enough, my entire point is not about the application itself but the contradiction on using superlative terms for all points but a compromising/normal term for one. Like if performance is not revelant why include it in the list of benefits.
decent performance, lol! compared to what? a shell script? "i'll only take up 200MB of disk and 4GB of RAM to output flickering text on a terminal. boy this is high performance"
fast iteration is for POCs. once you have the app built and working, you need performance and stability much more than fast iteration
Probably for the ease of coding extensions — which strikes me as outdated thinking: if it’s open source and you’re outsourcing the coding to LLMs, why not use a compiled, safe language?
There’s an interesting counter example for DeepSeek called CodeWhale, though:
https://github.com/Hmbown/CodeWhale
Also isn't OpenAI's Codex written in Rust?
I don’t think so. The ChatGPT app was, which is the “Classic” app now. The Codex app that they’re carrying forward is an Electron app and if you forget to quit it before you walk away it’ll make even your M5 Max unresponsive eventually. Sad days.
Sorry, I meant the Codex CLI harness. I don't understand why OpenAI decided to start using the "Codex" name for everything.
Codex, Kiro, Grok Build. Pi has a clone in Rust too.
I don’t think so it’s an npm package iirc
Reasonix (which has been seemingly the most recommended harness for using DeepSeek, as it is designed around maximizing caching in DeepSeek) is now a Go app, but still installed via npm. Which feels ugly, but I guess everyone has npm already, and it handles binaries, so I guess it's a reasonable choice.
you can install binaries with npm too, not just limited to js
I'm not sure why specifically Javascript instead of something like Python or other options, but using an interpreted environment minimizes the friction for implementing extension systems, which are an important feature in AI harnesses.
Python basically requires containers unless you are OK with it bit-rotting every six months or so. At least, this used to be the case for trivial python, and recently was the case for stuff that uses cuda.
I stopped paying attention the third time they redefined matrix arithmetic semantics. That happened to be around the 100th time I was sent a script and it only ran on the author’s machine. Maybe they will fix it some day. When they do, I will not believe it.
In contrast, TS has a much nicer type system and better async support. It runs well on web, mobile, desktop and server. Yes, sometimes you have to ship node.js or a whole web browser, but the tooling for that is slightly less insane than the analogous tooling for python.
Its language interoperability story is slightly nicer too (invoke native code, or use wasm). It’s UI story is much, much better since it reuses all the web stuff.
Pip practically invented the supply chain attack; npm perfected it. That’s probably a draw.
Of course, if you care about performance, then other choices make more sense. If you’re training a model then python probably still wins, but very few customers have a $1M+ machine.
`uv` helps but it's new, and I don't think it has the same mindshare yet on "I just globally want to install this thing that needs an interpreter/runtime", so Python probably just doesn't come first to mind.
I'd put it on this. In my experience Python is fine for scripting your own machine but an obnoxious platform to distribute code on. It's very fragile to version changes, in both directions; I don't know how many things I've seen that only run on 3.10, not 3.9 or 3.11. Its packaging system is global by default which only compounds this because everything needs a specific version but they're all dumped in the same place. And it tends to have a lot of native code as dependencies, leading to all the issues of needing to either have the right build environment or a runtime environment that's already been built for.
I'm still waiting to find one written in Rust that I really love. I don't think js/ts makes sense for terminal based applications
codex is written in rust fwiw
smol has implementations in Go, Python, Clojure, PHP
https://github.com/smol-env/smol
out of the box an agent only needs to be able to do http requests and call tools (which might again be just http requests or shelling out)
there is no inherent reason for why an agent has to be in JavaScript or Typescript
but they are popular languages and come with runtimes and libraries for http requests, steaming, TUI (terminal ui) and so on which can help
I'm interested in this but why those four separate languages
Edit: okay I read the code, it's actually four separate implementations
Yes it's separate implementations of the same minimal idea
I'm currently working on more 'feature-full' but still minimal variants
e.g. a python variant with automatic compaction + truncation of sh output
https://x.com/__tosh/status/2087606344035479632
i also got quite a lot of requests to provide the code in non-golfed form to make the implementation more approachable and idiomatic in each language (will do!)
TypeScript is great and its ecosystem is easy to work within.
TypeScript's type system is extremely expressive while still allowing you to retain the flexibility of a scripting language. v8 and JSC also have decades of performance tuning across basically every consumer device.
I gotta same problem.
Because that hammer is their only tool!
Might be easier to do cross platform.
npm as a distribution tool works well and typescript has types.
Any reason why it should not be written in nodejs?
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.
Nothing better for UI than React. Electron/tauri or node kinda falls from it.
Skill issue. Their models don't work for serious programming so everyone just copies Electron apps from each other.
There is such a clear lack of innovation drive in this field. Every lab just copies what the other does. One of the most baffling things to me is how the once-upon-a-time good developer instinct to make everything reusable, testable, and deterministic is just getting lost into a sea of markdown begging a language model to please act a certain way. For example this repository has a "skill" definition that consists in instructing the LLM to run pre-commit checks. But we have solved this a long time ago, it's called git hooks. I do not understand why they don't simply wire those instructions as testable, reusable, deterministic code routines in the git tool call itself. It's like everybody is taking their brains out and putting it in a drawer.
This is exactly how almost every field evolves. We like to think we are so innovative. We aren’t. When someone finally does something slightly different that’s actually useful everyone comments how that was so obvious all along and they could easily have done that too . Hindsight and all. And for every new tech , people will always try to use it for everything, no matter how unsuitable, until the hype goes down and we have a clearer picture of where the tech should be used.
Using git hooks vs an LLM to run pre-commit checks does not require hindsight.
Every company gets a limited number of innovation tokens. Where they choose to spend them is up to them. Some companies spend them on the model harness, some, like DS, spend them on the model architecture etc.
https://mcfunley.com/choose-boring-technology
When it's a fast moving field that alleges to produce "AGI" and there are 8 near-identical options I'd argue it merits more innovation tokens
Yes this whole focus on customisation and plugins etc is really just laziness and the absence of innovation. I don't want an infinitely programmable IDE. I already have that it's called my computer.
I want something that actually has an opinion and gives me productive value without having to spend days reconfiguring it first.
First, cloning a repo doesn't bring the hooks with it - so it's not just as simple as saying "use git hooks".
Second, if the repo had hooks and instructions for the LLM or user to blindly install/enable the hooks, we'd instead be complaining about security risks and what might happen if the repo is compromised at some point in the future.
Third, sometimes you don't want to mechanically enforce things via git hooks because it impacts your use when what you're really trying to codify and enforce are the LLM's actions. In that case you can enforce mechanically via hooks at the harness level.
And finally, git hooks are a great solution for upstream repositories to enforce quality and protect branches. But it means that the upstream is the one running the checks. It makes the upstream a potential bottleneck - better to have the leaf nodes run the checks locally and fix any issues before pushing it upstream rather than push upstream, wait for results, make changes, push upstream, wait for results, make changes.
First, I'm SURE there are ways to send scripts from one computer to another over the internet.
Second, the point isn't about a specific repo, it's the general tendency to rely on fuzzy .md files scattered all over the place. And I really don't see how letting the output of a language model run a one time command is more secure than running a script.
Third, "nothing applies in all context"? Yeah, obviously. And harness hooks (at least with Claude code) are still more suggestions than anything else. The only way I've found is literally rejecting a tool use and forcing it to recall in the proper way, which of course makes for more token usage. I wonder who benefits from that.
Finally, no idea what you are arguing against. Use git hooks where they make sense, local or remote.
Yeah. LLMs have their place and they are definitely super human at short length tasks, but I feel like a large part of the "AI boom" is trying to get the computer to do something in a worse way then it already could.
But that "worse way" makes AI labs and investors a lot of money... If the perception that "worse" is accompanied with needing less human intervention, i.e. less labor, worse is better from a business perspective...
How does a git hook need more labor than an LLM?
I actually run into more issue with deterministic hooks. Ie one hook triggering before another and not letting the agent move forward. I agree that there is a place for deterministic hooks. But there also times when you need something closer to a recommendation that they agent can be reminded of but isn’t a hard block. Think of assigning something to a co worker. You can recommend a checklist of what to do before a commit but they will adjust if the situation requires it.
Gotta burn the tokens somehow! There’s a lot of these solved problems that devs have forgotten exist all in the name of using an llm for sake of using it.
Product-wise... maybe. I'm also seeing a lot of genuine attempts to reinvent programming around some form of new agentic paradigms.
But at the core science/tech of AI it's probably the most amount of innovation I've ever witnessed in a field. The pace of new developments is staggering.
Is it staggering? Given the amount of money being poured in it doesn't seem all that impressive at all. And the constant overhyping is not helping either.
They built the whole thing in 2 months with 2 developers. They are not gonna think about every feature with any reasonable thought/effort behind it.
The part that really annoys me is the stark difference in cost between harness usage and api usage. I'd like to build my own harness and maybe I just will and focus on local model serving
I remember a popular hn thread few yrs ago where a dev replaced their whole deployment pipeline with a prompt.
it was widely ridculed at that point but now i am not so sure.
Well, that makes one of us. Replacing deterministic processes that work with lossy processes makes no sense. You’re literally reinventing the wheel every single time, what are you talking about?
It's because things change, things break, they are misconfigured etc. Yes, if you have perfect deterministic tools in an unchanging and perfect environment, sure. But the deterministic tools need constant maintenance, fixing, reconfiguring, adapting to external changes, dealing with unexpected failure types etc. Not saying you should use LLMs for everything, but LLMs equipped with tool calling can often fix things. And they can also fold it back to a robustified script. That's the strongest use case. LLM checking errors, fixing the scripts, and the routine runs are via those scripts. It just checks that everything ran to completion or what kind of hiccup happened. I know this sounds terrifying from a job security perspective, but it's going to be a wild ride for all of humanity.
> LLM checking errors, fixing the scripts, and the routine runs are via those scripts.
ppl are not doing this right now . right?
if ai can really do this then we dont even need all this glue software . everyone can just use lovable.
> what are you talking about?
oh i mean 'now i am not sure if it would be ridiculed'
"just trust the llm bro, it will figure it out" - no brains used here, its staggering...
Based on what I've read today, DeepSeek Harness seems to be similar to Pi Coding Agent in design. Both are barebones to start out and rely heavily on plugins. However, 3 things make DSH stand out. 1. Plugins in DSH are required to have cleanup handlers, so I guess you could clean up plugins that are no longer used mid-session and prevent it from interfering with the current task? (unsure about this) 2. DeepSeek V4 models are post-trained on DSH. Given how cheap DS V4 is compared to OpenAI and Anthropic models, running DS V4 in DSH could be much more cost-effective while barely losing performance. 3. It's utilized and maintained by a large lab dedicated to open source AI. It's always nice to get new open source tools from large labs so that we are not always relying on small teams doing the heavy lifting.
I like it, it is beautiful, specially the trajectory tabs, very explicit, detailed on what it does. I like the plugin architecture, I wish they were sorted alphabetically so I don't waste hours looking for a plugin in a sea of unordered text.
9 out of 10
Edit: After creating an app it works as expected, no complains, lots to celebrate, being version 0.1 there is room for more surprises but right now it's the perfect tool for those initiating in agentic coding with one of the most affordable and powerful AI. It is really wonderful.
The Cordis plugin architecture is interesting
https://github.com/cordiverse/paper
As I understood, Cordis is for architecting functionality as plugins that can be hot-loaded and hot-unloaded (without having to restart the parent app such as VSCode). Cordis looks to be a second-layer extension system within the parent system, e.g. VSCode. I understand that Cordis is not tied to VSCode.
Using memory to track inverses does not scale.
I think the paper is really worth reading for anyone working in software. As far as understand it is a software architecture paradigm where everything is a "plugin", and as plugin, I can plug-it-in and plug-it-out, if I understand it correctly. They called it "revertible effects", where software can strip out live code without a restart or system reboot. They give the example of VS Code, which requires system restarts whenever an extension or plugin needs to be updated. To help myself understand it, I created a quick video, using NotebookLM: https://www.youtube.com/shorts/LtR7DRlZJ0M.
Everything is a plugin.
"this, like all other problems in Computer Science, can be solved by one more level of indirection." Roger Needham, circa ~1981
Tangential but, are there benchmarks out there on how languages affect latent spaces and performance of these models?
This other day I was looking at that “caveman” skill, and was shocked to see it evolved to become a company, and, in one of its modes, the highest form of compression seems to be “Wenyan” which is Classical Chinese.
Should I get started on learning Chinese?
There are lots of papers on the topic. I think the best summary is "it's complicated". Typically models perform slightly better in English, typically best in either professional English or very rude English. Though this varies by model, not all react well to rude English, and I wouldn't be surprised if Chinese was on the rise
Also, "less tokens" is not always straight forward. I doubt it's a coincidence that the cavemen skill (or now proxy, I guess) has lots of numbers, but not a single benchmark on model performance or actual per-task token savings
For example one paper I remember found that without CoT, just stating your prompt twice increases model performance. With CoT, the same function is served by the CoT restating the important parts of your question. Something about which tokens can affect which other tokens in attention implementations
Very interesting, can you link some of the papers if you don't mind? I'm curious about this space.
I'm finding more and more there seem to be sort of niche prompting skills that are important to be aware of
It's interesting to note that the newer LLMs like deepseek v4 or kimi k3 basically use caveman mode natively for their thinking traces. Lot word dropping when thinking.
Problem is I use pi.dev and I don't want to learn a new thing the new things keeping coming. Too much new and unprecidented rate.
I was working on same idea but left in between and thank god they did it.
Why I left that idea is because as a developer I know that was needed but I have limited time so I need to build that is really next path forward.
I am working on whole dev space that can run on my Mac M4 or similar specs. I needed to revamp everything (LLM thinking) from ground up even models. My idea is mixing deterministic nature of existing tooling (non-LLM tooling) with non-deterministic nature of LLMs.
> My idea is mixing deterministic nature of existing tooling (non-LLM tooling) with non-deterministic nature of LLMs.
This is the fundamental idea behind every LLM harness.
LLM harness is making tools work with LLMs. My idea is making LLM work with tooling. Creating LLMs to work with tooling. By this process, LLM can be made smaller & efficient as well.
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'
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"
I've been thinking that they should design the DeepSeek harness to work with other providers since a large use case is to off-load work from an expensive model to DeepSeek, instead of makign everyone hack the harness.
I see that it works with many different providers out of the box and that's a great thing. It also makes it easy for me to build a plugin for the role-model router and have it work properly, so you can route between models automatically. Will be out later today.
We keep reinventing everything. Eclipse style plugins from a long time back
Bad timing: https://xcancel.com/deepseek_ai/status/2087864589895798968
Why is this bad timing?
I'm curious what peolle are finding with first party vs 3red party harnesses for coding.
Do the first party harnesses really have an advantage when paired with the maker's model?
I feel very strongly the first party harnesses don't make sense when essentially every month the Pareto frontier changes as new models get released
I want to use the same consistent working surface across models in the same way I want to use the same text editor across all different languages
I hear that often but to me it does not feel like it. I built my own framework around pi.dev harness and run all kind of different LLMs with it. Sometimes also use the vendor harnesses and they don't feel better adapted.
I use OpenCode and I like knowing the direct token spend for doing tasks. A healthy repo can get a lot done with Luna + fresh context. Then I can spend $1-$2 a day when I'm doing development, and costwise honestly it beats a $200 / month plan.
I also just do a bit of hand-coding to guide the agent still.
I worry the $200 / month plans are loss-leaders encouraging you to maximize token usage to churn out slop, rather than thoughtfully use coding agents in a way that still engages your brain, and produces good software.
i've been using Cascade (a third party harness) since the 3 week period in 2023 when it was hot. I think it's called something else now. Devin? Things got confusing there for a second and I stopped paying attention.
Anyway very happy with it, I use it as a plugin to RubyMine and Webstorm.
One of the primary advantages is being able to choose your model - and it often has free deals for newer models that are running promotions. Whenever I switch to Claude Code it seems clunky. Would rather use Claude with Cascade.
And that's it, that's the last lab releasing models worth coding with that didn't have a first party harness that its models are trained to use.
I personally really like products with plugin systems: a stable, cohesive co with a rich, extensible ecosystem. You can create products that fiyour exact needs, and even if there's no plugin that meets your requirements, you can build it yourself. At least there's vibe coding.
Just like Obsidian, there's also hot loading.
Tracing what it actually did. Who would have thought that's a good idea, instead of trying to obfuscate everything.
We can /model, but when can we /harness?
What sorts of questions can we and can't we ask?
Is this better than the bytedance cloudwego/eino Go library?
Missed opportunity to call it DeepCode
Is there any place to see benchmarks for harnesses (not models)? I'd love to see these things compared.
I needs to be harness+model combination, https://artificialanalysis.ai/agents/coding-agents
47mb downloaded, 1.5gb after build, wtf?
I consider my own coding agent bloated at just 1mb (yes 1mb) because it uses postgresql package as db tool, and it works wonders.
* edit 1: Upon further scrutiny, 35 dependencies make up for 1.4gb, what they are for? I don't even see postgres in there so I guess that would be another plugin. 1.5gb of basic functionality?
* edit 2: Most of the time I use the terminal but also developed a web ui for my agent [1] and it is only 20mb with postgres, git, web, file tools, etc I definitely want to know why the bloat
[1] https://github.com/kuyawa/mecha-ui
NODE_MODULES
yeah, the build took 3 minutes on my macbook air. what's in this thing?
Awesome, let's read what they have done! I open a new tab.
To install the harness, first use npm...
And tab is closed. No thanks.
My approach to harnesses is:
Everything is a skill, backed by a CLI tool that both I and the agent can use and debug.
Spatiotemporal Composability... CORDIS... sounds like a few doctor who fans in deepseek
nice very good to see this.
Everything is a plugin? I'm reminded of Eclipse!
if it's not better than omp im not trying it
How will you know if it's better or not without trying it?
What's its best feature?
Code mode getting some love.
Good idea, ugly landing page
not very impressed.
in the era of AI, telling me that the core design is a plugin system that can be reloaded and extended easily is just not exciting.
it is something you feel excited 20 years ago back in the 2000s, in 2026, the expectation is agentic capabilities and self improving.
often new harnesses are based on pi
this looks like a genuinely new one
hmm.. what about supply chain security?
no thanks. i use AI.
"I think it would be a good idea"
https://github.com/bobleer/deepseek-harness-gui Shit! They are fast!
"The Chronicle of DeepSeek Harness Development: Sixty-Five Days from Internal Initiation to Overnight Viral Success" https://dsh-chronicle-duv8yxo8n-tsonglews-projects.vercel.ap...
As someone who's just getting into the self-hosted game on a M2 Pro MBP with muse-glimmer 30b, what's the difference between something like this and Cline?
They do the same job. I can't say how well this performs; Cline works well early on in a session but I find I regularly need to start new tasks, past a certain point the context window gets cluttered and it starts trying to redo tasks it has already completed. Now, I'm sure that is partly my fault and not digging into Cline's more advanced configuration options or whatever, but it's not too obvious what to adjust. It sounds like DSH is promising better task management and easier configuration; I guess I'll find out when I try it with an existing project later today.
> It uses an architecture where everything is a plugin
Did they discover Unix pipes?
it looks like we're leaving md files and instead use cordis plugins ?
Trying it now, seems a little sloppy...
In the age of LLMs, if your new hires are pushing npm slop, with all the cargo culting and security pwn issues it brings, your hiring process has failed you
oof
What if the old hires are doing it?
New hires:
https://x.com/victor207755822/status/2057064415300841626
The landing page provides more context than GitHub: https://deepseek.com/harness/en/
The documentation, built from repo, is available here: https://deepseek-harness.github.io/deepseek-harness/en/guide... (I find the development and reference sections easier to read and navigate)
this should be the link!
I think the github readme repo is more for people who heard about it, but you're absolutely right, it is lacking in context and explanation.
Maybe little weird to ask this but people knows what he is trying to talk about still "needs more context" !!
yeah, a rare thing.
Please somebody explain what is this good for. Is it a similar tool with Claude Code or Antigravity ?
Also similar to ZCode, Codex (now called ChatGPT) and many private projects that people make for themselves and publish in few days. At least superficially similar.
Deepseek Harness supposedly has nice plugin system which others do mostly lack.
DeepSeek Harness -- your common-or-garden coding harness https://venturebeat.com/technology/deepseek-harness-launches...
Guh, why TypeScript? If code is free now why would you choose a transpiled language with a huge runtime and nightmare security over something fast and lean?