Build with multiple agents, then ship through a real workflow.

ACE is for builders who want AI to do real project work but do not want to manually coordinate every model, branch, tool, review, preview, and release step. It works for founders building prototypes, operators creating internal tools, designers turning ideas into runnable projects, and developers who want stronger review before accepting AI-generated work.

The reason to use ACE is not only speed. The stronger reason is control. ACE keeps the work in normal local repositories, separates tasks into isolated workspaces, and gives the user a visible path from idea to artifact.

ACE installs as a desktop app for macOS and Windows. On macOS the production app lives at /Applications/ACE.app and the developer channel app lives at /Applications/ACE Dev.app; on Windows ACE installs from the Windows build on the download page. On first launch, ACE checks whether the required local tools are installed and authenticated.

• Claude CLI powers Claude Code execution.
• Codex CLI powers OpenAI Codex execution.
• Gemini uses Gemini CLI for paid API, Standard, Enterprise, and supported Google Cloud access, or OpenRouter as a fallback. Antigravity task execution remains unavailable until its CLI supports safe per-run discovery isolation; authorization alone does not enable it.
• A GitHub account, connected in the browser, powers repository cloning, PR creation, and GitHub account flows.

Provider accounts remain provider accounts. ACE coordinates the workflows, but model authentication still runs through the connected provider tools or supported saved-key paths.

ACE starts from a project. A project can be a new local git repository, an existing local repository, or a repository picked from your connected GitHub account.

For existing repositories, ACE creates a git worktree. Each task gets its own folder and branch while sharing the repository history. That keeps parallel AI work isolated without hiding anything from git.

• New projects are initialized as normal git repositories.
• Existing projects run in task-specific worktrees.
• GitHub repositories are cloned or refreshed with your connected GitHub account.
• Users can inspect diffs, commit, push, and open PRs from the app.

That workspace model is why ACE can run multiple agents without turning the main checkout into a shared scratchpad. Parallel work is useful only when each attempt has room to succeed or fail independently.

Chat mode is the fastest path through ACE. The user selects a workspace, types a prompt, chooses the models or mode, and watches model output stream back through the app.

Board mode turns collaboration into a visible process. Instead of sending one prompt to one model, the user can build a workflow of specialist agents, documents, edges, loops, synthesis nodes, and actions.

• Agent nodes can use ready-made prompts for planning, research, building, review and QA, release management, scheduling, tool execution, or human decisions. Custom roles can generate their own editable prompt.
• Document nodes carry web content, repository notes, docs, images, audio, data, or plain notes into the workflow.
• Edges define collaboration, review, debate, delegation, or advanced custom interaction between stages.
• Loops can run exact rounds, continue until approved, or stop when a quality score target is reached.
• Action nodes can save markdown or prepare workflow output for handoff.

For complex requests, ACE can carry a mission contract through the workflow. That contract records deliverables, acceptance criteria, constraints, required artifacts, verification gates, side effects, and failure conditions, so downstream agents stay anchored to the requested outcome.

ACE can use Claude, Codex, and Gemini model families. Users can turn models on or off per workspace. If a selected workflow requires a provider that is missing or not authenticated, ACE blocks the run with a model auth preflight instead of failing later.

This is a practical trust feature. The user sees what needs to be connected before the agents start work, and ACE can normalize writer or reviewer roles when the originally selected model is unavailable.

ACE is a desktop app with a bundled local runtime. The runtime contains a Next.js UI, a local server, WebSocket orchestration, git workspace management, model CLI runners, billing access checks, preview launch, and verification gates.

User prompt
  -> workspace job
  -> model auth preflight
  -> Claude, Codex, Gemini, or board agents
  -> live WebSocket events
  -> synthesis, verification, preview, or PR workflow

ACE separates the desktop shell from the runtime. The shell is the installed desktop app on macOS and Windows. The runtime contains the UI and local server bundle that ACE can update from GitHub releases.

• Developer-channel runtime changes flow through GitHub dev, publish to duocode-runtime-dev, and are pulled by ACE Dev.app.
• Production runtime changes flow from dev to main, publish to duocode-runtime-latest, and are pulled by ACE.app.
• Normal UI and server changes ship as runtime updates.
• Desktop releases are reserved for Electron shell, updater, signing, packaging, protocol, native helper, or app version changes.
• Hosted landing, billing, and auth callback changes require the Cloudflare deployment flow.

ACE is local-first for project work and explicit about external provider use. Generated files, branches, and workspaces live on the user machine unless the user pushes them or connects a service that moves the data elsewhere.

• Generated files and branches stay on the local machine unless the user pushes them or uses a connected service.
• Model execution goes through provider CLIs, so prompts and selected context can be sent to the connected provider accounts.
• Workspaces are normal git folders, not a proprietary project format.
• Verification gates make output easier to inspect, but generated code still needs review.

Users should keep secrets out of prompts and agent-readable files, confirm model provider policy before using sensitive code, review generated diffs before pushing, and use stricter workflows for release-bound work.

Most ACE issues are easier to understand once the runtime boundary is clear. The installed app updates from GitHub runtime releases, not from a local Conductor workspace or a developer server.