# Show HN: Cc-fleet – run other LLMs as Claude Code workers, your sub drives

> Source: <https://github.com/ethanhq/cc-fleet>
> Published: 2026-06-21 01:40:27+00:00

**🤖 Plug any third-party model into Claude Code's ⚙️ Dynamic Workflows, 👥 Agent Teams, and ⚡ Subagents — from DeepSeek · GLM · Kimi · Qwen … to your Codex subscription, with your main session's auth untouched; no Claude subscription needed to run a full Claude Code on any provider 🚀**

**English** · [简体中文](/ethanhq/cc-fleet/blob/main/docs/README_zh.md)

Claude Code's multi-agent orchestration — Dynamic Workflows, Agent Teams, Subagents — only runs Anthropic's own models. cc-fleet lets any model with an Anthropic- or OpenAI-compatible API, even your Codex subscription, join as a workflow leaf, a long-lived teammate, or a one-shot subagent — scheduled by your main session, **with the same identity and capabilities as a native Claude agent**.

Every third-party worker is a real `claude`

process with its LLM backend swapped to the provider, so Claude Code drives it exactly like a native agent. Your main session's own auth (OAuth subscription or API key) is untouched, and provider keys never enter env, argv, or shell history — **zero leak risk**.

**Two steps to get going**: one-line install, register a provider. Then state your intent in Claude Code with `/workflow`

, `/team`

, or `/subagent`

— or just describe the task in plain language, and Claude figures out the rest.

No Claude subscription? `ccf run <provider>`

starts an interactive session driven by that provider — **the same claude you know**, just running on the provider's model.

**0. Install Claude Code first** — cc-fleet drives the official `claude`

CLI, so install it if you don't have it yet (skip if `claude`

is already on your PATH):

**macOS / Linux:**

```
curl -fsSL https://claude.ai/install.sh | bash
```

**Windows (PowerShell):**

```
irm https://claude.ai/install.ps1 | iex
```

**1. Install cc-fleet with the one-line script (recommended)** — one command does it all: downloads and verifies the CLI, puts it on your PATH (with a `ccf`

alias, so `ccf`

launches it from then on), and installs the Claude Code plugin (skill + session hook) via the marketplace. Ready to use right after:

**macOS / Linux:**

```
curl -fsSL https://raw.githubusercontent.com/ethanhq/cc-fleet/main/install.sh | sh
```

**Windows (PowerShell):**

```
irm https://raw.githubusercontent.com/ethanhq/cc-fleet/main/install.ps1 | iex
```

Other channels (npm / go install / Releases / source) and adding the Claude Code plugin, installer overrides, and requirements & maintenance live in

.[Install & maintenance]

**Common commands:**

```
ccf                      # open the interactive TUI
ccf doctor               # health check: dependencies, providers, plugin status
ccf update               # self-update by install channel + refresh the plugin
ccf uninstall --all      # remove the binary and plugin too
```

Once installed, run `ccf`

to register a provider and start delegating.

|
|
|
|
|
|

cc-fleet's capabilities fall into two groups:

**Three delegation lanes**(Workflow / Agent Team / Subagent) — scheduled automatically by Claude: say what you want and the skills pick the lane and the model for you, no manual choice.**Provider and**— tools you configure and use directly.`ccf run`

Agents Board: the phase → leaf tree |
drill into one leaf: full prompt and synthesized output |

**Orchestration API**: multi-phase orchestration lives in a JavaScript file, with an API identical to Claude Code's native Workflow tool — `agent()`

starts a node, `parallel()`

fans out, `pipeline()`

chains a flow. The one difference is that `agent()`

takes a `provider`

option to assign each node's model, so different vendors mix and run in parallel within a single run:

``` js
const meta = {
  name: "api audit",
  description: "map endpoints, then draft audit checklists",
  phases: [{ title: "map" }, { title: "build" }, { title: "judge" }],
};

phase("map");
const maps = (await parallel(
  ["auth", "billing", "users"].map((m) =>
    () => agent("List the exported endpoints in module " + m, { provider: "deepseek" }))
)).filter(Boolean);

phase("build");
const checklists = await pipeline(maps,
  (endpoints, _, i) => agent("Draft an audit checklist:\n" + endpoints,
                             { provider: "glm", label: "build:" + i }));

phase("judge");
const verdict = await agent("Pick the strongest one and say why:\n" + checklists.join("\n---\n"),
                            { provider: "claude", model: "opus", label: "judge" });
return { checklists, verdict };
```

