Installation

Control Center läuft auf zwei Wegen: als Web-App unter app.usectrl.dev, ohne etwas herunterzuladen, oder als Desktop-App, die du installierst. Es ist dieselbe Anwendung mit denselben Funktionen. Der einzige Unterschied ist, wo der Server läuft — und die Web-App kann dir keinen starten.

Im Browser nutzen

app.usectrl.dev ist diese Anwendung, kompiliert für den Browser. Nichts zu installieren, nichts zu aktualisieren. Öffnen und verbinden.

Was ein Browser-Tab nicht sein kann, ist der Server. Jeder Client — Desktop, Web, Smartphone — ist eine schlanke Oberfläche über einem Headless-cc_server, der die Datenbank besitzt und die Arbeit macht. Die Web-App spricht also immer mit einem Server, den du selbst betreibst. Zwei Wege, ihr einen zu geben:

Ein Server auf deinem eigenen Rechner. Starte cc_server lokal und richte die Web-App auf ws://localhost:9030. Browser behandeln localhost als vertrauenswürdig, also brauchst du kein Zertifikat und keinen Tunnel. Das ist der schnellste Weg, die Web-App auszuprobieren, und deine Daten verlassen den Rechner nie.

Ein Server auf einem anderen Rechner. Weil app.usectrl.dev über HTTPS ausgeliefert wird, muss ein nicht lokaler Server über wss:// erreichbar sein, mit einem Zertifikat, dem der Browser schon vertraut. cc_server lehnt ein Bind außerhalb von Loopback ohne TLS ab, also wählst du eines davon:

gib ihm ein Zertifikat direkt, mit --tls-cert und --tls-key
setze ihn hinter einen Reverse-Proxy, der TLS beendet, und starte ihn mit --insecure
mach ihn über einen Tunnel oder ein VPN erreichbar, das das Zertifikat liefert — Tailscale, cloudflared oder Ähnliches. Unter Einstellungen → Server → Verbindung und Status liegt die eingebaute Tunnel-Option bei Diesen Server teilen.

Sitzt der Server hinter einem Proxy, NAT oder Tunnel, setze --public-url auf die Adresse, die Clients wirklich anwählen sollen. Die Vorgabe ist das lokale Bind, ohne den Wert versuchen Clients also den falschen Host.

Einiges bleibt nur auf dem Desktop, weil es ein natives Fenster oder die eigenen Audiogeräte der Maschine braucht: die schwebende Pille des Fokusmodus, Betriebssystem-Toasts (die Benachrichtigungszentrale in der App funktioniert überall), „Aufnehmen und verknüpfen“ an einem Kalendertermin und eine Besprechungszusammenfassung erneut laufen lassen. Alles andere — Bereiche, Agenten, die Prüfung von Pull Requests, Pipelines, Tickets, Gedächtnis und die Besprechungsaufnahme selbst — verhält sich gleich.

Um die Web-App mit einem Server zu verbinden, folge Mit einem Remote-Server verbinden. Um den Server zu betreiben, folge Einen Headless-Server betreiben.

Systemanforderungen für den Desktop

Voraussetzung	macOS	Windows	Linux
Betriebssystem	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ oder eine andere Distribution mit glibc 2.35+ und GTK 3
Architektur	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Erforderlich	Erforderlich	Erforderlich
Speicherplatz	~200 MB für die App, plus das Datenverzeichnis des Servers	~200 MB	~200 MB

Für Intel-Macs gibt es keinen vorgefertigten Download. Baue stattdessen aus dem Quellcode.

Das Datenverzeichnis des Servers wächst über die App hinaus. Beim ersten Start installiert cc_server die Modelle auf dem Gerät zwingend — Text-Embeddings (~90 MB), Sprecher-Diarisierung (~35 MB) und das gewählte Sprachmodell (standardmäßig Parakeet TDT v3, ~600 MB; Whisper-Varianten 198–626 MB) — dazu ein eingebettetes code-server-Build, und jede Agenten-Unterhaltung bekommt einen Copy-on-Write-Worktree der Repos, an denen sie arbeitet (ein gewöhnliches git worktree unter Windows). Sprache ist nicht optional: Ohne das ASR-Modell werden Besprechungs- und Diktat-Operationen nicht bedient. Der erste Download des Sprachmodells braucht trotzdem einen Neustart, bevor die Aufnahme bereitsteht.

Der Desktop zeigt seinen Server auf das Anwendungsverzeichnis je Benutzer des Betriebssystems. Ein von Hand gestartetes cc_server ohne --data-dir nimmt als Vorgabe <application data>/control-center — ~/Library/Application Support/control-center unter macOS, %APPDATA%\control-center unter Windows, $XDG_DATA_HOME/control-center (oder ~/.local/share/control-center) unter Linux.

Herunterladen

Jedes Artefakt unten kommt aus den GitHub Releases.

macOS (Apple Silicon)

