İçeriğe geç

Kurulum

Control Center iki şekilde çalışır: app.usectrl.dev adresinde indirilecek hiçbir şey olmadan bir web uygulaması olarak ya da kurduğunuz bir masaüstü uygulaması olarak. İkisi de aynı özelliklere sahip aynı uygulamadır. Tek fark, sunucunun nerede çalıştığıdır — ve web uygulaması sizin için bir sunucu çalıştıramaz.

app.usectrl.dev bu uygulamanın tarayıcı için derlenmiş hâlidir. Kurulacak bir şey yok, güncellenecek bir şey yok. Açın ve bağlanın.

Bir tarayıcı sekmesinin yapamayacağı şey, sunucunun kendisi olmaktır. Her istemci — masaüstü, web, telefon — veritabanına sahip olan ve işi yapan headless bir cc_server üzerinde ince bir katmandır; bu yüzden web uygulaması her zaman sizin çalıştırdığınız bir sunucuyla konuşur. Ona bir sunucu vermenin iki yolu vardır:

Kendi makinenizde bir sunucu. cc_server’ı yerel olarak başlatın ve web uygulamasını ws://localhost:9030 adresine yönlendirin. Tarayıcılar localhost’u güvenilir sayar, dolayısıyla bunun için sertifika da tünel de gerekmez. Web uygulamasını denemenin en hızlı yolu budur ve verileriniz makinenizden hiç ayrılmaz.

Başka bir makinede bir sunucu. app.usectrl.dev HTTPS üzerinden sunulduğu için yerel olmayan bir sunucuya, tarayıcının zaten güvendiği bir sertifikayla wss:// üzerinden erişilebilmesi gerekir. cc_server TLS olmadan loopback dışı bir adrese bağlanmayı reddeder, bu yüzden şunlardan birini seçin:

  • ona doğrudan bir sertifika verin, --tls-cert ve --tls-key ile
  • onu TLS sonlandıran bir ters proxy’nin arkasına koyun ve --insecure ile başlatın
  • sertifikayı sağlayan bir tünel ya da VPN üzerinden erişilebilir kılın — Tailscale, cloudflared ya da benzeri. Ayarlar → Sunucu → Bağlantı ve durum sayfasında, Bu sunucuyu paylaş altında yerleşik tünel katılımı bulunur.

Sunucu bir proxy, NAT ya da tünelin arkasında olduğunda, --public-url ayarını istemcilerin gerçekte araması gereken adrese ayarlayın. Varsayılanı yerel bağlanma adresidir; dolayısıyla bu ayar olmadan istemciler yanlış ana makineyi dener.

Birkaç şey masaüstüyle sınırlı kalır, çünkü yerel bir pencereye ya da makinenin kendi ses aygıtlarına ihtiyaç duyarlar: yüzen odak modu hapı, işletim sistemi bildirim baloncukları (uygulama içi bildirim merkezi her yerde çalışır), bir takvim etkinliğinden “kaydı başlat ve bağla” ve bir toplantı özetini yeniden çalıştırma. Geri kalan her şey — alanlar, ajanlar, pull request incelemesi, pipeline’lar, biletler, bellek ve toplantı kaydının kendisi — aynı şekilde davranır.

Web uygulamasını bir sunucuya bağlamak için Uzak bir sunucuya bağlanma sayfasını izleyin. Sunucuyu barındırmak için Headless bir sunucu çalıştırma sayfasını izleyin.

Gereksinim macOS Windows Linux
İşletim sistemi sürümü macOS 13+ (Ventura) Windows 10+ Ubuntu 22.04+ ya da glibc 2.35+ ve GTK 3 içeren başka bir dağıtım
Mimari Apple Silicon (arm64) x64, ARM64 x86_64
Git Gerekli Gerekli Gerekli
Disk alanı Uygulama için ~200 MB, artı sunucunun veri dizini ~200 MB ~200 MB

Intel Mac’ler için hazır indirme yoktur. Bunun yerine kaynaktan derleyin.

