Cline im Test: ein offener Coding-Agent mit jedem Modell und ohne Leitplanken

Cline ist ein Coding-Agent, der dort läuft, wo Ingenieure ohnehin arbeiten, und er will das Modell nicht besitzen. Er erscheint als VS-Code- und JetBrains-Erweiterung, als CLI, als Desktop-App und als SDK, alles auf einem Agent-Kern unter Apache-2.0, und jede Oberfläche verbindet sich mit dem Anbieter, den das Team ohnehin schon bezahlt. Die Position hier: das ist die richtige Voreinstellung für alle, die die Rechnung begründen müssen, und die falsche für alle, die eine Leitplanke erwarten, auf die man sich verlassen kann, denn das Berechtigungsmodell ist weicher, als es aussieht.

Er konkurriert direkt mit Claude Code, Cursor und den gehosteten Coding-Assistenten. Anders als jene ist er kein Produkt mit angehängtem Modell, sondern eine Harness mit Modells slot: Die Dokumentation nennt Claude, GPT, Gemini, OpenRouter, AWS Bedrock, GCP Vertex, Groq, Cerebras, DeepSeek, lokale Laufzeiten über Ollama und LM Studio sowie alles mit OpenAI-kompatibler Form. Diese Breite ist das Feature, und sie ist auch der Grund, warum ein Qualitätsvergleich mit einem geschlossenen Produkt wenig aussagekräftig ist: das meiste, was man an einem Coding-Agent lobt oder kritisiert, ist das Modell darunter.

Was Cline ist

• Apache-2.0, rund 70.000 GitHub-Sterne, 7.600 Forks und über 250 Beitragende, veröffentlicht als cline-CLI-Paket und als @cline/sdk-Bibliothek.
• Derselbe Agent-Kern hinter vier Oberflächen: IDE-Erweiterung, Terminal-CLI, Desktop-App für macOS, Windows und Linux sowie ein TypeScript-SDK zum Einbetten.
• Plan-Modus und Act-Modus als getrennte Zustände, mit der Möglichkeit, in beiden ein anderes Modell zu fahren.
• Checkpoints standardmäßig aktiv, die nach jedem Werkzeugaufruf einen vollständigen Snapshot des Arbeitsbereichs in ein separates Shadow-Git-Repository committen.
• Auto-Approve-Schalter pro Kategorie für Lesen, Bearbeiten, Befehle, Browser und MCP-Werkzeuge, dazu ein YOLO-Modus, der alle abschaltet.
• MCP-Unterstützung mit lokalen STDIO-Servern und gehosteten Streamable-HTTP-Endpunkten sowie Regeln aus .clinerules, .cline/rules, .cursorrules, .windsurfrules oder AGENTS.md.

Plan und Act, und warum die Trennung zählt

Der Plan-Modus ist keine Prompt-Anweisung. In diesem Zustand kann der Agent Dateien lesen, suchen und diskutieren, aber keine Datei ändern und keinen Befehl ausführen, und der Gesprächsverlauf geht unverändert in den Act-Modus über. Damit ist der Plan etwas, was das Werkzeug durchsetzt, und nicht etwas, woran das Modell sich erinnern soll. Das ist materiell besser, als ein Modell zu bitten, erst vorzuschlagen.

Checkpoints sind die andere Hälfte des Designs und verdienen mehr Aufmerksamkeit, als sie bekommen. Nach jeder Dateiänderung oder jedem Befehl committet Cline den aktuellen Zustand der Arbeitsdateien in ein Shadow-Git-Repository, das vollständig von der echten Historie getrennt ist. Daraus folgen drei Restore-Modi: Dateien zurück und Gespräch behalten, Aufgabe zurücksetzen und Code behalten, oder beides zurücksetzen. Das ist der Grund, warum Auto-Approve überhaupt vertretbar ist, und die Dokumentation ist offen darin, dass die Snapshots auf sehr großen Repositories Speicher kosten und den Agenten ausbremsen.

Plan und Act können auch auf unterschiedliche Modelle zeigen, und das ist der billigste Kostenhebel im ganzen Produkt: ein starkes Reasoning-Modell für die Erkundung, ein schnelles billiges für die Umsetzung. Bei kleinen Aufgaben empfiehlt die Dokumentation, die Planung ganz zu überspringen, denn der Planungsdurchgang ist reine Zusatzlast, wenn die Antwort offensichtlich ist.