Lade Control-Center-<version>-arm64.dmg herunter, öffne es und ziehe Control Center in den Ordner Programme. Der Build ist mit einer Developer ID signiert und von Apple notarisiert, deshalb öffnet er sich normal.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: ein Installer je Benutzer.
Control-Center-<version>-windows-x64.zip: ein portables Zip.
Control-Center-<version>-arm64-setup.exe: ein Installer je Benutzer.
Control-Center-<version>-windows-arm64.zip: ein portables Zip.

Windows nutzt git worktree für die Checkouts von Bereichen (kein Copy-on-Write).

Linux (x86_64)

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

Das AppImage trägt Update-Informationen, deshalb können AppImageUpdate oder appimaged es an Ort und Stelle auf das neueste Release bringen und laden nur, was sich geändert hat.

Beide sind auf Ubuntu 22.04 gebaut und laufen darauf oder auf allem Neueren (Debian 12, Fedora 36 und später): Sie linken glibc 2.35 und die libstdc++ von GCC 12 und nehmen GTK 3 vom System. Die wenigen Bibliotheken, die einem gewöhnlichen Desktop fehlen können, reisen darin mit, es muss also nichts weiter installiert werden. Ton — Besprechungs-Wiedergabe, die Klanglandschaft, Rig-Audio und Benachrichtigungstöne — läuft über das libmpv des Systems (libmpv1 auf Ubuntu 22.04, libmpv2 auf neuerem Ubuntu und Debian, mpv-libs auf Fedora); ohne die Bibliothek startet die App mit diesen Steuerelementen ausgeblendet.

Eigenständiger Server

Jedes Release enthält den Headless-Server auch allein — 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 — neben den Images cc-server, cc-webapp und cc-remote auf GHCR. Siehe Einen Headless-Server betreiben.

Das Linux-Archiv ist auf Ubuntu 22.04 gebaut, und seine mitgelieferten nativen Bibliotheken linken glibc 2.35 und die libstdc++ von GCC 12. Der Host muss also mindestens so neu sein (Ubuntu 22.04, Debian 12, Fedora 36 oder später). Auf einer älteren Distribution nimm stattdessen das Image cc-server — ein Container bringt sein eigenes Userland mit, sodass nur der Kernel von dir sein muss.

Agenten-Backend

Control Center schickt Agenten über Adapter. Es gibt zwei, die Liste ist fest, und sie werden automatisch erkannt — einen weiteren kannst du nicht registrieren.

Der Adapter Control Center (built-in) braucht keine externe CLI: Die Agentenschleife läuft im Server und spricht über HTTP mit den Modellanbietern, deshalb ist er immer verfügbar. Einen Anbieter verbindest du unter Einstellungen → Server → Modellanbieter. OpenAI, Codex, Cursor und Kimi Code bieten eine Anmeldung im Browser; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai und Moonshot nehmen einen API-Schlüssel. Codex und Cursor sind Anbieter auf diesem Runner, keine eigenen CLIs. z.ai steht absichtlich zweimal in der Liste: z.ai ist die nutzungsbasierte offene Plattform, abgerechnet gegen dein Kontoguthaben, z.ai GLM Coding Plan ist das Abo. Es ist derselbe Kontoschlüssel, aber z.ai liefert den Tarif von einem anderen Host — fügst du einen Coding-Plan-Schlüssel in die schlichte z.ai-Kachel ein, kommt jede Anfrage mit 429 … "Insufficient balance or no resource package" zurück, weil der Tarif kein Guthaben hat, das er ausgeben könnte. Ein Claude-Pro/Max-Abo ist keine Anmeldung an der Anthropic-API; diesen Tarif erreichst du über den Claude-Code-Adapter. Was du auf der Seite hinzufügen kannst, ist ein eigener Anbieter — jeder mit OpenAI oder Anthropic kompatible Endpunkt (Ollama, LM Studio, vLLM, eine private Bereitstellung) unter Eigene Anbieter → Anbieter hinzufügen.

Der andere Adapter umhüllt eine externe CLI:

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

Die Erkennung prüft den PATH der Maschine, auf der cc_server läuft — dieselbe Maschine, wenn der Desktop seinen eigenen Server startet, sonst der entfernte Host. Installiere die Claude-Code-CLI dort, nicht auf dem Client. Die Schaltfläche Aktualisieren auf der Seite wiederholt die Prüfung.

Modelllisten kommen live von jedem verbundenen Anbieter; models.dev liefert nur Preis- und Kontextfenster-Metadaten. Siehe Adapter und Modelle verwalten.

GitHub-Authentifizierung

Ein GitHub-Zugangsdatum gehört dir und liegt auf dem Server, gebunden an deine Benutzer-ID — nicht im Schlüsselbund des Client-Betriebssystems. Jedes Gerät, von dem du dich anmeldest, nutzt dasselbe, und kein anderes Mitglied kann es lesen.

