The official release opened up the “whole-suite app API.” Web search, file parsing, speech — capabilities that until then existed only inside the App — now work from the API by declaring a parameter. The pitch line is “reproduce the complete DeepSeek App, 1:1.”

That same evening, DeepSeek Harness shipped v0.2.2-rc.3. It added exactly one thing: import the conversation history sitting in the DeepSeek App into your workspace and keep talking.

One side pushes capability out. The other pulls data in. Neither is big news alone; together they say something. The vendor is disassembling its own App while the community stitches its own history back together.

I ran both on my machine. Some numbers don’t match the docs.

First, What They Actually Opened

What got opened is really two layers: parameter switches, and standalone endpoints.

Layer one is switches. In the existing Messages, Responses and Chat Completions APIs, declare the tool and it works: deepseek_web_search handles web search and deep-thinking search, deepseek_read_url reads a link, and file input and model safety each get a parameter.

The key is one line of documentation: search and fetching both happen server-side, the client executes no tools.

That line decides how you use it. You don’t write your own scraper and wire it to the model; you send one request and the server walks the middle steps for you.

Layer two is standalone endpoints. Search, Fetch, OCR, ASR and TTS can each be called on their own, without going through a chat model. Take that route and you are the one assembling the workflow.

Together, the official positioning is “turn the parameters on and you have the App.” I checked how much of that holds up.

One Call, Three Searches on the Server

I tried the simplest possible request against the Responses API: ask when Kotlin 2.5.0-RC ships and what’s in it, answer in three sentences.

The request body had three fields: model deepseek-flash, tool deepseek_web_search, one line of input.

The response came back at 6,969 bytes in 4.2 seconds. Not one answer — five content blocks in sequence: reasoning, search call, reasoning, search call, answer.

The first search block says kind: "deep_search". The model issued three queries on its own, mixing Chinese and English. One asked about the release date and features in Chinese, one used site:kotlinlang.org to pin results to the official site, and one went straight for the release announcement page.

Those three queries brought back 16 sources, each with url, title, snippet, site_name and published_at. I counted: official kotlinlang.org doc pages sitting alongside reposts on third-party forums.

That’s the real cost of “the server walks it for you.” You say one sentence; it searches three times behind your back.

You Pay Per Tool Execution

One field deserves its own section: server_tool_use. This call returned tool_search 3, tool_fetch 0, tool_image_search 0. Three searches, no fetches, no reverse image search.

The same usage block carries input_tokens: 11799 (4,608 of them cache hits) and output_tokens: 761 (433 of them reasoning tokens).

Of those eleven thousand input tokens, the overwhelming majority is the content of those 16 sources, not your question.

So when the docs say “tool call fees are charged on top of token fees,” the thing being counted is server_tool_use. You write one line of tool declaration in your code, the bill grows three lines of search fees, and you don’t control how many times it searches.

Five Standalone Endpoints, Tried One by One

If your use case doesn’t need conversation, calling the standalone endpoints is cheaper. I ran the three I could verify locally.

TTS was the cleanest. Send a Chinese paragraph plus a voice_id, get a wav back in 2.09 seconds. The default voice stella returns 276,524 bytes, 5.76 seconds, 24kHz; switching to tide gives 261,164 bytes, 5.44 seconds. Same text, male voice 0.32 seconds shorter than female.

ASR closed the loop on that wav. 1.2 seconds to return, duration_ms: 5760, matching the 5.76 seconds afinfo measured locally.

The transcript has a trap, though. What I said was “多字段的 value class 在字节码里就是一个普通类，没有 box-impl” — a multi-field value class is just an ordinary class in bytecode, no box-impl. What came back was “多字段的Value Class在字节码里就是一个普通类，没有Box应用.”

box-impl came back as “Box应用” — Box app.

This isn’t an ASR-specific defect. Anyone dropping English technical terms into Chinese speech recognition hits it: the model hears the sound and guesses the closest Chinese word. Write code comments by voice and that error walks straight into the repo.

