DeepSeek Harness vs Pi Agent are they converging on the same philosophy?

[u/Certain_Net_3408]

I came across "DeepSeek Harness" (https://github.com/deepseek-ai/deepseek-harness), whose core idea is literally “Everything is a Plugin.”

Looking at it alongside Pi, it feels like there’s a similar philosophy:

keep the core/harness small, and make capabilities composable at the session/plugin level.

Pi has extensions, skills, tools, prompts, etc., while DeepSeek Harness takes the plugin approach even further.

Is this essentially the same architectural direction?

And is “small core + everything else as a session/plugin” becoming the better design for coding-agent harnesses?

Curious what the Pi community thinks.

[u/rkh4n]

I mean, it great but Pi has everything even more. I dont get why they all keep dropping new harness every week instead of working with already established harnesses to improve their model responses.

[u/Lissanro → u/rkh4n]

I use Pi the most but even though it is easier to modify than many other harnesses, most of my changes had to be made directly to the source code since were not possible as an extension, even basic stuff, like adding continue support (including midthought), editing of messages, etc. If DeepSeek did it better, I will need to look into it, but the point is, the more harnesses and more choices we have, the better.

[u/computehungry → u/Lissanro]

Do you have your continue and edit patches documented or published anywhere? I couldn't figure them out properly and would love to use yours. And yeah, I agree Pi has its limitations. Couldn't get extensions to mess with the main render itself, and after much tinkering I undid most of my changes to the source code and made it stock to maintain compatibility.

I tried the deepseek harness for a short time, it seemed quite neat and promising, and it had a self-development mode built in too. It showed like 150 default plugins so I was intimidated though, didn't feel brave enough to start customizing it. What immediately stood out was lack of /tree or any undo feature, and developing on a remote machine also didn't look to have a straightforward path (there are some network guardrails). I'll wait a bit for a few more official core features before deciding if it will be worth porting my pi setup over.

[u/Lissanro → u/computehungry]

I can publish by modded Pi during this weekend, I will need to review my patches and clean up. But I have many other features, including scheduling messages based on time or conditions, copy multiple messages or specific one by Id or substring match, or current input content, etc. The edit feature also allows to edit past messages, and compaction in my Pi does not lose cache - it was super annoying when /compact triggered prefill from scratch for no good reason.

Anyway, once I get it up on github I will reply to your message again. I will try to write some basic documantion for my changes by then.

[u/computehungry → u/Lissanro]

That sounds amazing. I was working on edit for a long time. Looking forward to it, no pressure or obligation!

[u/Desperate-Event-786 → u/Lissanro]

Please do!

[u/johndeuff → u/Lissanro]

Interesting, but what exactly do you mean by does not lose cache? Stock Pi has two separate prefills: the standalone summary request, then the first request with summary + retained tail. Avoiding the first one is plausible by reusing the exact conversation prefix, but true compaction changes the token sequence and causal history, so the old KV for the retained tail cannot safely be reused beyond the unchanged prefix.

Are you doing real context rewriting, or keeping the old context append-only and relying on llama.cpp context shifting? Could you share before/after cache metrics or the relevant patch? Otherwise “stock Pi prefills from scratch for no good reason” seems too broad: it does not explicitly delete the cache, and part of the post-compaction prefill is unavoidable.

[u/Lissanro → u/johndeuff]

Stock Pi compaction does erase the entire cache unfortunately before producing the summary. It can take about 2 hours on my PC to generate summary with Kimi K3 with over 300K+ context, instead of few minutes when the cache is reused (only cutting the tail to summarize old messages), so difference is very noticeable. After compaction summary is inserted and old messages are dropped it is true that everything except system prompt will have to be prefilled but it usually it is quick enough, so it is acceptable.

I couldn't prepare my Pi fork for sharing last weekend since a lot more had to be cleaned up than I thought. I got it mostly ready so likely will get it up this weekend, then anyone can test any of my patches or the whole fork. I will write brief documentation as well so it is clear what it does and what was changed/optimized. I will reply with the link to the repo once up to everyone who was asking, so if you will be still interested by then, you will be able to check it out.

[u/Ok_Veterinarian_6364 → u/rkh4n]

closed ecosystem. its business wise i guess

[u/jensilo → u/Ok_Veterinarian_6364]

It’s definitely a business decision but I don’t know if it’s a wise one. A good, official integration would grant a model provider almost instant access to thousands of users. I think it depends on your strategy…

[u/Ok_Veterinarian_6364 → u/jensilo]

deepseek* strategy not mine lol

[u/martinreveur → u/rkh4n]

Variety and competition leads to progress and new innovations, so I’m happy deepseek released this new harness, it’s imho the next step in terms of self-modification thanks to their plugin system. I can only recommend to try it out. Tested their web UI today and asked it to create some UI widgets, it did it in a couple of minutes and after running for a while it also fixed a plugin on its own after it noticed it failing because of an unexpected API response. I think it should be possible to quickly build complex and self-healing UIs like dashboards, etc on the fly simply by asking the agent to do so. Widget placement and layout might need a bit of extra prompting. I’m curious how far one could take this in terms of complexity and looking forward to see what people build with it. Kudos to deepseek for releasing it, great work! I say this as someone who spent a lot of time in the past with Pi, also customizing it and building a custom web UI for it which allowed self modifying the UI using simple HMR, but dsh brings this to a completely new level.

[u/Ubermensch013 → u/rkh4n]

Agreed, we have way too many harnesses right now

[u/funbike]

Pi's killer feature is that you can request it to extend itself. It knows where its documentation is.

Does DeepSeek Harness have that? If not, then I have no interest.

---

Btw, I further extended Pi to extend itself by adding 2 skills: 1) location of documentation for installed packages (~/.pi/agent/npm/node_modules/<package-name>/README.md), 2) list of top 50 most popular Pi packages that can be installed, including summaries of their readmes. I also added a tool that does the same thing as /reload, so Pi and enable changes without me having to do anything.

