Instalar

Control Center se ejecuta de dos maneras: como aplicación web en app.usectrl.dev, sin nada que descargar, o como aplicación de escritorio que instalas. Son la misma aplicación con las mismas funciones. La única diferencia es dónde se ejecuta el servidor, y la aplicación web no puede ejecutar uno por ti.

Úsalo en tu navegador

app.usectrl.dev es esta aplicación compilada para el navegador. Nada que instalar, nada que actualizar. Ábrela y conéctate.

Lo que una pestaña del navegador no puede hacer es ser el servidor. Cada cliente —escritorio, web, teléfono— es un renderizador ligero sobre un cc_server headless que posee la base de datos y hace el trabajo, así que la aplicación web siempre habla con un servidor que ejecutas tú. Hay dos maneras de darle uno:

Un servidor en tu propia máquina. Inicia cc_server de forma local y apunta la aplicación web a ws://localhost:9030. Los navegadores consideran localhost de confianza, así que esto no necesita certificado ni túnel. Es la forma más rápida de probar la aplicación web y tus datos nunca salen de tu máquina.

Un servidor en otra máquina. Como app.usectrl.dev se sirve por HTTPS, un servidor que no sea local tiene que ser accesible por wss:// con un certificado en el que el navegador ya confíe. cc_server se niega a enlazar una dirección que no sea de loopback sin TLS, así que elige una de estas opciones:

dale un certificado directamente, con --tls-cert y --tls-key
ponlo detrás de un proxy inverso que termine TLS e inícialo con --insecure
expónlo a través de un túnel o una VPN que aporte el certificado — Tailscale, cloudflared o similar. Ajustes → Servidor → Conexión y estado tiene la opción integrada de túnel dentro de Compartir este servidor.

Siempre que el servidor esté detrás de un proxy, NAT o túnel, define --public-url con la dirección a la que los clientes deben marcar de verdad. Su valor predeterminado es el enlace local, así que sin él los clientes intentarán el host equivocado.

Algunas cosas siguen siendo exclusivas del escritorio, porque necesitan una ventana nativa o los propios dispositivos de audio de la máquina: la píldora flotante del modo enfoque, los avisos de notificación del sistema operativo (el centro de notificaciones de la aplicación funciona en todas partes), «Grabar y vincular» desde un evento del calendario y volver a ejecutar el resumen de una reunión. Todo lo demás —espacios, agentes, revisión de pull requests, pipelines, tickets, memoria y la propia grabación de reuniones— se comporta igual.

Para conectar la aplicación web a un servidor, sigue Conéctate a un servidor remoto. Para alojar el servidor, sigue Ejecutar un servidor headless.

Requisitos del sistema del escritorio

Requisito	macOS	Windows	Linux
Versión del sistema operativo	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ u otra distribución con glibc 2.35+ y GTK 3
Arquitectura	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Necesario	Necesario	Necesario
Espacio en disco	~200 MB para la aplicación, más el directorio de datos del servidor	~200 MB	~200 MB

Los Mac con Intel no tienen descarga precompilada. En su lugar, compila desde el código fuente.

El directorio de datos del servidor acaba siendo mucho más grande que la aplicación. En su primer arranque, cc_server instala a la fuerza los modelos en el dispositivo —embeddings de texto (~90 MB), diarización de hablantes (~35 MB) y el modelo de voz seleccionado (Parakeet TDT v3 de forma predeterminada, ~600 MB; las variantes de Whisper, 198–626 MB)—, además de una compilación integrada de code-server, y cada conversación de agente recibe un worktree copy-on-write de los repos en los que trabaja (git worktree normal en Windows). La voz no es opcional: sin el modelo ASR, las operaciones de reunión y dictado no se sirven. La primera descarga del modelo de voz todavía necesita un reinicio para que la grabación se active.

El escritorio apunta su servidor al directorio de soporte de aplicaciones por usuario del sistema operativo. Un cc_server iniciado a mano sin --data-dir usa de forma predeterminada <application data>/control-center: ~/Library/Application Support/control-center en macOS, %APPDATA%\control-center en Windows, $XDG_DATA_HOME/control-center (o ~/.local/share/control-center) en Linux.

Descarga

Todos los artefactos de abajo proceden de GitHub Releases.

macOS (Apple Silicon)

Descarga Control-Center-<version>-arm64.dmg, ábrelo y arrastra Control Center a Aplicaciones. La compilación está firmada con un Developer ID y notarizada por Apple, así que se abre con normalidad.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: un instalador por usuario.
Control-Center-<version>-windows-x64.zip: un zip portable.
Control-Center-<version>-arm64-setup.exe: un instalador por usuario.
Control-Center-<version>-windows-arm64.zip: un zip portable.

