DSCode: a local-first coding agent with DeepSeek defaults

The problem DSCode solves: provider lock-in and cloud-side session state

Most coding agents bind you to one model vendor and one hosted session store. DSCode takes the opposite position. The README describes it as "a local-first, multi-provider coding agent with DeepSeek defaults", and the repository layout backs that up: sessions are written as local tree-shaped JSONL, credentials live in the operating system keyring with `~/.dscode/auth.json` as an owner-only fallback, and the global state directory is `~/.dscode`.

The target user is an engineer who wants to switch models per task without changing tools or losing session history. The README lists ten providers, including DeepSeek, OpenAI Codex, OpenAI, Anthropic, OpenRouter, Z.AI, Kimi, MiniMax, xAI and OpenCode Zen Go. DeepSeek V4 Flash is the default because it is the economical option, not because the runtime is DeepSeek-only. The project states this explicitly: it is "DeepSeek-first, not DeepSeek-only".

That framing matters for adoption. If your team already pays for a ChatGPT plan or an Anthropic account, DSCode treats those as first-class authentication paths rather than bolt-ons. The trade-off is that breadth of provider support is not the same as depth of integration with any single one.

How the runtime routes providers, patches and parallel agent roles

The mechanism visible in the README is provider-aware model routing wrapped around a local runtime. Authentication resolves to a provider ID, the provider resolves to a default model, and the runtime keeps that selection for later runs unless you override it with `--provider` and `--model`.

Three capabilities are worth separating. First, patching: DeepSeek gets a dedicated Responses adapter and native free-form `apply_patch`, and every successful patch creates what the README calls a "durable, conflict-safe checkpoint". Second, parallelism: explorer, implementer, reviewer and tester roles can run up to four tasks in parallel, with implementers working in isolated Git worktrees while the primary agent owns integration and final validation. Third, containment: commands run in an OS sandbox with network blocked by default, and API keys are removed from child-process environments.

Usage reporting is part of the same loop. The `/status` command reports context, cache hits, tokens, reasoning and estimated cost, which the README ties to DeepSeek's 1M context and disk prefix cache. Vision is conditional: paste an image in the TUI or pass one as `@file`, and models such as GPT-5.6 receive the attachment while text-only DeepSeek models fail with a clear error rather than silently dropping it.

One design choice stands out as a trade-off rather than a feature. Network access is blocked by default inside the sandbox. That is the right default for untrusted repositories, but it means any task that needs to fetch a dependency or call an external API requires you to change the sandbox policy deliberately.

Installing DSCode from npm and running a first session

The README requires Node.js 22.19 or newer and Git. DSCode also uses `rg`; the installer prepares pnpm and installs ripgrep through Homebrew when available. The npm path is the shortest:

npm install -g @thinkany/dscode

There is also a source installer that pulls the latest build from the main branch. The README notes that you should make sure `~/.local/bin` is on your `PATH` if you take this route.

curl -fsSL https://raw.githubusercontent.com/thinkany-ai/dscode/refs/heads/main/scripts/install.sh | sh

Start DSCode against a project directory with the `-C` flag:

dscode -C /path/to/project

On a fresh installation, the README says to enter `/login` in the TUI and choose a provider. DSCode then completes authentication and selects that provider's default model. You can also authenticate before opening the TUI, which is useful in scripts:

dscode login deepseek      # DeepSeek API key
dscode login openai-codex  # browser OAuth; uses ChatGPT plan limits
dscode login openai        # securely prompts for an OpenAI API key
dscode login anthropic     # Claude account or Anthropic API key
dscode login openrouter    # OpenRouter account or API key
dscode login opencode-go   # OpenCode Zen Go API key

If you would rather not store a key at all, the README gives environment variables as the alternative. Resolution order for the endpoint is `--base-url`, then `DEEPSEEK_BASE_URL`, then saved config, then the official DeepSeek URL.

export DEEPSEEK_API_KEY="sk-..."
export DEEPSEEK_BASE_URL="https://api.deepseek.com"
dscode -C /path/to/project

To override the saved provider and model for a single run, pass both flags. The README shows `gpt-5.6-sol` under `openai-codex` and `deepseek-v4-flash` under `deepseek` as the examples.

