Встановлення

Control Center працює двома способами: як вебзастосунок за адресою app.usectrl.dev, де нічого не потрібно завантажувати, або як настільний застосунок, який ви встановлюєте. Це та сама програма з тими самими функціями. Єдина різниця — де запущено сервер, а вебзастосунок не може запустити його за вас.

Використовуйте в браузері

app.usectrl.dev — це ця сама програма, скомпільована для браузера. Нічого не треба встановлювати, нічого оновлювати. Відкрийте й підключіться.

Чого вкладка браузера не може — це бути сервером. Кожен клієнт — настільний, веб, телефон — це тонкий рендерер над headless-cc_server, який володіє базою даних і виконує всю роботу, тож вебзастосунок завжди спілкується із сервером, який запускаєте ви. Дати йому сервер можна двома способами:

Сервер на вашій власній машині. Запустіть cc_server локально й спрямуйте вебзастосунок на ws://localhost:9030. Браузери вважають localhost довіреним, тож це не потребує ні сертифіката, ні тунелю. Це найшвидший спосіб спробувати вебзастосунок, і ваші дані ніколи не залишають вашої машини.

Сервер на іншій машині. Оскільки app.usectrl.dev віддається через HTTPS, нелокальний сервер має бути доступний через wss:// із сертифікатом, якому браузер уже довіряє. cc_server відмовляється прив’язувати адресу поза loopback без TLS, тож виберіть одне з:

дайте йому сертифікат напряму, за допомогою --tls-cert і --tls-key
поставте його за зворотний проксі, що завершує TLS, і запустіть із --insecure
відкрийте доступ до нього через тунель або VPN, який надає сертифікат — Tailscale, cloudflared тощо. Налаштування → Сервер → Підключення та стан містить вбудовану опцію ввімкнення тунелю в розділі Надати доступ до цього сервера.

Коли сервер стоїть за проксі, NAT або тунелем, задайте --public-url як адресу, до якої клієнти насправді мають звертатися. Типово це локальна прив’язка, тож без нього клієнти звертатимуться не до того хоста.

Дещо залишається лише на настільному застосунку, бо потребує нативного вікна чи власних аудіопристроїв машини: плаваюча пілюля режиму фокусу, системні спливаючі сповіщення ОС (центр сповіщень у застосунку працює всюди), «Почати запис і прив’язати» з події в календарі та повторний запуск підсумку зустрічі. Усе інше — простори, агенти, перевірка pull requests, конвеєри, тікети, пам’ять і сам запис зустрічей — поводиться однаково.

Щоб підключити вебзастосунок до сервера, дотримуйтеся Під’єднатися до віддаленого сервера. Щоб розмістити сервер, дотримуйтеся Запустити headless-сервер.

Системні вимоги настільного застосунку

Вимога	macOS	Windows	Linux
Версія ОС	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ або інший дистрибутив із glibc 2.35+ і GTK 3
Архітектура	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Обов’язково	Обов’язково	Обов’язково
Місце на диску	~200 MB для застосунку плюс каталог даних сервера	~200 MB	~200 MB

Для Intel Mac немає готового завантаження. Натомість зберіть із вихідного коду.

Каталог даних сервера переростає застосунок. Під час першого запуску cc_server примусово встановлює моделі на пристрої — текстові вбудовування (~90 MB), діаризацію промовців (~35 MB) і вибрану модель мовлення (типово Parakeet TDT v3, ~600 MB; варіанти Whisper 198–626 MB) — а також вбудовану збірку code-server, і кожна розмова з агентом отримує робоче дерево репозиторіїв, з якими працює, за принципом copy-on-write (звичайний git worktree на Windows). Мовлення не є необов’язковим: без моделі ASR операції із зустрічами й диктуванням не обслуговуються. Перше завантаження моделі мовлення все одно потребує одного перезапуску, перш ніж запис запрацює.

Настільний застосунок спрямовує свій сервер на каталог підтримки застосунків у ОС для окремого користувача. cc_server, запущений вручну без --data-dir, типово використовує <application data>/control-center — ~/Library/Application Support/control-center на macOS, %APPDATA%\control-center на Windows, $XDG_DATA_HOME/control-center (або ~/.local/share/control-center) на Linux.

Завантаження

Кожен артефакт нижче походить із GitHub Releases.

macOS (Apple Silicon)

