https://deepseek-harness.github.io/deepseek-harness/en/guide...
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.
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.
Yep sounds just like the Eclipse IDE plugin system indeed. Nice example of things being rediscovered every generation I suppose.
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."
[0] https://www.dreamcoder.ai -> scroll down to the event graph.
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!
I want something that actually has an opinion and gives me productive value without having to spend days reconfiguring it first.
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.
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.
it was widely ridculed at that point but now i am not so sure.
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.
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.
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.
Honestly I would not be surprised when it actually IS claude using those resources... It is very clearly vibed
But modern bloat manages perfectly well to make apps that wait for network calls run poorly enough to give you a bad experience.
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:
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.
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
Edit: okay I read the code, it's actually four separate implementations
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!)
Any reason why it should not be written in nodejs?
For web stuff, sure.
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 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.
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.
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.
Using memory to track inverses does not scale.
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
I'm finding more and more there seem to be sort of niche prompting skills that are important to be aware of
"this, like all other problems in Computer Science, can be solved by one more level of indirection." Roger Needham, circa ~1981
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.
Just like Obsidian, there's also hot loading.
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.
To install the harness, first use npm...
And tab is closed. No thanks.
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
Did they discover Unix pipes?
oof
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)
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.
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.
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
In short, there are workarounds, but they're not guaranteed to work forever and they're likely to bump into terms of service.