For OCR I used a cover image I’d made myself: 2.29 seconds, 481 input tokens for 131 output tokens. Layout like “36.0 字节 / 次” (36.0 bytes per call) and “0 / 2 迁移开关” (0 of 2 migration switches) — decimal points, slashes and all — came back accurate, right down to the middle-dot separator.

Harness Added Exactly One Thing

That same evening dsh v0.2.2-rc.3 landed, commit 38a6a5c, by imccyu and winewill.

Two changes: a new experimental “DeepSeek chat import” plugin, and a fix for in-app updates failing on the Windows desktop build.

The second is a plain bug fix, nothing to unpack. The first is worth discussing, because it pairs with the API released that day: the official demo supports importing past conversations, and dsh turned that into a plugin.

The plugin is an optional layer — the release notes state plainly that shipped profiles don’t include it. You mount it by hand:

- insert:  # appended to the end of the profile's patch layer
    - id: deepseek-chat-import
      name: '@deepseek-ai/dsh-deepseek-chat-import'

Usage: click the upload arrow next to “New session,” pick a deepseek_data-*.zip, then pick the workspace that should receive the conversations.

The Upgrade Hit a Wall

I upgraded my everyday web profile first. npm install -g @deepseek-ai/dsh@0.2.2-rc.3, it installed 0.2.2-rc.3, I restarted.

The startup log flooded a screen:

disabling profile plugin row "storage-domain": Plugin
@deepseek-ai/dsh-storage-domain@0.2.2-rc.1 is incompatible with dsh 0.2.2-rc.3

storage-domain, plugin-market, cua, ui-cua, tool-plugin-market, cua-provider-registry — all six disabled. Same reason every time: the profile has rc.1, the main package is rc.3, the versions don’t line up.

Then the chain reaction: storageDomain can’t start, so workspaceRegistry goes pending, session-controller follows it into pending, and the plugin I actually care about sits in the list waiting on workspaceRegistry.

Nothing was broken about the plugin. It was held up by upstream. This is the other face of the “Everything is a Plugin” philosophy: the finer the composition, the further one version mismatch cascades through the whole stack.

A Clean Profile and It Runs

Rather than touch the dependencies of the profile I use daily, I spun up a fresh one from the official template: dsh --profile chatimport --from-default-profile web --port 3081, a different port so it wouldn’t collide with the original.

The new profile carries just two bundles, @deepseek-ai/dsh-base and @deepseek-ai/dsh-web-app. Clean. Add that insert block, restart, and the log shows no disabling lines and nothing pending.

The UI gained a button. I dumped every button on the page through the accessibility tree; the second one is called Import DeepSeek chats, 38 pixels square, right next to New session.

So the plugin is alive. The question becomes what to feed it.

Import Test: Three, Two, One Skipped

I don’t have a real export package, so I reverse-engineered the structure from the zod schema in the plugin source and built one.

A valid export ZIP needs three things: manifest.json with export_format_version: 3, a chat_session_index.json listing sessions, and one chat_sessions/{id}.json per session. The session file holds a message tree, each message carrying id, parent_id, role, status and fragments.

I built three sessions: a plain Q&A, one with web search and multi-round reasoning, and one designed to test filtering.

In the first version I made “content filtered” mean message status FINISHED with a CONTENT_FILTER fragment stuffed in. The result dialog said, flatly: Imported 3 sessions into the smoke-test-connectivity-f0b666d1b2bb workspace.

All three came through, including the one that should have been dropped. I went into the conversion source and found the check reads exactly one field: if (reply?.status === 'CONTENT_FILTER') then continue, with the counter increment as its own separate step.

The filter looks at the message’s own status, not the fragment type. I fixed that and rebuilt the package; the second dialog said Imported 2 sessions, followed by 1 conversation could not be imported.

Two in, one skipped. That matches the docs: “a question whose answer was withdrawn by content filtering is omitted along with the answer, and sessions with no other turn are not imported.”

