Cindy has published its desktop and mobile agent client under Apache-2.0, bringing Anthropic’s Claude Code and OpenAI’s Codex into a shared interface. According to the project’s GitHub README, users can switch harnesses mid-task while keeping their workspace, memory, skills and tools continuous.
The key question is what this release actually opens. The repository contains the client applications and shared client packages. Cindy’s backend service lives in a separate repository and is not included. Users can run local agents without a Cindy account, but server-backed features require signing in.
That creates a useful middle ground: an inspectable, modifiable agent client that can use existing subscriptions, API keys or local models, with a separate hosted service available. The capabilities described here come from Cindy’s documentation; their reliability and safety have not been independently tested for this article.
What Cindy Has Actually Open-Sourced
The Cindy repository is a pnpm monorepo containing three main pieces:
- Desktop: an Electron application in
apps/desktop. - Mobile: an Expo and React Native application in
apps/mobile. - Shared packages: client capabilities including authentication, device linking, agent orchestration and model-provider integrations.
Those components are the substance of the Apache-2.0 release. Developers can inspect how the client works, modify it, build their own version and contribute changes.
The README explicitly excludes the backend service. Publishing the client therefore does not provide everything needed to reproduce Cindy’s hosted offering. A custom client build can still connect to Cindy’s infrastructure: the documented development workflow uses a developer’s own Cindy cloud account and existing login state.
The default client also connects to official cloud services using endpoint manifests in the repository. Desktop updates come from Cindy’s official content delivery network. Open source here describes the client’s licensing and availability, not a guarantee that every operation avoids company infrastructure.
There is another useful packaging detail. The repository says the Claude Code, Codex and ripgrep tool binaries are downloaded for the relevant platform during pnpm install; they are not committed to the monorepo. Inspecting Cindy’s source is therefore one part of understanding the installed application, alongside the tools it fetches.
My view is that this boundary matters more than the broad “open-source agent” label. The release gives users control over the interface and client-side orchestration. It does not, by itself, offer an independently deployable replacement for the complete hosted service.
How Switching Between Claude Code and Codex Works
Cindy separates the harness from the model. A harness is the execution engine that manages an agent’s work, while the model supplies its reasoning and responses. The official site says available combinations depend on the provider, authorization and model capabilities, so this is not a promise that every model works with every harness.
The README names Claude Code and Codex as its first supported harnesses. The website also lists Pi as integrated. That difference is worth noting: the site describes a broader current lineup than the README’s introductory wording, although both support the central Claude Code and Codex proposition.
Cindy’s claimed advantage is that a task belongs to the surrounding application instead of being confined to one harness session. Its documentation says workspace, memory, skills and tools stay continuous when the harness or model changes.
Those pieces serve different purposes:
- Workspace keeps the files and working environment associated with the task.
- Memory carries preferences and useful project context across harnesses.
- Skills preserve reusable methods for completing work.
- Tools provide access to connected capabilities, including integrations through MCP.
Consider a development task that starts with planning in Claude Code. Under Cindy’s documented workflow, a user could then select Codex to continue implementation inside the same task, with shared context available. The point is to reduce the manual work of moving files, copying instructions and reconstructing project conventions.
Cindy also describes more elaborate workflows: planning first, running implementation, tests and documentation in parallel, then assigning a separate review step. Different roles can use different supported harness-and-model combinations.
The practical value is continuity at the application level. It should not be read as a documented guarantee that every harness-specific internal artifact transfers unchanged. The published material explains which context Cindy preserves, but does not detail every conversion between execution engines.
I’d judge this feature by how little repair work a handoff requires. Keeping a task visible in one interface is useful; preserving its acceptance criteria, working files and reusable instructions is what could make switching genuinely productive.
Existing Plans, API Keys and Local Models
Cindy documents four ways to obtain model access. The distinction matters because an open client does not make inference free.
| Access option | What the documentation describes | Practical condition |
|---|---|---|
| Cindy’s managed service | Sign in and consume usage through the official service | Cindy’s service pricing applies |
| An existing coding plan | Authorize a supported subscription, including Claude Code or Codex plans | The provider’s fees, limits and authorization requirements still apply |
| Your own API key | Connect a supported model provider directly | Usage remains subject to that provider’s billing and limits |
| Local models | Connect a local runtime | Listed as beta on the website; capability depends on local hardware |
Sources: Cindy README and official site.
The README promotes existing-plan access as avoiding a duplicate bill. The narrower practical reading is that users can bring an eligible subscription instead of purchasing model access again through Cindy. It is not a promise of unlimited usage, universal plan compatibility or exemption from provider rules.
Local models are a separate choice from local agents. Selecting Skip Sign-In runs local agents without a Cindy account; it does not automatically mean the model itself runs on the computer. An agent operating on local files could still send requests to an online provider through an authorized plan or API key.
That distinction is especially important for sensitive projects. “Runs locally” tells readers where part of the execution happens. Determining where task content goes also requires checking the selected model provider, connected tools and any cloud-backed features.
Cross-Device Access Still Has Conditions
Cindy’s website describes connected computers and phones sharing access to tasks, conversations, files and configured models. It also advertises remote desktop access from a phone, allowing a user to see and operate a connected computer’s actual screen.
Frequently Asked Questions
4 questions
1Is All of Cindy Open Source?
No. The Apache-2.0 repository contains the desktop and mobile clients plus shared packages. The backend service is separate and is not included.
