Cindy: An Open-Source AI Agent Client That Mixes Harnesses, Models, and Local Tools

What Cindy Actually Solves

Cindy targets a specific pain: you have multiple AI coding tools, each with its own harness, model, and workspace. Claude Code, Codex and Pi are the supported harnesses. Normally you would switch between them and lose context. Your session stays in Cindy while you change harness or model as the work evolves; switching harnesses hands off or rebuilds the engine context rather than making their internal states identical. The README describes one task being planned, executed in parallel, and reviewed by agents on different harness and model combos. That is the core value proposition. It is for developers or teams who already pay for Claude Code or Codex plans and want a single client that can use those existing subscriptions without a duplicate bill. It also appeals to people who want local execution: Cindy runs on your own machine, using your real files and logged-in apps. The target user is someone who wants a configurable agent client, not a hosted black box.

The Architecture: A Monorepo Client, Not a Server

This repository is the client only. It is a pnpm monorepo with an Electron desktop app, an Expo and React Native mobile app, and shared packages for auth, device-link, agent orchestration, and model providers. The backend service lives elsewhere and is not part of this repo. That is a deliberate split. The client connects to Cindy's official cloud services by default, with endpoint manifests in config/endpoint.json and config/endpoint.global.json. Desktop auto-updates also come from the official CDN. The README says this is intentional so external developers do not need to self-host a server. You can sign in with your own Cindy account in a dev build and develop against the official servers. The architecture also includes tool binaries: claude-code, codex, and ripgrep are downloaded per platform by pnpm install, and Android platform-tools binaries are fetched with a pinned version and sha256 verification before Windows packaging. None of these binaries are committed to the repo.

Getting It Running: Commands and Prerequisites

The minimal entry point is straightforward. You need Node.js 22.x, pnpm 10.x (the README explicitly says pnpm 11 is not yet supported), and Git LFS. The commands are: git clone https://github.com/makecindy/cindy.git, then cd cindy, then git lfs pull, then pnpm install. For remote development, there are two entry points. Use pnpm restart:desktop:remote --region=cn for Mainland China accounts and pnpm restart:desktop:remote --region=global for everyone else. The README warns not to rely on the internal default region. There is also a "Skip Sign-In" option on the login screen that runs local agents without a Cindy account. The app shows the account state as "Not signed in". This is not a connection to a local server; it is simply a mode where server-backed capabilities are unavailable. That distinction matters if you expect full functionality without an account.

The Harness and Model Mixing Mechanism

The key mechanism is that harnesses and models mix freely and can switch mid-task. The README says your session stays in Cindy, and that switching harnesses hands off or rebuilds the engine context rather than making their internal states identical. This implies there is an orchestration layer, likely in the packages directory, that coordinates between the Claude Code, Codex and Pi harnesses. There is a doc mentioned, docs/dev-rules/, which includes deep-dive architecture docs on "Orca multi-agent orchestration". That suggests the orchestration is a named subsystem. The practical effect is that you can start a task with Claude Code, then switch to Codex for a subtask, and the session stays in Cindy. The README also mentions parallel execution: one task can be planned, executed in parallel, and reviewed by agents on different combos. That is a strong claim. The documentation does not give a detailed data flow, so the exact mechanism is not fully visible from the README. But the existence of an orchestration package and the Orca doc indicates a real design behind it.

Extensibility: Memory, Skills, MCP, and Plugins

Cindy is positioned as "yours to shape". The README lists companions, memory, skills, automations, MCP, plugins and the source as ways to shape it. Memory keeps useful preferences and knowledge. Skills let you teach a way of working once and reuse it everywhere. Automation schedules recurring work that runs itself and reports back. MCP wires internal tools and business systems into the agent's reach. Skills and plugins can be discovered in SkillHub, and there are official plugins to build on. The source is Apache-2.0, so you can audit, fork, and extend it. This is a real differentiator: many AI agent tools are closed or have limited extension points.

Genuine Limitations and Failure Modes

The most obvious limitation is that the backend is not in this repository. If you want to self-host the server, this repo is not enough. The README says the backend service is in a separate repository. That means server-backed capabilities are only available through Cindy's official cloud service. If the service goes down or changes pricing, you are dependent on it. Another limitation is the "Skip Sign-In" mode. It runs local agents, but the README explicitly says server-backed capabilities are unavailable in that state. So you cannot get the full experience without a Cindy account. Also, the client connects to official servers by default, which may be a privacy concern for some users. The README mentions TapDB analytics in official distribution builds, which aggregates device, OS, and app-version metadata, associated with your account ID after sign-in. That is a real trade-off for a local-first tool.

A Real Alternative: Running Claude Code and Codex Separately

The most direct alternative is to use Claude Code and Codex as standalone tools, without a client like Cindy. That means you run each harness in its own terminal or IDE, with separate workspaces and no shared memory. The difference is that you lose the continuity and the ability to mix models mid-task. You also lose the unified client for desktop and mobile. If you only use one harness and do not need parallel orchestration, the standalone tools are simpler and have no dependency on a third-party client. Another alternative is to use a different open-source agent framework that is fully self-hosted, such as an agent orchestration library that runs entirely on your own infrastructure. The difference is that those frameworks often require you to build the client UI and the harness integrations yourself. Cindy gives you a ready client but with a backend that is not in this repository. So the trade-off is between a ready client with a hosted dependency versus a DIY approach with full control.

Maintenance, Upgrades, and License Implications

The project is under active development. The recent releases show a beta version v0.1.122-beta from 2026-11-02, and stable releases v0.1.121 and v0.1.120 from the days before. That indicates a fast release cadence, which means you should expect frequent updates and potential breaking changes. The README says contributions go through pull requests into main, and every commit needs a Developer Certificate of Origin sign-off (git commit -s). There is no CLA required. The license is Apache-2.0, which is permissive for use and modification, but you should note that the backend is not covered by this repo's license. The client is free to use, but the hosted service has its own pricing. For maintenance, you need to keep up with pnpm and Node versions. The README explicitly says pnpm 11 is not yet supported, so upgrading pnpm could break your build. Also, tool binaries are downloaded during install, so you need a reliable network connection. The use of TapDB analytics in official builds means you should check the privacy implications if you distribute modified builds.

Editorial conclusion

Adopt Cindy if you want a local-first AI agent client that lets you mix Claude Code and Codex harnesses with your own API keys or local models, and if you are comfortable with the hosted backend for server-backed features. Do not adopt it if you require a fully self-hosted server, since the backend is not in this repository. Before using it, verify the current state of the "Skip Sign-In" mode: it runs local agents but disables server-backed capabilities, so check whether your workflows depend on those. Also confirm your Node.js version is 22.x and pnpm is 10.x, because pnpm 11 is not yet supported. The project is under active development with frequent beta releases, so pin a specific version if you need stability.

Frequently asked questions

Official sources

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