Erste Schritte

Die CLI lohnt sich zuerst, weil sie die einzige Oberfläche ist, auf der die Freigabe-Defaults sichtbar sind und auf der der Agent unbeaufsichtigt laufen kann. Der Headless-Modus schaltet sich selbst ein, sobald --json übergeben wird, stdin eine Pipe ist oder stdout umgeleitet wird, was für CI eine angenehme Eigenschaft ist.

# Read every failing test and fix what caused them, then stop.
set -euo pipefail

npm test 2>&1 | tee /tmp/failures.log || true

# Plan-only pass: no writes, no commands, just an analysis to review.
cline -p "Explain why these tests fail and what the smallest fix is" \
  --json < /tmp/failures.log > /tmp/plan.jsonl

# Apply pass on a clean branch, with a hard stop so a loop cannot burn the budget.
cline "Apply the fix for the failures listed in /tmp/failures.log" \
  --auto-approve true \
  --timeout 600 \
  --retries 3 \
  --model anthropic/claude-sonnet-4-6 \
  | tee /tmp/run.log

# Fail the job when the suite is still red, so the pipeline does not ship a broken tree.
npm test

Drei Defaults in diesem Aufruf verdienen Kritik. --auto-approve ist in der CLI standardmäßig true, unbeaufsichtigte Läufe sind also die Grundeinstellung und nicht die Ausnahme. --retries begrenzt aufeinanderfolgende Fehlversuche und ist die einzige Bremse gegen einen Agenten, der an derselben fehlschlagenden Änderung hängenbleibt. Und --timeout ist der Wall-Clock-Stopp, der einen geplanten Job davon abhält, das Budget aufzuzehren.

Was es kostet

Die Software ist kostenlos, die Inferenz nicht. Erweiterung, CLI, Desktop-App und SDK haben keine Lizenzgebühr, die Grenzkosten eines Cline-Laufs sind also das, was der gewählte Anbieter für die Tokens einer Agentenschleife berechnet, und eine Agentenschleife verbrennt ein Vielfaches dessen, was ein Chat verbrennt, weil jedes Werkzeugergebnis zurück in den Kontext kommt. Es gibt keinen Seat-Preis zu verhandeln und keine Rechnung von Cline für den Open-Source-Pfad.

• Eigener Schlüssel: direkt beim Anbieter zahlen, unter einem Vertrag und einem Ausgabenlimit, das die Organisation already kontrolliert.
• Cline Usage-Billing: ein Konto, aufgeladene Guthaben, ein Guthaben über alle Modelle, die Cline vermittelt, bei denen einige zeitweise als FREE markiert sind.
• ClinePass für 9,99 $ im Monat, ein Flatrate-Abo, das die Dokumentation als das zwei- bis fünffache der Nutzung auf einem kuratierten Satz offener Coding-Modelle gegenüber dem Standard-API-Preis bewirbt.
• Enterprise: SSO, rollenbasierte Zugriffe, zentrale Abrechnung, Audit-Logs, VPC-Deployment und OpenTelemetry, alles davon im kostenlosen Stand nicht vorhanden.

Praktisch heißt das, dass die Kostenkontrolle aus dem Werkzeug in die Anbieter-Konsole wandert. Wer eine harte Obergrenze für Agentenkosten braucht, braucht entweder einen Anbieter, der eine durchsetzt, oder einen Wrapper um die CLI, der den Lauf bei einem Token- oder Dollar-Budget abbricht. Cline weist die Nutzung im Sitzungsverlauf und im Enterprise-Dashboard aus, stoppt einen Lauf bei einer Schwelle aber nicht selbst.

Das Berechtigungsmodell, ohne Beschönigung

Hier lohnt sich die Direktheit. Auto-Approve wird pro Werkzeugaufruf gegen einen Kategorie-Schalter geprüft, aber es gibt keine feste Allowlist von Befehlen. Das Modell markiert jeden Befehl anhand von Befehl und Argumenten als sicher oder freigabepflichtig, und die Dokumentation liefert Beispiele statt Garantien: Build- und Testbefehle gelten meist als sicher, Installationen, Löschungen, Moves und In-place-Änderungen meist als freigabepflichtig. Eine Sicherheitskontrolle, die implementiert ist, indem man ein Sprachmodell einen Shell-String klassifizieren lässt, ist eine Schranke, keine Grenze.

