Desktop, web and CLI: resource, update and offline

Desktop, web and CLI differ in more than features. Resource usage, update mechanism and offline ability are the three differences that shape daily experience.

Three differences people skip

Look past the feature matrix.

Resource usage decides whether you can leave it running. The desktop app carries a client shell, so memory and GPU use are highest; web reuses a browser; CLI is a service process.

Update path decides version consistency. Desktop updates itself, npm needs a manual command, npx pulls the newest every run. Mixing all three is how versions drift.

Offline ability is widely misunderstood. Every form needs a model service for conversation; the difference is local models and local operations.

Resource usage

Judge by uptime, not by one launch.

1. Desktop: client shell plus renderer plus plugins, the heaviest resident footprint.
2. Web: a browser tab, which grows with page complexity and plugin count.
3. CLI: a service process with no interface rendering, the lightest option.
4. Plugins: UI packs, video wallpapers and desktop pets add measurable usage.
5. Two instances: running desktop and the web service together means two runtimes.

Pick the light form for always-on use, and treat plugins as the hidden variable. Desktop suits interaction, not background hosting. If something must stay up, start the service with CLI and open a browser on demand. Ten UI plugins and two are different machines; when it stutters, remove plugins first.

Update path

Who owns the version matters.

Desktop is effortless but less controllable, npm is controllable but forgettable, npx suits temporary use. Automatic updates can land when you did not want them; for stability, record the version and watch release notes. Manual updates suit validation work, and skipped ones miss fixes. Pulling the newest each time means behavior can move; during troubleshooting, confirm which version you actually ran.

Offline and weak networks

All three need a model service, but weak-network behavior differs.

1. Desktop: the interface opens offline, requests fail with a message, and retries work after recovery.
2. Web: a local service still serves the interface offline, but model calls fail.
3. CLI: the local service works and scripts can retry, which suits queued work on weak links.
4. Local model: with Ollama or similar, inference runs offline and all three forms benefit.
5. Proxy and mirror: on a weak network, fix the proxy before discussing offline.

Separate interface from model, and prefer CLI on weak networks. An interface that opens is not an answer; a local model is real offline inference. CLI avoids page loading and makes retry and queueing easier to control.

Startup time

Startup depends on whether the service is already running.

1. CLI service first: start once, then requests skip the wait.
2. Web: instant when the service is up, otherwise it must be started first.
3. Desktop: a cold start includes client initialization and is usually slower than a tab.
4. npx: may resolve packages each run, slowest on first launch.
5. Plugins: startup hooks in plugins lengthen cold starts.

Compare under the same condition, and check plugins when cold starts are slow. Service running versus not running are two different scenarios; mixed numbers prove nothing. Disable non-essential plugins and measure again before switching clients.

Choosing a form

Decide by duration, environment and whether you need a GUI.

For long-running use, host the service with CLI. Desktop is for interaction, not background duty; when something must stay up, use the lighter form.

Do not run all three in parallel. Versions, data and plugins blur together; pick one primary and keep the others temporary.

Migrating between forms

Move data and version together.

1. Data directory: confirm DSH_HOME matches, or sessions appear to vanish.
2. Version: note old and new builds before crossing versions.
3. Plugins: reinstall per profile instead of assuming sync.
4. Port: the port may change with the form, so update bookmarks.
5. Stop first: copying while running can leave half-written files.

Back up before, verify after. Sessions, plugins and configuration all need confirmation before migration counts as done.

Never write the same data twice. Two forms running against one directory invite locks and version conflicts.

Next steps

Check resource and updates before features. For the capability matrix, read How dsh CLI, desktop and web divide the work. For install paths, read How to install DeepSeek Harness. For local models, read Connecting DeepSeek Harness to a local model.

Sources: DeepSeek Harness documentation, dsh CLI README, DeepSeek Harness releases