u/Ethan-Coder

I am glad that cc-fleet can help you.

😂

I hope so too.

But that is exactly how Fable5 was disabled.

Thanks, if this helps you.

Thank you for liking it.

Good comparison — they look similar on the surface (both let Claude Code run on non-Anthropic models) but the goals are actually opposite.

free-claude-code is a global proxy: you point ANTHROPIC_BASE_URL at its local server and your whole session routes to one configured model. It's polished — admin UI, ~17 providers including local ones (Ollama/llama.cpp) — and if your goal is "run Claude Code on a free/cheap single model," it's honestly a cleaner pick than mine. But it's one session, one model at a time, and it fully replaces Anthropic — your Claude/Opus sub isn't in the picture.

cc-fleet is the inverse. It doesn't repoint your main session at all — your real Claude sub stays the driver, untouched. It swaps the backend per spawned worker process (`claude --settings <profile>.json --model <id>`), so the point isn't "one cheap model," it's multi-agent: subagents, tmux agent-teams, and resumable workflows running across different providers at once, orchestrated by your sub. DeepSeek maps files while GLM drafts while your Opus synthesizes — one run. (It can also do the single-model no-sub thing via `ccf run <provider>`, but that's not the reason it exists.)

So: free-claude-code if you want to replace Anthropic with one model (and you get local models + a nicer UI today). cc-fleet if you want to keep your sub as the brain and fan work out to many models as teammates. Genuinely different tools — I'd reach for theirs for the single local-model case.

Thank you. I'm very happy if this project has helped you.

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?

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

Thanks

Forwarding OAuth subscriptions simultaneously could lead to your Anthropic account being banned; this is because your agent tool would effectively be holding and forwarding Claude's authentication credentials—a practice not permitted by Anthropic.

Clean — the auth-scheme translation (x-api-key vs Bearer) is the annoying part and you nailed it.

Disclosure, I'm biased (I wrote cc-fleet), so this is "I went down this road" not a knock: since it repoints ANTHROPIC_BASE_URL for the whole client, it's all-or-nothing — your example routes claude-opus-* to DeepSeek too. So you can't keep your real Opus subscription as the driver and only farm the cheap tiers out. And routing the sub through a proxy to fix that is exactly what risks getting the account flagged.

That's why cc-fleet leaves the main session native and swaps the backend per worker process instead of globally — your sub stays the brain, cheap models do the grunt work. For a no-sub / API-keys-only setup though, your single proxy is simpler. How are you handling tool-call fidelity across providers?

I’m building cc-fleet, an open-source tool that lets Claude Code spawn vendor LLMs like DeepSeek, Qwen, Kimi, GLM, and MiniMax as real teammates or one-shot subagents.

The idea is to keep Claude Code as the lead coding agent, while cheaper models handle bounded side tasks like diff review, file summarization, log inspection, and implementation comparison.

Repo: https://github.com/ethanhq/cc-fleet

Would love feedback from people experimenting with multi-model coding workflows.

I don’t think there is one best coding agent for everything.

Claude Code feels strongest when I want deep repo understanding and planning. Codex/Gemini-style tools can be useful for cheaper or parallel attempts. Cursor is still nice when I want the IDE-first workflow.

The setup I like most is not tool loyalty, but routing: use the strongest model for orchestration and cheaper/faster models for bounded side tasks.

The way I think about it:

CLAUDE.md = project rules / persistent context
slash commands = manual workflows
hooks = automatic guardrails
skills = reusable task instructions
subagents = separate workers with their own context

The mistake is trying to use all of them everywhere. I’d pick one owner for each responsibility, otherwise the setup becomes harder to reason about than the actual code.

Small extra thought: I don’t think this is only about cost.

Claude-native subagents/teammates are great for consistency, but different vendor models can provide different failure modes and second opinions.

For review/debugging, that diversity can be useful: let Claude Code stay the lead, but let other models challenge it from different angles.

This is exactly why I’ve been experimenting with cheaper vendor models for subagent-style work.

Many side tasks — reviewing a diff, summarizing a file, checking logs, comparing approaches — don’t always need Claude-level tokens if Claude Code is still the main orchestrator.

I’m building cc-fleet for this: Claude Code stays the lead, while DeepSeek/Qwen/Kimi can run as teammates or one-shot subagents.

https://github.com/ethanhq/cc-fleet

Still early, but it feels like a more cost-effective pattern than burning Claude tokens on every side quest.

I like the idea, but I’d be careful with the “AI employees” framing.

The useful version for me is less “give every agent a job title” and more “keep one agent responsible for the final outcome, then delegate narrow tasks to workers.”

Review this diff, inspect this module, summarize this context, compare two approaches — those work well. Letting multiple agents all own the same feature gets messy fast.

I think of subagents as “bounded calls” and agent teams as “persistent collaborators.” Subagents are great when the output can be summarized cleanly back to the main session. Agent teams become more interesting when the worker needs continuity, visibility, or its own long-running context.

The tricky part is not spawning more agents, but designing the handoff: what context they get, what they are allowed to change, and how the lead agent decides whether to trust their result.

I’m also skeptical of the “AI dev team with PM/designer/backend/frontend/QA” framing when all agents are trying to own broad parts of the same feature.

The useful version, at least for me, is much narrower: keep one main agent as the owner/orchestrator, then use other agents for bounded tasks like review, alternative implementation ideas, test generation, log analysis, or summarizing large files.

So I don’t think “more agents” is automatically better. The value comes from reducing context pressure and getting independent second opinions, not from pretending the agents are a full company.

This is the main reason I’m more interested in “visible workers” than completely hidden subagents.

For short tasks, headless subagents are fine. But for anything that can drift — debugging, refactors, investigation — I want to see the worker’s intermediate reasoning/output and be able to interrupt or redirect it. Otherwise the main agent may only find the mistake after the subagent has already gone too far.

A separate pane/session per worker feels clunkier, but it gives much better observability.

cc-fleet (https://github.com/ethanhq/cc-fleet) — an open-source Claude Code plugin that turns Claude Code into a multi-model coding team.

It lets Claude Code use DeepSeek, Qwen, Kimi, GLM, MiniMax, etc. as coding teammates or one-shot subagents for code review, debugging, summarizing large files, comparing implementation ideas, and parallel research.

Claude Code stays the lead/orchestrator, while each vendor worker uses its own API key. Demo GIF is in the README.

https://preview.redd.it/n3jooiwutl4h1.png?width=3020&format=png&auto=webp&s=e1d4d00ac488b150d559627c80c96bd2b82bc639

I built cc-fleet, an open-source Claude Code plugin that lets Claude Code use other vendor LLMs such as DeepSeek, Qwen, Kimi, GLM, MiniMax, etc. as coding teammates or one-shot subagents.

The goal is to keep Claude Code as the lead/orchestrator, while delegating tasks like code review, debugging, summarizing large files, comparing implementation ideas, or parallel research to different models.

It currently supports two workflows:

1. Teammate mode — long-lived vendor LLM workers that can participate as Claude Code teammates.
2. Subagent mode — one-shot headless calls for focused tasks like review, debugging, summarization, and analysis.

It is still early, but the basic workflow is working. I’d love feedback from Claude Code users on whether this multi-model teammate workflow is useful in real coding sessions, and which providers/models would be most useful to support next.

GitHub: https://github.com/ethanhq/cc-fleet

Demo GIF is in the README.