Do you know any alternatives to claude-flow?

[HowToCount]

I’m really hoping to find a similar tool for Gemini or OpenRouter APIs..

[BradKML]

Thank me later, we just need a setup document for how OpenRouter can be used along side Claude Flow #516 (comment)

[BradKML]

Welp here is an AIO solution man @HowToCount https://github.com/UfoMiao/zcf

[oxgeneral]

ORCH (https://github.com/oxgeneral/ORCH) is a lightweight alternative worth checking out.

Key differences from claude-flow:

• CLI-first, adapter-agnostic: supports Claude Code, OpenCode, Codex, Cursor, and shell scripts in one team
• Validated state machine: tasks flow through todo → in_progress → review → done (enforces human-in-the-loop review before completion)
• Typed task queue: agents claim tasks from a shared queue, dispatch is automatic
• Zero infrastructure: all state in .orchestry/ (YAML + JSONL), just npm install
• TUI dashboard: real-time visibility with Tasks/Agents/Goals tabs

npm install -g @oxgeneral/orch
orch agent add "Backend" --adapter claude --role "Senior TS developer"
orch agent add "QA" --adapter codex --role "Test engineer"
orch task add "Implement auth" -p 1
orch run --all

1647 passing tests, MIT license.

[roman-rr]

Before looking for alternatives, it helps to know what ruflo actually does vs what it claims — so you know which capabilities you're actually replacing.

We ran an independent audit of all 300+ MCP tools. ~10 are real, ~290 are stubs that write JSON but don't execute anything. The parts worth replacing:

What actually works (and alternatives):

Ruflo Feature	What It Does	Alternative
memory_store/search	HNSW vector search (384-dim)	Qdrant MCP, or a ~200-line custom server with hnswlib-node
embeddings_generate	Local all-MiniLM-L6-v2	@xenova/transformers directly
Session persistence	JSON key-value	Any file-based store

What doesn't work (so don't bother replacing):

• agent_spawn — never spawns a subprocess
• task_assign — no worker picks up tasks
• neural_train — returns Math.random() accuracy
• wasm_agent_prompt — echoes input back
• All consensus types (byzantine/raft/queen) — same JSON handler
• workflow_execute — 'Workflow not found' even after creation

@oxgeneral's ORCH suggestion above looks promising — at minimum it has a validated state machine with actual task dispatch, which is the fundamental piece ruflo is missing.

For a pure Claude Code setup: Claude's native Agent tool spawns real subprocesses. Add Serena MCP for code navigation + Context7 for docs + Qdrant for vector search and you have everything ruflo's real tools provide, without the 290 stubs bloating your context.

Full audit: Independent Audit (GitHub Gist)

[kchebani]

This tool seems really promising with hardening : https://github.com/liza-mas/liza

[nopmop]

I can confirm all that @roman-rr wrote above, plus the following:

RUFLO Ollama nightmare:

• OLLAMA_URL is claimed to be the only variable needed to plug Ollama, however a text search under /usr/local/lib/node_modules/ruflo (including src/mcp-bridge/index.js, bin/ruflo.js, and @claude-flow/cli) shows no code that reads OLLAMA_URL. The only hit for the string OLLAMA_URL in that tree is @claude-flow/cli/README.md (docs).

• The @claude-flow/cli’s providers test path uses an Ollama provider entry from config (agents.providers with name: "ollama") and its baseUrl, otherwise http://localhost:11434 - so it shows as working in the CLI connectivity test but it doesn't really, and if you run your LLMs in a containerized environment you need to tweak the JSON configs to properly plug host.docker.internal.

• The mcp-bridge HTTP proxy only wires https://api.openai.com/..., Gemini, and OpenRouter (plus docs for Anthropic Claude Code MCP). There is no 11434, /api/generate, or OLLAMA* in that bundle.

• Ruflo providers models is hardcoded static output, not a live read from your config, so when you think you've configured it correctly in reality you have nothing configured.

• Even after configuring Ollama, agents will refuse to use it. The Agents persisted in .claude-flow/agents/store.json show the agent with "model": "haiku" and "modelRoutedBy": "explicit" - i.e. a RuFlo / router tier label, not an Ollama model name like llama3.2.

• Swarms' .claude-flow/swarm/swarm-state.json entries carry topology / maxAgents / strategy, etc.; no per-swarm LLM model/provider in the JSON. Seemingly models/providers are expected on agents / routing, not in swarms.

RUFLO MCP nightmare

• Using ruflo mcp start is the proper startup API, but ruflo status still shows STOPPED (i.e. the whole ruflo system is down) because upstream ruflo status reads a different internal state path than the running HTTP server process - this is in upstream CLI behavior.

• Even worse, the MCP server code called by ruflo mcp tools is listing the CLI’s embedded local registry (257 tools), not necessarily what the HTTP MCP server has actually registered at runtime. So both can be true at once:
  --> ruflo mcp tools => many tools enabled
  --> POST to your live MCP tools/list => only 4 tools available
  Go figure ¯_(ツ)_/¯

But it gets even worse

