Cindy: An Open-Source Client That Orchestrates Claude Code and Codex in One Local Agent

What it is: a local client that orchestrates several coding agents

Cindy (makecindy/cindy) is an open-source AI agent client with the tagline "Consider it done." Its pitch is simple. Instead of making you hop between Claude Code, Codex and other coding agents, it pulls several harnesses, models and tools into one agent. That agent runs on your own machine and works with your real files and your logged-in apps. The repository is Apache-2.0 licensed and is a pnpm monorepo. It holds an Electron desktop app, an Expo / React Native mobile app, and shared packages for auth, device linking, agent orchestration and model providers.

One fact comes first. This repository is the client only. The README states that the backend service lives in a separate repository and is not part of this monorepo. "Open source" here means the client source code, not the whole cloud service. Keep that in mind through the rest of this report.

Core architecture: harness, model and tools, decoupled

Going by the README, the design separates three things. The first is the harness. Claude Code and Codex are the first supported harnesses. The project says more are being added and that a native harness is in the works. The apps/*-bin directories hold tool binaries that ship with the desktop app. claude-code, codex and ripgrep are downloaded per platform by pnpm install. The Android platform-tools binaries are fetched at a pinned version, with a sha256 check, before Windows packaging. So Cindy does not reimplement a coding agent. It bundles existing agent CLIs and treats them as swappable execution engines.

The second is the model. Models and harnesses mix freely, and you can switch mid-task. The README lists four ways to bring models. You can sign in to the official Cindy service, where usage is deducted transparently. You can authorize a Claude Code or Codex Coding Plan you already pay for, and keep using it inside Cindy with no duplicate bill. You can connect your own API keys. Or you can use local models. The third is the working environment that stays continuous across engines. Workspace, memory, skills and tools persist when you change harness or model. This is the most valuable part of the design, and the hardest to get right. Different agents use different conventions for context, tool-call formats and skill descriptions. Keeping state across a change of engine needs an abstraction layer of Cindy's own.

Multi-agent work: plan, execute in parallel, review

The README says one task can be planned, executed in parallel and reviewed by agents running on different harness and model combinations. This matches a pattern now common in multi-agent engineering. One model decomposes the task. Several executors work in non-overlapping scopes at the same time. A different model then reviews the result independently, which reduces the blind spots of a model that reviews its own work. Cindy turns that workflow into a product feature, so you do not have to glue scripts together by hand.

Beyond code, Cindy can drive your browser, your computer and your phone. It can also take work from instant messaging (IM) and from schedules. That suggests the goal is a standing general-purpose work agent, not only a coding helper.

The "yours to shape" layer: memory, skills, automation, MCP, plugins

The project groups its extension points under the phrase "Yours to shape":

• Memory: correct her once and she does it right from then on, shared across harnesses.
• Skills: teach a way of working once and reuse it everywhere. Handing skills to a team is still in the making.
• Automation: recurring work schedules itself, runs itself and reports back.
• MCP: wire internal tools and business systems into her reach.
• Plugins: reshape features, UI and interactions, shared through an open marketplace. The marketplace is also in the making. For now, plugins are installed through SkillHub or manually.
• Source: audit, fork, extend and contribute back under Apache-2.0.

Deployment and usage modes

The login screen offers two modes. The hosted service uses a Cindy cloud account. "Skip Sign-In" needs no account and runs local agents. The app then shows the account state as "Not signed in", and server-backed capabilities are unavailable.

By default the client connects to Cindy's official cloud services. The endpoint manifests are config/endpoint.json and config/endpoint.global.json, and desktop auto-updates come from the official CDN. For client development, run pnpm restart:desktop:remote --region=cn or --region=global to work against your own Cindy account. The prerequisites are Node.js 22.x, pnpm 10.x (v11 is not yet supported) and Git LFS. Linux users can follow the repository's installation guide for Ubuntu, Arch Linux and Omarchy.

Performance and cost: no public benchmarks yet

This must be stated plainly. The README publishes no benchmark data. It gives no latency figures, no success rates and no cost comparison. So nobody can say, from this source, how much faster or more accurate Cindy is than Claude Code or Codex used alone. What the README does settle is the cost structure.

If you authorize an existing Coding Plan, there is no duplicate bill. If you use the official service, usage is deducted. If you bring your own keys or local models, you carry that cost yourself. Parallel multi-agent review multiplies token use. That is a trade-off shared by every design of this kind, and the real numbers need measurement in practice.

Impact, limits and outlook

For developers, the value is less context shuffling between agent tools and a review step built into the workflow. For enterprises, an Apache-2.0 client, auditable source and a local-first mode that works on real files are attractive. The data path still depends on the model source you choose and on whether you use the official cloud.

The limits are clear too. First, the backend is not open, so the hosted service cannot be audited. Second, an agent that can touch real files, logged-in apps and a phone has a very wide permission surface. Prompt injection and mistaken actions are risks that users must assess and contain. Third, Cindy depends on upstream CLIs such as Claude Code and Codex, so a change in their interfaces or license terms affects Cindy directly. Fourth, the native harness, team skill sharing and the plugin marketplace are all marked as in the making, so the roadmap is not yet delivered. Watch for the native harness release, more harness integrations, independent third-party evaluation, and a documented security model.