"Every run is traceable<p>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."<p>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).<p>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.
That is precisely how the dreamcoder [0] ai agent I built also works.<p>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.<p>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.<p>[0] <a href="https://www.dreamcoder.ai/" rel="nofollow">https://www.dreamcoder.ai/</a>
[1] <a href="https://www.dreamcoder.ai/assets/graph.webp" rel="nofollow">https://www.dreamcoder.ai/assets/graph.webp</a>
I get that today through Tailscale Aperture as an AI Gateway though, highly recommend!
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.<p>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.
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 <i>probable</i> 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".<p>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.<p>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.<p>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.<p>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.
This is basically similar to what bb (<a href="https://getbb.app/" rel="nofollow">https://getbb.app/</a>) is also doing. It's interesting to see many different people exploring things in this space...
just read the paper, and there aee definitely some interesting ideas in it.<p>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.<p>i also like the use of generator to to clean up partial registrations nicely.<p>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.<p>works ok within a single compilation unit, i.e. a plugin with many modules. does not help with typing of cross-plugin dependencies.<p>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).<p>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.<p>definitely cool stuff tho! remains to be seen how well it works in a real plugin ecosystem.<p>> they push the boundaries further, to the UI components<p>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.
> OSGi<p>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.<p>That actually sounds amazing.
For all the high-powered theory it looked just like every other harness! I was expecting more.<p>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?
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!
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 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)?
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.
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.<p>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.
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.
«It uses an architecture where everything is a plugin»
Ok, that's enough for me. I have developped over the year a plugin fatigue.<p>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.<p>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<p>Eclipse has been thriving since 2002 mostly by virtue of being able to coordinate developers via plugin's and a business-friendly license.<p>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.<p>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.<p>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).
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.
Plugins are the right solution for software that needs to strictly isolate a stable core domain from an unpredictable long-tail of niche integrations.
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
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.<p>AI can write custom plugins for you. So this means the tool is infinitely flexible for you, even without any community.<p>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.
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?
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.
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: <a href="https://deepseek.com/harness/en/" rel="nofollow">https://deepseek.com/harness/en/</a> is the Every Run is Traceable view:<p>"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."<p>Seems pretty helpful - have sort of wanted something similar (I use Pi).<p>They also released this research paper that backs their whole plugin composability system that seems pretty cool: <a href="https://github.com/cordiverse/paper" rel="nofollow">https://github.com/cordiverse/paper</a>
I promise this isn't meant to be snarky, but is that not just...logs?
It's only logging if an obsolete human does it.<p>But the future is here and thus it's called "Agentic causality's reified temporal traceability."
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 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.
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 <i>and</i> stable message history that does not break the cache.<p>[0] <a href="https://www.dreamcoder.ai" rel="nofollow">https://www.dreamcoder.ai</a> -> scroll down to the event graph.
Quoting it in full so you don't stealth-edit your comment:<p><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><p>why dont you mention that its your site instead of prenteding like something you discovered?
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): <a href="https://github.com/kenn-io/agentsview" rel="nofollow">https://github.com/kenn-io/agentsview</a>
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?<p>Aren't VS Code, Claude Code, Hermes Agent, Goose or Letta harnesses, but with UI, too?
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<p>Good to know I was not the only one confused. Reads like word salad!
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?
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:<p>1. The first significant agentic harness was made by Anthropic.<p>2. One of the most senior developers of client-side software at Anthropic is Felix Rieseberg, one of the original creators of Electron. [1]<p>3. After Claude Code blew up, everyone else copied Anthropic.<p>---<p>1: <a href="https://daringfireball.net/2026/07/claudes_criminally_bad_mac_app_is_an_inside_job" rel="nofollow">https://daringfireball.net/2026/07/claudes_criminally_bad_ma...</a>
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
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 has real <i>and</i> virtual threads and arguably just as good if not better on all these points.<p>(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.<p>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.<p>IMHO, Microsoft made the correct approach on .NET.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>I mean, we have malloc() and free(), they are in the stdlib for a reason :)<p>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.
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.
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?
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.
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"<p>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?<p>There’s an interesting counter example for DeepSeek called CodeWhale, though:<p><a href="https://github.com/Hmbown/CodeWhale" rel="nofollow">https://github.com/Hmbown/CodeWhale</a>
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.<p>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.<p>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.<p>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.<p>Pip practically invented the supply chain attack; npm perfected it. That’s probably a draw.<p>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.
codex is written in rust fwiw<p>smol has implementations in Go, Python, Clojure, PHP<p><a href="https://github.com/smol-env/smol" rel="nofollow">https://github.com/smol-env/smol</a><p>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)<p>there is no inherent reason for why an agent has to be in JavaScript or Typescript<p>but they are popular languages and come with runtimes and libraries for http requests, steaming, TUI (terminal ui) and so on which can help
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.
TypeScript is great and its ecosystem is easy to work within.
Because that hammer is their only tool!
I gotta same problem.
Might be easier to do cross platform.
npm as a distribution tool works well and typescript has types.<p>Any reason why it should not be written in nodejs?
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.
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.<p>9 out of 10<p>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.
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.<p><a href="https://mcfunley.com/choose-boring-technology" rel="nofollow">https://mcfunley.com/choose-boring-technology</a>
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.<p>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".<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.
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.<p>it was widely ridculed at that point but now i am not so sure.
"just trust the llm bro, it will figure it out" - no brains used here, its staggering...
Everything is a plugin.<p>"this, like all other problems in Computer Science, can be solved by one more level of indirection." Roger Needham, circa ~1981
The Cordis plugin architecture is interesting<p><a href="https://github.com/cordiverse/paper" rel="nofollow">https://github.com/cordiverse/paper</a>
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.<p>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: <a href="https://www.youtube.com/shorts/LtR7DRlZJ0M" rel="nofollow">https://www.youtube.com/shorts/LtR7DRlZJ0M</a>.
Tangential but, are there benchmarks out there on how languages affect latent spaces and performance of these models?<p>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.<p>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<p>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<p>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.<p>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.<p>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.
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 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.<p>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.
We can /model, but when can we /harness?
Bad timing: <a href="https://xcancel.com/deepseek_ai/status/2087864589895798968" rel="nofollow">https://xcancel.com/deepseek_ai/status/2087864589895798968</a>
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.<p>Just like Obsidian, there's also hot loading.
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'm curious what peolle are finding with first party vs 3red party harnesses for coding.<p>Do the first party harnesses really have an advantage when paired with the maker's model?
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.<p>I also just do a bit of hand-coding to guide the agent still.<p>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.<p>Anyway very happy with it, I use it as a plugin to RubyMine and Webstorm.<p>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.
Tracing what it actually did. Who would have thought that's a good idea, instead of trying to obfuscate everything.
Everything is a plugin? I'm reminded of Eclipse!
Is there any place to see benchmarks for harnesses (not models)? I'd love to see these things compared.
Awesome, let's read what they have done! I open a new tab.<p>To install the harness, first use npm...<p>And tab is closed. No thanks.
Spatiotemporal Composability... CORDIS... sounds like a few doctor who fans in deepseek
Code mode getting some love.
47mb downloaded, 1.5gb after build, wtf?<p>I consider my own coding agent bloated at just 1mb (yes 1mb) because it uses postgresql package as db tool, and it works wonders.<p>* 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?<p>* 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<p>[1] <a href="https://github.com/kuyawa/mecha-ui" rel="nofollow">https://github.com/kuyawa/mecha-ui</a>
if it's not better than omp im not trying it
Good idea, ugly landing page
often new harnesses are based on pi<p>this looks like a genuinely new one
hmm.. what about supply chain security?
<a href="https://github.com/bobleer/deepseek-harness-gui" rel="nofollow">https://github.com/bobleer/deepseek-harness-gui</a>
Shit! They are fast!
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<p>Did they discover Unix pipes?
Trying it now, seems a little sloppy...
it looks like we're leaving md files and instead use cordis plugins ?
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<p>oof
The landing page provides more context than GitHub: <a href="https://deepseek.com/harness/en/" rel="nofollow">https://deepseek.com/harness/en/</a><p>The documentation, built from repo, is available here: <a href="https://deepseek-harness.github.io/deepseek-harness/en/guide/quickstart" rel="nofollow">https://deepseek-harness.github.io/deepseek-harness/en/guide...</a> (I find the development and reference sections easier to read and navigate)
[flagged]
[dead]
[dead]
[flagged]
[flagged]
[dead]
[dead]
[flagged]
[flagged]
In the court of law, the plaintiff has the burden of proof.
You need to provide the proof instead of accusations.<p>What if DeepSeek never copied anything from anyone? They cannot prove something they haven't done.<p>Same here, you gotta provide the proof or at least trace of where DS might have done so.<p>---<p>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)
this is a very dangerous question.
Why?
You’re implying the open weight model providers are behind the US companies, so they cannot do anything right.<p>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.<p>We saw the same attitude from Silicon Graphics, Sun, etc vs Linux and Windows during the 1990s. It led to those companies’ ruin.<p>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.<p>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).<p>Those vendors even tried getting the US government to intervene with procurement regulations, etc.<p>Anyone that was paying attention during the dotcom era should know how the current bubble ends.
because this time it looks pretty much original ?
Please somebody explain what is this good for. Is it a similar tool with Claude Code or Antigravity ?
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?