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)?

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.

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?

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

Do you use deepseek models to improve deepseek training and inference?

Why is the Chinese text missing in many places?

[dead]

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.

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.

How is that different from what Pi already does?

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 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.

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...

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.

> OSGi

Yep sounds just like the Eclipse IDE plugin system indeed. Nice example of things being rediscovered every generation I suppose.

> 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.

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.

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?

As far as I can find, Cordis didn't exist before they shared it with this harness. It is very likely that its because I didn't search in Chinese (as I don't know it). Can you explain the evolution of it from the different versions?

Could memories and blocks of context be made pluggable and unpluggable in this manner to "hot swap" context?

Sounds very cool! What do you mean by “revert side effects it created”?

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.

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.

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.

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

Sounds like a Linux architecture, innit?

No. This is not for community plugins, it's for AI generated plugins.

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?

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

A "harness" is basically what you call Claude Code and such, i.e. a TUI to run the agent.

> 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.

[flagged]

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...

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

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

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.

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

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'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

Nothing better for UI than React. Electron/tauri or node kinda falls from it.

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?

Skill issue. Their models don't work for serious programming so everyone just copies Electron apps from each other.

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.

https://mcfunley.com/choose-boring-technology

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.

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.

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.

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.

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.

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

"just trust the llm bro, it will figure it out" - no brains used here, its staggering...

[flagged]

[dead]

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.

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.

> 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.

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.

[flagged]

Sadly, it doesn't ship with support for "dsh --profile acp"

Why is this bad timing?

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.

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.)

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 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.

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.

I needs to be harness+model combination, https://artificialanalysis.ai/agents/coding-agents

yeah, the build took 3 minutes on my macbook air. what's in this thing?

NODE_MODULES

How will you know if it's better or not without trying it?

What's its best feature?

What if the old hires are doing it?

no thanks. i use AI.

"I think it would be a good idea"

[flagged]

"The Chronicle of DeepSeek Harness Development: Sixty-Five Days from Internal Initiation to Overnight Viral Success" https://dsh-chronicle-duv8yxo8n-tsonglews-projects.vercel.ap...

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.

yeah, a rare thing.

HaS aNyOnE sEeN aLtErNaTiNg CaSe CoNvErTeRs https://en.toolpage.org/tool/alternatingcase https://www.textformatting.com/case-converter/alternating-ca...

Sadly no backwards direction

In the court of law, the plaintiff has the burden of proof. You need to provide the proof instead of accusations.

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)

this is a very dangerous question.

DeepSeek Harness -- your common-or-garden coding harness https://venturebeat.com/technology/deepseek-harness-launches...

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.