Hat der Server eine GitHub App registriert (Die GitHub App erstellen), bietet Einstellungen → Arbeitsbereich → Profil und Identität → Code-Hosting die Schaltfläche Mit GitHub anmelden (ein Device Flow, den der Server ausführt). Sonst fügst du ein persönliches Zugriffstoken ein:

Classic: repo und read:org
Fine-grained: Contents und Pull requests (read and write), Checks und Actions (read)

Lege eins an unter GitHub → Settings → Developer settings → Personal access tokens. Der Server prüft das Token auf den Kontonamen, so wie es gespeichert wird, damit die Zeile „Angemeldet als …“ sagen kann. Eine fehlgeschlagene Prüfung speichert das Token trotzdem, und ein Tippfehler oder ein fehlender Scope zeigt sich später als fehlgeschlagene Anfrage.

Der erste Schritt des Onboardings ist diese Verbindung. Danach ersetzt oder löschst du sie auf derselben Karte. GitLab und Bitbucket nutzen dieselbe Karte; siehe Einen Code-Host verbinden.

Wo der Server läuft

Control Center ist ein schlanker Client über einem Headless-Prozess cc_server, der die Datenbank besitzt und die ganze Arbeit macht; Bereitstellung und Clients erklärt, was diese Trennung für Desktop, Web und Smartphone bedeutet.

Beim ersten Start fragt der Desktop „Wie soll Control Center laufen?“:

In dieser App ausführen: Der Desktop startet und beaufsichtigt ein cc_server auf diesem Rechner und spricht mit ihm über Loopback. Sonst ist nichts einzurichten. Das ist die Einrichtung, von der der Schnellstart ausgeht.
Mit einer entfernten Instanz verbinden: Richte den Desktop auf ein cc_server, das woanders läuft, mit seiner WebSocket-URL, einer Geräte-ID und entweder einem Kopplungsschlüssel oder einem einmaligen Einladungscode. Dieser Server besitzt die Daten; dieser Desktop zeichnet sie nur.

Server fügst du später hinzu oder wechselst sie unter Einstellungen → Server → Verbindung und Status. Der Wechsel verbindet an Ort und Stelle neu — kein Neustart. Ein Browser kann keinen Server ausführen, der Web-Client ist also immer entfernt; siehe Mit einem Remote-Server verbinden.

Um selbst einen Server zu betreiben, folge Einen Headless-Server betreiben. Dort steht, wie du die Binärdatei baust, vor dem ersten Start einen Kopplungsschlüssel ausstellst und die Flags --data-dir / --port / --bind setzt.

Einrichtung prüfen

Einstellungen → Server → Modellanbieter listet beide Adapter. „Control Center (built-in)“ steht auf Verfügbar mit der Version built-in; Claude Code steht auf Verfügbar, wenn seine CLI auf dem PATH des Server-Hosts liegt. Fehlt sie, drücke Aktualisieren.
Einstellungen → Arbeitsbereich → Repositorys listet die Repos dieses Arbeitsbereichs, und Repository hinzufügen durchsucht die Ordner des Server-Hosts.
Einstellungen → Arbeitsbereich → Agenten listet die fünf Agenten, die dein erster Arbeitsbereich angelegt hat. Jeder braucht einen gesetzten Adapter und ein Modell, bevor er laufen kann.
Einstellungen → Server → Diagnose und Datenschutz meldet die Sandbox-Backends, die dieser Host anbietet, den Zustand des Embedding-Modells und das Logging.

Aus dem Quellcode bauen

Native Bibliotheken sind erforderlich, und einen eingeschränkten Modus gibt es nicht: Fehlt eine, ist das ein harter Startfehler, kein langsamerer Weg. Stelle sie bereit, bevor du irgendetwas anderes tust. Jeder Flutter- und Dart-Befehl geht über fvm, weil die SDK-Version vom Repo festgehalten wird.

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

Unter macOS braucht der sichere Speicher (Anmeldung bei GitHub, Linear und Google) eine App, die von einem Apple-Team signiert ist — eine kostenlose Apple ID reicht, und die einmalige Einrichtung steht unter Signieren für die lokale Entwicklung. Ohne sie startet die App trotzdem; nur der sichere Speicher fehlt. Windows und Linux brauchen keine Signatur.

Um die Headless-Server-Binärdatei zu bauen, stelle die Natives zuerst auf dieselbe Weise bereit, dann:

cd apps/cc_server
fvm dart build cli

Der Build-Hook kopiert, was schon in build/natives/ liegt, ins Bundle. Baust du, bevor die Natives dort liegen, entsteht ein Bundle ohne Natives, und der Server verweigert den Start.

Für den Web-Client nimmst du scripts/build_web.sh (--target remote für die Telefon-PWA). Genau das führt die CI aus: ein bloßes flutter build web lässt den Build-Identitäts-Stempel, die Neuerzeugung der Web Worker, das Deploy-Manifest und die Prüfung des Asset-Budgets aus.