Windows usa git worktree para los checkouts de los espacios (sin copy-on-write).

Linux (x86_64)

Control-Center-<version>-x86_64.AppImage
Control-Center-<version>-linux-x64.tar.gz

El AppImage lleva información de actualización, así que AppImageUpdate o appimaged pueden llevarlo a la última versión en su lugar, descargando solo lo que cambió.

Ambos se compilan en Ubuntu 22.04 y se ejecutan en esa versión o en cualquiera más reciente (Debian 12, Fedora 36 y posteriores): enlazan glibc 2.35 y la libstdc++ de GCC 12, y toman GTK 3 del sistema. Las pocas bibliotecas que le pueden faltar a un escritorio estándar viajan dentro de ellos, así que no hay que instalar nada más. El sonido —reproducción de reuniones, el paisaje sonoro, el audio de los rigs y los avisos sonoros de notificación— se reproduce a través del libmpv del sistema (libmpv1 en Ubuntu 22.04, libmpv2 en Ubuntu y Debian más recientes, mpv-libs en Fedora); sin él, la aplicación arranca con esos controles ocultos.

Servidor independiente

Cada versión también incluye el servidor headless por separado — cc_server-<version>-macos-arm64.tar.gz, cc_server-<version>-linux-x64.tar.gz, cc_server-<version>-windows-x64.zip, cc_server-<version>-windows-arm64.zip — junto con las imágenes cc-server, cc-webapp y cc-remote en GHCR. Consulta Ejecutar un servidor headless.

El archivo de Linux se compila en Ubuntu 22.04 y sus bibliotecas nativas incluidas enlazan glibc 2.35 y la libstdc++ de GCC 12, así que necesita un host al menos igual de reciente (Ubuntu 22.04, Debian 12, Fedora 36 o posterior). En una distribución más antigua, ejecuta la imagen cc-server en su lugar: un contenedor trae su propio userland, así que solo el kernel tiene que ser el tuyo.

Backend de agentes

Control Center despacha agentes a través de adaptadores. Hay dos, la lista es fija y se detectan automáticamente: no hay forma de registrar otro.

El adaptador Control Center (built-in) no necesita ninguna CLI externa: el bucle de agente se ejecuta dentro del servidor y habla con los proveedores de modelos por HTTP, así que siempre está disponible. Conecta un proveedor en Ajustes → Servidor → Proveedores de modelos. OpenAI, Codex, Cursor y Kimi Code ofrecen un inicio de sesión en el navegador; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai y Moonshot requieren una clave de API. Codex y Cursor son proveedores de este ejecutor, no CLI independientes. z.ai aparece dos veces a propósito: z.ai es la plataforma abierta de pago por uso, facturada contra el saldo de tu cuenta, mientras que z.ai GLM Coding Plan es la suscripción. Es la misma clave de cuenta, pero z.ai sirve el plan desde un host distinto: si pegas una clave del plan de código en el cuadro normal de z.ai, todas las peticiones devuelven 429 … "Insufficient balance or no resource package", porque el plan no tiene saldo que gastar. Una suscripción Claude Pro/Max no es un inicio de sesión en la API de Anthropic; llega a ese plan a través del adaptador Claude Code. Lo que sí puedes agregar en esa página es un proveedor personalizado: cualquier endpoint compatible con OpenAI o con Anthropic (Ollama, LM Studio, vLLM, un despliegue privado) en Proveedores personalizados → Añadir proveedor.

El otro adaptador envuelve una CLI externa:

Claude Code (claude): npm install -g @anthropic-ai/claude-code

La detección sondea el PATH de la máquina que ejecuta cc_server —la misma máquina cuando el escritorio ejecuta su propio servidor, el host remoto en caso contrario—. Instala allí la CLI de Claude Code, no en el cliente. El botón Actualizar de esa página vuelve a ejecutar la sonda.

Las listas de modelos las sirve en vivo cada proveedor conectado; models.dev solo aporta metadatos de precio y de ventana de contexto. Consulta Administrar adaptadores y modelos.

Autenticación con GitHub

Una credencial de GitHub es tuya y vive en el servidor, indexada por tu id de usuario, no en el llavero del sistema operativo del cliente. Todos los dispositivos desde los que inicies sesión usan la misma, y ningún otro miembro puede leerla.