Sunucunun veri dizini, uygulamadan çok daha fazla yer kaplar. cc_server ilk başlatılışında cihaz üzerindeki modelleri zorla kurar — metin gömlemeleri (~90 MB), konuşmacı ayrıştırma (~35 MB) ve seçilen konuşma modeli (varsayılan olarak Parakeet TDT v3, ~600 MB; Whisper varyantları 198–626 MB) — gömülü bir code-server derlemesini de kurar ve her ajan konuşması, üzerinde çalıştığı depoların copy-on-write bir worktree’sini alır (Windows’ta düz git worktree). Konuşma isteğe bağlı değildir: ASR modeli olmadan toplantı ve dikte işlemleri sunulmaz. Konuşma modelinin ilk indirmesi, kayıt devreye girmeden önce yine bir yeniden başlatma gerektirir.

Masaüstü, sunucusunu işletim sisteminin kullanıcı başına uygulama destek dizinine yönlendirir. Elle başlatılan ve --data-dir verilmeyen bir cc_server varsayılan olarak <application data>/control-center dizinini kullanır — macOS’ta ~/Library/Application Support/control-center, Windows’ta %APPDATA%\control-center, Linux’ta $XDG_DATA_HOME/control-center (ya da ~/.local/share/control-center).

Aşağıdaki her yapıt GitHub Releases sayfasından gelir.

Control-Center-<version>-arm64.dmg dosyasını indirin, açın ve Control Center’ı Applications klasörüne sürükleyin. Derleme bir Developer ID ile imzalanmış ve Apple tarafından noterlenmiştir, bu yüzden normal şekilde açılır.

  • Control-Center-<version>-x64-setup.exe: kullanıcı başına bir yükleyici.
  • Control-Center-<version>-windows-x64.zip: taşınabilir bir zip.
  • Control-Center-<version>-arm64-setup.exe: kullanıcı başına bir yükleyici.
  • Control-Center-<version>-windows-arm64.zip: taşınabilir bir zip.

Windows, alanların checkout’ları için git worktree kullanır (copy-on-write yoktur).

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

AppImage güncelleme bilgisi taşır, bu yüzden AppImageUpdate ya da appimaged onu yerinde en son sürüme getirebilir ve yalnızca değişenleri indirir.

İkisi de Ubuntu 22.04 üzerinde derlenmiştir ve orada ya da daha yeni her şeyde çalışır (Debian 12, Fedora 36 ve sonrası): glibc 2.35’e ve GCC 12’nin libstdc++’ına bağlanır ve GTK 3’ü sistemden alır. Stok bir masaüstünde eksik olabilecek birkaç kitaplık beraberinde gelir, dolayısıyla başka hiçbir şey kurmak gerekmez. Ses — toplantı oynatımı, ses manzarası, rig sesi ve bildirim sesleri — sistemin libmpv’si üzerinden çalınır (Ubuntu 22.04’te libmpv1, daha yeni Ubuntu ve Debian’da libmpv2, Fedora’da mpv-libs); o olmadan uygulama bu denetimler gizli olarak başlar.

Her sürüm, headless sunucuyu ayrıca tek başına da taşır — 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 — GHCR’deki cc-server, cc-webapp ve cc-remote imajlarının yanı sıra. Bkz. Headless bir sunucu çalıştırma.

Linux arşivi Ubuntu 22.04 üzerinde derlenmiştir ve beraberindeki yerel kitaplıklar glibc 2.35 ile GCC 12’nin libstdc++’ına bağlanır, bu yüzden en az o kadar yeni bir ana makine gerektirir (Ubuntu 22.04, Debian 12, Fedora 36 ya da sonrası). Daha eski bir dağıtımda bunun yerine cc-server imajını çalıştırın — bir konteyner kendi userland’ini getirir, dolayısıyla sizin olması gereken tek şey çekirdektir.

Control Center, ajanları adaptörler aracılığıyla gönderir. İki tanedir, liste sabittir ve otomatik algılanırlar — bir yenisini kaydetmenin yolu yoktur.