**Running and managing**: once kicked off, the whole run executes in a background engine, managed by a small command set. Runs are journaled by content hash, and budgets cap spend in USD or tokens:

```
RUN=$(ccf workflow run audit.js)            # starts in the background, prints the run id
ccf workflow wait "$RUN" --timeout 10m      # blocks until done, event-driven
ccf workflow stop "$RUN" --leaf build:1     # hold a single leaf (run keeps going)
ccf workflow restart "$RUN" --leaf build:1  # resume it
ccf workflow run audit.js --resume "$RUN"   # replay the journal, finished leaves hit cache
```

**Holding and restarting**: `ccf workflow stop --leaf`

/ `--phase`

doesn't fail the run — it just pauses the named node: the run keeps going and other nodes carry on, until you `restart`

it to run again. If every node currently running gets paused, the whole run settles into a *parked* state that needs you to step in before it continues.

**Wait without polling**: `ccf workflow wait`

blocks until the run ends, then exits — drop it in the background and come back when it exits, no repeated checking. The exit code states the outcome: `0`

succeeded, `1`

failed, `3`

parked and waiting, `124`

wait timed out (run still going), `130`

interrupted.

**Budget-adaptive**: `budget.spent()`

/ `budget.remaining()`

are readable live inside the script (USD or tokens), so a workflow can decide for itself whether to dispatch another batch.

**Mixing in your own subscription**: a node assigned `provider: "claude"`

runs on your **own** Claude login — the `judge`

above uses your subscription, not a provider key, which suits a synthesis-and-finish node.

four teammates working side by side in tmux panes |
a teammate's overview / messages / output on the board |

**Prerequisites**: Agent Team is the only lane that needs setup up front, and because it relies on tmux it **doesn't support Windows yet**. Two conditions before you use it:

**Be inside a tmux session**(`tmux new-session -s work`

) so teammate panes can show up alongside you;**Enable Claude Code's agent-teams**: the first time you run`ccf`

it detects this isn't on and offers to write it in for you — or add it once yourself to`~/.claude/settings.json`

:

```
{ "env": { "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1" } }
```

**How they collaborate**: each teammate is a real `claude`

process; Claude builds the team with native `TeamCreate`

and assigns work with native `SendMessage`

, and teammates stay alive across turns so you can keep adding tasks. One team can use several providers at once, then have one teammate gather and compare the results.

**Permission inheritance**: each teammate inherits your main session's permission posture (plan / acceptEdits / default). If that can't be detected, it falls back to the safest default and won't open up risky permissions on its own.

**Park and restore**: `ccf hide`

tucks a teammate's pane out of the way while the process keeps running — messages and context are never lost — and `ccf show`

brings it back. At cleanup, `ccf teardown`

thoroughly clears every related process, including ones still running in the background and consuming the key after their pane was closed, so no ghost quietly bills you.

**Outside tmux**: the teammate runs in a background `cc-fleet-swarm-<team>`

session, exactly the same flow with the pane just not on screen. To look in, attach with `tmux -L cc-fleet-swarm-<team> attach`

.

fan out three subagents in parallel from one ask |
the job list and one job's detail |

**Three run modes**: the default **slim** sends the model a trimmed system prompt with a narrowed tool set, so the first request is much smaller than a full session — cheaper and faster on metered providers. `--profile slim-ro`

is read-only, with tools cut to inspection only (Bash / Glob / Grep / Read / Skill) and no creating, editing, or deleting files, so a provider can read code and check logs without touching your workspace. Use `--profile full`

when you need full-session capability.

**Tool trimming and parallelism**: `--tools`

takes a comma-separated list to set exactly which tools are open (a replacement, not an addition to the defaults), `--skills=false`

turns off the Skill tool, and `--mcp`

controls whether the host MCP config carries over. A subagent builds no team, takes no pane, and holds no locks, so running many against one provider doesn't interfere — ideal for large batches in parallel.

**Background and wake-up**: add `--background`

to send a long job to the background, then `ccf subagent-status <job> --wait`

