Jede Diskussion über KI-Coding-Agents stößt irgendwann auf dieselbe praktische Frage – meist später als nötig: Wo läuft der Code eigentlich? Nicht, welches Modell zum Einsatz kommt, sondern welche Maschine Ihr Repository, Ihre Zugangsdaten, Ihre Caches und die Shell beherbergt, in die der Agent tippt.
Sharkly macht diese Antwort zu einem eigenständigen Konzept namens Computer. Ein Computer stellt den Ausführungs-Host für Agent-Arbeit bereit. Dabei kann es sich um einen lokalen Rechner, einen Remote-Server, einen Container oder einen unterstützten Cloud-Host handeln. Ihr Laptop zählt dazu. Genauso wie die Linux-Kiste in Ihrem Rack. Sie wählen den Host, Sie kontrollieren ihn, und Sharkly koordiniert die Arbeit dorthin, statt Ihren Code irgendwo auszuführen, wo Sie nicht hinsehen können.
Sharkly ist kein Ersatz für Claude Code, Codex oder andere Ausführungstools. Es ergänzt die Tools, die Ihr Team bereits nutzt, um eine gemeinsame Ebene für Task, Computer, Kontext, Steuerung und Review. Diese Tools bleiben auf Ihren Maschinen installiert, und die Modellnutzung läuft weiterhin über die Abonnements oder API-Keys, die darin konfiguriert sind.
TL;DR
Ein Computer ist der Ausführungs-Host für Agent-Arbeit in Sharkly: ein lokaler Rechner, ein Remote-Server, ein Container oder ein unterstützter Cloud-Host, den Sie kontrollieren. Ein kleiner lokaler Dienst verbindet den Computer mit Sharkly, erkennt verfügbare Runtimes (die dort installierten konkreten Agent-Tools wie Claude Code oder Codex), empfängt in die Warteschlange gestellte Runs, bereitet das Task-Verzeichnis vor, startet die ausgewählte Runtime und streamt den Fortschritt zurück an den Task. Verbinden Sie einen privaten Rechner über Sharkly Desktop oder einen Remote-Host über die Sharkly CLI und ein einmaliges Installations-Token. Die Modellnutzung läuft über die Abonnements und API-Keys, die bereits in Ihren Tools konfiguriert sind; Concurrency-Limits entscheiden, wie viel parallele Arbeit ein Host trägt.
Was ein Computer ist – und was nicht
Sharkly teilt die Ausführung in vier Rollen auf, von denen jede genau eine Aufgabe hat:
- Der Agent legt fest, wie Arbeit behandelt werden soll: Anweisungen, Skills, Repositories, Run-Einstellungen.
- Der Computer stellt den Host und die lokalen Ressourcen bereit: Betriebssystem, Dateien, Zugangsdaten, Netzwerk, Tools.
- Die Runtime führt die eigentliche Agent-Sitzung aus: das auf diesem Computer erkannte Coding-Tool.
- Der Task bleibt der gemeinsame Datensatz: Ziel, Diskussion, Ausführungsstatus, Trace, Ergebnis.
Diese Trennung erklärt den Großteil des Folgenden. Ein Agent ist nicht der Ausführungs-Host; dieselbe Agent-Konfiguration kann mit der Zeit auf verschiedene Computer zeigen. Ein Computer ist kein Agent; er hält eine oder mehrere Runtimes und tut nichts, bis Arbeit an ihn verteilt wird. Und ein einzelner Computer kann mehrere Agents gleichzeitig bedienen, begrenzt durch sein Concurrency-Limit.
Das erklärt auch das Versprechen. Gehostete Plattformen bündeln Modell, Runner und Infrastruktur in einem Produkt – Ihr Code läuft also auf Infrastruktur, die Sie nicht selbst betreiben. Sharkly vertritt die andere Position: Der Ausführungs-Host gehört Ihnen, und was obendrauf kommt, sind Zuweisung, Warteschlange und Review. Wenn Sie mit diesem Modell noch nicht vertraut sind, finden Sie in Was Sharkly ist das Gesamtbild.
Der lokale Dienst: das Stück, das die eigentliche Arbeit macht
Ein kleiner lokaler Dienst verbindet jeden Computer mit Sharkly. Er registriert den Computer, erkennt installierte Runtimes, sendet Heartbeats, empfängt in die Warteschlange gestellte Runs, bereitet Task-Verzeichnisse vor, startet das ausgewählte Agent-Tool und meldet Fortschritt und Ergebnisse zurück.
Ein Designdetail hat großes operatives Gewicht: Der lokale Dienst baut die Verbindung zum Server selbst auf, sodass ein typisches Setup keinen eingehenden Port benötigt. Genau das macht einen Laptop hinter einem Heimrouter, eine Workstation hinter einer Unternehmens-Firewall und einen Server in einem privaten Subnetz gleichermaßen zu geeigneten Computern.
Heartbeats sind der Weg, über den Sharkly weiß, dass ein Computer läuft: Online, wenn der Server sie empfängt, Offline, wenn sie ausbleiben. Die Abgrenzung, die bei der Fehlersuche Zeit spart: Online heißt nur, dass Heartbeats ankommen. Es heißt nicht, dass die ausgewählte Runtime einen Task ausführen kann.
Runtimes: Was Ihr Computer tatsächlich ausführen kann
Eine Runtime ist eine unterstützte Agent-Ausführungsfähigkeit, die auf einem Computer erkannt wurde. Der lokale Dienst sucht nach unterstützten Agent-Tools und meldet jedes nutzbare – ein Computer mit installiertem Claude Code und Codex stellt also beide als Runtimes bereit, die ein Agent auswählen kann.
Die Detailseite des Computers meldet für jede Runtime einen Fähigkeitsstatus:
- Available: Die Runtime ist verbunden und kann Agent-Arbeit ausführen.
- Needs configuration: Das Tool wurde erkannt, aber die erforderliche Konfiguration fehlt.
- Not installed: Das Tool ist für den lokalen Dienst nicht verfügbar; installieren Sie es oder wählen Sie eine andere Runtime.
- Unsupported: Die Runtime oder Umgebung liegt außerhalb des unterstützten Fähigkeitssatzes.
Die Installation bleibt bewusst Ihre Aufgabe. Sie installieren und authentifizieren jedes Tool genauso wie bei der direkten Nutzung; die Detailseite des Computers verlinkt die offizielle Installationsanleitung, und ein erneuter Scan bestätigt, dass der lokale Dienst es sehen kann. Wenn eine Fähigkeit, auf die Sie angewiesen sind, nicht erkannt wird, können Sie eine benutzerdefinierte ACP-Runtime mit Namen und Startbefehl hinzufügen und die Verbindung anschließend testen.
Daraus folgen zwei Konsequenzen. Die Rede von „bring your own subscription“ ist wörtlich gemeint: Das Modellkontingent hängt von den KI-Coding-Tools, Tarifen und API-Konten ab, die Ihr Team verbindet – ein Kontingentfehler verweist also auf das im Tool konfigurierte Konto, nicht auf eine Sharkly-Einstellung. Und die Modellauswahl liegt beim Tool: Ein Agent folgt dem Standardmodell seiner Runtime. Wie Agents konfiguriert werden, behandelt Agents in Sharkly.
Den ersten Computer verbinden
Der erste Computer ist meist der Rechner, an dem Sie gerade sitzen. Öffnen Sie die Einstellungen, wechseln Sie zu Computers, wählen Sie Connect Computer und entscheiden Sie sich für den Setup-Pfad Ihres Betriebssystems. Bei einem unterstützten privaten Rechner ist der empfohlene Weg die Installation von Sharkly Desktop, das den lokalen Dienst enthält und durch die Registrierung führt. Der Einstiegsleitfaden führt das in rund zehn Minuten von Anfang bis Ende durch.
Sobald die Verbindung steht, prüfen Sie, dass mindestens eine Runtime als Available gemeldet wird. Genau diesen Checkpunkt lassen viele aus: Ein verbundener Computer ohne nutzbare Runtime kann keine Agent-Arbeit ausführen.
Für Laptops sind zwei Einstellungen relevant, die es nur im Desktop-Client gibt. Prevent sleep hält die Maschine wach, damit ein langer Run nicht unterbrochen wird, und Keep running with lid closed ist eine separate macOS-Option. Beide erscheinen nur auf der lokalen Maschine, niemals auf einem Remote-Computer.
Einen Remote-Server hinzufügen
Ein Laptop ist ein guter erster Computer und ein schlechter dauerhafter. Er schläft, reist und konkurriert mit Ihrer IDE um Speicher. Der natürliche zweite Schritt ist ein Remote-Host, der durchgehend läuft. Installieren Sie dort direkt die Sharkly CLI und den lokalen Dienst:
curl -fsSL https://file-assets.sharkly.ai/download/install.sh | bash
sharkly version
Generieren Sie dann auf der Computers-Seite ein einmaliges Installations-Token und führen Sie den angezeigten Registrierungsbefehl auf dem Zielhost aus:
sharkly computer register --install-token sit_...
Die Registrierung erfasst den Computer in Ihrer Organisation, startet den lokalen Dienst und stößt die Runtime-Erkennung an. Das Installations-Token läuft nach 30 Minuten ab und ist nur einmal verwendbar – daraus folgt eine Hygieneregel, die die Doku klar benennt: Packen Sie es nicht in ein wiederverwendbares Image, Skript, einen Task oder einen Kommentar.
Die Zugangsdaten sind hier bewusst getrennt. Ein Personal Access Token registriert keinen Computer, und ein Installations-Token erzeugt kein menschliches CLI-Login. Das Personal Access Token mit dem Präfix shk_ authentifiziert Sie für Ressourcenbefehle wie sharkly task list; das Installations-Token sit_ erstellt die Sitzung, die der lokale Dienst verwendet. Die breitere Befehlsoberfläche behandelt der Leitfaden zur Sharkly CLI und API.
Nach der Registrierung dient dieselbe CLI als Diagnosewerkzeug: sharkly computer status und sharkly computer logs lesen den lokalen Zustand auf dem Host aus, während sharkly computer list, show, usage und ping registrierte Computer von überall aus inspizieren. Der Remote-Host braucht dieselben Dinge wie Ihr Laptop: installierte und authentifizierte Agent-Tools sowie Git-Zugriff für private Repositories.
Lokal, remote oder Container: ein ehrlicher Vergleich
Es gibt nicht den einen richtigen Host. Die Doku behandelt alle als Computer, und die Abwägungen sind die ganz normalen Infrastruktur-Abwägungen.
| Host | Am besten für | Stärken | Worauf achten |
|---|---|---|---|
| Lokaler Rechner (Sharkly Desktop) | Erstes Setup, Solo-Arbeit, Runs mit angegebenem Verzeichnis, die Ihren bestehenden Checkout und Ihre Caches wiederverwenden | Keine zusätzliche Infrastruktur; Ihre exakte Umgebung und Ihre Zugangsdaten; angegebene Arbeitsverzeichnisse gibt es nur auf lokalen Computern | Schlafmodus und Herunterfahren unterbrechen die Verfügbarkeit; Runs konkurrieren mit Ihrer eigenen Arbeit um CPU und Speicher |
| Remote-Server (CLI + lokaler Dienst) | Team-Workloads, durchgehende Verfügbarkeit, höhere Concurrency | Bleibt online; entkoppelt die Agent-Last von den Laptops aller Beteiligten; ein Host kann mehrere Agents bedienen | Sie installieren und authentifizieren Runtimes und Git-Zugriff selbst; die Kapazitätsplanung liegt bei Ihnen |
| Container oder unterstützter Cloud-Host | Reproduzierbare, wegwerfbare Ausführungsumgebungen | Saubere, neu aufbaubare Umgebung; derselbe Registrierungsablauf über Installations-Token | Das einmalige Token muss pro Registrierung erzeugt werden und darf niemals in ein wiederverwendbares Image eingebacken werden |
Das wichtigste Entscheidungspaar: Nutzen Sie Ihren lokalen Computer, wenn Agents in der Umgebung arbeiten sollen, der Sie bereits vertrauen; nutzen Sie einen Remote-Computer, wenn Tasks weiterlaufen sollen, während Ihr Laptop zugeklappt ist. Viele Teams landen am Ende bei beidem, denn Arbeit auf einen anderen Host zu leiten ist eine Konfigurationsänderung, keine Workflow-Änderung.
Was während eines Runs passiert
Wenn ein einem Agent zugewiesener Task bereit wird, stellt Sharkly einen Run in die Warteschlange und verteilt ihn an den ausgewählten Computer. Bevor die Runtime startet, wartet der lokale Dienst gegebenenfalls auf freie Concurrency-Kapazität, bereitet ein Verzeichnis vor, holt die Repositories und projiziert die erlaubten Umgebungsvariablen.
Die Verzeichnisvorbereitung folgt einem von zwei Modi. Im Modus Temporary bekommt jeder Task ein isoliertes Verzeichnis, und repository-gestützte Runs können aus zwischengespeicherten Repository-Daten einen frischen Git-Worktree anlegen; nutzen Sie ihn für die meiste Repository-Arbeit und immer dann, wenn mehrere Tasks dieselbe Codebasis parallel verändern könnten, wie in wie Sharkly Agents parallel ohne Merge-Konflikte ausführt beschrieben. Im Modus Specified verwendet der Run ein konfiguriertes absolutes Verzeichnis auf einem lokalen Computer wieder, samt der darin bereits vorhandenen Abhängigkeiten und Caches, und ein angegebenes Verzeichnis bedient jeweils einen Run gleichzeitig.
Während die Runtime arbeitet, wird der Fortschritt zurückgestreamt. Der Run-Status durchläuft Queued, Dispatched, Waiting for local directory und Running und endet dann bei Completed, Failed oder Canceled. Trace-Events, Tool-Aufrufe und die abschließende Antwort landen alle im Task. Der Computer ist der Ort, an dem die Ausführung physisch stattfindet; der Task ist der Ort, an dem die Abnahme erfolgt.
Concurrency: Wie viel sollte ein Computer tragen?
Jeder Computer hat ein Task-Concurrency-Limit, und jeder Agent hat sein eigenes Maximum für parallel laufende Tasks. Die Standardwerte sind bewusst konservativ: Ein Agent mit temporären Verzeichnissen startet mit 50 % des Computer-Limits, und einer mit angegebenen Verzeichnissen startet mit seiner konfigurierten Verzeichnisanzahl. Setzen Sie manuell einen Wert darüber, warnt das Produkt, dass Schreibvorgänge kollidieren können. Nehmen Sie die Warnung ernst.
Folgen Sie der Empfehlung der Doku: Höhere Concurrency verbraucht mehr CPU, Speicher, Festplatte, Provider-Kapazität und Repository-Bandbreite – erhöhen Sie sie erst, wenn das aktuelle Setup die bestehende Last zuverlässig bewältigt. Die Provider-Kapazität ist die Obergrenze, die viele vergessen: Zehn parallele Runs über ein Modellkonto erreichen dessen Rate Limits zehnmal schneller. Zu Skalierungsmustern siehe mehrere Claude-Code-Agents parallel ausführen.
Ein Online-Agent kann trotzdem Arbeit in der Warteschlange haben, einfach weil die Concurrency- oder Verzeichnis-Kapazität ausgeschöpft ist. Queued ist ein gesunder Zustand, kein festgefahrener.
Teilen, Eigentümerschaft und den Host sauber halten
Sobald ein Computer Teamaufgaben übernimmt, sind drei Kontrollen wichtig. Die Sichtbarkeit entscheidet, wer ihn sehen und nutzen kann: Personal, Organization oder Space. Die Eigentümerschaft ist davon getrennt: Der Eigentümer kann den Computer übertragen und ist die einzige Person, die ihn löschen kann. Und bei einem lokalen persönlichen Computer steuert der Eigentümer, welche Organizations ihn überhaupt nutzen dürfen – der Beitritt zu einer neuen Organisation gibt Ihren Laptop also nie stillschweigend mit frei.
Agent-Runs hinterlassen Arbeitsverzeichnisse, Caches und Artefakte, deshalb ist die Bereinigung eingebaut. Sie macht abgeschlossene oder abgebrochene Runs standardmäßig nach etwa 7 Tagen löschbar, kann einen Mindestwert für freien Speicherplatz erzwingen und rührt laufende oder wartende Arbeit, gepinnte Runs oder fehlgeschlagene Runs, die noch untersucht werden, nie an. Für eine sofortige Prüfung meldet sharkly daemon disk-usage die Nutzung und zeigt sharkly daemon cleanup eine Vorschau, was freigegeben würde.
Fangen Sie mit der Maschine an, die Sie haben
Das Computer-Konzept beantwortet eine Frage, die gehostete Plattformen lieber nicht von Ihnen hören: Auf wessen Infrastruktur läuft der Agent? Hier lautet die Antwort: auf Ihrer – vom einzelnen Laptop bis zum geteilten Serverpark. Den Serverpark brauchen Sie nicht am ersten Tag. Verbinden Sie einen Computer, prüfen Sie, dass eine Runtime als Available angezeigt wird, erstellen Sie einen Agent und weisen Sie ihm etwas Langweiliges zu. Wenn die Grenzen des Laptops sichtbar werden, registrieren Sie einen Server daneben. Die Sharkly-Dokumentation behandelt jede Einstellung hier ausführlicher.
FAQ
Was ist ein Computer in Sharkly?
Ein Computer ist der Ausführungs-Host für Agent-Arbeit: ein verbundenes Gerät, ein Server oder ein Container, der das Betriebssystem, die Dateien, Zugangsdaten, den Netzwerkzugang und die Tools bereitstellt, die ein Agent braucht. Ein kleiner lokaler Dienst verbindet ihn mit Sharkly, erkennt Runtimes, empfängt Runs und streamt den Fortschritt zurück an den Task.
Führt Sharkly meinen Code in einer eigenen Cloud aus?
Nein. Agent-Arbeit läuft auf den Computern, die Sie verbinden – also auf Maschinen, die Sie kontrollieren. Sharkly koordiniert Zuweisung, Warteschlange, Fortschritt und Review rund um diese Hosts. Auch die Modellnutzung bleibt Ihre: Sie läuft über die Abonnements oder API-Keys, die in den auf jedem Computer installierten Coding-Tools konfiguriert sind.
Wie verbinde ich einen Remote-Server als Computer?
Installieren Sie die Sharkly CLI auf dem Host, erzeugen Sie auf der Computers-Seite ein einmaliges Installations-Token und führen Sie sharkly computer register --install-token sit_... auf dieser Maschine aus. Das Token läuft nach 30 Minuten ab und funktioniert nur einmal – backen Sie es deshalb niemals in ein Image oder Skript ein. Installieren und authentifizieren Sie anschließend die gewünschten Agent-Tools und prüfen Sie, dass jede Runtime als Available angezeigt wird.
Warum zeigt mein Computer Online an, aber der Run startet nicht?
Online heißt nur, dass der lokale Dienst Heartbeats sendet; es heißt nicht, dass die ausgewählte Runtime Arbeit ausführen kann. Öffnen Sie die Computer-Detailseite und prüfen Sie den Fähigkeitsstatus der Runtime: Needs configuration und Not installed blockieren beide Runs. sharkly computer ping bestätigt, ob eine bestimmte Runtime einen Round Trip abschließt.
