One thing I found was tool calling in GLM 5.2 on github using Claude Code was mostly failing then fixing. But I didn't compare to z.ai's harness. (Nothing to do with Deepseek, sorry.)
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.".
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.
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.
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
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.
«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.
> 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).
96 comments
[ 2.0 ms ] story [ 44.5 ms ] threadThe 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)
Do the first party harnesses really have an advantage when paired with the maker's model?
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
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?
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.
oof
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.
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).