{"slug": "show-hn-cc-fleet-run-other-llms-as-claude-code-workers-your-sub-drives", "title": "Show HN: Cc-fleet – run other LLMs as Claude Code workers, your sub drives", "summary": "A new open-source tool called cc-fleet enables Claude Code to use third-party large language models as workers, allowing users to run models from providers like DeepSeek, GLM, Kimi, and Qwen within Claude Code's multi-agent orchestration system without needing a Claude subscription.", "body_md": "**🤖 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 🚀**\n\n**English** · [简体中文](/ethanhq/cc-fleet/blob/main/docs/README_zh.md)\n\nClaude 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**.\n\nEvery third-party worker is a real `claude`\n\nprocess 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**.\n\n**Two steps to get going**: one-line install, register a provider. Then state your intent in Claude Code with `/workflow`\n\n, `/team`\n\n, or `/subagent`\n\n— or just describe the task in plain language, and Claude figures out the rest.\n\nNo Claude subscription? `ccf run <provider>`\n\nstarts an interactive session driven by that provider — **the same claude you know**, just running on the provider's model.\n\n**0. Install Claude Code first** — cc-fleet drives the official `claude`\n\nCLI, so install it if you don't have it yet (skip if `claude`\n\nis already on your PATH):\n\n**macOS / Linux:**\n\n```\ncurl -fsSL https://claude.ai/install.sh | bash\n```\n\n**Windows (PowerShell):**\n\n```\nirm https://claude.ai/install.ps1 | iex\n```\n\n**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`\n\nalias, so `ccf`\n\nlaunches it from then on), and installs the Claude Code plugin (skill + session hook) via the marketplace. Ready to use right after:\n\n**macOS / Linux:**\n\n```\ncurl -fsSL https://raw.githubusercontent.com/ethanhq/cc-fleet/main/install.sh | sh\n```\n\n**Windows (PowerShell):**\n\n```\nirm https://raw.githubusercontent.com/ethanhq/cc-fleet/main/install.ps1 | iex\n```\n\nOther channels (npm / go install / Releases / source) and adding the Claude Code plugin, installer overrides, and requirements & maintenance live in\n\n.[Install & maintenance]\n\n**Common commands:**\n\n```\nccf                      # open the interactive TUI\nccf doctor               # health check: dependencies, providers, plugin status\nccf update               # self-update by install channel + refresh the plugin\nccf uninstall --all      # remove the binary and plugin too\n```\n\nOnce installed, run `ccf`\n\nto register a provider and start delegating.\n\n|\n|\n|\n|\n|\n|\n\ncc-fleet's capabilities fall into two groups:\n\n**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`\n\nAgents Board: the phase → leaf tree |\ndrill into one leaf: full prompt and synthesized output |\n\n**Orchestration API**: multi-phase orchestration lives in a JavaScript file, with an API identical to Claude Code's native Workflow tool — `agent()`\n\nstarts a node, `parallel()`\n\nfans out, `pipeline()`\n\nchains a flow. The one difference is that `agent()`\n\ntakes a `provider`\n\noption to assign each node's model, so different vendors mix and run in parallel within a single run:\n\n``` js\nconst meta = {\n  name: \"api audit\",\n  description: \"map endpoints, then draft audit checklists\",\n  phases: [{ title: \"map\" }, { title: \"build\" }, { title: \"judge\" }],\n};\n\nphase(\"map\");\nconst maps = (await parallel(\n  [\"auth\", \"billing\", \"users\"].map((m) =>\n    () => agent(\"List the exported endpoints in module \" + m, { provider: \"deepseek\" }))\n)).filter(Boolean);\n\nphase(\"build\");\nconst checklists = await pipeline(maps,\n  (endpoints, _, i) => agent(\"Draft an audit checklist:\\n\" + endpoints,\n                             { provider: \"glm\", label: \"build:\" + i }));\n\nphase(\"judge\");\nconst verdict = await agent(\"Pick the strongest one and say why:\\n\" + checklists.join(\"\\n---\\n\"),\n                            { provider: \"claude\", model: \"opus\", label: \"judge\" });\nreturn { checklists, verdict };\n```\n\n**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:\n\n```\nRUN=$(ccf workflow run audit.js)            # starts in the background, prints the run id\nccf workflow wait \"$RUN\" --timeout 10m      # blocks until done, event-driven\nccf workflow stop \"$RUN\" --leaf build:1     # hold a single leaf (run keeps going)\nccf workflow restart \"$RUN\" --leaf build:1  # resume it\nccf workflow run audit.js --resume \"$RUN\"   # replay the journal, finished leaves hit cache\n```\n\n**Holding and restarting**: `ccf workflow stop --leaf`\n\n/ `--phase`\n\ndoesn't fail the run — it just pauses the named node: the run keeps going and other nodes carry on, until you `restart`\n\nit 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.\n\n**Wait without polling**: `ccf workflow wait`\n\nblocks 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`\n\nsucceeded, `1`\n\nfailed, `3`\n\nparked and waiting, `124`\n\nwait timed out (run still going), `130`\n\ninterrupted.\n\n**Budget-adaptive**: `budget.spent()`\n\n/ `budget.remaining()`\n\nare readable live inside the script (USD or tokens), so a workflow can decide for itself whether to dispatch another batch.\n\n**Mixing in your own subscription**: a node assigned `provider: \"claude\"`\n\nruns on your **own** Claude login — the `judge`\n\nabove uses your subscription, not a provider key, which suits a synthesis-and-finish node.\n\nfour teammates working side by side in tmux panes |\na teammate's overview / messages / output on the board |\n\n**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:\n\n**Be inside a tmux session**(`tmux new-session -s work`\n\n) so teammate panes can show up alongside you;**Enable Claude Code's agent-teams**: the first time you run`ccf`\n\nit detects this isn't on and offers to write it in for you — or add it once yourself to`~/.claude/settings.json`\n\n:\n\n```\n{ \"env\": { \"CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS\": \"1\" } }\n```\n\n**How they collaborate**: each teammate is a real `claude`\n\nprocess; Claude builds the team with native `TeamCreate`\n\nand assigns work with native `SendMessage`\n\n, 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.\n\n**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.\n\n**Park and restore**: `ccf hide`\n\ntucks a teammate's pane out of the way while the process keeps running — messages and context are never lost — and `ccf show`\n\nbrings it back. At cleanup, `ccf teardown`\n\nthoroughly 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.\n\n**Outside tmux**: the teammate runs in a background `cc-fleet-swarm-<team>`\n\nsession, exactly the same flow with the pane just not on screen. To look in, attach with `tmux -L cc-fleet-swarm-<team> attach`\n\n.\n\nfan out three subagents in parallel from one ask |\nthe job list and one job's detail |\n\n**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`\n\nis 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`\n\nwhen you need full-session capability.\n\n**Tool trimming and parallelism**: `--tools`\n\ntakes a comma-separated list to set exactly which tools are open (a replacement, not an addition to the defaults), `--skills=false`\n\nturns off the Skill tool, and `--mcp`\n\ncontrols 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.\n\n**Background and wake-up**: add `--background`\n\nto send a long job to the background, then `ccf subagent-status <job> --wait`\n\nblocks 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`\n\nyour program can branch on.\n\n**Structured result**: with `--json`\n\nyou 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.\n\n**Run key nodes on your own subscription**: as with Workflow, setting the provider to the reserved name `claude`\n\n(`ccf subagent claude --model opus …`\n\n) uses your own Claude login and bills your subscription — good for a synthesis-and-finish node, not large parallel batches.\n\npresets for many vendors |\nset each tier's model, effort, and permission |\n\n**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.\n\n**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>`\n\nsets the fleet-wide default provider, and any call that doesn't name one goes to it.\n\n**Multi-key rotation**: one provider can hold several API keys, rotated by `off`\n\n/ `round_robin`\n\n/ `random`\n\nto spread quota and avoid rate limits.\n\n**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`\n\n, readable only by you, or handed to `pass`\n\n, 1Password, Vault, or your OS keyring; every UI and log shows the key masked (`sk-…238`\n\n).\n\n**Codex (ChatGPT subscription)**: one device-code login and your ChatGPT subscription becomes a regular provider — usable across Workflow / Team / Subagent / run.\n\nWarning\n\n**Codex is unofficial.** Reusing a ChatGPT subscription outside the codex CLI may violate OpenAI's terms, and `ccf codex login`\n\nasks 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.\n\none-line launch: ccf run / ccf run codex |\ninside, it's a full claude — here on gpt-5.5 |\n\n**Launch**: `ccf run <provider>`\n\nopens an interactive `claude`\n\non the named provider; with no provider (`ccf run`\n\n) it resolves to the fleet-wide default.\n\n```\nccf run deepseek        # an interactive claude, on DeepSeek, billing the provider key\n```\n\n**It's just native claude**: `ccf run`\n\nadds no extra process layer — it replaces itself with `claude`\n\n, cc-fleet steps out entirely, and from then on it's a plain `claude`\n\nprocess whose feel and exit behavior match typing `claude`\n\nyourself.\n\n**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.\n\n**Flags**:\n\n`--model strong / fast`\n\n— override the default with the provider's strong or fast model`--permission-mode`\n\n— set the permission posture`-- <claude args>`\n\n— everything after is passed through verbatim to the underlying`claude`\n\nNote\n\nThis 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.\n\n— 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`\n\n— always authoritative.\n\nPRs are very welcome — bug fixes, new provider presets, docs, tests, features. Please read the ** contribution guide** first; a few house rules:\n\n**UI changes and bug fixes need a screenshot or GIF** in the PR.**AI-** commits credit the tool with a*assisted*`Co-Authored-By`\n\ntrailer.**Fully AI-** PRs add an autonomous-PR marker at the bottom of the PR body.*authored*", "url": "https://wpnews.pro/news/show-hn-cc-fleet-run-other-llms-as-claude-code-workers-your-sub-drives", "canonical_source": "https://github.com/ethanhq/cc-fleet", "published_at": "2026-06-21 01:40:27+00:00", "updated_at": "2026-06-21 02:07:15.425299+00:00", "lang": "en", "topics": ["large-language-models", "ai-tools", "developer-tools"], "entities": ["Claude Code", "Anthropic", "DeepSeek", "GLM", "Kimi", "Qwen", "Codex"], "alternates": {"html": "https://wpnews.pro/news/show-hn-cc-fleet-run-other-llms-as-claude-code-workers-your-sub-drives", "markdown": "https://wpnews.pro/news/show-hn-cc-fleet-run-other-llms-as-claude-code-workers-your-sub-drives.md", "text": "https://wpnews.pro/news/show-hn-cc-fleet-run-other-llms-as-claude-code-workers-your-sub-drives.txt", "jsonld": "https://wpnews.pro/news/show-hn-cc-fleet-run-other-llms-as-claude-code-workers-your-sub-drives.jsonld"}}