Externe Agenten

Tale liefert integrierte externe Agenten — Claude Code, Cursor, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi und OpenClaw —, deren gesamte Runde in einer isolierten Sandbox läuft. Statt der normalen Chat-Schleife wird deine Nachricht an diesen Coding-Agenten übergeben, der in einem frischen Container lebt, Dateien bearbeitet, Befehle ausführt und zurückmeldet. Du sprichst im Chat direkt mit ihm, und er behält dasselbe Arbeitsverzeichnis und denselben Gesprächsverlauf über mehrere Runden, sodass eine Folgeanweisung wie „füge jetzt einen Test dafür hinzu" dort weitermacht, wo er aufgehört hat.

Es ist dieselbe Idee, als würde man ein solches Werkzeug auf einer entfernten Maschine ausführen — nur ist die Maschine eine verwaltete Sandbox, die der Workspace kontrolliert. Diese Seite behandelt, wie du sie nutzt, was die Sandbox erreichen kann und was nicht, und wie abgerechnet wird.

Mit einem Coding-Agenten sprechen

Wähle im Chat-Auswahlmenü Claude Code, Cursor, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi oder OpenClaw und beschreibe eine Aufgabe in normaler Sprache — „schreibe ein kleines Python-CLI und teste es", „klone dieses Repo und behebe den Fehler in Issue #42". Der Agent arbeitet in seiner Sandbox: Er plant, schreibt Dateien, führt Shell-Befehle aus und installiert bei Bedarf Pakete, dann antwortet er mit dem, was er getan hat. Während er arbeitet, siehst du eine Denkanzeige; die Antwort erscheint, wenn die Runde abgeschlossen ist.

Du musst nicht warten, bis eine Runde fertig ist. Das Eingabefeld bleibt offen, während der Agent arbeitet: Alles, was du sendest, wartet im Bereich Wartende Nachrichten über dem Eingabefeld und wird dem laufenden Agenten bei nächster Gelegenheit übergeben. Claude Code übernimmt das mitten in der Runde an der nächsten Werkzeuggrenze — eine Korrektur wie „nimm pnpm statt npm" landet also, während die Arbeit noch läuft. Cursor, OpenCode, Codex, Pi, OpenClaw und andere One-Shot-Laufzeiten leeren die Warteschlange dagegen an Rundengrenzen. In den Thread selbst gelangt die Nachricht erst bei dieser Übernahme, genau an der Stelle, an der sie gewirkt hat; bis dahin lässt sie sich entfernen (das × in ihrer Zeile). Mit Stopp beendest du die aktuelle Runde; noch wartende Nachrichten werden wenige Sekunden später automatisch als nächste Runde gesendet, mit unverändertem Kontext des Agenten.

Jeder Chat-Thread wird von einer dauerhaften Sandbox-Sitzung getragen. Folgenachrichten verwenden dieselbe Sitzung und dieselben Dateien wieder, und der Agent setzt seine frühere Überlegung fort, statt bei null zu beginnen. Weil die Sitzung dem Thread gehört, behält der Thread auch seinen Agenten: Die Agentenauswahl bleibt darauf fixiert, und ein Agentenwechsel an anderer Stelle leitet diesen Thread nie um — starte einen neuen Chat, um einen anderen zu verwenden. Wird der Thread gelöscht oder archiviert, wird die Sandbox abgebaut und ihre Ressourcen werden freigegeben.

Was die Sandbox erreichen kann

Die Sandbox startet mit einem leeren Arbeitsverzeichnis und ist standardmäßig abgeriegelt. Dateien und Ordner, die du in deiner Nachricht mit @ anheftest, werden unter /user/uploads/ in die Sandbox geliefert, sodass der Agent die echten Bytes öffnet, statt aus einem Retrieval-Schnipsel zu arbeiten. Ausgehender Netzwerkverkehr ist bis auf eine kleine Erlaubnisliste (Paket-Registries und GitHub) gesperrt, sodass der Agent Abhängigkeiten installieren und öffentliche Repositorys klonen, aber keine beliebigen Hosts erreichen kann. Standardmäßig wird das Modell über das Gateway des Workspace angesprochen, nie über einen rohen Provider-Schlüssel — die Sandbox hält für eine Runde nur einen kurzlebigen, budgetbegrenzten Schlüssel. Das ist der verwaltete Anmeldedaten-Modus des Agenten; die Eigene-Anmeldedaten-Alternative, die weiter unten behandelt wird, legt bewusst stattdessen deinen eigenen Provider-Schlüssel in die Box.