Which confirmed something else: import the same package twice and the sessions duplicate. My workspace sidebar now shows five sessions, with the Kotlin one and the Flutter one each having two copies, and the filtered one still single. The importer keeps no record of what it has already imported.

Import Writes Locally; Only Chatting Touches the Model

Opening an imported session, the history is complete: my questions, my answers, the timestamps, rendered as 11/10 17:00, with 1 turns 1 steps at the bottom.

Then I sent a new question straight into that session to see whether it could keep talking. I got a red line: This turn failed, saying the deepseek-official provider route has no API key, to write one through the credentials service or export one in the startup environment, with a MISSING_CREDENTIAL code at the end.

The new profile has no credentials configured — that’s my environment. But the error itself proves something: import never called the model at any point, or it would have stalled here first.

The red “Injected context” line in the UI says the same thing: the history is already in context, there’s just nobody reading it. In the screenshot, that failed turn pushed the bottom stats to 2 turns 2 steps.

Two Roads, Two Different Problems

Put the two side by side and they answer different questions.

The whole-suite API answers “how do I build something that behaves like the DeepSeek App.” It wraps the dirty work — search, parsing, speech — and sells it to you: token fees plus tool fees, in exchange for not building your own retrieval and parsing.

Chat import answers “how do I stop losing what I’ve already talked through.” It has nothing to do with the model — pure local read and write, splitting a ZIP into session files and writing them into a workspace.

On my machine the first produces a result in four seconds, the second puts three sessions into the sidebar in one. But the first asks you to trust that its server searched three times on your behalf, and the second asks you to accept that importing the same package five times will write five copies.

Two things shipped the same day: one pushing capability out, one pulling history in. If you have to pick one to start with, it comes down to whether you’re short on capability or short on memory.

I went to upgrade that same night. npm did not have that version at all.

Three places, three version numbers

GitHub Releases had dsh-v0.2.2-rc.2, published at 11:33 on the 11th. I tried to install it and npm returned notarget.

A quick look at dist-tags: both latest and next still pointed at 0.2.2-rc.1.

The desktop app was older still, sitting on 0.2.1-rc.2. So my machine was holding three version numbers at once and none of them was rc.2.

That is not a DeepSeek Harness flaw, every release process behaves this way. But it decides when you can actually use a new feature: either wait for npm to catch up, or switch the desktop app to the dev update channel, which is itself something rc.2 introduced.

So I reproduced it myself

Since I could not install it, I reproduced what DeepSeek Harness does on my own machine.

Worktrees, comparing by branch, slicing by file type: all of that is git commands underneath and has nothing to do with the client. I used my own repository, 21,711 files and 60,037 commits, as the target, with a 50-file repository alongside as a control.

Starting with the slowest step: creating a worktree.

Small repository: 32 milliseconds, three runs at 31, 32, 32.

Large repository: 1.5 seconds, three runs at 1.47, 1.49, 1.51. Rock steady. A 46x gap.

The checked-out worktree occupies 275 MB, but .git is shared, so the 840 MB repository was not copied again. That design saves a lot of disk.

1.5 seconds is not long, but if an agent creates a worktree on every edit, with network round trips, disk jitter and a pile of invisible waiting mixed in, that 1.5 seconds becomes a bet that could time out at any moment. The release notes say “relaxed the wait time for creating worktrees in large repositories,” and this 1.5 seconds is what that refers to.

Three review dimensions, all in milliseconds

I made two rounds of changes inside the worktree to simulate an agent at work: 40 files in the first round, 240 in the second, totaling 311 files and 28,458 lines against the main branch.

Then I compared along the three dimensions it describes.

Stats by branch: 65 milliseconds. Full body: 75. Grouped by file type: 29. Log by commit: 26.

All four are under a hundred milliseconds. Nothing at the git layer is slow.

Here is the counterintuitive part. A 28,458-line, 1.27 MB diff takes git only 75 milliseconds to compute. I expected it to dominate and it turned out to be the fastest thing in the room.

