I built a tool to run Claude Code subagents & teammates on any model — DeepSeek, GLM, Kimi, Qwen... — your Claude sub drives

I've been deep in Claude Code's multi-agent stuff for a while (the workflows / agent teams / subagents orchestration), and the thing that always bugged me: it only ever runs Anthropic's own models. If I wanted to fan a job out across a bunch of agents, every one of them was burning my Claude budget.

So I built cc-fleet to scratch that itch, and it's at the point where I actually use it daily, so I'm putting it out there. It's an open-source Go CLI + a Claude Code plugin (Apache-2.0).

The trick that made it click for me: a provider "worker" is a genuine claude process — same REPL, same tools, same orchestration — just launched with its backend model swapped to whatever provider you point it at. So Claude Code drives it exactly like a native agent, because it basically is one. It just happens to be thinking with DeepSeek or GLM or Kimi or Qwen or MiniMax (or any Anthropic-/OpenAI-compatible endpoint, plus a Codex subscription) under the hood.

Two things that genuinely made me go "huh, neat":

  1. You don't need a Claude/Anthropic subscription to run Claude Code. ccf run deepseek drops you into a normal interactive claude session running on DeepSeek's model. Full REPL, all the tools. I pointed it at a couple of cheaper/regional providers and it just... worked.
  2. You can fan one task out across different models at once. Tell your main session "map each module with deepseek, have glm draft an audit checklist, gpt synthesizes" and it writes the JS workflow script and runs it in the background — off your main context. Watching a board of leaves light up across three different vendors is the part that got me.

On the auth side, which I cared about a lot: your Claude login (OAuth or API key) is never touched, and provider API keys go through an apiKeyHelper so they never land in env, argv, or your shell history.

Honest limitations so nobody feels misled:

  • The tmux-based Agent Teams lane is Unix-only (macOS/Linux). Subagents, workflows, and ccf run work on Windows too, but no tmux teammates there.
  • Output quality is whatever the provider gives you — a cheap model is still a cheap model. cc-fleet doesn't make DeepSeek reason like Opus; it just harnesses it.
  • It's young. I'm the author, and it's mostly tested through my own daily use so far.

Question for you all: when you fan work out to multiple agents, do you actually want different models for different roles (cheap model for grunt tasks, stronger model for synthesis), or do you just want the cheapest thing that doesn't fall over? I'm trying to figure out whether per-role model routing is a real need or just a thing I find cool.

6 comments · 100% upvoted · source · other discussions

comments

Ethan-Coder [OP]

Repo (install one-liner in the README): https://github.com/ethanhq/cc-fleet 🌟

AutoModerator

Thank you for your submission! To keep our community healthy, please ensure you've followed our rules.

I am a bot, and this action was performed automatically. Please contact the moderators of this subreddit if you have any questions or concerns.

Mithryn

Responding because you asked nicely and I appreciate you sharing. I don't think most users approach multi-model like this; but I have. I built out a "clutch" for tasks and then shift to the model that makes the most sense for that task based on price and prior success/struggle.

I think that's the best use case for having this kind of architecture. Also, if one goes down, we have priorities for what the next-best model is, and shift to that. While the rest of the Claude sub is complaining that the model is down or they ran out of usage; and stating they are going to rage quit, I'm just working away uninterrupted.

This is good work. Be proud. And don't give everything away ;-)

Ethan-Coder [OP]

Ha, thank you — that genuinely means a lot.

Your "clutch" is exactly the use case I had in mind, so let me be straight about where cc-fleet actually is: it gives you the substrate — every provider registered, instant `ccf run <provider>` switching, mixed-provider teams, and workflow scripts where you can code the routing — but it does NOT ship an automatic "pick by price + prior success, fail over to next-best when one's down" policy. That logic is still yours to write, and it sounds like you've built the smart part.

The "everyone else rage-quits the outage while I work away uninterrupted" angle is honestly a sharper pitch than anything I wrote — mind if I borrow that framing (credited)?

Re: don't give everything away — it's Apache-2.0, so the mechanism is fully public by design 😄. The only "moat" is ergonomics + keeping keys out of env/argv; secrecy was never the play.

How are you tracking the per-task "prior success/struggle" signal — manual notes, or scored automatically?

Mithryn

Please, feel free to use my phrasing.

Motes are more real than anyone is giving them credit for today. In the 1800s it was very expensive to be a professional photographer. Buying one of those accordian cameraa, developing film, flash bulbs. Today, everyone has a camera in their pocket (inclused with their phone) that would put those to shame and yet there are still professional photographers.

Laziness. Interest. Effort. Taste. Experience.

These are motes. Code isn't any more, but that was just the tool.

Where you say "Just Apache", I say in hundreds of posts, only two of us have built any kind of clutch.

Sure others could, if they see the effort as valuable, and interesting... but if they do it better (or better for our usecases) that is not for certain.

As to the cost dynamic.. no. That's for my clients to benefit from. But I will leave you a hint, people will pay for that. Just that service alone.

Because they don't habe the experience to even know where to start.