Über diese Abriegelung hinaus kann der Agent jede Integration nutzen, die deine Organisation verbunden hat — das Web über Tavily durchsuchen, eine API aufrufen, eine Datenbank abfragen —, solange diese Integration an den Agenten gebunden ist. Du bindest sie genauso wie bei jedem anderen Agenten: Öffne den Tools-Tab des Agenten und wähle sie unter Gebundene Integrationen aus. Die Anmeldedaten gelangen dabei nie in die Sandbox; ruft der Agent eine Integration auf, geht die Anfrage an Tale zurück, das den Aufruf mit den gespeicherten Anmeldedaten ausführt und nur das Ergebnis zurückgibt — ein kompromittierter Container kann deine Schlüssel also nicht auslesen. Ein Schreibvorgang läuft nicht stillschweigend ab: Er erscheint als Genehmigungskarte im Chat und wird ausgeführt, sobald du ihn genehmigst.

Auch die Daten des Workspace selbst laufen über diesen vermittelten Weg. Auf demselben Tools-Tab kannst du zusätzlich Plattform-Tools freigeben — Wissenssuche, das Durchsehen und Lesen von Dokumenten, das Speichern von Dateien im Dokumenten-Hub —, und der Agent ruft sie während der Arbeit aus der Sandbox heraus auf. Jeder Aufruf läuft auf der Plattform im Wissensbereich des Agenten und liefert nur das Ergebnis zurück; die Sandbox hält also auch keine Plattform-Anmeldedaten, und ein Speichern im Hub erzeugt dieselbe Genehmigungskarte wie jeder andere Schreibvorgang. Nicht freigegebene Tools sind nicht aufrufbar, und ein BYO-Agent, der ohne Sitzungsschlüssel läuft, hat gar keine Tool-Brücke.

GitHub ist die Ausnahme, bei der auch ein Token in die Sandbox gelangt, weil git und das gh-CLI es lokal brauchen: Verbinde GitHub unter Integrationen und binde es an den Agenten, dann erhält die Sitzung ein begrenztes Token, mit dem der Agent in deinem Namen klonen, pushen und Pull Requests öffnen kann. Alle Anmeldedaten — das GitHub-Token in der Sandbox ebenso wie die vermittelten — sind auf die Sitzung beschränkt, werden bei jedem Aufruf auditiert und beim Ende der Sitzung widerrufen.

Verwaltete und eigene Anmeldedaten

Wie der Agent sein Modell erreicht, ist eine Entscheidung pro Agent, die du im Anweisungen-Tab des Agenten unter Anmeldedaten triffst. Drei Anmeldedaten-Backends existieren; die UI benennt sie nach der Laufzeit des Agenten.

Gateway-verwaltet (Claude Code, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi und OpenClaw, verwaltet) ist die Voreinstellung für diese Laufzeiten. Die Plattform prägt für die Runde einen kurzlebigen virtuellen Schlüssel, leitet den Agenten über ihr Gateway, erzwingt die erlaubten Modelle des Agenten aus dem Providers-Katalog, erfasst die Nutzung und wendet die Ausgabengrenzen der Organisation an. Die Sandbox hält nie einen echten Provider-Schlüssel. Verwaltete Hermes- und Codex-Runden laufen über eine OpenAI-kompatible Gateway-Route (OPENAI_BASE_URL plus virtueller Sitzungsschlüssel in der Sandbox; Codex spricht darüber die OpenAI-Responses-API); verwaltete Gemini-CLI-Runden über die Google-GenAI-kompatible Route des Gateways (GOOGLE_GEMINI_BASE_URL plus der virtuelle Sitzungsschlüssel als GEMINI_API_KEY); verwaltete Pi-Runden ebenfalls über die OpenAI-kompatible Route, verdrahtet als Pi-Provider-Konfiguration pro Runde, die den virtuellen Sitzungsschlüssel aus der Umgebung referenziert (die Konfigurationsdatei enthält den Schlüssel nie); verwaltete OpenClaw-Runden über die OpenAI-kompatible Route des Gateways mittels einer pro Runde erzeugten Provider-Konfiguration.