• Der YOLO-Modus gibt alles frei: Dateizugriffe überall auf dem Rechner, alle Terminalbefehle, Browseraktionen, MCP-Werkzeuge und sogar den Wechsel von Plan zu Act.
• Die Schalter für Lesen und Bearbeiten haben eine All-files-Variante, die den Zugriff über den Arbeitsbereich hinaus erweitert, wenn der Grundschalter an ist.
• Scheduling, Agent-Teams und Subagents gibt es in SDK, CLI und Kanban, nicht in den IDE-Erweiterungen. Eine in einer Oberfläche getestete Kontrolle fehlt also möglicherweise in einer anderen.
• Subagents sind konstruktionsbedingt nur lesend. Das ist der eine Teil des Werkzeugs, in dem eine Fähigkeitsgrenze echt und nicht nur empfehlend ist.

Wo es schmerzt

Die Zersplitterung ist die Steuerlast. Funktionen kommen zuerst ins SDK und die CLI und später in die Erweiterungen, was die Dokumentation für Scheduling, Agent-Teams und Subagents offen zugibt. Am schärfsten ist das JetBrains-Plugin: Das Repository sagt klar, dass JetBrains-Plugins nicht open-sourced werden, die IDE also, die ein großer Teil der Entwicklerbasis nutzt, ist genau die Oberfläche, die ein Prüfer nicht auditieren kann.

Der Umgang mit Kontext ist der zweite weiche Punkt und nicht spezifisch für Cline. Ein Agent, der Dateien liest, Tests startet, die Fehler liest und den Diff noch einmal liest, gibt den größten Teil seines Budgets für wiederholtes Lesen aus. Die dokumentierte Antwort sind Subagents, die parallel mit eigenen Kontextfenstern erkunden und einen kurzen Bericht zurückgeben, sowie Memory-Bank-Dateien für Struktur. Beides hilft, und keines ändert daran, dass eine agentische Sitzung auf einem großen Repository teuer ist im Verhältnis zum Wert der Änderung.

Und die Sicherheitsfläche des Werkzeugs selbst verdient dieselbe Prüfung wie jeder andere Agent: Das Repository hat eine Security Policy, und ein Projekt, das einem Agenten erlaubt, auf einer Entwicklerdatei- und Befehlsebene zu arbeiten, ist eine Abhängigkeit mit einer Shell. Version als gepinnte Abhängigkeit behandeln, das Changelog vor Upgrades lesen und die Anbieterschlüssel möglichst eng fassen.

Fazit

Cline ist die beste verfügbare Antwort für ein Team, das sein Modell wählen muss, seine Daten in einem bestehenden Anbietervertrag halten muss oder Agentenarbeit in CI automatisieren will, ohne dass das Berechtigungssystem eines Anbieters im Weg steht. Es ist keine bessere Variante eines geschlossenen Coding-Agenten, und Vergleiche, die die beiden gegeneinander stellen, vergleichen eine Harness mit einem Modell.

1. Teams, für die die Anbieterwahl eine Beschaffungsfrage und keine Präferenz ist.
2. Ingenieure, die Repository-Arbeit in CI automatisieren, denn die headless CLI und das SDK sind der Grund für die Einführung.
3. Alle, die auf einer Agent-Laufzeit aufbauen, denn @cline/sdk ist der Agent-Kern und kein Wrapper.
4. Nicht einführen in der Annahme, Checkpoints machten Autonomie sicher. Sie machen sie wiederherstellbar.
5. Nicht einführen, wo die Befehlsoberfläche ohne eigene Hooks beweisbar begrenzt sein muss, oder wo ein nicht auditierbares IDE-Plugin das Werkzeug ausschließt.

Quellen

1. Cline docs: Overview
2. Cline docs: Plan and Act mode
3. Cline docs: CLI reference
4. Cline docs: Auto Approve and YOLO mode
5. Cline docs: Checkpoints
6. Cline docs: MCP
7. Cline docs: Rules
8. Cline docs: ClinePass
9. Cline pricing
10. cline/cline auf GitHub