Завантажте Control-Center-<version>-arm64.dmg, відкрийте його й перетягніть Control Center до теки Applications. Збірка підписана Developer ID і нотаризована Apple, тож відкривається звичайно.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: інсталятор для окремого користувача.
Control-Center-<version>-windows-x64.zip: портативний zip-архів.
Control-Center-<version>-arm64-setup.exe: інсталятор для окремого користувача.
Control-Center-<version>-windows-arm64.zip: портативний zip-архів.

Windows використовує git worktree для checkout просторів (без copy-on-write).

Linux (x86_64)

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

AppImage містить інформацію для оновлення, тож AppImageUpdate або appimaged можуть оновити його до останнього випуску на місці, завантажуючи лише зміни.

Обидва зібрано на Ubuntu 22.04, і працюють вони на ній чи на будь-чому новішому (Debian 12, Fedora 36 і пізніші): вони лінкуються з glibc 2.35 і libstdc++ від GCC 12 та беруть GTK 3 із системи. Кілька бібліотек, яких може бракувати звичайному настільному середовищу, подорожують усередині них, тож більше нічого встановлювати не треба. Звук — відтворення зустрічей, звуковий пейзаж, аудіо Rig і звуки сповіщень — відтворюється через системний libmpv (libmpv1 на Ubuntu 22.04, libmpv2 на новіших Ubuntu та Debian, mpv-libs на Fedora); без нього застосунок запускається з прихованими цими елементами керування.

Окремий сервер

Кожен випуск також містить headless-сервер окремо — 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 — поряд з образами cc-server, cc-webapp і cc-remote на GHCR. Див. Запустити headless-сервер.

Архів для Linux зібрано на Ubuntu 22.04, і його вбудовані нативні бібліотеки лінкуються з glibc 2.35 і libstdc++ від GCC 12, тож потрібен хост щонайменше такої ж свіжості (Ubuntu 22.04, Debian 12, Fedora 36 або пізніші). На старішому дистрибутиві запускайте натомість образ cc-server — контейнер приносить власний userland, тож вашим має бути лише ядро.

Бекенд агента

Control Center спрямовує агентів через адаптери. Їх два, цей список фіксований, і вони виявляються автоматично — зареєструвати ще один неможливо.

Адаптеру Control Center (built-in) не потрібен зовнішній CLI: цикл агента виконується всередині сервера й спілкується з провайдерами моделей через HTTP, тож він доступний завжди. Підключіть провайдера в розділі Налаштування → Сервер → Постачальники моделей. OpenAI, Codex, Cursor і Kimi Code пропонують вхід через браузер; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai і Moonshot приймають API-ключ. Codex і Cursor — це провайдери на цьому раннері, а не окремі CLI. z.ai наведено двічі навмисно: z.ai — це відкрита платформа з оплатою за використання, яку списують з балансу вашого облікового запису, а z.ai GLM Coding Plan — це підписка. Це той самий ключ облікового запису, але z.ai обслуговує план з іншого хоста — вставте ключ плану Coding Plan у звичайну плитку z.ai, і кожен запит повертатиметься з 429 … "Insufficient balance or no resource package", бо в плану немає балансу, який можна витратити. Підписка Claude Pro/Max — це не вхід в Anthropic API; для цього плану натомість використовуйте адаптер Claude Code. Те, що ви можете додати на цій сторінці, — це користувацький провайдер: будь-яка кінцева точка, сумісна з OpenAI або Anthropic (Ollama, LM Studio, vLLM, приватне розгортання), у розділі Користувацькі провайдери → Додати провайдера.

Інший адаптер обгортає зовнішній CLI:

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

Виявлення перевіряє PATH машини, на якій запущено cc_server — тієї самої машини, коли настільний застосунок запускає власний сервер, інакше — віддаленого хоста. Встановіть CLI Claude Code саме там, а не на клієнті. Кнопка Оновити на цій сторінці повторює перевірку.

Списки моделей кожен підключений провайдер віддає наживо; models.dev дає лише ціну та метадані вікна контексту. Див. Керувати адаптерами та моделями.

Автентифікація GitHub

Облікові дані GitHub належать вам і зберігаються на сервері, прив’язані до вашого ідентифікатора користувача, — не в системному сховищі ключів клієнта. Кожен пристрій, з якого ви входите, використовує ті самі дані, і жоден інший учасник не може їх прочитати.

