Anthropic
Claude
Razonamiento profundo para la arquitectura, la planificación y la compuerta de preparación de la Ola 3: el modelo con el que se construyó primero la tubería.
βάθος, griego para “profundidad, el abismo”.
Dale a tu IA multimodal la profundidad de un equipo de producto completo.
BATHOS convierte una sola sesión de codificación con IA — en Claude, Codex, GLM, Kimi, DeepSeek o Qwen — en un equipo disciplinado:17 roles especialistas a lo largo de una tubería de 7 olas, un modelo elegido ola por ola, enrutamiento adaptativo a la escala y compuertas de calidad estrictas, todo respaldado por un motor determinista en Rust.
v0.4.0 · motor en Rust · seis proveedores de modelos, elegidos ola por ola
Varios modelos, un equipo de producto completo
El equipo es agnóstico al modelo. Los mismos 17 roles, la tubería de 7 olas y las compuertas estrictas ahora funcionan sobre el modelo de frontera que elijas — seis proveedores — sin reescrituras ni dependencia. Asigna el modelo que mejor encaje en cada rol y cada ola.
OpenAI
Codex
Preciso en implementación y refactorización. Corre como subproceso delegado, así que puede compartir ola con cualquier otro runtime.
Zhipu · Z.ai
GLM
El único backend intercambiable con la conexión verificada en vivo en este repositorio. Capaz y económico para los roles de alto volumen.
Moonshot AI
Kimi
Un flagship de un millón de tokens más niveles dedicados a código, a través del endpoint compatible con Anthropic de Moonshot.
DeepSeek
DeepSeek
Niveles flagship y rápido a bajo coste. El catálogo recoge también sus rarezas, incluidos los campos que su endpoint ignora en silencio.
Alibaba Cloud
Qwen
Niveles flagship, equilibrado y flash a través de Model Studio, cuyo endpoint es por espacio de trabajo en lugar de una única URL fija.
Elige un modelo por rol, por ola, o no lo toques en absoluto: el motor determinista en Rust, las compuertas y la cadena de auditoría permanecen idénticos. Las conexiones de API en vivo están verificadas para Claude, Codex y GLM; Kimi, DeepSeek y Qwen están conectados y documentados a partir de las especificaciones oficiales de sus proveedores, pero todavía sin comprobar contra una clave real.
Instalación
Compila el motor de Rust para tu plataforma, apunta BATHOS_BIN hacia él y ejecuta la tubería desde Claude Code con el modelo que elijas: cualquiera de los seis proveedores admitidos.
1 — Obtén el código y compila el motor
2 — Vincula BATHOS con tu proyecto
Haz que βάθος esté disponible en tu proyecto
Se ajusta a la plataforma que elegiste en el paso 1. Usa este repositorio como directorio de trabajo o adopta βάθος en tu propio proyecto.
# Option A — use this repo as your working directory
# .claude/ (commands, agents, hooks) is already wired — just open Claude Code here.
# Option B — adopt βάθος into your own project:
./install.sh --into /path/to/your/project # --force overwrites an existing .claude/
export BATHOS_BIN="/path/to/bathos/core/target/release/bathos"3 — Ejecuta la tubería
Ejecuta las olas en el proveedor que elegiste
Abre Claude Code en tu proyecto, elige tu modelo con /model-config y ejecuta los comandos de olas en orden.
/team-kickoff
/route /abs/path/to/project
/wave1-discovery /abs/path
/wave2-design /abs/path
/wave3-story-gate /abs/path
/wave5-implement /abs/path
/wave6-verify-report /abs/path
/team-confirmRequiere Claude Code v2.1.32+ con Agent Teams activado — con cualquiera de los seis proveedores admitidos —, además del toolchain de Rust (y jq para los hooks de bash).
Estructura donde un chat no la tiene
Una única conversación larga con un LLM se desvía: se pierde el contexto entre el diseño y la construcción, se omiten las verificaciones, y el mismo modelo escribe y aprueba su propio trabajo. BATHOS reemplaza eso con estructura.
Chat LLM simple
BATHOS
Una sola conversación, con deriva de contexto creciente
17 roles especialistas a lo largo de una tubería de 7 olas
Contexto perdido entre el diseño y la implementación
Ficheros de historia autocontenidos, sin pérdida de contexto (Ola 3)
Esfuerzo implícito, único para todo
Un enrutador adaptativo a la escala con niveles explícitos Lv0–4
La implementación empieza en cualquier momento
Una compuerta de preparación estricta que bloquea físicamente la construcción ante un FAIL
El autor también “verifica” su propio trabajo
Revisores independientes y una cadena de auditoría a prueba de manipulación
Consejos que te anulan de forma silenciosa
Soberanía del usuario: la IA propone, tú decides
Dos planos, un solo runtime
En su mayoría escribes comandos slash. Un único binario en Rust es el núcleo determinista al que esos comandos invocan por debajo.
Markdown bajo .claude/
Orquestación
Comandos slash, roles y hooks que ejecutan las olas y despliegan, revisan y retiran a los compañeros de equipo, dirigidos por el líder: tu sesión principal de codificación, ejecutándose en el proveedor que elegiste para esa ola.
Un único binario estático en Rust
Motor
Calcula y hace cumplir el estado, las compuertas, las transiciones de ola, el enrutamiento, la frescura de las historias y los plugins, invocado automáticamente por los hooks y los comandos.
Una tubería de entrega de siete olas
El trabajo avanza desde el descubrimiento hasta una release verificada a través de olas explícitas. La línea principal es W0 → W1 → W2 → W3 → W5 → W6; la propiedad intelectual y la investigación (W4) son un complemento opcional fuera de la ruta crítica.
W0
Análisis
Caleb
Preinforme opcional: lluvia de ideas, forjar la idea, brief de producto.
W1
Descubrimiento y mercado
John · Caleb
Ingeniería inversa e investigación de mercado; afinar la USP.
W2
Plan · arquitectura · diseño
Joshua → James · Jonnathan
La planificación abre la compuerta de la ola, luego la arquitectura y la UX en paralelo.
W3
Ingeniería de historias
Matthew + Thomas · Matthias
Condensar en ficheros de historia autocontenidos; la compuerta de preparación para la implementación.
W4
PI e investigación
Mark · Nathanael
Complemento opcional, fuera de la ruta crítica: patentes y artículos.
W5
Implementación
Phillip · Andrew · Stephen
Backend, frontend y ML se construyen sobre los ficheros de historia.
W6
Verificar · docs · informe
Thomas · Michael · Hananiah · Martin
Revisión, auditoría de seguridad, refactorización que preserva el comportamiento y el informe de release.
Ola 3: el corazón
La Ola 3 cierra la brecha entre el diseño y la construcción: el ingeniero de historias condensa el trabajo previo en un fichero de historia autocontenido donde cada afirmación técnica queda vinculada a su fuente, los revisores independientes dan el visto bueno, y ante un FAIL un hook bloquea físicamente la entrada a la implementación.
Elige el modelo ola por ola
El descubrimiento, la arquitectura y la implementación no son el mismo trabajo, así que ya no tienen por qué correr sobre el mismo modelo. Cada ola puede nombrar su propio proveedor, y el motor te obliga a cumplirlo.
- Claudenative
- Codexsubprocess
- GLMenv-swap
- Kimienv-swap
- DeepSeekenv-swap
- Qwenenv-swap
- Un plan por ola, y por rol
- bathos model set --wave W5 --runtime kimi registra la elección de esa ola en model-plan.json. Una asignación de rol gana a la de su ola, y la resolución cae por cinco pasos — rol → ola → valores por defecto → frontmatter del agente → valor por defecto del runtime — y cada valor muestra de qué paso viene.
- Seis proveedores, una sola interfaz
- Claude corre de forma nativa, Codex como subproceso delegado, y GLM, Kimi, DeepSeek y Qwen a través de sus endpoints compatibles con Anthropic. Un único predicado decide qué runtimes pueden compartir un lote, así que añadir un séptimo proveedor consiste en enseñárselo a ese predicado, no en reescribir las reglas.
- Una compuerta, no una promesa
- Las variables de entorno son globales al proceso, así que dos proveedores intercambiables no pueden convivir en una misma sesión. bathos model validate --wave lo detiene con exit 2 e imprime el procedimiento de cambio, en lugar de fingir que los modelos se intercambian en caliente por debajo.
- El catálogo es una carta, no una valla
- Treinta modelos catalogados entre los seis proveedores, cada uno marcado según si se confirmó en la documentación oficial del proveedor, y con los ID retirados aparte. Los ID de modelo siguen siendo texto libre, así que un modelo más antiguo o más económico sigue funcionando, y un lanzamiento nuevo es una edición de JSON, no una recompilación del motor.
$ bathos model set --wave W2 --runtime claude
$ bathos model set --wave W5 --runtime kimi
$ bathos model set phillip --runtime codex
# a role assignment beats its wave
$ bathos model validate --wave W5
→ exit 2 · session is claude, W5 wants kimi
save → set env → restart → /cold-startDeclara el proveedor en cada ola; validate detiene la ejecución antes de que una ola arranque en el backend equivocado.
¿Se acabaron los tokens? Cambia el modelo, no el plan.
El límite de uso es donde mueren casi todas las ejecuciones de agentes: el compañero se queda callado y se lleva consigo todo lo que tenía en la cabeza. Aquí es solo una pausa. Cada entrega ya vive en disco, así que rediriges al equipo hacia un proveedor que aún tenga presupuesto desde la línea de comandos, y la ola sigue donde se detuvo.
1 · Reconocer
Un compañero en silencio suele ser cuota
Un compañero que deja de producir salida casi nunca se ha caído: nueve de cada diez veces es el límite de sesión de la cuenta, y su propia transcripción lo dice. No lo mates. bathos model show imprime en su cabecera el backend de la sesión, así que ves qué proveedor se agotó y qué roles estaban sobre él.
2 · Redirigir
Un comando, por ola o por rol
bathos model set --wave W5 --runtime glm --model glm-5.3 escribe el nuevo proveedor de esa ola en model-plan.json; nombrar un rol en su lugar sobrescribe solo ese rol, y bathos model unset lo devuelve al valor de reserva. Solo se escribe la entrada que cambiaste: el resto del plan queda intacto.
3 · Reanudar
Un reinicio, y nada perdido
A GLM, Kimi, DeepSeek y Qwen se llega intercambiando ANTHROPIC_BASE_URL, y esa variable es global al proceso: el cambio cuesta un guardado, un cambio de entorno y una sesión nueva, nunca un intercambio silencioso a tus espaldas. Codex, delegado como subproceso, no cuesta ninguno. /cold-start restaura la sesión y la ola se rehace desde los artefactos en disco.
# 1 — which backend am I on, and what just ran dry?
$ bathos model detect # ANTHROPIC_BASE_URL → claude|glm|kimi|deepseek|qwen
$ bathos model show # effective runtime/model per role, and its source
# 2 — re-point the wave (or one role) at a provider that still has budget
$ bathos model set --wave W5 --runtime glm --model glm-5.3
$ bathos model set stephen-ml-engineer --runtime codex
# a role assignment beats its wave · unset returns it to the fallback
$ bathos model validate --wave W5
→ exit 2 · session is claude, W5 wants glm
1) take the whole batch to glm 2) move the role to claude / codex
3) split the wave: finish this batch, shut down, restart on glm
# 3 — env-swap runtimes only: save, swap, restart, resume
/save
$ export ANTHROPIC_BASE_URL=https://api.z.ai/api/anthropic
$ export ANTHROPIC_AUTH_TOKEN=… # DeepSeek reads ANTHROPIC_API_KEY instead
# restart Claude Code → /cold-start → re-run /wave5-implementvalidate se niega a arrancar una ola sobre el backend equivocado, e imprime las tres salidas en vez de un stack trace.
Cambiar de proveedor no cambia nada más: los mismos 17 roles, el mismo vocabulario PASS / CONCERNS / FAIL, la misma cadena de auditoría, el mismo orden de olas. Los IDs de modelo son texto libre y no una allowlist, así que un modelo más barato o más antiguo de la misma cuenta también funciona — y bajar un escalón suele ser la vía más rápida para superar un límite, sin necesidad de un segundo proveedor.
Enrutamiento adaptativo a la escala
BATHOS activa solo las olas que una tarea necesita. El enrutador recomienda un nivel a partir de cuatro ejes de riesgo; tú lo confirmas.
| Nivel | Tipo de trabajo | Olas activas |
|---|---|---|
| Lv0 | Corrección de errores / trivial | W5 (+ W6 mínima) |
| Lv1 | Función pequeña / refactor local | W2 ligera + W3 (reducida) + W5 + W6 ligera |
| Lv2 | Función / módulo estándar | W1 + W2 + W3 + W5 + W6 |
| Lv3 | Producto nuevo / grande | W0–W6 (W4 opcional) |
| Lv4 | Empresarial / deep-tech / regulado | W0–W6 completa + W4 |
Diecisiete especialistas, un líder
El líder es tu sesión principal y nunca se despliega. Los especialistas se despliegan por ola, con la concurrencia limitada a tres.
00PaulLíder / confirmación finalall
01JohnEspecialista en ingeniería inversaW1
02CalebAnálisis de mercado / USPW1
03JoshuaPlanificación de servicioW2
04JamesArquitecto de SW / nubeW2
05MarkEspecialista en PI (patentes)W4
06NathanaelRedactor de investigaciónW4
07JonnathanDiseñador jefe (UX/UI)W2
08PhillipLíder de backend y datosW5
09AndrewLíder de frontend y móvilW5
10StephenLíder de IA / MLW5
11TimothyDocumentación de definición de desarrolloW6
12ThomasRevisor de códigoW6
13MichaelEspecialista en seguridadW6
14HananiahEspecialista en refactorizaciónW6
15MatthiasQA / validaciónW6
16MartinMonitorización / informeW6
17MatthewScrum master / ingeniero de historiasW3
Compuertas que de verdad cierran el paso
Cada compuerta de ola habla un solo vocabulario, y la crítica se hace cumplir en el código, sin aprobación automática sin evidencia.
PASS
Criterios cumplidos, sin bloqueantes
Avanzar a la siguiente ola
CONCERNS
Aprobación condicional, riesgo no bloqueante
Registrar el riesgo y luego avanzar
FAIL
Defecto bloqueante
Entrada bloqueada; subsanar y volver a la compuerta
A prueba de manipulación por diseño
Cada cambio de estado se escribe en una cadena hash de auditoría con clave (HMAC-SHA256). Un solo comando (bathos audit verify) demuestra que el rastro no ha sido alterado.
Construye como un ingeniero bien formado, no como una demo
A su aire, una IA responde a cualquier tarea con código nuevo: una abstracción nueva, una dependencia nueva, un fichero más. Los implementadores de la Ola 5 llevan en su lugar una disciplina explícita: antes de escribir nada suben una escalera de siete peldaños y se detienen en el primer peldaño que aguanta. Perezosos con la solución, nunca con la lectura.
¿Esto necesita existir?
Lo que solo hace falta por especulación se omite, y se dice en voz alta en una línea. YAGNI.
¿Ya está en este código?
Un helper, un tipo o un patrón que ya vive aquí se reutiliza. Reimplementar lo que está a unos pocos ficheros de distancia es la chapuza más común.
¿Lo hace la biblioteca estándar?
Entonces lo hace la biblioteca estándar.
¿Es nativo de la plataforma?
Un input de fecha antes que una librería de selector, CSS antes que JS, una restricción de la DB antes que código de aplicación.
¿Lo cubre una dependencia ya instalada?
Úsala. Nunca añadas una dependencia nueva para lo que resuelven unas pocas líneas.
¿Puede ser una sola línea?
Entonces es una sola línea.
Solo entonces: el mínimo que funciona.
Gana el diff más corto que funcione, pero solo cuando ya entiendes de verdad qué tiene que tocar el cambio.
Nunca se simplifica
- La validación de entradas en los límites de confianza
- El manejo de errores que evita la pérdida de datos
- Las medidas de seguridad
- Lo básico de accesibilidad
- Cualquier cosa que se haya pedido explícitamente
- Entender el problema: la escalera acorta la solución, nunca la lectura
La escalera gobierna qué se construye. Con cuánta integridad se construye el alcance ya fijado es otro eje, y ese le pertenece a Boil the Ocean. Ninguno se cambia nunca por el otro.
// ponytail: single global lock, split per-wave
// if profiling shows contention
# ponytail: fixed backoff, go exponential once
# the API starts rate-limiting
$ /bathos-debt # CONCERNS: docs + ponytail: src
→ 2 open · 1 no-triggerCada atajo deliberado deja en el código su techo y su disparador de mejora, y /bathos-debt los recopila, señalando los que no nombran ningún disparador, porque son los que se pudren en silencio.
Un solo interruptor decide cuánto aprieta: /bathos intensity lite · full · ultra · off.
Principios de ingeniería adaptados de ponytail, de Dietrich Gebert (MIT). No se adoptan ni la persona ni la marca: BATHOS es un producto de orquestación, no un personaje.
Un núcleo determinista, no intuiciones
Los invariantes críticos — estado, compuertas, enrutamiento, frescura de las historias — viven en un único binario estático en Rust, de modo que se calculan y se hacen cumplir de la misma manera cada vez.
- Único binario estático
- Un ejecutable bathos compacto, sin dependencias de runtime.
- SSOT validado por esquema
- manifest.json es la fuente de verdad, validado por esquema, con escrituras atómicas.
- Auditoría a prueba de manipulación
- Una cadena hash HMAC con clave y una verificación de un solo comando.
- Probado
- 510 pruebas de Rust + 86 comprobaciones de determinismo de hooks, todas en verde; clippy limpio.
$ echo '{"scope":"feature","novelty":true}' \
| bathos --state-dir _state route decide
→ {"recommended_level":2,"requires_confirmation":true}Recomienda un nivel a partir del riesgo: el motor propone, tú confirmas.
Un informe por cada sesión
Cada sesión de trabajo termina con un informe HTML autónomo, escrito automáticamente al cerrar la sesión o a demanda con /taskreport. Se arma solo con hechos del disco y de git; no se inventa nada.
- Generación automática
- Un hook SessionEnd escribe el informe al salir; /taskreport produce el mismo archivo a demanda, a mitad de sesión.
- Seis secciones fijas
- Inicio, fin y duración total; el trabajo clave de la sesión; las incidencias relevantes; y todo el historial de git commit / push / PR / merge.
- Hechos, no invención
- La narrativa viene del estado de la sesión y el rastro de git del repositorio. Lo que no está registrado se marca como «(no registrado)».
- Autónomo y numerado
- Un único archivo HTML sin recursos externos, nombrado por marca de tiempo y un número de sesión autoincremental.
result_report/
├─ task_report_20260716_104150_session_no12.html
└─ … # one file per session, auto-numbered
# on /exit → SessionEnd hook · or run /taskreportUn informe por sesión, numerado en orden: el rastro documental de toda la construcción.
Elige por rol y míralo en vivo
Asigna un modelo y un runtime a cada rol antes de una oleada y luego sigue la ejecución en un panel en vivo, sin quitarle nunca el teclado al líder.
- Plan de modelos por rol
- bathos model set / show / validate registra la asignación rol → runtime/modelo en model-plan.json, la fuente de verdad que cada oleada resuelve. Sin plan, cada rol recae en su propio valor por defecto, así que un proyecto que nunca lo toca queda igual.
- Seis runtimes, un plan
- Asigna Claude, Codex, GLM, Kimi, DeepSeek o Qwen entre roles; un guardián de lote mixto bloquea las combinaciones incompatibles antes de generar a nadie.
- Paneles de oleada en vivo
- bathos panes abre un panel tmux o TUI integrado de solo lectura sobre los mismos datos de inspect: control, estado y una bandeja de entrada, lado a lado.
- Propuestas, no anulaciones
- El confirm y el feedback del panel llegan como archivos a una bandeja de entrada; la puerta final sigue siendo del líder. La Soberanía del Usuario se mantiene.
$ bathos model set james --runtime claude --model opus
$ bathos model set phillip --runtime codex
$ bathos model validate --wave W5 # mixed-batch guard
→ PASS
$ bathos panes --mode tui --wave W5 # live · read-onlyAsigna modelos antes de la oleada y luego mira cómo se ejecuta: solo lectura, con una bandeja de entrada para tus propuestas.
Aporta profundidad a tu propia construcción.
Lee el código fuente o explora más en la web.