Pick the wrong baseline and you review nothing

I stepped on something here worth writing down.

My first comparison used git diff main...HEAD. Three dots means comparing against the merge base of two branches. It printed zero files.

The reason is simple: local main on that repository was far behind, so HEAD was itself an ancestor of main. The merge base resolved to HEAD, and comparing a commit against itself is of course empty.

Switching to origin/main...HEAD immediately gave 311 files.

Same repository, same branch, only the baseline changed, and it went from 0 to 311 files.

So the thing to be careful about with review-by-branch is not whether diff is fast, it is what the diff is comparing against. If the agent’s branch was cut from an old baseline, you will see considerably less than was actually changed, and nothing will warn you.

Three dots compare merge bases, two dots compare endpoints. That distinction rarely matters until review is automated, at which point it becomes the difference between seeing the change and not seeing it at all.

How to read those 28,458 lines

Since git is not slow, the slowness must be elsewhere. Split the diff by extension and the answer surfaces.

Python: 187 files, 12,468 lines, 43%. JSON: 52 files, 5,690 lines, 20%. TypeScript: 46 files, 2,647 lines. TSX: 12 files, 1,526 lines.

The interesting part is those 5,690 JSON lines. Lock files, contract snapshots, config exports, a fifth of the total line count, and under five percent of it needs to be read line by line.

The value of review-by-file-type is not tidier categorization. It is having a principled reason to skip an entire 5,690-line folder.

What a worktree saves is not disk

I assumed worktrees would eat disk space. Measured, that worry was unfounded.

Against 21,711 files and an 840 MB .git, the worktree occupies only 275 MB, because .git is shared and only the working tree gets copied out.

What those 275 MB buy is isolation: one repository can host several worktrees, each on a different branch, without interfering. Agent A edits code on feat-a while agent B edits elsewhere on feat-b, and each side has its own working tree and index.

A sandbox or a full repository clone costs you 840 MB of disk plus tens of seconds of copying. A worktree costs 1.5 seconds, and throws in branch isolation for free.

That is also why review is built on top of worktrees. The branch is there, the commits are there, the files are there, and whichever dimension you slice by, the raw material is already in place.

The bottleneck is context, not tooling

Put every stage’s number side by side and the conclusion is clear.

Creating a worktree: 1.5 seconds. Producing the diff: 75 milliseconds.

Hand that diff to a model and it is 1,268,059 characters, roughly 300,000 tokens.

What is 300,000 tokens? Mainstream models now carry context windows around 200,000, so this single change does not fit, before counting repository structure, the task description and your own question.

So when rc.2 says “reduced jank when viewing large changes,” what it is janking on is not git. It is the layer that renders this pile, feeds it to a model and puts it in front of a human. No amount of optimizing those millisecond figures helps, because the real ceiling is here.

Review by file type, by commit, by branch: three paths that are three ways of cutting. Cut it down far enough and only then can a model finish reading.

The one I could not test

rc.2 added two more things: named and multi-level SubAgent collaboration, and AgentTeam that can be enabled per session with shared members and a task panel.

I cannot reproduce that locally, because it is not a git-layer concern, it is orchestration. And rc.2 is not installable from npm, so all I have is rc.1, and running that would not show rc.2 behavior.

So I only write what I verified. That one is for people who can actually get their hands on it.

What you can do now

If your agent already works on branches, two things are worth changing today. First, give the worktree directory a fast disk. Most of that 1.5 seconds is disk I/O, and a spinning disk or a network volume makes it worse.

Second, read the stats before the body. 312 lines versus 28,458 is a 90x difference, and reading the former first can filter out half the files you do not need to open.

As for DeepSeek Harness rc.2, it is a matter of waiting for npm. Once you have it, the first thing worth doing is running worktree creation against your largest repository to see whether your machine takes 1.5 seconds or 15.

