Agentes de IA corren tu proceso de desarrollo. Vos decidís qué se mergea.
Cada etapa de tu tablero tiene su agente. Un auditor que prendés puede revisar el trabajo antes de avanzar, un agente de QA te entrega el video de cada prueba y, por default, ningún agente puede mergear.
Gratis, sin límite de workspaces. Corre en tus servidores y habla con el modelo con tu propia key.
- El agente arrancó en su rama y su sandbox
- El agente terminó y subió la rama
- El auditor revisa contra la definición de terminado
- Auditor: aprobó, 3 de 3 criterios cumplidos
- El agente de QA graba la prueba
- PR #128 listo, checks en verde. Lo mergea una persona
Cómo funciona
Una tarea, del tablero vacío al merge
Armás el tablero con tus etapas.
Un tablero nuevo arranca con Backlog, In progress y Done. Lo convertís en Backlog, Desarrollo, QA, Review humano y Done, o en lo que use tu equipo. Decidís cuáles tienen agente, cuáles avanzan solas y cuáles esperan la aprobación de una persona.
Le asignás un agente a cada etapa.
Los agentes los escribís vos o los importás; no viene ninguno instalado. Cada agente tiene su prompt, su modelo, sus herramientas y sus permisos en cada etapa. El de desarrollo puede hacer push en Desarrollo; el de QA abre un browser en QA.
Creás la tarea y el agente trabaja.
Trabaja en su propia rama y su propio sandbox, donde levanta tu app con el script de arranque del proyecto. Su key dura 24 horas como máximo, muere cuando termina el run y sólo puede cambiar su propia tarea.
El auditor la devuelve si falta algo.
Si lo prendiste para esa etapa, un auditor revisa el resultado contra tu definición de terminado, en su propio contenedor y con el repo montado en sólo lectura. La tarea vuelve con el motivo y el siguiente run sigue desde ahí.
Recibís el video de cada prueba.
El agente de QA prueba la app en un navegador real, graba cada caso y registra si pasa o falla. Ves dónde hizo clic y qué estaba comprobando.
Una persona aprueba y mergea.
La tarea te muestra el PR con su CI y su review. Una persona de tu equipo revisa y mergea. Los agentes pueden pedir aprobaciones pero nunca darlas, y mergear es una herramienta que ningún permiso de escritura incluye: un admin tiene que nombrarla en la etapa.
Dibujos con datos inventados. Las capturas de más abajo son el dashboard real.
Probalo con dos comandos
curl -fsSL https://github.com/MisterDonnuts/thulu/releases/latest/download/install.sh | sh
thulu initNecesitás Docker con Compose. El asistente pregunta lo que tiene que saber y la página Setup te muestra lo que falta: agentes, una credencial de GitHub, una key del modelo y tu primer proyecto.
Pipeline gobernado
Tu proceso, con agentes que lo respetan
Tu equipo ya tiene reglas: qué se revisa, quién aprueba, qué no se mergea sin pruebas. En Thulu esas reglas son parte del tablero.
- Etapas a tu medida. Hasta 32 por tablero y 64 tableros por workspace. Tipos de tarea que saltean etapas, como un hotfix que no pasa por refinamiento.
- Un auditor en las etapas que elegís. Lo prendés por agente y etapa; ninguno viene prendido. Corre en su propio container, con el repo en sólo lectura. Aprueba, devuelve la tarea a otra etapa, la bloquea o pide más turnos.
- Gates de aprobación. Una etapa puede exigir que una persona apruebe antes de que la tarea salga, y un agente que detecta una decisión de arquitectura o un impacto en infraestructura puede pedir una aprobación. La tarea no avanza hasta que una persona apruebe. Los agentes piden aprobaciones pero nunca las dan. Si pedís cambios, el agente retoma el trabajo.
- El PR adentro de la tarea. Cada PR muestra cuántos checks de CI pasaron, el estado del review, si está listo para mergear y por qué está bloqueado, sin abrir GitHub (el conteo completo usa el permiso Checks de la GitHub App).
- Los agentes preguntan en vez de adivinar. Cuando un agente necesita algo que sólo sabe una persona, pregunta en la tarea y espera. Cuando contestás, el run sigue donde quedó.
Ver 6 más
- Hablás con el agente mientras trabaja. Le escribís en la tarea o lo arrobás en un hilo, y contesta ahí mismo (con Claude Code en Docker; en Kubernetes, o con Codex y OpenCode, el mensaje espera a que termine la corrida).
- El agente atiende el review. Responde y resuelve los hilos de review, pide reviewers, maneja labels y lee los checks del PR (con el mismo permiso Checks; sin él, sólo los jobs de Actions). Cerrar un PR no puede.
- Un chat que trabaja por vos. Con "Actuar por mí", un chat sin tarea crea, edita y mueve tareas en todos tus tableros durante 8 horas, y con la GitHub App abre PRs en tus repos. Lo que borra, un merge o la aprobación de un deploy esperan tu confirmación. Un owner lo puede apagar para todo el workspace.
- Dependencias. Una tarea no arranca hasta que la que la bloquea llegue a una etapa terminal, como Done.
- Subtareas y tablero con teclado. Las subtareas tienen su orden y pueden esperar a una hermana. El tablero se maneja entero con el teclado: flechas, Space levanta y suelta la tarjeta, M la mueve, P cambia la prioridad. Modo claro y oscuro.
- Automatizaciones. Tareas que se crean solas por cron, por un evento de GitHub o cuando una métrica cruza un umbral.
QA con video
Cada prueba llega con su video
El agente de QA levanta tu app en el sandbox de la tarea, la prueba en un browser real y graba lo que hace. No tenés que creerle a un "lo probé".
- Video con cursor y subtítulos. Ves dónde hizo clic y qué estaba probando. Se recortan los tiempos muertos.
- Pasa o falla, medido. Cada caso tiene su check, que la herramienta mide y vuelve a medir cada vez que se reproduce la prueba.
- Antes y después. La misma prueba contra la versión anterior y contra la nueva, lado a lado.
- La app arriba en cada tarea. Cada proyecto tiene un script de arranque con sus parámetros, puertos y chequeo de "listo". El agente lo corre cuando lo necesita; si tu app cambió y el script falla, lo corrige y la revisión queda en la auditoría con el agente como autor.
- Casos de prueba con historia. TC-1, TC-2: cada uno con sus pasos, el resultado esperado y cada corrida con su veredicto y su video.
Ver 4 más
- Pruebas que se repiten. La toma se guarda en tu repo como JSON y se vuelve a correr en otra tarea.
- Capturas anotadas. Con los pasos numerados y los datos sensibles tachados.
- Todo en una vista. La pestaña "Desde tareas" de Evidencia junta los casos de todo el workspace, con filtros por estado, tablero y proyecto.
- Sin reinstalar todo en cada tarea. Cada workspace guarda las cachés de npm, Go y pip y los toolchains en un volumen propio. Con la fase setup del script de arranque del proyecto, Thulu precalienta las dependencias de la rama principal y la tarea las restaura en vez de instalarlas; si tu rama cambió el lock file, instala sólo lo que falta.
Seguridad y control
Corre en tus servidores y habla con el modelo con tu propia key
Tu infraestructura
- Thulu
- Postgres
- Containers de agentes
- Proveedor de LLM, con tu key
- GitHub
- Tu key del modelo. Claude por Anthropic, Bedrock o Vertex. El código que lee el agente va al proveedor que elegiste, con tu key. Nosotros no vemos tus tokens ni los revendemos.
- La key no entra al agente. Un gateway dentro de Thulu le da a cada run un token propio y lo revoca al terminar. Un token OAuth de Claude Pro/Max no pasa por el gateway.
- Una key por run. Cada container recibe una key que dura 24 horas como máximo, se revoca al terminar y sólo puede cambiar su propia tarea.
- Por default ningún agente mergea. Mergear es una herramienta que ningún permiso de escritura incluye: un admin la tiene que nombrar en la etapa.
- Audit log con cadena de hashes. 62 tipos de evento, cada uno encadenado al anterior, con verificación por API y copia a stdout, stderr o un archivo NDJSON.
Ver 6 más
- Tu token de GitHub no entra al agente. Thulu publica la rama en GitHub con un token acotado al repo. En Docker, commit y push los hace Thulu; en Kubernetes el agente usa git normal en su copia (commit, rebase, push) y el push pasa por Thulu, que nunca descarta un commit.
- SSO de tu IdP. Okta, Entra ID, Google, Keycloak o cualquier IdP OIDC, o GitHub. Thulu no guarda contraseñas.
- Tu equipo entra por invitación. Cargás el email y el rol, y compartís el link: Thulu no manda el mail. La persona entra con ese rol la primera vez que inicia sesión, y la invitación ocupa un asiento.
- Aislación fuerte en Kubernetes. Namespace por equipo, NetworkPolicy deny-by-default y Kata o gVisor obligatorios. Validado en un solo nodo; pide una licencia paga (Team o Enterprise).
- Binarios firmados. El instalador verifica el SHA-256 y, si tenés cosign, la firma.
- Hoy self-hosted; nube gestionada: beta cerrada, sólo con invitación. Self-hosted con Docker Compose o Kubernetes. Cómo es la beta de la nube.
Métricas y costo
Cuánto costó cada tarea y dónde se trabó
- Costo por tarea. Costo y tokens por agente, modelo, proyecto, tool y skill, y las 20 tareas que más costaron.
- Métricas de flujo. Lead time, tiempo por etapa, rework, tareas devueltas por el auditor, first-pass rate y costo por tarea terminada.
- Métricas de tu app. Mandá las tuyas por OTLP; entran a un gráfico cuando un admin las aprueba.
- Prometheus.
/metricscon las métricas del daemon para tu monitoreo.
Precios
En tus servidores (self-hosted)
Precios en USD. Team se paga por mes, o por año con dos meses gratis ($3.990/año hasta 10 personas). Enterprise es un contrato anual, por factura o transferencia.
| Free | Team | Enterprise | |
|---|---|---|---|
| Precio | Gratis | $399/mes hasta 10 personas, más $20/mes por cada persona desde la 11ª | $15.000/año hasta 25 personas, más $30/mes por cada persona desde la 26ª |
| Equipo | Hasta 4 personas | Desde la 5ª persona | Cualquier tamaño |
| Tablero, etapas, agentes, auditor y QA con video | Sí | Sí | Sí |
| Sandbox Docker | Sí | Sí | Sí |
| Audit log en la UI y SSO por OIDC o GitHub | Sí | Sí | Sí |
| Varios workspaces | Sí | Sí | Sí |
| Export del audit log (CSV/NDJSON) | No incluido | Sí | Sí |
| Runtime Kubernetes (Kata/gVisor, namespace por equipo) | No incluido | Sí | Sí |
| Soporte | Documentación y GitHub | Email, horario laboral | SLA por contrato y contacto nombrado |
| Versiones soportadas por contrato | No incluido | No incluido | Sí |
Free
- Precio
- Gratis
- Equipo
- Hasta 4 personas
- Tablero, etapas, agentes, auditor y QA con video
- Sí
- Sandbox Docker
- Sí
- Audit log en la UI y SSO por OIDC o GitHub
- Sí
- Varios workspaces
- Sí
- Export del audit log (CSV/NDJSON)
- No incluido
- Runtime Kubernetes (Kata/gVisor, namespace por equipo)
- No incluido
- Soporte
- Documentación y GitHub
- Versiones soportadas por contrato
- No incluido
Team
- Precio
- $399/mes hasta 10 personas, más $20/mes por cada persona desde la 11ª
- Equipo
- Desde la 5ª persona
- Tablero, etapas, agentes, auditor y QA con video
- Sí
- Sandbox Docker
- Sí
- Audit log en la UI y SSO por OIDC o GitHub
- Sí
- Varios workspaces
- Sí
- Export del audit log (CSV/NDJSON)
- Sí
- Runtime Kubernetes (Kata/gVisor, namespace por equipo)
- Sí
- Soporte
- Email, horario laboral
- Versiones soportadas por contrato
- No incluido
Enterprise
- Precio
- $15.000/año hasta 25 personas, más $30/mes por cada persona desde la 26ª
- Equipo
- Cualquier tamaño
- Tablero, etapas, agentes, auditor y QA con video
- Sí
- Sandbox Docker
- Sí
- Audit log en la UI y SSO por OIDC o GitHub
- Sí
- Varios workspaces
- Sí
- Export del audit log (CSV/NDJSON)
- Sí
- Runtime Kubernetes (Kata/gVisor, namespace por equipo)
- Sí
- Soporte
- SLA por contrato y contacto nombrado
- Versiones soportadas por contrato
- Sí
Thulu no controla los tamaños de equipo. Lo único que pide una clave de licencia es lo que está en ee/.
Para comprar Team o Enterprise, abrí una pregunta en GitHub.
Nube gestionada (SaaS)
Por seat, con tu key del modelo. La nube gestionada es una beta cerrada, sólo con invitación.
| Free | Team | Business | Enterprise | |
|---|---|---|---|---|
| Precio | $0 | $39/seat/mes ($32 anual) | $79/seat/mes ($65 anual) | A medida |
| Seats | Hasta 4 | Hasta 20 | Ilimitados | Ilimitados |
| Agentes a la vez | 1 | 5 | 15 | Pool dedicado |
| Runs por mes | 100 | 1.000 | 5.000 | A medida |
| Varios workspaces y export del audit | No incluido | No incluido | Sí | Sí |
| Contrato y DPA | No incluido | No incluido | No incluido | Sí |
Free
- Precio
- $0
- Seats
- Hasta 4
- Agentes a la vez
- 1
- Runs por mes
- 100
- Varios workspaces y export del audit
- No incluido
- Contrato y DPA
- No incluido
Team
- Precio
- $39/seat/mes ($32 anual)
- Seats
- Hasta 20
- Agentes a la vez
- 5
- Runs por mes
- 1.000
- Varios workspaces y export del audit
- No incluido
- Contrato y DPA
- No incluido
Business
- Precio
- $79/seat/mes ($65 anual)
- Seats
- Ilimitados
- Agentes a la vez
- 15
- Runs por mes
- 5.000
- Varios workspaces y export del audit
- Sí
- Contrato y DPA
- No incluido
Enterprise
- Precio
- A medida
- Seats
- Ilimitados
- Agentes a la vez
- Pool dedicado
- Runs por mes
- A medida
- Varios workspaces y export del audit
- Sí
- Contrato y DPA
- Sí
El consumo del modelo lo pagás vos directo a tu proveedor. Thulu te muestra cuánto se fue en cada tarea.
¿Querés que lo instalemos nosotros? Implementación de $3.000 a $6.000: instalación, etapas y agentes para tu stack, GitHub conectado y los primeros flujos de QA. O un piloto de 60 días por $2.500, que se descuenta si firmás el año. Preguntanos en GitHub.
Preguntas frecuentes
¿Qué modelos usa?
Claude a través de Claude Code, el motor principal: Sonnet, Opus y Haiku, con la API de Anthropic, con Bedrock, con Vertex o detrás de un proxy propio como LiteLLM. Codex usa los modelos de OpenAI con tu clave de OpenAI, y OpenCode llega a APIs compatibles con OpenAI como DeepSeek. Cada agente elige su motor y su modelo, y su auditor puede usar otros.
¿Dónde corre?
En tus servidores, con Docker Compose o con Kubernetes. Hoy self-hosted; nube gestionada: beta cerrada, sólo con invitación. En self-hosted necesitás Postgres; el instalador te lo arma con Docker Compose si no tenés uno.
¿Qué pasa con mi código?
Si Thulu corre en tus servidores, el repo se clona ahí y cada tarea trabaja en su propio worktree. El código que el agente lee va al proveedor de LLM que elegiste, con tu key, igual que cuando un desarrollador usa un agente de código. A Mister.D no le llega.
¿Cuánto cuesta el modelo?
Lo pagás vos directo a tu proveedor, según lo que consumen tus agentes. La página de usage te muestra el costo de cada tarea, agente y modelo desde el primer día.
¿Necesito Kubernetes?
No. Con Docker Compose alcanza para empezar. Kubernetes con Kata o gVisor suma aislación fuerte por equipo y control del tráfico de salida; pide una licencia paga (Team o Enterprise) y está validado en un solo nodo. En Kubernetes, una corrida que no entra en la cuota del workspace espera en fila y arranca sola cuando se libera lugar.
¿Funciona con GitLab o Bitbucket?
No. De los proveedores de Git, sólo GitHub, incluido GitHub Enterprise Server para el login. Se conecta con una GitHub App que da tokens acotados a cada repo. También podés crear un proyecto subiendo una carpeta o un .zip (hasta 200 MiB comprimido): Thulu aloja el repo, los agentes trabajan sobre él igual que sobre un clon de GitHub, y la rama de la tarea se integra con "Integrar en", sin PR, dentro del repo que aloja Thulu.
¿Qué no hace?
No es un enjambre: cada tarea tiene un agente por etapa, más el auditor. No hay GitLab ni Bitbucket. Evidencia cubre aplicaciones web en Chromium, también en tamaño de teléfono, no apps móviles nativas. No hay integración nativa con Slack o Jira, sólo webhooks salientes y automatizaciones con pasos HTTP. No tiene certificación SOC 2 ni ISO. Y no publicamos una cifra de costo del modelo ni de cuánto más rápido vas a entregar: las dos cosas las medís en tus propias tareas.
¿Qué agentes trae?
Ninguno viene instalado: tu equipo define sus agentes (prompts por etapa, skills y herramientas) para tu stack, o los importa con un comando. Desde el Workshop, un admin instala agentes y skills de un catálogo y ve el plan antes de aplicarlo, y exporta un agente como JSON para importarlo en otro workspace. Hoy ese catálogo trae dos agentes y una skill de ejemplo. Lo que sí viene con Thulu son skills del sistema que le enseñan a cualquier agente a trabajar adentro de Thulu: cómo es un run, cómo preguntarle a una persona o pedir una aprobación, cómo escribir casos de prueba y grabar evidencia en el browser.
¿Un agente puede mergear?
Por default no. Mergear es una herramienta (pr_merge) que ningún permiso de escritura incluye: un admin la tiene que nombrar en la etapa donde la quiere. En un chat, el merge queda esperando a que lo confirmes vos.
¿Está en castellano?
Sí. El dashboard, la API, el CLI y los mensajes que Thulu escribe en las tareas están en castellano y en inglés. Cada persona elige el idioma del dashboard en Settings.
¿Cómo se instala?
curl -fsSL https://github.com/MisterDonnuts/thulu/releases/latest/download/install.sh | sh
thulu initEl wizard te pregunta si vas con Docker Compose o Helm (el runtime Kubernetes pide una licencia paga), tu IdP, la base y qué herramientas instalar. Después, la página Setup te marca qué falta: agentes, credencial de GitHub, key del modelo y el primer proyecto. La guía de instalación tiene cada paso.
¿Es open source?
Sí. El núcleo es open source (AGPL-3.0). Con él corrés Thulu en Docker gratis, con todos los workspaces que quieras. Lo que se cobra pide una clave de licencia: export del audit, runtime Kubernetes y billing de Stripe para un servicio alojado. Los tres están en la carpeta ee/, con el código a la vista y la Thulu Enterprise License. Usar Thulu no te obliga a publicar tu código; la AGPL alcanza a los cambios que le hagas a Thulu si lo ofrecés como servicio. El código está en GitHub.
¿Qué soporte tengo?
El plan Free tiene la documentación y soporte en GitHub. Team incluye soporte por email en horario laboral; Enterprise, SLA por contrato y un contacto nombrado. Toda licencia paga incluye actualizaciones y parches de seguridad mientras esté activa.
Probalo con una tarea tuya
Instalá Thulu gratis y armá tu primer tablero, o pedinos en GitHub un piloto de 60 días con un repo de tu equipo.