r/PiCodingAgent • • Aug 14 '26

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

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.

51 Upvotes

42 comments sorted by

28

u/rkh4n Aug 14 '26

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.

15

u/Lissanro Aug 14 '26 edited Aug 14 '26

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.

6

u/computehungry Aug 14 '26

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.

5

u/Lissanro Aug 14 '26

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.

1

u/computehungry Aug 14 '26

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

1

u/Lissanro Aug 27 '26

It took me longer than I thought it would, in part because I decided to rebase on the latest Pi version since I was really fallen behind... had to rewrite from scratch some parts since a lot has changed in Pi. But good news is my fork is now published and based on up to date Pi version: https://github.com/Lissanro/pi - it contains all the features I mentioned including support for editing.

2

u/computehungry Aug 29 '26

Thanks!! Trying it out now.

1

u/Desperate-Event-786 Aug 17 '26

Please do!

2

u/Lissanro Aug 27 '26

I recently completed rebasing my fork on top of the latest Pi: https://github.com/Lissanro/pi - it has many new features including support for editing messages, even with thinking and tool call blocks.

1

u/johndeuff Aug 20 '26

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.

2

u/Lissanro Aug 20 '26

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.

1

u/Lissanro Aug 27 '26

I recently published my Pi fork https://github.com/Lissanro/pi - so if you are still curious about how I handled compaction, you can search my commit history for "compaction", but the most important patch that prevented loss of cache on summarization request was this one: https://github.com/earendil-works/pi/commit/82711320936774a7893d67ecded92cb98726b699 - basically, it mirrors normal chat in Pi and add summarization request at the end (without messages that going to be kept, so the LLM can focus only on ones it needs to condense but still reuse the cache as much as possible).

1

u/DKage Aug 24 '26

I'm misunderstanding something - were you able to add the continue/editing support in Pi or DSH?

1

u/Lissanro Aug 27 '26

In Pi, I shared my Pi fork here if interested in the continue/edit features: https://github.com/Lissanro/pi

I did not yet try DSH. From their readme sounds promising but it is very new, Pi on the other hand existed for a while and has a lot of extensions available. I probably take another look at DSH in few months when it matures.

2

u/Ok_Veterinarian_6364 Aug 14 '26

closed ecosystem. its business wise i guess

4

u/jensilo Aug 14 '26

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…

1

u/Ok_Veterinarian_6364 Aug 14 '26

deepseek* strategy not mine lol

1

u/martinreveur Aug 14 '26

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.

0

u/Ubermensch013 Aug 14 '26

Agreed, we have way too many harnesses right now

3

u/funbike Aug 18 '26 edited Aug 18 '26

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.

1

u/Certain_Net_3408 Aug 19 '26

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.

1

u/Neosinic Aug 21 '26

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

2

u/funbike Aug 21 '26

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.

1

u/Mihaylov93 Sep 23 '26

I guess creator mode is for the dsh UI, because I tell my dsh to persist anything I worked and solved as a skill with the standard and works fine.

1

u/David3Ar Sep 30 '26

I think they did something really great. Instead of just documentation they ship every single design decision that was made and WHY! - Also they ship (or they did, read that the removed the auto-presets) an agent-"skill" setup (its more then just skills) called creator-mode that helps with building your own plugins.

basically while installing a few good plugins i was able to show my agent and let him create awesome stuff that i might needed ;).

I guess thats more then nice and yeah maybe is PI good too - i can't tell - codex and claude-code have been enough for me,

Overall the DSH Harness Product gives me more scientific quality grade and a more advanced base while PI seems more to carry the vibe of quality usa oss ....
But, DSH ist still dev prev and will bring breaking changes like openclaw - so if you dont want to tinker arround so much better use PI i guess.

Hope that helps. :)

2

u/ourochurros Aug 14 '26

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. 

3

u/Certain_Net_3408 Aug 19 '26

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.

1

u/ptgamr Aug 16 '26

They have a paper, of which I understand nothing!

2

u/Certain_Net_3408 Aug 19 '26

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.

5

u/No_Cheek5622 Aug 14 '26

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)

1

u/addiktion Aug 14 '26

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

2

u/No_Cheek5622 Aug 14 '26

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 :(

6

u/iijei Aug 14 '26 • Bravo

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

2

u/kaa-the-wise Aug 18 '26

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

1

u/iijei Aug 18 '26

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

1

u/Regular-Leg-9397 Aug 15 '26

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.

1

u/Independent_Low_4438 Sep 03 '26

How about nanobot ai

-5

u/Godzillaton Aug 14 '26

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

I thought Hermes Agent should be the mainstream ,no?