dscode --provider openai-codex --model gpt-5.6-sol -C /path/to/project

A first real session should be something small and verifiable: open a repository, ask for a change that touches one file, and then check `/status` to see the token and cost figures the runtime reports. That tells you whether the prefix cache is being hit before you point it at a large codebase.

Where DSCode is the wrong tool

The project's own comparison page concedes the main limitation: Claude Code and Codex "have broader and more mature ecosystems". If your workflow depends on a large library of third-party integrations, that gap is real and DSCode does not close it.

There are narrower failure modes too. Text-only DeepSeek models cannot accept image input, and the README says they fail clearly rather than degrading. If your work involves reading screenshots or diagrams, you need a vision-capable provider such as GPT-5.6 selected before you start.

The sandbox default is the second edge. Network access is blocked, so a task that expects to install a package mid-run will not succeed without a policy change. That is a deliberate constraint, but it is a constraint.

Platform maturity is uneven. The README states that macOS builds are signed with a Developer ID certificate, notarized by Apple, and stapled, while Windows and Linux builds are currently unsigned. If you are distributing the desktop app inside an organization with strict binary signing requirements, the Linux and Windows artifacts will not pass.

Finally, the runtime is local-first by design. If you actually want a hosted agent that keeps working when your laptop is closed, this architecture is pointed the wrong way.

How DSCode differs from Claude Code and Codex

The README points to `docs/COMPARISON.en.md` for an evidence-based comparison and summarizes the difference in one line: the alternatives have broader and more mature ecosystems, while DSCode is smaller, DeepSeek-first, locally controlled and MIT-licensed.

The concrete difference in approach is where state lives. DSCode stores sessions as local tree-shaped JSONL under `~/.dscode`, keeps credentials in the OS keyring with an owner-only fallback file, and runs commands in an OS sandbox with network blocked by default. It also removes API keys from child-process environments. A hosted agent does not make those guarantees because it does not need to; the session and the execution both live on the vendor's side.

The second difference is model economics. DSCode defaults to DeepSeek V4 Flash and surfaces cache hits, token counts and estimated cost in `/status`, tying the runtime to DeepSeek's disk prefix cache and 1M context. The project links to DeepSeek's own pricing page rather than restating it, which is the right call for a number that changes.

The third difference is licensing. DSCode is MIT-licensed, and the repository carries a LICENSE file at the top level. If you need to fork the runtime or embed it in an internal tool, that is a materially different starting position from a closed hosted product.

Maintenance status, upgrade cost and licence implications

The repository is not archived. The most recent push recorded on the default branch `dev` was on 2026-08-14, roughly a month before this writing, and the latest tagged release is v0.3.6 from 2026-08-13. A separate desktop line exists: DSCode Desktop v0.1.0 was tagged on 2026-08-13. The version numbers tell you the terminal runtime is past its first few release cycles while the desktop app is at its first.

Upgrade cost is low on the npm path. `npm install -g @thinkany/dscode` replaces the global binary, and the package declares `pnpm@10.12.2` as its package manager for source builds. Because global state lives under `~/.dscode`, upgrading the binary does not touch sessions, credentials or settings. The README does not document a downgrade or rollback procedure, so if a release breaks your workflow you should be prepared to install a specific version rather than assume one exists.

The licence is MIT, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. That is a permissive position, but it is not legal advice, and the desktop app bundles a native component built by `scripts/build-windows-sandbox.mjs`, so review what that component links against before shipping a redistributed build. The `.env.example` file also exposes `DSCODE_SANDBOX_IMAGE`, which lets you point the sandbox at an image you have reviewed yourself.

Editorial conclusion

Adopt DSCode if you want a coding agent whose sessions, credentials and sandbox policy stay on your machine and whose default model is DeepSeek V4 Flash. Skip it if you need the wider tool and integration ecosystem that the project's own comparison page attributes to Claude Code and Codex, or if you cannot run Node.js 22.19 or newer. Before committing, verify three things: that `dscode login` works against your chosen provider, that the sandbox blocks network access as expected on your OS, and that the `0600` permission on `~/.dscode/config.json` survives your credential setup.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. thinkany-ai/dscode on GitHub