That number decides whether you let it branch freely, and whether your pipeline can run several agents editing the same codebase in parallel. A 1.5-versus-15-second difference on one machine ends up being the difference between “three agents at once” and “one at a time,” two entirely different architectural choices.

One thing has to be said up front. This version is not the latest one on npm yet. A plain install still gives you 0.2.1-rc.2, so you have to pin the version number by hand.

npm install -g @deepseek-ai/dsh@0.2.2-alpha.2

Skip that version number and nothing I describe below will be visible to you.

Then I started it, and there was the problem. Three consecutive disabling profile plugin row lines in the log. Three of the things I had installed were taken away.

npm had also flagged something during the install: install scripts for five packages were blocked, including two native modules, node-pty and koffi. I stared at it for a while and started the app anyway. The web UI opened, the model list loaded, nothing seemed broken. I filed that away to look at later if something misbehaved.

Three lines hit me the moment it booted

Here is the log, verbatim.

dsh: disabling profile plugin row "plugin-market":
  Plugin @deepseek-ai/dsh-plugin-market@0.2.1-rc.2
  is incompatible with dsh 0.2.2-alpha.2:
  requirements {"@deepseek-ai/dsh-plugin-manager":"0.2.1-rc.2",
                "@deepseek-ai/dsh-settings":"0.2.1-rc.2",
                "@deepseek-ai/dsh-tools":"0.2.1-rc.2",
                "@deepseek-ai/dsh-typert-protocol":"0.2.1-rc.2"}

The three that got disabled were ui-agent-team, plugin-market, and tool-plugin-market. The last two are actually the same package, referenced by two different config rows.

The requirements block is the whole story. It reads "0.2.1-rc.2". No caret, no tilde, four exact version numbers. And the four internal packages at runtime had already moved to 0.2.2-alpha.2.

Exact match fails, plugin gets rejected. DeepSeek Harness handles it cleanly: it does not load the plugin, it does not throw, it prints one warning line and keeps going.

That design is actually right. Letting a plugin that declared “I was only tested against these versions” run on a newer runtime makes the eventual crash far harder to diagnose. Rejection beats loading something broken.

The cost lands on the user though. You bump a version, things you installed disappear, and because it is a warning rather than an error, it is very easy to miss.

The fallout spreads to the plugin market

I had a custom plugin index configured. It lives at line 12 of ~/.dsh/profiles/web/cordis.patch.yml and points at a local static server.

After the upgrade I opened Plugins → Discover and got one line in red:

Could not read the index sources.

There was a Retry button next to it. Clicking it returned the same line.

My first instinct was the static server. lsof -iTCP:3489 came back empty, so the service had died at some point. I assumed that was the whole story, brought it back up, and curl returned 200 with a 3,764-byte index.json sitting there.

Back to the browser, clicked Retry. Same red line.

Same red line on the second try, and only then did it click: reading the index is itself an action performed by plugin-market. The index source was fine. The thing that reads it was gone. An empty page either way.

So there are two layers stacked here. On the surface the index source was down. Underneath, the plugin that reads it had been disabled.

I also tripped over a hole of my own making, worth noting. The serve.py I use for reproduction hardcodes its access log at /tmp/market/access.log, and I had cleaned that directory out. Every incoming request threw before it could respond, so curl returned exit 52 with an empty body. Creating the directory fixed the requests.

There is an official switch, buried in the warning text

The tail of those three warnings does give you a way out. It mentions dsh plugin allow-version, or the plugin manager, to grant an exemption for an exact version.

I read the help first. The plugin subcommand documentation for DeepSeek Harness does not mention this at all. It only says the remaining arguments are forwarded to pnpm.

So I just ran it, and the usage fell out on its own:

dsh: Error: usage: dsh plugin allow-version <package@version>
                   --dsh-version <exact> --accept-risk

Filling that in, one exemption per plugin:

$ dsh plugin --profile web allow-version \
    "@deepseek-ai/dsh-plugin-market@0.2.1-rc.2" \
    --dsh-version 0.2.2-alpha.2 --accept-risk
