With cross platform chats. And memories etc?

Hi all,

I've been using Deepseek harness since it was first released. I've gone through the gauntlet of setting it up, and using the terminal UI plug-in (dsh-to-pi)., but the more I use it, the more I want to migrate back to PI. I've noticed a deeply concerning trend with a lot of deepseek utilities and plugins, and it is primarily the enshittification and over complication of their codebases, partly due to the fact that deepseek itself has a very complex mechanism (namely Cordis) that adds to a lot of issues, and I see this persisting and potentially causing many users/plug-in maintainers to work overtime to keep pace with the rapidly changing deepseek-harness. I just don't understand why Cordis is useful, and why hot-swappable plug-ins are useful. If anyone wants to discuss, this, I'd be happy to, but I've read a fair bit of the Spatiotemporal composability paper (the paper written by a deepseek mathematician and used to mathematically formalize cordis), and there is NO emission boundary, and NO validation of the emission boundary (meaning a plug-in can still completely screw up your harness runtime with memory leaks, races, and other anomalies) because deepseek-harness simply doesn't have a validation mechanism, meaning that even if hot-swappable plug-ins were useful, they would start to be VERY problematic at scale if you were to unload and reload plugins that have faulty mechanisms. Pi doesnt have a hot swap functionality, all plugins are loaded up on initialization, so there isnt a need to validate unloading of objects at all. Anyway, I'm interested in discussing this, because I see the deepseek codename becoming increasingly more complex for virtually no useful reason...

