Installer

Control Center kjører på to måter: som en nettapp på app.usectrl.dev, uten noe å laste ned, eller som en skrivebordsapp du installerer. Det er samme applikasjon med de samme funksjonene. Den eneste forskjellen er hvor serveren kjører — og nettappen kan ikke kjøre en for deg.

Bruk den i nettleseren

app.usectrl.dev er denne applikasjonen kompilert for nettleseren. Ingenting å installere, ingenting å oppdatere. Åpne den og koble til.

Det en nettleserfane ikke kan gjøre, er å være serveren. Hver klient — skrivebord, nett, telefon — er en tynn renderer over en headless cc_server som eier databasen og gjør arbeidet, så nettappen snakker alltid med en server du kjører. To måter å gi den en:

En server på din egen maskin. Start cc_server lokalt og pek nettappen mot ws://localhost:9030. Nettlesere anser localhost som klarert, så dette krever ingen sertifikat og ingen tunnel. Det er den raskeste måten å prøve nettappen på, og dataene dine forlater aldri maskinen din.

En server på en annen maskin. Fordi app.usectrl.dev leveres over HTTPS, må en ikke-lokal server være tilgjengelig over wss:// med et sertifikat nettleseren allerede stoler på. cc_server nekter å binde en ikke-loopback-adresse uten TLS, så velg ett av:

gi den et sertifikat direkte, med --tls-cert og --tls-key
sett den bak en TLS-avsluttende reversproxy og start den med --insecure
eksponer den gjennom en tunnel eller VPN som skaffer sertifikatet — Tailscale, cloudflared eller lignende. Innstillinger → Server → Tilkobling og status har det innebygde, valgfrie tunnelvalget under Del denne serveren.

Når serveren ligger bak en proxy, NAT eller tunnel, setter du --public-url til adressen klientene faktisk skal koble til. Den har standardverdien fra den lokale bindingen, så uten den prøver klientene feil vert.

Noen få ting forblir kun på skrivebordet, fordi de trenger et native vindu eller maskinens egne lydenheter: den flytende fokusmodus-pillen, varselpopuper fra operativsystemet (varslingssenteret i appen fungerer overalt), «Start opptak og knytt» fra en kalenderhendelse, og å kjøre et møtesammendrag på nytt. Alt annet — områder, agenter, pull request-gjennomgang, pipelines, saker, minne og selve møteopptaket — oppfører seg likt.

For å koble nettappen til en server, følg Koble til en ekstern server. For å hoste serveren, følg Kjør en headless server.

Systemkrav for skrivebordet

Krav	macOS	Windows	Linux
OS-versjon	macOS 13+ (Ventura)	Windows 10+	Ubuntu 22.04+ eller en annen distro med glibc 2.35+ og GTK 3
Arkitektur	Apple Silicon (arm64)	x64, ARM64	x86_64
Git	Påkrevd	Påkrevd	Påkrevd
Diskplass	~200 MB for appen, pluss serverens datakatalog	~200 MB	~200 MB

Intel-Macer har ingen forhåndsbygd nedlasting. Bygg fra kildekoden i stedet.

Serverens datakatalog vokser forbi appen. Ved første start tvangsinstallerer cc_server modellene på enheten — tekst-embeddinger (~90 MB), talerdiarisering (~35 MB) og den valgte talemodellen (Parakeet TDT v3 som standard, ~600 MB; Whisper-varianter 198–626 MB) — pluss en innebygd code-server-bygging, og hver agentsamtale får et copy-on-write-worktree av repoene den arbeider med (vanlig git worktree på Windows). Tale er ikke valgfritt: uten ASR-modellen betjenes ikke møte- og dikteringsoperasjoner. Den første nedlastingen av talemodellen krever fortsatt én omstart før opptaket lyser opp.

Skrivebordsappen peker serveren sin mot operativsystemets katalog for programstøtte per bruker. En cc_server som startes manuelt uten --data-dir, bruker <application data>/control-center som standard — ~/Library/Application Support/control-center på macOS, %APPDATA%\control-center på Windows, $XDG_DATA_HOME/control-center (eller ~/.local/share/control-center) på Linux.

Nedlasting

Alle artefaktene nedenfor kommer fra GitHub Releases.

macOS (Apple Silicon)

