Preguntas frecuentes

¿Puedo usar Takuto libremente?

Sí. Autoalojar Takuto Core para tu propio uso — en tu máquina o dentro de tu empresa — es gratis: sin pagos al proyecto, sin límites de asientos, sin topes de uso que te imponga. El motor es AGPL-3.0 y la Takuto CLI es MIT, así que eres libre de ejecutarlo, modificarlo y desplegarlo en tu propia infraestructura. No hay telemetría y nada hace phone-home.

La única obligación de la AGPL que conviene conocer: si ofreces Takuto Core como un servicio a terceros (un producto alojado), tienes que publicar como open source todo tu stack correspondiente. Ejecutarlo internamente para tu propio equipo no activa eso. Si esos términos no encajan con tus necesidades, ponte en contacto.

¿Cuánto cuesta ejecutarlo?

Takuto Core en sí no te factura — lo hace tu proveedor de IA. El agente ejecuta Claude Code, Cursor Agent, Codex o un modelo autoalojado contra tu cuenta, y cada ticket consume tokens en proporción al tamaño del código, al contexto del prompt y al número de pasos de tu workflow.

Lo que cuesta depende por completo del proveedor y el modelo que elijas — consulta sus tarifas actuales y vigila tus primeras ejecuciones para hacerte una idea de tu propia carga.

Palancas para ahorrar costes:

  • Usa pasos de comando para el trabajo determinista (lint, test) — no consumen tokens de IA.
  • Limita el contexto con [jira] ticket_context_max_description_bytes.
  • Ensaya con [general] dry_mode = true antes de apuntar a un backlog real.
  • Un modelo autoalojado vía OpenCode elimina por completo la facturación por token (solo pagas el hardware) — consulta Modelos autoalojados.

¿Está listo para producción?

Takuto Core está en beta. Es usable hoy, y hay gente ejecutando workflows reales con él — pero espera asperezas, y todo el feedback es bienvenido. El estado de beta es también la razón de que el mensaje en todo este sitio se incline hacia “pruébalo, dinos qué se rompe” en lugar de “listo para empresa”. Cada reporte ayuda a dar forma al rumbo del proyecto.

¿Puedo contribuir? ¿Por qué no se aceptan pull requests?

Takuto Core es open source, pero el autor no acepta pull requests por ahora. Es una postura deliberada y temporal por motivos legales: el proyecto necesita tiempo para ser observado y estructurado como es debido — el licenciamiento de contribuidores, la gobernanza y las marcas tienen que estar en su sitio antes de que el código externo pueda mergearse de forma responsable.

Eso no significa que el feedback no sea bienvenido — al contrario. Los reportes de bugs, las peticiones de funcionalidades y el feedback general se desean mucho. Abre un issue o escribe a morphet.contact@gmail.com. La restricción es específicamente sobre mergear código externo, no sobre la conversación en torno al proyecto.

¿Cuáles son las licencias?

Dos componentes, dos licencias:

  • Takuto Core (el motor que autoalojas) está licenciado bajo AGPL-3.0. Autoalojarlo es gratis. Si ofreces Takuto Core como un servicio a terceros, la AGPL te obliga a publicar como open source todo tu stack. Si esos términos no encajan con tus necesidades, escribe a morphet.contact@gmail.com — encantado de hablarlo.
  • La Takuto CLI (la herramienta complementaria de setup) está licenciada bajo MIT.

El código fuente de Takuto Core está en https://github.com/takuto-team/takuto-core; la CLI está en https://github.com/takuto-team/takuto-cli.

¿Recopiláis algún dato o telemetría?

No. Takuto Core no recopila ni transmite ninguna telemetría — sin analíticas de uso, sin reporte de crashes, sin phone-home. Puedes verificarlo tú mismo en el código fuente.

Todo el tráfico saliente pasa por una allowlist: tu sitio de Jira/Atlassian y GitHub, los hosts de la API de los proveedores de IA que actives (Claude, Codex/OpenAI y Cursor quedan habilitados de fábrica; OpenCode es autoalojado, así que en su lugar se habilita su base_url), los registros de paquetes (npm — más los de tu .npmrc — crates.io, nodejs.org), un puñado de sitios de documentación para desarrolladores (Rust docs, MDN, Stack Overflow) y AWS STS/SSO para ejecuciones autenticadas con AWS. Los hosts de los proveedores siguen a [agent].available_providers — recórtalo para estrechar el firewall — y puedes añadir tus propios hosts con [network] extra_egress_hosts. Un egress firewall (configurado al arrancar el container) bloquea todo lo demás por defecto. El contenido de tus tickets, tu código fuente y tus prompts se envían solo al proveedor de IA que elegiste — Takuto Core en sí nunca los ve. Y como corre localmente o en tu propio servidor, puedes ejecutarlo totalmente autoalojado (o incluso apuntarlo a un modelo autoalojado) para que nada salga de tu infraestructura en absoluto.

¿Cómo se aísla? ¿Es seguro ejecutar agentes de forma autónoma?

El aislamiento es un objetivo de diseño central:

  • Cada agente corre en su propio container, así que el radio de impacto de un ataque de prompt injection se limita a ese container.
  • La allowlist del egress firewall restringe lo que cualquier agente puede alcanzar por la red.
  • La protección de ramas es obligatoria — los agentes empujan ramas y abren PRs, nunca hacen commit a main. Combinado con tokens acotados (un PAT de GitHub de grano fino, una cuenta de servicio limitada en Jira), esto acota lo que una sesión secuestrada puede hacer realmente.

Takuto Core añade un encuadre explícito de contenido no confiable en torno al texto de los tickets y topes de bytes opcionales, lo que reduce el riesgo de prompt injection pero no lo elimina — la revisión humana de código en los PRs sigue siendo tu red de seguridad.

¿Qué agentes de IA son compatibles?

  • Claude Code
  • Cursor Agent
  • Codex
  • OpenCode (solo para modelos autoalojados)

Eliges el proveedor en Configuración → AI Settings; cada uno tiene sus propios ajustes [agent.providers.<name>]. Consulta la referencia de configuración.

¿Qué hardware necesito?

Estas cifras son estimaciones aproximadas, no requisitos estrictos — tus necesidades reales dependen del proyecto, de tu proveedor y de tu concurrencia. Como referencia, el autor desarrolla y ejecuta Takuto Core en un Apple M1 Pro con 16 GiB de RAM.

  • RAM: ≥ 8 GiB para un solo workflow; ≥ 12 GiB en macOS con Podman (la VM necesita su propia parte). Escala con [general] max_concurrent_workflows.
  • Disco: ≥ 30 GiB libres — los worktrees, las cachés de npm/cargo, los toolchains de mise y la capa opcional de Docker-in-Docker viven todos en volúmenes de Docker.
  • SO: se recomienda un host Linux para despliegues en servidor; macOS funciona bien para uso local.
  • Los modelos autoalojados necesitan considerablemente más — dimensiona la GPU/VRAM al modelo que pretendas servir.

¿A dónde voy ahora?