Env-verwaltet (Cursor, verwaltet) gilt für Laufzeiten, die sich mit einem API-Schlüssel authentifizieren, den du am Agenten hinterlegst, nicht über das Gateway. Öffne die Umgebung-Seite des Agenten und setze CURSOR_API_KEY (oder den Schlüssel, den die Laufzeit deklariert). Das Modell ist eine Runtime-ID, die du in der Modelle-Liste unter Anweisungen eintippst — composer-2.5 etwa —, kein Katalogeintrag. Diese Runden fließen nicht in die Nutzungsanalyse ein; die Abrechnung liegt bei deinem Cursor-Konto.

Eigene Anmeldedaten (BYO) nimmt die Plattform aus dem Anfragepfad heraus — für unterstützte Laufzeiten (Claude Code, Cursor, Gemini CLI, Codex, Pi und OpenClaw). OpenCode ist nur verwaltet — seine Laufzeitkonfiguration zeigt auf das Plattform-Gateway und authentifiziert sich mit dem Sitzungs-Virtual-Key; BYO ist für OpenCode-Agenten nicht verfügbar. Es wird kein virtueller Schlüssel geprägt; der Agent authentifiziert sich mit Anmeldedaten, die du unter Umgebungsvariablen & Geheimnisse hinterlegst, und erreicht den Provider direkt. Das Modell wird zu einer rohen Runtime-ID, die du wortwörtlich eintippst, statt zu einem Katalogeintrag. Weil das Gateway umgangen wird, gelten die Modell-Erlaubnisliste, die Ausgabengrenzen und die Nutzungserfassung der Organisation nicht für BYO-Runden — Abrechnung und Limits wandern in dein eigenes Provider-Konto. Wechselst du einen Agenten von verwaltet auf BYO, werden gespeicherte Plattform-Modelle gelöscht, wenn es Katalogverweise waren; du gibst die rohen IDs neu ein.

Das verschiebt auch die Vertrauensgrenze. Im gateway-verwalteten Modus hält die Sandbox nur einen budgetbegrenzten Gateway-Schlüssel; bei env-verwaltet oder BYO wird deine echte Anmeldedaten in die Sandbox-Umgebung eingespeist — dieselbe Lage wie beim GitHub-Token in der Sandbox —, sodass jeder Code, den der Agent in der Box ausführt, sie lesen kann. Das ist Absicht: Es ist deine Box und deine Anmeldedaten. Einen Agenten zu konfigurieren ist ohnehin eine privilegierte Aktion, daher ist der Schalter pro Agent die einzige Stellschraube; es gibt keinen separaten Schalter auf Organisationsebene.

Engines und Modelle

Claude Code, Cursor, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi und OpenClaw sind getrennte Einträge im Chat-Auswahlmenü (oder Agenten, die du mit entsprechend gesetztem agentKind konfigurierst).

Für gateway-verwaltetes Claude Code, OpenCode, Hermes Agent, Gemini CLI, Codex, Pi oder OpenClaw kommt das Modell aus der Liste der unterstützten Modelle des Agenten im Providers-Katalog — wähle es im Modellauswahlmenü. Claude Code und OpenCode werden standardmäßig mit Claude Fable 5 ausgeliefert, und Fable-Kapazität ist rationiert: Markieren die Sicherheitsklassifikatoren eine Anfrage, ist das Modell überlastet oder das Fable-Kontingent erschöpft, schlägt der Zug nicht fehl — die Sitzung fällt automatisch auf das im Katalogeintrag hinterlegte Fallback-Modell zurück, Claude Opus 4.8 (nur Claude Code; OpenCode nutzt die von dir gewählte Gateway-Modell-ID). Hermes Agent, Pi und OpenClaw werden mit Claude Sonnet 4.6 und Claude Opus 4.8 ausgeliefert, Gemini CLI mit Gemini 3 Pro und Gemini 3 Flash, Codex mit GPT-5.5 und GPT-5.5 Pro; sie alle bestreiten die ganze Runde auf dem gewählten Modell — ein automatisches Fallback gibt es dort nicht. Eine OpenClaw-Besonderheit: Seine Laufzeit meldet sich headless erst am Ende der Runde, im Chat siehst du also die fertige Antwort und die Nutzung, keine Werkzeug-für-Werkzeug-Zeitleiste.