Si el servidor tiene una GitHub App registrada (Crear la GitHub App), Ajustes → Espacio de trabajo → Perfil e identidad → Alojamiento de código ofrece Iniciar sesión con GitHub (un flujo de dispositivo que ejecuta el servidor). Si no, pega un token de acceso personal:

Clásico: repo y read:org
De grano fino: Contents y Pull requests (read and write), Checks y Actions (read)

Crea uno en GitHub → Settings → Developer settings → Personal access tokens. El servidor sondea el token para obtener el nombre de la cuenta tal como se guarda, así que la fila puede decir «sesión iniciada como …»; una sonda fallida guarda el token de todos modos, y un error tipográfico o un permiso faltante se manifestará más adelante como una petición fallida.

El primer paso de la incorporación inicial es esta conexión. Después, esa misma tarjeta es donde la reemplazas o la borras. GitLab y Bitbucket usan la misma tarjeta; consulta Conectar un host de código.

Elegir dónde se ejecuta el servidor

Control Center es un cliente ligero sobre un proceso cc_server headless que posee la base de datos y hace todo el trabajo; Implementación y clientes explica qué significa esa separación para el escritorio, la web y el teléfono.

En el primer arranque, el escritorio pregunta «¿Cómo debe ejecutarse Control Center?»:

Ejecutar en esta aplicación: el escritorio lanza y supervisa un cc_server en esta máquina y habla con él por loopback. No hay nada más que configurar. Esta es la configuración que da por supuesta el inicio rápido.
Conectar a una instancia remota: apunta el escritorio a un cc_server que se ejecute en otro sitio con su URL de WebSocket, un id de dispositivo y una clave de emparejamiento o un código de invitación de un solo uso. Ese servidor posee los datos; este escritorio solo los representa.

Agrega o cambia de servidor más adelante en Ajustes → Servidor → Conexión y estado. El cambio se reconecta en el sitio, sin reiniciar. Un navegador no puede ejecutar un servidor, así que el cliente web siempre es remoto; consulta Conéctate a un servidor remoto.

Para alojar tú mismo un servidor, sigue Ejecutar un servidor headless. Cubre cómo compilar el binario, cómo emitir una clave de emparejamiento antes del primer arranque y los flags --data-dir / --port / --bind.

Verifica tu configuración

Ajustes → Servidor → Proveedores de modelos lista ambos adaptadores. «Control Center (built-in)» aparece como encontrado con la versión built-in; Claude Code aparece como encontrado si su CLI está en el PATH del host del servidor. Presiona Actualizar si no aparece.
Ajustes → Espacio de trabajo → Repositorios lista los repos de este espacio de trabajo, y Añadir repositorio explora las carpetas del host del servidor.
Ajustes → Espacio de trabajo → Agentes lista los cinco agentes que sembró tu primer espacio de trabajo. Cada uno necesita un Adaptador y un Modelo definidos antes de poder ejecutarse.
Ajustes → Servidor → Diagnóstico y privacidad informa de los backends de sandbox que ofrece este host, el estado del modelo de embeddings y el registro.

Compilar desde el código fuente

Las bibliotecas nativas son obligatorias y no hay modo degradado: si falta una, el arranque falla en seco, no es una ruta más lenta. Prepara las nativas antes que cualquier otra cosa. Todos los comandos de Flutter y Dart pasan por fvm, porque la versión del SDK está fijada por el repo.

git clone https://github.com/SamuelAlev/control-center.git
cd control-center
scripts/natives/build_natives.sh
fvm flutter pub get
fvm flutter pub run build_runner build --delete-conflicting-outputs
fvm flutter gen-l10n
fvm flutter run -d macos  # or -d windows, -d linux

En macOS, el almacenamiento seguro (inicio de sesión de GitHub, Linear y Google) necesita que la aplicación esté firmada por un equipo de Apple: basta con un Apple ID gratuito, y es una configuración única que se describe en firma para desarrollo local. Sin ella, la aplicación se inicia igualmente; solo el almacenamiento seguro queda no disponible. Windows y Linux no necesitan firma.

Para compilar el binario del servidor headless, prepara antes las nativas del mismo modo y luego:

cd apps/cc_server
fvm dart build cli

El hook de compilación copia en el paquete lo que ya haya en build/natives/, así que compilar antes de preparar las nativas da como resultado un paquete sin nativas y un servidor que se niega a arrancar.

Para el cliente web, usa scripts/build_web.sh (--target remote para la PWA del teléfono). Es lo que ejecuta CI: un flutter build web a secas se salta el sello de identidad de compilación, la regeneración del Web Worker, el manifiesto de despliegue y la comprobación del presupuesto de recursos.