Orchemax

Orchemax vs otros orquestadores de agentes

Orchemax es un orquestador de agentes: dirige las CLI de código que ya pagas. Los gateways de asistente personal como OpenClaw y Hermes, y los frameworks de agentes como CrewAI, AutoGen y LangGraph, son asientos y librerías que un orquestador maneja — no competidores, así que no están en esta tabla. Par principal: Traycer.

La matriz

Cada celda es un hecho del relevamiento de orquestadores del 2026-09-15 o Sin documentar — nunca una suposición. Donde un par nos gana, lo decimos debajo de la tabla.

Desliza de lado para leer todas las columnas.

Capacidad Traycer Paperclip Gas Town + Beads Kiro Crew claude-squad Orchemax
Dónde se para Extensión de VS Code y app de escritorio, encima de tu agente Server Node + UI React; los agentes se le enganchan gt como gestor de workspaces sobre tmux; bd es una segunda CLI Gateway + dashboard, corriendo como servicio systemd/launchd TUI de tmux con una sesión por agente Debajo de la CLI que ya abriste: herramientas MCP y un hook del harness, sin ventana nueva
Quién dirige Modos plan-first dirigen a los agentes; un segundo director está Sin documentar Organigrama de “empleados”, con gates de aprobación arriba “Mayor” — una instancia de Claude Code corre los convoys; no hay regla documentada contra un segundo director Un crew delega en subagentes; vos aprobás pedidos de herramienta, sin regla de director único Sin director: las instancias son independientes y vos cambiás entre ellas Un solo Chair por proyecto por orden de llegada; el segundo se rechaza
Choque entre agentes Planifica antes de que alguien escriba; sin locks de archivo documentados Checkout de tarea atómico más presupuesto — nivel de negocio, no de archivo Worktree por polecat, bead reclamado y merge queue bisectora (Refinery) Sin documentar — el README no nombra worktrees, locks ni merge queue Un workspace de git por instancia; aislamiento por checkout, sin locks finos Worktree y un lock compartido con TTL tomado antes de la edición compartida — sin merge queue
Anti-duplicado Memoria compartida entre modelos — contexto, no símbolos Reuso de skills documentadas por agente; sin registro de símbolos Grafo de dependencias en Dolt, consultable por SQL — tareas, no símbolos de código Sin documentar; memoria semántica en proceso, no una ley de símbolos tipada Ninguno — es un gestor de terminales guard dup en PreToolUse más el registro de firmas exportadas (orch:export)
Gobernanza Review Mode como modo de primera clase; boards que un humano co-edita en vivo Organigramas, presupuestos, gates de aprobación, config versionada, rollback seguro Convoys, Mayor y bd remember; sin gate humano obligatorio documentado Aprobaciones interactivas por chat, catálogo de comandos denegados por defecto, bloqueo de rutas protegidas, kirocrew security verify Sin ledger; leés los diffs a mano antes de aplicarlos Ledger con task_claim sobre la línea misma, más verify_report
Workers heterogéneos Claude Code, Codex, Cursor, OpenCode — tabla de “fully supported” OpenClaw, Claude Code, Codex, Cursor Claude Code, Copilot, Codex, Gemini; bd setup conecta más kiro-cli sobre ACP; el README no nombra una segunda CLI de código Un flag -p cambia entre claude / codex / aider / gemini Cliente ACP para Gemini CLI y OpenCode (opt-in agents.transport: acp); Codex, Claude y Cursor como subprocesos
Lectura de costo Sin medidores de crédito sobre tu propia suscripción; su inferencia se cobra aparte Presupuesto aplicado por agente y por tarea, de forma atómica Ninguno nativo; scheduler.max_polecats limita concurrencia, no gasto Sin documentar — el README no expone tokens, costo ni presupuesto Ninguno — cada instancia gasta lo que gaste su CLI orch usage · --leaks · --governance leen tus propios transcripts; Team limita el presupuesto de una tarea antes de lanzarla
El código no sale Host local; la nube puede sincronizar datos de tareas y el Privacy Mode es un tier pago Sí — MIT, server Node self-host Sí — OSS y local; Beads solo sale si hacés dolt push Sí — Mac, contenedor local o una máquina remota que vos controlás Sí — OSS, tmux en tu máquina Sí — el runtime es local; una cuenta vinculada recibe contadores y eventos, nunca código

Dónde nos ganan hoy. La Refinery de Gas Town es una merge queue bisectora que batchea merge requests, corre los gates y aísla el malo; Orchemax no tiene merge queue. Paperclip aplica un presupuesto y un gate de aprobación antes de que el agente gaste, con config versionada y rollback seguro de un cambio malo. Kiro Crew (AWS, Apache-2.0) corre trabajo agendado 24/7 como servicio del sistema, muestra el plan, las llamadas a herramientas, los gates y los resultados de cada agente en una sola vista de actividad, y guarda un registro de eventos de seguridad verificable. El Review Mode y los boards de Traycer dejan que un humano co-edite junto a los agentes en tiempo real. Multica, que quedó afuera por no tener repo localizable, maneja unas doce CLI — más que cualquiera de la tabla.

Fuera de la tabla, por ancho: Conductor (Melty Labs) — app de Mac de código cerrado, worktree de git por agente con revisión diff-first, solo Claude Code y Codex, sin API abierta para sumar un tercero, sin medidor propio (“pagás solo tu costo de API”) y sin anti-duplicado documentado.

Elegí Gas Town si el cuello de botella es el throughput de merge con veinte agentes. Elegí Paperclip si los topes de gasto y las aprobaciones importan más que el dedup a nivel de código. Elegí Kiro Crew si querés corridas desatendidas 24/7 sobre la CLI de un solo proveedor, con una superficie de comandos sandboxeada y auditada. Elegí Traycer si el trabajo es planificar y revisar en boards compartidos con humanos. Elegí claude-squad o Conductor si lo único que necesitás son sesiones paralelas en worktrees aislados. Elegí Orchemax si la CLI que ya abriste debe seguir siendo la que abrís — con un lock, un registro, un claim y una lectura medida debajo. Vendemos talleres gobernados y un mirador de CTO, no otro IDE de agentes. A fondo: Orchemax vs Traycer.