Control Center (built-in) adaptörü harici bir CLI gerektirmez: ajan döngüsü sunucunun içinde çalışır ve model sağlayıcılarıyla HTTP üzerinden konuşur, bu yüzden her zaman kullanılabilir. Bir sağlayıcıyı Ayarlar → Sunucu → Model sağlayıcıları altında bağlayın. OpenAI, Codex, Cursor ve Kimi Code tarayıcıda oturum açma sunar; Anthropic, OpenRouter, Google Gemini, DeepSeek, Mistral, xAI, z.ai ve Moonshot ise bir API anahtarı alır. Codex ile Cursor bu runner üzerinde sağlayıcıdır, ayrı CLI’ler değildir. z.ai kasıtlı olarak iki kez listelenir: z.ai kullandıkça öde esaslı açık platformdur ve hesap bakiyenizden faturalandırılır; z.ai GLM Coding Plan ise aboneliktir. Aynı hesap anahtarıdır, ancak z.ai planı farklı bir ana makineden sunar — kodlama planı anahtarını düz z.ai kutucuğuna yapıştırırsanız her istek 429 … "Insufficient balance or no resource package" ile döner, çünkü planın harcayacak bir bakiyesi yoktur. Bir Claude Pro/Max aboneliği Anthropic API oturumu değildir; o plana bunun yerine Claude Code adaptörü üzerinden ulaşın. O sayfada ekleyebileceğiniz şey bir özel sağlayıcıdır — Özel sağlayıcılar → Sağlayıcı ekle altında OpenAI ya da Anthropic uyumlu herhangi bir uç nokta (Ollama, LM Studio, vLLM, özel bir kurulum).

Diğer adaptör harici bir CLI’yi sarar:

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

Algılama, cc_server’ı çalıştıran makinenin PATH’ini yoklar — masaüstü kendi sunucusunu çalıştırıyorsa aynı makine, aksi halde uzak ana makine. Claude Code CLI’yi istemciye değil oraya kurun. O sayfadaki Yenile düğmesi yoklamayı yeniden çalıştırır.

Model listeleri her bağlı sağlayıcı tarafından canlı olarak sunulur; models.dev yalnızca fiyat ve bağlam penceresi meta verilerini sağlar. Bkz. Adaptörleri ve modelleri yönetme.

Bir GitHub kimlik bilgisi size aittir ve sunucuda yaşar, kullanıcı kimliğinize göre anahtarlanır — istemci işletim sisteminin anahtarlığında değil. Oturum açtığınız her cihaz aynı kimlik bilgisini kullanır ve başka hiçbir üye onu okuyamaz.

Sunucuda kayıtlı bir GitHub App varsa (GitHub App oluşturma), Ayarlar → Çalışma alanı → Profil ve kimlik → Kod barındırma size GitHub ile oturum aç seçeneğini sunar (sunucunun yürüttüğü bir cihaz akışı). Aksi halde kişisel bir erişim token’ı yapıştırın:

  • Classic: repo ve read:org
  • Fine-grained: Contents ve Pull requests (okuma ve yazma), Checks ile Actions (okuma)

Bir tane GitHub → Settings → Developer settings → Personal access tokens adresinde oluşturun. Sunucu, token’ı saklandığı hâliyle hesap adı için yoklar, böylece satır “… olarak oturum açıldı” diyebilir; başarısız bir yoklama token’ı yine de kaydeder ve bir yazım hatası ya da eksik kapsam sonradan başarısız bir istek olarak ortaya çıkar.

Onboarding’in ilk adımı bu bağlantıdır. Sonrasında aynı kart, onu değiştirdiğiniz ya da temizlediğiniz yerdir. GitLab ve Bitbucket aynı kartı kullanır; bkz. Bir kod barındırıcısı bağlama.

Control Center, veritabanına sahip olan ve tüm işi yapan headless bir cc_server süreci üzerinde ince bir istemcidir; Dağıtım ve istemciler bu ayrımın masaüstü, web ve telefon için ne anlama geldiğini açıklar.