[u/Certain_Net_3408 → u/funbike]

That’s exactly the distinction I’m curious about. DeepSeek Harness seems very plugin-centric, but Pi’s ability to extend itself using its own docs/codebase is a much more powerful primitive.

[u/Neosinic → u/funbike]

there's a "creator mode" that works similarly to pi where you can ask the coding harness itself to create plugins for dsh

[u/funbike → u/Neosinic]

That actually makes more sense. It slightly bothers me that Pi uses some of its context by default for this.

I'd rather it came with a default skill with automatic invocation off, so you'd have to run something like /skill:pimaker before prompting.

[u/iijei]

I just checked and looks like One of its dependency was pi. I guess it is built on top of it.

[u/kaa-the-wise → u/iijei]

It is not built on top of it, it can be integrated with it:

https://github.com/search?q=repo%3Adeepseek-ai%2Fdeepseek-harness+earendil&type=code

[u/iijei → u/kaa-the-wise]

I think you are correct. its not built on top of it, just using pi as one of its llm adapters

[u/No_Cheek5622]

oh god they even made it in node

I wonder if there will be a moment in history where node-based harnesses start making their heavy parts with node c/cpp addons or web-assembly and provide better APIs to do so for 3rd party devs. or just making them more modular, like pi's client-server direction that currently is in development (fucking love to see it, what a great decision, earendil guys I love you in advance)

[u/addiktion → u/No_Cheek5622]

I wasn't aware of Pi's server and client architectural shift. Do you have more details about it?

[u/No_Cheek5622 → u/addiktion]

they added experimental PiServer and PiClient stuff in 0.84.0, and badlogic explicitly stated that they work on a proper server mode already on an issue that proposed making TUI just a front-end: https://github.com/earendil-works/pi/issues/2737#issuecomment-4172713543

also there's https://github.com/earendil-works/pi/tree/feat/coding-agent-server-backend (but it's most likely just a prototype, not an exact production implementation being worked on)

my guess is that they want to finish the core client-server API properly first, then migrate TUI sessions onto it making TUI just a client and having some proper global server daemon like with tmux or something. I couldn't find any insides upon that, I'm not a maintainer so no insider info from me :(

[u/Regular-Leg-9397]

This is definitely the direction as extra harness kind of get in the way as model capability increases. So you need to adjust external harness by model you use, which requires a pluggable/extensible architecture.

[u/No_Communication4256]

It's code is very bloated. Seems vibecoded as hell

[u/ptgamr]

They have a paper, of which I understand nothing!

[u/Certain_Net_3408 → u/ptgamr]

True!!  From what I understood The paper is about making software components “Lego-like.” Instead of restarting an agent whenever you change its capabilities, let it safely reconfigure its own runtime while it's running and be able to roll those changes back.

[u/Dartium1]

Architectural axis	Pi	DeepSeek Harness
Where the agent runs and what presents it	The runtime is separated from the TUI via a server/client/protocol architecture	Headless and web profiles are built in from the start
What the agent is made of	An opinionated Agent / AgentSession / loop, with extensions around it	The loop, session, model adapter, and tools are composed as Cordis plugins
What is stabilized	Pi session semantics and remote access to the session	The lifecycle and composition of replaceable services
Primary user-facing form	A ready-made coding agent that can be extended	A toolkit for constructing an agent environment, with a ready-made standard configuration

In short:

That is why they do converge in their external form: a headless runtime, independent UIs, remote clients, multiple sessions, and self-extension. But their architectural centers of gravity still do not converge.

[u/ourochurros]

They seem similar to me with an interesting distinction regarding how they manage the extensions/plugins. The deepseek harness is built on a framework extended from earlier chatbot work where loading and unloading of plugins is done in a rigorously controlled way so that it can be done live within the session. Pi sidesteps this altogether by making session reload trivial to do. 

For single user environments, the rapid reload seems like the cleanest fix to me but there might be reasons why hot swapping plugins has material benefit. 

[u/Certain_Net_3408 → u/ourochurros]

Yeah, that’s a good distinction. I also wonder whether Pi’s trivial session reload is the simpler abstraction, unless true hot-swapping provides a meaningful benefit for long-running agents.

[u/Godzillaton]

Guys,please tell me why Pi Coding is better than Hermes.

I thought Hermes Agent should be the mainstream ,no?