Für env-verwaltetes Cursor (und BYO auf jeder Laufzeit) akzeptiert der Modelle-Editor unter Anweisungen Runtime-IDs aus deinem Konto — führe agent models in einer Sandbox-Sitzung aus, um zu sehen, was dein Abo freigibt. Lass die Liste leer, damit die Laufzeit ihr Standardmodell wählt (Auto). Das Chat-Modellauswahlmenü zeigt einen schreibgeschützten Indikator — den Kurznamen der konfigurierten ID oder Standardmodell, wenn die Liste leer ist — statt des Katalog-Dropdowns.

Ein BYO-Hermes-Agent nutzt Anmeldedaten, die du unter Umgebungsvariablen & Geheimnisse hinterlegst — je nach Provider üblicherweise OPENROUTER_API_KEY, OPENAI_API_KEY oder ANTHROPIC_API_KEY. Setze das Modell auf eine Hermes-/OpenRouter-übliche ID (zum Beispiel openrouter:anthropic/claude-sonnet-4.6).

Ein BYO-Gemini-CLI-Agent nutzt deine eigenen Google-Anmeldedaten aus Umgebungsvariablen & Geheimnisse — GEMINI_API_KEY für die Gemini-API oder GOOGLE_API_KEY mit GOOGLE_GENAI_USE_VERTEXAI=true für Vertex AI. Tippe rohe Google-Modell-IDs (zum Beispiel gemini-3.1-pro-preview); die mitgelieferten katalogförmigen Standardwerte werden zur Laufzeit in ihre Google-nativen IDs übersetzt.

Ein BYO-Pi-Agent nutzt Anmeldedaten, die du unter Umgebungsvariablen & Geheimnisse hinterlegst — je nach Provider üblicherweise OPENROUTER_API_KEY, ANTHROPIC_API_KEY oder OPENAI_API_KEY. Setze das Modell auf eine ID aus Pis eigenem Katalog (pi --list-models in einer Sandbox-Sitzung) — zum Beispiel anthropic/claude-sonnet-4.6 mit einem OpenRouter-Schlüssel; die mitgelieferten katalogförmigen Standardwerte werden zur Laufzeit in diese OpenRouter-üblichen IDs übersetzt. Pi hat keine eingebauten Web-Tools; Fakten von außen kommen über die gebundenen Integrationen oder das, was curl auf der Netz-Erlaubnisliste der Sandbox erreicht.

Ein BYO-OpenClaw-Agent nutzt Anmeldedaten, die du unter Umgebungsvariablen & Geheimnisse hinterlegst — je nach Provider ANTHROPIC_API_KEY, OPENAI_API_KEY oder OPENROUTER_API_KEY. Setze das Modell auf eine OpenClaw-übliche provider/model-Referenz (zum Beispiel anthropic/claude-sonnet-4-6) oder lass es leer für den Laufzeit-Standard.

Ein BYO-Codex-Agent nutzt den OPENAI_API_KEY, den du unter Umgebungsvariablen & Geheimnisse hinterlegst, und spricht direkt mit der OpenAI-API. Mitgelieferte Katalogverweise werden über die nativeModelId des Eintrags übersetzt (etwa gpt-5.5); selbst eingegebene IDs bleiben unverändert.

Ein BYO-Claude-Code-Agent tippt rohe Anthropic-IDs — claude-opus-4-20250514 etwa — in Prioritätsreihenfolge. Mitgelieferte Pack-Agenten mit katalogförmigen Verweisen werden zur Laufzeit über nativeModelId des Katalogeintrags übersetzt; selbst eingegebene IDs bleiben unverändert.

Kosten und Budget