blocks until it's done and wakes the session that launched it — no repeated checking. Each job is capped by spend (USD), turns, and timeout, and a failure returns a fixed `error_code`

your program can branch on.

**Structured result**: with `--json`

you get a result object with fixed fields, easy for scripts to parse — besides the answer text it includes the model id that actually responded, the call's spend, token usage, turns, and session_id.

**Run key nodes on your own subscription**: as with Workflow, setting the provider to the reserved name `claude`

(`ccf subagent claude --model opus …`

) uses your own Claude login and bills your subscription — good for a synthesis-and-finish node, not large parallel batches.

presets for many vendors |
set each tier's model, effort, and permission |

**Broad compatibility**: works with any Anthropic- or OpenAI-compatible API endpoint — the former includes DeepSeek, Kimi, GLM, Qwen, and more; the latter Groq, Together, Fireworks, a local vLLM, and OpenAI itself. Common vendors ship as presets — select one and the endpoint and protocol are filled in, no manual entry; for anything not listed, pick *Custom* and enter the address.

**Model tiers**: each provider can carry **default / strong / fast** model slots, each separately taggable with 1M context and a reasoning effort. So Claude just asks for "the strong model" — no hardcoded model IDs. `ccf default <provider>`

sets the fleet-wide default provider, and any call that doesn't name one goes to it.

**Multi-key rotation**: one provider can hold several API keys, rotated by `off`

/ `round_robin`

/ `random`

to spread quota and avoid rate limits.

**API key protection**: a key is fetched only at request time, emitted once, and never written into environment variables, command-line arguments, or shell history; a worker process starts with the main session's credentials cleared, so the two never leak into each other. On disk it's saved `0600`

, readable only by you, or handed to `pass`

, 1Password, Vault, or your OS keyring; every UI and log shows the key masked (`sk-…238`

).

**Codex (ChatGPT subscription)**: one device-code login and your ChatGPT subscription becomes a regular provider — usable across Workflow / Team / Subagent / run.

Warning

**Codex is unofficial.** Reusing a ChatGPT subscription outside the codex CLI may violate OpenAI's terms, and `ccf codex login`

asks you to confirm first. The OAuth token lives only inside the local conversion daemon; cc-fleet keeps its own login chain and never touches the codex CLI's auth.

one-line launch: ccf run / ccf run codex |
inside, it's a full claude — here on gpt-5.5 |

**Launch**: `ccf run <provider>`

opens an interactive `claude`

on the named provider; with no provider (`ccf run`

) it resolves to the fleet-wide default.

```
ccf run deepseek        # an interactive claude, on DeepSeek, billing the provider key
```

**It's just native claude**: `ccf run`

adds no extra process layer — it replaces itself with `claude`

, cc-fleet steps out entirely, and from then on it's a plain `claude`

process whose feel and exit behavior match typing `claude`

yourself.

**Credentials isolated automatically**: even if you run it from inside a logged-in Claude Code session, it first clears any leftover Anthropic auth from the environment and uses the chosen provider's auth instead — so billing lands on the provider's key, never your own subscription.

**Flags**:

`--model strong / fast`

— override the default with the provider's strong or fast model`--permission-mode`

— set the permission posture`-- <claude args>`

— everything after is passed through verbatim to the underlying`claude`

Note

This lane is for hands-on interactive use: it needs a real terminal and doesn't support pipes or redirects — for non-interactive, one-shot output use a Subagent instead.

— every command, flag, and envelope.[CLI reference & advanced usage](/ethanhq/cc-fleet/blob/main/docs/cli.md)— the JS scripting API for the workflow lane.[Writing workflows](/ethanhq/cc-fleet/blob/main/docs/workflows.md)— how spawning, key safety, the conversion daemon, and the workflow engine actually work.[Architecture](/ethanhq/cc-fleet/blob/main/docs/architecture.md)`ccf <cmd> --help`

— always authoritative.

PRs are very welcome — bug fixes, new provider presets, docs, tests, features. Please read the ** contribution guide** first; a few house rules:

**UI changes and bug fixes need a screenshot or GIF** in the PR.**AI-** commits credit the tool with a*assisted*`Co-Authored-By`

trailer.**Fully AI-** PRs add an autonomous-PR marker at the bottom of the PR body.*authored*