Last ned Control-Center-<version>-arm64.dmg, åpne den og dra Control Center til Programmer. Byggingen er signert med en Developer ID og notarisert av Apple, så den åpnes normalt.

Windows (x64, ARM64)

Control-Center-<version>-x64-setup.exe: en installasjonspakke per bruker.
Control-Center-<version>-windows-x64.zip: en portabel zip.
Control-Center-<version>-arm64-setup.exe: en installasjonspakke per bruker.
Control-Center-<version>-windows-arm64.zip: en portabel zip.

Windows bruker git worktree for utsjekking av områder (ingen copy-on-write).

Linux (x86_64)

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

AppImage-filen har med seg oppdateringsinformasjon, så AppImageUpdate eller appimaged kan oppdatere den til nyeste versjon på stedet og bare laste ned det som er endret.

Begge bygges på Ubuntu 22.04 og kjører på den eller nyere (Debian 12, Fedora 36 og senere): de lenker mot glibc 2.35 og libstdc++ fra GCC 12 og bruker GTK 3 fra systemet. De få bibliotekene en vanlig skrivebordsinstallasjon kan mangle, følger med inni dem, så ingenting annet trenger å installeres. Lyd — møteavspilling, lydlandskapet, rigg-lyd og varsellyder — spilles av gjennom systemets libmpv (libmpv1 på Ubuntu 22.04, libmpv2 på nyere Ubuntu og Debian, mpv-libs på Fedora); uten den starter appen med disse kontrollene skjult.

Frittstående server

Hver utgivelse inneholder også den headless serveren for seg selv — 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 — ved siden av avbildningene cc-server, cc-webapp og cc-remote på GHCR. Se Kjør en headless server.

Linux-arkivet bygges på Ubuntu 22.04, og de medfølgende native bibliotekene lenker mot glibc 2.35 og libstdc++ fra GCC 12, så det krever en vert som er minst like ny (Ubuntu 22.04, Debian 12, Fedora 36 eller senere). På en eldre distribusjon bruker du avbildningen cc-server i stedet — en container har sitt eget brukerland, så bare kjernen må være din.

Agentbackend

Control Center sender ut agenter gjennom adaptere. Det finnes to, listen er fast, og de oppdages automatisk — det finnes ingen måte å registrere en ny.

Adapteren Control Center (built-in) trenger ingen ekstern CLI: agentløkken kjører inne i serveren og snakker med modellleverandører over HTTP, så den er alltid tilgjengelig. Koble til en leverandør under Innstillinger → Server → Modellleverandører. OpenAI, Codex, Cursor og Kimi Code tilbyr pålogging i nettleseren; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai og Moonshot tar en API-nøkkel. Codex og Cursor er leverandører på denne kjøreren, ikke egne CLI-er. z.ai står med vilje oppført to ganger: z.ai er den åpne plattformen med betaling etter bruk, fakturert mot saldoen på kontoen din, mens z.ai GLM Coding Plan er abonnementet. Det er samme kontonøkkel, men z.ai betjener abonnementet fra en annen vert — limer du inn en abonnementsnøkkel i den vanlige z.ai-flisen, kommer hver forespørsel tilbake med 429 … "Insufficient balance or no resource package", fordi abonnementet ikke har noen saldo å bruke. Et Claude Pro/Max-abonnement er ikke en pålogging til Anthropic-API-et; nå det abonnementet gjennom Claude Code-adapteren i stedet. Det du kan legge til på den siden, er en egendefinert leverandør — et hvilket som helst OpenAI- eller Anthropic-kompatibelt endepunkt (Ollama, LM Studio, vLLM, en privat distribusjon) under Egendefinerte leverandører → Legg til leverandør.

Den andre adapteren pakker inn en ekstern CLI:

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

Oppdagelsen sonderer PATH på maskinen som kjører cc_server — samme maskin når skrivebordsappen kjører sin egen server, ellers den eksterne verten. Installer Claude Code-CLI-en der, ikke på klienten. Oppdater-knappen på den siden kjører sonderingen på nytt.

Modellister betjenes direkte av hver tilkoblet leverandør; models.dev leverer bare metadata om pris og kontekstvindu. Se Administrer adaptere og modeller.

GitHub-autentisering

En GitHub-legitimasjon er din og ligger på serveren, knyttet til bruker-id-en din — ikke i klientoperativsystemets nøkkelring. Hver enhet du logger inn fra, bruker den samme, og ingen andre medlemmer kan lese den.

