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.
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.
«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 model 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
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.
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
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?
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
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.
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.
JVM apparently has the advantage 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.
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.
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.
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 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.
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.
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
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'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 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.
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
You’re implying the open weight model providers are behind the US companies, so they cannot do anything right.
Instead, they currently own the entire Pareto frontier — they have the lowest cost model (in terms of inference and training) at every commercially-available level of output quality.
We saw the same attitude from Silicon Graphics, Sun, etc vs Linux and Windows during the 1990s. It led to those companies’ ruin.
Concretely, I remember lots of arguments that the Linux kernel team would stall out once they implemented posix, since that was the end of the “copy for the sake of compatibility” runway.
While making such claims, none of the Unix vendors produced anything vaguely price-competitive with whitebox PCs (they were slightly better for niche workloads at 10x the cost, with crippling guardrails, er, license gated features).
Those vendors even tried getting the US government to intervene with procurement regulations, etc.
Anyone that was paying attention during the dotcom era should know how the current bubble ends.
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)
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.
That actually sounds amazing.
If anybody has tried it, does it let you preview components in any frontend framework with perfect fidelity? That would be a big win.
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.
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.
"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
But the future is here and thus it's called "Agentic causality's reified temporal traceability."
Aren't VS Code, Claude Code, Hermes Agent, Goose or Letta harnesses, but with UI, too?
Good to know I was not the only one confused. Reads like word salad!
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
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 actually have/am writing a harness in Java fwiw, but mostly as a hobby/experimentation)
Having Oracle's tramp-stamp on it may have been the final kiss of death in terms of totally-superficial "coolness" factor.
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.
But modern bloat manages perfectly well to make apps that wait for network calls run poorly enough to give you a bad experience.
Honestly I would not be surprised when it actually IS claude using those resources... It is very clearly vibed
fast iteration is for POCs. once you have the app built and working, you need performance and stability much more than fast iteration
There’s an interesting counter example for DeepSeek called CodeWhale, though:
https://github.com/Hmbown/CodeWhale
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.
Any reason why it should not be written in nodejs?
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.
https://github.com/cordiverse/paper
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?
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
Do the first party harnesses really have an advantage when paired with the maker's model?
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 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.
Did they discover Unix pipes?
oof
Sadly no backwards direction
What if DeepSeek never copied anything from anyone? They cannot prove something they haven't done.
Same here, you gotta provide the proof or at least trace of where DS might have done so.
---
Also in this field, nothing is original. Everything builds on another's ideas (unless the idea is copyrighted. Paid for it? then ok, stolen? no)
Instead, they currently own the entire Pareto frontier — they have the lowest cost model (in terms of inference and training) at every commercially-available level of output quality.
We saw the same attitude from Silicon Graphics, Sun, etc vs Linux and Windows during the 1990s. It led to those companies’ ruin.
Concretely, I remember lots of arguments that the Linux kernel team would stall out once they implemented posix, since that was the end of the “copy for the sake of compatibility” runway.
While making such claims, none of the Unix vendors produced anything vaguely price-competitive with whitebox PCs (they were slightly better for niche workloads at 10x the cost, with crippling guardrails, er, license gated features).
Those vendors even tried getting the US government to intervene with procurement regulations, etc.
Anyone that was paying attention during the dotcom era should know how the current bubble ends.