Якщо на сервері зареєстровано GitHub App (Створити GitHub App), Налаштування → Робочий простір → Профіль і ідентичність → Хостинг коду пропонує Увійти через GitHub (потік із кодом пристрою, який виконує сервер). Інакше вставте особистий токен доступу:

Класичний: repo і read:org
Деталізований: Contents і Pull requests (читання й запис), Checks і Actions (читання)

Створіть його тут: GitHub → Settings → Developer settings → Personal access tokens. Сервер перевіряє токен на назву облікового запису в тому вигляді, у якому його збережено, тож рядок може показувати «ви увійшли як …»; невдала перевірка все одно зберігає токен, а друкарська помилка чи відсутня область доступу згодом проявиться як невдалий запит.

Перший крок початкового налаштування — саме це підключення. Далі на тій самій картці ви його замінюєте чи очищаєте. GitLab і Bitbucket використовують ту саму картку; див. Підключити хост коду.

Де запускається сервер

Control Center — це тонкий клієнт над процесом headless cc_server, який володіє базою даних і виконує всю роботу; Розгортання та клієнти пояснює, що цей поділ означає для настільного застосунку, веба й телефона.

Під час першого запуску настільний застосунок запитує «Як має працювати Control Center?»:

Запускати в цьому застосунку: настільний застосунок породжує й наглядає за cc_server на цій машині та спілкується з ним через loopback. Більше нічого налаштовувати не треба. Саме цю конфігурацію передбачає швидкий старт.
Підключитися до віддаленого екземпляра: спрямуйте настільний застосунок на cc_server, що працює деінде, вказавши його URL WebSocket, ідентифікатор пристрою та або ключ прив’язки, або одноразовий код запрошення. Той сервер володіє даними; цей настільний застосунок лише відображає їх.

Додати чи перемкнути сервери можна пізніше в розділі Налаштування → Сервер → Підключення та стан. Перемикання повторно підключається на місці — без перезапуску. Браузер не може запустити сервер, тож вебклієнт завжди віддалений; див. Під’єднатися до віддаленого сервера.

Щоб розмістити сервер самостійно, дотримуйтеся Запустити headless-сервер. Там описано збірку бінарника, створення ключа прив’язки перед першим запуском і прапорці --data-dir / --port / --bind.

Перевірте своє налаштування

Налаштування → Сервер → Постачальники моделей перелічує обидва адаптери. «Control Center (built-in)» показано як знайдений із версією built-in; Claude Code показано як знайдений, якщо його CLI є в PATH хоста сервера. Натисніть Оновити, якщо його немає.
Налаштування → Робочий простір → Репозиторії перелічує репозиторії цього робочого простору, а Додати репозиторій переглядає каталоги хоста сервера.
Налаштування → Робочий простір → Агенти перелічує п’ятьох агентів, яких створив ваш перший робочий простір. Кожному потрібно задати Адаптер і Модель, перш ніж він зможе працювати.
Налаштування → Сервер → Діагностика та приватність показує бекенди пісочниці, які пропонує цей хост, стан моделі вбудовування та логування.

Збірка з вихідного коду

Нативні бібліотеки обов’язкові, і жодного зниженого режиму немає: відсутня бібліотека — це жорсткий збій під час запуску, а не повільніший шлях. Підготуйте їх перед усім іншим. Кожна команда Flutter і Dart виконується через fvm, бо версію SDK закріплено в репозиторії.

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

На macOS захищене сховище (вхід через GitHub, Linear і Google) потребує, щоб застосунок було підписано командою Apple — безкоштовного Apple ID достатньо, і це одноразове налаштування, описане в розділі підписування для локальної розробки. Без цього застосунок усе одно запускається; недоступне лише захищене сховище. Windows і Linux підпису не потребують.

Щоб зібрати бінарник headless-сервера, спершу так само підготуйте нативні бібліотеки, а потім:

cd apps/cc_server
fvm dart build cli

Хук збірки копіює те, що вже лежить у build/natives/, до бандла, тож збірка до підготовки дає бандл без нативних бібліотек і сервер, який відмовляється запускатися.

Для вебклієнта використовуйте scripts/build_web.sh (--target remote для PWA телефона). Саме це запускає CI: звичайний flutter build web пропускає штамп ідентичності збірки, перегенерацію Web Worker, маніфест розгортання й перевірку бюджету ресурсів.