Masaüstü ilk açılışta şunu sorar: “Control Center nasıl çalışsın?”:

  • Bu uygulamada çalıştır: masaüstü bu makinede bir cc_server başlatır ve onu denetler, onunla loopback üzerinden konuşur. Yapılandırılacak başka bir şey yoktur. Hızlı başlangıç sayfasının varsaydığı kurulum budur.
  • Uzak bir örneğe bağlan: masaüstünü başka bir yerde çalışan bir cc_server sunucusuna WebSocket URL’si, bir cihaz kimliği ve ya bir eşleştirme anahtarı ya da tek kullanımlık bir davet koduyla yönlendirin. Verilere o sunucu sahiptir; bu masaüstü yalnızca onu çizer.

Sunucuları sonradan Ayarlar → Sunucu → Bağlantı ve durum altında ekleyebilir ya da değiştirebilirsiniz. Geçiş yapmak yerinde yeniden bağlanır — yeniden başlatma yoktur. Bir tarayıcı sunucu çalıştıramaz, bu yüzden web istemcisi her zaman uzaktır; bkz. Uzak bir sunucuya bağlanma.

Bir sunucuyu kendiniz barındırmak için Headless bir sunucu çalıştırma sayfasını izleyin. İkili dosyayı derlemeyi, ilk başlatmadan önce bir eşleştirme anahtarı üretmeyi ve --data-dir / --port / --bind bayraklarını anlatır.

  1. Ayarlar → Sunucu → Model sağlayıcıları her iki adaptörü listeler. “Control Center (built-in)” built-in sürümüyle bulundu olarak görünür; Claude Code ise CLI’si sunucu ana makinesinin PATH’inde olduğunda bulundu olarak görünür. Eksikse Yenile’ye basın.
  2. Ayarlar → Çalışma alanı → Depolar bu çalışma alanının depolarını listeler ve Depo ekle, sunucu ana makinesinin klasörlerine göz atar.
  3. Ayarlar → Çalışma alanı → Ajanlar ilk çalışma alanınızın oluşturduğu beş ajanı listeler. Her birinin çalışabilmesi için önce bir Adaptör ve bir Model ayarlanmış olmalıdır.
  4. Ayarlar → Sunucu → Tanılama ve gizlilik bu ana makinenin sunduğu sandbox arka uçlarını, gömme modelinin durumunu ve günlüklemeyi bildirir.

Yerel kitaplıklar zorunludur ve düşürülmüş bir mod yoktur: eksik bir kitaplık yavaş bir yol değil, sert bir başlatma hatasıdır. Onları her şeyden önce hazırlayın. Her Flutter ve Dart komutu fvm üzerinden geçer, çünkü SDK sürümü depo tarafından sabitlenmiştir.

Terminal penceresi
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’ta güvenli depolama (GitHub, Linear ve Google oturum açma) uygulamanın bir Apple ekibi tarafından imzalanmasını gerektirir — ücretsiz bir Apple ID yeterlidir ve bu, yerel geliştirme imzalaması altında açıklanan tek seferlik bir kurulumdur. O olmadan uygulama yine de açılır; yalnızca güvenli depolama kullanılamaz. Windows ve Linux imzalama gerektirmez.

Headless sunucu ikili dosyasını derlemek için önce yerel kitaplıkları aynı şekilde hazırlayın, sonra:

Terminal penceresi
cd apps/cc_server
fvm dart build cli

Derleme kancası, build/natives/ içinde hâlihazırda ne varsa pakete kopyalar; bu yüzden yerel kitaplıkları hazırlamadan derlemek, içinde yerel kitaplık bulunmayan bir paket ve başlamayı reddeden bir sunucu üretir.

Web istemcisi için scripts/build_web.sh kullanın (telefon PWA’sı için --target remote). CI’ın çalıştırdığı şey budur: düz bir flutter build web, derleme kimliği damgasını, Web Worker yeniden üretimini, dağıtım bildirimini ve varlık bütçesi denetimini atlar.