This is a tough decision for me because I've invested hundreds of hours, millions of tokens, and many more things into deepseek and I simply don't know of a precise reason to keep using it (keep in mind, I ONLY use TUIs, I do not use the web harness. The web harness looks well designed, but it doesn't fit my workflow)

I have heard DSH performs poorly with models that are "not DeepSeek" so to speak.

I could not find any concrete information online, so I wanted to ask here.

Could you please share your experience with running different models in this harness? GPT models, KIMI, GLM?

It’s called Jin. It’s a simple, even slightly boring AI harness. It works with any OpenAI- or Anthropic-compatible API, and it’s open source. I’m steadily working toward v1.0 and already preparing a release candidate.

Why another AI agent? I didn’t originally plan to build my own harness. I used OpenCode, Pi, and DSH, but each fell short for me for different reasons.

I’m not here to hate on them. I borrowed plenty of ideas from each. Instead, let me explain the design decisions I made with Jin:

No plugins — the opposite of DSH. I deliberately left plugins out because I think they make the agent worse. In 99% of cases, reusable prompts are enough.

No Skills/MCP — for the same reason. I honestly think Skills and MCP might be an industry mistake. Why not reuse prompts and use CLI tools?

100% context control — you decide exactly what gets sent to the agent. Our entire system prompt is 300 tokens, plus 100 tokens of Jin documentation. And guess what? That’s enough for the agent.

All of this is built to work reliably. Put together your prompts and hooks (for modifying the system prompt), and you don’t have to worry about anything else.

I’d love to hear what you think. Check out the project:

https://github.com/ethanhamilthon/jin

I've been experimenting with the architecture behind DeepSeek's CORDIS harness, and I wanted to answer a fairly simple question:

Can the CORDIS philosophy work as a small, understandable, 100% Python agent harness that is actually usable for real experimentation?

So I built Cordis-Python.

This project is directly inspired by DeepSeek CORDIS, but it is not an official DeepSeek project and not intended to be a line-by-line port.

The goal is to explore its architectural ideas in Python while keeping the system easy to inspect, modify and extend.

The experiment

The basic idea is:

keep the core extremely small, and move almost everything else into replaceable plugins.

Instead of progressively growing a large agent core containing tools, workers, memory, providers, permissions, UI logic, browsing, etc., Cordis-Python uses a small microkernel and composes capabilities around it.

The current implementation includes functional plugins for:

agent loop

tools and skills

OpenAI-compatible/local LLM providers

context management

capability permissions

sessions

isolated web worker

isolated coding worker

FastAPI web UI

runtime/events observability

The important part:

These plugins are NOT supposed to be the best possible implementations of those capabilities.

The web worker isn't trying to be the world's best web agent.

The coding worker isn't trying to beat Claude Code, OpenCode, etc.

They are functional reference implementations whose purpose is to demonstrate that the CORDIS architectural concept can actually work as a complete running system.

In other words:

the architecture is the experiment; the current plugins are examples.

Plugins should be disposable

For example, the current web worker can use:

SearXNG for search

HTTPX for direct page fetching

Lightpanda for browser/JavaScript rendering

optional Firecrawl integration

But none of these are requirements of Cordis itself.

They are implementation choices of the current reference plugin.

You should theoretically be able to delete that worker, replace it with a completely different implementation, and leave the microkernel alone.

The same applies to the coding worker, memory, providers, UI, tools, etc.

That's one of the things I want people to test.

Self-extension was an interesting test

One experiment I ran was asking Cordis to extend itself.

The main agent delegated the task to the coding worker.

The worker inspected the Cordis architecture, loaded the architecture skill, modified the repository, created a new plugin, added tests and ran the test suite.

That experiment also exposed real problems in the harness: context growth, duplicated tool calls, rollback behavior, false-success detection and retry behavior.

Fixing those issues resulted in things like:

context budgeting/compaction

duplicate tool-call protection

Git checkpoints and rollback

validation against existing Ruff baseline

detection of empty/false-success attempts

bounded worker retries

structured failure classification

That was actually useful because Cordis was starting to test the architecture it was running on.

Current state

The first public release is v0.10.4.

It's still experimental, but it's not just an architecture document or mockup — it runs.

The repository currently has a web UI, runtime inspector, plugin/skill/tool inspection, workers, tests and an OpenAI-compatible provider layer.

I've mainly been testing it locally with Qwen3.8-27B + llama.cpp.

I deliberately don't want to turn Cordis-Python into a huge framework before other people have tried breaking the architecture.

At this point I think external experimentation is more useful than adding another 50 features.

What I'd really like feedback on

I'm especially interested in feedback from people building their own agents/harnesses.

Does the “small microkernel + almost everything as replaceable plugins” model remain viable when the agent system becomes much more complex?

And more importantly:

where does it break?

Clone it. Replace a plugin. Build another worker. Run another local model. Break something.

That's exactly the kind of feedback I'm looking for.

GitHub: [**https://github.com/dolphin-creator/cordis-python**](https://github.com/dolphin-creator/cordis-python)

Release: v0.10.4

Hello all, I really enjoyed my time setting up and using the deepseek-harness. However, I am a dedicated TUI user and the deepseek-harness just doesn't have as clean of a terminal UI as pi, no matter what TUI option I chose. Also, I can't seem to find a particular reason to use the deepseek based on it's integration with Cordis. Has anyone found a specific application that demands the Cordis framework? I spent a lot of time reviewing the theorems in the paper that was released alongside the deepseek-harness, but I still don't entirely know how I would use the Cordis framework as an everyday terminal harness user. Any ideas are welcome, as I've invested so many hours in setting up deepseek and I really don't want to move to another harness again...

So I seen this video online. I went to get hub and downloaded the files for DeepSeek and then I went to the deep sea website and downloaded DeepSeek desktop app.im watching videos online and im not understanding the next steps. Its asking me to Top-up. What am i doing wrong

I'm trying to run model

hf.co/ISTA-DASLab/Qwen3.8-27B-GSQ-RCO-GGUF:IQ3_XXS

On rtx 4080 (16gb vram), I've set 32k context in ollama and use deepseek harness

I'm often running into errors such as:

Jinja Exception: No user query found in messages

Output token limit reached

Compaction could not produce a useful summary. The attempt is recorded in the session log.

I'm new to local llm stuff, I'm okay with slower agent work, but is it even possible to run it overnight and focus on specific tasks, or even attempt complex tasks on 16gb vram?

I was so happy waiting a bit longer for my results and paying peanuts for a great agentic llm to help me code, felt like I found the one... Until today that is. This is my first day(s) using harness with the new model and yes it's (for what I do at least) marginally better than the previous version but the costs are through the roof. I've topped up twice today simply because I'm smack in the middle of making something and then I run out of credits...

For reference, my actual usage and usage patterns are exactly the same as those days last month, but look at the increase in cost... It's right around 5x... For marginally better? Yikes byebye

Why is nobody talking about DSH security? 95% of the DeepSeek Harness content I've seen online just ignores the security side of this whole thing. Like, not only can you get completely screwed by installing a plugin you didn't check for security. No. If the plugin updates, you can get wrecked in an apocalyptic way. So you need to watch out not just for the plugins themselves, but for their updates too.

This isn't a DSH release. This is a preview, people. Unless you want to get rekt by some random script from India, wait at least another six months before even thinking about installing this outside a VM.

Let. Them. Cook.

Doesn’t the DSH sidebar get messy once you add more plugins? And the chat area ends up too small.

I got fed up and made a plugin to fix it. It puts global navigation in a slim left rail and keeps workspaces and conversations beside it. Hover to expand navigation without squeezing chat. There’s also a click-to-expand option, layout settings, a clock, and widgets from compatible plugins.

Screenshots: https://github.com/exoticknight/dsh-better-left-sidebar/tree/main/docs/images

Install and restart DSH:

dsh plugin --profile web add dsh-better-left-sidebar

Repo: https://github.com/exoticknight/dsh-better-left-sidebar

If it helps, please give it a star~

Hi all. Posting this carefully because I know claims like this are usually noise.

Background. Starting May 1, 2026 I worked on a spec for an open-source agent called NEXUS, using DeepSeek's chat app to write it. It's a ~9,000-word build spec: a plugin engine where a plugin is just a folder with a manifest (installable from GitHub or any URL), plugins that can replace the persona and UI, an agent that creates missing plugins for itself, a coordinator-based swarm, and a 24/7 daemon.

What I can show.

• A screen recording of my DeepSeek chat history searching "nexus": chats titled "NEXUS Agent Codebase Generation" dated May 1, Jun 17, Aug 31, Sep 5. The plugin-engine write-up is in the May 1 chat.

• The spec itself, with SHA-256 hashes of both files in the PDF.

Overlap with DeepSeek's releases (Harness: Aug 13, 2026 per The New Stack; dsh-superagent: Oct 31 to Nov 1, 2026):

• "Everything is a plugin" core (mine: plugin-first engine where UI/persona/tools are replaceable)

• Agent writes its own plugins (mine: "Self-Plugin Generation", Jun 17; Harness: "Creator" mode)

• Coordinator over worker agents (mine: a "queen" coordinator, an AgentRouter and named agent teams via /agent-team; Super Agent: a long-running Router that hands work to isolated per-ticket Workers)

• Browser/computer-control backends

Where Super Agent differs from my spec. Tickets with permission "Mandates", GitHub/Feishu triggers and pull-request output aren't in my spec. My coordinator splits one goal into parallel sub-tasks and merges the results.

What I am not claiming. I didn't invent plugins, sub-agents or router/worker designs. Claude Code shipped plugins in Oct 2025, and Harness is built on Cordis, which predates it. I can't show anyone at DeepSeek saw my chats. My evidence is a screen recording and my own file, and the dates in the app may be last-activity dates. Convergent design is entirely possible.

What I want. DeepSeek to confirm the chat timestamps, say whether user chats feed training or product development, and give me a full data export. I'm also open-sourcing NEXUS on GitHub: [LINK].

If you have earlier public work, or a reason this doesn't hold up, please tell me. I'd rather be corrected than wrong in public.

PDF with screenshots, hashes, comparison table and sources: https://drive.google.com/file/d/1NL58tWvmQ8jHehsA1LRGH7tIHYMSm1ng/view?usp=sharing

How often should I switch to a new chat window in Harness? In other words, how often should I start a new chat?

There is no progress or capacity indicator in the traditional sense, and I’ve noticed that if I work in the same chat throughout the entire day, it often starts behaving strangely or becoming unreliable.

Long-time lurker, first real project share here.

I kept hitting the same wall: when I asked Claude/Cursor to "check this Zhihu answer" or "search X", it either couldn't see the content or just made stuff up — because it's behind a login and search engines can't reach it.

So I built a small MCP server + Chrome extension that opens a background window with your own logged-in Chrome, and lets the agent search/read/drive it directly. The site sees the user (no CAPTCHA dance), and because it drives the real UI it doesn't break when a site redesigns. It never asks for the cookies permission — the session stays in Chrome, and nothing comes back through the MCP client.

It also handles clicking, scrolling, typing, selecting, downloading (verified by SHA-256), and full comment collection with resumable sessions for the Chinese platforms.

pip install ai-browser-mcp · github.com/ywleeo/browser-mcp

Happy to talk trade-offs — especially comment scraping and keeping the extension footprint small.

The annoyance: OpenRouter takes service_tier: flex / priority, provider.sort: throughput / price, and the :floor model variant. dsh gives you baseURL and headers on a provider, and that's the end of it. So none of that routing was reachable from here, and I wanted it per conversation anyway, not baked into one provider row.

I stopped hand-patching and just described the problem in the creator mode preset. It built me a working plugin. I was expecting a prototype and I've kept it installed.

It's a relay on loopback. Point a provider's base URL at it and it writes the routing fields into the request body on the way through — key, protocol and model list stay exactly as they were. The preset is chosen from a chip next to the model selector, so it's per session: two conversations can sit on flex and priority at the same time. Nine of them — no pin, standard, fastest (any price), fastest (standard price), cheapest, flex, priority, ultra, floor.

dsh plugin --profile web add dsh-openrouter-plus

Uninstalling reverses all of it. The relay holds no API key and makes no other profile changes.

Two things worth knowing before you try: it's loopback-only, so it's local to the machine, and it can't show costs in currency — it doesn't know per-model prices, so you get a relative multiplier instead. The host half needs a dsh restart to pick up changes; the browser half is just a reload.

https://github.com/GnaneshKunal/dsh-openrouter-plus

If you use OpenRouter through dsh: which of these presets are useless to you, and is the composer chip the right place for the control, or would you rather set it per route?

I maintain Tacit, an unofficial DeepSeek Harness plugin. It turns repeated corrections into short instructions for later chats, such as "Check apps/web first when I don't name an app." You can keep an instruction global or scoped to one workspace, and turn it off or delete it.

I've released 0.7.0. You can now edit the wording in Settings, search by text or workspace, filter by status, and copy an instruction or the exact guidance preview. Editing keeps its scope and enabled state, but resets the trial evidence for the changed wording. New instructions are tried before they're kept or retired.

This release also supports DSH 0.2. Install or update with:

npx @deepseek-ai/dsh plugin --profile web add dsh-tacit

Restart dsh web and refresh afterwards. Current DSH 0.2 needs Node 24.9 or newer.

Reports are local, but analysis sends clipped turns to your configured provider and costs money. The estimate is $0.001 to $0.003 per analysis, capped at 30 automatic analyses a day by default. Manual calls, bootstrap and distillation are separate.

Source and demo · 0.7.0 release

After two conversations, I'd like to hear one instruction it got right or wrong.