dsh: allowed @deepseek-ai/dsh-plugin-market@0.2.1-rc.2 for DSH 0.2.2-alpha.2

The exemption is scoped to one package at one version. A different version and you have to grant it again. After restarting DeepSeek Harness, the three warning lines were gone from the log, Discover read the index immediately, both plugins listed properly, and category and tag filters were back.

One note: --accept-risk means what it says. I got lucky here and the plugin ran without incident. That is not a guarantee.

What the new interface looks like

The plugins page now has two tabs, Installed and Discover. Installed splits into two sections.

The top section is Built-in plugin settings, four entries. Subagent governs recursion depth, count, and model. Web search configures the DeepSeek search source. Agent loop controls how the agent dispatches tool calls. Shell limits how long a single command may run and how much output it may produce.

The bottom section is Experimental plugins, five entries, each with a toggle:

Agent teams lets the agent split work across named teammates that share a task board and report results back.

Voice input transcribes locally with SenseVoice; the first use requires installing dependencies.

Custom plugin indexes is what adds the Discover tab to Plugins, letting you browse and install from index sources you add.

Auto authorization review is a new review mode: before each tool call the model checks it against your original request and batch-approves the ones that comply.

Change requests & worktrees tracks each session’s change requests along with their check and review results, and can start new sessions directly inside a Git worktree.

Of the five, the first two are on by default and the last three are off.

Two things that actually changed on the plugins page

After all that, it is worth looking back at what this upgrade actually delivered.

The plugin detail page now renders the package’s own README. Click into an experimental plugin and you get the full documentation, with an English and Chinese toggle, a summary, a table of contents, and a section called Use this package further down.

More interesting is that the same page breaks the bundle into its 5 components, listed one per row, each with an icon, a one-line description, a short name, the full package name, and its own toggle on the right.

Take the Change requests & worktrees package. Expanded, it is five parts.

Change requests, GitHub change requests, Session change requests, Worktree service, Change request panel. The top of the page reads Components 5 total · 5 off.

The bottom also shows provenance: Code source is Built in, current version 0.2.2-alpha.2.

This is far clearer than the old “one plugin, one switch” model. You can inspect each part of a bundle and flip them independently, and you no longer have to open a config file to find out what is installed.

Where I land on this

The interesting part of this whole episode is not the trap I fell into. It is the design tradeoff the trap exposes.

An exact-version lock keeps the plugin ecosystem safe, and the price is that any runtime upgrade can invalidate a batch of plugins at once. It is especially visible between alpha and rc: bump a few internal packages and every plugin declaring a dependency on them drops offline.

DeepSeek Harness provides an exemption switch, but the default path is rejection. The bet it is making is “better to load less than to run something broken.”

For people building plugins, this means reissuing a version declaration every time you follow a runtime release. For people using plugins, it means knowing what you installed before you upgrade, because afterwards you may not even be able to tell what went missing.

DeepSeek’s official release notes for 0.2.2-alpha.2 also mention that a failed hot plugin update will attempt to restore the previous version. That mechanism protects updates already in flight. It cannot save the version check that runs before startup. The two pieces of logic do not touch each other.

This release also lists a few things I did not verify: subagent_oar can hand standalone tasks to a local Codex or Claude CLI, and the developer tools stats plugin can show context, cache, model, and tool timing by turn. The first one sounds the most interesting, but I could not find an entry point in the UI, so it likely needs a separate install and I left it alone. Same for the hot-update rollback: official wording, and I did not construct a failure to test it.

Do you check which plugins you have installed before upgrading your toolchain? Or are you like me, finding out only after things are gone.

References

• DeepSeek Harness v0.2.2-alpha.2 release notes: https://github.com/deepseek-ai/deepseek-harness/releases/tag/dsh-v0.2.2-alpha.2
• Test environment: macOS arm64, DeepSeek Harness upgraded directly from 0.2.1-rc.2 to 0.2.2-alpha.2, npm global install