Hvis serveren har en GitHub App registrert (Opprett GitHub App), tilbyr Innstillinger → Arbeidsområde → Profil og identitet → Kodehosting Logg inn med GitHub (en enhetsflyt serveren kjører). Ellers limer du inn et personlig tilgangstoken:

Klassisk: repo og read:org
Finkornet: Contents og Pull requests (les og skriv), Checks og Actions (les)

Opprett ett på GitHub → Settings → Developer settings → Personal access tokens. Serveren sonderer tokenet for kontonavnet slik det lagres, så raden kan si «logget inn som …»; en mislykket sondering lagrer likevel tokenet, og en skrivefeil eller et manglende omfang dukker opp som en mislykket forespørsel senere.

Første steg i oppstartsveiledningen er denne tilkoblingen. Etterpå er det samme kortet stedet der du bytter ut eller fjerner den. GitLab og Bitbucket bruker samme kort; se Koble til en kodevert.

Velg hvor serveren skal kjøre

Control Center er en tynn klient over en headless cc_server-prosess som eier databasen og gjør alt arbeidet; Drift og klienter forklarer hva denne delingen betyr for skrivebord, nett og telefon.

Ved første oppstart spør skrivebordsappen «Hvordan skal Control Center kjøre?»:

Kjør i denne appen: skrivebordsappen starter og overvåker en cc_server på denne maskinen og snakker med den over loopback. Ingenting annet å konfigurere. Dette er oppsettet hurtigstarten forutsetter.
Koble til en ekstern instans: pek skrivebordsappen mot en cc_server som kjører et annet sted, med WebSocket-URL-en, en enhets-id og enten en paringsnøkkel eller en engangskode for invitasjon. Den serveren eier dataene; denne skrivebordsappen gjengir dem bare.

Legg til eller bytt servere senere under Innstillinger → Server → Tilkobling og status. Bytte kobler til på nytt uten omstart. En nettleser kan ikke kjøre en server, så nettklienten er alltid ekstern; se Koble til en ekstern server.

For å hoste en server selv, følg Kjør en headless server. Den dekker bygging av binærfilen, utstedelse av en paringsnøkkel før første start, og flaggene --data-dir / --port / --bind.

Verifiser oppsettet

Innstillinger → Server → Modellleverandører viser begge adapterne. «Control Center (built-in)» vises som funnet med versjonen built-in; Claude Code vises som funnet hvis CLI-en ligger på PATH til serververten. Trykk Oppdater hvis den mangler.
Innstillinger → Arbeidsområde → Arkiv viser repoene i dette arbeidsområdet, og Legg til arkiv lar deg bla gjennom mappene på serververten.
Innstillinger → Arbeidsområde → Agenter viser de fem agentene det første arbeidsområdet ditt ble opprettet med. Hver av dem trenger en Adapter og en Modell satt før den kan kjøre.
Innstillinger → Server → Diagnostikk og personvern rapporterer sandkasse-backendene denne verten tilbyr, tilstanden til embedding-modellen og logging.

Bygg fra kildekoden

Native biblioteker er påkrevd, og det finnes ingen redusert modus: et manglende bibliotek er en hard oppstartsfeil, ikke en tregere vei. Klargjør dem før alt annet. Hver Flutter- og Dart-kommando går gjennom fvm, fordi SDK-versjonen er låst av repoet.

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

På macOS krever sikker lagring (pålogging med GitHub, Linear og Google) at appen er signert av et Apple-team — en gratis Apple-ID er nok, og det er et engangsoppsett som er beskrevet under signering for lokal utvikling. Uten det starter appen likevel; bare sikker lagring er utilgjengelig. Windows og Linux trenger ingen signering.

For å bygge binærfilen til den headless serveren klargjør du native-bibliotekene på samme måte først, og deretter:

cd apps/cc_server
fvm dart build cli

Byggekroken kopierer alt som allerede ligger i build/natives/, inn i pakken, så bygger du før du klargjør, får du en pakke uten native-biblioteker og en server som nekter å starte.

For nettklienten bruker du scripts/build_web.sh (--target remote for telefon-PWA-en). Det er det CI kjører: en vanlig flutter build web hopper over byggeidentitetsstempelet, regenereringen av Web Worker, distribusjonsmanifestet og kontrollen av ressursbudsjettet.