DeepChat keeps agent sessions, Skills and ACP agents in one Electron window

The npm name belongs to the app, not to something you depend on

package.json declares name DeepChat at version 1.1.4-beta.8, and what it describes is an Electron shell rather than a library you add to a build. The compiled entry point is ./out/main/index.js, bundling runs through electron.vite.config.ts, and electron-builder.yml carries the packaging. Dockerfile.build.linux covers a container build of that shell, while plugins/, runtime/, resources/ and examples/user-plugins/ sit next to src/ in the tree. That shape is the real difference from calling a provider API inside your own service: there the HTTP client, the tools and the failure handling are code you own and test, here they are settings in a window. Nothing in this repository is published as a dependency for another project to require.

One selector holds DeepChat, ACP agents and remote bots

The model selector is where the design decision shows. DeepChat agents, ACP agents and remote-capable bots are chosen from one model-like entry point, so a single dropdown mixes a chat runtime, third-party coding agents and message bridges.

Session Tape records the work, Trace shows the token budget

The stated philosophy is Tape.systems, and it comes down to keeping the process so context, tool calls, requests and results stay recoverable and inspectable. Two features carry that. The README describes them as preserving recoverable session history, tracing request context, and inspecting token budgets when agent work gets complex.

A Skill you installed is not a Skill you enabled

The README describes Skills as reusable and portable: you can install, import, export, and enable them per conversation, for tasks such as code review, documents, frontend work and Office/PDF tasks. Because a Skill is enabled per conversation, installing one is a separate step from switching it on for a given chat.

ACP agents come from a registry the build downloads

ACP support is the Agent Client Protocol, and the README says ACP-compatible coding and task agents run as first-class entries in the model selector. The registry behind those entries is fetched at build time. The prebuild step chains three node scripts, and one of them is scripts/fetch-acp-registry.mjs, so the ACP agents present in your build depend on what that script returned on the day you built. Nothing in package.json pins that list.

The provider list arrives from a dev branch of another repository

Model providers arrive the same way. The prebuild step runs three scripts in sequence, and the middle one is scripts/fetch-provider-db.mjs:

node scripts/generate-icon-collections.mjs && node scripts/fetch-provider-db.mjs && node scripts/fetch-acp-registry.mjs

The address it reads sits in .env.example as VITE_PROVIDER_DB_URL, pointing at a raw file on the dev branch of the PublicProviderConf repository. A build therefore depends on that file staying where it is, and the default branch of DeepChat itself is dev, so a fresh clone already points at unreleased work. The newest tags are v1.1.4-beta.6, v1.1.4-beta.7 and v1.1.4-beta.8, published between 2026-10-23 and 2026-11-03, with the last push on 2026-11-02. At runtime the providers are yours to enter: anything in OpenAI, Gemini or Anthropic API format is accepted, and locally deployed Ollama models share the list with the hosted ones.

Copilot OAuth in .env.example points at one external host

GitHub Copilot is the one provider in the tree that comes with environment plumbing instead of a key you paste into a settings screen. The template spells it out:

VITE_GITHUB_CLIENT_ID=Iv1.b507a08c87ecfe98
VITE_GITHUB_CLIENT_SECRET=your_github_client_secret_here
VITE_GITHUB_REDIRECT_URI=https://deepchatai.cn/auth/github/callback
VITE_LOG_IPC_CALL=0
VITE_APP_LIFECYCLE_HOOK_DELAY=0
VITE_PROVIDER_DB_URL=https://raw.githubusercontent.com/ThinkInAIXYZ/PublicProviderConf/refs/heads/dev/dist/all.json

Two things to check before building a fork. The redirect URI is a fixed host that does not belong to you, so the Copilot OAuth round trip sends users to deepchatai.cn until you change the value. And the prefix is the one the Vite build inlines into the client bundle, so anything placed in VITE_GITHUB_CLIENT_SECRET is compiled into the shipped desktop app rather than kept on your machine. The file ships a filled-in client id next to a placeholder secret, which makes the shape of the requirement easy to miss.

npm is refused outright and Node 24.21 is the floor

The install step has two hard edges, both in package.json. The first is preinstall, which stops an npm or yarn install before anything is fetched:

npx only-allow pnpm

The second is the engines block:

  "engines": {
    "node": ">=24.22.1 <25",
    "pnpm": ">=10.34.5 <11"
  },

pnpm 10.34.5 is the pinned packageManager as well, a floor with an upper bound one line below the next major, and mise.toml at the top level is there to manage tool versions. The scripts that can be copied verbatim are the test and lint entries: vitest run for the whole suite, vitest run --config vitest.config.renderer.ts test/renderer for the renderer, and oxfmt --check. for formatting. Lint is a chain, project-specific cleanup and alert-dialog checks before oxlint runs, and five separate vitest configs cover the memory work, so a fork inherits more than a formatter gate.

Editorial conclusion

DeepChat fits a developer who wants one desktop window over hosted providers, local Ollama models, Skills, ACP agents and message bridges, and who can live with an Electron app plus a Node 24.22.1 floor where pnpm is the only accepted package manager. It does not fit a team that wants a library inside an existing service, because what ships is a window, and it does not fit a build that has to be reproducible offline, since prebuild downloads a provider database and an ACP registry. Before adopting, build it once on the required Node line and confirm that scripts/fetch-provider-db.mjs still resolves the address in VITE_PROVIDER_DB_URL.

Frequently asked questions

Official sources

1. Official documentation
2. Official README
3. Project repository
4. Release notes