> Source: makecindy/cindy — https://github.com/makecindy/cindy > Language: TypeScript | Stars today: 471 | License: Apache 2.0 > In one line: An AI agent not bound to a single model or framework — one task can span Claude Code × GPT-4 planning, Codex × Sonnet execution, and Gemini × Pro review.
A Counter-Intuitive Design
Most AI agents have a single "body" — one model, one harness (framework), one toolset. Claude Code runs Claude models, Codex CLI runs the GPT family, Gemini CLI runs Gemini. Pick an agent and you've picked the model; pick the model and you've picked the ecosystem.
Cindy's first counter-intuitive design decision: these dimensions are orthogonal.
A task in Cindy can work like this: the Claude Code harness with a Sonnet model does planning, the Codex harness with GPT-4o does execution, and the Gemini harness with Pro does review. Workspace, memory, skills, and tools stay continuous across switches. You're not using three agents — you're using one agent that transforms three times.
This sounds like "multi-agent collaboration," but there's a key difference: multi-agent collaboration means N independent instances talking to each other, while Cindy is 1 continuous identity migrating between bodies. The former is a "meeting"; the latter is a "shift change."
Why This Matters
A hidden bottleneck in current agent engineering is "model lock-in." You use Claude Code because Claude models are strong at one task, but they may underperform GPT-4o on another. You're forced to trade off between overall capability and per-task capability.
Cindy turns that trade-off into a switch over time:
- Planning phase uses a model strong at structured reasoning (Claude Sonnet)
- Execution phase uses a model strong at code generation (GPT-4o or Codex)
- Review phase uses a model good at spotting blind spots (Gemini Pro)
Memory Persists Across Harnesses
Cindy's second design: "correct once, every harness remembers."
A traditional agent's memory is harness-bound — a preference you corrected in Claude Code has to be restated in Codex, because memory lives in the harness's context, not the agent's.
Cindy lifts memory to a layer above the harness. Tell Cindy "I prefer pnpm over npm," and that preference applies across all harnesses. Next time, no matter which body Cindy is in, she knows to use pnpm.
It looks like a small feature, but it changes something fundamental: the agent's identity no longer depends on a specific model. Previously, "my agent" was really "my Claude Code configuration" or "my Codex configuration." Cindy makes "my agent" a continuous entity that spans models.
Skills: Define Once, Reuse Everywhere
The third design is cross-harness portability of skills.
Teach Cindy a workflow — say, "run lint + type check + tests before every commit" — and that skill works in all harnesses. No need to configure hooks once in Claude Code and again in Codex.
This continues the previously discussed skills CLI idea: skills are assets; the agent is the consumer. Cindy pushes the concept further — not just skills are portable, but memory, workspace context, and even task state.
The Cost of Out-of-the-Box
Cindy's selling point is "works out of the box" — download the client, log in, go. No API keys to configure, no model to choose, no plugins to install.
But out-of-the-box convenience has a price. Cindy's client connects to its official cloud service (cindy.app), and your task data passes through their backend. The code is open source (Apache 2.0), but the backend service is not.
This differs from Open WebUI's philosophy — Open WebUI is fully self-hosted and your data never leaves your machine. Cindy takes a middle path: open-source client, hosted backend.
A "Skip Sign-In" mode lets you use local agents without logging in, but server-backed capabilities are unavailable. It's an explicit trade-off: ease of use vs. autonomy.
Desktop + Mobile + IM
Cindy has multi-platform ambitions: not just a desktop client, but mobile (Expo/React Native), plus task triggering from IM and calendars.
"Driving from IM" means you can send Cindy a task in Slack (or similar), she executes it on the desktop, and sends results back to IM. This turns the agent from "something you open" into "something always online."
But this is also where vigilance is most needed. An agent that can operate your computer, access your IM, and read your calendar has a much larger blast radius when it errs than a pure coding agent. Cindy's security model currently appears to be "user authorization + local execution," with no additional sandbox layer observed. By contrast, NVIDIA OpenShell confines the agent to a sandbox; Cindy lets the agent use your logged-in session directly.
The Real Competitive Dimension
Cindy isn't competing with other agents — Claude Code, Codex CLI, and Gemini CLI each have their own model advantages. Cindy is competing for something higher up: the agent operating-system layer.
An OS abstracts hardware differences — you don't need to know which GPU you have; the OS gives you a unified interface. Cindy abstracts harness and model differences — you don't need to know which harness is active; Cindy gives you a continuous agent identity.
This positioning overlaps with Open WebUI's "AI OS" concept, but the paths differ: Open WebUI grows upward from a chat interface, Cindy grows downward from the harness. Who reaches "agent OS" first depends on whether the market prefers "one interface for all models" or "one identity across all models."
A Detail Worth Noting
Cindy's repo is a pnpm monorepo containing apps/desktop (Electron), apps/mobile (Expo), and packages/* (shared capabilities). Notably, the apps/*-bin directories — binaries for claude-code, codex, and ripgrep — are not committed to the repo; they're downloaded per-platform during pnpm install.
This means Cindy treats Claude Code and Codex as "dependencies," not "integrations." They are optional bodies of the Cindy agent, downloaded on demand. This is the opposite of "the agent is a plugin for Claude Code" — here, Claude Code is a component of Cindy.
Closing
Cindy's core bet: agent identity lives not in the model but above the models. If that bet pays off, the future agent market won't be won by whoever has the strongest model, but by whoever has the best abstraction layer. Models become replaceable components, and the agent's continuity is what drives user stickiness.
The bet carries risk. Model vendors could block cross-harness usage through API restrictions (Can a Claude Code subscription be used inside Cindy? Yes — Cindy supports "Claude Code / Codex Coding Plan" authorization without double billing). If vendors tighten restrictions, Cindy's core selling point disappears.
But for now, Cindy offers something no other agent does: a continuous "you," flowing between different bodies.