Runden externer Agenten können lang sein und das Modell viele Male aufrufen, daher kosten sie mehr als eine einzelne Chat-Antwort. Jede verwaltete Runde läuft gegen ein Pro-Runde-Budget, und die Richtlinien und Limits der Organisation begrenzen die Ausgaben pro Nutzer, pro Team oder pro Agent. Die Nutzung wird wie bei jedem anderen Agenten in der Nutzungsanalyse erfasst und dem externen Agenten zugeordnet, sodass du siehst, was diese Läufe kosten.

Diese Abrechnung gilt nur für den gateway-verwalteten Pfad — also verwaltete Claude-Code-, OpenCode-, Hermes-Agent-, Gemini-CLI-, Codex-, Pi- und OpenClaw-Runden. Env-verwaltete und BYO-Agenten laufen auf Anmeldedaten außerhalb des Gateways: Ihre Runden fließen nicht in die Nutzungsanalyse ein und die Ausgabengrenzen der Organisation greifen nicht; Kosten und Ratenlimits liegen bei deinem Provider-Konto.

Coding-Agenten auf dem Task-Board

In den Einstellungen ist Coding-Agent das Produktlabel für Agenten, deren Chat in einer Sandbox-CLI (Claude Code oder Cursor) läuft, oder deren Task-Dispatch in JSON über runtime (tale-daemon auf deinem Rechner) oder preferDurableStepForTasks (durable Sandbox-Schritt) konfiguriert ist. Das Label allein ändert nicht, wie Board-Tasks laufen — der Dispatch folgt diesen JSON-Feldern, nicht der Chat-Sandbox.

Wenn du einen Coding-Agenten einem Board-Task zuweist, hängt das Ergebnis von der Konfiguration ab:

• Agent (Plattform-Tool-Schleife, keine Sandbox-CLI, kein Task-Runtime) — nutzt Plattform-Tools und postet Ergebnisse als Task-Kommentare.
• Coding-Agent + runtime — Tasks laufen auf deinem Rechner (tale-daemon) in einem Git-Workspace.
• Coding-Agent + preferDurableStepForTasks — Tasks laufen in einem Sandbox-Container; das Ergebnis ist eine Summary-Datei.
• Coding-Agent, nur Sandbox (external-agent-Chat, ohne Runtime oder Durable-Flag) — Chat läuft in einer Sandbox; Board-Tasks nutzen die Plattform-Schleife, bis du einen Daemon bindest oder durable Tasks im Agent-JSON aktivierst.

Der Assignee-Picker zeigt diese Hinweise beim Auswählen. Für Recherche, Texte oder persönliche Deliverables weise eine Person oder einen Plattform-Agent zu, nicht einen Coding-Agenten für Repo-Arbeit.

Wo das hineinpasst

Ein externer Agent verwandelt einen Chat-Thread in eine Live-Sitzung mit einem Coding-Werkzeug in einer Sandbox — du steuerst ihn in normaler Sprache, er arbeitet in einem isolierten Arbeitsbereich, und die Sitzung bleibt für Folgefragen bestehen, bis du den Thread schließt. Die Anmeldedaten sind die Achse, die entscheidet, wie viel davon unter der Kontrolle der Organisation läuft: Ein gateway-verwalteter Agent bleibt am Plattform-Gateway unter den Grenzen und der Erfassung der Organisation, während ein env-verwalteter oder BYO-Agent mit den Schlüsseln läuft, die du unter Umgebungsvariablen & Geheimnisse hinterlegst, und deinem eigenen Provider-Konto gegenüber rechenschaftspflichtig ist. Die Drift-Kandidaten hier sind die Agenten- und Modellnamen; kombiniere diese Seite mit der laufenden Provider-Liste, statt dir bestimmte Modellzeichenketten zu merken, und mit Integrationen für die verbundenen Integrationen, die der Agent erreichen kann — von GitHub für einen echten Pull-Request-Workflow bis zu einer Such- oder Datenintegration, die externe Fakten in die Arbeit holt. Wenn Claude Code oder Codex statt in der verwalteten Sandbox auf eigener Hardware laufen sollen — für Board-Aufgaben statt Chat —, sieh dir tale-daemon an.