dreamcoder has no installer for any platform, and the README says so first

The default README is Chinese and the English one is a separate file

The repository's front page is written in Chinese, and the tree holds both language versions side by side.

`README.md` is the Chinese document. `README_en.md` is a second file at the root, reachable from a language switcher at the top of the Chinese one. The repository description is Chinese as well, describing a fully open-source desktop programming workbench for Claude Code.

The Chinese-first pattern goes deeper than the README. Inside `docs/` the contribution guide is named `CONTRIBUTING_zh.md` and the roadmap is `ROADMAP_zh.md`, so the English suffix convention is applied to the Chinese files and there is no English counterpart for either. The source-code guide lives at `docs/tutorial/README.md` and is described as a set of seven articles in Chinese, walking through one small code change and covering the execution loop, code tools, permission control, sessions and context, streaming responses with failure recovery, and desktop integration.

What is in English is the part a developer reads in an editor: `package.json`, `.env.example`, `CHANGELOG.md`, `PRIVACY.md`, `LICENSE`, and every identifier, script name, and environment variable in the tree.

So the practical split is that the prose documentation assumes a Chinese-reading maintainer while the configuration surface is international. Anyone contributing needs to know which of the two they are reading before they file an issue, and the label filters the README points at for newcomers are on the GitHub repository rather than the AtomGit mirror.

Three platforms, zero prebuilt installers

The platform table is the most useful thing in the README, and its answer to download-and-run is no.

Windows x64 is the one platform the maintainer tests long-term. macOS arm64 and Linux x64 are both marked as not yet verified in daily use, and both carry no prebuilt package with a note asking for community help to fill the gap. And the Windows row is not a download either: v0.4.5 attaches no installer, so the row tells you to check the Releases page or run from source.

The explanation under the table is more careful than the table itself. Development and verification centre on Windows x64. The code retains `#[cfg(target_os = "macos")]` and `#[cfg(target_os = "linux")]` branches, so the platform-specific work has been written, but the maintainer does not use those two systems daily, which leaves non-Windows builds in a state the documentation describes as code covered and experience awaiting more real-machine verification. That phrase is doing a lot of work: it means the code paths compile in someone's expectation, not that anyone has run the resulting application.

One concrete symptom is recorded. A memory problem on Linux is tracked as issue 25, which is the kind of detail a platform matrix should carry and usually does not.

The table also states that installer availability is whatever is actually attached to the GitHub Releases page, which is the honest way to say there is no artifact policy yet. Release automation and auto-update are still open items on the roadmap, so nothing here is going to change on its own.

Four commands, three runtimes, two dependency roots

The quick start asks for three runtimes before it shows a single command: Bun 1.0 or newer, Rust because the desktop shell is built with Tauri, and Node.js 18 or newer, which the document admits some dependencies still use. That is a lot of toolchain for what reads as a desktop app.

The install itself is four steps, and the README is unusually insistent that all four are needed.

git clone https://github.com/GoDiao/dreamcoder.git
cd dreamcoder
bun install
cd desktop && bun install
bun run build:sidecars
bun run tauri dev

Step one installs the root workspace, which is where the sidecar runtime lives, with the Anthropic SDK, the AWS SDK, and ink named as examples of what you are pulling in. Step two installs the desktop dependencies, which is the Tauri CLI and the React frontend. Step three compiles the sidecar binary, and step four starts the desktop in development mode.

The warning attached to it names the failure mode: skip any step and `tauri dev` often will not start because the sidecar binary or the Tauri CLI is missing. That is a real ordering constraint, since the sidecar is a separately compiled program the desktop shell launches, not a library import.

The two install steps exist because this is a Bun monorepo with independent dependency roots. The root and the `desktop/` directory each maintain their own, and `cd desktop && bun install` is not redundant with the first one.

Linux users are then told they also need WebKitGTK, libappindicator, and librsvg as system packages, with the Tauri prerequisites page as the reference and an invitation to submit distribution-specific commands. That invitation is a fair summary of the state of Linux support here.

The sidecar build step writes a .exe filename on every target

The build script for the sidecar hardcodes a Windows executable extension.

"build:sidecar": "bun build --compile ./desktop/sidecars/dreamcoder-sidecar.ts --outfile desktop/src-tauri/binaries/dreamcoder-sidecar.exe"

Bun compiles the TypeScript entry point into a standalone binary and drops it into the Tauri `binaries/` directory under a name ending in `.exe`, regardless of the platform doing the compiling. On macOS and Linux the file that appears is named as though it were a Windows executable.

That matters more here than it would in most projects, because this is the step the README tells you not to skip. A missing sidecar binary is named as one of the two reasons `tauri dev` fails to launch, and the compile step is what produces it. So on a non-Windows machine the documented flow can produce a file the shell will not execute without an extra step, and the documentation does not mention that.

The rest of package.json is worth a look for a different reason. The package is marked `private`, so despite carrying a version and a `bin` entry pointing at `./bin/dreamcoder` it cannot be installed from a registry. There are two scripts that both run that file, `dreamcoder` and `start`, plus a `dev:server` script that pins the port with an inline variable assignment to 3456 before running the server entry point. Tests are `bun test`, with separate desktop test and lint scripts that change directory again.

So the CLI exists, works, and is deliberately not a published package. Anyone planning to script it needs the repository checked out.

Every provider is reached through the Anthropic variable names

The multi-model claim is implemented by remapping Anthropic's own environment variables.