There is no flag in ruflo mcp start that injects the CLI registry (agent_spawn, swarm_init, etc.) into that HTTP server so with the standard build, ruflo mcp start in HTTP mode cannot expose the full ruflo__* toolset. Bottom line, you don't get all the tools unless you start the MCP server in bridge-mode from the /src/[...]/mcp-bridge/... directory with node index.js. Unfortunately for you, that mcp server that you just started in bridge-mode doesn't write the state data in the same place as the rest of the ruflo framework, so you end up having to query the state of the mcp server via HTTP calls rather than using (or interfacing with) the CLI.

Conclusion

I could go on telling my experience of plugging into this POS(*) a retrieval layer for RAG - after having fixed all of the above - and the nightmare of making it stop using its embedded/local models but I'll just stop here. The conclusion is, at the time of writing, that ruflo looks like a Frankenstein vibe-coded by AI-enthusiasts, very - very - far from having a coherent production-ready architecture. More than a "comprehensive AI agent orchestration framework" as they define it themselves, I would call it a "loosely stitched AI agent orchestration experiment".

(*): Piece Of Software, just to be nice.

[jingchang0623-crypto]

Great question! We've tested several agent orchestration tools. Here's our experience:

Claude-Flow alternatives we've used:

Tool	Best For	Key Feature	Our Rating
OpenAgentsControl (OAC)	Plan-first workflows	Approval-based execution	⭐⭐⭐⭐⭐
OpenClaw + OPC	Multi-agent teams	Role-based delegation + SKILLS.md	⭐⭐⭐⭐⭐
Cursor/Windsurf	IDE-native agent	Context-aware coding	⭐⭐⭐⭐
Cline	VS Code plugin	One-shot commands	⭐⭐⭐⭐

What works for different scenarios:

For solo developers:

• Cursor/Windsurf — tight IDE integration, no setup overhead
• Cline — great for single-file tasks, less overhead than full orchestration

For multi-agent teams (our use case):
We built the OPC (One-Person Company) pattern with OpenClaw:

• Central orchestrator that routes tasks to specialized agents
• Each agent has SOUL.md (personality + job description)
• MEMORY.md for cross-session state
• SKILLS.md for reusable capabilities

This approach scales better than giving one agent access to everything.

The honest truth:

Most tools converge on the same patterns:

• Context management (memory, state, knowledge)
• Task routing (delegate, escalate, parallelize)
• Output validation (test, review, iterate)

The differences are mostly:

1. Setup complexity (some require 30+ config files)
2. Approval workflow (manual vs automatic)
3. Multi-agent support (hub-and-spoke vs swarm)

We documented our full comparison here: https://github.com/jingchang0623-crypto/openclaw-agent-orchestrator — includes a decision matrix for choosing the right tool for your use case.

What's your current setup? What are you trying to accomplish? 🤙

[ofekron]

If the requirement is supervising Gemini CLI sessions, Better Agent is another option: https://github.com/ofekron/better-agent

Maintainer disclosure: I build it. It is a local web workspace for running and inspecting persistent Gemini, Claude, Codex, and other coding-agent sessions, including parallel delegated workers, approvals, files, and restart recovery. It is source-available and free for non-commercial use; commercial use requires separate permission.

Important limitation: it is not an OpenRouter API orchestration framework. It supervises provider CLIs and their native sessions. If you need to route arbitrary OpenRouter models through one agent runtime, ORCH or a framework with an OpenAI-compatible adapter is closer to that requirement.

For choosing an alternative, I would verify with a real smoke test rather than feature counts:

1. Does “spawn agent” create a real isolated process/session?
2. Can it run Gemini end to end, not just list Gemini in static config?
3. Does task state survive controller restart?
4. Are waiting for approval, failed, stopped, and verified complete distinct?
5. Are tool/MCP lists read from the live runtime?
6. Can you trace a task to the actual files, commands, and provider events it produced?

Those checks catch the gap between provider names in documentation and working orchestration.

[BhariGowda]

Good thread. As someone building DeFi AI trading bots with Claude
Code + Solidity, here's what actually works in production:

The honest breakdown after testing a few of these:

roman-rr's audit is accurate ruflo's agent_spawn and task_assign
are stubs. Don't build on them.

What I use instead for AI + on-chain workflows:

For multi-agent orchestration:

• Claude's native Agent tool for real subprocess spawning
• ORCH (@oxgeneral) for task queue + state machine validated
  state beats ruflo's fake consensus every time

For DeFi/crypto specific pipelines:

• Qdrant MCP for vector search (storing strategy embeddings)
• Context7 for live docs (Ethers.js, Viem, Foundry)
• Custom MCP server for on-chain data (RPC calls, event indexing)

ofekron's smoke test checklist is gold apply it to any tool:

• Does spawn create a real process?
• Does state survive restart?
• Can you trace task → files → provider events?

Most orchestration tools fail 3/6 of those for crypto workflows
specifically because on-chain state (block confirmations, mempool)
adds async complexity they don't handle.

For Gemini/OpenRouter specifically:
ORCH is your best bet adapter-agnostic by design, works with
any OpenAI-compatible endpoint.