The example environment file shows three working configurations and they all look the same underneath. Each sets `ANTHROPIC_AUTH_TOKEN`, `ANTHROPIC_BASE_URL`, `ANTHROPIC_MODEL`, and then the three alias slots `ANTHROPIC_DEFAULT_SONNET_MODEL`, `ANTHROPIC_DEFAULT_HAIKU_MODEL`, and `ANTHROPIC_DEFAULT_OPUS_MODEL`. What changes between them is only what fills those slots.

For MiniMax, the Anthropic-compatible endpoint is used, with two domains offered, one international and one for China, and the model slots point at MiniMax-M2.7 with the highspeed variant assigned to the Haiku slot. For OpenAI and for DeepSeek, both go through a LiteLLM proxy started with `litellm --config litellm_config.yaml --port 4000`, and the slots are filled with `gpt-4o` and `deepseek-chat` respectively. So the model the application thinks is Opus is whichever model you put in the Opus slot, and a provider that does not speak the Anthropic protocol shape needs a translation layer in front of it.

Two details in that file are easy to copy by accident. The LiteLLM examples set the auth token to the literal placeholder `sk-anything`, which is correct for a local proxy and wrong for any hosted endpoint. And the timeout line reads `API_TIMEOUT_MS=3000000`, which is fifty minutes, so a stalled request can occupy a connection far longer than most agents expect.

The README's own preset list goes wider than these three examples, naming DeepSeek, Qwen, Kimi, Zhipu GLM, LM Studio, and Ollama, and it is careful to say whether a given model works depends on the provider and the configuration.

Five Anthropic SDKs, three Bedrock clients, and a telemetry stack

The dependency list is where the project's real ambition shows.

There are five separate Anthropic packages: the base SDK, plus Bedrock, Foundry, and Vertex variants, plus MCPB and a sandbox runtime. Alongside them sit three AWS Bedrock clients, the Bedrock service client, the Bedrock runtime client, and STS, plus Azure Identity. That is a set of dependencies for reaching the same model through several hosted platforms, which the README's provider list does not mention at all.

Then there is the operational layer. The Model Context Protocol SDK is there for the MCP support the features section promises. GrowthBook is a feature-flagging service, which is an unusual dependency for a desktop application but a normal one for something built to be rolled out gradually. And OpenTelemetry is not a single package but a spread: the API, the logs API, the core, and separate OTLP exporters for both logs and metrics over gRPC, over HTTP, and over protobuf.

Two smaller entries explain the terminal. `@alcalzone/ansi-tokenize` parses ANSI escape sequences, which is what a terminal emulator needs to render command output, and Commander with extra typings is the CLI argument parser behind the `bin/dreamcoder` entry.

The stack table in the README describes the same project in one line each: Tauri 2 in Rust for the shell, React 18 with Vite and TailwindCSS 4 for the interface, Bun as the runtime, portable-pty in Rust with xterm.js for the terminal, Zustand for state, and WebSocket, MCP, and LSP as the protocols. The dependency list is the longer version of that table, and it is the one to read before judging the install size.

Phase 4 and Phase 5 are open, and Phase 5 explains the release titles

The roadmap is a checkbox list and it is honest about where it stops.

Four phases are ticked. Phase 1 delivered the desktop interface, multi-model support, and the project workbench. Phase 2 delivered the command-line backend integration, Computer Use, MCP, Skills, and Agent Teams. Phase 2.5 was a performance pass covering bundle splitting, polling throttling, terminal LRU eviction, and a sessionStore refactor. Phase 3 delivered H5 access so a phone or browser on the same local network can pick up a desktop session.

Two are not. Phase 4 is IM adapter integration for Feishu, DingTalk, Telegram, and WeChat. Phase 5 is release automation plus automatic updates.

Phase 5 is the one with consequences you can measure. Without release automation the three published tags are v0.3.0, v0.4.0, and v0.4.5, and each carries a hand-written title in the release notes. The v0.3.0 release is titled for Phase 2 and shipped on 2026-05-31, before Phase 2.5 and Phase 3 were checked off, so the release names trail the roadmap rather than tracking it. The newest release, v0.4.5, was published on 2026-06-25, and the branch was last pushed on 2026-09-29, which leaves roughly three months of commits past the newest tag.

One other unfinished thing sits in the features section rather than the roadmap. Cross-network access to a phone session needs a reverse proxy you configure yourself, and the deployment guide for it is still being written. What works out of the box is the local network case, with a QR code and a managed access token, and the desktop has to stay running.

Editorial conclusion

dreamcoder is a sensible pick if you work on Windows x64, use Claude Code, and want one desktop surface for sessions, terminal output, file changes, and tool calls, with LAN access from your phone. It is not a download-and-run project: no platform has a prebuilt installer, macOS arm64 and Linux x64 are both marked as not routinely verified, and the documented path needs Bun, Rust, and Node.js 18 present at the same time. Two things to check before committing. The default README is Chinese with the English version as a separate file at the root, and every provider is reached through the Anthropic variable names with the Sonnet, Haiku, and Opus slots remapped, so a provider that does not honour that shape needs a local proxy in front of it. Also expect to compile: the sidecar build step writes a .exe filename whatever the target is, and that is the same step the documentation warns is easiest to leave out.

Frequently asked questions

Official sources

1. GoDiao/dreamcoder on GitHub
2. License: MIT
3. Project website
4. README
5. Releases